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?
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.
How does a device that thinks that addresses fit in a 32-bit address space send a packet to a device with a larger address?
It could possibly be known as IPv5 considering Internet Stream Protocol was never really used.
Or simply IP64.
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.
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.
https://en.wikipedia.org/wiki/Internet_Protocol_version_4#He...
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.
Even having them be 16-bit integers would've been find imo
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.