Summary

  • RFC 2019 treated a non-zero LLC priority on a valid IPv6 Router Advertisement, Neighbor Advertisement or Neighbor Solicitation received over FDDI as evidence about one neighbour path, not as proof of an end-to-end route.
  • That signal allowed unicast to that neighbour up to 4,352 octets; smaller mixed-media and multicast limits remained in force, and RFC 2467 removed the method in 1998.

In a mixed-media LAN, the safest number was also the least informative one. If FDDI shared a broadcast domain with a smaller-MTU technology, routers could advertise the minimum and every node would fit its packets to the weakest link. That prevented avoidable oversize traffic. It also meant two FDDI nodes might leave capacity unused even when the particular path between them never touched the smaller medium.

RFC 2019, published in October 1996, proposed a very specific escape from that dilemma for IPv6 over FDDI. Its default IPv6 MTU was 4,352 octets. A smaller Router Advertisement or manual setting could reduce the interface value. A larger advertised value could be logged, but was otherwise ignored. The default was a ceiling, not an invitation to believe every neighbour could receive it.

The interesting mechanism appeared at the bridge boundary. An enabled FDDI interface put a non-zero LLC priority on three Neighbor Discovery messages: Router Advertisements, Neighbor Advertisements and Neighbor Solicitations. RFC 2019 said an IEEE 802.1D bridge translating a frame from Ethernet to FDDI would set that priority to zero. A frame that originated on Ethernet, or had crossed Ethernet, would therefore arrive without the mark assumed by the design.

Now consider N1 receiving a valid marked message from N2. RFC 2019 allowed N1 to infer that this observed neighbour path had not crossed Ethernet. N1 could then send unicast packets to N2 as large as 4,352 octets, even if the shared interface setting or an advertisement was smaller. N2 might be the ultimate destination. It might instead be the next-hop router, in which case the permission ended at that hop.

That distinction is the whole design. The non-zero priority did not certify the rest of a routed path. It did not promise that tomorrow’s frame would traverse the same topology. It did not establish delivery or application completion. RFC 2019 referred to a valid Neighbor Discovery message, but validity was a protocol condition, not authentication. The contemporaneous RFC 1970 also kept receipt of unsolicited link-layer information distinct from confirmation of forward reachability; only a solicited Neighbor Advertisement performed that latter role in its cache processing.

Nor did the exception expand multicast. RFC 2019 required multicast packets to remain no larger than the smallest MTU among the media in the bridged LAN. Multicast has no single observed neighbour whose marked control frame can justify a private allowance. The rule therefore preserved a conservative common denominator for shared delivery while permitting a more generous bilateral choice for unicast.

The interface option made the bargain reversible. Implementations had to provide a way to disable the mechanism, although enabled was the default. A disabled interface sent the three control-message types with zero priority and supplied no evidence for the exception. The priority field could have been applied to all IPv6 traffic, but RFC 2019 said the control messages were sufficient for this purpose.

There is a clean operational logic here: observe one boundary effect, derive one negative fact, grant one scoped permission. The bridge’s zeroing behaviour did not reveal the full topology; it eliminated one path component from the observed adjacency under the assumptions of the 1996 specification. The resulting action was correspondingly narrow—larger unicast to one neighbour—and could fall back to the configured minimum.

The mechanism’s historical ending matters as much as its invention. RFC 2467 obsoleted RFC 2019 in December 1998. It kept the 4,352-octet default, kept the rule that an advertisement above the default or manually configured value was ignored, and retained the need to respect a smaller medium in a bridged LAN. But its changes section explicitly removed “FDDI adjacency detection,” citing recent IEEE 802.1p developments. It also warned against depending on bridge Path MTU Discovery unless the bridges were known to implement the relevant mechanisms correctly.

That replacement should not be rewritten as a security verdict or a deployment failure. RFC 2019’s own Security Considerations said that security issues were not addressed, and the official record does not quantify adoption or performance. What changed was the portability of the inference: when the meaning carried by the priority boundary could no longer be treated as stable, the standard stopped spending it.

What the mark did—and did not—say

Observation Permitted inference in RFC 2019 Not established
Valid RA, NA or NS arrives on FDDI with non-zero LLC priority The observed path from that neighbour did not traverse Ethernet under the RFC’s bridge premise End-to-end path, permanence, authentication, delivery or application success
A smaller MTU is configured or advertised Use the smaller value as the shared interface constraint That every FDDI neighbour is limited to that value
The marked neighbour is known Send unicast to that neighbour, or next-hop router, up to 4,352 octets Permission for multicast or for later hops
A larger MTU is advertised It may be logged Authority to exceed the default or manual ceiling

Sources