I also appreciated how much the linked article is adamant that IPv6 is what you get when all you do is increase the addressing size. There were wilder alternatives discussed that broke more things or took a more progressive stance. Part of the "there's no compelling 'use case' for IPv6" is that it really doesn't do anything new or exciting, it just increased the address size, and then dealt with the consequences (including "lack of backward compatibility", that was always going to be a consequence of increasing the address size).

It could work like 4 socks requests wrapped in each other like onion. But LAN services wouldn't need to care about long addressing as they don't need to cross network boundary, while letting everything else use new approach, so you could use old stuff without changing anything and there would be no need for new ip6 drivers with new vulnerabilities that are yet to be fixed.

There have been tunneling protocols and systems for IPv6 since nearly the beginning of IPv6. The ability to tunnel it hasn't solved all the "backwards compatibility" complaints for IPv6.

Same for network address translation, both NAT46 and NAT64 standards have existed for a while now and that also hasn't solved the "backwards compatibility" complaints for IPv6.

Presumably NAT46 still requires most things like middle boxes to upgrade to ipv6, and also somehow needs to squeeze ipv6 addresses into ipv4 addresses, which is only a temporary solution at best.

If addressing is two layer, e.g. NAT is 1.1.1.1 and everything behind it is in 10.0.0.0/8 network (cloudflare could use this scheme while having only one top level address), then you can use existing socks support without any new hardware or software.

My understanding is NAT46 is very nearly the same as NAT44 ("traditional NAT" between IPv4 and IPv4), using tricks like (but sometimes different from) SOCKS and UPnP and fake port numbers to accept incoming connections for one (or more) IPv4 addresses to pretend to be/delegate to some number of IPv6 consumers behind it. It doesn't solve general routing of any IPv6 address, just specific addresses routing via an IPv4 proxy.

To my understanding, the difference between NAT44 and NAT46 is really hard to spot in practice and somewhat "just" a distinction of whether or not the NAT in question thinks of its IPv6 subnet or IPv4 subnet as "primary". I've heard some major consumer-side routers quietly upgraded to NAT46 as "primary" because it does lend itself to better consumer experiences. Also I've heard some CGNAT (Carrier Grade NAT) is easier to build when considered as NAT46 than NAT44 (as awful as CGNAT is as a general thing).

NAT46 is absolutely a standard designed to be a temporary solution. It's just about the exact same ugly temporary solution as NAT44. (Or at least as NAT44 was supposed to be. The continued confusion of NAT44 as a security measure will probably keep NAT44 still in use long after its problem disappears and its temporary transition window has expired.)

(NAT64 is the interesting one that may not be as temporary as networks move to IPv6-only single stacks. Some cell carriers have already moved in that direction.)

NAT44 translates only client addresses, leaving server addresses intact, NAT46 has to translate both client and server addresses, which can be taxing if there are more servers than clients behind NAT, which is further exacerbated by server farms as each domain now has several addresses. Well, if clients connect only to facebook and google, that's only two addresses to translate.

I don't think you can use port numbers to disambiguate between servers as clients will connect to port 443 for https.

But no v4 devices support this "four socks requests wrapped like an onion" thing you're proposing, so how would they work with it?

Socks goes on application layer, hardware sees it as normal tcp/ip4.

Applications don't support it either, and if the hardware is seeing normal v4 then you're limited to sending to v4 destinations. How is this helping?

It would help everything else, applications are not the only part of the network (and many already support socks), there are middle boxes, DHCP, NAT, firewalls, reverse proxies, LAN services and what not that don't need to be aware of new addressing scheme. Firewalls might benefit from it, but even they would still mostly work, even if with less than perfect precision. And even applications can benefit from simplification due to absence of dual mode sockets and no need for two sockets to listen on 0.0.0.0 and [::].

Many already support SOCKS, but not this 4-layer thing you're suggesting. How can a device, application, whatever that doesn't have support for this use it to handle longer addresses? How can it communicate with a remote node that doesn't have support? How can that remote node communicate back?

If you just want to transport v6 over an existing v4 network there are already approaches to do that in v6.