Yeah, it's fascinating here that they've gone from "NAT is bad and we won't let you implement NAT, we need an internet on a single flat 128-bit address space" to "The internet will be IPv4 forever and you should implement IPv6 internally and run NAT, because we like it better than running IPv4 NAT which is what you've done for years and works great".

That's not what the article is saying. They're saying that you still need to provide access to legacy v4-only hosts on the internet somehow, and you either do that via v4 (i.e. dual stack) or by some transition technology of which NAT64 is just one possible option.

Nobody is suggesting to not talk native v6 to the internet too, they're just suggesting to not cut your users off from v4-only services.

If all your connections are potentially NATted (i.e., any DNS lookup might only return an IPv4 record), what's the advantage? You still have to build applications that are capable of dealing with NATs / non-end-to-end connections. You just also have to maintain IPv6 infrastructure. That seems strictly worse than staying on IPv4 NAT.

(If you're talking to specific parties that you know have working IPv6, it's less work to run a site-to-site VPN than to both maintain working IPv6.)

The only world in which IPv6 is worthwhile is one in which we can turn off access to legacy v4 hosts and stop having public IPv4 addresses. At this point, it seems like there is no hope of doing so in the current Internet. Perhaps in a few hundred years the Internet itself will be dead and IPv4 will die with it, but not before then.

No. The idea goes like this:

You throw away IPv4 internally. Nothing internally is IPv4. All your network address sizing issues vanish, puff, gone, because in IPv6 the subnets are always 64-bits, which means whether it's four boxes or four million boxes it fits in the same subnet. No more NAT, you just use real (globally unique) IPv6 addresses for everything, so there are no confusing debug sessions where you thought 10.4.5.6 was this box but actually because of how routing is set up it's _that_ box and so you wasted six hours.

So internally everything is _wonderful_

And then to manage the fact that some fraction of the Internet is (and for the foreseeable future will be) IPv4 only, you have edge devices that translate. They translate DNS too. If you ask for www.example.com and the answer is A 10.20.30.40 the edge devices wrap that inside an IPv6 address and provides that as your AAAA answer.

_This_ way around works, because 128 is bigger than 32. Unlike the people who magically want an IPv6 that hides 128-bits in 32-bits, which is mathematically impossible, this merely hides 32-bits in 128-bits, which is trivial.

Anyway, nothing else needs to even care, just those edge devices, and as transition continues you spend less and less money on them. In reality at any modern company you probably already spend more on edge devices you've added because somebody read about them in a magazine - anti-malware, service protection, next generation firewalls, that sort of thing.

The advantage is that you can be behind a dozen layers of NAT on the v4 side and it doesn't matter so much because 99% of your traffic is going over v6 anyway and anything that needs an inbound connection has the v6 available instead of being impossible. It's okay for v4 to suck if you can avoid it most of the time, but not so much when it's your only option.

Maintaining v6 is a lot less work than site-to-site VPNs, especially when "specific parties" is "random internet users" and when RFC1918 clashes are a thing.

v6 is worthwhile even if there is still some v4 going on. And even if it wasn't, how would you propose to deploy v6 and turn off v4 in one internet-wide atomic operation? There's no longer any entity that can enforce a flag day on the internet, so I can't see any way of doing that. The result is that we'd need to do a gradual changeover, which happens to be exactly what we are doing.