I’m getting questions like this one all the time: “Where are we with NAT-PT? It was implemented in IOS quite a few years ago but it has never made it into ASA code.”

Bad news first: NAT-PT is dead. Repeat after me: NAT-PT is dead. Got it? OK.

More bad news: NAT-PT in Cisco IOS was seriously broken after they pulled fast switching code out of IOS. Whatever is left in Cisco IOS might be good enough for a proof-of-concept or early deployment trials, but not for a production-grade solution.

There are numerous reasons NAT-PT was a bad idea and deserved to be shot. If you want to know all of them (or at least most of them), read the RFC 4966; here are the more important ones (including the way NAT64 addresses them):

NAT46 can never work well. NAT-PT tried to solve too many problems, including ubiquitous access of IPv4 clients to IPv6 content. As you might imagine, it’s somewhat hard to map 128-bit address space into 32 bit addresses.

NAT64 solves the workable part of NAT-PT: giving IPv6 clients access to IPv4 servers.

NAT-PT has DNS ALG in the forwarding path. The NAT46 functionality of NAT-PT forced its designers to include DNS translation code (application level gateway – ALG) in the forwarding path – every time an IPv4 client sends a DNS request that returns only an AAAA, a dynamic IPv4-to-IPv6 mapping needs to be established and returned to the client.

The mapping from (server) IPv4 addresses into (client-side) IPv6 addresses in NAT64 is static (32 bits from IPv4 addresses are inserted into a predefined part of the NAT64 prefix), removing the need for communication between DNS64 server (DNS ALG) and NAT64 device.

NAT-PT has to be in the forwarding path. If you want NAT-PT to perform DNS mappings in the forwarding path, it has to see all IPv4 and all IPv6 traffic. NAT-PT must inspect all the traffic, not just the traffic that needs to be translated.

You can place a NAT64 device at the edge of your network (the technology also allows one-arm deployment), as it works similarly to the Source NAT load balancers. Native IPv6 traffic and native IPv4 traffic never traverse the NAT64 device, reducing its performance requirements.

NAT64 implementations and deployment experience

Networking vendors are slowly rolling out NAT64-capable devices. Cisco has implemented stateless NAT64 on ASR 1000, Juniper has full-blown NAT64 running on MX Series 3D Universal Edge router, Microsoft has Forefront UAG DirectAccess and there’s an open-source product from Viagenie. Have I missed something? Please share it in the comments.

NAT64 has obvious limitations: web applications work well, broken web applications that embed IPv4 addresses in URLs or use IPv4 addresses to download additional content (flash movies, for example) clearly demonstrate their brokenness, and most peer-to-peer applications (including Skype) haven’t realized yet there’s a whole new IPv6 world out there. However, the early test reports (including this one) seem to indicate NAT64 works well within the bounds of its capabilities.