IPv6: The Design That Never Had a Chance

The story of IPv6 is one of missed opportunities and technical compromises that reveal much about how network protocols evolve in practice. What began as an elegant solution to address exhaustion has become a complex overlay on an already messy foundation. To understand why IPv6 never delivered on its original promise, we must examine the historical context of network development and the fundamental design assumptions that proved incompatible with reality.

The Network Evolution That IPv6 Failed to Account For

Network development began with telephone networks using physical circuit switching, where each call established a dedicated end-to-end connection. This evolved into time-division multiplexing and virtual circuit switching, allowing multiple connections to share physical infrastructure.

The Internet Protocol emerged as a way to connect these circuits together, introducing the concept of IP addresses and routing. Meanwhile, local area networks (LANs) developed separately with their own addressing schemes. Early LAN technologies like ARCnet used simple 8-bit addresses manually configured by network administrators, while later Ethernet introduced 48-bit MAC addresses assigned at manufacturing time.

When organizations needed to connect multiple LAN segments, they faced a fundamental choice: extend their LAN protocols or adopt IP. The LAN protocols won initially because they were hardware-optimized and fast, leading to the development of bridging and switching technologies that operated at layer 2.

The IPv6 Vision

When IPv6 was designed in the 1990s, its creators envisioned a clean slate where the accumulated complexity of networking could be eliminated. Their idealized world included:

• No more physical bus networks (already obsolete)
• No more layer 2 internetworks
• No more broadcasts (replaced with multicast)
• No more MAC addresses
• No more ARP and DHCP
• Simplified IP headers for hardware acceleration
• Abundant address space eliminating the need for NAT

In this vision, devices like WiFi access points and Ethernet switches would simply become IPv6 routers, eliminating the need for layer 2 bridging. The increased header size in IPv6 (128-bit addresses vs 32-bit) was justified by the elimination of 12 bytes of Ethernet addressing in every packet.

Why the Vision Never Materialized

The fundamental problem, as apenwarr explains, is that "layers are only ever added, never removed." Even with IPv6 adoption, we remain stuck with legacy systems:

1. Persistent IPv4: IPv6 deployment never reached 100%, meaning dual-stack networks became the norm, not the exception.

2. Persistent MAC addresses: Despite the vision of eliminating layer 2, we still need 48-bit MAC addresses for Ethernet and WiFi frames. The IEEE 802.3 and 802.11 framing standards remain entrenched.

3. ARP-like protocols: IPv6 still requires Neighbor Discovery, which functions essentially as a more complex version of ARP.

4. DHCP persistence: We still need DHCP servers to manage IP address assignment for legacy devices.

5. NAT persistence: NAT remains necessary for IPv4 compatibility and for conserving address space in certain contexts.

The Mobile IP Problem

Perhaps the most significant oversight in IPv6 design was the failure to adequately solve the mobile IP problem. The original designers planned to address mobility after IPv6 deployment, assuming it would be simpler once legacy systems were eliminated.

In reality, mobile devices became ubiquitous before IPv6 achieved widespread adoption. Current solutions rely heavily on layer 2 bridging:

• Corporate WiFi networks bridge their entire LAN to maintain consistent IP addresses
• Home WiFi systems with multiple extenders use similar bridging techniques
• LTE networks tunnel traffic back to a central location, creating a massive virtual layer 2 LAN

These solutions work but introduce significant complexity and latency. The fundamental issue is that IP routing cannot handle mobility—if a device changes its IP address, all existing connections are broken.

A Potential Technical Solution

The root cause of the mobility problem lies in how TCP and UDP identify sessions using the 4-tuple (source IP, source port, destination IP, destination port). This approach ties session identification to layer 3 addressing, making mobility problematic.

A better approach would be to identify sessions using only layer 4 data with much larger port numbers (128-256 bits). In this model:

• Devices would send packets tagged with a UUID rather than relying on IP addresses for session identification
• The kernel would use only the UUID to determine which socket receives the packet
• When a device moves to a new network, it continues using the same UUID
• The receiving device would update its cache to associate the UUID with the new IP address

This approach could work with QUIC, which already uses unique session identifiers for encryption and authentication. The experimental QUIC protocol has the right packet structure to support transparent roaming.

Lessons for Future Protocol Design

The IPv6 experience offers several important lessons:

1. Backward compatibility matters: New protocols must account for existing infrastructure rather than assuming a clean slate.

2. Layer separation has limits: While clean layer separation is theoretically desirable, practical implementations often violate layer boundaries for efficiency.

3. Incremental change beats revolution: Complete overhauls of fundamental protocols face insurmountable adoption challenges.

4. Future-proofing is difficult: It's nearly impossible to anticipate all future use cases, especially those enabled by emerging technologies.

The IPv6 story demonstrates that even well-designed protocols can fail to deliver on their promises when they don't account for the messy reality of deployed systems and evolving use cases. While IPv6 did solve the address shortage problem, it failed to simplify network infrastructure as originally envisioned.

For more technical details on network design and protocol evolution, you might find these resources helpful:

• The original article by apenwarr
• QUIC protocol documentation for understanding modern transport protocols
• IEEE 802.11 standards for WiFi protocol details