Summary

  • RFC 1180 was a 1991 Informational tutorial for system administrators, programmers and network managers—not an Internet Standard or a complete TCP/IP history.
  • Its authors used UNIX and Ethernet examples to make forwarding visible, then told readers to consult the defining RFCs when a protocol specification mattered.

A route drawn for people who had to run it

The Internet’s protocols were already distributed across hosts, links and gateways. What RFC 1180 offered was a way to picture their cooperation. Its opening diagram stacked applications, TCP and UDP above IP, ARP and Ethernet. The accompanying text followed data down through those modules, across a local medium, then back up at a destination. T.J. Socolofsky and C.J. Kale wrote for systems administrators, systems programmers and network managers: readers who needed a working mental model, not a new protocol definition.

The memo chose examples from UNIX TCP/IP and Ethernet, but said its main points applied across implementations. That choice made the account concrete; it did not show that every Internet host ran UNIX or that Ethernet defined the Internet. The authors were careful about the distinction. RFC 1180 calls itself “bare bones,” lists major subjects it leaves out—including the history and funding of development, the business case and the relationship to ISO OSI—and says its purpose is explanation, not definition.

The router in the middle is not another endpoint

The tutorial’s practical center is forwarding. A host sends an IP datagram toward a destination; an IP router receives it on one network interface and can forward it through another. In RFC 1180’s model, that transit packet does not climb through the router’s TCP or UDP modules. Some router implementations need not contain those modules at all. The router’s job in this example is at IP, not to become the application endpoint.

That picture helped make “internet” less mysterious: IP links multiple physical networks into one logical reachability system while lower-level media can differ. It also helps separate what changes at a hop from what remains the addressed IP datagram. RFC 1180 did not claim to invent this architecture. It organized an explanation around a path that a professional could trace from the sending host to the receiving one.

The disclaimer is part of the tutorial

RFC 1180 was published as Informational in January 1991 and explicitly said it did not specify an Internet Standard. Its opening tells readers where authority lives: if a question concerns the correct specification of a protocol, consult the standards that define it. This is not boilerplate to skip. It is the document’s operating boundary.

That boundary had real neighbors. RFC 1122 set communication-layer requirements for Internet hosts; RFC 1123 covered application and support requirements. RFC 1180 cited RFC 1122 when noting that terminology varied between publications. It could simplify a diagram or use a UNIX example because it did not purport to settle every host obligation. RFC 1812 later specified IPv4 router requirements; it came after the tutorial and must not be projected backward into January 1991.

The distinction is not that one document is useful and another is authoritative. A tutorial can make a system teachable precisely by selecting a view. A standard answers a different question: what a conforming implementation is required or recommended to do. Confusing the map with the rulebook can turn one illustrative stack, interface or forwarding example into an obligation its authors expressly declined to create.

RFC 1180 therefore records a modest but important role in Internet history: explanation as infrastructure for professionals, kept separate from protocol authority. The source does not show how widely the tutorial circulated, whether it changed training outcomes, or what share of systems matched its UNIX examples. It shows what the authors intended the memo to do—and where they directed readers when explanation was not enough.

Sources and limits

RFC 1180; RFC Editor record; IETF Datatracker record; RFC 1122; RFC 1123; RFC 1812. These sources establish document status, contents and separate requirements; they do not measure distribution, professional influence, adoption or deployed operating systems.