1) As far as I know, nobody ever wrote down a protocol description, and preferably made an implementation. The devil is in the details. It is very hard to estimate if such a design would actually work.
2) At the moment, the core of the internet and just about all host operating system support IPv6. The hard part is getting the edge networks to upgrade. My guess is that your proposal would run into similar issues.
There are a number of proposals that build on these ideas, for example EnhancedIP. Typically, they would encode the extended addressing info in an options field. They were to late the party and missed the circa 2000-2005 window where it became clear Ipv6 will be an uphill struggle. Back in the day, only naive proposals like ipv7 existed, "ipv4 with larger address" but that solves little.
The fundamental difference compared to dual stack is that there is no technical cost to deploy it outside software updates and very little risk - aside from the dubious security benefits of NAT. Not only the core, but virtually all hardware and software on the Internet today support ipv6, but there is an enormous cost to configure it to work.
This flexibility and drop in upgradability of things like EnhancedIP comes with the significant cost of breaking the internet into 2^32 independent routing domains that prevent you for getting the full benefits of the larger address format. This is an acceptable trade off only in retrospect, after the v6 "failure".
There is a large cost to configure IPv6 because most operators have ignored IPv6, waiting for the IETF to magically get it right.
There is very little consensus within the operator community on how to deploy IPv6. The net effect is that there is an endless series of configuration options.
Which leads to having to select equipment very carefully to make sure you get an overlapping feature set.
The problem with something like encoding extra address bits in IPv4 options is that you would have to get a large group of operators on board for it to get any traction.
For example, the ISP that I use for my home internet connection give customers a static (officially 'stable') IPv4 address. It may not be beneficial for them if a next generation internet protocol would force the deployment of NAT boxes.
The downside of dual stack is that you have to manage 2 networks. The benefit it that you manage two completely separate networks. IPv4 routing has very little effect on IPv6 routing.
Merging the two, as is done for example with NAT64/DNS64, leads to network issues that many people don't understand. I think you would get the same if you mix legacy IPv4 stacks with stacks that encode extra bits in an IPv4 header option.
This is of course completely ignoring the fact that many firewalls just drop anything that has IPv4 options. So deployment may be just as an uphill battle as IPv6.
> The problem with something like encoding extra address bits in IPv4 options is that you would have to get a large group of operators on board for it to get any traction.
Sure that's why you have things like IETF, to coordinate such changes. If that were to happen, the EnhancedIP option would quickly become transparent, as the core of the internet upgrades firmware in a few years. I'm not in any way proposing this to be a good idea today, let alone that it could be deployed in ad-hoc uncoordinated fashion.
> my home internet connection give customers a static (officially 'stable') IPv4 address. It may not be beneficial for them if a next generation internet protocol would force the deployment of NAT boxes.
In that case you become the owner of your own routing domain and you have the option to provide your "customers" with an extended IP address that is e2e reachable from the outside world, while NATing the rest of the legacy devices. Your ISP does not have to do anything aside from not filtering options, that's the beauty of a backwards compatible solution.
> Merging the two, as is done for example with NAT64/DNS64, leads to network issues that many people don't understand.
The complexity and fragility of something like NAT64 comes exactly from the fact that it tries to bridge two separate internets. An EnhancedIP NAT is simply a transparent router for EnhancedIP aware endpoints within the domain it controls. You can freely mix legacy and upgraded devices in your network with guaranteed interoperability and you get e2e connectivity if both end points and any NATs in the route are upgraded. The rest of the network only "sees" IPv4 traffic as far as they are concerned.
1) As far as I know, nobody ever wrote down a protocol description, and preferably made an implementation. The devil is in the details. It is very hard to estimate if such a design would actually work.
2) At the moment, the core of the internet and just about all host operating system support IPv6. The hard part is getting the edge networks to upgrade. My guess is that your proposal would run into similar issues.