Is there any alternative approach that would be more effective?
https://en.wikipedia.org/wiki/Second-system_effect
Even the use of colons in the textual IP address notation is moronic. The colon is already used in a notation for port numbers: 1.2.3.4:567. Under IPv6, you have to use square brackets around the address if it is followed by colon-delimited port number. Ugh!
A 64 bit extension to IP can just use a four-part dotted address, where the parts are 16 bit decimals. Or perhaps an 8 part dotted address. A range of zeros can be two consecutive dots: 10..1 would be 10.0.0.0.0.0.0.1.
We might as well take advantage of a compatibility breaking upgrade to fit in all of the other upgrades.
Replacing inaddr_t with inaddr6_t is trivial, and does not require any significant effort at all.
Replacing everything else is hard. My house is on IPv4 and will be on IPv4 for foreseeable future, because all of my setup (filtering, metering, monitoring, fixed IP assignment) is completely unusable in the new IPv6 world with privacy extensions where addresses are not only random, but change constantly.
If you want predicatable addressing, you can always forego privacy extensions and use EUI64-style interface identifiers.
This is not an insolvable problem. I can write another daemon to keep the history of IP<->Mac associations, change my accounting scripts to look the matching MAC, change the firewall to filter based on mac address, and so on -- but it is a lot of work, and no benefits.
The NAT is not a problem at my home network, generic openwrt router has enough CPU power for my bandwidth. Direct addressing for each device is useless, as I would still have to list every port and every device I want to expose -- even if NAT goes away, the firewall with default-deny incoming policy stays.
This, IMHO, is the biggest problem with IPv6 adoption. If this was only "recompile the problem and change IP address regex", then we would be done ages ago. Instead, it just got strictly worse for most small network owners.
These are the shoals that so many projects have foundered upon.
People bought new routers, for example, because of faster ethernet and fibre. Faster switching, more ports. Bigger routing tables. At the last hop, also due to Wi-Fi and rounds of newer Wi-Fi.
A smart upgrade to IP could have been hammered out by a team of half a dozen skilled engineers well before Y2K rolled in.
As a result, we end up with several generations of hardware that support everything necessary but where the people who wrote the config for them are too lazy to actually turn it on.