Maybe it’s different on the software side but coming from a network VAR it’s the same skill set. You still have subnets and routes and netmasks and DHCP or automatic assignments the difference is the size. If you know IPv4 all you need to learn is “the subnets are all /64 in size, addresses are 128 bits, and you don’t need DHCP if you don’t want”.

Yeah, but I have to say, even as someone who wants IPv6 to succeed and supersede IPv4, from the perspective of building that network infrastructure software, I think this "IPv4+" would have been massively simpler to add, extremely so, and that may have aided adoption a lot.

It's really hard to overstate how much simpler tacking on 128bit IP addresses to an otherwise unmodified protocol would have been in the software stack of network infrastructure.

But, as I also said a few times here, the time to make desirable compatibility-breaking changes was exactly then, when every piece of network equipment needed massive alteration or replacement anyway. And I look forward to the day IPv6 hopefully becomes predominant, and the advantages it brings.

The majority of the problems seem to come from the fact that v6 addresses are longer than v4 ones. That's why we need socket(AF_INET6)s and AAAA records and a DNS API that supports multiple address families and dual stack and new firewalling and updates to all protocols that embed v4 addresses.

You're going to have the exact same problems with any protocol that has addresses longer than v4's.

BSD Sockets ensured that we have problems using anything other than what the software was originally written for, unless it's a program recent enough to use the one bit of API that got back ported from OSI-oriented Ed networks, the getaddressinfo() call.

Otherwise there's a ton of low level IPv4 details leaking all around the basic idea of connecting from one service to another.

I find that hard to believe. That may be true for endpoints, but I'm talking about the network infrastructure in between. There, I believe that the vast differences in the protocols on higher level (autoconfiguration, link-local addresses, temporary addresses, Neighbor Discovery as part of ICMP6 instead of ARP, ICMP6 itself, and so on and so forth) are much, much more work to implement than dealing with new DNS records and APIs, and the new struct sockaddr variants.

My point is exactly that I have a strong suspicion that the longer addresses are not the problem for slow adoption, the different network protocols and semantics are.