[akersten]

> it really is quite a good standard,

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.

[nybble41]

It's not that IPv6 is bad. There are no other, more successful alternative proposals to grow the address space while maintaining end-to-end connectivity. It's just a difficult coordination problem. From a purely technical point of view IPv6 works, today. It's not hard to set up IPv6 networks and connect them together. But there is a lot of IPv4-only equipment, legacy applications, etc. in active use which would have problems with any new protocol.

[arp242]

Not wrong, but I have a feeling that a protocol which changed things less would have caught on a lot faster. IPv6 changes a lot more than just expanding the address space.

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.

[nybble41]

> I have a feeling that a protocol which changed things less would have caught on a lot faster.

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-...