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:
- Allowing IPv6-only clients to reach legacy IPv4 content while minimizing IPv4 address usage (similar to PAT)
- Allowing content providers to offer their IPv4-only content over IPv6. This use case is described in my Enterprise IPv6 – the first steps webinar (register for an online session or buy a recording).
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?
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.