5 ms·

anyone who thinks "ipv6mess" is still relevant in 2022, doesn't understand the problem space it describes. part 1, interoperability failure/incompatibility: na

by noipv6 4y ago

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.

cryptonector 4y ago
> 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.
- Dagger2 4y ago
  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.
  - howinteresting 4y ago
    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.)
    - noipv6 4y ago
      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.
      - commandersaki 4y ago
        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.
    - ipython 4y ago
      Actually, aws and the big cloud providers are only now starting to release ipv6 aware services. If close to half of US traffic to google transits over ipv6 is considered a failure, I would hate to see “success”.
  - mort96 4y ago
    If it describes problems we're still struggling with, it's still relevant.
  - cryptonector 4y ago
    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.
- noipv6 4y ago
  > 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.
MisterTea 4y ago
> 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.
- Sesse__ 4y ago
  > 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.
- throw0101a 4y ago
  > 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] * https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse... * https://datatracker.ietf.org/doc/html/rfc4291#section-2-5-5 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.

by noipv6 4y ago

cryptonector 4y ago

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

Dagger2 4y ago
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.
- howinteresting 4y ago
  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.)
  - noipv6 4y ago
    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.
    - commandersaki 4y ago
      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.
  - ipython 4y ago
    Actually, aws and the big cloud providers are only now starting to release ipv6 aware services. If close to half of US traffic to google transits over ipv6 is considered a failure, I would hate to see “success”.
- mort96 4y ago
  If it describes problems we're still struggling with, it's still relevant.
- cryptonector 4y ago
  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.
noipv6 4y ago
> 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.

MisterTea 4y ago

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

Sesse__ 4y ago
> 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.
throw0101a 4y ago
> 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] * https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse... * https://datatracker.ietf.org/doc/html/rfc4291#section-2-5-5 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.