Hacker News new | ask | show | jobs
by bell-cot 1053 days ago
My IPv6 philosophy:

If any "new" computer technology has been around even half as long as IPv6 ( https://en.wikipedia.org/wiki/IPv6_deployment#Major_mileston... ), with even a tenth of the "you gotta start using this!" push from the Big Boys - and yet still is very widely avoided/resisted, and the older-tech alternative commands a price premium due to widespread demand...gosh, that "new" technology must absolutely suck, eh?

4 comments

I don't think it's fair to blame the technology. The problem is that the computing industry has changed.

The things that IPv6 would enable (direct end-to-end connectivity) is now seen as a negative by the industry that has since pivoted on rent-seeking, walled gardens and restricting user's potential. The industry is now even legally making money on many things that would've been considered outright malware just a decade ago.

People being able to host things themselves, or local-first apps that communicate directly without the need for any middlemen is a negative for the industry. The industry wants there to be a technical need for a middleman, so they can provide that and seek rent over it.

There is no user-level demand for IPv6 because the industry is no longer making any apps/devices/services that would take advantage of end-to-end connectivity (even if it was available now - let's say in a hypothetical world where IPv6 adoption is 100%) since it's more profitable not to, so as a result there is no pressure on ISPs to offer it.

I think that it's fair to blame the specification. I don't think the problem is that the industry has changed, I think it's that there's a huge amount of friction and headache for shifting to it. I think that's because it was too large of a change all at once, combined with the initial specification having some real problems (that did eventually get mitigated in later specs).

I suspect that if IPv6 limited itself to just increasing the size of IP addresses, IPv4 would largely be a distant memory by now.

"IPv4 with bigger addresses" would never have been backwards compatible and would always have been a compatibility break and would always have a slow rollout.

The proposals that seemed backwards compatible were just aggressive CGNAT consolidating even more power in the hands of IPv4 address owners. That doesn't seem like a sustainable fix in the long run.

> "IPv4 with bigger addresses" would never have been backwards compatible and would always have been a compatibility break

True, but it would limit that break to a single thing. That's much easier to deal with than the whole basket of things that IPv6 brings with it.

Compatibility breaks are always headaches. There's not "just broke a 'single' thing" when it comes to compatibility breaks. That is why strict semver suggests a major bump no matter how "small" a compatibility break appears to the developer. There is no such thing as a "simple" compatibility break to downstream users.

In general, despite the complex vocabulary about most of it, in many ways IPv6 is simpler than IPv4. Its header has fewer fields. Its QoL/QoS fields aren't accidental hacks on top of old debugging fields but intentionally designed fields for that very purpose. SLAAC is a simpler protocol than DHCPv4, though the algorithm sounds more complex at first. (DHCPv6 is basically as complex, but fewer devices and fewer subnets should need DHCPv6 in the first place.) Much of the "basket of things" that IPv6 brings with it are designed to remove complexity that has concreted around IPv4.

They ripped the bandaid completely off with the backwards compatibility break that they made with IPv6, and apparently a lot of people loved the cute stickers they had applied on top of the bandaid. But at this point it is probably better for the skin below to heal without the bandaid than to continue to sticker and bandaid over that and let all that unnecessary glue fester in place. (To push such a metaphor almost to its breaking place.)

> in many ways IPv6 is simpler than IPv4.

It's not really about whether or not IPv6 is simpler than IPv4, though. It's about how painful moving from IPv4 to IPv6 is. And it's very painful. If the only thing that changed between the two was that the IP address space is bigger, it would reduce the pain of changing.

I'm certainly not going to claim that my experience is representative of anyone except for me, but the reason that I'm not going to shift to IPv6 until I literally have no other choice is because doing so is an enormous undertaking. Since IPv6 doesn't bring me any benefit that I care about, there is no reason to do so unless I simply can't get on the internet without it anymore.

Please note: I am not bashing IPv6 here, and I'm not saying that a change isn't needed. I'm just expressing some of the reasons I've seen why people resist changing to it, and that I think adopting it would have happened within a reasonable timeframe if it weren't as ambitious.

> The problem is that the computing industry has changed.

Nah, the problem is ipv6 has been designed by a commitee for a lot of enterprise-ish features so the hobbyists have taken a look and postponed setting it up internally for when they have absolutely no choice.

I've asked for simple ipv6 tutorials in discussions on HN and elsewhere and whatever I got pointed at was always longer than the article we're discussing and incomplete.

Basic set up of ipv4 for a home network can be explained over just one pint. Looks like you need two barrells for ipv6.

Yeah right. The summary of the first page already throws around like 4-5 acronyms that each require reading a separate documentation.

And that's only for configuring your router, not your local network...

Okay then please provide me the level of documentation you are looking for, but for an IPv4 network. Sounds wonderful, I'd love to share it with new hires.
> I've asked for simple ipv6 tutorials

There really does seem to be a lack of good documentation about all of this. The docs that I've seen appear to be aimed at actual network engineers, or are so incomplete as to not be worthwhile.

I would be much less stressed by all of this if I could find something good that sits between those two extremes.

A part of me, though, suspects that the reason there is no "middle ground" documentation is that it's not possible -- that IPv6 is too complex for that. Not saying that's the actual reality, but it has the whiff of it.

All networking is complex.

I asked the other guy this, but I'll also ask you. Please provide me the level of documentation you are looking for, but for an IPv4 network. If you have some grand tutorial that explains it as easily as you make it out to be, then I truly would love to see it, I will include it in my onboarding documentation at work.

Because I understand both IPv4 and IPv6, and do not consider IPv6 the more complex protocol by any measure. I suspect your "whiff" is more a bias towards what you are comfortable with, rather than a true reflection of IPv6's complexity.

> Because I understand both IPv4 and IPv6, and do not consider IPv6 the more complex protocol by any measure.

You mentioned "new hires" while i mentioned hobbyists. You're talking about a business network where people are paid to do it, I'm talking about home networks and home labs.

You're basically confirming my statement that IPv6 was designed for enterprise needs?

There are millions of people using IPv6 without knowing it. The ISP has everything preconfigured and if you use a third party router it's normaly one or two options to set. And it just works like for IPv4.
> The industry is now even legally making money on many things that would've been considered outright malware just a decade ago.

Sounds a bit over the top. Can you name some examples?

10 years ago if you made software that uses all kinds of lies and dark patterns to get access to a user's contacts list, uploads it to your server and then you did data mining on it, people would be concerned and consider the software malicious.

Likewise with analytics - tracking every single action you do in an app (along with generic metadata such as IP addresses - which often leaks your general location and your relationship with anyone on the same network since you'd be sharing the IP address with them) would have been considered spyware.

When there were talks of tracking people for ad targeting in the early days of the internet people (rightfully) freaked out, even though that tracking was really primitive by today's standards.

All of those things are now considered legitimate and are routinely done.

I remember how often DoubleClick were the villains of tracking and privacy over-reach on early Slashdot, and then Google bought DoubleClick and became worse than DoubleClick ever were as top Slashdot villains and yet Google is still often called the heroes in the adtech space. (Though that sea is somewhat changing again as even more mainstream media catches up to tracking prevention.) It remains such a profound reversal to me.
We also used to have a name for malware that injected ads into your computer: adware. Now ads are just part of Windows.
Indeed. When I look at how far things have fallen in this regard, it gets very hard to feel positive or optimistic about the internet.
And the human race. The biggest revolution in communication since Gutenberg, and in less than half a century it's been used almost exclusively for evil purposes.
Instagram, for one.
But no one has pushed.

Consumer routers still suck regarding IPv6. Last time I tried setting up IPv6 on my wan I got a /128 which is utterly incompetent.

No service wants to cut off access to the ipv4 customers so they've made things just work. We have only recently hit address exhaustion (relative to IPv6 age).

No one wants to jump first and there is no government mandate for support.

I don't know who you think the big boys are, but it's not like Google or Meta have throttled ipv4 services or put banners on their site warning users they are on a legacy protocol.

A /128 on the WAN is normal. Addresses assigned by DHCPv6 (which is commonly used by ISPs for WAN address assignment) are assigned as /128.

The important part is the delegated prefix, which you normally get via DHCPv6-PD and should be at least a /56.

A big part of it is how much actually needs to change, and work properly, before you can actually rely on IPv6 the way you can on IPv4.

I recall reading about Facebook's internal IPv6 migration for their data centers and the problems they ran into. The two that stuck out the most to me and which I still remember details for are:

1. The PHP function developers used to convert an IPv4 address into an integer to store into a database or something. It didn't work in IPv6, meaning the code broke badly when it was considering an IPv6 host. They kept asking developers to stop using it, but new code kept getting added which used it. Eventually the decision was made that 'we've warned you enough, so from now on we're just going to go ahead and let your code break'.

2. Their networking hardware wasn't extensively tested for an IPv6 single-stack deployment. Turns out that when presented with a BGP advertisement that contained only IPv6 routes and no IPv4 routes, their switches would immediately crash. How did they discover this? By sending out a BGP advertisement that contained only IPv6 routes and no IPv4 routes, crashing every rack switch in the data center. There's no reason why this should happen; it's not a violation of the BGP spec or anything, it's just a bug for a case that no one tested on the vendor's end because none of their customers tried to do that.

So it's not that IPv6 sucks; it's actually pretty great in a lot of ways. The problem is that everything else sucks; people don't bother to support things, they don't consider it in their code, they don't test for it, they don't bother to roll out support because no one else has done so either so why bother, and so on.

In the end, IPv6 is 'avoided' because of the problems that Facebook ran into, or that OP ran into, and is 'resisted' because it's extra work that they could put into doing other things with their limited time and engineering work.

To be clear, dual-stack deployments work great; my ISP recently did a trial of a dual-stack deployment which I was lucky enough to participate in, and it was almost completely transparent. My Unifi gateway picked up the address and handed addresses out to clients internally, clients used IPv6 where appropriate and fell back to IPv4 when necessary, and everything worked completely transparently.

TL;DR IPv6 isn't the problem, the industry is the problem.

I am not buying that even at Facebook there's enough developers to keep adding ip address lookup calls in amounts that make a difference.
Well...okay, some good points, +1.

OTOH - for people making real-world decisions, the difference between "$Networking_Technology sucks" and "~all available implementations of $Networking_Technology suck" is pretty meaningless.

One way to think about the timescale is the rollout time versus the expected usage amount of time. IPv6 was also a bit of a "science fiction project". I remember a lot of the early hype for IPv6 was that it was "IP for the whole solar system" or even sometimes "galactic IP". The architects of IPv6 were clear that they were hoping for something like a 1000 years or more of addresses and usage, even expecting nearly every device on the planet (and maybe the whole solar system) needing an IPv6 address and knowing how fast things like the "Internet of Things" were coming down the horizon.

If it is built to last a 1000 years or more, ~25% of internet traffic by the end of the first 30 years isn't a terrible rollout curve. That's 0.3% of its expected lifetime. (Assuming the 1000 years clock started 30 years ago. It's even believable the 1000 years clock starts closer to 90% rollout of IPv6 than to IPv6 announcements 30 years ago. IPv4 address scarcity wasn't truly felt until decades into IPv4 usage, though it was an academic concern.)

Many Internet projects have always run on different timescales compared to the vastly faster timescales people associate with software and even hardware generations. (In part because these rollouts happen across software and hardware generations.) The IP protocol is so deeply fundamental to that, it is somewhat "civilization defining". It would probably be a lot scarier if an upgrade to something fundamental like IP was an "overnight success". Civilizations are built on the timescales of decades and lifetimes. It should not be a surprise that IPv6 rollout has happened on such timescales. We mostly can only hope that the IPv6 architects were as smart as they hoped they were in preparing for the deep, unknown future of the internet, because they knew they were working on a civilation-timescale tool. (Which is exactly why IPv6 is not just "IPv4 with bigger addresses".)

> If it is built to last a 1000 years or more, ~25% of internet traffic by the end of the first 30 years isn't a terrible rollout curve.

I don't think that measuring the rollout curve relative to the expected lifetime of the thing is reasonable (or at least, useful), though. In terms of something like this, measuring it relative to when IPv4 is simply no longer feasible is better. And that time is very, very near.