I understand what you're saying, but isn't IP supposed to be about routing things around failure points? So routers that "know" IP 4.4 would "know" what routers aren't 4.4.
By definition you’re trying to retain back compat. So you have a 4.4 source IP address. You try to establish a TCP connection to a legacy IPv4 website that isn’t 4.4 aware. What address is that website sending the response back to? Even if it is 4.4 aware, how do you guarantee it’s taking a path back through 4.4 aware servers? The whole point of adding an option header is to allow unmolested transit through existing IP stacks. If you’re saying you’re routing around them, then you’ve bifurcated the networks and you’re back to IPv6.
You're basically doing carrier grade NAT for that, the same thing that is apparently tooootallly acceptable to the ipv6 people for their big success story: mobile.
The only success story of ipv6 leads us to the solution: backbone-level CGNAT and other hacks, then impose the economic cost on IPV4-only carriers and endusers.
Indeed, your system would require NAT4.44 as a transition mechanism, just like NAT64 is needed now. It gets no benefit over IPv6, and none of the other benefits like SLAAC.
So, what's the point? It's no easier to migrate to, and once we're migrated is worse.
If a source behind an IP4.4 router sent a packet to an IP4 destination, then yes, the source router would need to apply NAT to the source address. But this is already a standard IP4 router capability, and I think that most connection origins on the internet are already behind a NAT.
I don't agree that it wouldn't have been easier to migrate. No changes would have been needed within retail ISPs for starters. Source code changes to existing IP4 stacks would have been minimal, without requiring a whole new stack like IP6. Practical migration requires only that the source and destination networks be IP4.4 aware.
The idea might make less and less sense over time, but if we'd done this 20 years ago we would have reliably had all the address space we needed 10 years ago, no further transition necessary. So much money spent on IP6 could have been saved, not to mention the opportunity cost of IP4 space being hard to get in recent years.
How would changes not have been required in the ISPs? An IPv4 router wouldn't know what to do with a 4.4 packet. At best, it'd route it to the wrong place - 1.2.3.4.5.6.7.8 and 5.6.7.8 are totally different hosts that may well not even be on the same continent.
Additionally, the only reason so much code had to change for ipv6 is that Berkley sockets is a terrible, terrible API that has abstractions so leaky they might as well not exist. Sure, in other APIs (what few exist) low-level code had to be rewritten somewhat, but that's going to be true for any protocol change, because that's kinda what change means.
I think you have missed that a IP4.4 packet would be a valid IP4 packet. The first 4 octets of the 4.4 address are where IP4 expects them to be. The router at this IP4 address needs to understand IP4.4, but routers before do not. The additional octets are smuggled within the IP4 options header.
I didn't claim it to be a new idea - I asked why we didn't do something simple like that (as the solution) instead of all the expensive complexity of trying to upgrade the entire Internet to IP6 over multiple decades.
That was my point: we did. It turns out people prefer to deploy v6 natively.
(Also, I don't think it's fair to call it simple. Many of the things we've done to deploy v6 are things which need to be done to deploy any IP protocol with bigger addresses than v4. If you count those things against v6 while ignoring them for any alternative, you aren't doing a fair comparison.)
