There are several types of IETF RFCs, including strict standards, looser “best common practices”, as well as purely informational documents. Today we’ll look at RFC 1180, a tutorial on how TCP/IP typically worked as of 1991 (when this document was written). This RFC is more than 30 years old, so I’ll mention a few possible updates that come to mind as I read it. This is probably going to feel a bit abrupt in places—think of it more as a set of notes than a fully synthesized RFC revision.

Sections 1 & 2 (Introduction and TCP/IP Overview)

RFC 1180 starts with a discussion of the basic structure of TCP/IP. This has not fundamentally changed, but there are some recent competitors to TCP, such as QUIC, that should be noted. Likewise, while Ethernet is still in widespread use, many people rely on wireless link layer protocols.

Section 3 (Ethernet)

Ethernet started as a shared-bus protocol and relied heavily on carrier-sense multiple access to manage communication on broadcast channels. These days it’s mostly used with point-to-point full duplex links, connected via switches, so the emphasis has moved from medium access control techniques to packet switching.

Section 4 (ARP)

ARP solves the problem of determining link-layer MAC addresses given an IP address. RFC 1180 describes a “typical scenario” in which the destination IP address is used to directly look up the destination MAC address, so that an Ethernet frame can be constructed. There are two extensions of this discussion that I’d consider:

1. A typical case not mentioned is when an IP packet is destined for an address outside of the current subnet. In this case the IP packet needs to be sent to the next-hop router, and so it is this next-hop router’s MAC address that is needed. While this can be inferred from the discussion in the next section (on IP), I think it would have been worth an explicit call-out here.
2. By now, we recognize some of ARP’s weaknesses, such as ARP spoofing.
3. Although ARP is still used for IPv4, it is not used for IPv6. Instead, see Neighbor Discovery Protocol.

Section 5 (Internet Protocol)

Overall this section was clear, and I found the distinction between Direct Routing (where IP adds little beyond Ethernet) and Indirect Routing (where IP is used to connect multiple Ethernet networks) well motivated. The extended discussion is dated in a few ways:

1. This section predates CIDR. So the discussion on addressing, as well as the routing examples, are “classful”.
2. There’s also no mention of DHCP, since it didn’t exist at the time.
3. RFC 1180 discusses the role of hosts files in associating names to IP addresses. While these are still used today, DNS is the main mechanism for managing this association.
4. There’s no discussion of IPv6.

Section 6 & 7 (UDP and TCP)

As far as I can tell, UDP hasn’t really changed since 1991. Maybe the only thing I would add here is some additional context around which contemporary application protocols use UDP.

TCP, on the other hand, has seen a lot of development, even if the basic protocol has not changed. Just a few examples:

1. There has been a fair amount of work on TCP congestion control. This has ramifications at lower levels of the stack (e.g. router bufferbloat), and is probably worth mentioning if only briefly.
2. This tutorial is notably light on security. I think it should include a discussion of TLS.

Section 8 (Network Applications)

In terms of philosophy, this section is still well motivated. But the particular examples (TELNET, FTP, rsh, NFS, SNMP, X-Windows) could be revised. Here are a few protocols I’d mention:

1. HTTP and HTTPS are ubiquitous examples that must be mentioned.
2. ssh as a modern and widespread replacement for rsh.
3. A mail or messaging protocol, like SMTP.
4. Some RPC protocol like gRPC.
5. Perhaps a reference to an overlay protocol like Tor.

Concluding Thoughts

When writing a tutorial there’s a tension between what to include and what to leave out. On the whole I think the authors of RFC 1180 did an admirable job. These days, this kind of “overview” can be found in any networking textbook, but in 1991 such information was undoubtedly harder to come by. I imagine this RFC helped orient a generation of system administrators, software developers, and network operators to the organization and function of the TCP/IP stack.