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

Stateless NAT64 is useless

When I was explaining stateless and stateful NAT64 a while ago, I compared them to what we used to know as NAT (L3-only translation) and PAT (per-L4-session translation). Wrong. Even L3-only NAT44 needs some state (inside-to-outside IPv4 address mapping).

Stateless NAT64 is truly stateless: it uses a deterministic algorithm to convert IPv4 addresses into specially crafted IPv6 addresses (a good diagram is included in IOS XE documentation). It’s also mostly useless.

NAT64 has two common use cases:

You don’t need a full-blown stateful NAT64 to make your content available over IPv6. 6-to-4 load balancer like F5’s BIG-IP, Brocade’s ADX or Zeus Traffic Manager is a good enough solution.

Stateless NAT64 cannot be used in either one of these use cases.

IPv6 address format. Stateless NAT64 address translation algorithm works only with very particular IPv6 addresses. If you want to use stateless NAT64 to give your IPv6 clients IPv4 connectivity, you have to ensure the clients’ IPv6 addresses conform to that format. Forget SLAAC, you must use DHCPv6 (or static IPv6 addresses).

IPv4 address preservation. Stateless NAT64 needs a separate IPv4 address for each IPv6 address it’s translating. This might have been fine 15 years ago; today we don’t have that luxury in public IPv4 networks any more.

You can “solve” the address preservation problem by placing a NAT44 device in front of NAT64 device. Great design ... and while doing that, why don’t you insert an RFC 4338 link running over FCoE between the two boxes to ensure continuous headache.

Is stateless NAT64 useful at all? Well, there is a single use case where it might come handy: if you have an IPv6-only server and you have to make it reachable to IPv4-only clients (fat chance today), stateless NAT64 is the right tool for the job.

Why bother? Cisco promised NAT64 a year and a half ago, and then launched stateless NAT64 last November. I’m positive they’re as aware of its general uselessness as I am and I can’t figure out why they would bother launching a half-baked solution. After all, once you get the hard part done (IP header translation and ICMP translation), adding state table is a minor annoyance (more so since they already have stateful NAT44 code). Any ideas?

More information

If you need a high-level IPv6 overview and a deployment action plan, my Enterprise IPv6 – the first steps webinar is the right choice (register for an online session or buy a recording).

If you’re interested in baseline technical details like IPv6 addressing, packet structure and basic router/host configuration, Brandon’s MyIPv6Tutor is the best choice (register).

Working for a Service Provider? You’ll find all the intricate details of deploying your IPv6 core and providing IPv6 to your enterprise and residential customers in my Building Service Provider IPv6 Core webinar (buy a recording or yearly subscription).

Last but definitely not least, if you need in-depth knowledge of major Cisco IOS IPv6 features, take the weeklong IPv6 Fundamentals, Design, and Deployment v3.0 course.


  1. What about a cable company with v6 VoD servers connecting to crap Moto set top boxes?

  2. question is why was not ipv6 compatible with ipv4, i just cann't get over this overlook, did they believe that every one will accept their candy from day one.

    Just trying to make up for lost chance. It is only hope for the old boxes lying in the dust some where, but that will be mostly for devices(routers) that are out of sale and support.

  3. Ivan Pepelnjak26 May, 2011 20:15

    Somehow it's hard to make 128-bit addresses compatible with 32-bit addresses. It's a bit late (and the question is purely academic at the moment), but if you have any ideas, write them down.

  4. Ivan Pepelnjak21 June, 2011 21:02

    If you would propose s/useless/mostly useless/ I might reluctantly agree. Remember that stateless NAT64 has a very rigid structure of the IPv6 addresses.

    Assume that you have a single Class-C that you can use for mapping and that you want to have servers in separate subnets. I could probably design a solution, but it would be kludge royale.

    Interestingly, I had a discussion with Tore Anderson as he proposed the exact use case in one of his presentations and wanted to use NAT64 in ASR1K to do it. Turned out his design is still conceptual and after I pointed out "a few" limitations of addressing structure he went like "Are you telling me this will never work" and then "Why can't they just allow me to configure static NAT translation?"

    So, if you have a customer that actually uses stateless NAT64 (not static 4-to-6 NAT or 4-to-6 LB) to connect IPv4 clients to IPv6 servers, please let me know. I would be more than interested to hear (and blog) about them.

  5. If NAT64 is useless, what's the opinion of the dual stateless (dIVI) translation method?

  6. Ivan Pepelnjak24 April, 2012 19:06

    Will try to figure it out and form some cohesive thoughts. My brains hurt when I looked at the diagrams in the Wikipedia article.

  7. Ivan Pepelnjak24 April, 2012 19:08

    BTW, Tore pushed his "NAT46 on ASR1K" idea to completion using IPv6 host routing and /128 on server loopback interfaces.

  8. Hey Ivan, Great blog.

    My apologies if i am opening a somewhat old thread.

    I have a slight discrepant opinion about one to one IPv4 to IPv6 mapping.

    Agreed that NAT64 is truly stateless. However you can use SLAAC or DHCPv6 to allocate a fixed /64 IPv6 address to the CPE or the End users.

    The rest of the 64 address or the interface identifier can contain the converted IPv4 to IPv6 address.

    What do you think?

    1. What will you gain with that? Think about the IPv4 side, not IPv6 side.

  9. The headline of this article is no longer accurate: MAP-T ( is an extension of statelss NAT64, that allows shared IPv4 use. It is shipping from a couple of vendors incl. cisco.

    1. I should have quoted the SIIT RFC # and then it would still be accurate ;) ... but of course I agree with you, will have to write an update.

      BTW, when is the "Tore Anderson" SIIT extension in IOS XE shipping?

    2. That's coming in XE rel 11. Strictly speaking it's not so much a SIIT extension, but rather a feature allowing non rfc 6052 address formats to be mapped using SIIT (rfc 6145)


Constructive courteous comments are most welcome. Anonymous trolling will be removed with prejudice.