Why is IPv6 so complicated?

> In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”.

Topic drift, but for younger people who didn't live it, that's how it used to be!

For most of the 90s my workstation in the office (at several employers) was directly on the Internet. There were no firewalls, no filtering of any kind. I ran my email server on my desktop workstation to receive all emails, both from "internal" (but there was no "internal" really, since every host was on the Internet) people and anyone in the world. I ran my web server on that same workstation, accessible to the whole Internet.

That was the norm, the Internet was completely peer to peer. Good times.

The nice thing about NAT is it makes the security model easier to reason about.

By this, I don’t mean it’s more secure, because I know it isn’t. But it is a lot easier to see and to explain what has access to what. And the problem with enterprise is that 80% of the work is explaining to other people, usually non-technical or pseudo-technical decision makers, why your design is safe.

I really do think IPv6 missed a trick by not offering that.

> IPv6 has some quirks that make it harder to digest.

Almost every point in your list is wrong.

> - link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space

IPv4 has link-local addresses, too. Those are the 169.254.X.X addresses that you see on Windows machines. IPv6 adds nothing new.

> - privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer

Well then, don’t use them. Configure the machines with one address each, just like before. If you want the (arguable) advantages of the privacy extensions, they are available, but not mandatory.

> - multicast instead of broadcast

IPv4 always had multicast, too. IPv6 is simplified by considering the broadcast concept to be a kind of multicast.

> - way too many ways for autoconfiguration (SLAAC, DHCPv6)

SLAAC is just link-local addresses, which you already mentioned above. Did you mean NDP with router advertisements?

If you did, you do have a small point, but DHCP6 is still there like always. IPv6 just offers an additional feature for the simple cases where a host just needs an IP address, netmask and a router address.

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

That’s the complete opposite of my experience. Almost everything in IPv6 works exactly the same as with IPv4.

The SLAAC/DHCPv6 combo seems really strange to me.

Either IP/DNS/gateway discovery with one or the other could be tolerable. But allowing combinations such as SLAAC for addressing and DHCP for DNS discovery is lunacy.

It’s as if one said, let’s take the most basic and critical step and make it as complicated as possible and explore the combinatorial explosion…

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

Was also designed in the early 90s before security was taken seriously.

It basically did, just in hex...

ULA give more trouble than what it solves.

Almost all computer have multiple interface (virtual or not). Application now need to know which interface the destination is on, and there is no easy data structure to store the interface

My IPS changes my prefix once in while. I consider this a privacy feature, not a bug.

Now I find myself in a situation that my devices are not reachable anymore as when the IPv6 address changes and both DNS entries and firewall need to be updated each time when the prefix changed (In between connections break, but this might be a lesser problem)

As far as I understand the only solution which does not include some complex scripting of ip change detection and automatically updating the firewall rules is to use NAT66 and ULA. But even then I have a protocol whose most advertised feature is not to rely on NAT and puts mit fast in a situation in need to use NAT. And the privacy extension of every device or the devices using SLAC and not DHCPv6 are problematic.

IPv6 is just not able to steup efficiently for where IP addresses are changing. Not with moving mobile devices, not in wifi environments with multiple access points, not with changing prefixes, not in failover scenarios.

Bottom Line: I disabled IPv6 again here without any intentions to look for complex workarounds. All outbound traffic is now IPv4 again. IPv6 is providing no benefit but causes additional problems over IPv4 due to issues with the design. I am waiting for IPv7 (or whatever will be the next successor of IPv4) will arrive.

And that's what you should do, since you're forcing the protocol update you should take the opportunity that might not come later

Didn't happen. The swamp aside, Traffic engineering drives most disaggregation. Better in some senses, but not orders of magnitude better I think.

It would be pretty straightforward to change the text selection rule, so that double-clicking anything matching the syntax of an IPv6 address selects the whole address.

The hard part is to find all the places to repeat that change, and convince the code owners to accept it. Probably start with a standard analogous to RFC 5952?

This is the most pro-IPv6 comment I could ever imagine. I am more persuaded now than by the IPv6-is-easy guys all these years.

Fwiw opera mobile on Android selects the whole address there when i long-press

> There is no working solution to ipv6 dual WAN failover, 30 years later... A critical design flaw that was simply ignored by the designers despite being used in almost any SME network.

One of the major issues with IPv6’s design and development is that the people who designed it do not operate networks, nor do they build networking products. They literally fly around the world to committee meetings for a living.

Critical use cases like this are missed and/or ignored because they do not fall within the committee members’ ivory tower world view.

The actual solution is network prefix translation. You effectively NAT the primary network when failed over to the secondary. See https://docs.netgate.com/pfsense/en/latest/recipes/multiwan-... for an example.

IPv4 has exact same problem, the NAT is working here because devices does not actually have proper Internet connection, all connections are terminated on NAT and reassembled after.

Actual solution could be extending TCP and UDP or make a new transport layer procotol that handles changing addresses, similar to what QUIC do. But we cannot do it exactly because things like NATs existing, thus QUIC build was build on ossificated UDP. Imagine if instead of IP+port a connection use unique per-connection hash to persist IP addreses changing. No more trying fighting to keep the IP the same.

Can you just NAT66?

Pretty sure BGP exists. NAT, also.

A couple of years later ipv6 became unnecessary. A big driver for ipv6 at the time was routers not being able to manage the increasing size of the core routingtable. Then 2 years later betterhardware and routing table compression became available and ipv6 became unnecessary.

if you want population measurements, there is a APNIC page for that too.

https://stats.labs.apnic.net/v6pop

Fair warning, this page is not optimized and takes a lot of resources to render.

It happened in india mainly due to regulatory pressure[1]. It also helped that around the same time, Reliance (an oil company) launched at a hitherto-unseen pace an entirely new telco (Jio) with only 4G support (now 5G too, but at the time) and zero legacy infrastructure. Airtel (an older telco) was still using ipv4 in lots of cases. However due to pricing pressure[2] and TRAI pressure, they also switched when their 5G rollout happened in 2022. They changed vendors and with that changed the infrastructure as well. So today they are also in good shape ipv6-wise. See also [3]

[1] https://www.dot.gov.in/ipv6-transition-across-stakeholders Edit: hey look the govt drupal page is broken again, shocker. here is another source: https://icrier.org/pdf/IPv6_Transition.pdf

[2] The pricing pressure was _real_. 4G was the first time networks moved away from circuit switched to IP-based. So the marginal cost equation became better. And no legacy infra to support. By 2020, they also had funding from google and meta.

[3] https://broadbandindiaforum.in/wp-content/uploads/2022/08/Re...

Now compare average income to see how much this matters.

> Why/how did it turn out?

It is extremely hard (for Brian, but even more so for anyone else, I certainly can't) to give a good answer to that, since you're talking about the absence of utility. People had applications in mind but dismissed them because they either found better ways or it wasn't practical. But that very frequently doesn't result in a "paper trail".

(It's a bit like LLMs having problems with negatives/absences.)

Try it and see!

  192.168.1.1$ ip link set sit0 up
  192.168.1.2$ ip link set sit0 up
  192.168.1.2$ ping ::192.168.1.1
  64 bytes from ::192.168.1.1: icmp_seq=1 ttl=64 time=0.812 ms

(It works over the Internet too, though make sure your firewall doesn't block protocol 41 and that the packet doesn't get NATed.)

Notice how this doesn't really help you at all. You still need a functional v4 network, you still need v6 support in the kernel on both sides and your programs still need to support AF_INET6 sockets -- at which point, why not just use ::ffff:192.168.1.1 which sends packets without the tunnelling and doesn't need OS support on the far side, or 192.168.1.1 which works with AF_INET sockets and doesn't need tunnelling or any OS support on either side? This is strictly worse than the former option and less compatible than the second.

At home, my external IPv4 address was the same for extended periods of time even though I never paid for a static IP. You could have figured the traffic was coming from the same location.

The one external IP to many internal devices relationship does help with privacy.

But once you enable those IPv6 privacy extensions, I have so many devices bouncing between IPs I’m not sure how you’d even know how many devices I have, let alone which device is which.

An interface can have many ipv4 addresses as well. It's just not that common, so many people believe they'd need vlans to achieve that.

How I wish that djb time stamped his articles, as I feel like this article is over a decade old but I can’t tell with certainty.

> What I don’t understand is why coexistence was so important.

Military, corporate, tech... it isn't. (If your people like flag day migrations. It's… "a choice".) But if you have to explain to an end user why some things work and some don't, you're just f'd.

And note "coexistence" here means that an end host can implement IPv4 and IPv6 at the same time, without them interacting at all. Imagine if you had to choose between IPv4 and IPv6 on your devices, maybe something like "you need a 2nd network card". Can you imagine anyone switching to the less popular protocol?

Because the internet was still a "network of networks".

There were interconnections between DECNET and Novell et al networks and IP networks etc, let alone the push from telcos etc of the OSI models.

IP hadn't "won" the networking space.

The whole world can't migrate all of their hardware on a whim. There was a period of time when it was a very common quip to say that Amazon would have to buy every new IPv6 compatible router in the world for a year if they wanted to upgrade their infra. I don't know if the urban legend is true or not, but the fact that it sounded plausible is a good enough of an example.

On one of my linux machines the "localhost:8080" did not work after new installation. It resolves to local ipv6 address, while server only listened on ipv4.

After this I go out of my way to disable, remove and nuke ipv6, out of every setup and deployment I do. Ipv6 is already quite complicated, but supporting TWO competing network stacks, with complicated pseudo compatibility, just multiplies unnecessary complexity!

inet_pton/inet_ntop handle AF_INET6.

TL;DR: because it doesn't actually solve anything.

Being able to jam an IPv4 address into an IPv6 packet header doesn't mean you can send that packet to an IPv4-only host and have it be understood. You still need an IPv6 stack on both endpoints, and on all the routers in the middle - and at that point, why not just use IPv6 addresses?

It's not complicated because you understand it? Okay then

The main complexity of IPv6 is still ha I g to maintain an IPv4 installation. The vast majority of non phone devices do not work in an IPv6 world only because CLAT hasn’t been baked into the OS since the very beginning. It still isn’t a first division tenant on Linux servers, desktops, IoT, or windows. I believe OSX integrates it now

Could with approximately zero services requiring IPv6, the collapsing cost of IPv4 addressing, and it makes IPv6 very much a hidden protocol for phones. When I tether off my phone I get an IPv4 address, the phone may well do a 4:6 translate and then something else does a 6:4 translate. That doesn’t matter, I can still open a socket to 1.1.1.1 from my application.

Had IPv4 been transparently supported IPv6 wouldn’t have taken 30 years and a whole new ecosystem (phones) to get partway there.

If anything, IPv6 is extremely easy to use, especially with SLAAC: On any kind of standard network, you turn on IPv6 on your machine, and, given physical connectivity, bam! You're on the internet.

It only gets complex if you try to micro-manage it.

I was at some of those IETF meetings in the mid-1990s and attended some early IPv6 working group sessions. We knew the conversion would take time, but I don’t think any of us thought it would be this slow. I was involved with multiple L3 switches and routers from 1997 through 2010. The issue was always that IPv6 basically required lots of boxes in the middle to understand it in order to roll it out, so when would it be commercially necessary? Yes, you can do tunneling and NAT at various points, but it always requires more than just the endpoints. It shows up in DNS and socket APIs. There’s no easy way to determine if a path supports it, and the path can change in an instant due to a route change. All that is very different than SSL or QUIC where only the endpoints have to be involved. That’s why QUIC uses UDP, for instance, so old intermediate devices just see it as a protocol they already know. SSL just assigned port 443 and the “https” protocol in the web URL. If a web client contacts a server on port 443 that doesn’t use SSL, it just fails. To put it another way, the level of the stack that you’re changing matters. SSL and QUIC are really L5+. IPv6 is squarely L3. There are no protocol negotiation mechanism available at L3. So, from a business standpoint, when do you take the hit and integrate it all into the processing pipeline? How do you do that in a way that doesn’t impact your IPv4 forwarding performance, because that’s what the near-term market will judge you on? How do you afford the development and test cost associated with a whole other development (almost double)? If you’re doing software forwarding, the answers are a lot easier. As soon as you’re designing silicon, it’s a lot harder. When you’re under a lot of commercial pressure, it’s difficult to be the one who goes first. And remember that this hardware evolves on roughly 10 year cycles (2 years for design, 3-5 year market sales, 3-5 year depreciation at the customer before they buy new ones). Oh, and customer rollout of IPv6 is a major project with lots of program management and testing, not just buying a box or two. So, yea hindsight is easy. Eventually you get there, but it’s a long road.

> It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP.

All that's required to implement each of those is two computers: 1 client and 1 server. Whereas supporting IPv6 requires every router between the two computers to also support IPv6. Similarly, if your current software doesn't support SSL/SSH/Gzip/etc., it's pretty easy to switch to different software, whereas it's hard or impossible for most people to switch ISPs.

> GPRS/HSDPA/3G/4G/5G

Radio spectrum costs providers millions of dollars, and each new cellular protocol increased spectrum efficiency, so upgrading means that providers can support more users with less spectrum. The problem is that most of the "Western" countries still have lots of IPv4 addresses, so there isn't much cost benefit to switching to IPv6. However, China and India both have lots of users and fewer IPv4 addresses, so there is a cost benefit to switching to IPv6 there, and unsurprisingly both of these countries have really high IPv6 adoption rates.

> Instead they expected humans to parse hex, which no one does

Of all aspects of IPv6 you took the only one that doesn't complicate implementations and can easily be swapped if you wanted.

  $ ping -c 1   1.65793
  PING 1.65793 (1.1.1.1) 56(84) bytes of data.
  64 bytes from 1.1.1.1: icmp_seq=1 ttl=54 time=1.56 ms
  
  --- 1.65793 ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 1.560/1.560/1.560/0.000 ms

> The whole SLAAC/DHCPv6/RA thing is a total clusterfuck.

SLAAC is easily the thing I love most about IPv6. It just works. Routers publish advertisements, clients configure themselves. No DHCP server, no address collisions, no worry. What's bugging you about it?

  ping somehostname

> It didn’t take 25 years for SSL.

It wasn't even on the map until 1994. Prior to that it was an ad-hoc mess of "encryption" standards. It wasn't even important enough to become ubiquitous until Firesheep existed.

Even then SSL just incorporated a bunch of things that already existed into an extensible agreement protocol, which, in the long run, due to middleware machines, became inextensible and the protocol somewhat inelegant for it's task. 30 years later and it's due for a replacement but we're stuck with it. Perhaps slow adoption isn't a metric that portends doom.

> What does your ISP support?

My ISP is Spectrum. They get a 0/10 on IPv6 support on this test page [1].

[1] https://test-ipv6.com

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

You're comparing incremental rollout with migratory rollout for most of these; (not the mobile phone standards.) That's apples and oranges.

You can argue for other proposals. But at the end of the day the best you could've done is steal bits from TCP and UDP port numbers, which is... NAT. Other than that if you want to make a serious claim you need to do the work (or find and understand other people's work. It's not that people haven't tried before. They just failed.)

And, ultimately, this is quite close to typical political problems. Unpopular choices have to be made, for the benefit of all, but people don't like them especially in the short term so they don't get voted for.

> If they’d designed something that was easy to understand, […]

I can't argue on this since it's been far too long since I had to begin understanding IPv4 or IPv6… bane of experience, I guess.

> […] not too hard to implement quickly and easily, […]

As someone actually writing code for routers, IPv6 is easier in quite a few regards, especially link-local addresses make life so much easier. (Yet they're also a frequent point of hate. I absolutely cannot agree with that based on personal experience, like, it's not even within my window of possible opinions.)

> […] expected humans to parse hex […]

You're assuming hex is worse than decimal with binary ranges. Why? Of course it's clear to you that the numbers go to 256 because you're a tech person. But if you know that, you very likely also know hex. (And I'll claim the disjunct sets between these are the same size magnitude.)

Anyway I think I've bulletpointed enough, there's arguments to be made, and they have been made 25 years ago, and 20 years ago, and 15 years ago, and 10 years ago and 5 years ago.

Please, just stop. The herd is moving. If anything had enough sway, it would've had enough sway 15 years ago. Learn some IPv6. There's cool things in there. For example, did you know you can "ping ff02::1%eth0"?

how do you encode 128 bits without making a long number? and not using hex?

Yeah the at least 25 years thing is a cop out. The IPng committee specifically chose the protocol that didn't have a transition plan, and today still doesn't have a transition plan.

I expect we're going to plateau with adoption for a long while now. 50% adoption is meaningless if it doesn't tangibly make a dent in the IPv4 exhaustion problem.