NAT64 and DNS64 are a pair of standards that work together to perform stateful translation from specifically IPv6-only clients to external IPv4-only servers at the Internet Layer (L3).
NAT64 is specified in RFC 6146, “Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers”, April 2011.
From the RFC:
IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or
ICMP. One or more public IPv4 addresses assigned to a NAT64
translator are shared among several IPv6-only clients. When stateful
NAT64 is used in conjunction with DNS64, no changes are usually
required in the IPv6 client or the IPv4 server.
DNS64 is specified in RFC 6147, “DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers”, April 2011.
From the RFC:
DNS64 is used with an IPv6/IPv4 translator to enable client-server
communication between an IPv6-only client and an IPv4-only server,
without requiring any changes to either the IPv6 or the IPv4 node,
for the class of applications that work through NATs. This document
specifies DNS64, and provides suggestions on how it should be
deployed in conjunction with IPv6/IPv4 translators.
The more general problem of stateless, bidirectional translation at the Internet Layer (L3) appears not to be feasible. NAT64/DNS64 is an attempt to reduce the problem domain enough to come up with a viable solution to at least part of the problem.
Limitation of the Problem Domain
For one thing, NAT64 is not stateless (NAT-PT tried to be, but failed). This means that you can only translate traffic where the connection originated on one side of the gateway, not traffic that originated on the other side. In this case it happens to be the IPv6 side. With a stateful scheme, you can only “untranslate” replies to requests that were translated in the first place. You can’t “untranslate” something that was never translated in the first place (traffic that originated on the other side of the gateway). Stateful mechanisms also have limitations on capacity. These are both problems of “Hide Mode” NAT44, for the same reasons.
Second, the translation is only from IPv6-only clients to external IPv4-only servers. It cannot translate from an IPv4-only client to an IPv6-only server – the DNS64 scheme can embed a 32-bit IPv4 address in the 128-bit bogus AAAA record, but the reverse is not possible – you can’t embed a 128-bit address in a 32-bit A record. There is no need to translate from an IPv6-capable client to an IPv6-capable server – that is just normal IPv6 connectivity. Likewise there is no need to translate from an IPv4-capable client to and IPv4 capable server. The only problem that NAT64/DNS64 is even supposed to solve is not very common today. Most networks are IPv4-only, and would like to be able to access IPv6 nodes through a translator. That would require “NAT46/DNS46”, for which there is no IETF standard (this is because it is not feasible). An example of the situation in which NAT64/DNS64 would be useful is a real 4G smartphone, which is connected only via IPv6. Such devices need to be able to access legacy (IPv4-only) servers. If the server is dual stack, it can access it normally. But for some time to come, the majority (or at least a lot) of the servers on the Internet will be IPv4-only. This is really the problem domain that NAT64/DNS64 was designed to address.
DNS64 is a highly non-standard version of DNS that can fabricate a “bogus” AAAA record from an IPv4 address. An IPv6-only node tries to access a legacy IPv4-only site (e.g. whatismyipaddress.com). It first submits the FQDN to the DNS64 server. That server looks up the real A record of that site and fabricates a bogus AAAA record that embeds that address, which it returns to the IPv6-only client. If the client could do IPv4 it would not be able to use the returned answer to its DNS query, so the client must be IPv6-only (a dual stack client cannot use DNS64). The IPv6-only client then tries to make a connection via the NAT64 gateway using the bogus AAAA record. The NAT64 gateway extracts the IPv4 address embedded in the bogus AAAA record by DNS64 and makes a connection to it. Like Hide Mode NAT44, it must maintain “state” which records the outgoing translation, which it will use to “untranslate” the reply form that server (over IPv4) back to an IPv6 packet to return to the IPv6-only node. Therefore every request/reply event requires an IPv6->IPv4 translation on the way out and an IPv4->IPv4 translation on the way back in. Both of those translations are problematic due to the significant differences between IPv4 and IPv6 (not to mention between ICMPv4 and ICMPv6).
You cannot use NAT64 without DNS64 (NAT64 can only work with bogus AAAA records generated by DNS64 – every translation begins with a DNS64 query). Nodes not behind a NAT64 gateway cannot use DNS64. If you have a highly reliable, high performance standard DNS system, you cannot use it from a node behind NAT64 – you must use a DNS64 server. Recent copies of BIND do support DNS64, but not all high performance DNS appliances do. At the very least, you must have separate DNS infrastructures – standard DNS for nodes not behind NAT64 and DNS64 for nodes behind NAT64. The nodes that use DNS64 cannot be dual stack – they must be IPv6-only.
IP Address Literals
Every protocol that embeds IP addresses in the payload, such as VoIP, requires a protocol specific “helper” Application Layer Gateway that can find that addresses and attempt to translate them. This usually doesn’t work well, since in many cases the information required to do this isn’t available to the NAT64 gateway. Embedding IP addresses (as opposed to FQDNs) in a protocol is a very bad design practice, but we are stuck with a number of widely deployed protocols that do this. We can’t really fix them at this point. Another example of this is a web page that has embedded IP address “literals” in it. A link like “http://188.8.131.52” (as opposed to “http://www.xyz.com”) will work fine over normal HTTP, but completely fails via NAT64/DNS64. The information needed to translate these IP address literals is rarely if ever available to the NAT64 gateway. These links simply fail. Perhaps 5% of web pages contain these. For an example of this (and to see the failure happen via NAT64) see the web page http://us1.hughesnet.org/test.php. The FQDN us1.hughesnet.org has both A and AAAA records published, the FQDN us1-v4.hughesnet.org has only the A record published, and the FQDN us1-v6.hughesnet.org has only the AAAA record published. The IP address literal URLs point to the same site as the FQDN URLs. Note that all of these work fine over normal HTTP, or a Layer 7 translating web proxy.
Nodes that Offload TCP/IP Processing onto Hardware
More and more NICs offer higher performance by offloading TCP/IP processing from the software stack onto hardware in the NIC. This is normally a big win and completely transparent to applications. At least some of these implementations are incompatible with NAT64. It is not clear what exactly the problem is, but it is easy to demonstrate. My ASUS G53SX is a high end gaming notebook (I bought it for the high end i7 processor and ability to install 16GB of RAM). It will not work behind the Ecdysis NAT64 gateway when using the built-in NIC. If a non-hardware assisted NIC is installed, it works fine. This issue needs additional research, but appears to be a serious problem that will affect any NAT64/DNS64 implementation.
There is an informative powerpoint presentation called NAT64 and DNS64 in 30 minutes.
Another interesting viewpoint is available from Secure64.
Microsoft has a NAT64/DNS64 implementation in Forefront UAG DirectAccess.
Cisco has a whitepaper that includes information on their NAT64/DNS64 implementation.
There is a public test of several NAT64/DNS64 implementations here, from go6 Lab at the Internet Society.