One big UX mistake of IPv6: it was not made backward compatible with IPv4. (v6)0.0.192.168.1.10 == 192.168.1.10(v4).
This simple design when planning and rolling it out would have meant incrementally updating the networking stack to also support v6. Now it turns out v4 and v6 are completely different, and no one has a big enough reason to make the change until everyone else makes the change. Hard chicken-egg problem.
Backwards compatibility can not work. You can not answer an IPv6 packet with IPv4. There is no room in the header for the much bigger source/return address.
You can try to do hacks like NAT (like you probably do in your home IPv4 network, which breaks/stops any peer-2-peer protocol). The IPv6 version is called DNS64/NAT64, and it breaks even more things, e.g. DNSSEC. Because it not only requires network address translation (lying about your IP), but also rewriting DNS records (lying about signed DNS records).
The only sane way forward is get rid of IPv4 as fast as possible (even if 'fast' means a decade or two).
> You can try to do hacks like NAT (like you probably do in your home IPv4 network, which breaks/stops any peer-2-peer protocol).
That’s demonstrably untrue. Sure p2p protocols and NAT devices need to account for NAT, but to imply that they’re impossible to use with NAT is just silly. Many p2p protocols work via NAT all the time...
Sure, you can add another layer of hacks like UPnP or NAT-PMP to work around the breakage a bit. Or try to use side effects like NAT boxes waiting UDP responses when they forward such a packet. And you can spend the rest of day telling yourself this is totally fine, because it works most of the times.
Or could step back and see that this a terminally ill protocol on life support.
I don't mean it that way. Yes, on-the-wire format would have changed, maybe there would have been a required transition from v4 to v4.1, which could then have been backward compatible to v6.
To be fair, I don't think the authors of v6 at the time realized how much friction an alternative IP stack would cause.
That .1 change has __all__ of the same (and maybe a bit more) problems as the move to v6.
(Because it makes things even more complicated, now you'll have not two incompatible but about three things.)
And of course the problem is/was of economics. No incentive to change, v4 is good enough for now, for the incumbents. And even if large companies with new users were running out of v4, they can afford trading netblocks and/or carrier grade NAT devices, both are cheaper than telling others to upgrade (and you'd lose customers/subscribers otherwise).
> One big UX mistake of IPv6: it was not made backward compatible with IPv4.
The sin was committed when IPv4 was made and not initially designed to allow for variable / expanded address space -- it is not IPv6's fault.
Adding an IP Option to IPv4 packets that could carry extra address bits was not an option either -- IP options aren't preserved much at all on the Internet. Furthermore, even if most routers didn't drop IP options, adding "v6" address space via IP option in a packet that old/v4-only devices would nevertheless attempt to parse would have been hell operationally.
granted, IPv6 has lots of complexity/flaws/idiosyncrasies/weirdnesses (multicast, mobility, slaac, ndp, prettyprinting / the colons, extension headers, etc.) that mostly only look good through the rose-tinted glasses of the 90s and significantly slowed down deployment -- and in the end mostly ended up as "difference for difference's sake", but that the transition is difficult is also IPv4's fault for not having a robust address space expansion mechanism.
Ip options make it through the net/core just fine. It's generally edge networks where the ip option filtering occurs. This could be restored...so if someone wanted to suggest a backwards compatible extension to IPv4 that might be cool.
There is a straight-forward mapping of the IPv4 address space into IPv6 (you can do ping6 "::ffff:127.0.0.1"), and for new development that is also by far the easiest way to support both protocols: the application does everything in IPv6, and without writing a single line of code, the OS takes care of transparently using IPv4 when needed.
There is no mapping back from IPv6 to IPv4 (so IPv6 is backwards compatible, but not forwards compatible), but it can't be because the whole point is to have a larger address space.
With the way IP Routing works, every router on the path makes a routing decision. So two people on the "new IPv4" would be unable to talk to each other if even one router on their path doesn't understand the new format. Not to mention that to be fully compatible, you'd need a way for a person with the address "0.1.192.168.1.10" to talk to an IPv4 only client on 192.168.1.10.
Then there are switches and routers that make assumptions about incoming packets, so we can't do strange bit hacks with IPv4 packets. http://seclists.org/nanog/2016/Dec/29
Switching to a new protocol is the only real choice at this point.
One case where I found IPv6 great was on my home network. All my systems have IPv6 addresses and I can ssh into them from a remote network which also supports IPv6. I don't need any NAT. But, I do have an IPv6 firewall of course.
Except people _are_ making the change. When my ISP adopted IPv6, I just started using it. And a significant chunk of my traffic was IPv6. Backwards compatibility would have driven faster adoption, but just was too much of a technical hurdle. Dual-stack however is very possible, and is working to drive adoption. IPv6 usage is increasing. The change is happening.
This simple design when planning and rolling it out would have meant incrementally updating the networking stack to also support v6. Now it turns out v4 and v6 are completely different, and no one has a big enough reason to make the change until everyone else makes the change. Hard chicken-egg problem.