Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

NAT64: it’s all about the legacy content

Few days ago I enjoyed listening to the Teredo-bashing Packet Pushers Podcast during which Greg & the crew simply couldn’t avoid NAT64. Tom even wrote a follow-up post explaining why NAT is bad (we all agree with that) and why we shouldn’t use it in IPv6. Unfortunately he missed the elephant in the room: it’s all about the legacy content. IPv6-only residential users have to access IPv4-only content.

We know IPv4 address space has been sold out. In Asia an ISP cannot get more than a /22 regardless of their size. There are three ways to connect new customers to the Internet (see my NAT64 and DNS64 in 30 minutes presentation for details).

Connect them using private IPv4 address space and use NAT44 (or NAT444 aka LSN/CGN). This is clearly a dead end. Layered NAT is even more broken than regular NAT or NAT64 (although it’s possible to do 30 layers of NAT and still have some connectivity). You have also not addressed the IPv4 address exhaustion problem.

Connect them using dual-stack. As above, you still need NAT44/NAT444 for IPv4 and you make your network more complex than necessary. On top of that, people trying to avoid NAT444 have proposed convoluted schemes like DS-Lite or A+P.

Supporting and troubleshooting dual-stack residential ISP networks with unknown customer-side configs could also turn out to be great fun.

Connect them to IPv6 and use NAT64. Still seems to be the cleanest solution to me. Single protocol in the access network, NAT is out of the forwarding path, and it’s used only where absolutely needed. Caveat: while regular web browsing works just fine with NAT64, P2P applications (like Skype) might get totally confused unless they're NAT64-aware.

We all hate NAT to various degrees, but at the moment NAT64 seems to be the least painful interim solution. The long tail of the content will take years to figure out why you shouldn’t ignore IPv6.

What are the alternatives?

The proper way to tackle this issue is to make your content available over IPv4 and IPv6. IPv4 clients won’t notice it and IPv6 clients will use native IPv6 connectivity bypassing NAT64. You might find useful overview of what needs to be done in my Enterprise IPv6 – the first steps webinar (register here or buy a recording).


  1. Terry Pattinson11 May, 2011 09:31

    Sounds good in theory. However, my blog is hosted by Bluehost and yesterday I thought I should consider IPv6'ing up - a quick google search revealed this funny (and sad) link:

  2. Ta for the link Ivan - But NAT has to go IMO 8-)


  3. Ivan Pepelnjak12 May, 2011 07:34

    Can't agree more ;)

  4. Ivan Pepelnjak13 May, 2011 20:52

    No, it will become another dying (and finally extinct) protocol like DECnet, AppleTalk, IPX, X.25, SNA ...

  5. Ivan is exactly right, and that is how I always start my own IPv6 seminars. As of last summer, 96% of the top 1000 Internet sites were IPv4-only accessible, and the majority of the remaining 4% were google's whitelisted properties.

    But the reality is that no consumer, today, would pay for an IPv6-only connection without the ISP providing some mechanism to reach the IPv4 Internet.

  6. what IOS suport NAT64 ??

  7. Latest IOS XE

  8. thanks for your answer, let me know if you can emulate NAT64 with GNS3 or something like that. Forgive me for my poor English.

  9. Use F5's BIG-IP VE trial version. Search my blog for related post.

  10. google talk works with NAT64. Skype not..

  11. He tried to do it again with multiple NATs internally per firewall...


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