What the ARPANET Transition Teaches Us About IPv6

ARPANET (Advanced Research Projects Agency Network) was one of the first computer networks to use packet switching and is considered one of the main precursors to the Internet. Created by ARPA in the United States, the network initially connected universities and research centers, and over the years, ended up linking hundreds of computers. It was in this context that the need arose to replace the Network Control Program (NCP) used for communication between ARPANET hosts, with the Transmission Control Protocol/Internet Protocol (TCP/IP) suite, developed to enable interconnection between different networks. This transition would become a milestone in the development of the modern Internet.

In 1981, ARPANET faced a challenge that might seem familiar to those who work in networking: it would be necessary to replace the protocol that supported communication between its hosts with a new interconnection architecture. NCP used up until then would be replaced by TCP/IP. The difference is that, back then, someone had the idea—which today might seem bold or even controversial—to set a date for this to happen.

In October 1981, Jon Postel published a message in the TCP/IP Digestthat presented the deadline directly, as shown in Figure 1.

Figure 1. The deadline is: 1January 1983. Source: Jon Postel, NCP-to-TCP Transition, TCP/IP Digest, Vol. 1, Issue 2, 14 Oct. 1981. Reproduction available in the LivingInternet historical archive. [1]

Published in November 1981, RFC 801 [2] formalized the transition plan. It was not simply a matter of recommending that administrators begin implementing TCP/IP. Each organization had to prepare its own hosts. The plan included intermediate stages scheduled for 1982, mechanisms to allow coexistence between NCP and TCP/IP. At the end of the process, NCP would be eliminated. These mechanisms included hosts supporting both protocols and services for Telnet, FTP, and email between NCP-only and TCP-only systems. According to the plan, in January 1983 all hosts were expected to be ready for TCP/IP, NCP was to be taken out of service, and the temporary mechanisms would no longer be needed.

This is interesting to note today, as we have been talking about IPv6 for many years, almost always using the word “transition.” What happened in 1983 was also a transition, but there was a fundamental difference: it was planned as a migration with a start date, preparatory phases, and a deadline for completion.

A Migration Requires a Date

Perhaps the first lesson is precisely this: a migration requires a date that marks the moment when the new system becomes the standard and the old one ceases to be the primary option.

This does not mean that all equipment needs to be updated at the same time. In the case of ARPANET, development, implementation, testing, and periods of operation took place in parallel. Throughout 1982, the community conducted experiments in which NCP was temporarily shut down, including longer tests during which NCP packets were rejected. This was a way to discover problems in advance while simultaneously showing administrators that the shutdown scheduled for January was not merely a recommendation.

By December, the sense that the date was fast approaching is clearly evident in historical records. On 30 December, Nancy Mimno sent a notice, shown in Figure 2, to CSNET’s institutional contacts, explaining that the transition had been in preparation for several years and that the switch to TCP/IP would take place on 1^st January. According to the message, the change would affect more than 250 ARPANET hosts, some of which might not be ready by the established date.

Figure 2. Message sent by Nancy Mimno on 30 December 1982, announcing the ARPANET transition to TCP/IP on 1^st January 1983. Source: MIMNO (1982), electronic message preserved in the Anne and Lynn Wheeler historical collection. [3]

The following day, 31^st December, while millions of people were likely preparing to celebrate the New Year, some administrators were worried about something else. At 11:11 PM, Ken Wertz from Carnegie Mellon sent a message titled “TCP reminder”, shown in Figure 3, reminding everyone that the ARPANET would begin using TCP/IP exclusively at 12:01 AM the next day and recommending that administrators verify the configuration settings of their university systems.

Figure 3. Message sent by Ken Wertz at 11:11 PM on December 31, 1982, reminding everyone that ARPANET would begin using TCP/IP exclusively on 1st January 1983 at 12:01 AM. Source: CMU CS General Bboard archive. [4]

The date existed because it was necessary to turn an intention into a collective commitment. Perhaps this is one of the things we lose when a transition drags on indefinitely: the perception that, at some point, it must come to an end.

Responsibility

A date alone does not make a migration happen. The second aspect that stands out in documents from that era is the clarity about who was supposed to do what. RFC 801 assigned each organization the responsibility of implementing TCP/IP on its own hosts.

This distinguishes ARPANET from the current Internet. ARPANET had a defined administrative structure and was subject to coordination by ARPA and the DCA. On the global Internet, no single organization has the authority to set a specific date for shutting down IPv4.

In an account reproduced in Figure 4, Andrew G. Malis shared that he participated in implementing the code that allowed blocking NCP packets, and that this mechanism was applied on a host-by-host basis, even taking into account an official list of hosts authorized to continue using NCP. He spent the first day of 1983 turning off NCP for unapproved hosts and answering calls from administrators whose systems had lost connectivity.

Figure 4. Andrew G. Malis’s account of the NCP to TCP transition on 1^st January 1983. Malis describes the application of filters and his role in the operation. Source: Internet-history mailing list, 5 December 2020. [5]

In an interview with the Computer History Museum [6], Dan Lynch also recalled this moment as the “big cutover,” with many professionals working around the time of the switch to ensure the change happened. Perhaps this is precisely what turns a technical decision into an actual migration: professionals who not only believed that the change was necessary but also took responsibility for its execution.

When we look at IPv6, this issue remains the same. It is relatively easy to say that an organization is deploying IPv6. The real challenge is identifying who is responsible for ensuring that a specific network, service, or application stops relying on IPv4. Without clear accountability, the transition tends to remain a collective goal lacking the defined leadership needed to drive it to completion.

Managing Exceptions Without Abandoning the Main Goal

There is another detail of the story that I consider particularly important. Not everyone was ready. Documents make it clear that not all hosts had completed the migration and that some problems were to be expected. This is why exceptions and transition mechanisms were contemplated. Subsequent documentation shows that some hosts received temporary authorization to continue using NCP after the shutdown. Therefore, 1^st January 1983 should be understood as the effective start of TCP/IP-only operation as the standard, rather than the moment when the use of NCP disappeared without exception.

This shows that a planned migration does not mean demanding perfection before moving forward. It means recognizing that some situations will not be ready and creating mechanisms to address them without abandoning the main objective. This distinction is important. An exception may be necessary. The problem arises when the exception is no longer time-limited and comes to be viewed as a permanent part of the architecture.

This is something we know very well in the world of IPv6. Legacy equipment exists that still requires IPv4. Old applications exist that do not work on IPv6. An operating system exists that cannot be updated. IoT devices exist for which the manufacturer has not yet implemented IPv6. Each case may be legitimate and, in many environments, temporarily maintaining IPv4 is simply the right operational decision. But we must be careful to ensure that these cases do not become a justification for maintaining IPv4 everywhere.

Perhaps the question should not be “When will everyone be ready for IPv6? because we may never know the answer to that. A better question would be “Which systems actually still need IPv4, and at which points in the infrastructure does it need to remain?”

From then on, exceptions could be handled individually, rather than serving as a justification for keeping the entire infrastructure stuck in the past. That was precisely the ability that the ARPANET community demonstrated. There were exceptions, but they did not prevent the migration.

The Decision to Abandon NCP

We have reached what is perhaps the most difficult step: being willing to leave behind protocols that have become part of the network’s legacy.

In this sense, mechanisms such as NAT64, DNS64, 464XLAT, and SIIT-DC can play a role similar to the intermediate services of that earlier transition: allowing access to legacy resources without requiring the previous protocol to remain native across the entire infrastructure.

The ARPANET transition did not end simply because the majority of hosts were already using TCP/IP. The plan anticipated that NCP would no longer be used and, under the established migration framework, NCP traffic from hosts lacking an approved exception would be rejected.

This required a decision that is often difficult in production environments: accepting that, from a certain point on, the protocol that had sustained the network for years would no longer be admitted as a standard method of access.

Vint Cerf later recalled that the community had already temporarily shut down NCP during testing precisely to demonstrate that the migration would be taken seriously. When January 1983 arrived, access via the old protocol was effectively discontinued, with few exceptions.

Dan Lynch also became known for the “I Survived the TCP Transition” badge shown in Figure 5, of which he produced 500 at his own expense to mark the occasion. But what had actually occurred was far more significant: the community had demonstrated a collective ability to decide that a transition needed to end.

Figure 5. “I Survived the TCP Transition 1/1/83” badge produced by Dan Lynch as a memento of ARPANET’s transition to TCP/IP. Source: Computer History Museum, interview with Dan Lynch.

What Can We Learn from This?

We have now been talking about the transition to IPv6 for decades. There is a significant difference between how we are handling IPv6 adoption today and how the ARPANET community approached the transition to TCP/IP.

Back then, the goal was not to maintain both protocols indefinitely. NCP and TCP/IP had to coexist for a time because their coexistence was necessary to complete the migration. This does not mean that all prolonged coexistence between protocols is necessarily inappropriate. The difference lies in whether it addresses a measurable need or it persists simply because of a lack of planning to phase it out.

Today, we often turn coexistence into a permanent state. I do not believe the lesson is simply to set a date to shut down IPv4 across the entire Internet, even though controlled shutdowns are sometimes proposed—even provocatively—to measure the current level of IPv4 dependency, much like the tests conducted prior to 1983.

ARPANET had a few hundred hosts and had an administrative coordination capable of setting and enforcing a deadline. Today’s Internet brings together countless autonomous systems, operators, manufacturers, applications, and users, with no central authority capable of mandating a global IPv4 shutdown. The question of when we will shut down IPv4 might trigger resistance before we even begin.

Perhaps a more useful question is: What is the next environment where we can set a date to stop relying on IPv4?

It might be a new Wi-Fi network, a new VLAN, a new data center, an IoT infrastructure, or an application that is IPv6-only or IPv6-mostly by design and only uses translation to access resources that still rely on IPv4.

For each environment, the goal could be accompanied by simple metrics: the number of applications still requiring IPv4, the volume of remaining IPv4 traffic, the existence of individuals responsible for exceptions, the review timeline, and the percentage of services capable of operating exclusively over IPv6.

Ultimately, this is the story I think is worth telling, even in classrooms. Not just out of nostalgia or an interest in Internet history, nor as an attempt to claim that today’s Internet could be managed like the ARPANET of 1983, but because that experience presents an uncomfortable question that remains relevant today.

One question remains, however: if an entire community managed to set a date to leave NCP behind, what is still preventing us from defining goals and deadlines to reduce our reliance on IPv4 in the environments we manage?

References

[1] LIVINGINTERNET. TCP/IP Internet Protocol. [n.p.], [n.d.]. Available at: https://www.livinginternet.com/i/ii_tcpip.htm. Accessed: 8 September 2026.

[2] POSTEL, Jon. RFC 801: NCP/TCP Transition Plan. [n.p.]: Internet Engineering Task Force, November 1981. Available at: https://www.rfc-editor.org/info/rfc801. Accessed: 8 September 2026.

[3] MIMNO, Nancy. Notice of TCP/IP Transition on ARPANET. Email sent to the CSNET-LIAISONS list on 30 December 1982. Reproduction preserved in the Anne and Lynn Wheeler historical collection. Available at: https://web.archive.org/web/20230928072135/https://www.garlic.com/~lynn/2000e.html#18. Accessed: 8 September 2026.

[4] WERTZ, Ken. TCP reminder. Message posted to the CMU CS General Bboard on 31 December 1982. In: BAIRD, Jeff. CMU CS General Bboard Contents from 25-Nov-82 to 31-Dec-82. [n.p.], 15 July 2002. Available at: https://self-issued.info/Smiley/Nov-Dec-82_BBoard_Contents.html. Accessed: 8 September 2026.

[5] MALIS, Andrew G. Account of the NCP/TCP transition on ARPANET. Email dated 5 December 2020, reproduced in a discussion on the Internet-history mailing list. In: AUERBACH, Karl. Fwd: Question – reference source for formal decommissioning of ARPANET in 1990? Internet History Society, 6 December 2020. Available at: https://elists.isoc.org/pipermail/internet-history/2020-December/006780.html. Accessed: 8 September 2026.

[6] LYNCH, Dan. Interview of Dan Lynch. Interview given to James Pelkey ​​on 16 February 1988, Cupertino, California. Mountain View: Computer History Museum, 2016. Available at: https://archive.computerhistory.org/resources/access/text/2016/02/102717120-05-01-acc.pdf. Accessed: 8 September 2026.