IPv4 Exhaustion is Real: My Strategy for IPv6 Dual Stacking

We’ve been hearing about “IPv4 exhaustion” for decades. For most engineers, it was a distant boogeyman—something that would happen eventually. But when I was working at Net4, an ISP handling critical infrastructure, eventually became today.

We literally hit the wall. We ran out of allocatable IPv4 blocks.

This wasn’t a theoretical exercise; it was an operational crisis. We couldn’t provision new subnets for customers because the RIR (Regional Internet Registry) pool was dry. The only way forward was to implement IPv6 across the entire Data Center.

Here is the deep dive into how we architected that transition, specifically focusing on the Dual Stack strategy.

Phase 1: The Upstream Handshake (BGP)

The first step in any ISP-level migration is talking to the world. We had to establish IPv6 BGP peering with our upstream providers.

If you are used to advertising /24s in IPv4, the scale of IPv6 takes a moment to adjust to. We were now advertising /32 and /48 prefixes. The configuration on our edge routers shifted from standard neighbor x.x.x.x remote-as to configuring IPv6 address families.

The complexity here isn’t the syntax; it’s the routing policies. You have to ensure your AS-PATH filtering and prefix lists are just as rigorous for v6 as they are for v4. You do not want to accidentally become a transit AS for global IPv6 traffic just because you misconfigured a route-map.

Phase 2: The Security Paradigm Shift (The NAT Trap)

This is where most organizations fail.

In the IPv4 world, we got lazy. We treated NAT (Network Address Translation) as a security feature. We assumed that because an internal server was on a private RFC1918 address (like 192.168.x.x), it was “safe” from the public internet.

IPv6 kills that assumption.

IPv6 was designed to restore end-to-end connectivity. There is no NAT. If you assign a Global Unicast Address (GUA) to a server, it is reachable from anywhere on the planet unless you explicitly stop it.

We had to rigorously audit our edge security on our Juniper and Cisco gear.

Stateless ACLs: We updated our perimeter Access Control Lists to drop all incoming IPv6 traffic that wasn’t established from the inside, effectively mimicking the stateful protection we were used to.
ICMPv6: You cannot block ICMPv6 entirely (like we often did with IPv4 ICMP) because IPv6 relies on it for Neighbor Discovery (ND) and Path MTU Discovery. Blocking it breaks the protocol. We had to fine-tune our filters to allow essential ICMPv6 types while blocking the rest.

Phase 3: The Dual Stack Architecture

We couldn’t just flip a switch to IPv6. Legacy applications, old kernels, and hard-coded IP addresses in customer code meant IPv4 had to stay.

We chose a Dual Stack architecture.

In a Dual Stack environment, every networking device, server, and switch interface is configured with both an IPv4 and an IPv6 address. They operate as two ships in the night—independent protocols running over the same physical wire.

DNS Resolution: We updated our DNS infrastructure to return both A records (IPv4) and AAAA records (IPv6). Modern OSs employ an algorithm (Happy Eyeballs) to try IPv6 first and fall back to IPv4 seamlessly.
Throughput: Interestingly, we noticed that for some direct peering links, IPv6 throughput was marginally better because it eliminated the CPU overhead of NAT processing on the firewalls.

The Takeaway

The transition wasn’t painless. But it taught me a valuable lesson: Don’t fear the hex code.

The internet is huge, but the 32-bit address space of IPv4 (4.3 billion addresses) is mathematically insufficient for a hyper-connected world. IPv6 gives us 340 undecillion addresses.

If you are still holding onto IPv4 because “it works,” you are building technical debt. The exhaustion is real. The only way out is through the hex.