The last free pools of IPv4 ran dry years ago; what remains is a secondary market where addresses lease and trade at prices that show up in your unit economics. Every new NAT layer you deploy to stretch the pool adds state, fragility, and debugging cost. IPv6 is no longer a protocol purity argument — it is the cheaper, simpler path for any network you expect to still be growing in five years, and mobile carriers plus major CDNs already deliver a large share of consumer traffic over it.
Yet most enterprise backends remain IPv4-only islands behind load balancers, because rollouts stall on fear of the unknown rather than on actual blockers. The playbook below is what has worked for us: dual-stack at the edge first, IPv6-only where it pays, and instrumentation before either.
Decide the target architecture before touching routers
There are three credible end states, and mixing them accidentally is what causes the pain:
- ▸Dual-stack everywhere: every host carries both address families. Simple to reason about, never breaks legacy dependencies, but doubles parts of your operational surface — two firewall policies, two monitoring views.
- ▸IPv6-only inside, translated at the edge: hosts speak only IPv6; NAT64 with DNS64 (RFC 6146 and RFC 6147) handles the shrinking set of IPv4-only destinations. This is what large mobile networks run and it halves address management — but every internal tool must genuinely work without IPv4.
- ▸Dual-stack edge, IPv4 core: the honest first milestone for most companies. Publish AAAA records for public services, terminate IPv6 at the load balancer, keep the interior unchanged while you learn.
Pick one target, write it down, and stage toward it. Ambiguity here is why rollouts die.
The classic pitfalls, named
- ▸Broken AAAA is worse than no AAAA: publish an AAAA record for a service whose v6 path is misconfigured and clients using Happy Eyeballs (RFC 8305) will mostly recover, but older stacks and misbehaving middleboxes will hang. Test the v6 path from outside your network before publishing.
- ▸Firewall parity drift: the v6 ruleset must be generated from the same source of truth as v4. Hand-maintained parallel rulesets diverge within a quarter, and the divergence is usually an open port.
- ▸SLAAC versus DHCPv6 confusion: servers want stable, auditable addressing — static assignment or DHCPv6 — while SLAAC with privacy extensions suits clients. Mixing models on one segment without a decision breaks address-based inventory and logging.
- ▸Path MTU discovery: IPv6 routers do not fragment. If your network filters ICMPv6 Packet Too Big messages, large responses blackhole silently. ICMPv6 is not optional; RFC 4890 describes exactly what to permit.
- ▸Observability gaps: flow logs, GeoIP enrichment, WAF rules, and rate limiters must reason about /64 and /48 prefixes, not single addresses. Per-IP rate limiting that treats each v6 address separately is trivially bypassed.
A phased rollout that ships
1. Instrument first: add address-family labels to traffic dashboards so v6 adoption and error rates are visible separately from day one. 2. Obtain address space and an addressing plan: a /48 per site, a /64 per segment, and no clever subnetting narrower than /64. 3. Enable dual-stack on the public edge — DNS, CDN, load balancers — and publish AAAA for one low-risk service. 4. Watch error budgets for two weeks; expand to all public services once v6 error rates match v4. 5. Move internal shared services — resolvers, package mirrors, logging — to dual-stack, generating both firewall policies from one source. 6. Pilot an IPv6-only segment (CI runners are ideal) with NAT64 and DNS64 at its border, and fix what breaks. 7. Make v6 the default for new deployments and treat v4 as the legacy exception with an owner and a review date.
What it buys you beyond addresses
Flat, NAT-free addressing simplifies things people rarely credit to IPv6: direct peer-to-peer paths for real-time media, cleaner abuse attribution, and an end to the port-exhaustion incidents that plague large NAT gateways. Overlapping RFC 1918 space is one of the most common integration headaches after a merger or acquisition; v6 makes it structurally impossible. Service meshes, VPN overlays, and multi-tenant platforms all get simpler when every endpoint has a globally unique address and policy does the isolating.
The business case is straightforward: IPv4 scarcity is now a recurring cost — leased addresses, NAT appliances, engineer hours lost in state tables — while IPv6 capability is a one-time investment that compounds. Public procurement frameworks and large enterprise customers increasingly ask for it in questionnaires. Treat the rollout as a two-quarter infrastructure project with named phases and error-budget gates, and you convert an open-ended fear into a finished line item — one that quietly removes a whole class of future incidents and costs from your roadmap.