[orangeboats]

I challenge you to send a packet from 256.0.0.0 to any current IPv4 host.

"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.

[orangeboats]

To really drive the point home, representing an IPv6 address in the same way as an IPv4 address (4 dot-separated numbers) would make it look like this:

    536939960.3187088857.1487198345.2501756647
    
    (this is 2001:db8:bdf7:1dd9:58a4:d889:951d:c6e7)

You can't even squeeze that into a `sockaddr_in`.

[stonogo]

The entirety of ipv4 could have been embedded in ipv6 from the start. Instead the standards were written with no way for the two networks to interconnect, embedding ipv4 addresses into the link-local space within ipv6. This was a ridiculous decision, one of many that disincentivized adoption. ipv6 should have been designed with ease of transition from the beginning, instead of requiring dual-stack with a flag day that may never come.

[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.