What is your solution?
Understand very little about the problem space and complain about the best-compromise solution that the people who do know what they're talking about came up with. It's a very comfortable position to be in, I recommend it to everyone.
Things look fine to me, the reality is dual stack, a full ipv6 transition is idyllic and pointless.
I'm certainly not the first ipv6 critic, and you may notice the nuance that I didn't advocate for not using it, I just don't advocate dropping ipv4. Furthermore it doesn't matter if I advocate it or not, like a train ipv4 keeps going, it's only ipv6 that is advocated.
IPv10. The next IP version number that is unassigned, that is conveniently 4+6.
Basically something that is not breaking compatibility with IPv4 and doesn’t require those dual network stacks nonsense.
> perhaps we could look at the 240.0.0.0/4 reserved for future use block
What's the current rate of v4 address space consumption? How long will this block last?
> and add more address bytes in the payload or something.
This is, by definition, not backward compatible.
See my suggestion as some kind of NAT-PT at scale. With a better marketing name and user experience.
The problem is indeed hard because no one manage to find a solution at scale since 3 decades.
The problem is hard because despite everyone's wishes, it's got nothing to do with technology. All migrations are about economics and incentives, IPv6's qualities as a design (it's a long, long way from perfect, but I'd argue that it's good enough) are irrelevant.
This is a fundamental and unresolvable problem with "making it backwards compatible"
>if you are making more than 4B addresses routable then any existing IPv4 device will not be able to route some addresses, so you will have caused a split in the internet
This has basically already happened. We've massively extended IPv4 by stuffing extra address bits into the router's port number, and it means that any two devices behind NATs can't directly route to each other.
Not being able to route directly doesn’t seem to be a major issue to me. It for sure require more computing power in routers but also adds some safety and privacy by design.
Look at the bigger world around you.
I am, right now, involved in a major cloud migration. Having overlapping, constrained RFC1918 space and also having to NAT everything is presenting an enormous set of constraints and risks. It adds literally zero benefit.
Life would be infinitely easier, and we could provide so many more capabilities if everything could just have a routable IP address. Unfortunately, I'm not in charge of our addressing policy.
NAT is an awful, short-sighted hack that causes many more problems than it solves.
Of course, we could extend the address space by further breaking the layering of routes, and baking in support for higher layer protocols into routers. We can certainly stuff more address information in HTTP headers, so the web could be extended to essentially arbitrary size by simply requiring routers to look not just at source and destination IPs and source/dest TCP/UDP port numbers, but also client and server HTTP headers. SIP looks a lot like HTTP, so the same solution could work there. TLS already has support for additional headers, so we could also do extra NAT at that layer.
Hell, AWS could then use a single IPv4, and just rely on HTTP/SIP headers or TLS extension headers to know the actual destination! Of course, if you want to run another L7 protocol, tough luck - tunneling it is for you.
If I had to guess the futur, the industry will most likely go towards something like few expensive IPv4 owned by major cloud and internet providers and crazy recursive NAT setups everywhere. Because that works without breaking stuff.
Then it's not IPv4 and is not compatible with IPv4.