NAT64 is a translation mechanism that lets devices running only IPv6 communicate with servers running only IPv4. It solves a fundamental problem during the long transition from IPv4 to IPv6: billions of devices are moving to IPv6-only networks, but a significant portion of the internet still runs on IPv4. Without something bridging that gap, IPv6-only clients simply can’t reach IPv4-only destinations. NAT64, working alongside a companion technology called DNS64, handles that bridge transparently.
The Problem NAT64 Solves
IPv4 addresses ran out years ago. The pool of roughly 4.3 billion addresses can’t keep up with the number of devices coming online, which is why the industry has been shifting to IPv6 and its vastly larger address space. But that shift can’t happen overnight. Countless websites, APIs, and services still operate exclusively on IPv4, and they’ll continue to for years.
If you run a network that’s purely IPv6 (as many mobile carriers now do), your devices have no native way to talk to those IPv4-only servers. The two protocols use completely different address formats and packet structures. NAT64 sits at the boundary between the two networks and translates packets in both directions, converting IPv6 packets into IPv4 packets on the way out and doing the reverse on the way back. From the perspective of the IPv6 device, it looks like it’s communicating over IPv6 the entire time.
How NAT64 and DNS64 Work Together
NAT64 doesn’t work alone. It relies on DNS64 to set up the illusion that an IPv4-only server is reachable over IPv6. Here’s the sequence:
When an IPv6-only device wants to reach a website, it asks a DNS server for an IPv6 address (called a AAAA record). If the website supports IPv6, the DNS server returns that address normally and NAT64 isn’t involved at all. But if the website only has an IPv4 address (an A record), the DNS64 server steps in. It takes that IPv4 address and wraps it inside a specially constructed IPv6 address by combining a designated prefix with the original IPv4 address. For example, if the IPv4 address is 192.0.2.1 and the prefix is 64:ff9b::/96, the synthesized IPv6 address becomes 64:ff9b::192.0.2.1.
The IPv6 device receives this synthesized address and sends its traffic to it, unaware that anything unusual is happening. The network routes that traffic to the NAT64 translator, which recognizes the prefix, extracts the embedded IPv4 address, translates the packet headers from IPv6 to IPv4, and forwards the packet to the real IPv4 server. When the server responds, the translator converts the IPv4 response back into IPv6 and sends it to the original device.
The key requirement is that both the DNS64 server and the NAT64 translator use the same prefix. If they don’t, the translated addresses won’t match and the routing breaks.
The Well-Known Prefix
The IETF reserved a standard prefix for NAT64 use: 64:ff9b::/96. This is called the Well-Known Prefix, and it’s what services like Google Public DNS64 use to provide NAT64 resolution globally. Any IPv6 packet addressed to the 64:ff9b::/96 range signals to the network that it needs to be routed through a NAT64 translator.
Networks can also use their own custom prefixes instead. Some equipment, like certain Cisco firewall versions, actually requires a custom prefix and doesn’t support the Well-Known Prefix. Custom prefixes give operators more control over routing but require coordinated configuration between the DNS64 and NAT64 components. The prefix length must be 96 bits or shorter, and the algorithm that embeds the IPv4 address must be reversible so the translator can always extract the original IPv4 address from the synthesized IPv6 address.
Stateful vs. Stateless NAT64
NAT64 comes in two flavors. Stateful NAT64, defined in RFC 6146, is the more common deployment. It works like traditional network address translation: multiple IPv6 clients share one or more public IPv4 addresses, and the translator maintains a table of active sessions to keep track of which response goes to which client. This is efficient because you don’t need a dedicated IPv4 address for every IPv6 device, which is the whole point when IPv4 addresses are scarce. Stateful NAT64 supports TCP, UDP, and ICMP traffic.
Stateless NAT64 takes a simpler approach with a fixed, one-to-one mapping between IPv6 and IPv4 addresses. It doesn’t maintain session state, which reduces complexity on the translator, but it requires a dedicated IPv4 address for each IPv6 device that needs to communicate. That tradeoff makes stateless NAT64 less practical for large-scale deployments where conserving IPv4 addresses is the goal. It’s more suited to specific scenarios like connecting IPv4 clients to IPv6-only servers using preconfigured static bindings.
Where NAT64 Is Deployed Today
Mobile carriers are the most prominent adopters of NAT64. T-Mobile in the United States runs IPv6-only on its mobile network and uses a protocol called 464XLAT, which integrates NAT64, to maintain access to IPv4 content. Sprint, Telstra in Australia, and Deutsche Telekom in Germany have reported similar deployments. China Mobile has also signaled its intention to use NAT64 as it rolls out IPv6 across its massive network.
Research from Georgia Tech and the Max Planck Institute that examined NAT64 deployment across the internet found DNS64 active in 13 unique autonomous systems. These included four mobile service providers, four network service providers, two Chinese university networks, two hosting providers, and one content delivery network. The footprint is still relatively concentrated, but it reflects the practical reality that mobile networks, where new devices are constantly joining and IPv4 address pools are most strained, have the strongest incentive to go IPv6-only.
Protocols That Don’t Translate Cleanly
NAT64 works well for standard web traffic, email, and most common protocols, but it struggles with applications that embed IP addresses inside their data payloads rather than just in packet headers. The translator can convert headers automatically, but it can’t see or modify addresses buried in application-layer data without extra help.
That help comes in the form of Application Layer Gateways, or ALGs, which understand specific protocols deeply enough to find and translate embedded addresses. Most NAT64 deployments include an FTP ALG, since FTP is notorious for passing IP addresses in its data stream. More capable deployments may also support ALGs for HTTP, HTTPS, RTSP (used in streaming), and SMTP (used in email).
SIP, the protocol that powers most voice-over-IP calls, is a notable pain point. Testing in LTE mobile environments found that voice calls between an IPv6 SIP client and an IPv4 SIP client failed outright due to the lack of NAT64 traversal support. Protocols that rely heavily on embedded addresses or peer-to-peer connectivity patterns remain the hardest cases for any translation-based approach.
Why NAT64 Matters for the IPv6 Transition
NAT64 occupies a specific and practical role: it lets network operators deploy IPv6-only infrastructure without cutting off access to the IPv4 internet. This is significant because running dual-stack networks (where every device has both an IPv4 and an IPv6 address) is expensive and complex. It doubles the routing tables, doubles the firewall rules, and still requires a pool of IPv4 addresses that are increasingly difficult and costly to obtain.
By going IPv6-only internally and placing NAT64 at the network edge, operators simplify their infrastructure to a single protocol stack while preserving backward compatibility. The IPv6 device never needs to know that the far end is IPv4. The translation is invisible. As more servers and services adopt native IPv6, the volume of traffic flowing through NAT64 translators naturally decreases, and eventually, when IPv4 servers become rare enough, the translators can be retired entirely. NAT64 isn’t the end state. It’s the mechanism that makes it possible to start deploying IPv6-only networks today without waiting for the entire internet to finish migrating.