RFC 2019

RFC 2019 🎀 A Method for the Transmission of IPv6 Packets over FDDI Networks

okay bestie, this is the RFC for running IPv6 over FDDI (the old fiber token ring stuff) 🦋 It's a Standards Track doc from October 1996, written by Matt Crawford at Fermilab ✨ It doesn't list anything it obsoletes or updates, so it's standing on its own 💅

• Number: RFC 2019
• Title: A Method for the Transmission of IPv6 Packets over FDDI Networks
• Author: Matt Crawford, Fermilab
• Category: Standards Track
• Date: October 1996
• Obsoletes / Updates: nothing listed

Status of this Memo 📜

this doc is an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions for improvements 🫶 for the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) edition that's out right now. And distribution of this memo is unlimited, so share away 💖

Introduction 🌸

this memo lays out the MTU and frame format for sending IPv6 [IPV6] packets over FDDI networks, plus a way to figure out the MTU when 802.1d bridges are hooked up to other media 🧚 It also covers how IPv6 link-local addresses get formed on FDDI, and what goes in the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages from [DISC] when they're sent over FDDI ✨

Maximum Transmission Unit 🍓

okay so FDDI allows a frame length of 4500 octets (9000 symbols), and that includes at least 22 octets (44 symbols) of Data Link encapsulation when long-format addresses are in use. Take off 8 octets for the LLC/SNAP header and you could, in theory, fit an IPv6 packet of up to 4470 octets in the Information field 🤯 BUT the author wants room for the MAC header and frame status fields to change size or get extended later, so the default MTU for IPv6 on FDDI is 4352 octets 💅

That default can get smaller. A Router Advertisement [DISC] with an MTU option that asks for a smaller MTU can lower it, and so can someone manually setting a smaller value on each node. Now here's the twist: if a Router Advertisement comes in with an MTU option bigger than the default or the manually configured value, that MTU option MAY be logged to system management, but it MUST be otherwise ignored 🙈 no sneaky bigger MTUs allowed!!

For this document, anything received from DHCP counts as "manually configured" 🎀

Frame Format 💖

FDDI does synchronous and asynchronous transmission, and the async side splits again into restricted and unrestricted tokens 🌈 Only asynchronous transmission with unrestricted tokens is REQUIRED for FDDI interoperability, so IPv6 packets SHALL be sent in asynchronous frames using unrestricted tokens. The robustness principle says that nodes SHOULD be able to receive synchronous frames and asynchronous frames sent with restricted tokens, because being lenient on receive is iconic behaviour 👑

IPv6 packets ride inside LLC/SNAP frames, using long-format (48 bit) addresses. The data field holds the IPv6 header and payload, and then comes the FDDI Frame Check Sequence, Ending Delimiter, and Frame Status symbols 🦋

    +-------+                                               ^
    |  FC   |                                               |
    +-------+-------+-------+-------+-------+-------+       |
    |            Destination FDDI address           |       |
    +-------+-------+-------+-------+-------+-------+      FDDI
    |              Source FDDI address              |     header
    +-------+-------+-------+-------+-------+-------+       |
    | DSAP  | SSAP  |  CTL  |          OUI          |       |
    +-------+-------+-------+-------+-------+-------+       |
    |   Ethertype   |                                       v
    +-------+-------+-------+-------+-------+------+------+
    |            IPv6 header and payload ...              /
    +-------+-------+-------+-------+-------+------+------+

FDDI Header Fields:

• FC: The Frame Code MUST be in the range 50 to 57 hexadecimal, inclusive, with the three low order bits telling you the frame priority. The Frame Code SHOULD be in the range 51 to 57 hexadecimal, inclusive, and there's a reason for that in the next section 🧐
• DSAP, SSAP: Both of these SHALL contain AA hexadecimal, which means SNAP encapsulation ✨
• CTL: This SHALL be set to 03 hexadecimal, meaning Unnumbered Information 💅
• OUI: This SHALL be set to 000000 hexadecimal 🎀
• Ethertype: This SHALL be set to 86DD hexadecimal, which is the IPv6 ethertype 🌸

Interaction with Bridges 🌉

802.1d MAC bridges that connect different media, like Ethernet and FDDI, are everywhere now 😭 Some of them do IPv4 packet fragmentation and/or support IPv4 Path MTU discovery [PMTU], but lots of others don't, or do it wrong 💀 So using IPv6 in a bridged mixed-media setup SHOULD NOT depend on support from MAC bridges. Protect your network from bridge drama 🫶

Here's the rule for mixed media: the smallest MTU of all the media MUST be advertised by routers in an MTU option. If there are no routers, this MTU MUST be manually configured on each node connected to a medium with a bigger default MTU 🔥 Multicast packets on a bridged network MUST NOT be larger than the smallest MTU of any of the bridged media. Sometimes the topology supports bigger unicast packets between certain pairs of nodes, so to get the high-MTU paths when they're available, nodes transmitting IPv6 on FDDI SHOULD implement the simple mechanism called "FDDI adjacency detection" 👑

Okay, the mechanism itself. A node that implements FDDI adjacency detection and has it enabled on an FDDI interface MUST set a non-zero LLC priority in all Neighbor Advertisement, Neighbor Solicitation and, when it applies, Router Advertisement frames sent on that interface. (In IEEE 802 language, the user_priority parameter of the M_UNITDATA.request primitive MUST NOT be zero.) If FDDI adjacency detection is disabled on an FDDI interface, the priority field of those frames MUST be zero 🙈

Now the plot twist: an IPv6 frame that started on an Ethernet, or went through one, gets translated by an 802.1d bridge and handed to a node's FDDI interface, and that frame will have zero in the priority field, as REQUIRED by [BRIDGE] 💅 (There's a fine point here: a conforming bridge MAY provide a management-settable Outbound User Priority parameter for each port. The author doesn't know of any product that offers this optional capability, and either way the default value for the parameter is zero 🤓)

If a node N1 receives, in an FDDI frame with a non-zero LLC priority, a valid Router Advertisement, Neighbor Advertisement, or Neighbor Solicitation from a node N2, then N1 MAY send unicast IPv6 packets to N2 with sizes up to the default IPv6 FDDI MTU (4352 octets). This applies no matter what smaller MTU was configured manually or received in a Router Advertisement MTU option! N2 MAY be the IPv6 destination or the next hop router to the destination ✨

Nodes that implement FDDI adjacency detection MUST provide a configuration option to turn the mechanism off. That option MAY be used when you want a smaller MTU for reasons other than mixed-media bridging. By default, FDDI adjacency detection SHOULD be enabled 🎀

The only planned use of the LLC priority field of the FC octet is helping with per-destination MTU determination. For that purpose it would be enough to only require that Router Advertisements, Neighbor Advertisements, and Neighbor Solicitations sent on FDDI always have non-zero priority. However, it MAY be simpler or more useful to send all IPv6 packets on FDDI with non-zero priority 🌈

Stateless Autoconfiguration and Link-Local Addresses 🦋

The address token [CONF] for an FDDI interface is the interface's built-in 48-bit IEEE 802 address. It's in canonical bit order, with the octets in the same order they'd show up in the header of an ethernet frame. (The individual/group bit is in the first octet, and the OUI is in the first three octets.) A different MAC address that's set manually or by software SHOULD NOT be used as the address token 🙅‍♀️

An IPv6 address prefix used for stateless autoconfiguration of an FDDI interface MUST be 80 bits in length 💖

The IPv6 Link-local address [AARCH] for an FDDI interface is formed by appending the interface's IEEE 802 address to the 80-bit prefix FE80:: ✨

   +-------+-------+-------+-------+-------+-------+------+------+
   |  FE      80      00      00      00      00      00     00  |
   +-------+-------+-------+-------+-------+-------+------+------+
   |  00      00   |                  FDDI Address               |
   +-------+-------+-------+-------+-------+-------+------+------+

Address Mapping -- Unicast 🧚

The way IPv6 addresses get mapped into FDDI link-layer addresses is described in [DISC]. The Source/Target Link-layer Address option looks like this when the link layer is FDDI 💅

   +-------+-------+-------+-------+-------+-------+------+------+
   | Type  |Length |                 FDDI Address                |
   +-------+-------+-------+-------+-------+-------+------+------+

Option fields:

• Type: 1 for Source Link-layer address. 2 for Target Link-layer address.
• Length: 1 (in units of 8 octets).
• FDDI Address: The 48 bit FDDI IEEE 802 address, in canonical bit order. This is the address the interface is currently responding to, and it MAY be different from the built-in address used as the address token 🌸

Address Mapping -- Multicast 🌈

An IPv6 packet with a multicast destination address DST gets sent to the FDDI multicast address whose first two octets are 3333 hexadecimal, and whose last four octets are the last four octets of DST, ordered from most to least significant 🦋

         +-------+-------+-------+-------+-------+-------+
         |  33   |  33   | DST13 | DST14 | DST15 | DST16 |
         +-------+-------+-------+-------+-------+-------+

Security Considerations 🔐

⚠️ Security considerations are not addressed in this memo. Yes, that's the whole section, and yes, it's a bit of a plot hole, so keep that in mind before you deploy anything 😭

Acknowledgments 🫶

Erik Nordmark contributed to the method for interaction with bridges 💜

References 📚

• [AARCH] Hinden, and S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, December 1995.
• [BRIDGE] ISO/IEC 10038 : 1993 [ANSI/IEEE Std 802.1D] Media access control (MAC) bridges.
• [CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971, August 1996.
• [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996.
• [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, August 1996.
• [PMTU] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.

Author's Address 💌

Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA

Phone: +1 708 840-3461

EMail: crawdad@fnal.gov