Hacker News Reader

Comment by sneak | Hacker News Reader

There is a lot of cultural inertia that instantly biases against anything new in sysadmin/netadmin circles.

It's super annoying, tbh. A subset of technologists only seem comfortable with the technology that was available when they were 18-24, regardless of how old they get.

"What's this? I never needed it before, what's the sysctl to turn it off?"

View on HN

There is a lot of cultural inertia that instantly biases against anything old and stable in developer circles.

It's super annoying, tbh. A subset of developers only seem comfortable with technology invented in the past 18-24 months, regardless of how untested and unstable it is.

“What's this? It was written 2 years ago? It must be old and useless. I’m going to require my app to use the latest version and I don’t care what kind of headaches it makes for the people who actually need to make sure it’s up an running when users try to use it.”

Sure, that's annoying too, but I don't see how it's relevant to the topic at hand. IPv6 isn't some shiny new tech, the original RFC just turned 26. It's also not just a superficial re-write of some existing tool, it fixes a real problem which clearly needs to be addressed (no pun intended).

I agree my response isn’t directly relevant, I’m just tired of seeing the same tropes over and over again about how Ops people’s only motivation is to drag their feet on everything just because they’re old and out of date. They actually have good reasons for having processes that appear to slow things down, for good reason.

I wish v6 just tried to fix things. The problem with v6 was that it also tried to do thing in a right way and broke too much compatibility. And then it turned out what was right in 1995 was no longer so for the last 10 years.

It mostly only broke the things it had to break. v4 isn't forwards compatible to longer address lengths, so the lack of compatibility isn't the fault of any aspect of v6's design.

v6 128-bit address was an attempt to simplify the routing. The was fear that with big routing tables that v4 stated to require 25 years ago the performance would collapse. In practice it never became an issue. Yet with smaller address space, like with just 48 bits, connecting from v6 to v4 address would be possible with much less complex nat.

That was part of it, but there was also a desire to be very sure we had enough address space to avoid needing to go through this again. SEND and privacy extensions also make use of the 128-bit address to add some security.

It's already possible to connect from v6 to v4, and using 48-bit addresses wouldn't make doing so any easier. 48 bits would also be way too small; there'd be no point in going to this amount of effort to update IP only to then have to do it a second time straight afterwards.

Both things are true and equally annoying.

I guess we can agree that there is a cultural inertia that instantly biases someone against something based on perceptions of time XD

How odd, I find the opposite with most developers having close to zero tolerance for buggy tools.

Trying to keep jumping to the new hotness is simply a survival strategy.

One developer's "old and stable" is another developer's "filled with vulnerabilities that nobody will ever find let alone bother to fix because everyone assumes it's old and stable."

IPv6 has been a draft standard since 1998. Get a better argument.

Had this issue with a coworker who uses a decade old version of Linux and refuses to install anything other than base packages cus it's "Stable". Well I made an in house tool, and it's not stable, since his glibc had a bug that's been fixed for a decade that made it so pthreads would break. Everytime I tried telling him it's his system before someone else found the bugfix, he would go "YOU JUST DON'T KNOW HOW TO WRITE MULTITHREADED CODE! MAKE IT SINGLETHREADED AND FIND THE BUG!"

A brand new project being written from scratch is way more likely to have bugs and likely to be abandoned as quickly as it started.

Not if it’s written by a good programmer.

What other things we use daily are "draft standards"?

E-mail (RFC-821), HTTP (RFC-7540), IPv4 (RFC 791), etc. Pretty much the entire internet.

Reminds me of how people would get angry when you suggest a site should switch to HTTPS and people would demand you prove why it would be worth it rather than just doing it anyway since it's free and easy. Glad we have mostly moved past that.

Just witness the pitchfork army whenever systemd is mentioned.

Just don’t want it forced on me and by its nature it becomes a hard dependency over time, thus, it does.

I’m not interested in another argument but calling my position “pitchforks” is a bit disengenuous and irritating (which is why I’m replying, off-topic, to you).

While I think it has something to offer I would like potentially better alternatives to be able to exist in future, this is not “pitchforks”.

>Just don’t want it forced on me and by its nature it becomes a hard dependency over time, thus, it does.

systemd is the choice of basically everyone who builds distros, so of course it's going to be hard to avoid unless you volunteer to do all of that work yourself. When you take work from someone else, that comes with taking on the choices that they make.

Don’t let this descend into another systemd thread. Just don’t lump all criticism against systemd as pitchforks, since it delegitimises complaints.

What you state is absolutely true, but denying there’s more nuance is not helpful. That’s all I’ll say because this is not a worthwhile conversation to have here.

> systemd is the choice of basically everyone who builds distros

Even if we ignore the fact that systemd made it artificially difficult* for distros to support other init systems (so it wasn't a freely made "choice"), have you never encountered a situation where the popular choice turned out to be the wrong one? Think, for example, of people throwing their trash into nearby rivers, or developers using 2 digits to store year values.

(* Imagine being a volunteer for a distro and having to deal with bugs like "I installed my new printer and it changed my init system[0] / my system no longer boots").

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863974

> "What's this? I never needed it before, what's the sysctl to turn it off?"

Of course, turning off IPv6 fixed a lot of connectivity issues, at least back in the day. Maybe it's better now, but I see no benefit in re-enabling it. What's the value-add?

The value is that you don't get caught with your pants down when IPv4 addresses get expensive enough to shaping businesses' decisions. It's going to be a lot less stressful to come to grips with IPv6 now rather than waiting until it becomes a critical path dependency of some business goal.

"Our sires' age was worse than our grandsires'. We, their sons, are more worthless than they; so in our turn we shall give the world a progeny yet more corrupt."

Horace Odes, III 65BCE

There's a bias against anything new in human circles

Well, yes. Getting up to speed on the new thing is work, and unless it's clear what the benefit is then I'm disinclined to do that work.

IP6 requires a bunch of new tooling and configuration, and if running dual stack provides plenty of new opportunities for failure.

In 2021 IP6 is still 'new' to you?

My ISP has offered ipv6 for almost 7 years. When ever I tried to you use ipv6 it was just a miserable shit show. Their support says everything is fine and in the support forums thing work fine for some and for some not so much.

When ever I enabled ipv6 I got 10/10 from test-ipv6.com and randomly few ours later it would go down for no reason. I used few hours to understand wtf was happening. Then I just gave up and disabled ipv6. I got peace of mind and lost nothing. Maybe someday I am bored enough to try again that sorcery and black magic.

As a sysadmin, I'd be fine if the stuff on top supported ipv6. E.g., I'm not aware of support for ipv6 in Kubernetes.

In anticipation, where can I catch up on ipv6 routing? Does the number of route entries explode?

I do need a "business reason" to adopt it, since the Center for Internet Security benchmark dings your system if it is turned on.

On the contrary, the numbers of routes decline. Since you get a single IPv6 assignment, often a /48, you can summarize all your networks to that assignment. IPv4 is a mess in this regard. Small assignments to ISP's and businesses were made to be frugal and delay address space exhaustion. This has caused the address space to be very scattered. You can see at https://bgp.potaroo.net/index-bgp.html that IPv4 has about 900k advertised routes and IPv6 has about 150k advertised routes. The IPv4 address space will fragment further now the price for IPv4 addresses is going up fast. Everyone with enough unused space will fractures their assignment and sell the unused pieces.

That's also your business reason. The price for IPv4 connectivity will go up. At some point a startup will not use IPv4 anymore because it will be too expensive. If you don't have IPv6 access you will not be able to use the services of that startup.

Price of an IPv4 address has doubled last year and gone from about $7.50 in 2016 to about $40 now. https://ipv4marketgroup.com/ipv4-pricing/ https://ipv4.global/reports/

Kubernetes does do v6 today. Given the amount of address space a Kubernetes cluster can use, it's useful there.

Reply on news.ycombinator.com