IPv6 was designed in 1994 to solve address exhaustion. Thirty years later, global adoption sits at 43-45%. HTTP/2 was standardized in May 2015 to make pages load faster. Five years later, approximately 50% of home pages used it. Same internet, same organizations, radically different timelines.

Temporary Solutions Become Permanent

In 2011, IANA officially ran out of free IPv4 addresses. The crisis everyone predicted had arrived. Except it hadn't, because Network Address Translation already solved the problem "good enough."

NAT lets organizations use private IP addresses internally while sharing limited public addresses. A hack, a temporary workaround that was never meant to be permanent infrastructure. But it worked. Organizations that thought they'd run out of addresses discovered they could function fine with NAT. The urgency evaporated.

Successful workarounds create path dependency. As long as IPv4 "works" via NAT, organizations delay expensive upgrades. The temporary solution becomes infrastructure that lasts decades because the pain of staying put dropped to nearly zero while the cost of moving stayed high.

All-or-Nothing Transitions

IPv6 can't talk to IPv4 directly. An IPv6 device and an IPv4 device need something in between: dual-stack networks, tunneling, translation mechanisms. Organizations face a choice. Maintain both protocols simultaneously, doubling infrastructure complexity. Or stay on IPv4 until they can flip entirely, deferring benefits indefinitely. Neither option is appealing when the old system works fine.

HTTP/2 maintained HTTP semantics—no changes to methods, status codes, or URIs. A browser supporting HTTP/2 could still talk to HTTP/1.1 servers. The transition could happen incrementally, one connection at a time, without requiring coordinated infrastructure replacement. Organizations could upgrade when convenient rather than coordinating a flag day.

Third Parties Accelerate

Over 40% of sites have no first-party HTTP/2 requests at all, but "even the lowest 5% of pages have 30% of third-party content served over HTTP/2." CDNs, ad networks, analytics providers adopted HTTP/2 and served content over the new protocol regardless of whether the first-party site had upgraded.

Major platforms make the switch, protocol transitions happen faster than organizational decision cycles. Google, Cloudflare, Akamai upgrade their infrastructure, and suddenly millions of sites benefit without doing anything. The protocol spreads through the ecosystem rather than requiring site-by-site migration. IPv6 lacks this shortcut. You can't serve IPv6 content to IPv4 clients through a third-party intermediary. The transition requires infrastructure changes at every layer.

Building Fresh vs. Upgrading

India's IPv6 adoption sits at 74%, higher than the United States at 46-50%. Reliance Jio deployed IPv6 to 450 million mobile subscribers using a mobile-first strategy that bypassed legacy IPv4 infrastructure. Building new networks, you can leapfrog old decisions. Maintaining infrastructure that works, the switching costs span technical, organizational, human, and economic dimensions. Training engineers who've spent careers working with IPv4. Maintaining dual-stack networks during transition. Debugging compatibility issues that only surface in production.

What Drives Replacement

HTTP/2 made pages load faster, something users noticed immediately. IPv6 solved address exhaustion, something NAT had already addressed "good enough" for most organizations. HTTP/2 maintained backward compatibility. IPv6 required dual infrastructure or complete replacement. HTTP/2 reached 50% adoption in five years. IPv6 is still climbing toward 50% after thirty years.

Protocols stick when workarounds function well enough, switching costs run high enough, and benefits remain abstract enough that organizations can justify waiting. Protocols get replaced quickly when benefits arrive immediately, compatibility stays intact, and third parties can accelerate adoption without requiring organizational decisions.

Thirty years from now, we'll probably still be running some IPv4 somewhere. The workaround became permanent infrastructure. Infrastructure evolves this way when the old solution works well enough and the new solution requires everyone to move at once.