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.
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.
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.
†: https://www.zdnet.com/article/apple-tells-app-devs-to-use-ip....
NAT is a cruicial privacy and security feature.
"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.)
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.)
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.
IPv6 security is like IPv4 security: Firewalls
For privacy IPv6 uses Security Extensions, which shuffles your ipv6 ip.
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?
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.
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.
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 know that v6 has been a success within datacenters and such.)
If close to half of US traffic to google transits over ipv6 is considered a failure, I would hate to see “success”.
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'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.
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.
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]
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
* https://datatracker.ietf.org/doc/html/rfc4291#section-2-5-5
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.
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.
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.
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...
0: https://cr.yp.to/djbdns/ipv6mess.html