> Problem with ULA is that it's functionally useless on a dual-stack network.

Nope, it works just fine. I use it for stable local addressing and LAN host AAAA records and let my ISP-delegated global prefix drift as my ISP wishes it to.

And -as it happens- the prose in that article about source address selection is incorrect.

On Linux, source address preference appears to be application-specific. For example, curl prefers IPv6 addresses, and falls back to IPv4 if the v6 connection fails. I checked just now by removing my globally-assigned IPv6 address, and capturing the traffic created by executing 'curl https://www.google.com'. I know for a fact that BIND 9 prefers non-link-local IPv6 source addresses over IPv4 addresses because until I set up my home-built router to reject Internet-bound traffic coming from my ULA, a sufficiently-long failure of the DHCPv6 server run by my ISP would cause name resolution to get very, very, very slow when the global prefix expired and BIND started using its host's ULA as a source address and my router dutifully relayed that traffic into my ISP's black hole. I'm certain that very many applications unconditionally prefer non-link-local IPv6 addresses over IPv4 ones. You might also care to pay attention to this comment and its publication date: [0]

OTOH, Firefox prefers IPv4 connections in that scenario and doesn't even attempt a v6 connection. I assume Chrome is the same way.

And, that article suggests GUA space as a replacement for ULA space:

> All of these are serious pitfalls that arise when attempting to use ULA. The simple and more elegant answer is to simply leverage GUAs.

Which... uh... no. I'd have to go through my local RIR to get an allocation, and then negotiate with my ISP to get it routed. Given that I'd have to go through ARIN because I'm in the US, and I have a boring residential account with my ISP, neither of those things will ever happen. The entire point of ULA is that no coordination with external entities is required to do network-local addressing.

Also, the documentation that that article links to to discourage people from deploying NAT66 is almost literally "It's exactly as complicated as NAT44. Why do it when you can get global IPv6 addresses?!?", which isn't a useful complaint when your intent is to exactly replicate what you get from IPv4 NAT in an IPv6 world. I agree that globally-routable addresses are better, but if your site admin demands (for whatever reason) that you not have them, then -because of the collision-avoidance property of the ULA prefix generation procedure- you're better off than with IPv4 NAT.

[0] <https://blog.apnic.net/2022/05/16/ula-is-broken-in-dual-stac...>