As those unique "fresh" addresses would have to come from some shared routable prefix (which is the core problem with the various IPv6 randomized address soluti

As those unique "fresh" addresses would have to come from some shared routable prefix (which is the core problem with the various IPv6 randomized address solutions), that would still provide strictly worse privacy than NAT: if you happened to be one machine before you are now outing to the world the connection correlations between your tabs, and if you were multiple machines before you are now separating the traffic from the multiple users; meanwhile, no one thinks you are a large number of unrelated addresses (as no one is dumb enough to be tricked by your supposedly-separate addresses that all share the same prefix). FWIW, one can totally implement NAT for IPv6, and in fact people have: everyone should always use NAT. NAT is the correct solution to this problem, whether you are mixing your traffic locally on your own network or are shifting your traffic through remote mixers (which is effectively what Orchid--the open source decentralized privacy network I work on, funded by some major VCs--does, though it frankly isn't there yet with "#privacy" despite having launched a long time ago and being usable today; btw: I haven't finished implementing this yet, but "use a separate circuit for each target host", which I think best achieves your dream of an address per tab, is one of the features I have been intending to have in Orchid for forever ;P). (It makes sense for me to attach this to this comment, but I appreciate I am likely preaching the choir with respect to responding to you ;P.) The downsides people like to whine about for NAT involving peer-to-peer connections and hole punching are either misunderstandings (people often like to claim things don't work that do), are caused by shitty NAT implementations (that ignore the RFC recommendations on NAT), or were fixed by PCP/NAT-PMP (which is the technology everyone should be implementing support for in their software stacks, not IPv6). (With respect to the attack in this article, this isn't an attack on NAT per se: it is an attack on these "application level gateways", which I frankly had always assumed were a "crazy" Linux IPMASQ feature, not something people were using in production. I appreciate why people are doing this: no one integrates PCP/NAT-PMP, and there exist older notably unencrypted and thereby already somewhat unfortunate protocols--such as FTP and SIP--that have port allocation assumptions that the router is trying to fix with heuristics. This mechanism doesn't work if the traffic is encrypted anyway--and all of these protocols support encryption as of 15 years ago, and a lot of users actually did switch--so I will claim these features should not be deployed: developers should use PCP/NAT-PMP in their clients or we should potentially integrate it into their operating systems, and not pretend that ALGs are much more than a dangerous MITM attack.)