The myth that it would have been easier to switch to a protocol that is just ip4 with more bits needs to die.
The companies too cheap or lazy to adopt ipv6 would still be clinging to classic ipv4 with NAT.
The companies too cheap or lazy to adopt ipv6 would still be clinging to classic ipv4 with NAT.
The difficulty is social. Everyone would have been fine with "IPV4.2", IPV4 with six octets, because it's just like something they already knew, fixing its one obvious defect, not enough addresses.
The consitituency for replacing the hardware/firmware and software stacks would have been there.
IPV6 was not just like IPV4 and so people naturally resisted the devaluation of their hard-won knowledge.
Other than already mentioned issues of hardware, you also had for years the issue of lots of applications requiring substantial rewrite to support another protocol due to use of BSD Sockets which leaked protocol internals up to application layer. It was a very big and vocal issue about porting to v6 even in early 2000s despite BSD Sockets finally getting a new API (lifted from the Streams-based XTI) that made handling dual stack easier - but everyone still learnt from older manuals.
And tricks with time table were tried - vendors would lobby for all sorts of extensions "while they work to update the code", the result was that none did because none wanted to actually put the work to upgrade network stacks and handle dual-stack in applications.
After all, IPv6 is not the first attempt to replace the "temporary" solution that was IPv4 whose planned EOL was in 1990.
Past tense? I still regularly see code that uses BSD sockets and doesn't support IPv6. Actually, I feel like among C and C++ codebases that make direct TCP or UDP connections, the majority are IPv4-only, even in 2023. Though, direct TCP and UDP connections themselves are less popular than they used to be, and so are C and C++...
Today we have getaddrinfo, so if you're writing from scratch you can just use that, you can also simplify older code with it and get v6 at the same time.
But there's a lot of old code that still doesn't use GAI and was never upgraded.
The problem is that nobody has the authority to enforce such a timetable on the Internet as a whole, so that's not actually a workable plan.
But even if that weren’t a thing, even if you did need all the routers to be replaced, “IPv4 with more bits” would still be better. After all, it’s been decades - the hardware has been replaced. If it were a seamless incremental upgrade, just a switch to flip that enabled “more bits support” and didn’t break anything, then ISPs would have enabled it even when there was little short-term benefit. By now, practically all of the Internet would support it. Instead it’s an entirely separate network, with entirely separate configuration, which historically had a high tendency to break things. No surprise that even today, many people just don’t bother with it.
The anycast gateways are only used when communicating between 6to4 and native IPv6 addresses, so if 2002::/16 had been the only IPv6 address space, then it would have been more reliable, but then we'd be stuck with IPv4-based IPv6 addresses forever.
Yep, but would that have been so bad? Certainly with IPv6's 128-bit addresses, there would still be enough space to go around…
Though admittedly, when I see "IPv4 with more bits" hypotheticals, they often involve smaller addresses than IPv6.
IPv6 still causes troubles in deployment.
For example, Android phones (still!!!) don't support stateful DHCPv6. Moreover, DHCPv6 was designed by idiots and out of many options for DUIDs it doesn't allow the most logical one: a user-specified host name.
PMTU in IPv6 is even _more_ broken than in V4 because extension headers just plain don't work in the wide Internet.
That's Google's fault, not the protocol's.