Skip to content

IPv4 exhaustion and IPv6 benefits

IP addressing already gave the headline number: IPv4's 32 bits allow for a little over 4.3 billion addresses, and that space is now fully allocated. Not "running low" — allocated. Every regional registry that hands out address blocks to ISPs and large organizations has already given out everything it had. What this article covers is what that actually means in practice, since the internet obviously hasn't stopped working, and why the fix that's been available for over two decades still isn't the default everywhere.

The exhaustion timeline, region by region

IPv4 addresses are allocated by five Regional Internet Registries (RIRs), each responsible for a different part of the world — ARIN for North America, RIPE NCC for Europe and parts of Central Asia, APNIC for Asia-Pacific, and so on. Each one drew from its own share of the global pool independently, which is why exhaustion didn't happen everywhere at once:

  • APNIC reached its final /8 block of IPv4 addresses first, on 15 April 2011, triggering the region's strictest allocation-rationing policy — a consequence of the Asia-Pacific region's explosive growth in internet-connected devices during the 2000s.
  • RIPE NCC reached its last available /8 block in September 2012, at which point its policy shifted to a final, one-time /22 allocation per member — and by November 2019, even that reduced allocation had run out entirely.
  • ARIN, covering North America, issued the last addresses in its free pool on 24 September 2015.

Once an RIR's free pool is gone, it doesn't simply stop functioning — a waiting list takes over, fed only by addresses the registry recovers: blocks returned voluntarily, revoked for policy violations, or reclaimed from organizations that no longer exist. RIPE NCC's post-exhaustion policy limits new allocations to organizations that have never received an IPv4 block before, and caps that allocation at a single /24 — 256 addresses, a small fraction of what a growing organization might actually need. The gap between what's available through official channels and what the internet's continued growth actually demands is filled today largely by a transfer market, where organizations holding more address space than they use sell blocks to organizations that need them, at prices that have risen substantially as availability has tightened.

Why the internet didn't grind to a halt

If addresses ran out years ago, the obvious question is how billions of new devices have connected since. The honest answer is a set of workarounds, not a real fix — techniques that stretch the existing address space further rather than creating new addresses:

  • NAT, covered at the mechanism level in the device-level NAT article and at the planning level in this module's own NAT article, lets an entire household or office share a single public address across every device inside it. Without NAT, exhaustion would have been catastrophic years earlier; with it, one address does the work that would otherwise require dozens.
  • CGNAT, already introduced in the device-level NAT article, pushes the same trick up a level — an ISP shares one public address across many customers, each of whom is themselves already sharing that shared address across their own household's devices through their own router's NAT. It's NAT stacked on NAT, and it works, at the cost of breaking anything that assumes a customer genuinely holds their own unique public address, including plain port forwarding, as that article's CGNAT section already covered.
  • The transfer market redistributes existing allocations from organizations with more than they use to organizations that need more, without creating a single new address.

Every one of these buys time. None of them adds addresses to a space that is fundamentally, permanently full. That's the ceiling IPv6 exists to remove entirely rather than work around.

What 128 bits actually buys beyond "more addresses"

IP addressing already covered IPv6's address format and the eye-watering scale of 2¹²⁸ possible addresses. What's worth adding here is that the address space itself is only part of why IPv6 matters — several of its design decisions solve problems that have nothing to do with running out of numbers:

  • No more NAT as a structural requirement. With enough addresses for every device to hold a genuinely unique, globally routable one, the entire reason NAT exists — sharing scarcity — disappears. A device with a real IPv6 address doesn't need port forwarding, hole punching, or STUN/TURN relays just to receive an unsolicited inbound connection; it's directly reachable, subject to whatever firewall policy is actually intended, rather than an accidental one that falls out of address scarcity.
  • A simplified, fixed-size header. IPv6's header design deliberately dropped fields IPv4 carried for decades — including the header checksum, since every layer above and below IP already checksums its own data, making IP's own checksum redundant work every router had to repeat on every single packet. A router forwarding IPv6 traffic does measurably less per-packet processing than one forwarding IPv4, a real efficiency gain at internet scale.
  • Built-in support for multicast and anycast, replacing IPv4's broadcast entirely — covered briefly in IP addressing and given full treatment later in this course, in the module on advanced topics.
  • Simplified address autoconfiguration. An IPv6 device can construct its own valid address from the network's advertised prefix and its own interface identifier without necessarily needing a DHCP exchange at all — a lighter-weight alternative to the full DHCP lease process this module already walked through in detail for IPv4.

Why adoption has been slow despite two decades of availability

IPv6 was standardized in 1998. Measured adoption — the share of traffic and users actually reaching services over IPv6 rather than IPv4 — has grown steadily for over a decade and now represents a substantial and still-rising portion of global internet traffic, though the pace and current share vary considerably by country and network operator; Google's own long-running IPv6 adoption statistics track this trend continuously and are worth checking directly for current figures rather than relying on any number quoted here, since the trend keeps moving.

The slowness has a straightforward cause: IPv4 and IPv6 don't interoperate directly. A device with only an IPv4 address cannot open a connection to a device with only an IPv6 address without something in between translating — there's no equivalent of NAT that bridges the two protocols transparently for arbitrary traffic the way NAT bridges private and public IPv4. This module's NAT article already covered NAT64 and DNS64, the specific translation mechanism that makes an IPv6-only network able to reach the still-substantial IPv4-only portion of the internet — and the fact that a purpose-built translation layer is necessary at all is itself evidence of how deep the incompatibility runs.

That incompatibility is why the practical migration path for most networks isn't a hard cutover but dual stack — a device or network running both protocols simultaneously, using whichever one the destination actually supports — which IP addressing already named as the dominant real-world deployment model. Dual stack avoids the interoperability cliff entirely, at the cost of every network needing to maintain and secure two parallel addressing and routing configurations indefinitely, rather than one — a real, ongoing operational cost that's a large part of why the full transition has taken this long and remains incomplete even now.

Practical scenario: a new cloud deployment that can't reach a legacy partner API

A team provisions a new set of application servers in an IPv6-only cloud subnet — increasingly the default for new deployments, since it sidesteps IPv4 address planning and cost entirely. Everything works during testing against modern, dual-stack services. Once connected to a long-standing partner company's API, every request fails to even establish a connection.

dig partner-api.example.com AAAA

;; ANSWER SECTION:
;; (no records returned)

The partner's API has no AAAA record at all — it's reachable only over IPv4, which many long-established backend systems still are, since migrating a stable, working system carries real risk for a benefit that's mostly external. An IPv6-only server has no IPv4 stack to fall back to and, without help, simply cannot open a connection to an address family it doesn't speak.

The fix is exactly the mechanism this module's NAT article already worked through: a NAT64 gateway and DNS64 resolver in front of the IPv6-only subnet, synthesizing an IPv6-reachable address for the IPv4-only partner API and translating the actual traffic at the gateway. From the application's point of view, nothing changes — it still just resolves a name and connects — but the translation layer is now doing the work of bridging two address families that otherwise have no way to reach each other directly.

Practice exercises

  1. Explain, in one or two sentences, why NAT and CGNAT count as workarounds for IPv4 exhaustion rather than solutions to it.
  2. A network engineer says "we're dual stack, so IPv6 adoption doesn't matter to us yet." Explain what operational cost they're still paying by running dual stack indefinitely, even if every one of their own services already works over both protocols.
  3. Using the scenario above as a model, explain why an IPv6-only network reaching an IPv4-only destination needs NAT64/DNS64, while two ordinary IPv4 networks reaching each other across the public internet need no translation layer at all.

This module has now covered the full set of services that make a private network usable end to end and connected to the wider internet: resolving names, leasing addresses, sharing one public address across many devices, reaching in through that address deliberately, tunneling privately across an untrusted network, distributing content close to its audience, prioritizing traffic that can't tolerate delay, and the address space constraint underlying several of those services at once. None of it, so far, has asked who's allowed to do any of this, or how to stop someone from doing it maliciously. That's a later module's entire subject. First, though, there's a gap between understanding why IPv6 exists and being able to work on a server that has it — where the surprises have almost nothing to do with the size of the address space.

Sources