Why IPv6 Adoption Has Stalled (and Why IPv4 Won't Die Anytime Soon)

Networking & Firewalls
1

This comes up often enough that I’m putting it in one place to point people to.

The short version

IPv6 hasn’t replaced IPv4 because it never gave the people who’d have to deploy it a reason they couldn’t ignore. The whole point of IPv6 was to solve IPv4 address exhaustion. But the industry already solved exhaustion well enough with NAT and a few server-side tricks, so the urgency that was supposed to force the switch just never materialized.

The core argument

Geoff Huston, Chief Scientist at APNIC and probably the most-cited researcher on IPv4 exhaustion, lays this out well in his 2024 piece The IPv6 transition. His central point: IPv6 is essentially “IPv4 with bigger addresses.” It isn’t faster, it isn’t more versatile, and it isn’t more secure. Its one real benefit is relief from address exhaustion, and that’s a future risk the market heavily discounts.

The pressure got absorbed from both ends of a connection, and it’s worth seeing both, because people tend to only think about one.

On the client side, NAT made IPv4 stretch far past its expected life. Huston notes the Internet is now sharing each IPv4 address across an average of about seven devices, and it all just works. Every home with a router is doing this already. Carriers took the same idea further with Carrier-Grade NAT (CGNAT), sharing a single public IPv4 address across many subscribers, which let mobile and broadband providers keep onboarding customers long after the free address pool dried up.

The Serial Port YouTube Channel has great video covering the history of the PIX and being first widely successful product to include NAT.

On the server side, the rescue came from TLS Server Name Indication (SNI). Before SNI, hosting multiple HTTPS sites generally meant one IP per site, because the server had to pick a certificate before it knew which site the client wanted. SNI fixed that by having the client announce the hostname it’s after during the TLS handshake, so a single IP can front a large number of separate sites and the server picks the right cert and service by name. That quietly killed one of the biggest remaining reasons a host needed lots of public IPs. As an example, GRC runs more than a dozen web services off a single IP this way, with DNS pointing all those names at the one address.

So between NAT and CGNAT soaking up client-side demand and SNI soaking up server-side demand, the address crunch that was supposed to force everyone onto IPv6 got managed instead. That’s the whole reason the urgency evaporated.

The result is what I’d call adoption by attrition. Huston’s data shows that more than a decade after IPv4 ran out, only about a third of users could reach an IPv6-only service as of 2024, and at the trend rate the transition wouldn’t finish until somewhere around 2045.

The objections worth knowing about

This isn’t a settled debate, and if you cite Huston, expect pushback. The fair counterpoints:

NAT is breaking down at scale. The Internet Society points out that large ISPs running Carrier-Grade NAT are finding even the biggest private IPv4 block of 16.7 million addresses isn’t enough, so they’re stacking multiple layers of CGN, which creates real performance and management problems. They also note NAT forces routers to rewrite packets, which adds a performance hit and breaks protocols that embed IP literals instead of domain names. See the Internet Society IPv6 FAQ. So “works well enough” is getting shakier for the carriers actually carrying the load.

Eliminating NAT is itself a benefit. ARIN frames IPv6 as more than address count: no NAT, a globally unique address per device, stateless address autoconfiguration (SLAAC), and simplified headers that cut administrative overhead. See ARIN’s writeup. Restoring true end-to-end connectivity matters for peer-to-peer, VoIP, gaming, and IoT, all of which NAT complicates.

The “stalled” numbers are higher than they sound. Per Google’s data reported by Network World, global IPv6 adoption was around 43% as of December 2024, with the U.S. near 49%, and mobile and carrier networks leading the way. DigiCert’s 2025 overview agrees with the diagnosis (no urgency while IPv4 still works) but argues dual-stack is a poor long-term answer and that government mandates are slowly raising the pressure.

One caveat on sourcing: ARIN is a regional registry and DigiCert sells managed DNS, so both have a stake in promoting the transition, the same way you could argue Huston writes from an RIR’s vantage point too. Weigh accordingly.

Bottom line

The disagreement is mostly about framing, not facts. Everyone agrees NAT is the reason IPv4 is still standing and that adoption has been slow. The split is whether that’s a stable equilibrium (Huston’s “works well enough”) or a problem we’ve deferred whose costs are quietly piling up at the carrier level. IPv4 isn’t dying on a schedule. It’s dying by attrition, if it dies at all.

Sources

If you want the long version, Steve Gibson covered Huston’s article in detail on Security Now #998, “The Endless Journey to IPv6” (Oct 29, 2024). Show notes: https://www.grc.com/sn/SN-998-Notes.pdf

4 Likes
We Fixed IPv4 Too Well for IPv6 to Win. [YouTube Release]
2

And yet, I still can’t get a direct ipv6 address from T-Mobile for my system. Nat upon Nat upon nat, when all these addresses should be available to us.

3 Likes
3

I feel you. I’ve been called back a few times to troubleshoot why Hulu Live won’t work on the new network I installed. I usually find out they left cable/fiber for T-mobile 5G.

4

The random egress is a real problem for these stupid services!

5

The slow adoption of IPv6 really resulted in a mess. There are obvious advantages to IPv6 (simpler routing, no NAT, no masquerading, end to end connectivity, …). But since we have so many holdouts that don’t support IPv6 on the service side (e. g. GitHub), we’re currently sadly stuck in this weird middle ground.

Some networks only support IPv4, some have dual stack, and some only support IPv6 with NAT64, DNS64 and 464XLAT (more on this later).

While IPv4 only is probably the easiest out of the three, I would personally say it is just turning a blind eye towards IPv6, which can be a real solution to many problems, and I wouldn’t consider it best practice to not support it. (In fact, I would consider it makes you part of the problem!)

Dual stack solves this, but now you have to manage two networks, often independently, which can get very messy very fast.

Another solution that I almost don’t hear people discuss is IPv6 only with NAT64, DNS64 and (optionally) 464XLAT. You get all the benefits of IPv6 (no NAT, no subnet masks, no overlapping subnets, no masquerading, …) and only have to manage one network. Only the router running NAT64 needs an IPv4 address.

Any domain with only A records get translated to AAAA records by DNS64. This handles basically all connectivity that runs through DNS.

And any service / app that still relies on IPv4 literals (common examples being legacy VPNs, WebRTC connections with users in IPv4 only networks, Discord and some Steam services) can get translated on the device itself with 464XLAT. Apple and Android added support for 464XLAT years ago, Windows recently added support, and on Linux Clatd and NetworkManager (since 1.57) support it.

Edit: Apalrd’s Adventures has some awesome videos and writeups on IPv6 Mostly / Only, NAT64, DNS64 and 464XLAT.

1 Like
6

While NAT works in western countries, who were early in the game and have snatched the majority of addresses, many other countries who are currently still adopting the internet will probably be forced to adopt IPv6 (only) networks.

Looking at this table, there countries like Bangladesh that have just 12 addresses for every 1000 humans living there.

As these countries develop and more and more people get their first phones and internet connections, I can’t imagine NAT being able to keep up (in theory, you can masquerade up to 65k connections behind a single IPv4 address with NAT, but this amount of efficiency is not reasonable in practice).

And developed countries are usually not willing to give up their unused supply of IPv4, and when it happens, usually at very high prices. The current waiting list for reused IPv4 at RIPE is over 530 days long, and pricing for a single /24 subnet is going into the tens of thousands of dollars.

(Interestingly, this has resulted in many educational institutions to sit on a small goldmine, as they often do not need many addresses but were often assigned a /16 subnet during the IPv4 development).

Tl;dr while NAT and IPv4 currently work in western countries, where IPv4 is “plentiful” (1-10 devices per address), it probably won’t work in countries currently building up their network infrastructure (100-1000 devices per address, once developed).

2 Likes