Fast forward 15 years snd the situation has improved quite dramatically.
IPv6 has some quirks that make it harder to digest.
- link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space
- privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer
- multicast instead of broadcast
- way too many ways for autoconfiguration (SLAAC, DHCPv6)
- no real tentative mapping to what people were used to. Every IPv6 presentation I did had to start with “forget everything you know about IPv4”
In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”. Those people love their NAT.
I don't know anything about the IPv6 situation, but the way this paragraph just slots in so innocently foreshadows some long wordy Wayland retrospective document on why adoption was so slow where someone from deep in the community slips in 1 short "sure we tried to block screenshots and that might have caused some issues with adoption for some users" paragraph in the middle-end. The innocence of the admission is so mild and context-free that it somehow manages to make itself look guilty.
For example, the IPv6 packet structure [0] is much simpler than the IPv4 packet structure [1]; SLAAC [2] is much simpler than DHCPv4 [3]; IPv6 multicast [4] is much simpler than IGMP [5]; IPv6's lack of NAT simplifies peer-to-peer networking compared to IPv4; ULAs [6] prevent the annoying address conflicts you get with IPv4 [7]; etc.
[0]: https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header
[1]: https://en.wikipedia.org/wiki/IPv4#Packet_structure
[2]: https://en.wikipedia.org/wiki/IPv6_address#Stateless_address...
[3]: https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Pro...
[4]: https://en.wikipedia.org/wiki/IPv6#Multicasting
[5]: https://en.wikipedia.org/wiki/Internet_Group_Management_Prot...
There was a time when most devices had 1 network interface and didn't move. But that was never a guarantee. People thought it was a guarantee when your $400-in-1988-dollars Madge ISA full-height full-width token-ring NICs with dangling AUI dongles next to your tank of an ST225 hard drive were a thing, but we're past that. Today most things that aren't servers have at least 2 - wired/Wi-Fi for laptops, Wi-Fi/cellular for phones. You can talk about NAT and security and mapping all you want, but if I can bypass your corporate internal network security simply by turning off my phone's Wi-Fi, yet still get to your resources - then NAT is a legacy chore that IPv6 makes unnecessary.
Which also allowed for better route aggregation in the core BGP tables.
Better node mobility support. Better multicast support. Genuine link local addresses.
IPv4 had a lot of unfortunate edge cases. I think IPv6's greatest strength and also responsible for it's slow rollout was it's insistence on solving several of these problems at once, along with IPSec as the article notes, and hammering them into the hard requirements for the core stack.
inb4 no you can't have all lan devices have multiple ipv6 addresses and choose for themselves, typically 1 WAN is cheap and the second WAN is expensive/slow and should be used only for WAN1 failover
Inb4 no you can't just advertise new RA, devices on lan can takes minutes to update.
On ipv4, NAT+changing route on router just works, 1-2 seconds failover.
https://stats.labs.apnic.net/ipv6/in
They report nearly a billion users, predominantly in mobile.
So, "only" 750 to 800 million users. Think about that: 3x the population of the USA using it most of the time, in one economy.
Here's the rankings:
https://stats.labs.apnic.net/ipv6/XA?o=cINw30x1r1
This is a different measure to Google's. They measure different things,
> Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in {{RFC3513}} but deprecated by {{RFC4291}} because it turned out to be of no practical use for coexistence or transition.
Why/how did it turn out?
IPv4 addresses in logs are not super helpful in tracking a specific person and household’s behavior long term (NAT, reuse etc.)
Almost every end user oriented IPv6 deployment makes it significantly easier to use IPv6 addresses to persistently track individual machines (ie individual people) and map them to a household (yes I’m aware of RFCs 7217 and 8981, I’m mostly talking about long term stable prefixes).
How much of a real concern this is is debatable but it’s perhaps a little bit unfortunate.
Another thing that will always trip up new IPv6 network engineers is solicited-node multicast. You know the theory, computers talk to ff02::1 for neighbor discovery and then you hop onto a real network and see none of that actually happening.
And probably the most complicated thing for network engineers - how to set up firewall rules if machines are constantly changing their addresses.
For developers and security people - just parsing and validating v6 addresses is a whole bunch more work, but at least for this, the tools are available to help you now.
That is oversimplified a few things. The 50% deployment is largely Mobile Phone + Cloudflare and India. ( Not sure about China ). Outside of that things aren't that different from a high level overview.
You could have 50% deployment in less than 10 years if 6G Mobile Phone mandate the use of let say IPv8.
Ipv4 is jsut about able still to hold in your head, have a convo or more importantly you can: "Shout an ipv4 across the open office floor from your desk to your tech colleague"
If you shout an ipv6 address in public, you jsut seem broken
Also what’s with all the problems? I’ve had RA packets leak across VLANs via firewall misconfigurations, some my fault and some not. I get that people designing internet protocols had a lot to think about, but why am I fighting stuff like this?
Any tl;dr on why/how the simplest solution imaginable would have been "of no practical use for coexistence or transition"? Granted, I understand the other points make a strong enough case by themselves.
It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP. GPRS/HSDPA/3G/4G/5G They all rolled out just fine and were pretty backwards and forwards compatible with each other.
The whole SLAAC/DHCPv6/RA thing is a total clusterfuck. I’m sure there’s many reasons that’s the case but my god. What does your ISP support? Good luck.
We need IPv6 we really do. But it seems to this day the designers of it took everything good/easy/simple and workable about v4 and threw it out. And then are wondering why v6 uptake is so slow.
If they’d designed something that was easy to understand, not too hard to implement quickly and easily, and solved a tangible problem it’d have taken off like a rocket ship. Instead they expected humans to parse hex, which no one does, and massive long numbers that aren’t easily memorable. Sure they threw that one clever :: hack in there but it hardly opened it up to easy accessibility.
Of course hindsight is easy to moan but the “It’s great what’s the problem?” tone of this article annoys me.
* It was designed by people who didn't have the full picture and were missing representatives from hardware vendors, small businesses, home network admins and a bunch of other people that will be affected by design.
* It was designed by people who didn't consider the cost of migration and the amount of work that would require (see previous point).
* It was designed by people who lived in an ivory tower of "noone will run dual stack for a long time", "everyone will love to run two completely separate network designs".
* It was designed on a premise that end-to-end, fully accessbile devices are something we actually want and won't cause privacy issues.
I think it should be a study material on how standards and designs by commitee can go wrong if they're not headed by people with extensive experience across the industry with enough authority to push for good solutions.
IPv6 tried to do too much (just like many software "let's refactor this legact code") and was done by people who didn't consider all perspectives and costs (again, like many less experienced architects trying to rewrite legacy software).