Abstract
The exhaustion of IPv4 address space has pushed cloud providers and large-scale operators toward IPv6-only internal infrastructure with NAT64/DNS64 translation at the boundary. Apple required IPv6-only network support for iOS app submissions back in 2016, accelerating the ecosystem, but enterprise data center transitions have lagged. By early 2026, a growing number of operators are completing or actively running IPv6-only deployments for new infrastructure builds - not as a long-term aspiration but as the practical default. The operational pattern that makes this work is NAT64 combined with DNS64, and its deployment has matured enough that the transition is tractable for most shops.
NAT64 and DNS64 Mechanics
In an IPv6-only network, hosts lack IPv4 addresses. When they need to communicate with IPv4-only services, NAT64 performs stateful translation at the network boundary, converting IPv6 packets destined for a synthesized IPv4-mapped address into IPv4 packets and back. DNS64 (RFC 6147) is the companion mechanism: a DNS64 resolver intercepts AAAA queries that return no result (IPv4-only destination) and synthesizes an AAAA record by embedding the destination’s A record address into a well-known IPv6 prefix (typically 64:ff9b::/96). The client receives a valid AAAA record, connects via IPv6, and NAT64 handles translation transparently. For east-west traffic between internal services - which is all dual-stack or IPv6-native in a properly built internal network - NAT64 never enters the path.
Common Deployment Blockers
Several categories of applications break under NAT64 that operators should audit before cutting over. Applications that embed raw IPv4 literals in payloads (SIP VoIP stacks are the classic example) bypass DNS64 and cannot reach IPv4 destinations. Applications that call getaddrinfo but then filter out AAAA results and attempt direct IPv4 socket connections also break. Legacy monitoring agents with hardcoded IPv4 syslog or SNMP targets need updated configuration. These are all addressable, but the audit is non-trivial on large legacy server fleets. Tools like NAT64check (from ARIN) and the Apple-published network-check utility help enumerate broken endpoints before transition.
DNS64 Resolver Placement and DNSSEC
DNS64 and DNSSEC have a known conflict: DNS64 synthesizes records that were not signed by the origin authority, which breaks DNSSEC validation for synthesized AAAA responses. The resolution is to run DNS64 in resolvers that do not advertise DNSSEC validation (AD bit) for synthesized responses, and to run separate validating resolvers for DNSSEC-critical paths. Unbound and BIND both support DNS64 with appropriate DNSSEC handling when configured correctly, but the default configurations in most distributions need adjustment. Cloudflare’s 1.1.1.1 and Google’s 8.8.8.8 explicitly support DNS64 synthesis for NAT64-prefixed lookups when queried from an IPv6-only client, which simplifies external resolver configuration.
What the Fully Migrated Network Looks Like
In a completed migration, all servers carry only IPv6 addresses on their primary interfaces. Private IPv4 space is gone from the internal routing table entirely. NAT64 gateways (Jool on Linux is widely used for this) handle a shrinking set of legacy external connections as the internet continues its IPv6 transition. Internal service discovery, load balancers, and monitoring stacks are all native IPv6. The operational simplification from a single address family is substantial: no more dual-stack debugging, no IPv4 address management overhead, and simpler firewall rules with a unified address space.