Transmission of IP and ARP over FDDI Networks
also
- std-36
Extracted elements (24)
Although the IEEE 802 hardware type code for ARP is 6 and FDDI is an 802 network, ARP uses hardware type 1 (Ethernet) to avoid interoperability problems when bridging to Ethernet networks. Using differing type codes would break ARP through translational bridges.
IEEE specifies numbers as bit-string little-endian (least significant bit first), while Internet protocols are documented in big-endian order. An appendix provides a conversion table for all relevant constants (UI, SAP for SNAP, XID, TEST, etc.) to avoid confusion between the two conventions.
The MTU was set to 4352 rather than the full FDDI maximum (~4470 usable octets) to reserve additional space for future MAC header and frame status field extensions, providing a stable MTU value with headroom for evolving standards.
RFC 1390 removes acceptance of ARP frames bearing hardware type code 6 (IEEE 802) compared to its predecessor RFC 1188, and makes explicit the intent to support FDDI/Ethernet interoperability via translational bridges. These changes affect implementations upgrading from RFC 1188.
All implementations must support IEEE 802.2 standard Class I service, including Unnumbered Information (UI) commands, XID commands and responses, and TEST commands and responses. Stations need not transmit XID/TEST commands but must be able to transmit responses.
All IP and ARP frames must be transmitted in standard 802.2 LLC Type 1 Unnumbered Information format. The DSAP and SSAP fields must be set to the SNAP SAP value (170 decimal), and 802.2 LLC Type 1 communication is used exclusively.
All IP and ARP frames shall be transmitted as Asynchronous LLC frames using Unrestricted tokens. The priority value is a local convention; implementations should make priority a tunable parameter.
ARP packets shall be transmitted with a hardware type code of 1 (Ethernet) and shall be accepted only with a hardware type code of 1. The IEEE 802 hardware type code of 6 must not be used or accepted.
FDDI implementations must be prepared to receive and ignore trailing pad octets to maintain interoperability with Ethernet in a bridged environment.
Gateway implementations must be prepared to accept packets as large as the MTU and fragment them when necessary. Gateways should also be able to accept packets as large as can be carried within a maximum-size FDDI frame.
Hardware addresses in ARP packets (ar$sha, ar$tha) must be carried in canonical bit order, with the Group bit as the low order bit of the first octet. Because FDDI addresses are normally expressed with the Group bit in the high order position, addresses must be bit-reversed within each octet for ARP.
Host implementations must not send datagrams longer than 576 octets unless they have explicit knowledge that the destination is prepared to accept them. Hosts should be prepared to accept packets as large as the MTU. The TCP MSS option may be used to communicate size preferences.
Hosts directly connected to FDDI networks shall not use trailer encapsulation. Some Unix 4.x BSD systems use trailers for VAX virtual memory performance, but these are prohibited on FDDI.
If IP multicasting is supported on FDDI networks, the method specified in RFC 1112 shall be used. Implementation may require the ability to copy frames addressed to an arbitrary number of multicast group addresses.
Only 48-bit FDDI addresses shall be used with IP and ARP to avoid interoperability problems arising from FDDI's partial support for 16-bit and 48-bit address interworking.
The 24-bit Organization Code in the SNAP header must be zero; the remaining 16 bits carry the EtherType from Assigned Numbers (IP=2048, ARP=2054). SNAP must be used with an Organization Code indicating EtherType.
The broadcast Internet address must be mapped to the all-ones FDDI broadcast address. The 32-bit IP broadcast (host part all ones) maps to the 48-bit FDDI broadcast (all binary ones).
The MTU of FDDI networks shall be 4352 octets, providing 4096 octets of data plus 256 octets of headers at the network layer and above. Implementations must not send packets larger than the MTU.
When an XID or TEST command is received with DSAP equal to the SNAP SAP (170), Null SAP (0), or Global SAP (255), an appropriate response must be returned. XID responses must include an 802.2 XID Information field of 129.1.0 indicating Class I service; TEST responses must echo the received information field.
An IP multicast address is mapped to an FDDI group address by placing the low-order 23 bits of the IP address into the low-order 23 bits of the FDDI group address 01-00-5E-00-00-00 (canonical order). The resulting FDDI address is bit-reversed per-octet for transmission in the destination MAC field.
ARP fields for FDDI: hardware type (hrd) = 1, protocol type (pro) = 2048, hardware address length (hln) = 6, protocol address length (pln) = 4, operation code (op) = 1 for request, 2 for reply.
Security issues are not discussed in this memo. No authentication, integrity, or confidentiality mechanisms are specified for IP or ARP over FDDI.
802.2 LLC control field encodings (Internet bit order): UI=3, XID=175 (Poll/Final off) or 191 (Poll/Final on), TEST=227 (Poll/Final off) or 243 (Poll/Final on). Command frames have SSAP low-order bit=0; response frames have it set to 1.
IP and ARP frames on FDDI are encapsulated in 802.2 LLC/SNAP headers totaling 8 octets: DSAP=170, SSAP=170, Control=3 (UI), 24-bit Organization Code=0, and a 16-bit EtherType (IP=2048, ARP=2054). This sits atop the FDDI MAC and physical layers.