NAT64/DNS64 and Layer 7 Proxy Translation

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:

This document describes stateful NAT64 translation, which allows
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 a mechanism for synthesizing AAAA records from A records.
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 (e.g. a true 4G smartphone) tries to access a legacy IPv4-only site (e.g. 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 "" (as opposed to "") 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 The FQDN has both A and AAAA records published, the FQDN has only the A record published, and the FQDN 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 (such as SolidProxy).


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.


Addtional Information

For additional insight into NAT64/DNS64, see RFC 6052, "IPv6 Addressing of IPv4/IPv6 Translators", October 2010. You can also check out the wikipedia entry on NAT64. There is a lot of information, and a free, open source implementation of NAT64 and DNS64 available from Viagenie. I downloaded the Viagenie NAT64/DNS64 translator and deployed it for testing. It is not straightforward to deploy this, but it can be done. If you are considering using NAT64/DNS64, or simply want to understand it better, I recommend doing this.

There is another open source Linux implementation of NAT64 called TAYGA. They do not include a DNS64 implementation, but recommend the Totd DNS64 "forwarder" (I was unable to reach the website for this, but it supposedly is available via the Ubuntu package manager). I have not worked with TAYGA. It can be deployed on low-end WRT54 wireless routers (by replacing the original firmware). Here is a website that you may find useful for working with TAYGA.

There is an informative powerpoint presentation called NAT64 and DNS64 in 30 minutes.

Another interesting viewpoint is available from Secure64.

Many Telcos are hoping to use NAT64/DNS64 for IPv6-only smartphone deployments.

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.


Alternative - Layer 7 Proxy Translation

The main alternative to Layer 3 translation like NAT64/DNS64 is Layer 7 proxy translation. This works well for web and email and should work for VoIP. You can deploy forward and/or reverse web proxy translators today using Apache or Nginx. I have created a commercial product (SolidProxy) that does this for incoming and outgoing web, so I know it is possible.

This approach requires a separate proxy translator for each protocol to be translated (e.g. one for web, one for email, one for VoIP, etc). Each protocol to be translated must have support for proxies, or else a firewall must be able to do transparent proxying, by capturing traffic for the protocol to be translated and routing it to the translator. In comparison, a single Layer 3 translator should be able to translate all protocols. In practice, layer 3 translators require an Application Layer Gateway helper for most protocols, so there is not really a lot of difference here in terms of protocol support.

The advantages of Layer 7 translation are as follows:

  • Uses only standard DNS - no DNS-ALG or DNS64 required
  • Bidirectional - can translate IPv4 to IPv6 and IPv6 to IPv4
  • Embedded IP address literals in web pages are not a problem
  • Literal IP addresses in the payload can in general be handled
  • Translator can be located anywhere, even "in the cloud"
  • Translator can be combined with IPv6 in IPv4 tunnel to provide access to IPv6 Internet
  • Can be deployed literally overnight, with very few, if any, changes to legacy network required
  • Forward web proxy can translate outgoing web - allows legacy IPv4-only browsers, even in IPv4-only networks, to access external IPv6 servers transparently
  • Forward web proxy can also allow IPv6-only browsers, even in IPv6-only networks to access external IPv4-only servers transparently (solves real 4G smartphone access to legacy servers)
  • Reverse web proxy can allow existing legacy IPv4-only servers to be accessed from external IPv4 and/or IPv6 browsers, transparently.
  • Reverse web proxy can also allow IPv6-only servers to be accessed from external IPv4 and/or IPv6 browsers, transparently
  • Performance and bandwidth can be scaled to any level via deploying on high performance servers and using load balancers (both well understood and time-tested technologies)

The disadvantages of Layer 7 proxy translation are:

  • One proxy is required for each protocol (e.g. web, email, VoIP, etc)
  • Each protocol must have support for proxies, or else transparent proxying is required (which means the translator must be deployed inside the network as the border gateway)
  • Browsers must be configured to use the translator as a proxy (this can be mitigated to a large extent by using WAPD)



At this time, NAT64/DNS64 is unproven technology, with a number of potentially serious issues already discovered. We may see it deprecated at some point in the future, like NAT-PT was. Some very smart people are working on trying to make this work in a greatly reduced problem domain (compared to NAT-PT). There are several commercial implementations available, but no large scale deployments that I've been able to locate. One reason for this is that it is only useful in IPv6-only networks, of which there are not many currently running, although with the rollout of real 4G (LTE Advanced) over the next few years, there may be a lot.

Anyone considering NAT64/DNS64 should seriously consider Layer 7 proxy translation as an alternative, especially if only web and email need to be translated.