The world in which IPv6 was a good design (2017)

So you want all computers to be behind at least a single layer of NAT. And you also want people to not only have to purchase a domain but also have to pay their NAT operator to add their domain to the reverse proxy

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.

You can't make a backwards compatible "IPv4 with more bits" like people dream of. L2 routers and middleboxes would still need to be replaced, software would still need to be rewritten, nothing would be different. IPv4 changed how private networks worked because its first attempt at private networks failed.

People are stuck with the IPv4 mindset through a combination of lacking education (who even taught IPv6 when our current sysadmins were in college?) or assuming IPv4 is normal and well thought out. There are free guides, books, and playgrounds out there if you want to learn IPv6, so the education problem is one you can solve yourself. Realizing the flawed nature of IPv4 is harder.

I've come from IPv4 networking, but learning IPv6 later made me realize how silly old networks really are. DHCP is a hack to solve a design failure in IPv4 and SLAAC is a much better solution. Companies have started relying on awful hacks originating from when companies decided to staple features to a side effects of a generic address distribution protocol. ARP feels more like a placeholder that should've been included a layer lower or higher in the network graph, put in its own little place to solve the theoretical "what if we don't run IP over our switch" problem that stopped being relevant decades ago.

As annoying as it may be, we live in an age where the OSI model with seven layers of networking protocols don't exist. Token ring is dead, SCTP died in the womb, Ethernet II exist purely in theory. The world now runs on HTTPS on top of UDP or TCP on top of IPv6/4, on top of some kind of wire that carries ethernet.

Ethernet now exists to support IP and vice versa in 99% of all use cases. TCP and UDP exist to serve HTTPS, or some legacy protocol that will be rewritten into HTTPS in the next ten years. WiFi and high-speed data networks came in as a whole new networking system and have turned out to be "what if ethernet, but wireless" with some control logic to make the wireless antennae talk. The OSI model and all the expansion and flexibility it provided simply died over a decade ago. Anything on top of the data link exists purely to support Ethernet + IP + HTTPS.

The migration path to IPv6 is now blocked by excuses. People pretended to care about servers not supporting IPv6 as the reason not to use but, but three or four different ways of providing backwards compatibility to all IPv4 clients were thought up and nobody actually asked for any of them. People complained that their data center provider didn't support IPv6 but now that enabling IPv6 is just a single click in a web UI they don't enable it anyway. People cared about the IPv6 privacy risks but never let go of that concept even after rfc4941 fixed that oversight. Companies like Microsoft and Github, too incompetent to set up a network that their dollar store competitors have supported for years now, have become something to point at and go "see? we need those!" as if NAT64/DNS64/464XLAT/SIIT/whatever haven't been providing IPv4 compatibility for years now.

"I don't know enough about it" and "I don't like it" are perfectly good excuses not to enable IPv6 in your home network, but they're not design flaws or protocol problems. If you're willing to accept the packet maiming we have nicknamed "NAT" or even "CG-NAT", you should feel refreshed at the sight of the plain and simple protocols IPv6 provides you with.

The way people talk about IPv6 now reminds me of the way people talked about HTTPS back when Let's Encrypt started gaining popularity, and the way people dealt with systemd reinventing a better Linux management system. Grumpy people, clinging to what they know, delaying unavoidable change until the very last moment. You can be like the Dracut people running ipromiseiwillneverrunssl.com if you want, but it's a losing battle.

While one can say that there's no way that IPv4 demand can ever be "satisfied" (which seems right to me), one can also imagine a different quantity demanded at $0.50/address than at $0.00/address, and also different levels of effort to make sure that almost all addresses that are allocated get put into use on the Internet. (I know $0.00/address isn't exactly the right way to describe what RIR allocations cost, but economically they've been more similar to the "beauty contest" than the "auction" allocation method.)

In the final direct initial allocation phase, people learned that something (with substantial economic value that can likely be sold in the future, no less!) was very scarce, and was being given out nearly at no cost for almost the last time. It's not surprising that they would have jumped at the opportunity to get as much of it as they could qualify for, somewhat independent of what use they expected to make of it in the short term. Maybe especially when they were hearing how other people were jumping at that opportunity.

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.