LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

The Internet's Founding RFCs

14 min read Computing History
rfcietftcp-ipinternet-protocolnetworking-historycomputing-history
Contents

The most consequential technical documents of the twentieth century were not patents, standards, or specifications handed down by a committee with subpoena power. They were memos. Numbered, plaintext, often apologetic memos called Requests for Comments, the first of which was written in April 1969 by a graduate student so worried about overstepping his authority that he chose the deferential name on purpose. From that anxious first note grew a corpus of more than nine thousand documents that collectively define the protocols every connected device on Earth speaks, and — more importantly — a culture of design that explains why the internet is decentralized, robust, and effectively impossible to switch off. To understand why the internet works the way it does, you read the founding RFCs: RFC 1, which established the tone; RFC 791 and RFC 793, which established the protocols; and the April Fools’ joke RFC 1149, which, by specifying how to carry internet traffic on pigeons, accidentally explained the entire architecture better than any textbook.

This is a tour of those documents and the philosophy encoded in them. The thesis is simple: the internet’s resilience is not an accident of good protocol design alone — it is a direct consequence of how the protocols were designed, by whom, and under what rules. “Rough consensus and running code” is not a slogan; it is the reason a network built by a few dozen people in the 1970s scaled to billions of devices without ever being centrally redesigned.

RFC 1 and the culture of deference

On April 7, 1969, Steve Crocker, a UCLA graduate student, distributed a document titled “Host Software.” It described how the first computers on the ARPANET — the research network funded by the US Defense Advanced Research Projects Agency — might talk to one another. The ARPANET did not yet exist; the first Interface Message Processor would not arrive at UCLA until that autumn. The people writing the software had no authority over one another, no manager dictating a specification, and a real fear of seeming presumptuous. Crocker later explained that he chose the name “Request for Comments” precisely to sound humble and provisional, to make clear that these were notes open to revision rather than pronouncements. The group called itself, with similar modesty, the Network Working Group.

That humility became institutional. RFCs were openly distributed, anyone could write one, and the tone stayed conversational and undefensive for decades. The series found its center of gravity in one extraordinary person: Jon Postel, who served as RFC Editor from the early 1970s until his death in 1998, hand-curating the document series and simultaneously running the Internet Assigned Numbers Authority that doled out protocol numbers and addresses. Postel was sometimes called, only half-jokingly, the god of the internet, because for years the authoritative list of which protocol number meant which protocol was a file on his computer. The lineage runs straight back through the Unix culture of the same era — small groups, plaintext, open sharing, suspicion of bureaucracy — and the parallel is not coincidental; many of the same machines and people sat at both tables.

The deeper point is that the openness was load-bearing. Because anyone could read and implement an RFC for free, and because the documents carried no legal force, adoption was driven entirely by usefulness. A protocol survived if people implemented it and it worked. That selection pressure — implement, test, interoperate, or be ignored — is the genetic code of everything that followed.

The design philosophy that beat the alternatives

Before the specific protocols, the principles. Three ideas from the founding era explain why the TCP/IP stack outlasted its better-funded rival, the OSI model — a story told in full in How TCP/IP Actually Won.

The first is the end-to-end principle, articulated by Saltzer, Reed, and Clark in 1984 but implicit from the start: keep the network simple and push intelligence to the endpoints. The network’s only job is to move packets, best-effort; reliability, ordering, and encryption are the hosts’ problem. A “dumb” network with “smart” edges is easier to scale, harder to break, and trivial to extend — you can invent a new application without asking permission from the middle of the network.

The second is the robustness principle, stated verbatim in the early specs and now known as Postel’s Law: “be conservative in what you do, be liberal in what you accept from others.” Tolerate sloppiness from peers; emit only clean output yourself. This made early interoperability possible when every implementation was buggy. It also, as the honest section below admits, sowed problems the founders did not foresee.

The third is layering with a narrow waist. The stack is an hourglass: many applications on top, many physical media on the bottom, and one protocol — IP — at the pinch point that everything else funnels through. Anything that can carry IP can join the internet, and anything built on IP reaches the whole internet. That single architectural choice is why the network absorbed Ethernet, Wi-Fi, fiber, cellular, and (as we will see) carrier pigeons without redesign.

RFC 791: the Internet Protocol

In September 1981, two companion documents edited by Postel for DARPA froze the core. RFC 791 specified the Internet Protocol. It is worth dwelling on what IP deliberately does not promise: not reliability, not ordering, not duplicate suppression, not delivery at all. IP offers a single, humble service — best-effort delivery of a datagram from a source address to a destination address — and nothing more. This connectionless, fire-and-forget design is the narrow waist in concrete form.

The entire contract fits in a twenty-byte header:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |    DSCP/ToS   |          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|     Fragment Offset     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |        Header Checksum        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options (if IHL > 5)            | Padding   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Every field is a deliberate decision. TTL (time to live) is decremented at each router and the packet is discarded at zero — the loop-prevention insurance that lets a best-effort mesh tolerate transient routing errors without melting down, and the mechanism traceroute exploits. Protocol names the payload (6 for TCP, 17 for UDP, 1 for ICMP), the field that makes IP a multiplexer rather than a single-purpose pipe. Identification, Flags, and Fragment Offset support fragmentation, so a datagram larger than a link’s maximum transmission unit can be split and reassembled. The 32-bit Source and Destination Address fields are the famous limitation: four billion addresses sounded infinite in 1981 and ran out decades later, forcing the NAT workarounds and the slow IPv6 migration the honest section returns to.

One historical detail matters: TCP and IP began life as a single protocol in Cerf and Kahn’s 1974 work and were deliberately split apart around 1978. Separating routing (IP) from reliability (TCP) was the move that enabled UDP, ICMP, and every future transport to share the same network layer. Splitting them was the narrow waist becoming real.

RFC 793: TCP and reliability on a best-effort net

RFC 791’s companion, RFC 793, specified the Transmission Control Protocol — the layer that turns IP’s unreliable datagram service into the reliable, ordered byte stream that applications actually want. TCP’s job is to paper over everything IP refuses to guarantee: it numbers every byte with a sequence number, acknowledges received data, retransmits what goes missing, reorders what arrives scrambled, discards duplicates, and applies flow control via a sliding window so a fast sender cannot drown a slow receiver. Ports multiplex many conversations onto one host.

It opens every connection with the three-way handshake, the most-recited exchange in networking:

   Client                                   Server
     |                                         |
     |  ---------  SYN  (seq=x)  ------------>  |   "I want to talk; my
     |                                         |    byte stream starts at x"
     |  <----  SYN-ACK (seq=y, ack=x+1) -----  |   "OK; mine starts at y,
     |                                         |    and I got your x"
     |  ---------  ACK (ack=y+1) ------------>  |   "Got your y; we're synced"
     |                                         |
     |  ===========  connection established  ==|

You can watch it happen on any machine. A capture of a single TCP connection setup shows the three packets and their flags directly:

$ sudo tcpdump -n -S 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0' -c 3
IP 10.0.0.5.51514 > 93.184.216.34.443: Flags [S],  seq 2960132000, win 64240
IP 93.184.216.34.443 > 10.0.0.5.51514: Flags [S.], seq 1872051001, ack 2960132001
IP 10.0.0.5.51514 > 93.184.216.34.443: Flags [.],  ack 1872051002

[S] is SYN, [S.] is SYN-ACK, [.] is the bare ACK — RFC 793’s state machine, live on the wire forty-plus years later. The separation of concerns is total and is the point: IP gets the packet there; TCP makes the stream correct; neither knows the other’s job. This is the OSI-versus-TCP/IP layering distinction made concrete.

Here is the honest gap, though. RFC 793 as written in 1981 had flow control but no congestion control — nothing to stop senders from collectively overwhelming the network (as opposed to the receiver). That omission caused the internet’s first near-death experience: in October 1986 a link between Berkeley and the Lawrence Berkeley Laboratory suffered congestion collapse, with usable throughput falling roughly a thous-fold. Van Jacobson’s 1988 congestion-control algorithms — slow start, congestion avoidance, the additive-increase/multiplicative-decrease backoff — were bolted on afterward and only later codified in RFCs. The founding TCP was incomplete, and the fix is a model of the culture: someone wrote running code, it worked, and the RFC followed the implementation rather than preceding it.

Rough consensus and running code

How does a memo become a standard with no government behind it? The Network Working Group grew into the Internet Engineering Task Force, and in 1992 David Clark captured its ethos in a sentence that became the organization’s creed: “We reject: kings, presidents, and voting. We believe in: rough consensus and running code.” Both halves matter. Rough consensus means decisions are made not by majority vote but by the sense of the room that objections have been heard and substantially addressed — in IETF working groups this is sometimes gauged literally by humming rather than counting hands, a practice documented in its own RFC. Running code means a specification earns its stripes by being implemented, interoperably, by independent parties. An idea with two working, interoperating implementations beats an elegant idea with none.

The mechanics are deliberately lightweight. Anyone can submit an Internet-Draft, a working document that automatically expires in six months unless revised — a built-in forcing function against dead proposals. Drafts that achieve working-group consensus and demonstrated interoperability advance onto the standards track.

Document type Purpose Force
Internet-Draft Work in progress None; expires in 6 months
Proposed Standard Stable, reviewed, implementable The common real-world “standard”
Internet Standard Mature, widely deployed The highest maturity level
Best Current Practice (BCP) Operational/process guidance Normative for process
Informational / Experimental Ideas, research, FYI Non-normative
Historic Obsoleted or abandoned Deprecated

There is no membership roster, no fee, no national delegation — a pointed contrast with the formal, treaty-organization process of ISO and the ITU that produced OSI. You participate by showing up on a mailing list and contributing. That openness is exactly why the IETF could move faster than its institutional rivals, and why the protocols it produced were the ones with running code behind them. The same body still runs the modern internet’s evolution, from IPv6 to QUIC and HTTP/3, under the same rules.

RFC 1149: the joke that explains everything

Every April 1, the RFC series publishes a joke, and the most beloved is RFC 1149 (1990), “A Standard for the Transmission of IP Datagrams on Avian Carriers,” by David Waitzman. It specifies, in the deadpan register of a real protocol document, how to carry IP packets using homing pigeons: datagrams are printed on paper, rolled around the bird’s leg, and the bird constitutes the physical layer. A 1999 follow-up, RFC 2549, adds quality-of-service classes.

It is a joke, and it is also the single best illustration of the narrow-waist architecture ever written. IP, by design, does not care what carries it. Copper, fiber, radio, laser, or pigeon — if a medium can ferry a datagram from one place to another, IP runs over it, and everything built on IP runs over it too. The joke is funny because the architecture genuinely permits it, and in 2001 the Bergen Linux User Group proved the point by actually implementing RFC 1149: they sent nine ICMP echo-request packets to a host one carrier pigeon at a time, received four replies, and recorded round-trip times of roughly an hour with about 55 percent packet loss. Pigeon-based IP works, badly, exactly as the layering model predicts. There is real pedagogy in the gag: it teaches the end-to-end principle and the medium-independence of IP more memorably than any diagram, and the willingness to publish it is itself a window into a standards culture that never took itself too seriously.

What the founders got right, and what they left for later

Honesty requires separating the genius from the gaps. The founding RFCs got the architecture profoundly right: the narrow waist, the end-to-end principle, and best-effort datagrams produced a network that scaled twelve orders of magnitude in device count without a central redesign, absorbed physical media nobody had imagined, and survived the commercial internet, mobile, and cloud eras intact. That is an almost unmatched record of design longevity.

But they left real problems for their successors. Security was absent at the foundation — IP and TCP have no built-in authentication or encryption, because the early network was a small circle of trusted research institutions. Every security layer the modern internet relies on (TLS, IPsec, DNSSEC) was bolted on later, and the gaps in between are where decades of attacks have lived; the trust problem is the whole subject of the route-security story and the reason DNS needed hardening. Address space ran out — 32-bit IPv4 addresses forced the NAT kludge and a still-unfinished IPv6 migration that began in the 1990s. Congestion control was an afterthought, nearly fatal in 1986. And Postel’s Law has a dark side: being liberal in what you accept tolerates buggy implementations into ubiquity, which ossifies protocols (you cannot fix a field everyone now depends on misusing) and creates security ambiguities where a permissive parser and a strict one disagree about what a message means. The modern critique is that “be liberal in what you accept” should be retired in favor of strictness, and the design of QUIC — encrypted by default, versioned to resist ossification — is in part a deliberate reaction to exactly these founding-era compromises.

None of that diminishes the achievement. It contextualizes it: the founders solved the problem in front of them with the resources they had, wrote it down in plaintext, gave it away, and built a process that let everyone else fix the rest.

Verdict

The internet’s founding RFCs are worth reading not as historical curiosities but as the clearest available statement of why the network behaves as it does. RFC 1 set a tone of openness and humility that turned a few graduate students’ notes into a global commons. RFC 791 and RFC 793 encoded the narrow waist and the end-to-end principle into the IP and TCP headers still on every wire today, with the honest caveat that congestion control and security had to be added later by the same running-code process. And RFC 1149, the pigeon joke, captured the architecture’s deepest truth — medium independence — better than any serious document could. The throughline is the culture: rough consensus and running code, no kings or presidents, free and open documents, and a willingness to ship the imperfect-but-working over the elegant-but-theoretical. That culture, more than any single protocol, is the founders’ real invention, and it is why the internet was never centrally redesigned and never needed to be. Read the founding RFCs if you want to understand not just how the internet works, but why a system designed by so few, so long ago, still carries everyone.

Sources

Comments