Avery Pennarun wrote a post in 2017 with a deceptively simple premise: the world in which IPv6 would have been a good design is a world that no longer existed by the time IPv6 was standardized. It resurfaced on Hacker News recently, and the discussion is worth reading alongside the original, because nearly a decade later the core observation has only become more pointed.
IPv6 was designed in the early 1990s, standardized in RFC 2460 in December 1998, and it made one enormous bet: that the internet was fundamentally a network of peers, that every device would have a globally routable address, and that the end-to-end principle was inviolable. The problem is that by the time RFC 2460 was published, RFC 1631 had already existed for four years. NAT was already everywhere. The bet had already lost.
What IPv6 Actually Delivered
IPv6 expanded the address space from 32 bits to 128 bits. That is its core value proposition. Everything else is secondary or marginal.
The simplified header format (no checksum, no fragmentation in transit, fixed-length base header) is a real improvement, but it mostly benefits router hardware designers rather than application developers. Stateless Address Autoconfiguration (SLAAC, defined in RFC 4862) eliminated the need for DHCP in many cases, which is useful but not transformative. Mandatory IPsec was the flagship security feature, but it became optional in RFC 6434 in 2011, quietly dissolving the one claim that IPv6 provided meaningful security improvements.
None of these changes address the actual problems that had emerged in the decade between IPv4’s deployment and IPv6’s design work.
The Problems That Went Unsolved
Identity versus location. In IPv4 and IPv6 alike, your IP address serves double duty: it identifies who you are and it tells routers where to send packets. This conflation is the root cause of several intractable problems. When you move between networks, your address changes, and TCP connections break. When you connect to multiple ISPs simultaneously (multihoming), routing policy conflicts make it difficult to use both paths coherently. When you want to authenticate a peer, an IP address is a poor identifier because it can change, be spoofed, or be shared by multiple hosts behind NAT.
The Host Identity Protocol (HIP, RFC 4423, 2006) proposed separating these concerns. A host would have a cryptographic Host Identity, derived from a public key, and a separate Locator that described its current network position. The protocol could map between them. Your TCP connections would survive network changes because they were bound to your identity, not your address. HIP was technically sound and is still referenced in research contexts, but it required changes at every endpoint and offered no transition path, so it went nowhere outside of specialized deployments.
LISP (Locator/ID Separation Protocol) took a different approach, pushing the identity/locator separation into the routing infrastructure rather than the endpoints. It has seen limited deployment in some enterprise and carrier contexts but has never become a general internet mechanism.
IPv6 could have incorporated either approach. It did not.
NAT traversal. The internet in 2026 is not a network of peers with globally routable addresses. It is a network in which most devices sit behind one or more layers of NAT. Mobile carriers run Carrier-Grade NAT (CGNAT, RFC 6888), placing millions of customers behind shared IPv4 addresses. Home routers add another NAT layer. Corporate networks add another. A device trying to accept an inbound connection must either use a relay server, punch holes through UDP, or convince every NAT device in the path to maintain a mapping.
This is the problem that STUN (RFC 5389), TURN (RFC 5766), and ICE (RFC 8445) exist to solve. WebRTC depends on them. Every peer-to-peer protocol built in the last fifteen years has had to re-implement variants of these mechanisms. The protocol stack has grown a tumor of NAT traversal machinery because the network layer never addressed the problem.
IPv6 restores globally routable addresses and in principle eliminates NAT. In practice, many IPv6 deployments still sit behind stateful firewalls that block inbound connections, reproducing NAT semantics without the address translation. And the transition has been so slow that application developers cannot assume IPv6 connectivity, so they implement NAT traversal anyway.
Mobility. Mobile IPv6 (RFC 6275) exists and specifies how a mobile node can maintain a stable Home Address while roaming. It requires a Home Agent infrastructure, adds latency through triangle routing, and has seen essentially zero deployment outside of academic papers. Mobile devices handle mobility through the application layer: TCP connections break when you switch from WiFi to cellular, and applications reconnect. QUIC (RFC 9000) improves this slightly with connection migration, but it is a workaround rather than a solution.
The Transition Disaster
The practical story of IPv6 deployment is a lesson in what happens when a protocol requires universal adoption to provide value. IPv4 and IPv6 are not compatible at the network layer. A host that only speaks IPv6 cannot communicate with a host that only speaks IPv4, full stop.
The transition mechanisms designed to bridge this gap became a graveyard of half-measures. 6to4 (RFC 3056) encapsulated IPv6 in IPv4, but relied on anycast relay infrastructure that was often slow or broken. Teredo (RFC 4380) tunneled IPv6 over UDP through NAT, producing some of the worst network performance characteristics ever shipped in a default OS configuration. Windows Vista and 7 enabled Teredo by default, leading to mysterious latency spikes that network administrators traced back to IPv6 traffic taking bizarre paths through Microsoft’s relay servers.
Microsoft, Google, and Apple eventually coordinated to disable these automatic tunneling mechanisms by default, recognizing that broken IPv6 connectivity was worse than no IPv6 connectivity. The Happy Eyeballs algorithm (RFC 8305) was developed to let applications race IPv4 and IPv6 connections and use whichever succeeds first, which is a reasonable engineering response to the situation but represents significant complexity added purely to compensate for unreliable IPv6 infrastructure.
As of early 2026, Google’s IPv6 statistics show roughly 45% of their users reaching Google over IPv6. That number has climbed steadily for a decade. The US, Germany, India, and several other countries have high adoption rates, largely driven by mobile carriers assigning IPv6 addresses to avoid CGNAT costs. The remaining 55% will take years more, and a non-trivial fraction of networks will likely never migrate.
What Could Have Been
Pennarun’s argument is a counterfactual, and counterfactuals in protocol design are always speculative, but the shape of the missed opportunity is visible in what later systems were forced to build independently.
WireGuard is a VPN protocol that cryptographically identifies peers using public keys and handles NAT traversal, key exchange, and encrypted tunneling in roughly 4,000 lines of code. Tailscale builds a mesh network on top of WireGuard, assigning stable addresses (in the 100.64.0.0/10 CGNAT range, ironically) to every device and handling NAT traversal automatically. The result is something close to what the early internet actually felt like: every device has an address, every device can reach every other device directly.
Tailscale’s founding team, which includes Pennarun, built exactly the network that IPv6 promised and failed to deliver. They built it at the application layer, on top of the broken infrastructure, because waiting for the network layer to fix itself was not a viable strategy.
If IPv6’s designers had prioritized identity/locator separation, mandatory NAT traversal, and cryptographic host authentication over address space expansion and header simplification, the protocol might have provided a foundation that application developers could actually rely on. Instead, it solved a problem (address exhaustion) that NAT had already worked around in practice, while leaving the problems that NAT created entirely unaddressed.
The 128-bit address space is real. 2^128 addresses is enough for every atom on Earth’s surface to have its own IP address many times over, and that is not a problem anyone will complain about. But address space was the least interesting thing the IETF could have redesigned when it had the opportunity to rethink the network layer from scratch.
Why It Still Matters
Protocol design decisions made in the 1990s are still constraining what engineers can build in 2026. Every application that wants peer-to-peer connectivity must implement its own NAT traversal. Every mobile application that wants connection continuity across network changes must implement its own reconnection logic. Every system that wants to authenticate a remote peer by something more stable than an IP address must build its own identity layer.
These are not unsolvable problems; they have been solved, repeatedly, at layers above the network. But solving them at every application layer separately is expensive, error-prone, and produces a fragmented ecosystem where each solution has slightly different semantics.
The window to redesign the internet’s addressing layer is closed. IPv6 is what we have, and it will slowly displace IPv4 over the next decade. The interesting work is happening in the overlay layer, with protocols like WireGuard and QUIC providing the properties that the network layer never delivered. Pennarun’s post is worth reading not as a grievance but as a precise diagnosis of why that overlay layer had to exist at all.