NAT-PT is dead! Long live NAT-64!

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.

Getting more information

The effects of NAT64 deployed by mobile operators on your web applications are described in my Enterprise IPv6 – the first steps webinar (buy the recording or register for an online session). The webinar also explains how you can use NAT64 or IPv6-to-IPv4 load balancing to IPv6-enable your legacy applications.

7 comments:

  1. I have been testing (very) basic NAT64 functions in the Zeus appliance. And I have been told from non-official sources that Netflix used F5s to do this but I am not sure if their move to EC2 has killed that since there is no native IPv6 into EC2.

    ReplyDelete
  2. NAT-PT == NAT64. NAT-PT implementations made the separation of the DNS ALG and the translator too.
    Same shit, new name.

    ReplyDelete
  3. You can use Proxy Servers to provide the same NAT46 functions however because they include an ALG that actually works for translating HTTP requests and rewriting DNS. Look at BlueCoat who are already complete with their IPv6 technology.

    Of course, Proxy Servers use a completely different methodology. .......

    ReplyDelete
  4. Ivan Pepelnjak30 March, 2011 14:27

    Proxy servers only work for specific protocols (for example, HTTP). If you assume that HTTP is the new TCP, then you've solved your problem. Skype over HTTP over proxy server? I doubt it will ever happen.

    ReplyDelete
  5. Hi Ivan,

    You must have missed Brocade's software release 12.3 announcement last week that adds NAT64 support to the ServerIron ADX. (As well as a 2X performance increase)

    Here's a link to the announcement: http://goo.gl/qQHPg

    Cheers!

    (Disclosure: I am an employee of Brocade, but this comment is my own)

    ReplyDelete
  6. Ivan Pepelnjak30 March, 2011 15:05

    Thank you! Exactly what I was looking for!

    ReplyDelete
  7. Berge Schwebs Bjørlo28 April, 2011 10:02

    Among NAT64 implementations there's also the free TAYGA, on http://www.litech.org/tayga/. It only does stateless NAT64, but you can always NAT44 the traffic as well.

    ReplyDelete

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

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.