Take USB for example. The capabilities of USB 3.1, 3.0, 2.0 is impossible to achieve for USB 1.0. So is high-speed charging.
However, the end-user experience is generally pleasant, nitpicks around some of USB-IF's specific choices aside.
The "end-user experience" IPv6 equivalent of the USB version transition is that a person browsing to "www.google.com" has no clue whatsoever that it actually went via IPv6 instead of IPv4.
Just like with USB 1 to 4, IPv6 goes down the same cables and works the same at the application layer. Some changes occurred, but changes are mandatory for things to change.
You're asking for USB 4 to be magically "the same" as USB 1.0 while sending tens of gigabits over the wires -- not for the end users -- but for the lazy electrical engineers that can't be bothered to update their designs!
This is a fundamental problem. Backwards compatibility (without introducing translation schemes and middleboxes) is literally impossible.
But no, someone said we must redo whole stack and we need every piece of sand to have public routable address..so now we are stuck between rock (old fossilized IPv4) and hard place (completely incompatible IPv6).
No it is not:
* You also have to deploy new DNS code to handle a new record type to handle longer "IPv4+" addresses.
* You also have to deploy new OS and library code with new socket, etc, APIs because all in_addr_t definitions and data structures are 32-bit-only.
If a public service has a "IPv4+" address, how does a not-IPv4+ host, or not-IPv4+ compliant code handle it? If you want >4B addresses you have to tweak all the code that touches address structures. You have to (re)deploy code on all the network elements that touch the packet bits: all the end-user applications (browsers, chat clients, etc), all the end-user operating systems, all the middle-boxes, all the routers. If you have network devices and segments between the public service and the client that are not IPv4+ compliant, you have to configure the clients to send the IPv4+ traffic to translation boxes that are IPv4+ compliant.
Basically all the stuff that is happening with IPv6.
You're re-inventing IPv6.
There is also no specified way to convert USB 3 to USB 2, but some have tried, with mixed results.
Option 1: "6to4" https://en.wikipedia.org/wiki/6to4
Option 2: "nat64" https://en.wikipedia.org/wiki/NAT64 + DNS64
Option 2b: "nat46" (which makes a few ipv6 hosts available over ipv4 if yo ulike)
Option 3: "Teredo" (also known as "6in4" "tunnel broker" "6over4" "tunneling" ...) https://en.wikipedia.org/wiki/Teredo_tunneling
Option 4: 6rd https://en.wikipedia.org/wiki/IPv6_rapid_deployment
Option 5: ffff/96 (yes I get it, only works if host has both ipv4 and ipv6, on the plus side: no need for the network to support it. Mostly for applications)
Option 6: DS-lite https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual...
And then there's the weird ones: https://en.wikipedia.org/wiki/IPv6_transition_mechanism
The issue is most of these require ISPs to deploy new hardware, or deploy new network services. The problem is that network hardware is single-purpose, because only single purpose hardware can sustain the speeds we demand of internet networks. This means a lot of hardware needs to be replaced in order to make the global IPv6 transition and, short of redesigning IPv4, which is 43 years old now, there's no other way to make the transition. All these solutions require either work by your ISP, or work by you yourself on all your hosts.
Section 5.5:
CRITERION
The protocol must have a straightforward transition plan from the current IPv4. Category: Informational
Publication of this document does not imply acceptance by the IPng Area of any ideas expressed within.Clients can be IPv6 only and ideally need a CLAT installed to handle the edge case of IPv4 literals in apps that don't use DNS. The ISP's internal network can be IPv6 only. Only this NAT64 translator needs to speak both IPv6 and IPv4, and only for non-IPv6 traffic.