Summary

  • RFC 1188 specified how IP datagrams and ARP messages used FDDI: a local LLC/SNAP grammar, a 4352-octet IP MTU and ARP conventions designed to keep FDDI and bridged Ethernet interoperable.
  • An EtherType, a 48-bit hardware address, an ARP mapping, a permitted frame size or a received link frame identifies only a bounded transport fact. It does not prove a person, ownership, authorization, route, receipt or application outcome.

The fast ring still needed a common sentence

FDDI promised a 100-Mbit/s fibre ring, but speed did not decide how an IP implementation should read the bits inside a local frame. RFC 1188, published by David Katz in October 1990 and replacing RFC 1103, supplied that missing agreement. It specified a method for IP datagrams and ARP requests and replies on FDDI and drew heavily on the earlier IEEE 802 interoperability model in RFC 1042.

The common sentence was LLC type 1 followed by SNAP. In the familiar notation, the two service access points are 0xAA, the control byte is 0x03, the organization code is zero, and the following protocol identifier distinguishes IP from ARP. Those fields tell a local receiver how to interpret an enclosed payload. They are deliberately narrower than the claims often later attached to a protocol label. A marker saying “IP” says what grammar the link layer has been asked to carry; it does not authenticate the originator, certify that the claimed IP address belongs to a particular person, or turn the frame into permission to use another system.

That modest boundary was the point of standardization. RFC 1042 had already required compatible IEEE 802 implementations to use LLC/SNAP so that IP and ARP could interoperate within each network type. RFC 1188 brought the same discipline to FDDI. It did not turn FDDI into a universal identity plane. An implementation could recognize a valid encapsulation and still have no evidence about the sender beyond the local frame, no authority over a remote host, and no proof that a higher layer would accept the traffic.

A large local frame was not an end-to-end entitlement

RFC 1188 set the FDDI IP MTU at 4352 octets. The document notes that a maximum FDDI frame left roughly 4470 octets for data after LLC/SNAP, but reserved additional space for possible MAC and frame-status overhead. Gateways had to accept MTU-sized packets and fragment when necessary. The number is a local engineering ceiling: it describes what a conforming FDDI network can place around an IP datagram under the specified rule.

The same RFC refuses the tempting conclusion that a host on such a ring may assume the whole Internet can take a 4352-octet datagram. A host must not send beyond the general 576-octet limit without explicit knowledge that the destination can accept more. The later RFC 1191 lists 4352 as the revised FDDI entry in its historical path-MTU table, but a table entry is not an observation of any particular route. A local MTU, a gateway's fragmentation duty and a remote path's usable size are three different propositions.

This distinction prevents a common narrative error. A large interface capability may make a packet possible at the first link; it does not establish that every next hop, endpoint, filter, transport session or application will accept it. Conversely, fragmentation is a mechanism for carrying an IP datagram across a smaller boundary, not a certificate that the original application transaction succeeded.

ARP mapped a local next-hop address, not a claimant

RFC 1188 also made an apparently mundane ARP decision consequential. FDDI permitted both 16-bit and 48-bit station addresses, but the RFC required only 48-bit addresses for IP and ARP to avoid interoperation trouble. For ARP in a bridged environment it required transmission with hardware type 1, acceptance of hardware types 1 or 6, and canonical bit order for the hardware addresses. FDDI's usual presentation placed the Group bit differently, so the bits in each octet had to be reversed for the ARP representation.

These rules do not make a hardware address a personal name. They make two local encodings compatible enough for a node to form and receive an ARP message. An ARP cache is useful because an IP implementation needs a next-hop frame destination on a particular medium. It is not a land registry, a login record, a proof that a remote IP stack is alive, or a command over the station whose address was returned.

The bridge wording makes the limitation unusually clear. RFC 1188 cared that FDDI and Ethernet conventions could meet without a bit-order misunderstanding. It did not claim that a response solves duplicate addresses, physical custody, routing choice, policy or security. The document's security section says security issues are not discussed. A reader should not manufacture a security conclusion from a compatibility rule that never offered one.

What later standardization changed—and did not prove

RFC 1390 records the 1993 Internet Standard successor for IP and ARP over FDDI. That is a useful revision marker. It is not evidence that RFC 1188 was itself the current standard, that an FDDI deployment existed at a named site, or that a present interface follows either document. The history is about a sharply bounded layer: an Internet community learned to make payload grammar, local address representation and frame budget explicit rather than treating them as implicit properties of a cable.

The durable lesson is therefore not “a MAC address is truth” or “a fast frame means delivery.” It is that a coordination layer becomes safer when it says exactly which fact it carries. RFC 1188 carried an IP or ARP payload over a particular FDDI framing rule. It left identity, ownership, authority, remote reachability and application effect where the evidence for each of those claims actually belongs.

Sources and evidence boundary

This historical analysis uses RFC 1042, RFC 1188, RFC 1191 and RFC 1390. They establish encapsulation conventions, historical MTU treatment and document succession. They do not establish current FDDI deployment, a named network, identity, ownership, authorization, a live path, delivery or application result.