[orangeboats]

Did you just ignore my comment before making this reply? I already explained why it makes no sense to interconnect those two protocols, when one of them is destined to be unable to speak with the other.

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.

[stonogo]

That 'one of them is destined to be unable to speak with the other' is true no matter what you do, but my point (which I here note that you seem to have ignored) is that with the method of implementation selected, there is no reason to give a shit about ipv6 unless you're a network operator, and network operators don't write client or server software. ipv6 is still a ghetto for this reason. Forcing them into one stack would have resulted in application developers having to address this or face their software stop working. Breaking ipv4 should have been the point.

[orangeboats]

> Forcing them into one stack would have resulted in application developers having to address this or face their software stop working

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.