I think we need to start judging how good a standard is by how easy it is to implement for its intended purpose.
The purpose of IPv6 was to superscede IPv4. 25 years later, only 1/4 of the top sites from this link are IPv6 enabled. That's... well, at some point you have to stop blaming lazy sysadmins or stubborn vendors and start considering that it's genuinely just a bad and hard to understand standard.
In 2050 we'll still be on IPv4. That's how bad I think IPv6 is. Technically impressive? Sure. Viable as an understandable network paradigm and designed for widespread real-life use? Looking like no.
32bit IPv4 gives us 4.2 billion IP addresses (although there are fewer usable addresses due to reservations etc.). If we would have just tacked on another byte we'd have 1 trillion (theoretical) IP addresses. Two extra bytes and we'd have some number I don't even know the name of (~2.7e14).
Changing from 213.113.223.023 to 142.213.113.223.023 is a lot less invasive, both for users and implementations (although increasing the address space isn't necessarily easy, it doesn't require an entire new stack).
Now, these other IPv6 changes aren't necessarily bad and also address real problems as well, but it seems IPv6 changes too much in one step for its own good. In this regard, it's not that dissimilar to Python 3 (except even worse!)
Also: one think that struck me about that list is that sites who do implement IPv6 are all Western, and that none of the Asian (mostly Chinese) sites implement IPv6. You'd expect it to be the other way round because Asian/Chinese would benefit a lot more from IPv6 since they have fewer allocated addresses, and their infrastructure also tends to be newer so legacy hardware is less of a concern. I don't know what this means or why this is the case though.
Perhaps. IPv6 had more goals than just increasing the address space. Some of these goals were interdependent; for example, just increasing the address space without doing something about routing table complexity would have been a recipe for disaster, which is part of the reason why IPv6 uses much longer addresses with a fixed number of bits reserved for the local subnet, and why it also strongly discourages the non-hierarchical routing which has become commonplace in IPv4.
> Changing from 213.113.223.023 to 142.213.113.223.023 is a lot less invasive, both for users and implementations….
I would say 2602:7b:294e:d207::1 isn't much worse to remember or type than a dotted-quintet (based on, but not equal to, one of my real IPv6 addresses). Implementations don't have any issue with 128-bit addresses, and probably prefer that over an odd size like 40 bits due to alignment. Users usually don't have any reason to care about IP addresses; that's what DNS and mDNS are for. Or copy & paste if you absolutely must work with raw addresses.
> (although increasing the address space isn't necessarily easy, it doesn't require an entire new stack)
In practice, it does. You could certainly model it more closely on the original protocol, but the systems wouldn't be interoperable. System calls, library APIs, applications, and GUIs would all need to change. You'd have to rebuild all the routing hardware and redesign any protocols that embed IP addresses. Basically everything that needed to be updated to work with IPv6 would still need to be updated to work with "IPv4+1B". The changes might be smaller but it's the fact that you need to change these things at all that makes the process so difficult.
There are some other changes in IPv6 that are more debatable, like replacing DHCP with SLAAC when we could have probably just used a straightforward IPv6 adaptation of DHCPv4, at least in the beginning. SLAAC strikes me as the sort of thing that could have been deployed separately once IPv6 adoption was well underway. But I wouldn't say that these minor differences represent significant obstacles to IPv6 adoption.
It is interesting that most of Asia is trailing somewhat behind, whereas India is at the top of Akamai's charts for IPv6 adoption[0].
[0] https://www.akamai.com/visualizations/state-of-the-internet-...
What is the sales pitch you would bring to the CEO of a Fortune 500?
When you buy or merge companies, and they both have RFC 1918 addresses, you'll probably have a conflict between the two entities. You'll probably have to implement NAT with-in your own network and hope the two sides don't have to talk to each other that much. (Or you completely re-IP the acquisition.)
With IPv6, either the companies will be using their own PI IPv6 space and/or they will be using unique ULA prefixes, so the chance of conflicts will be very small.
This at least was one of the business cases for Wells Fargo, "the fourth largest bank in the United States by total assets and is one of the largest as ranked by bank deposits and market capitalization":
If an internet service needs to distinguish users by IP address, say for spam fighting reasons, then IPv6 will provide finer granularity because the addresses are not shared by multiple users. Depending on how the ISP implements CGNAT, IPv6 may also improve performance and geolocation accuracy.
(They'd also be doing those ISPs a favor, because offloading traffic to IPv6 lowers the operating costs of CGNAT.)
I love IPv6 btw. I just don't think you'll see anything meaningful happen until FAANG drop IPv4 support. Imagine that. People would convert pretty quick if Google couldn't crawl your site or you couldn't buy an iPhone without IPv6...
IPv4 addresses are expensive right now. Registries run out of new allocations years ago, so if you ask them you'll be put in a waiting list[1] hoping one for a block to be recovered. To get one right know you have to go on the market and negotiate a transfer: blocks are selling at ~50$/address right now. The price more than doubled in the last year or so: people are even speculating on it [2].
[1]: https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-pool
[2]: https://teddit.net/r/investing/comments/qdple3/i_am_planning...
https://www.internetgovernance.org/2021/08/19/a-fight-over-c...
(Although, people rent apartments with break-even periods well beyond 10 years, so maybe 2-3 is still fine.)
This has been happening for years with VPSes.
mDNS helps since you can use hostname.local without having to set up a DNS server. I was going to make a joke blog post about using ipv4 addresses as hostnames so you can "keep using ipv4" while actually using ipv6, but I found you can't have "." in hostnames, so maybe instead use "-".
[Unit]
Description=DNS-SD Proxy
After=network.target network.service
[Service]
Type=simple
DynamicUser=yes
ExecStart=/usr/local/bin/mdns-discovery-proxy.py home.arpa 35353
Restart=always
RestartSec=30
[Install]
WantedBy=multi-user.target
zone "home.arpa" {
type forward;
forward only;
forwarders { 127.0.0.1 port 35353; };
};