Fitting more than 4B numbers into 4 bytes is mathematically impossible, but building a backwards compatible and easier to integrate standard may not be.
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 USB protocols over the wire are generally not compatible between versions, especially at the lowest levels (signalling). That's the definition of how more bandwidth can be squeezed into the same wires. The signalling layer changed between versions.
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!
Extending address is fully possible, and if we drop requirement that the extended part be individually routable, even simple.
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).
> Extending address is fully possible, and if we drop requirement that the extended part be individually routable, even simple.
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 inventing a new addressing scheme, and proposing that we put a bunch of middleboxen in to mediate connecting the old world to hosts on this new addressing scheme.
No, I describe existing practice with NAT where you in fact have IP addresses extended by TCP/UDP port numbers. You could instead move this "port" directly into IP header in backward-compatible way and fall back to stateful NAT only if the counterparty does not support it.
A device that doesn't understand your newly invented addressing scheme would need to rely on some other intermediate device in order to get traffic to an endpoint that does support your new scheme.
You're using different words, but you've got a separate addressing scheme, and dependence on proxies to enable everyone to talk to each other. This is exactly where we are with IPv6.
> You could instead move this "port" directly into IP header in backward-compatible way
If you're changing the meaning of the headers, it is by definition not backwards compatible.
No, you can't: an IPv4-only device that receives that packet would interpret your extra address bytes as part of the TCP/UDP header. There simply isn't any room in the IPv4 header to squeeze extra bytes in. That is exactly why NAT baked knowledge of TCP & UDP into routers, breaking the layering design in the process. If there were any way to add extra headers to IPv4 without relying on middle boxes to support it, it would have been done a long time ago.
Not true. There is Options field to extend IPv4 header. And only server and the router closest to user would need to support such extension, keeping layering violations to minimum.
USB 3 the protocol isn't backwards compatible with USB 2, USB 3 ports just include both USB 2 and USB 3 pins (what one might call dual stack). You can easily connect two differnt devices one to the USB 2 pins and one to the USB 3 pins. If you only want to connect USB 3 devices, there is no need for USB 2 Pins, as done on the PS4.
There is also no specified way to convert USB 3 to USB 2, but some have tried, with mixed results.
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)
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.
NAT64+DNS64 is the best transition method as it eliminates the need for dual-stack.
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.
On hacker news. You're going to find a big contingent of people who are getting things like VPS/colo/dedicated/cloud hosting, only get an IPv6 address on that (or finding that an IPv4 address costs extra) ... and are occasionally finding some customers can't reach their sites without every host having an IPv4 address or paying for something like cloudflare.
So there is a bit of a demand, especially here, for forward compatibility.
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.