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.

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

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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

> 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

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

> 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"?

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

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.

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

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.