Summary

  • RFC 1118 assumed a site could already run a few IP hosts on an Ethernet, but had not yet joined the wider Internet.
  • Its answer was an operator-facing guide to allocation, escalation, information services and network etiquette, explicitly not a standard or tutorial.

The first connection problem was not only technical. A campus could have working hosts and still lack a unique network number, a clear upstream contact, or a way to learn which local decisions might affect other networks. RFC 1118, published in September 1989, addressed that gap as an onboarding document. Its audience was a small network already operating in isolation; its goal was to get that network connected with “little danger to either” side.

That boundary shaped the guide. It did not prescribe a new protocol. It collected pointers, literature and hints that the author said were rarely written down. It explained how the Internet’s direction was set, where online information could be found, and how a new participant could behave as a good neighbor. The practical object was not a packet format but the transition from local competence to participation in an interconnected system.

The guide made the operating hierarchy visible. ARPANET, NSFNET and regional networks had separate network operations centers. If a campus attached to a regional network had a problem, its liaison was told to contact that directly connected operator, even when the regional network itself reached NSFNET and ARPANET through gateways. The escalation path followed the relationship the site actually had. It did not ask a new campus to treat the most famous backbone as its first-line help desk.

Address allocation was another part of entry. The memo described a local network applying to SRI-NIC for a unique IP network number. It discussed then-current classful allocation and the pressure gateway tables faced as the number of networks grew. RFC 950 provided the formal subnetting procedure; RFC 1009 set out gateway requirements for vendors. RFC 1118 used those documents as context for decisions a campus administrator had to make. Its advice about class A/B/C allocations, named hosts and NIC contacts belongs to 1989. It is historical evidence, not a modern connection checklist.

The safety question was reciprocal. The guide described an Internet designed for roughly 50 networks that was approaching 1,000, along with gateway capacity and congestion pressures. It warned that gateways often accepted routing information on faith, so a rogue gateway could cause serious harm. Those passages do not show that one did so; they show why “connecting a network” carried obligations beyond making one host reachable. An announcement about reachability could affect traffic far outside the campus.

Information services were part of the same map. The guide pointed new users to SRI-NIC, while distinguishing services operated by BBN for CSNET and NSFNET and by Merit for NSFNET. Telnet, FTP, mail, mailing lists and operator contacts appeared as routes into information, not as a single central help system. The guide’s picture was distributed: responsibility and knowledge lived at different institutions, and a newcomer needed to know which door answered which question.

Its own status notice is unusually candid. RFC 1118 said no standards were specified. It called the editing uneven, joked that reality might be wrong when the document was inaccurate, and said the memo should change regularly because the Internet was dynamic. That is a maintenance promise, not evidence that every revision arrived or that readers used the guide. RFC 1123, published the next month, stated host application and support requirements in a more normative genre; it did not turn RFC 1118 into a protocol or erase its operational purpose.

The guide is valuable because it records a layer that protocol specifications can leave implicit: joining a network meant locating an operator, obtaining an address, finding current information and understanding what the surrounding networks expected. Its disclaimer did not make that knowledge useless. It made its shelf life part of the problem. A manual for a changing Internet had to be treated as a dated map whose claims needed confirmation, not as proof that the route was safe or that the site had successfully arrived.

Sources