NAT64 and DNS64 have quietly become core pieces of infrastructure for mobile operators trying to loosen their grip on IPv4. And it’s no mystery why. The global IPv4 pool is basically gone, so carriers now face a choice: keep buying addresses at ever-higher prices, or move subscribers onto IPv6-only networks while still reaching the huge portion of the internet that remains IPv4-only. NAT64 and DNS64 together form the bridge that makes the second option work. Devices never need dual-stack provisioning; translation happens in the network. For anyone planning this transition, understanding how the pieces actually behave in production is the difference between a clean migration and a support nightmare.<\/p>\n
Mobile carriers face a peculiar squeeze. Subscriber bases grow by millions a year, yet traditionally each device needed at least one public IPv4 address for internet access. With Regional Internet Registries (RIRs) like ARIN, RIPE NCC, and APNIC reporting exhausted free pools, the only remaining option is the open market, where prices have climbed steadily and currently sit at roughly $30 to $60 per address, depending on block size and transfer terms.<\/p>\n
Do the math. A carrier adding ten million subscribers a year cannot buy ten million IPv4 addresses at those rates. Carrier-Grade NAT (CGNAT) offered a partial answer, sure. But it comes with its own headaches: logging requirements for law enforcement compliance, degraded performance for peer-to-peer applications, and breakage in some inbound connection scenarios.<\/p>\n
IPv6-only networks with NAT64 at the edge shift the burden elsewhere. Translation only happens when traffic actually needs to reach an IPv4 destination, and stateful NAT64 pools can be sized far smaller than a full per-subscriber allocation. The practical benefits:<\/p>\n
For IT managers looking at long-term infrastructure budgets, the takeaway is blunt: every percentage point of traffic moved off IPv4 translation eases pressure on constrained address pools. And market prices, as far as anyone can see, only go up.<\/p>\n
The two protocols are complementary halves of one translation architecture. DNS64 works at the resolver: when an IPv6-only client asks for a hostname that has only A records (no AAAA), the resolver synthesizes an AAAA record by embedding the IPv4 address inside a reserved prefix, typically the well-known prefix 64:ff9b::\/96. The client gets what looks like a perfectly normal IPv6 answer and sends traffic accordingly. It never knows the difference.<\/p>\n
NAT64 picks up from there, at the network edge. It receives packets addressed to the synthesized prefix, extracts the embedded IPv4 destination, translates the IPv6 packet into IPv4, and forwards it using its own pool of public addresses. Return traffic follows the reverse path, with the NAT64 holding state to map flows back to the right IPv6 client.<\/p>\n
A few operational details deserve attention before rollout:<\/p>\n
Engineers should also keep an eye on gateway metrics \u2014 active sessions per subscriber, port allocation rates, latency added by translation \u2014 and size the NAT64 pools correctly before expanding IPv6-only coverage. Guessing here gets expensive later.<\/p>\n
T-Mobile US provided the industry’s most influential proof of concept when it launched its 464XLAT-based IPv6-only network, combining stateless translation on the device side with stateful NAT64 in the core. The results, shared publicly through presentations and measurement reports, showed that more than 90% of traffic from major applications flows natively over IPv6. Only a small fraction ever touches the NAT64 gateway.<\/p>\n
Several lessons from these deployments have hardened into industry practice:<\/p>\n
Other carriers across Europe, Asia, and North America have followed similar playbooks, steadily shrinking their IPv4 footprints while keeping service quality intact. Operators that still need to bridge gaps during migration \u2014 CGNAT pools, peering ranges, legacy infrastructure \u2014 often find that supplementing inventory on the open market is the pragmatic path. Working with a trusted marketplace like IP4 Market, which offers verified sellers and competitive pricing, helps secure clean, transferable blocks without procurement risk.<\/p>\n
The financial argument for NAT64 and DNS64 is not hard to make. Consider a mobile operator with a million subscribers. Running a traditional dual-stack CGNAT environment comfortably typically takes several \/16-equivalent IPv4 allocations. Now flip it: move most subscriber traffic to an IPv6-only core and let NAT64 handle whatever IPv4 destinations remain. Operators who do this routinely cut their public IPv4 requirements by 60 to 80 percent. With lease rates running roughly $30\u201350 per address per year, that’s seven-figure savings over a few years for the larger carriers. Real money, not rounding errors.<\/p>\n
And the operational side compounds it. An IPv6-only subscriber plane means you stop sizing dual-stack state tables, you maintain half the address plan, and subscriber tracing gets cleaner \u2014 each device maps to one stable IPv6 address instead of a shared IPv4 address plus a port range. RADIUS and diameter accounting records become more precise, too, which quietly reduces the support escalations that come from CGNAT port exhaustion and abuse attribution mistakes. Anyone who has handled those tickets knows how much time they eat.<\/p>\n
Even operators who can’t go fully IPv6-only gain something from partial deployment. Apply NAT64 only to roaming or IoT APNs, where IPv4-only destination traffic is minimal, and you still shrink the exposure.<\/p>\n
Mature as it is, NAT64\/DNS64 has failure modes that are well documented. Every deployment team should plan for them. Some are subtle.<\/p>\n
Synthesized AAAA records cannot pass DNSSEC validation \u2014 the signed zone simply contains no such records, so clients performing local validation will reject the synthetic answers. The practical fixes: let the resolver do validation on behalf of clients (a validating resolver with stubs that don’t validate locally), or route traffic for DNSSEC-validating applications down a different path. And do test with popular mobile apps. Many bundle their own validating resolvers, which surprises people.<\/p>\n
Applications hard-coding addresses like 192.0.2.10 never query DNS. So DNS64 never synthesizes a translation, and the app breaks. Hard-coded literals, non-compliant URI parsers, and SDKs using raw sockets are the leading causes of breakage on IPv6-only networks. Keep a 464XLAT fallback in place \u2014 T-Mobile and most major carriers do \u2014 so client-side CLAT restores IPv4 connectivity transparently. It also helps to log literal-usage patterns; that gives you leverage to pressure application vendors toward actual fixes.<\/p>\n
For mobile operators, increasingly the answer is yes. NAT64 and DNS64, typically deployed with 464XLAT, have been proven at planetary scale by the largest carriers, and they deliver a direct, measurable cut in IPv4 demand while pushing genuine IPv6 readiness forward. That said, the technology doesn’t replace dual-stack where legacy enterprise dependencies dominate \u2014 here I’d rather be honest than enthusiastic. But in subscriber-facing mobile networks, the economics and operational gains are compelling. Success depends on disciplined planning: validate resolver behavior, test application compatibility, size translation capacity honestly, and secure your residual IPv4 needs strategically. When a transition still requires additional address space for CGNAT pools, legacy peering, or interim dual-stack, how you acquire it matters. IP4 Market offers a trusted platform for IPv4 transactions, with verified sellers and competitive pricing, letting operators buy or lease exactly what the transition demands without overcommitting capital. Networks that pair aggressive IPv6-only adoption with a lean, well-sourced IPv4 reserve will be the ones best positioned for the decade ahead.<\/p>\n