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.