> If they used the old >bolting on top< method by extending ip4 from 4 octets to 8 (or more) octets, then old software could be extended much easier too / probably addresses could be simply mechanically translated too, so ancient software can work.

In every fucking IPv6 thread this "just add more addresses" idea comes up. There is no "just" in expanding the address space:

"""

Whether you expand the address size to 33, 64 or 128 bits, all IPv4 implementations will discard the packets. So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately:

1. You have to change the version number.

2. You have to add new code to handle the new version.

Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So,

3. You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol.

Two minutes of thought show that this third requirement has only two solutions:

(3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol.

(3B) Translation, in which something translates addresses between the old and new protocols.

This has been known for more than 30 years [RFC1671], although people still sometimes try to deny it.

"""

* https://github.com/becarpenter/book6/blob/main/01.%20Introdu...

Any IPv4+ idea that "just" adds more address bits will same issues we've faced with IPv6.

Actually no software rewrite is needed because the Berkeley Sockets API is agnostic to address format. If your software requires a particular address format, that's a bug. if you pass an IPv6 literal to getaddrinfo, you get a result with an IPv6 address structure and it tells you the IPv6 socket type you need to connect to it.

There is no space to put the additional octets. Supporting this would have needed a rewrite anyways. Nothing won there. They took that as a chance to improve the protocol overall.

Software availability isn't really the problem. For most software there was no change at all ("connect to that host" or "listen to any device" and operating system will handle details), most software which needed adaption had it for a while (picking up a devices explicitly, handling of IPv6 addressees, ...) while maybe not equally good (missing GUI improvements for better handling of IPV6 addresses)

The problems, as I observe, are more in network infrastructure, routing, etc.

I never heard this idea before, but more octets would be a lot prettier!!