Summary

  • RFC 1009 required Ethernet and serial-line connections as the minimum interconnection floor for different vendors' gateways in the NSF setting.
  • Its Appendix B separated that attachment rule from routing: in 1987, no open IGP let gateways from different vendors form one autonomous system.
  • The text records a procurement and interoperability design, not universal compliance, successful forwarding, or proof that a particular network used any one approach.

A common port did not make a common route

Two gateway systems could connect through Ethernet and still disagree about how to exchange routes. RFC 1009 put those facts next to one another. Appendix B required a common interconnection technology for NSF gateways, then acknowledged that vendor-to-vendor routing inside one autonomous system had no open IGP standard. The distinction is easy to miss if a physical link is treated as evidence of a working path.

Published in June 1987, RFC 1009 was a formal statement of Internet gateway requirements and vendor guidance. It describes the gateway as an IP-level router connected to two or more packet networks. A gateway had to implement the functions of each attached network as well as forward Internet datagrams and choose a next hop from its routing database. Those jobs crossed layers: an IP packet had to be framed for a constituent network, translated to its local address, and carried over a link that could differ from the one on the other side.

The document's general introduction says it was written specifically to support NSF research programs while stating the requirements in a general Internet context. The more specific procurement boundary appears in Appendix B, “NSFNET Specific Requirements.” Section B.2 says that, to ensure network-level interoperability among vendors' gateways in that setting, each gateway must support Ethernet and serial-line protocol connections at minimum.

Ethernet was a practical choice. The RFC describes it as mature, broadly available, and largely vendor independent. It calls Ethernet the common point of demarcation between NSF network systems supplied by different vendors. A supplier could use proprietary switching inside its own network, but its gateway still had to expose an Ethernet attachment to a gateway from another supplier. The rule placed the shared contract at the point where systems met; it did not prescribe every internal link or switching design.

The routing gap sat behind the handoff

Ethernet made packets able to cross a compatible link. It did not tell gateways which next hop to select. Section B.3 says the Internet then lacked an “open IGP” that would let gateways from different vendors form a single autonomous system. The RFC lists the workarounds rather than pretending the problem had already been solved.

One vendor used a proprietary interior protocol and connected to the rest of the Internet through EGP. RIP had supported successful multivendor interoperation, but the RFC notes that it was undocumented and that implementations differed in subtle ways. The NSF networking community had also built a gateway-daemon program to mediate among protocols. Its prototype ran on a 4.3BSD machine, spoke RIP and Hello to gateways inside the mixed system, and used EGP toward other autonomous systems.

These were different forms of compatibility. Ethernet supplied a common network attachment. RIP or a daemon supplied a way to exchange or translate route information. EGP handled information exchanged across autonomous-system boundaries. Neither the presence of a common Ethernet port nor the word “interoperability” proves that these systems agreed on a route, installed it, or forwarded a packet successfully.

The 1987 specification therefore captures an unfinished transition. A buyer could make a boundary interoperable before a common routing system existed. That separation gave NSF a concrete point at which to compare unlike vendors, while leaving the path-selection problem visible as its own task. RFC 1009 was later superseded by RFC 1812 in 1995; that document history does not identify the deployment or procurement choices of any individual network.

A minimum shared rule, with a procurement caveat

Lu Heng's later Note 64 proposes keeping a shared specification to the rules needed for interoperability and leaving other choices to participants running their systems. Read through that lens, RFC 1009 offers a useful example of scope: it named a common attachment, but it did not require one vendor's internal switching design. The analogy has limits. The NSF clause was a program requirement for gateways in its context, not a universal claim that future changes were voluntary or that the 1987 authors were advancing Note 64's later doctrine.

Sources and limits

The primary record is RFC 1009, especially Appendix B.2–B.3. RFC 985 is the predecessor draft; RFC 1812 later superseded RFC 1009. The specifications establish stated requirements and reported routing approaches. They do not establish a vendor's actual implementation, contract award, network-wide adoption, a converged route, or packet delivery.