> Point A: IPv6 is broken because it didn't go far enough
Alternatively, it failed because it went too far. When you have an established system which is used everywhere, it is immensely difficult to replace it.
Something like IPv4, with 64 bit addressed might have been easier to push through.
Eg, addresses like 123.123.123.123.123.123.123.123.
Because it comes with all of the drawbacks of IPv6 but also ditches some of the advantages.
You still need to update every router and application. Network admins still need to learn something new. The two protocols still don't interoperate. If you're going to go through all of that trouble why only do a half measure. IPv6 is supposed to be the final version of IP.
On the contrary, they would, the behavior's and quicks would be the same. And if we define, say, that if the last four components are zero, then the addr is the same as normal IPv4 address, then you could deploy the whole thing without having anybody assigning new addresses. NAT's/configs/etc could keep working.
The big problem with IPv6 is that everything has to be double-configured to support both IPv4 and IPv6. Two addressed for all. Different semantics. No backwards compatibility.
If you imagine that all network HW is recycled, say every decade, you could roll the thing in without having anybody to reconfigure everything. Eventually coverage would be complete. This cant happen with IPv6, because the double configuration problem. Extending vs replacement.
This is of course a pointless though experiment, because IPv6 is the route that was chosen.
The devil is in the details. All applications that use the Socket interface (which is almost everything that talks on the network) still needs to be rewritten. Firewall rules still need to support longer addresses, even if you do keep the old ones--it is basically the same situation we are in now, only the line between the networks is fuzzy and there is more confusion. You still end up with two sets of configurations for everything.
> If you're going to go through all of that trouble why only do a half measure.
Because a "half measure" would have been easier to adopt, therefore would have been more likely. The strategic error IPv6 made was, I think, taking the point of view that as long as a breaking change is necessary, then increasing the scope of that change doesn't bring greater cost.
But it does, quite a lot of it, and that greater cost is the primary reason why IPv6 adoption has suffered.
> Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123.
IPv6 supports dotted quad notation, if that is your problem with it. You can absolutely write a 128-bit IPv6 address with the last 32 bits in 123.123.123.123 notation if that makes you feel happier. ::ffff:123.123.123.123
Technically, there's nothing stopping you from building a quick library that translates 128-bit dotted quad to IPv6 addresses. Use something like 123.123.123.123.123.123.123.123.123.123.123.123.123.123.123.123 if you really want to. The 4-hex digit, colon-separated notation for IPv6 wasn't designed to make it "weirder than IPv4", but to make it easier to write/mnemonically remember than just accumulating dotted quads.
> We have jumbo frames, why not jumbo addresses?
Because there's no room. IPv4 has a fixed header size (period) and almost every field is used. IPv6 had to break compatibility in some way, no matter what, to get "jumbo addresses".
Unless I'm mistaken, I would not say it's fixed due to the rarely used IP options field that varies depending on the IHL field. It has a variable size within a range. There might be a way to get "jumbo addresses" but it would have to be terribly hacked onto the design of the header as it is, which is one reason for IPv6's existence.
My understanding of options is that many routers and/or firewalls consider it a dangerous and deprecated field and are most likely to drop packets that use them, especially when they are variably sized.
That also gets back to the point that almost all of IPv4 is too "known" as a design and every field accounted for in some router and/or firewall logic somewhere by the time IPv6 was designed.
If you think you have a better notation idea for 128-bit numbers, build your own address converter and try it?
The obvious other notations for numbers that large to compare to are the various notations people use for UUIDs/GUIDs.
I personally find IPv6's designed notations one of the easier ones to use, especially because of that :: fill with zeroes shortcut to focus on the easier separation of prefix versus suffix. (For a network you control you likely only need to remember the prefix, and then suffix is whatever numbering scheme you want to implement so it may be algorithmic and simply ordered ::1, ::2, ::3, etc. Also, the regular pattern of a colon every four hex digits versus say the strange group order of UUIDs is nice. Trying to write the notation of a UUID without software help is much more painful than IPv6 address notation, I think.) But also, I have a bit of dyscalculia (my brain catches all the individual digits in a number but not always their correct order) and hex works much better for me at remembering or visualizing long numbers.
Alternatively, it failed because it went too far. When you have an established system which is used everywhere, it is immensely difficult to replace it.
Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123.
We have jumbo frames, why not jumbo addresses?