IPv6 Migration: The Underestimated Bottleneck in Cloud Transformation

The situation in 2026: IPv6 is the majority protocol, IPv4 is a cost factor

Two developments have shifted the starting position in recent years. First, usage: according to Google's measurements, since the end of March 2026 more than 50 percent of all users worldwide have been accessing Google services via native IPv6 for the first time. APNIC, using a different methodology, measures around 42 percent; both curves show a steady upward trend. Germany has been well above the global average for years, because the major access networks (both fixed-line and mobile) rolled out Dual Stack or DS-Lite long ago. Anyone running a customer-facing application today is serving the majority of their audience over IPv6, whether they realise it or not.

Second, cost: public IPv4 addresses have become a managed commodity. Since February 2024, AWS has charged 0.005 US dollars per hour for every public IPv4 address, around 3.65 US dollars per month, regardless of whether the address is attached to an EC2 instance, a load balancer or a NAT gateway. With a few hundred addresses spread across multiple accounts, this adds up to a five-figure annual sum that appeared in no migration calculation. On the transfer market in 2026, small blocks (/24 to /22) cost roughly 20 to 40 US dollars per address, depending on region and registration history. Leasing a /24 starts at around 100 euros per month. IPv6 prefixes, by contrast, are available from the RIRs for essentially the cost of membership.

The real bottleneck, however, does not lie with public addresses. It lies in the private address space, and that is where it hits cloud transformation with full force.

Why private IPv4 address space runs out first

RFC 1918 provides around 17.9 million private addresses: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. That sounds like a lot, but in a company with a long history it is used up faster than one might think. Three mechanisms are responsible.

Allocation with a watering can

In the 2000s, sites were generously assigned /16 networks, of which perhaps ten percent are used today. They are rarely reclaimed, because nobody knows the dependencies. On paper the 10.x network is full; in reality it is empty – but it is still unavailable for new cloud landing zones.

Overlap through acquisitions and partners

Every acquisition brings its own 10.0.0.0/8, every service-provider connection another 192.168.x network. The standard response is double NAT at the interconnection points. That works until applications enter the picture that carry addresses in the payload, issue certificates against IPs, or (typical in OT) embed fixed, hard-coded addresses in PLC programs and control systems. At the latest when trying to connect such islands to a shared cloud platform, the addressing question turns into a project blocker.

Cloud and containers as address consumers

Cloud architectures consume private address space on a scale that on-premises planners underestimate. Every landing zone needs non-overlapping VPC or VNet ranges, and every region, every stage multiplies the demand. Kubernetes makes matters worse: pod and service CIDRs quickly consume a /16 per cluster, and anyone who makes pods directly routable (for example with the VPC CNI under EKS) pulls this demand into the central address plan. Many organisations are already falling back on the carrier-grade NAT range 100.64.0.0/10, which is actually reserved for provider NAT and collides as soon as a carrier or SD-WAN provider uses the same range.

The result: it is not the shortage of public addresses that slows transformation, but the impossibility of carving out conflict-free private networks for new platforms. IPv6 solves precisely this problem: a single /48 per site offers 65,536 subnets, overlaps are ruled out with clean prefix planning, and NAT disappears as a structural element.

Comparing the migration models

There are three basic patterns for getting there, which differ significantly in effort and target state.

Dual Stack: the expensive standard route

Both protocols run in parallel on every segment. This is the most compatible approach and the right starting point for internet-facing services, but it has a structural catch: it does not solve the address problem, because the IPv4 plan must still be maintained in full. Firewall rule sets, monitoring and troubleshooting are duplicated, and every security concept must cover both paths. An IPv6 gap in a rule set that was tested for IPv4 only is a classic finding in penetration tests. Dual Stack is a transitional state, not a destination. Experience shows that anyone who introduces it without a switch-off date for IPv4 ends up running it for a decade. On the other hand, there are still various network and security device vendors whose management interfaces – or in some cases other components – simply do not work without IPv4.

IPv6-only with NAT64/DNS64: the target state for new platforms

New environments (landing zones, container platforms, backend segments) are addressed exclusively with IPv6. The transition to the IPv4 world is handled by a central NAT64 service with DNS64: the resolver synthesises AAAA records for pure IPv4 destinations from the well-known prefix 64:ff9b::/96, and the NAT64 gateway translates the traffic. For clients without clean DNS usage (hard-coded IPv4 literals, older SDKs), CLAT/464XLAT adds translation on the end device (a mass-deployed technique in mobile networks for years). The hyperscalers now support IPv6-only subnets in production, including NAT64/DNS64 as a managed service. The benefit: a single address plan, no overlaps, and the IPv4 estate shrinks to a handful of translation points.

IPv6-mostly in access: the pragmatic middle way

In campus and client networks, DHCP option 108 ("IPv6-only preferred") allows capable end devices to operate without an IPv4 address, while legacy devices continue to obtain IPv4. This drastically reduces IPv4 consumption in the access layer without forcing a cut-off date for every device. For corporate networks with a heterogeneous device fleet, this is currently the most realistic way to wind down the existing estate.

RFC 8950 (IPv4 prefixes with IPv6 next-hops) is really neat, but is currently supported by only a handful of devices and operating systems. We are therefore not comparing it here yet.

The OT perspective: where IPv4 stays, and why that's fine

Different rules apply in production networks. Fieldbuses and industrial protocols such as PROFINET partly operate at the cell level without IP, or with fixed, hard-coded IPv4 addresses. Device lifecycles of 15 to 25 years rule out any assumption that IPv6 will spread there comprehensively. The mistake would be to conclude from this that IPv6 is "irrelevant for OT". Correctly designed, the opposite is true: it becomes a relief tool. The cell remains IPv4 and is operated (very much in line with IEC 62443) as a self-contained zone with locally unique addresses, ideally even identical across sites. Connectivity upward, i.e. towards site aggregation, the data platform and the cloud, runs over IPv6. This eliminates the notorious problem of identical machine networks in serial production lines: instead of maintaining a NAT construct per line, an edge gateway terminates the cell and communicates upward with a unique IPv6 address. The address conflict that has previously complicated every central data connection is thereby structurally eliminated – without touching a single field device.

What to do now, concretely

Projects reveal a recurring roadmap that decouples migration from the cloud programme instead of forcing it in:

1. Address inventory before architecture. Build a robust IPAM, measure real usage (not allocations) and document overlaps. Without this picture, any discussion of the target state is speculation.
2. Define a global IPv6 prefix plan. Apply for provider-independent (PI) address space from the RIR, define a hierarchical scheme (e.g. region → site → zone → function) and plan generous reserves. The plan is an architecture document, not a by-product. Renumbering is easier with IPv6, but not free. Preferred rule of thumb: always determine the next network in 4-bit (binary) steps with IPv6, for the sake of readability and memorability.
3. Internet edge first. Make public services, DNS, mail and CDN connections Dual Stack capable. This is low-risk, immediately measurable, and ends the situation where the majority of your own customers access you via third-party translation infrastructure.
4. Plan new cloud platforms as IPv6-only. Design every new landing zone and every new cluster as IPv6-only with NAT64/DNS64, and permit IPv4 only as a justified exception. This stops the problem growing further while the existing estate gradually catches up.
5. Bring security operations up to speed. Extend firewall policies, IDS rules, logging and geo/reputation lists to IPv6, handle ICMPv6 correctly (do not block it wholesale: Neighbor Discovery and PMTUD depend on it), and enable first-hop security such as RA Guard in the access layer. An IPv6 that "just runs alongside" unmanaged is the greatest real danger of the migration.
6. Build skills and operational processes. Troubleshooting, capacity planning and change processes must treat IPv6 as the normal case. Technology is rarely the obstacle; two decades of IPv4 thinking trained around NAT cascades is.

Conclusion

Cloud transformation does not fail because of a shortage of IPv4 addresses on the internet, but because of a private address space that was never designed for the platform era. Double NAT, CGN space and address brokers buy time, but no structure – and that time becomes more expensive with every landing zone, every cluster and every acquisition. IPv6 is not a modernisation project alongside the cloud strategy; it is its prerequisite: a conflict-free, plannable address space on which segmentation, Zero Trust and central data connectivity can be built cleanly. Anyone who sets up the prefix plan before the third landing zone collides is carrying out the migration as an architectural decision. Everyone else will carry it out later regardless, just under time pressure and on worse terms.