The purpose of a network is to allow any two consenting parties to communicate. IPv4 cannot deliver that if either party has an RFC1918 address. NAT is a foul perversion of this foundational principle of the Internet Protocol.

On your *internal* network e.g the thing between your postgres VM and your webserver (or whatever). Not arguing against it on the public/wan connection.

There is no such thing as an 'internal' network.

For a lot of use cases a major advantage of IPv6 is to get away from ambiguous rfc1918 addressing.

You can then just put an allow rule between arbitrary v6 addresses anywhere on the internet when you need connectivity without any other hacks like proxies, NAT, etc and the associated complexity and addressing ambiguity/context dependence of rfc1918 addresses.

So fex you can just curl or ssh to your mycontainer.mydomain.net or you can put an allow rule from mycontainer.mydomain.net to a vm or laptop on your home network.

Internetworking, they call it.

I'm talking about an internal network, not the public connection.

The context in the GP comment was generally getting v6 connectivity for containers.

"Internal" is a context dependent term that you introduced. But to give a use case for that, for example you might want to have (maybe at a future date) two hosts on your networks on AWS and Hetzner talk to each other, still without allowing public connectivity.

The benefit of IPv6 is that I don’t need an “internal” network. Everything is on the Internet and the firewall is the only thing that gets in the way.