Is NAT64 a subset of NAT-PT?

Quick summary for the differently attentive: Even without the DNS processing, NAT-PT and NAT64 differ from the perspective of peer-to-peer applications. The differences don’t matter for IPv6 clients connecting to IPv4 servers.

Whenever I’m talking about NAT64, someone would say “we’re already using it”. As it turns out, they’re usually using NAT-PT, which looks a lot like NAT64 from afar (after all, they both allow IPv6-only clients to connect to IPv4-only servers). However, there are significant differences between the two, the most important one being DNS64, which handles DNS processing completely outside of the forwarding path (NAT-PT has embedded DNS Application Level Gateway, which was one of the major reasons NAT-PT was declared broken beyond hope).

I’m discussing the reasons we’ll be forced to use NAT in the transition toward IPv6 in the Market Trends in Service Provider Networks webinar and Enterprise IPv6 Deployment workshop. Core IPv6 network design and implementation guidelines are provided in the Building IPv6 Service Provider Core webinar.

Taking away the DNS processing, the actual protocol translation functions performed by NAT64 and the IPv6-to-IPv4 part of NAT-PT look very similar. I didn’t want to waste time going through the RFCs and comparing the gory details, so I tried to find out whether someone has already done that job. Not surprisingly, Google helped:

  • draft-wing-nat-pt-replacement-comparison-02 compares numerous NAT-PT replacements, including NAT64. It’s sketchy on details, but if you’re interested in various v4/v6 transition mechanisms, it’s definitely worth reading.
  • A presentation by Simon Perreault describes the technical glitches I’ve been looking for. Apart from the DNS-related changes (page #4), the detailed changes to NAT functionality are described on page #11.

The differences in TCP/UDP translations between NAT-PT and NAT-64 are relevant only to peer-to-peer applications; IPv6-client-to-IPv4-server applications work well with both NAT-PT and NAT-64:

  • NAT mapping and filtering behavior matter only in a peer-to-peer scenario or when you have a server using a dynamic TCP/UDP port situated behind NAT.
  • TCP simultaneous-open can only happen in a peer-to-peer environment.
  • Hairpinning is required only when two IPv6 hosts behind a NAT64 device want to communicate using their NATed IPv4 addresses.


  1. Hi Ivan,

    I have been using NAT64/DNS64 from Viagenie for a while now and it worked decent. The mechanism of translation obviously is dependent on DNS though. I am now looking for a translation mechanism for IPv6 only hosts to access IPv4 only internet without DNS (for those applications that do not make DNS queries). Are there any options for such a scenario? I couldn't find any.

  2. Ivan Pepelnjak01 June, 2010 17:41

    Hi Roman,

    How many clients do you have going through the NAT64 from Viagenie simultaneously? A friend of mine was testing NAT64 as a translation platform for an IPv6 conference (his Wifi access was IPv6-only) and claimed that the Viagenie software crashed on him.

    As for the stupidities such as IPv4 addresses encoded in URLs, there's nothing we can do.

    Thank you!

  3. Hi,

    The software crashes indeed from time to time and it does not depend on the number of users from my experience. It is surely more of a prototype. By saying "worked decent" I was mainly referring to the thing that it does the job well. When it comes to stability though - there is a long way to go. It would be nice if Viagenie would release a less buggy version, I am however not sure it is within their scope.

  4. Michael van der Kolff18 September, 2010 05:31

    It seems to me that isn't quite all we can do... By changing what socket() family of calls do on the client with AF_INET (which seems feasible if we're talking about an IPv6 only network), we could make AF_INET calls get translated to being AF_INET6 with the source address being the IPv6 address, and the destination being the WNP + IPv4 address or some other prefix, perhaps handed out with DHCPv6 or through some stateless mechanism.

  5. We could do much more if we would have been able to modify host TCP stack or socket API. Unfortunately, that's unrealistic.

    But you're right; your proposal would make DNS64 irrelevant.


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.