If the Internet Had Started With IPv6, We Might Not Have the Internet We Know

Suppose we return to 1978. ARPANET was still young, and TCP/IP had not become the standard that would reshape computing. Vint Cerf and Bob Kahn sat at a table covered with scratch paper, preparing to draw the foundation of the future Internet.

Consider a different choice. What if they had written 128-bit addresses instead of 32-bit addresses? What if they had chosen today’s IPv6 header, with its fixed 40 bytes, flow labels, mandatory security architecture, and room for a huge number of devices? The Internet would look very different.

The design would probably have died in review. It was too advanced for the hardware, economics, and engineering culture of the 1970s. IPv6 belongs to the 1990s, after the Internet had already proved it would grow without limit. Putting it into the 1970s is like putting a jet engine on a bicycle. The engine is fine. The bicycle cannot carry it.

War inside 64 KB of memory

A 1970s machine room looked nothing like a modern data center. A PDP-11 might have 64 KB of memory. CPUs ran at a few MHz or less. A router was a general-purpose computer forwarding packets in software.

Address length was not an abstract design choice. It decided cost, speed, and survival.

An IPv4 address is 32 bits. A routing table entry takes a few dozen bytes. An IPv6 address is 128 bits, four times longer. If an early routing table had ten thousand entries, IPv4 might need a few hundred KB of memory. IPv6 would need several MB. A few MB is nothing today. In 1978 it was a fortune. Lookup was worse. Every packet required longest prefix matching. A 32-bit lookup was already hard. A 128-bit lookup multiplied the work. The CPUs of the time could not do it at line rate.

Vint Cerf later recalled that variable-length addresses were considered and rejected. Computers were too expensive. Nobody wanted routers doing complex calculations. If variable-length addresses were too costly, fixed 128-bit addresses had no chance.

Bandwidth was another wall. Early ARPANET links ran at 56 kbps. IPv6’s fixed header is 40 bytes. IPv4’s basic header is 20 bytes. IPv6 removed the checksum and simplified some router work. In an era when bandwidth cost more than gold, every header byte mattered. IPv6 was simpler for 1990s routers. For 1970s machines, it was still heavy.

The avalanche of the routing table

IPv6 says every grain of sand can have an address. It does not say how to find that address. A large address space is easy. Being routable, aggregatable, and manageable is hard.

In practice, IPv6 uses the first 64 bits for subnet routing and the last 64 bits for interface identification. Even then, the routable space is 2^64, which is 2^32 times larger than IPv4’s 2^32. If IPv6 had started in the 1970s without IANA and the RIRs, early institutions would have grabbed large blocks. Every university would take a /48. Every company would take a /32. Every project would take a /40. Addresses would be plentiful. The routing table would explode.

Today the global IPv4 routing table has passed one million entries. The IPv6 routing table is around 300,000. IPv6 usage is still far smaller than IPv4, and allocation is relatively orderly. If IPv6 had been in place since the 1970s, the Internet’s growth through the 1980s and 1990s could have pushed the routing table into the tens of millions. Routers could not have kept up. BGP did not appear until 1989. If a massive routing table had arrived earlier, the protocol might have collapsed. The Internet might have split into islands.

Route aggregation would also have suffered. IPv4’s CIDR works because 32-bit space is limited. Address blocks can be grouped. A 128-bit space is too large. If allocation were messy, aggregation boundaries would blur. Routers would carry many fine-grained routes. Performance would suffer further.

The ghost of OSI

IPv6 is more than longer addresses. It is a full design: fixed header, extension headers, flow labels, mandatory IPSec, neighbor discovery, stateless autoconfiguration, multicast, anycast. These features made sense in the 1990s. By then the Internet was huge, and security, mobility, and autoconfiguration had become urgent. In the 1970s, most of them were excess.

Mandatory IPSec needs public-key cryptography. In the 1970s, public-key cryptography was just beginning. Diffie-Hellman appeared in 1976. RSA appeared in 1977. A mandatory security architecture across the entire Internet was technically immature and politically unrealistic. Cerf admitted that public-key cryptography was left out. He did not want to redo the work later. Security grew later. It could not be designed in from the start.

Neighbor discovery and stateless autoconfiguration need multicast. Early multicast was immature and complex. Flow labels and QoS had no use case. Many IPv6 features looked like overdesign in the 1970s. If the IETF’s predecessor had received such a proposal, it would have demanded cuts. Remove IPSec. Remove flow labels. Shorten addresses. Keep the checksum. Reduce extension headers. The result might have been IPv4.5, not today’s IPv6.

The more likely outcome is that TCP/IP would not have won. An overly complex TCP/IP would have made OSI look practical. It would have given X.25, DECnet, and other protocols more room. The Internet might have become more centralized, more expensive, and slower. The open, free, end-to-end Internet we know might never have appeared.

If it had been forced into deployment

Suppose the IPv6-style design had been forced through in the 1970s and deployed by some miracle. The world would look different.

Early Internet expansion would have slowed. Only governments, large corporations, and wealthy universities could afford it. Small research labs, hobbyists, and the later PC revolution would have been locked out. Democratization would have been delayed.

NAT might never have appeared. NAT came from address shortage and extended IPv4’s life. With infinite addresses, NAT would be unnecessary. Devices would sit directly on the public Internet. Firewalls and perimeter security would have become important earlier. Early security was immature. More incidents could have slowed commercialization.

The routing table would have become a nightmare. Without NAT’s address reuse, every device would need a globally unique address. Routing entries would grow with device count. If today’s Internet of Things had been built on early IPv6, the routing table might already exceed any router’s capacity. The Internet might have adopted a more hierarchical, centralized routing architecture, sacrificing the end-to-end principle.

Many IPv6 advantages, such as autoconfiguration, mobility, and end-to-end connectivity, could not have run on early hardware. It would have been IPv4 with very long addresses, carrying a heavy header and complex processing. The benefits would have been small. The costs would have been high.

The temptation of variable-length addresses

If we could travel back, the realistic plan would be to design a variable-length address protocol. Start with 32 bits. Extend it as hardware improves. That preserves room for growth without crushing early routers.

History shows that variable-length addresses were also hard to implement. Cerf recalled that they were rejected because of processing overhead. The more likely path is the one that happened: keep 32 bits, hit address shortage in the 1990s, invent CIDR and NAT, then design IPv6 in the late 1990s.

IPv4’s flaw, addresses that were too small, produced a series of innovations: CIDR, NAT, private addresses, DHCP, BGP aggregation, and the IPv4 address market. These patches let IPv4 live for more than forty years. It is still running. They are not elegant. They are evolution at work. The Internet was not designed. It grew.

300,000 and 1,000,000

Today the IPv6 routing table has about 300,000 entries. The IPv4 routing table has about 1,000,000. NAT still works. CIDR still aggregates. BGP still converges. IPv4’s address space ran out long ago. The Internet did not die. It uses patches, markets, and engineering skill to squeeze the last drop from 32-bit addresses.

IPv6 is the right answer today. It solves address exhaustion. It supports the Internet of Things, mobile networks, and cloud computing. It belongs to the era after the 1990s, to a world of abundant hardware, widespread fiber, and security as a basic need. Take it back to the 1970s, and it looks overdesigned, complex, and impractical.

IPv4 succeeded because it made the right compromise at the right time. It traded 32-bit addresses for low cost, high performance, and easy implementation. It traded the end-to-end principle for unlimited application innovation. It traded later CIDR and NAT for decades of life. It danced in chains and still danced out the entire Internet age.

If we could travel back, the best strategy would be to tell Cerf and Kahn: make the simplest thing that runs. Patch it when addresses run short. The patches will be ugly. The Internet will survive.

History has no ifs. This thought experiment shows that technology is a contest of timing, constraints, and ecology. IPv6 is tomorrow’s answer. IPv4 is yesterday’s answer. The Internet’s greatness lies in letting yesterday’s answer live into tomorrow and repair itself along the way.

Back to that table

In the 1978 meeting room, someone proposed 128-bit addresses. Cerf did not laugh. He wrote the idea down and continued discussing the 32-bit proposal. He knew that someday people would need a larger address space. He also knew that today the protocol had to run.

There was no IPv6 on that table. There were scratch paper, pencils, and an Internet that had just begun to breathe.