one is close to hundreds of millions in cost and with likeminded stakeholders. the other is hundreds of trillions in costs with the entire human population as stakeholders.

but climate change is not up to the tech industry

If you have a dedicated IPv4 address, those behind NAT and CGNAT face significant throttling and false positive blocking. It's been made worse by scraper botnets.

  https://en.wikipedia.org/wiki/End-to-end_principle

IPv4 is better than IPv6, and imperial is better than metric. I would like something to replace IPv4, but that thing shouldn't be IPv6 and probably won't be at this rate.

This is quite similar situation indeed. It was once easier to adopt the metric system when the infrastructure was not yet as developed around the previous ones.

Austria-Hungary adopted the metric system in the 1870s. Back then: no cars, no highways, no speeding laws etc. Oxen-drawn wagons in the countryside were not built to a precise spec.

Only the railway, the architects and the artillery had to really switch. Ordinary people would still ask the grocer for half a pound of ham in the 1930s.

USA in the 1970s would have to remeasure all the land communications etc., or end up with a weird hybrid like the UK.

WHat we have in IPv4 and IPv6 is the weird UK-like hybrid...

> No, backwards compatibility is competence.

Creating an IPng was always going to be complicated:

      So it's a matter of mathematical and physical fact that to expand
      the address size, you must change the protocol, and that means 
      [three] things immediately:

            You have to change the version number.

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

      […]

            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.

* https://datatracker.ietf.org/doc/html/rfc1671

For anyone curious as to the decision-making process, here are the criteria for what the IETF was looking for in an IPng:

* https://datatracker.ietf.org/doc/html/rfc1726

Here are the candidates that were floating around at the time, and the reason why the winner was chosen:

* https://datatracker.ietf.org/doc/html/rfc1752

> IPv4 is perfectly and objectively fine on internal networks. IPv6 is overkill and way too complicated for most.

Unless there's a merger/acquisition and the two companies both use 10.0.0.0.

Most home networks use 192.168, and so you can't use that in corporate environments, because the WFH people who VPN in could then have routing snags between local and remote locations.

Also, in your VPN software be sure to perhaps not use 172 addresses (like my previous job did), as some of those ranges are used by Docker by default, and so you can cause issues for developers.

But other than that IPv4 RFC 1918 is not complicated at all…

You can't selectively use IPv6 in the WAN and IPv4 in the LAN.

How would an IPv4 client send a packet to an IPv6 server? The IPv4 packet has only 4 bytes to spare for the destination address.

You can't.

Anything longer, even if it's just 1 bit, would require a new IP version.

Alternatively, IPv4 simply does not scale effectively on the LAN, whereas IPv6 allows much simpler addressing and routing topologies. Simple = good.