"But IPv4 only ranges from 0.0.0.0 to 255.255.255.255"? Then congratulations on getting the point - it's pretty much guaranteed that any IPvNext address will have more bits than IPv4, therefore any IPvNext protocol is pretty much guaranteed to be backwards incompatible with IPv4.
IPv4 hosts simply cannot accept a packet nor send back a reply to IPvNext hosts, unless you rely on a middleman that does the translation between the two worlds.
536939960.3187088857.1487198345.2501756647
(this is 2001:db8:bdf7:1dd9:58a4:d889:951d:c6e7)
Furthermore, depending on your definition of "embedding" you can pretty much already do that now. [::ffff:192.168.0.1] gives you the ability to use a socket for both IPv4 and IPv6 connections. [64:ff9b::192.168.0.1] facilitates the translation from IPv6 to IPv4.
And what would be your solution for achieving that? Given the distributed nature of the web, it's hard to see how one can force other people to do something. They will just ignore this IPvForced6 just like how they ignored IPv6 (until they see the IPv4 address bills arriving).
Furthermore, "easing the transition to IPv6" isn't plausible IMO no matter how much you do. Just the mere fact that IPv6 addresses are larger than IPv4 addresses already set that in stone, since it necessitates the upgrade of software and hardware - and good luck convincing the programmers and netengs to update those.
https://twitter.com/BingSwenSun/status/1738513794933182671
What's notable is that IPswen is bidirectionally compatible with IPv4, meaning the two can interwork when the addresses are limited in the "Base Address Space" (the level 0 subspace of IPswen), much like the back and forward compatibility between color TV vs. black-and-white TV, or monophonic broadcasting vs. stereo broadcasting.
IPswen is a relatively new idea and still under development. As the history of networking and communications is replete with failures and technological disasters, it may be quite interesting to see how far it will actually go...
“Curse you for not magically squeezing more than 4 billion addresses into 32 bits! Curse you!”
https://web.archive.org/web/20021017164820/http://cr.yp.to/p...
It's a bit long-winded, but the essential argument is that IPv6 introduces a breaking change by definition -- more addresses than IPv4 supported. That's the point. Either you abandon this benefit, or break direct compatibility with IPv4. It's possible to proxy, or tunnel over IPv4, and there a few corner cases that "might" work, but the general case simply cannot.
E.g.: If you support IPv6 -> IPv4 translation, then this must occur either in the host, or on the first-hop router, which must also become highly stateful so that it can return the traffic to the correct IPv6 host. This essentially means that you have IPv4 + IPv6 coexisting side-by-side either on the host or its immediate upstream. This is literally dual-stack! That's why this is the solution that has been adopted by the industry. It works. Everything else doesn't.
Whatever else you're about to suggest has a counter-example where it just won't work. There aren't two toy hosts on the Internet, there are billions. There aren't a couple of routers under your control, there are hundreds of millions, most of which are replaced infrequently.
Solutions for migrations must cater for every bizarre scenario, not just simplified ones required to make that solution work.
Solutions must not require highly stateful routers, because at telco scale, that just doesn't work.
Etc...
These ideas have been discussed at length by experts in the field, and have been shot down decades ago.
Also, the link I posted doesn't involve highly stateful routers. It's talking about getting IPv4 clients that is IPv6 aware being able to IPv6 hosts without the involvement of an IPv6 gateway aside from Anycast gateway that could be outside of the balliwick of the client. Something tells me you don't understand what was being proposed.