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).
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.
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.
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!
Ivan
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.
But you're right; your proposal would make DNS64 irrelevant.