4 ms·

Compare IPv6 adoption to that other generational migration of our time: 32-bit x86 to 64-bit x86. The first x86-64 CPUs became available in 1999, while 32-bit W

by jl6 5y ago

Compare IPv6 adoption to that other generational migration of our time: 32-bit x86 to 64-bit x86. The first x86-64 CPUs became available in 1999, while 32-bit Windows will still be supported through to 2025 on Windows 10. Only with Windows 11 will the world’s mainstream OS finally complete the move away from 32-bit. IPv6 migration is much more complex, so I don’t think we’re doing too badly, and I think we’ll be done around 2040.

formerly_proven 5y ago
AMD64 hit the market in 2003. Adoption on the software, desktop side was mostly delayed because Vista as a whole failed and XP64 was very niche (on servers and Linux desktops everyone jumped on it). 32 bit Windows outside VMs is only really needed for Intels gimped low end SoCs which lacked AMD64 support for a long time. The value prop of AMD64 was very clear from the start: better performance, more memory, without porting to a 64 bit RISC which coincidentally were all dying or dead at the time. The only other option at the time was IA64 - Itanium - which sucked and was way more expensive. The value prop of v6 is: ??? Learn an entirely new networking stack! Enjoy degraded service because v6 will cause inexplicable hangs and timeouts! Deal with a weird ass protocol founded on perimeter security which is not something we have been doing for 20 years! Fun for the whole family!
- trulyrandom 5y ago
  I'm not a network guy, so forgive my ignorance, but this is the first time I'm hearing about this. Why will IPv6 cause inexplicable hangs and timeouts?
  - corty 5y ago
    When a server has IPv4 and IPv6 connectivity, i.e. an A and AAAA DNS record, clients would usually try IPv6 first, then IPv4. Now, if IPv6 is broken somehow (as it was prone to be due to tunneling, Teredo and even nowadays stupid ISPs), the client would wait for a connection timeout, then try IPv4, so every connection would hang for one timeout. Nowadays, most clients, especially browsers, will try IPv4 and IPv6 concurrently and use the connection that comes back with an ack first. This prevents hangs at the expense of a little higher server resource usage. But the myth of "IPv6 makes things hang randomly" remains.
    - formerly_proven 5y ago
      It's not a myth when it happens. Last time I tried v6 again on my network (about a year ago) I had these issues. Not a lot of them, but toggling v6 off made them go away. There are fewer issues, true, but having dual-stack does still appear to break some things. I say "appear to" because I'm assuming that it's not actually an issue with v4+v6 dual stack, but rather a problem with misconfigured services (e.g. services having wrong AAAA records, stuff using v6 that doesn't work properly with v6 etc.); from an end-user perspective this does not really matter: There are sometimes issues when v6 is on, which go away by turning v6 off - end user perception: v6 is wonky.
      - mindcrime 5y ago
        Your lived experience is what it is, and I certainly don't mean to contradict you. But just to add another viewpoint for perspective... My ISP (formerly Time Warner, now Spectrum) has been handing out v6 addresses here, and I've been running in dual stack mode, for a good 3 years or more now. And in all that time, I can remember exactly one occasion where IPv6 caused any issue. And that was only because somebody at my employer who was setting up a GCP environment didn't take into account that anybody would be coming in on IPv6, didn't configure the corresponding firewall rules, and it broke using kubectl to access GKS clusters from my home network, as kubectl was defaulting to the v6 connection. So yeah, v6 can cause some weirdness, even now (the event described above was about 3 months ago) but in my experience it is exceedingly rare. YMMV, of course.
        easrng 5y ago
        I use Spectrum and their IPv6 connectivity drops out relatively frequently, but IPv4 connectivity stays.
- throw0101a 5y ago
  > The value prop of v6 is: ??? Learn an entirely new networking stack! The value prop of IPv6 is not having to pay US$ 30/IP (and rising) when you need a block of new IPs. Most folks don't need that many public IPs and so simply use RFC 1918 addresses and then implement the kludge that is NAT. NA(P)T was codified in 1999 (RFC 2663), and it is now "background radiation" so people think it's normal because it's all that they've ever know. But we've long gotten to the point where we're now doing double-(CG)NAT, and entire chunk of address space (100.64.0.0/10) has been reserved just for this purpose: * https://en.wikipedia.org/wiki/IPv4_shared_address_space https://en.wikipedia.org/wiki/IPv4_shared_address_space I'm waiting for triple-NATing to start occurring.
  - tenebrisalietum 5y ago
    NAT is essentially required in IPv4 due to IPv4 address exhaustion. NAT, when done on the carrier level (CGNAT), more or less prevents external systems from initating connections with anything on your network (without ISP involvement). You can still initiate outgoing connections fine. Sounds great for security, but this enforces the existence of centralized services (middlemen) that you have to use/pay for if you want to have asynchronous communication with anyone that you might not necessarily initiate. If you want a chance at a real decentralized Internet without dependency on tech giants, you're gonna need IPv6.
    - saurik 5y ago
      Does the CGNAT setup you contend with not support NAT-PMP/PCP? (To me that is the reasonable solution to the problem you cite, not IPv6, and I have been thinking it is already widely deployed... just not adopted by developers for some reason.)
      - tenebrisalietum 5y ago
        I don't contend with CGNAT, thankfully, but no one ever moves from IPv4 then everyone's going to eventually be behind a CGNAT at some point. I don't know too much about NAT-PMP/PCP - so I'm looking into it.
- MisterTea 5y ago
  I believe XP64 was OEM only, there was no retail availability. I had.. uh ... obtained a copy and installed it on my brothers gaming PC and it ran surprisingly well for an OS that barely made it to market.
  - formerly_proven 5y ago
    XP x64 was available in retail, I used it for a pretty long time. The biggest issue was lack of drivers for stuff like printers and scanners, though iirc later on the Vista 64-bit drivers would usually work.
yyyk 5y ago
64 bit adoption was far faster. A mere decade after x86_64 was available, just about the entire consumer market switched. The last barely-mainstream 32bit processors were of the Intel Atom line (for notebook), and that ended about a decade ago. Microsoft's backward compatibility guarantee makes the timeline look much longer than it actually is.

by jl6 5y ago

formerly_proven 5y ago

AMD64 hit the market in 2003. Adoption on the software, desktop side was mostly delayed because Vista as a whole failed and XP64 was very niche (on servers and Linux desktops everyone jumped on it). 32 bit Windows outside VMs is only really needed for Intels gimped low end SoCs which lacked AMD64 support for a long time. The value prop of AMD64 was very clear from the start: better performance, more memory, without porting to a 64 bit RISC which coincidentally were all dying or dead at the time. The only other option at the time was IA64 - Itanium - which sucked and was way more expensive. The value prop of v6 is: ??? Learn an entirely new networking stack! Enjoy degraded service because v6 will cause inexplicable hangs and timeouts! Deal with a weird ass protocol founded on perimeter security which is not something we have been doing for 20 years! Fun for the whole family!

trulyrandom 5y ago
I'm not a network guy, so forgive my ignorance, but this is the first time I'm hearing about this. Why will IPv6 cause inexplicable hangs and timeouts?
- corty 5y ago
  When a server has IPv4 and IPv6 connectivity, i.e. an A and AAAA DNS record, clients would usually try IPv6 first, then IPv4. Now, if IPv6 is broken somehow (as it was prone to be due to tunneling, Teredo and even nowadays stupid ISPs), the client would wait for a connection timeout, then try IPv4, so every connection would hang for one timeout. Nowadays, most clients, especially browsers, will try IPv4 and IPv6 concurrently and use the connection that comes back with an ack first. This prevents hangs at the expense of a little higher server resource usage. But the myth of "IPv6 makes things hang randomly" remains.
  - formerly_proven 5y ago
    It's not a myth when it happens. Last time I tried v6 again on my network (about a year ago) I had these issues. Not a lot of them, but toggling v6 off made them go away. There are fewer issues, true, but having dual-stack does still appear to break some things. I say "appear to" because I'm assuming that it's not actually an issue with v4+v6 dual stack, but rather a problem with misconfigured services (e.g. services having wrong AAAA records, stuff using v6 that doesn't work properly with v6 etc.); from an end-user perspective this does not really matter: There are sometimes issues when v6 is on, which go away by turning v6 off - end user perception: v6 is wonky.
    - mindcrime 5y ago
      Your lived experience is what it is, and I certainly don't mean to contradict you. But just to add another viewpoint for perspective... My ISP (formerly Time Warner, now Spectrum) has been handing out v6 addresses here, and I've been running in dual stack mode, for a good 3 years or more now. And in all that time, I can remember exactly one occasion where IPv6 caused any issue. And that was only because somebody at my employer who was setting up a GCP environment didn't take into account that anybody would be coming in on IPv6, didn't configure the corresponding firewall rules, and it broke using kubectl to access GKS clusters from my home network, as kubectl was defaulting to the v6 connection. So yeah, v6 can cause some weirdness, even now (the event described above was about 3 months ago) but in my experience it is exceedingly rare. YMMV, of course.
      - easrng 5y ago
        I use Spectrum and their IPv6 connectivity drops out relatively frequently, but IPv4 connectivity stays.
throw0101a 5y ago
> The value prop of v6 is: ??? Learn an entirely new networking stack! The value prop of IPv6 is not having to pay US$ 30/IP (and rising) when you need a block of new IPs. Most folks don't need that many public IPs and so simply use RFC 1918 addresses and then implement the kludge that is NAT. NA(P)T was codified in 1999 (RFC 2663), and it is now "background radiation" so people think it's normal because it's all that they've ever know. But we've long gotten to the point where we're now doing double-(CG)NAT, and entire chunk of address space (100.64.0.0/10) has been reserved just for this purpose: * https://en.wikipedia.org/wiki/IPv4_shared_address_space https://en.wikipedia.org/wiki/IPv4_shared_address_space I'm waiting for triple-NATing to start occurring.
- tenebrisalietum 5y ago
  NAT is essentially required in IPv4 due to IPv4 address exhaustion. NAT, when done on the carrier level (CGNAT), more or less prevents external systems from initating connections with anything on your network (without ISP involvement). You can still initiate outgoing connections fine. Sounds great for security, but this enforces the existence of centralized services (middlemen) that you have to use/pay for if you want to have asynchronous communication with anyone that you might not necessarily initiate. If you want a chance at a real decentralized Internet without dependency on tech giants, you're gonna need IPv6.
  - saurik 5y ago
    Does the CGNAT setup you contend with not support NAT-PMP/PCP? (To me that is the reasonable solution to the problem you cite, not IPv6, and I have been thinking it is already widely deployed... just not adopted by developers for some reason.)
    - tenebrisalietum 5y ago
      I don't contend with CGNAT, thankfully, but no one ever moves from IPv4 then everyone's going to eventually be behind a CGNAT at some point. I don't know too much about NAT-PMP/PCP - so I'm looking into it.
MisterTea 5y ago
I believe XP64 was OEM only, there was no retail availability. I had.. uh ... obtained a copy and installed it on my brothers gaming PC and it ran surprisingly well for an OS that barely made it to market.
- formerly_proven 5y ago
  XP x64 was available in retail, I used it for a pretty long time. The biggest issue was lack of drivers for stuff like printers and scanners, though iirc later on the Vista 64-bit drivers would usually work.

yyyk 5y ago

64 bit adoption was far faster. A mere decade after x86_64 was available, just about the entire consumer market switched. The last barely-mainstream 32bit processors were of the Intel Atom line (for notebook), and that ended about a decade ago. Microsoft's backward compatibility guarantee makes the timeline look much longer than it actually is.