I recently came across this thread:
(Requesting to know if NAT64/DNS64 are in the feature roadmap for ROSv5)
Obviously, being 6 years later, we can all say that the answer to that question was a big "hell no."
Over the years, I've generally fallen in with the idealogues who are almost religiously opposed to any sort of NAT in the IPv6 world. I do still feel that stateful, per-session NAT66 with a many-to-one mapping capability is an evil that should never be unleashed upon the IPv6 world. So much can be improved by eliminating all of this nat-traversal stuff that we've all become so accustomed to. It wasn't supposed to be this way. It didn't work this way before, and we can go back to the way things were supposed to be again!
However, I now feel that there are cases where NAT is justified in the brave new world of IPv6 tomorrow land: NAT64 and Stateless prefix translation
(both stateless and stateful)
This is the primary focus of the thread I linked above. Many people (including myself) poo-pooed the idea, saying that dual stack is just the way to go, and that NAT is problematic. IPv6 should just be free from the scourge of NAT from inception through the end of time. I still do feel that dual stack is the best way to go, but I have realized that this view is not
a valid critique of NAT64. NAT64 is an interworking function designed to allow direct communication between the parallel universes of internet4 and internet6. Some far-flung future day will dawn, when the last IPv4 address is turned off, and there will be much rejoicing. On that day, NAT64 will not be a part of IPv6, so there's no reason to oppose NAT64 because dual-stack is better than interworking.....
It seems that most people (including myself) have missed the point of NAT64.
The prevailing view of NAT64 in the thread was that its use is for early-adopters of IPv6 to throw IPv4 out of their networks, and use the NAT64+DNS64 gateway as the way to reach the 'legacy' IPv4 Internet. Only someone who's totally chugged the Kool-Aid would drop all IPv4 on their own network just to be an early adopter; accepting the hiccups of NAT64 in this mode of deployment. Therefore, while NAT64+DNS64 would allow someone to leap into the world of early-adoption (and let's face it - it's silly to say that deploying IPv6 today is "early" anymore - you can watch Netflix using only IPv6 for crying out loud), this isn't really where NAT64 is most useful.
NAT64 allows the end user networks to operate as dual-stack islands crossing a sea of IPv6 to reach the IPv4 Internet.
The true benefit of NAT64 is in the ISP's space - where IPv4 addresses must ultimately be public, and the supply is down to the point where a rationing mentality prevails. Stateless NAT64 as a feature in ROS would allow use of Mikrotik routers as the CLAT component in a 464XLAT deployment. 464XLAT is much more seamless to end users than running v6-only w/ NAT64.
Why? IPv4 literals, that's why!
If a user needs to communicate with a host using only its IPv4 address, then there's no amount of help that DNS64 can offer, and there's no way to get an IPv6-only host to even think about talking to it (without running a CLAT shim right on every host - which is NOT a reasonable requirement IMO). If the user's network is dual-stack internally, there is nothing special required for the end user devices. They can operate as dual-stack hosts without any realization that their IPv4 space is an island. The fact of the matter is that even in today's world, the IPv4 space is ALREADY an island - it's just an island of RFC1918 (private IP) space that gets translated into some public IP address before crossing the ocean of IPv4. NAT64 just changes the ocean from the fresh water of IPv4 to the salt water of IPv6, so to speak.
NAT64 not only relieves the ISP from having to supply a unique public IP address for each customer just like CGNat does, but it ALSO frees the customer from being behind double NAT. The ISP can run a centralized (or distributed) IPv4 gateway (stateful NAT64) as the PLAT portion of the 464XLAT architecture, and there NAT directly between the customer's internal private IPv4 address and the server's public IP address pool. In fact, there's no reason the PLAT even needs to be run by the ISP at all. New ISPs could go into business as pure IPv6 from day one, and simply pass the IPv4 connectivity up to an out-sourced provider. It's completely transparent to the customers - whenever they feel that they no longer need IPv4 inside their networks, they can just turn it off. Poof.
Stateless Prefix Translation
This is another NAT technology in the IPv6 world that I have come to accept, contrary to my previous "NAT is the devil in all cases" stance.
Multi-homed networks will pretty much require this kind of functionality to operate without deploying BGP. Another situation where it's useful is organizations connected to ISPs which insist on using dynamic prefix assignment. Can you imagine if your printer's IP address is always changing at the ISP's whim?
Now, I'm not as strongly in favor of prefix-translation as I am NAT64, but I do think it's a useful tool to have in the tool box. I would rather these same situations be taken care of by more forward-thinking means. For instance, the multi-home issue could be addressed just as easily with protocols like MPTCP and SCTP. If hosts would all have an address from each ISP, they could easily use these protocols to automatically load share all available Internet connections without much fancy stuff going on in the routers at all. And the dynamic prefix issue with ISPs is simply the remaining IPv4 mentality that resources must be assigned dynamically because of things like pools, over-subscribing resources, and preventing residential users from running servers. With an address space so vast, there's no reason in the world that end users couldn't receive permanent assignments of address space, and with TOS agreements, there's no reason the ISP couldn't simply block inbound connection requests for "business-class" services.
However, both of these things require a change in the common mentality of the Internet service community at large, and cannot be reasonably expected to gain any kind of traction any time soon, so in the mean time - prefix translation gives us a way to deal with them w/o waiting for the world to enlighten itself.
I know this has been an essay, but if you've read it, I hope that maybe I've helped shed some light on why NAT isn't 100% evil in the IPv6 world, while still holding to the ideal that direct end-to-end addressing should be maintained as a goal of the Internet.