IP Address Translation

IP Address Translation is another transition mechanism, in addition to Dual Stack and Tunneling. A translating gateway converts existing IPv4 packets into IPv6 packets (or vice versa). It must remove the existing IP Packet Header and replace it with one of the other IP family (an IPv4 Packet Header is replaced with an IPv6 Packet Header, or vice versa). Compare this to tunneling, which prepends a Packet Header of the other IP family to an entire packet of the tunneled IP family, leaving the original IP Packet Header in place, unchanged. At the other end of the tunnel, the prepended header is removed, and the original IP Packet Header now becomes the real Packet Header again. Tunneling is a way to transport packets of one IP family from one region of that IP family through an intervening infrastructure the other IP family, to a different region of the first IP family (e.g. from one IPv6 region to another, through intervening IPv4 infrastructure). Translation, on the other hand converts packets of one IP family into packets of the other IP family (e.g. IPv4 to IPv6, or IPv6 to IPv4). It is not a two-ended mechanism, like tunneling. In theory, you can convert IPv6 packets into IPv4, transport them over IPv4 to another IPv6 region, then translate them back. This is called NAT646 (translation from IPv6 to IPv4 followed by translation from IPv4 to IPv6). One translation causes enough problems, two makes it even worse. If you are trying to just move packets through an intervening infrastructure of the other IP family, then tunneling is far superior. On the other hand, if you are just translating once (NAT64 or NAT46), you may can get it to work to some extent, for some protocols.

Translation between IP families (NAT64 or NAT46) has all of the problems of translation within a single IP family (e.g. NAT44 or NAT66), but it has additional (far more complex and intractable) problems due to the differences between IPv4 and IPv6. Some very bright people have spent a lot of time and effort trying to solve this problem for over a decade, with very little to show for it. The reason they keep trying is it would be very useful to have a translator that actually works reliably (it has become a kind of "holy grail" quest, with similar results to what King Aurthur's knights managed). It is actually easier to create a translator that converts between SD TV and HD TV than between IPv4 and IPv6, and so far, the results on TV translation have not been entirely satisfactory).

Translation has been by far the most problematic transition mechanism. This is because of the major and significant differences between IPv4 and IPv6. Several schemes (e.g. NAT-PT) have been proposed and then deprecated a few years later because of serious problems to which no solution could be found. Not only the IP packets, but also the ICMP packets must be translated. With tunneling, ICMP packets are just tunneled the same way as IP packets. With translation, every ICMP message from one IP family must be translated into an ICMP message from the other IP family, and there is no one-to-one mapping - there are many more ICMPv6 messages than ICMPv4 messages, and they do much more complex things. Also, address scopes are not fully realized in IPv4, while they are in IPv6. It is possible to map all possible IPv4 addresses into a tiny subset of IPv6 addresses (there is no shortage of IPv6 addresses to map them onto), but it is very difficult to map IPv6 addresses onto IPv4 addresses (there are trillions of trillions times as many IPv6 addresses as IPv4 addresses, even if you have the entire 10/8 private address block to work with - if you are translating onto public IPv4 addresses, there are almost none available to translate onto).

One of the really serious problems in layer 3 IP translation schemes is protocols that embed an IP address literal in the payload (the classic example is SIP, used in VoIP). This is an extraordinarily bad protocol design decision to do this, but unfortunately, we are stuck with several widely deployed protocols that did this. In addition to translating the IP headers and ICMP messages, something (called an Application Layer Gateway helper) must have a detailed knowledge of each specific protocol, and be able to reach inside the packet payload and translate any embedded address(es). Again, it is one thing to translate embedded IPv4 addresses onto IPv6 addresses (where there are plenty available), but another to translate embedded IPv6 addresses onto IPv4 addresses (where there are very few, if any, available). Every protocol that does this requires another Application Layer Gateway helper, specific to that protocol.

One problem that designers of layer 3 translation schemes didn't anticipate is Network Interfaces that offload some of the TCP/IP processing onto hardware in the NIC (these are becoming more common, as it is not difficult for a NIC designer to add this functionality, and it is normally a big win). Nodes with such interfaces usually won't work at all through layer 3 translation gateways. When I tried to deploy NAT64/DNS64, it turned out that the ASUS notebook computer I was using had such an interface in it, and it was impossible to make it work via the NAT64 gateway. Other nodes worked fairly well, but still had problems with web pages that had embedded IPv6 address literals (e.g. "http::/").

All layer 3 translation schemes require a custom DNS implementation to work. NAT-PT had DNS-ALG. NAT64 has DNS64. NAT46 would require a DNS46. You cannot use the custom DNS implementation with nodes that are not doing layer 3 translation, and you cannot use standard DNS with nodes that are. BIND added support for DNS64 some time ago, but it doesn't work as well as standard DNS.

Basically, the non-standard DNS-ALG or DNS64 implementation fabricates a bogus AAAA record based on the IPv4 address of the target. The translator (NAT-PT or NAT64) uses this bogus DNS AAAA record to actually do the translation. This is a stateful process, which means a gateway can only translate in one direction. If the connection originates on the external side, the gateway cannot "untranslate" addresses and ports that were never translated in the first case (just like NAT44 gateways are one-way outgoing). Nodes not going through NAT-PT or NAT64 cannot use the bogus AAAA record - there is no node at the IPv6 address in the bogus AAAA record. Nodes going through NAT64 must be configured to use the corresponding DNS64, and other nodes must not use this. This really complicates your DNS infrastructure.

One approach that has been tried in layer 3 translation is to redefine the original problem to a much simpler one. NAT-PT tried to do stateless translation in both directions (IPv4->IPv6 and IPv6->IPv4). This was pretty much a total failure. NAT64/DNS64 redefined the problem domain to stateful translation from IPv6 clients to external IPv4 servers.It is specified in RFC 6146, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", April 2011. This is a small subset of the original goal.

There has been some success in this smaller problem domain, but a lot of people would like to have a translator that allows them to access external IPv6 servers from an IPv4-only node. This problem is not even addressed by NAT64. That would be addressed by NAT46/DNS46. Unlike NAT64/DNS64, there is no IETF RFC for NAT46. There are a few implementations that have been tried (e.g. in the Cisco ASA firewall). For one thing, the fabrication of a bogus A record in DNS46 is much more problematic than the fabrication of a bogus AAAA record in DNS64. There is plenty of room in a 128-bit bogus AAAA record to embed a 32-bit IPv4 address, but nowhere near enough room in a 32-bit bogus A record to embed a 128-bit IPv6 address.