Transmission of IPv6 Packets over Token Ring Networks
updated by
- rfc-8064 — Recommendation on Stable IPv6 Interface Identifiers
Extracted elements (21)
The MTU priority order (source route bridging LF values first, then router advertisements, then manual configuration, then default 1500) reflects that more specific path information should override more general configuration, but manually configured values cap what router advertisements can claim.
The U/L bit in the EUI-64-derived Interface Identifier is complemented so that a globally unique (universally administered) address, which has U/L=0 in IEEE 802 convention, becomes U/L=1 in the IPv6 Interface Identifier convention for global uniqueness. This aligns Token Ring with the IPv6 addressing architecture.
Protocols other than IPv6 may use the same Token Ring functional addresses mapped from IPv6 multicast addresses, so not all Token Ring frames destined to these functional addresses are guaranteed to be IPv6 datagrams.
Some 802.1D LF values in source route bridging result in a maximum IP MTU less than the IPv6 minimum of 1280 bytes (e.g., LF base 001 yields IP MTU 1462, but lower LF values yield less). Communication across such paths using IPv6 is generally not possible.
Token Ring adaptors assume addresses are in non-canonical rather than canonical format, requiring special care to ensure addresses are processed correctly. Implementors must consult RFC 2469 for details on canonical bit order.
A manually set or software-assigned MAC address should not be used to derive the Interface Identifier. If such a MAC address must be used, its global uniqueness property should be reflected in the U/L bit value.
An implementation MAY allow sending IP multicast traffic using an All Routes Explorer (for compatibility with old bridges that do not support Spanning Tree Explorer), but this ability must be configurable by a system administrator and the default MUST be to use the Spanning Tree Explorer.
An IPv6 address prefix used for stateless autoconfiguration of a Token Ring interface must have a length of 64 bits.
In a bridged token ring network, all multicast packets SHOULD be sent with a RIF header specifying the use of the Spanning Tree Explorer.
In an 802.5 LLC/SNAP frame carrying IPv6, DSAP and SSAP shall always contain 0xAA, CTL shall always contain 0x03, OUI shall always contain 0x000000, and EtherType shall always contain 0x86DD.
In the absence of any other information, an implementation should use a default MTU of 1500 octets. This size offers compatibility with all common 802.5 defaults and with Ethernet LANs in environments using transparent bridging.
The Token Ring address in the Source/Target Link-layer Address option must be in canonical bit order and is the address the interface currently responds to, which may differ from the built-in address used to derive the Interface Identifier.
When source route bridging is used and an implementation derives MTU from the LF subfield, it must maintain separate MTU values for each neighbor. The IPv6 MTU is the MAC MTU (from the LF subfield) minus 8 octets for the LLC header.
All IPv6 packets with multicast destination addresses are transmitted to Token Ring functional addresses. All-Nodes and solicited-node addresses map to 03-00-80-00-00-00; All-Routers addresses map to 03-00-40-00-00-00; other multicast addresses map to one of eight functional addresses based on the three least-significant bits of the IPv6 multicast address.
The Interface Identifier for a Token Ring interface is derived from the 48-bit IEEE 802 address by expanding it to EUI-64 (inserting FFFE after the OUI) and then complementing the Universal/Local bit (next-to-lowest-order bit of the first octet).
The IPv6 link-local address for a Token Ring interface is formed by appending the Interface Identifier to the prefix FE80::/64, yielding a 128-bit address with 10-bit prefix 1111111010, 54 zero bits, and 64-bit Interface Identifier.
When source routing bridges are used, the source route to a destination can be extracted from the RIF field of received Neighbor Advertisement messages. The RIF can be reversed for return traffic by toggling the D bit and setting Bcast to indicate a Specifically Routed Frame.
Token Ring, like most broadcast LAN technologies, has inherent security vulnerabilities: any sender can claim the identity of another and forge traffic. Higher layers are responsible for taking appropriate steps in environments where such vulnerabilities are unacceptable.
IPv6 packets are encapsulated in LLC/SNAP frames on Token Ring. The DSAP and SSAP fields shall always be 0xAA, CTL shall always be 0x03 (Unnumbered Information), OUI shall always be 0x000000, and EtherType shall always be 0x86DD for IPv6.
The Routing Information Field (RIF), when present (indicated by the most significant bit of the source address being set to 1), begins with a 2-octet Routing Control header containing Bcast (3 bits), Length (5 bits), D (1 bit), LF (4 bits), and rsvd (3 bits), followed by zero to seven 2-octet Route Designator fields each containing a 12-bit segment number and 4-bit bridge number.
The Source/Target Link-layer Address option for Token Ring has Type (1=source, 2=target), Length field of 1 (in units of 8 octets), and a 48-bit Token Ring address in canonical bit order.