The 1983 TCP/IP flag day usually arrives as an anecdote. On 1 January 1983 the ARPANET stopped speaking NCP, started speaking TCP/IP, and the people who got it done handed out buttons. The buttons were real. What almost never gets read is the document that made the date operational: RFC 801, NCP/TCP Transition Plan, Jon Postel, ISI, November 1981.
Twenty-one pages, about five thousand words of plain text, free, twenty minutes to read — and a better migration plan than most of the ones written in the last five years.
That is a claim about contents, not nostalgia. RFC 801 names a cutover date and an earlier, separately mandatory start date; specifies transitional bridging services and walks their user-visible steps through three appendices; lists the exact documents an implementer needs and the month each will exist; carries a readiness inventory of thirteen implementations, dated and contributed by the engineers who wrote them; and publishes a capacity model for the transitional infrastructure with the author’s own warning about how far to trust it.
It also never uses the word “rollback.”
The Clock Started Six Weeks After the Plan Was Published
Get the arithmetic right; the popular version compresses two numbers into one. RFC 801’s “General Plan”:
“The goal is to make a complete switch over from the NCP to IP/TCP by 1 January 1983. It is the task of each host organization to implement IP/TCP for its own hosts. This implementation task must begin by 1 January 1982.”
Published November 1981. Work must begin by 1 January 1982, roughly six weeks later, and be complete by 1 January 1983: a twelve-month mandatory countdown, not a two-year one.
The multi-year story sits underneath the mandate, not inside it. The Department of Defense had made these protocols a defense standard three years earlier: RFC 760 is “DOD STANDARD INTERNET PROTOCOL”, January 1980, and its companion RFC 761 is “DOD STANDARD TRANSMISSION CONTROL PROTOCOL”, the same month. RFC 801 records the consequence: the DoD had adopted them “as DoD wide standards for all DoD packet networks,” and would be “transitioning to this architecture over the next several years.”
The participants say the same about the community half. A Brief History of the Internet — the Internet Society’s account co-authored by Leiner, Cerf, Clark, Kahn, Kleinrock, Lynch, Postel, Roberts and Wolff — says the cutover “was carefully planned within the community over several years before it actually took place”.
So: a hard twelve-month mandate sitting on a three-plus-year runway. Both numbers are true, and merging them into one loses the shape of the thing.
That same document disposes of a framing argument. “Flag day” is not a populariser’s exaggeration imposed afterwards — the phrase is the nine architects’ own, and so are the quotation marks around it. Their sentence describes a “flag-day” style transition, “requiring all hosts to convert simultaneously or be left having to communicate via rather ad-hoc mechanisms.” A long runway ending in a hard cutover. The two descriptions are not in competition.
(Why the ARPANET was converging on this stack at all — the rivals, the procurement fights, the contested historiography — belongs to this hub’s cornerstone on the protocol wars. This article is only about the mechanics of the move.)
Nine Milestones, and Four of Them Were Already Done
The plan’s Milestones section is nine rows. Four of them carry the word already in the date column instead of a month:
| Milestone | Date in RFC 801 | What it meant |
|---|---|---|
| First Internet Service | already | “A few hosts are TCP-capable and use TCP-based services.” |
| First TCP-only Host | already | The first host with no NCP at all was live |
| Telnet and FTP Relay Service | already | Bridging accounts available to qualified users |
| Ad Hoc Mail Relay Service | already | Prototype MTP relay, TCP-only to NCP-only, one direction |
| Last NCP Conversion Begins | Jan 82 | The slowest host starts |
| Mail Relay Service | Jan 82 | SMTP relay plus at least one special forwarder |
| Normal Internet Service | Jul 82 | “Most hosts are TCP-capable” |
| Last NCP Conversion Completed | Nov 82 | The slowest host finishes |
| Full Internet Service | Jan 83 | NCP removed, relays end, everything TCP-based |
Two things in that table are worth more than the date everyone remembers.
The plan was published after the migration had begun. The Discussion section says so outright: “The implementation of IP/TCP on several hosts has already been completed, and the use of some services is underway.” The countdown was written for the stragglers, by a team that had already proven the path on real hosts and stood up the bridge. Nobody was asked to go first.
The last conversion is scheduled two months before the switch-off
Look at the gap between the last two rows. The last NCP-only host is scheduled to finish converting in November 1982. NCP is not removed from service until January 1983 — a deliberate two-month gap between “everybody has moved” and “the old thing stops existing,” sitting between the milestone the migration owner controls and the milestone that is irreversible.
Modern plans routinely put those two events on the same day, then discover the difference between migrated and migrated and verified at the worst possible moment. Postel put eight weeks between them and wrote both dates down.
The Word “Relay” Appears Eighty-Two Times
RFC 801 runs about five thousand words. The string relay, in all its capitalisations, appears 82 times. That count tells you where the plan thought its risk actually lived, and it was not in the cutover. The mechanism is stated up front:
“Because all hosts can not be converted to TCP simultaneously, and some will implement only IP/TCP, it will be necessary to provide temporarily for communication between NCP-only hosts and TCP-only hosts. To do this certain hosts which implement both NCP and IP/TCP will be designated as relay hosts.”
Three services, three bridges. Telnet relay hosts ran both stacks and both user and server Telnet; FTP relay hosts did the same for file transfer; mail was bridged by SMTP relaying plus a special forwarder that rewrote user.host@forwarder addresses across the boundary.
Appendices A, B and C then do something plans almost never do: they write out the user-visible procedure, step by step, for each bridge. Appendix B’s FTP scenario runs seven numbered steps in phase one and four in phase two, ending on a warning that has nothing to do with protocols and everything to do with running a migration:
“Note that the relay host may have a policy of deleting files more than a few hours or days old.”
That is the transitional workaround documented honestly, including the part where it will lose your file. The plan then names both failure modes of a bridge before either has happened:
“The reliability is a concern because relaying puts another host in the chain of things that have to all work at the same time to get the job done.”
“The load is a potential problem, since an overloaded relay host will lead to unhappy users.”
The mitigation for both is the same, stated once: “It is desirable to provide alternate relay hosts if possible.” Redundancy for reliability, horizontal spread for load — argued from first principles, in 1981, about a compatibility shim nobody intended to keep.
Postel Modelled the Interop Load, Then Called His Own Model Speculative
The best page in RFC 801 is headed “A Digression on the Numbers” and opens with the question every migration owner asks about the compatibility layer and almost none answers on paper: “How bad could it be, this relay load?”
The model is one sentence. A host that speaks both protocols is not a customer of the bridge — it “takes itself out of the game” — so:
“Let us postulate that the number of NCP-only hosts times the number of TCP-only hosts is a measure of the relay load.”
An N×M interop-surface estimate. Then the projection, reproduced as published:
| Total hosts | Dual | NCP-only | TCP-only | “Load” | Date |
|---|---|---|---|---|---|
| 200 | 20 | 178 | 2 | 356 | Jan-82 |
| 210 | 40 | 158 | 12 | 1,896 | Mar-82 |
| 220 | 60 | 135 | 25 | 3,375 | May-82 |
| 225 | 95 | 90 | 40 | 3,600 | Jul-82 |
| 230 | 100 | 85 | 45 | 3,825 | Sep-82 |
| 240 | 125 | 55 | 60 | 3,300 | Nov-82 |
| 245 | 155 | 20 | 70 | 1,400 | Dec-82 |
| 250 | 170 | 0 | 80 | 0 | 31-Dec-82 |
| 250 | 0 | 0 | 250 | 0 | 1-Jan-83 |
The load peaks in September 1982, nowhere near the deadline. It rises about elevenfold from the start of the mandate, tops out four months before the cutover, then falls off a cliff as the last NCP-only hosts disappear. The compatibility burden is highest in the middle of a migration, when the population is genuinely split, and it reaches zero not gradually but at the moment the old protocol is removed.
Read the last two rows together as well. On 31 December 1982 the plan expects 170 dual-protocol hosts; on 1 January 1983, zero, and 250 TCP-only. The dual-stack code is not carried forward. It is deleted, on schedule, as a planned deliverable.
Postel also shows the counterfactual that makes the model worth having. Had the initial 200 hosts “immediately split into 100 NCP-only and 100 TCP-only”, his own arithmetic puts the load at 10,000 — nearly three times the projected worst case, and the argument for pushing hosts to dual-stack early rather than letting them cut over cleanly one at a time.
And then the part that decides whether you trust the whole document:
“This load measure (NCP hosts times TCP hosts) may over state the load significantly.”
“Please note that this digression is rather speculative!”
The author publishes his estimate, names the direction of its likely error, and labels its confidence — in the plan itself, where the people relying on it will see it. That is not humility as a personality trait. It is a projection a reader can use correctly, which an unlabelled one cannot be.
Search RFC 801 for “Rollback” and You Get Nothing
Because the plan is plain text and free, claims about what it contains are checkable in seconds. A full-text search of the raw file, with whitespace collapsed and line-break hyphenation removed, on 8 September 2026:
| Term | Occurrences in RFC 801 |
|---|---|
rollback, roll back, fallback, fall back | 0 |
contingency | 0 |
revert, back out | 0 |
risk | 0 |
fail, failure | 0 |
delay, postpone, slip | 0 |
penalt, consequence, sanction | 0 |
enforc, waiver, exception | 0 |
authority, approval, review | 0 |
budget, cost, funding | 0 |
deadline | 0 |
test | 1 |
There is no rollback plan, because there is no rollback. That is the actual content of the phrase “flag day,” stated by omission: the plan does not discuss reverting to NCP under any circumstance, at any date, for any host. The only outcome it describes for a host that misses the date is the one the participants named — being “left having to communicate via rather ad-hoc mechanisms.”
There is also no stated consequence for non-compliance. The document says the task “must begin” by 1 January 1982 and gives no answer to “or else” — no approving authority, no waiver process, no exception path, no reviewer. The word must appears eight times in lower case (RFC 2119’s keyword convention was still sixteen years away), should twice. No budget, cost estimate or funding discussion appears anywhere.
The single occurrence of test is in an Appendix D status entry, where the HP-3000 implementation is “in its final testing stages.” RFC 801 specifies no test plan, dry run, pilot or acceptance criterion.
⚠️ The honest reading of that list is not “1981 was better at this.” RFC 801 could omit all of it because those things lived elsewhere: in DARPA’s authority over its own network, in a community of a few hundred hosts whose operators knew each other, and in running implementations that already existed. The absences describe an environment, not a template. What transfers is narrower — a plan that omits rollback because there is no rollback has been honest with its readers, and a plan that omits rollback because nobody asked has not.
The Documents Shipped With the Start Date
RFC 801’s “Documents” section is a bill of materials, naming by number the eight specifications an implementer needs — IP (RFC 791), ICMP (RFC 792), TCP (RFC 793), Telnet (RFC 764), FTP (RFC 765), SMTP (RFC 788), Name Server (IEN 116) and Assigned Numbers (RFC 790) — then committing to four supporting artifacts with a delivery month:
“These and associated documents are to be published in a notebook, and other information useful to implementers is to be gathered.”
The Internet Protocol Handbook, the Implementers Hints, the SDC IP/TCP specifications and an expanded host table were all scheduled for January 1982 — the month the work became mandatory. The documentation is not a follow-up item; it lands on the start line.
A readiness inventory written by the implementers, not by the planner
Appendix D is titled “IP/TCP Implementation Status” and carries thirteen entries — seven from BBN alone, plus COMSAT, DCEC, DTI’s VAX/VMS product, MIT Multics, SRI’s LSI-11 and UCLA’s IBM system. Each has a date, a named engineer and a working mailbox: Rob Gurwitz, Alan Sheltzer, Bob Hinden, Jack Sax, Jack Haverty, Charles Lynn. A site with a given machine could find whoever had already made it work on that machine.
That is the answer to “who has running code,” published inside the migration plan, per platform, with contact details — and bounded by its own honesty about shelf life:
“Please note that the information in this section may become quickly dated.”
followed by the canonical, continuously updated version’s location: a status file, <INTERNET-NOTEBOOK>TCP-IP-STATUS.TXT, on a named host. The document points at the live source rather than pretending to be it — the instinct that makes a good runbook link to a dashboard instead of pasting in a screenshot.
The Implementation Issues section is a known-defects list, written before the defects were yours. Under the heading “Shortcuts”:
“There are some very tempting shortcuts in the implementation of IP and TCP. DO NOT BE TEMPTED! Others have and they have been caught!”
Nine follow — the unverified IP header checksum, skipped fragment reassembly, static routing that ignores ICMP redirects, unprocessed options, the unverified TCP checksum, segments never reordered, no silly-window protection, useless error reporting. Every one is a bug somebody had already shipped, listed so the next implementer would not.
What the Record Will Not Tell You About the Day Itself
This article is about what RFC 801 specified. Be exact about the difference between that and what happened, because the second is much less well evidenced than the confident retellings suggest.
How it went is available only as participant self-assessment. The characterisation everyone quotes — that the transition “went surprisingly smoothly”, though it also “resulted in a distribution of buttons” carrying, in the source’s own quotation marks, “I survived the TCP/IP transition” — comes from A Brief History of the Internet, published 1997, fourteen years afterwards, by nine of the people responsible for it. That is a legitimate primary source for what the architects thought and the right kind of source for the button. It is not an independent operational assessment, and none was located for this article. Treat “surprisingly smoothly” as the verdict of the people who ran the migration, because that is what it is.
How many hosts were left behind is not established here. RFC 801 projects 250 hosts, all TCP-only, on 1 January 1983 — inside the digression its own author called speculative, written thirteen months early. The nearest independent counts come from RFC 1296, Internet Growth (1981-1991), Mark Lottor, SRI International, January 1992, built from archived SRI-NIC host tables:
| Date | Hosts | Source given in RFC 1296 |
|---|---|---|
| 08/81 | 213 | Host table #152 |
| 05/82 | 235 | Host table #166 |
| the flag day | no count published | — |
| 08/83 | 562 | Host table #300 |
| 10/84 | 1,024 | Host table #392 |
⚠️ Those two series do not measure the same population, and comparing them directly would be wrong. RFC 1296 counts “hosts with at least one IP address assigned”; RFC 801’s “Total hosts” column counts every ARPANET host, including NCP-only ones that by definition had no IP address. Before the cutover the two sets diverge structurally. Afterwards they converge — and 562 hosts in August 1983 against a projection of 250 for the previous January suggests the model’s growth assumption of fifty new hosts over the year was low. It licenses no claim about the state of the network on the day.
That mismatch is itself the transferable lesson: the projection you make before a migration and the telemetry you have after it frequently count different things. If the second will be used to grade the first, the definitions have to be agreed in advance. Here they were not.
1981 Against a Modern Migration Plan
Set what RFC 801 specified against what a database, API or auth migration plan is normally expected to contain today.
| Migration-plan element | In RFC 801 (Nov 1981) | Typical modern plan |
|---|---|---|
| Named cutover date | Yes, 1 January 1983 | Usually |
| Separate mandatory start date | Yes, 1 January 1982 — six weeks after publication | Rare; work begins when a team gets to it |
| Slack between “last migrated” and “old system off” | Yes, Nov 82 to Jan 83 | Rare; usually the same day |
| Compatibility layer, specified | Yes: Telnet, FTP and mail relay hosts | Usually |
| Worked user-visible procedure for that layer | Yes, Appendices A, B and C | Almost never |
| Capacity model for that layer | Yes, the N×M digression table | Almost never |
| Stated confidence in the model | Yes: “rather speculative!” | Almost never |
| Exact document list for implementers, with dates | Yes: 8 specs plus 4 artifacts, all Jan 82 | Sometimes |
| Per-platform readiness inventory with named contacts | Yes, Appendix D, 13 entries | Almost never |
| Pointer to the live status source | Yes, the TCP-IP-STATUS.TXT file | Sometimes |
| Known-defects list for implementers | Yes, the “Shortcuts” section, 9 items | Rare |
| Rollback or fallback plan | None | Expected |
| Test plan, pilot, acceptance criteria | None | Expected |
| Consequence for missing the date | None stated | Usually implied |
| Budget or cost estimate | None | Expected |
The interesting rows are not the ones where 1981 loses. They are the six where a forty-five-year-old RFC has something and the modern plan usually does not.
Six moves worth stealing
- Set the start date, not just the end date. A completion deadline with no mandatory start gets discovered in its last month.
- Put slack between “everyone has moved” and “the old thing is switched off.” Different events, different failure modes. Eight weeks cost the ARPANET nothing and bought it the ability to be wrong.
- Model the compatibility load, and publish the model. N×M is crude; it is also the difference between provisioning the bridge and hoping. Expect the peak mid-migration.
- Label the confidence of your own numbers, inside the plan. Postel’s “rather speculative!” costs one sentence and is worth more than a projection presented flat.
- Ship the reference material with the start date, and point at the live status source rather than embedding it.
- Publish the known-defects list before the defects are yours. The cheapest defect prevention there is, and it needs only that somebody write down what already went wrong.
None of that is out of reach for a modern team. It tends not to get written because a migration plan is usually authored as a schedule rather than as a document somebody has to implement from. RFC 801 was written for the second purpose, by someone who assumed his readers would be doing the work at three in the morning without him.
❓ Frequently Asked Questions
Was the 1983 TCP/IP flag day really a one-day event?
The cutover was; the transition was not. RFC 801 set a twelve-month mandatory window — begin by 1 January 1982, complete by 1 January 1983 — on a runway starting with the DoD’s January 1980 adoption of these protocols as a defense standard, with several years of community planning underneath that on the participants’ own account. Both hold at once: a long, well-signposted approach ending in a single hard date with no fallback.
Did RFC 801 have a rollback plan?
No. A full-text search returns zero occurrences of “rollback,” “fallback,” “revert,” “contingency,” “fail,” “risk” and “delay.” Returning to NCP is not contemplated for any host under any circumstance. The stated alternative for a host that missed the date was, in the architects’ own words, being “left having to communicate via rather ad-hoc mechanisms.”
What happened to hosts that were not ready on 1 January 1983?
RFC 801 does not say, and no consequence for non-compliance appears anywhere in it — no penalty, no waiver, no approving authority, no exception path. What it does specify is the transitional bridge: relay hosts running both stacks for Telnet, FTP and mail, with worked procedures in Appendices A, B and C. Those relays were scheduled to end at the cutover, along with NCP itself.
How many hosts were on the network when it happened?
No count for the flag day itself was published. RFC 801 projected 250, inside a section its author flagged as “rather speculative!” RFC 1296 records 235 IP hosts in May 1982 and 562 in August 1983 — a different population, since it counts only hosts with an IP address assigned. The honest answer is a range bracketed by two figures that were not measuring the same thing.
Why does RFC 801 write “IP/TCP” instead of “TCP/IP”?
Because the ordering had not settled. In RFC 801’s own prose “IP/TCP” appears thirteen times and “TCP/IP” zero times; every “TCP/IP” in the document sits in Appendix D, contributed by the implementers rather than by Postel. Nagle’s RFC 896 still used “IP/TCP” in its title in January 1984. The modern ordering was fixed by usage, later, not by anyone’s decision.
Is RFC 801 worth reading if I will never touch a network protocol?
That is the best reason to read it. Strip the protocol names out and what remains is a compact, complete migration plan for a system with an installed base, a hard deadline, no rollback, and implementers who do not report to the author. The compatibility-load digression alone is worth the twenty minutes.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, this site earns a small commission at no extra cost to you.
On this subject the free primary material is not a substitute for a book — it is better than one, and it is shorter.
Read RFC 801 itself. It is twenty-one pages and it is the whole article. Twenty minutes, free, plain text, no paywall and no summary in between. Read it in this order: the Discussion section for why the relay hosts exist, the Milestones table for the two-month gap between the last conversion and the switch-off, then “A Digression on the Numbers” — the N×M capacity model for the compatibility layer, complete with the author’s own “Please note that this digression is rather speculative!” Then skim Appendices A, B and C, which are the user-visible procedures for the bridge, and Appendix D, which is a readiness inventory with thirteen platforms and named engineers. If you only ever read one RFC in your career for reasons unrelated to networking, read this one.
For the runway underneath the mandate, RFC 760 and RFC 761 — “DOD STANDARD INTERNET PROTOCOL” and “DOD STANDARD TRANSMISSION CONTROL PROTOCOL”, both January 1980. You need only the title pages. They establish the three-year gap between “this is now the standard” and “the old thing is switched off,” which is the part that gets compressed out of every retelling.
For the numbers around the event, RFC 1296, Internet Growth (1981-1991), Mark Lottor, SRI International, January 1992. Section N.1 is the host-count series built from archived SRI-NIC host tables, and Lottor documents his own collection caveats in the same document — the correct model for publishing a measurement you know is imperfect.
For what the people who ran it said afterwards, the Internet Society’s A Brief History of the Internet, by Leiner, Cerf, Clark, Kahn, Kleinrock, Lynch, Postel, Roberts and Wolff. It is free, it is short, and it is the source of both the “flag-day” framing and the buttons. Read it as what it is: nine participants assessing their own work fourteen years later.
Two books, if you want the long form
- Where Wizards Stay Up Late: The Origins of the Internet — Hafner and Lyon, Simon & Schuster. The narrative history of how the ARPANET got built and who was in the room. It is institutional texture rather than migration mechanics, and it is the right companion to RFC 801 for exactly that reason.
- TCP/IP Illustrated, Volume 1: The Protocols, 2nd edition — Fall and Stevens, Addison-Wesley. Not history at all: the reference for what the protocol that survived the cutover actually does on the wire today. Useful here as the other end of the same story.
One book is named without a link, because its print edition could not be identity-confirmed for this article and a link that resolves is not the same as a link to the book you claimed:
- Inventing the Internet — Janet Abbate, MIT Press, 1999. The academic history of the ARPANET’s institutional decisions, including the transition period. ⚠️ ASIN UNVERIFIED