tl;dr: The Linux kernel team view all bugs as a possible security issue. The CVE assignment teams tries to minimize the number of Kernel CVEs because corproate policies mandate fixing CVEs in 30/90 days. There's a lot of politics.
OpenBSD was also one of the first operating systems to disable hyper-threading by default due to all the related security issues with this technology. Yet another case of security over speed.
Hyper-threading, at least in the beginning, had limited if any performance improvement when enabled. Windows (XP, 7), at least, was faster at work with hyper-threading disabled.
I'm still waiting for benchmarks which show more than a 5% increase in performance with hyper-threading enabled.
If you haven't seen a >5% performance improvement for any workload with HT/SMT enabled, you're just willfully blinding yourself to benchmark data. It can be closer to 80% than 5%, at least for some reasonable workloads.
“[N]o interest in performance” is probably a bit unfair, no? It makes it sound like any patch that brought solely performance would be rejected. But it is certainly true that they have much less manpower than the “competition” and that performance takes a backseat relative to other priorities.
Sure, U-Haul. It's $19.95/day and $1.39/mile. Last time I rented one the automated "don't have to talk to anyone" app I couldn't figure out, but it took less than 120 seconds to navigate the in person exchange to get the key.
You don't need a pickup truck to go camping (they're actually not terribly useful for that) or yard sale shopping. Like seriously it's https://van.life not truck life.
The value proposition of a CDN is being physically closer to customers around the world, which means renting space in (often) expensive carrier hotels.
Yes yes all the major CDNs have loads of developer and infrastructure wizbangs to keep you on their platform but that’s not the fundamental value.
It's been a quarter of a century since IPv6 launch.
There's some really good lessons learned here. IPv6 requires everyone, everywhere, needs to change their configuration to add IPv6 addresses and network connectivity to every node/endpoint. The madness of course is that all the underlying infrastructure software (routers, OS, standard libraries) all support IPv6. It would seem, at a large enough scale, that software is the easy part, configuration is the hard part.
DJB wrote this up two decades ago[0] and it remains relevant. In particular the comparison between IPv6 and MX records. It took me a little while to wrap my brain around just extending existing software to support sometimes 32bit and sometimes 128. Ultimately it wasn't hard to dream up a few solutions for how that would work.
The other thing, FWIW, which has been slowing IPv6 adoption is business owners not asking for it as a high priority item from their providers. I've seen this happen way more often that I would like where provider asks a customer what they want and the customer never mentions IPv6, and when prompted shrugs it off because they don't see it as a business critical (and in fairness, it hasn't been). Yes provider isn't asking the 'nerds' at their customer's businesses, but those folks also aren't the ones paying the bills so...
I got a brand new router recently, IPv6 was still disabled by default! I honestly can't understand the reasoning, I don't even buy the internet visibility argument because the default incoming connection rules for IPv6 after I enabled it were deny-all. We really have a long way to go still in getting equipment everywhere enabled on it.
Some ISPs have v6 enabled but it's just broken or sub optimal. I imagine the logic is that v4 always works and the user could only see a benefit from having v6 off by default.
True, on an individual level that probably represents the best benefit. Anyone who actually cares would also know to go through the settings to check the defaults on all of those things with a new router too.
Both of those statements are wrong. It provides benefits to the user and it's no more of a security vulnerability than having any other networking protocol is.
If anything, v4 is more of a vulnerability because it's so easy to scan and because NAT increases the complexity enough that most people don't understand how their networks work.
Three decades of IPv6 mis-adoption shows otherwise. "Running out of IPv4 addresses" is not a problem you face unless you're an internet service provider or a mobile network.
99.99999% of the rest of us don't care because we use 192.168.0.0/16 or 10.0.0.0/8 when we have to do networking.
Yes, NAT is complex. That sucks. No, blindly stating "you don't need NAT and you're holding it wrong" is just plain incorrect.
Please make NAT easier to use and configure, don't sweep it under the rug and pretend like the world can function without it.
It causes no end of problems, not just for ISPs and mobile networks but also for people running server networks and for end users like us. I suppose it can be hard to see that when you grew up with the problems and have never used a network where you didn't need to deal with them though.
The world can mostly function without NAT. It's mainly only used to work around address shortages, which aren't an issue on v6, so there's simply no reason to use it most of the time. It can be a useful tool in your toolbox, but it's one that you only need to use very rarely.
Here's a benefit from v6: 40% faster connection setup†. Measurable benefits show that there are benefits. "No need to use NAT" is of course another obvious benefit of v6.
"No need to use NAT" is, of course, a horrible anti-feature, not a benefit of IPv6. (And, of course, in the real world the vast majority of IPv6 is rolled out with NAT anyways.)
NAT is neither a privacy nor security feature, what are you talking about? Have you actually tested what your CPE does when it gets packets addressed to internal IPs from the WAN port? Almost every time, the answer is just pass it on to the target host. Thinking NAT is a security feature makes your network MUCH less secure.
As for privacy - you can fingerprint individual devices pretty trivially, and with privacy extensions for SLAAC you can only tell what /64 network it's coming from, which is no more information than IPv4 (unless you're behind CGNAT, but frankly being behind a 4-to-4 CGNAT shouldn't count as internet access because you literally can't get incoming connections.)
Having enough address space to not need to NAT is hardly an anti-feature.
I don't have any hard stats, but NAT seems to be very rare in v6 deployments. You don't really hear of ISPs using it. I'm certain you could find some if you looked hard enough, but mostly it's not a thing.
If it was easy to set up, the providers would just include it (or the price would be low enough to shrug it on).
But it's not really trivial and IPv4 works well enough for most people to bother. Remember the typical workaround for network issues being disabling IPv6?
anyone who thinks "ipv6mess" is still relevant in 2022, doesn't understand the problem space it describes.
part 1, interoperability failure/incompatibility: nat64+dns64 has been viable since 2008
part 2, incoherence: dual-stack was the transition plan, & was clearly communicated from the start (to anyone who listened). that turned out to not be so effective since so many ppl ignored the realities of legacy ip depletion. at this juncture ipv6-only (w/ nat64) is becoming a more preferable approach, since you only need to maintain a single protocol in the majority of your environment (as evidenced by org's like tmobile us, facebook, etc).
part 3, distractions: one could argue that rants like "ipv6mess" are the biggest distractions to ipv6 deployment.
"no one is asking for ipv6" is a lie writ large in the provider space; i've seen plenty of examples where a provider has told multiple customers "you're the first person to ask for ipv6 support!" - the problem being is that most org's don't actually keep track of such requests in a unified place, & so every customer is pushing for it alone, so far as the provider is concerned.
> anyone who thinks "ipv6mess" is still relevant in 2022, doesn't understand the problem space it describes.
It was relevant then -and it is relevant now- because there are good lessons in how to migrate from thing A to thing B, even if some of the then-missing necessary bits are in place now.
Still, it's almost certainly the case that DJB's rant had no real effect, and that the necessary steps were bound to be taken as the cost of sticking with IPv4 rose. Also, a significant period of time was always going to be necessary for software and tooling to catch up -- perhaps there wasn't much to be done about improving the transition 20 years ago. Yet DJB's rant isn't wrong or devoid of value -- it's mostly right and entertaining (still!), even if there just wasn't enough IETF and dev oomph to do better at the time.
I'm not sure it was ever relevant. All it does is describe the problem, which was already well-known at the time by the people working on v6. It doesn't give a fix for it.
It doesn't give a fix because no fix is possible. Because the problem comes from the design of v4, not from v6.
For some reason djb wasn't able to get his head around that, and people have been pointing to that damn page as if it's some big gotcha ever since. No, it's just the situation we're stuck with, thanks to the people that designed v4.
I mean, v6 is still mostly a failure, so (rightly or not) the situation is going to be blamed on the people that have been pushing v6. That's just the cost of trying to push the entire world towards a new standard.
(I know that v6 has been a success within datacenters and such.)
by what definition would you call ipv6 "mostly a failure"? 30-40% global eyeball network (to the end user) adoption after ~10 years of active deployment, against very vocal opposition seems commendable enough to me.
More like 15 years of active deployment, and I'd expect levels at 90%. The world changed after IPv6 with smartphones that are controlled by a select few carriers, so it's easy to deploy IPv6 in which they're in dire need.
But the rest of the networks: enterprises, hosting providers, cloud providers, ISPs really don't give a shit. It's merely a cost centre or a burden.
It talks quite a bit about how to tackle migrations. It doesn't specify specific solutions for IPv6, no, but it does talk about what doesn't work and what should be looked into. It's a blog, not an Internet-Draft.
> It was relevant then -and it is relevant now- because there are good lessons in how to migrate from thing A to thing B, even if some of the then-missing necessary bits are in place now.
it's irrelevant now because there are smoother approaches to migrating to future-proofed networks than existed at the time. the fact that it persists on the internet, unamended, to be regularly presented (two decades later) as some semblance of current realities of the challenges to ipv6 deployment is a disservice to the internet.
> Still, it's almost certainly the case that DJB's rant had no real effect, and that the necessary steps were bound to be taken as the cost of sticking with IPv4 rose.
i would maintain that "ipv6mess" had a NEGATIVE impact on ipv6 adoption overall, as people who saw djb as a tech god accepted his word as gospel, despite it fundamentally being a crybaby rant, & proliferated the misconceptions & opposition therein.
the fact that he explicitly rejected ipv6 patches to qmail & djbdns (resulting in a fork to at least qmail) should not be understated - he didn't just complain about ipv6, he actively sought to undermine its adoption.
> part 1, interoperability failure/incompatibility: nat64+dns64 has been viable since 2008
Why are we stuck with nat in 2022 again? Why did we not map the 32 bits of ipv4 to ipv6?
> part 2, incoherence: dual-stack was the transition plan, & was clearly communicated from the start (to anyone who listened).
Perhaps they didn't listen because dual stack means investing in building another incompatible internet on ipv6 in parallel with the ALREADY WORKING ipv4 internet. Reminds me of a great quote: "the most dangerous enemy of a better solution is an existing codebase that is just good enough." - Eric S Raymond
> part 3, distractions: one could argue that rants like "ipv6mess" are the biggest distractions to ipv6 deployment.
Because it is a mess. Stop denying that. If ipv6 was designed to be easily deployed via backwards compatibility then we would be using ipv6 already.
> Why are we stuck with nat in 2022 again? Why did we not map the 32 bits of ipv4 to ipv6?
Oh, you mean like this:
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[61]
You still need to upgrade bit of networking kit between the source and destination to understand "IPv4+", and this (lack of) upgrading and enabling is what is hampering deployment.
What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6?
> Because it is a mess. Stop denying that. If ipv6 was designed to be easily deployed via backwards compatibility then we would be using ipv6 already.
Backwards compatibile IPv6 was impossible.
IPv4 has 32 bits of address. Anything after IPv4 needed >32 bits of address. How do you fit in >32b in a data structure that is 32b? You cannot.
So you have to go an replace every bit of networking code out there to change the data structures. You know, like was done to deploy IPv6.
> Why are we stuck with nat in 2022 again? Why did we not map the 32 bits of ipv4 to ipv6?
Because it does not help. djb's “idea” was to change everybody's setup _first_ and then have a flag day where the entire world were moved from IPv4 to IPv6 in one big change. Good luck with that. (And only after that flag day, we could start actually using a larger address space to try to get rid of NATs.)
The ipv6mess essay is confused because it somehow thinks _getting addresses_ is the hard problem. It does not solve _any_ other configuration or coding part. You still need to upgrade DNS. You still need to have a different wire protocol. You still need every hop on the path from me to you to understand and route IPv6.
At least now with gradual rollout and dual stack, we're at 40% of endpoints and AFAIK a majority of traffic. With djb's plan, we'd still be at zero.
This is an astoundingly narrow take. They (vendors, practitioners, stodgy luddites) didn't listen because there was nothing on fire and no money to grab at when the conversations began 20 years ago.
Networks exist (and have always existed) globally that operate using parallel, incompatible protocols from layer 1 to layer 3. None of this is new, and none of it should be a surprise.
The outrage all stems from a lack of awareness of history and increased visibility from armchair experts that fixate on how things work for them, and not from the long-term perspective or the point of view of a large provider, global network, or resource of significant scale / size.
IPv4 is the poster child for the sunk cost fallacy; it is an outdated shit pile that has become the outdated shit pile we know, and therefor somehow the option that needs extended in perpetuity.
"Good Enough" is subjective. A bicycle is "good enough" for moving a person from point A to point B over short distances. It's not good enough when it is below freezing, raining, or needs to transport large cargo. It's not good enough when there are 3 people that need to travel from point A to point B and there is only one bicycle. A car may be good enough for that. But a car isn't good enough when part of that trip spans an ocean. The fact that a person thinks IPv6 is a stupid idea and that extending or making compatible the pant load of diarrhea that is IPv4 is "good enough" is fine for that one person, or even a group of persons.
However, it does not scale globally, and it provides no supportable longevity. Even with the release of every single extra block of IPv4 - 240, 127, all of the unused or dark /8 addresses, 0.0.0.0, 255, and even with the proliferation of carrier NAT - it is still too limited to scale long term or introduces blindingly unnecessary complexity.
There is already significant IPv6 deployment globally, and it has grown by a large margin in the last 3 years, prior posts have clearly shown that. As far as IPv4, The goal was never to turn it off like a light switch, it has always been to phase it out, and by and large that has been happening at a fairly accelerated rate.
If we spend half as much time on IPv6 that we do moaning about IPv6, we would have been done with this a decade ago. The point is that IPv4 is functionally legacy. It'll continue to exist until it doesn't, but refusal to learn and implement IPv6 (and contribute to improving it) is truly a disservice. It's well past the point of no return, so learn it. Or don't. It won't really change the direction we are moving.
> SMS is a terrible solution that really only solves "you used the same password across two sites
Right. That’s the sole purpose. People pick bad passwords and reuse them, but you already know that.
As much as tech tries to make this easy people, it’s a horse-vs-water problem. Even smart people refuse to use to use password managers. Most of those people have figured out how to receive text messages.
Seriously, go find someone who owns a JitterBug phone and watch them create a new account on the website of your choice. We’ve got a long way to go.
Instead of pushing a non-solution that trades one issue for another we should be educating people on password managers. Every major browser has built-in password management.
It’s a good read, and I really wish time was always that simple. Sometimes you have multiple platforms on different clock systems and distributed systems running across them. Did you know google and amazon smear leap seconds? GPS/Galileo/that-China-one don’t have leap seconds (but all are different TAI offsets) but that Russian GPS one does have leaps. They all have slightly different versions of utc.
Most of the time none of that matters and you can just install chronie and point it to whatever.pool.ntp.org and you’re off to the races. But boy does it suck when you have to to know.
> GPS/Galileo/that-China-one don’t have leap seconds (but all are different TAI offsets) but that Russian GPS one does have leaps. They all have slightly different versions of utc.
This is not wrong, but it's missing a large chunk of information. All non-UTC-based geonavigation satellites also broadcasts both the offset between internal and UTC and if there's an impeding leap second.
You can nowadays buy a chip-scale atomic clock for $2000, which is a modest fraction of the price of an entire server. Every datacenter should have one.
https://lwn.net/Articles/961978/
tl;dr: The Linux kernel team view all bugs as a possible security issue. The CVE assignment teams tries to minimize the number of Kernel CVEs because corproate policies mandate fixing CVEs in 30/90 days. There's a lot of politics.