IPv6 at Enterprise Scale: A Migration Playbook

by

Ask a network architect why they’re finally doing an enterprise IPv6 migration and “we’re running out of IPv4 addresses” is almost never the honest answer. Nobody sitting in a data center cares about the global IPv4 free pool — that argument was settled a decade ago and either way it was never their problem. The trigger that actually shows up on a change ticket is that 10.0.0.0/8 is spoken for twice inside the same routing domain, or that this quarter’s GPU cluster can’t get a subnet large enough for its back-end fabric without carving into a block someone else already owns.

This is the playbook I reach for when RFC1918 space has actually run out — not in theory, in the IPAM tool — usually after a run of acquisitions, a few years of multi-cluster Kubernetes sprawl, and a GPU buildout that eats subnets faster than anyone budgeted for. I’m assuming you already know IPv6 basics: SLAAC, the address format, that /64 is the standard subnet size. What follows is about sequencing a migration a large organization can survive, not another argument for why IPv6 is good for you.

Why Enterprise IPv6 Migration Stops Being Optional

RFC1918 was never sized for GPU fabrics. A single GPU node in a modern training or inference cluster carries multiple NICs for the compute fabric, plus a separate management/BMC network, plus a storage network. One rack of eight GPU servers can burn a few hundred addresses before a workload ever runs. Multiply that across dozens of racks and several clusters — training, inference, staging, DR — and you’re allocating subnets by the thousand. Private space handles that arithmetic fine in isolation. It stops working the moment every business unit, region, and cluster is drawing from the same finite 10.0.0.0/8.

Kubernetes multiplies the allocation problem instead of solving it. Every cluster wants its own pod CIDR and service CIDR, and the easy default — carve out a /16 per cluster — burns through address space you can’t easily reclaim once workloads are scheduled against it. Cross-cluster service mesh or federation needs those CIDRs to be globally unique, or NAT’d at every cluster boundary. A platform team running fifty-plus clusters across regions runs out of non-overlapping /16s inside a /8 far sooner than the raw host count would suggest.

Mergers and acquisitions guarantee overlap, not exhaustion. Two companies have almost certainly both standardized on 10.0.0.0/8, or the same handful of common /12 and /16 blocks, entirely independently. Day one of any integration starts with subnet collisions, not free space. The standard fix — 1:1 NAT or a renumbering project — is expensive either way: hundreds of manual mapping entries, monitoring and alerting that now has to key off the NAT’d address instead of the real one, and one missed mapping entry causes packet loss nobody can explain from the logs alone.

NAT and overlapping-CIDR VPNs are a standing tax, not a one-time cost. Every site-to-site tunnel between two overlapping networks needs static NAT or a policy-routing workaround to disambiguate traffic. Every new acquisition or partner integration adds another set of translation rules to a table that’s already hard to reason about. A packet capture during an incident needs a NAT lookup before anyone can even identify which host originated the traffic. This is the part that never makes it into the original NAT decision: it doesn’t cost you once, it costs your on-call rotation every single day you keep running it.

Reference Architecture: Dual-Stack Core, IPv6-Only Islands, and NAT64/DNS64 at the Edge

The target I aim for, phased over twelve to twenty-four months depending on estate size, looks like this: a dual-stack core and WAN backbone that everything still routes through, new capacity built as IPv6-only islands from day one, and a NAT64/DNS64 gateway sitting at the boundary so those islands can still reach the IPv4-only world that isn’t going anywhere soon.

flowchart TB
    subgraph Legacy["Legacy IPv4-Only Estate"]
        L1[App Servers - 10.x.x.x]
        L2[Databases - 10.x.x.x]
    end

    subgraph Core["Dual-Stack Core / WAN Backbone"]
        R1[Core Router - Region AMER]
        R2[Core Router - Region EMEA]
        DNS[DNS64 Resolver]
        NAT[NAT64 Gateway]
    end

    subgraph Island1["IPv6-Only Island: GPU Training Fabric"]
        GPU1[GPU Nodes - IPv6-only fabric]
        K8S1[K8s Cluster - IPv6-only pod/service CIDR]
    end

    subgraph Island2["IPv6-Only Island: New Regional Site"]
        K8S2[K8s Cluster - IPv6-only]
        APP2[New Applications - IPv6-only]
    end

    GPU1 --> R1
    K8S1 --> R1
    K8S2 --> R2
    APP2 --> R2
    R1 <-->|iBGP/IGP| R2
    R1 --- L1
    R1 --- L2

    K8S1 -->|resolve legacy-db.internal| DNS
    DNS -->|synthesize AAAA via 64:ff9b::/96| K8S1
    K8S1 -->|traffic to synthesized address| NAT
    NAT -->|stateful translation to real IPv4| L1

ASCII fallback:

                       Dual-Stack Core / WAN Backbone
                Region AMER                        Region EMEA
              Core Router A  <------ iBGP/IGP ------>  Core Router B
                |         |                                |
          DNS64/NAT64     |                                |
           Gateway        |                                |
              |           |                                |
     +--------+           |                                +--------+
     |                    |                                         |
Legacy IPv4-only    IPv6-only Island:                     IPv6-only Island:
App/DB servers       GPU Training Fabric                   New Regional Site
  (10.x.x.x)      (k8s IPv6-only pod/svc CIDR,          (k8s IPv6-only CIDR,
                    IPv6-only fabric NICs)                 new applications)

IPv6-only pod resolves "legacy-db.internal" -> DNS64 synthesizes an AAAA
record inside 64:ff9b::/96 -> traffic routed to the NAT64 gateway -> NAT64
does stateful translation back to the real IPv4 destination -> reaches the
legacy server, which never has to know IPv6 exists.

The address plan underneath that topology is the part people underinvest in, and it’s the part that actually determines whether the migration is boring or miserable two years in. Flat is the enemy — assign a /48 or /56 per site with a fixed hierarchy and you can summarize routes at every level and delegate blocks to regional teams without a spreadsheet fight every quarter.

Layer Prefix Example Notes
Enterprise allocation /32 2001:db8::/32 One block from your RIR (or provider PA space if you’re not running your own ASN yet) — sub-allocate internally, don’t request more than one
Region /36 2001:db8:1000::/36 (AMER), 2001:db8:2000::/36 (EMEA) 4 bits per region = 16 regions with room to spare
Site / data center /48 2001:db8:1210::/48 (us-east-dc2) Roughly the guidance in RFC 6177; a small branch office doesn’t need a full /48 — I use /56 there and save /48s for real DCs and campuses
Segment / VLAN / pod CIDR /64 2001:db8:1210:a3::/64 One per L2 segment, or the block a Kubernetes cluster carves per-node pod ranges out of
Router point-to-point link /127 2001:db8:1210:ffff::1/127 Per RFC 6164 — don’t burn a /64 on a two-node link
Loopback /128 2001:db8:1210:ffff::1/128 Router ID, anycast source

For the Kubernetes piece specifically, dual-stack has to be declared at the cluster level before it shows up at the Service level — you can’t retrofit it onto a running cluster’s pod network without a CIDR migration, so get this right at cluster build time:

# kubeadm ClusterConfiguration fragment - dual-stack cluster networking.
# This is what actually gets you dual-stack pods and services, not just
# a dual-stack NIC on the node.
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
  podSubnet: "10.244.0.0/16,2001:db8:1210:a300::/56"
  serviceSubnet: "10.96.0.0/12,2001:db8:1210:a3ff::/108"
---
apiVersion: v1
kind: Service
metadata:
  name: inference-api
spec:
  ipFamilyPolicy: PreferDualStack
  ipFamilies:
    - IPv6
    - IPv4
  selector:
    app: inference-api
  ports:
    - port: 443
      targetPort: 8443

The order in ipFamilies isn’t cosmetic — the first entry becomes the primary family and gets .spec.clusterIP, which matters for anything that only reads that one field instead of clusterIPs. And confirm your CNI and cloud load-balancer integration actually support dual-stack before you flip this in production; Calico and Cilium do, but plenty of managed load-balancer controllers still only provision a v4 frontend even when the Service behind it is dual-stack.

For the IPv6-only islands, DNS64 and NAT64 are the seam that lets them reach anything that hasn’t moved yet:

# BIND9 dns64 clause - synthesizes AAAA records for IPv4-only legacy
# hosts, so an IPv6-only client gets a routable address instead of NXDOMAIN
dns64 64:ff9b::/96 {
    clients { ipv6-only-islands; };
    mapped { !10.0.0.0/8; any; };
    exclude { 64:ff9b::/96; ::ffff:0:0/96; };
};

# Jool NAT64 instance (syntax varies by version - illustrative) - translates
# 64:ff9b::/96 traffic back to a real routable IPv4 address at the edge
jool instance add nat64-edge --netfilter --pool6 64:ff9b::/96
jool -i nat64-edge global update pool4 --tcp --add 203.0.113.50/32

Neither of these is meant to be permanent architecture. Treat NAT64/DNS64 as a transition device with a removal date attached to each legacy service it’s covering, not as a place to build new dependencies.

Decision Criteria: Dual-Stack vs. IPv6-Only + NAT64/DNS64 vs. IPv6-Mostly

Criteria Dual-Stack Everywhere IPv6-Only + NAT64/DNS64 IPv6-Mostly (Dual-Stack Edge, IPv6-Only Core)
App/library compatibility Highest — every legacy IPv4-only app and library keeps working untouched Lowest — anything with a hardcoded IPv4 literal or a v4-only library breaks until fixed Good — legacy stays dual-stack at the edge; only new/internal services need to be v6-clean
Address-exhaustion relief Minimal short-term — every host still consumes RFC1918 space on its v4 side Complete — new fabric and clusters never touch private v4 space again Strong — the growth that was actually eating your address space (new clusters, new GPU fabric) stops doing so
Operational complexity (running two stacks) Highest, indefinitely — every ACL, monitoring rule, and runbook exists twice, forever Lower once cut over — one internal stack, NAT64/DNS64 is one well-understood edge component Moderate — complexity concentrated at the edge boundary instead of spread through the whole estate
Security parity effort High but at least symmetric — one policy engine usually covers both families equally High and asymmetric — the v6-only interior is simpler to secure, but the NAT64 gateway becomes a chokepoint that needs its own hardening and logging Moderate — the edge needs full dual-stack parity; the core only needs v6
Rollout risk Low per-step, high cumulative cost — safe, but you never actually finish Highest per-step — a broken v6-only cutover has no v4 fallback Balanced — new builds carry the risk, legacy is untouched until its own retirement
Best fit Orgs early in migration, or with a hard requirement that specific legacy IPv4-only integrations keep working indefinitely Greenfield GPU fabrics and new Kubernetes clusters where you control every workload going in Most large enterprises mid-migration — new capacity built v6-only, legacy kept dual-stack until it’s decommissioned on its own schedule

If I had to compress this into one line for a steering committee: don’t run dual-stack forever, and don’t flag-day your way into IPv6-only either. Build new capacity as IPv6-only from day one, keep legacy dual-stack until it’s decommissioned anyway, and let NAT64/DNS64 be the seam between the two — a transition device with a removal date, not a permanent piece of the architecture.

Pitfalls and What I’d Do in Production

Don’t flag-day it, and don’t let “eventually” pass for a plan either. Flipping a whole estate to dual-stack or IPv6-only in one maintenance window guarantees you discover every broken assumption at the same time, usually at 2am. What I’d do: sequence by blast radius — greenfield workloads first, since they carry no legacy baggage, then internal east-west traffic between teams who can coordinate fixes together, then anything client-facing or regulated last, with a hard decommission date on the old path so dual-stack doesn’t quietly become permanent.

Hardcoded IPv4 literals and v4-only libraries don’t announce themselves until traffic actually hits them. A config file with a literal dotted-quad, a monitoring agent that only opens v4 sockets, a vendor appliance whose management API has no v6 support at all — none of this surfaces in a design review. It surfaces in production, as a silent timeout from a v6-only pod. What I’d do: grep every config repo for IPv4 literals before cutover, and — more useful than any static scan — actually run each candidate service in an IPv6-only test namespace before anyone calls it “IPv6 ready.” A code review can’t catch what a real socket call will.

Security tooling parity lags the network layer, and that gap is the actual risk, not a paperwork gap. Firewalls, IDS/IPS signatures, NetFlow/sFlow collectors, and SIEM parsers were tuned against years of v4 traffic and get bolted-on v6 support nobody has stress-tested. An ACL that’s airtight on v4 and default-permit on v6 because someone forgot to mirror the rule is an exploitable hole, not a theoretical one. What I’d do: audit every control on the path — firewall, ACL, IDS, flow logging — for explicit v6 parity before v6 goes live anywhere that matters, and treat “does the SIEM actually parse this v6 log format” as a launch blocker, not a backlog ticket.

Dual-stack doubles your operational surface, and it stays doubled for as long as you run it. Every ACL, monitoring rule, capacity plan, and incident runbook now has a v4 branch and a v6 branch, and they drift apart the moment one gets updated without the other. That’s the real cost of dual-stack — not a performance tax, an ongoing tax on whoever’s holding the pager. What I’d do: attach a real decommission date to dual-stack for each workload at migration time, not just an intention. No date means no plan, and you’ll be running both stacks longer than you think.

Happy Eyeballs will quietly hide a broken IPv6 path from you, which is worse than an outright outage. Client OSes race both address families per RFC 8305 and use whichever connects first, so a broken v6 route on your egress path can sit broken for weeks — traffic just falls back to v4 every time, and nothing pages anyone. What I’d do: monitor v6 connection success rate as its own signal, separate from the blended success rate, and alert on it independently. Watch only the combined number and a 100%-failing v6 path with working v4 fallback looks identical to a fully healthy dual-stack service.

If your monitoring and logging stack doesn’t understand v6, you’re flying blind the moment you turn it on. Flow exporters that only emit v4 records, log parsers with a regex that matches dotted-quad and nothing else, dashboards that silently drop or mis-bucket v6 addresses — you find out during the first v6 incident, which is the worst possible time to learn it. What I’d do: validate end-to-end v6 visibility — flow collection, log parsing, alerting — before the network change goes out, using synthetic v6 traffic to confirm every hop in the observability pipeline actually sees it.

ULA vs. GUA is a real decision, not a formality — get it wrong and you re-architect later. Unique Local Addresses (RFC 4193, fc00::/7) feel like the IPv6 answer to RFC1918: private, not globally routed. But they don’t get you out of NAT for anything that needs to reach the internet or a partner network, which defeats half the point of migrating in the first place. What I’d do: use GUA for anything that might ever need direct external reachability — which, once you count SaaS integrations and partner VPNs, is most things in a large enterprise — and reserve ULA narrowly, for genuinely isolated management or out-of-band networks that will never route externally. Don’t let nostalgia for RFC1918’s “private by default” model drag you into ULA everywhere; that just rebuilds a smaller version of the exhaustion problem you started this migration to escape.

Related Reading

Planning Your Own Migration?

If you’re mapping out an enterprise IPv6 migration and want a second opinion on the address plan or the NAT64 cutover sequence, I’m happy to compare notes. Connect with me on LinkedIn or reach out via Contact.