15 ms·

It boggles my mind that IPv6 has such a slow roll out (it's been a thing since the early 2000s = twenty years ago). I would have thought that all the major tec

It boggles my mind that IPv6 has such a slow roll out (it's been a thing since the early 2000s = twenty years ago). I would have thought that all the major tech companies supported it years ago on all their infrastructures, websites and apps. But there are still a lot of hold outs. What about IPv6 makes it such a chore to become widespread?

zokier 5y ago
I think its more of a matter of perception than anything. IPv6 adoption has gone pretty smoothly imho, there hasn't been any major blowbacks or anything; for example the Google IPv6 adoption chart trend is steadily increasing. Another thing you can see from Google IPv6 charts that before 2011 IPv6 adoption was near zero. This matches pretty well with IPv4 exhaustion; IANA pool was exhausted in 2011, and APNIC followed later that year. Before that anyone could get IPv4 address pretty liberally, so there was very little reason to think about IPv6. Especially in western world (RIPE/ARIN) where consumption was slower than e.g. APNIC; notably ARIN reached exhaustion only in 2015. https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html In summary, I feel that having third of internet become ipv6 in about a decade seems pretty decent result, considering how complex and especially diverse internet is.
- xxpor 5y ago
  Someone pointed out recently on NANOG the thing that probably killed a TON of IPv6 momentum was when they missed the deadline to get it included in Windows 95. Approximately no one was on the internet before then. (Yes yes you nerds were, but most people weren't)
  - zokier 5y ago
    Seems pretty far fetched to me that there would have ever been a chance to have IPv6 in Win9x. For comparison, afain FreeBSD was the forerunner with IPv6 support, and they got it in 2000. So I'd say they "missed the deadline" by 5+ years. It was probably around 2005 when we realistically had somewhat usable IPv6 support at base OS level.
    - xxpor 5y ago
      I think the point was that it changed the whole demand curve. If the major consumer OS at the time had v6 support things like FreeBSD would have added it earlier.
api 5y ago
Two reasons. First, it's just inertia and backward compatibility. Same reason we still use the x86 instruction set in spite of its issues. Second reason is that long IPs really are kind of inconvenient for IT and network administrator people.
- azernik 5y ago
  IT and network admin people gripe about the long addresses, but when push comes to shove they don't actually make decisions based on that.
nsoxo 5y ago
Why change something that works?
- curiousmindz 5y ago
  HTTP/1.1 also "works", yet we are moving to v2 (edit: more smoothly). Same for many other (low level) techs. But maybe IPv6 is so low level that it has a lot more inertia...
- josephcsible 5y ago
  Because we're running out of IPv4 addresses, and in a lot of cases, NAT doesn't work.
  - throw0101a 5y ago
    > Because we're running out of IPv4 addresses, and in a lot of cases, NAT doesn't work. We have run out of IPv4 addresses. Past tense. Go to a RIR for some and you'll be put on a waiting list. If you want a block of IPv4 space you'll be paying about US$ 30 per IP at the moment.
- supertrope 5y ago
  Video chat. File transfers without a third party host. Cell phones almost always only offer a public address over v6. Internet gaming. VPNs without address conflicts. Not being banned from Wikipedia because someone else with the same CGNAT ISP got banned.
  - jonathantf2 5y ago
    For the average consumer they don't notice a difference. Both my home and mobile ISPs have said they have no plans to offer IPv6 connectivity because it's not a requirement. Users don't care, and until a lot of them do ISPs won't do anything. People can still video chat, play games and use VPNs without v6.
    - supertrope 5y ago
mattashii 5y ago
It was, at some point, routing. Not all (inter)continental data highways are/were IPv6-enabled, meaning that IPv6 does/did not have the performance of IPv4 (latency, bandwidth). Global websites with no global distribution of servers thus kept using IPv4-only to prevent significant performance regressions for the early adopter clients. Similarly, IPv6 hardware accelleration was not very common on consumer/prosumer routing hardware, making it very resource-intensive (much more so than IPv4), resulting in low throughput. ... based on personal research in ~2015-2016
- AceJohnny2 5y ago
  Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers. Performance was abysmal, 2x-10x slower than IPv4. Turns out many of the routers out there can perform IPv4 table lookups in the data-plane (fast-path), but IPv6 is delegated to the control-plane (slow-path), for much slower performance.
  - throw0101a 5y ago
    > Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers. And quite a quick deployment AFAICT: > Free deployed the IPv6 infrastructure in only 5 weeks, from 7 November to 11 December 2007, thanks to an innovative 6rd (IPv6 rapid deployment) proposal by Rémi Després.[44] * https://en.wikipedia.org/wiki/Free_(ISP)#Internet_access https://en.wikipedia.org/wiki/Free_(ISP)#Internet_access * https://en.wikipedia.org/wiki/IPv6_rapid_deployment https://en.wikipedia.org/wiki/IPv6_rapid_deployment
    - blacksmith_tb 5y ago
      Hmm, my experience in the US with CenturyLink Fiber's 6rd implementation suggests it's also slower than IPv4 (I went from ~900/900 to ~500/500 when I enabled it). I decided I could live with that, but it's still a little disappointing.
  - lokedhs 5y ago
    I see the opposite right now, with transfer rates being about the same but latency over IPv4 being quite bad compared to IPv6: Pinging www.google.com with IPv6: $ ping www.google.com PING www.google.com(sc-in-x67.1e100.net (2404:6800:4003:c02::67)) 56 data bytes 64 bytes from sc-in-f103.1e100.net (2404:6800:4003:c02::67): icmp_seq=1 ttl=108 time=4.46 ms 64 bytes from sc-in-x67.1e100.net (2404:6800:4003:c02::67): icmp_seq=2 ttl=108 time=3.73 ms 64 bytes from sc-in-f103.1e100.net (2404:6800:4003:c02::67): icmp_seq=3 ttl=108 time=3.73 ms And with IPv4: $ ping -4 www.google.com PING (142.250.186.100) 56(84) bytes of data. 64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=1 ttl=107 time=317 ms 64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=2 ttl=107 time=317 ms 64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=3 ttl=107 time=317 ms I have no idea why that happens. It's not on all sites though, so it's not like my ISP adds latecy to all IPv4 sites, but rather something to do with routing. The IPv4 traffic might be routed to a google datacentre further away.
unethical_ban 5y ago
I dug into IPv6 a few weeks ago. If you learn it from the ground up, as if you were first learning IPv4, it truly is not more complicated than IPv4+ARP. Length of address may be a reason people don't look at it at first, but if you look at it from an engineering perspective, it makes sense. The only thing I don't like about it, is how they created SLAAC (a way for a client to auto-configure its own IP address without DHCP) - but didn't enable routers to provide DNS information. Therefore, in any useful deployment, you need to deal with SLAAC for IP allocation, and DHCPv6 for DNS information. Outside of that, the spec is pretty decent. ---- Also, damn every ISP and every router company that doesn't 100% support IPv6. Shockingly, this includes Ubiquiti, which is "supposed" to be medium-enterprise grade. ISPs and endpoint network devices are the only reason we don't have IPv6 more prevalent, combined with NAT, CGNAT etc. being good enough to keep the net hobbling along.
- gorgoiler 5y ago
  As of a few years ago you don’t need DHCPv6 to announce DNS servers. Router advertisements can announce a recursive DNS server (RDNSS) which local clients might like to use, eg: https://github.com/radvd-project/radvd/blob/master/radvd.conf.example#L106 https://github.com/radvd-project/radvd/blob/master/radvd.con... Bad luck though if you are using, ahem, AIX or Windows Phone: https://en.m.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems https://en.m.wikipedia.org/wiki/Comparison_of_IPv6_support_i...
- AceJohnny2 5y ago
  > Also, damn every ISP and every router company that doesn't 100% support IPv6. It's extra development and extra testing (in fact it's way more testing due to the combinatorial explosion of IPv4/IPv6 interface schemes). That comes at a cost. > ISPs and endpoint network devices are the only reason we don't have IPv6 more prevalent, combined with NAT, CGNAT etc. being good enough to keep the net hobbling along. ISPs & endpoint devices are the majority of the Internet, as far as complexity is concerned. Upgrading the equipment for HW-acceleration of IPv6 (parity with IPv4) is very costly.
- mercora 5y ago
  > The only thing I don't like about it, is how they created SLAAC (a way for a client to auto-configure its own IP address without DHCP) - but didn't enable routers to provide DNS information. there is RDNSS for router advertisments used with slaac. although it wasnt there initially and support for it might be lacking yet.
IshKebab 5y ago
Give it another 20 years... https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html
- SilverRed 5y ago
  looks like another 10 years at most going by the current rate. And I expect it will speed up at the end when we reach something like 90% and some sites go v6 only.
- fulafel 5y ago
  Note that this is measuring clients of Google services. It's useful for tracking consumer ISPs, but applications that really benefit from e2e connectivity have been and will be moving faster.
- mprovost 5y ago
  IPv6 adoption is slowing and may never converge with v4. It halved from 2019 to 2020. See "Counting IPv6 users": https://blog.apnic.net/2021/02/08/ipv6-in-2020/ https://blog.apnic.net/2021/02/08/ipv6-in-2020/
throw0101a 5y ago
> It boggles my mind that IPv6 has such a slow roll out (it's been a thing since the early 2000s = twenty years ago). IPv4 had just as slow a roll out in some ways. TCP/IP had its flag day in 1983: * https://en.wikipedia.org/wiki/Flag_day_(computing) https://en.wikipedia.org/wiki/Flag_day_(computing) There was early commercialization of the Internet around ±1990, but it didn't really start taking off until around 1994: * https://en.wikipedia.org/wiki/Commercialization_of_the_Internet https://en.wikipedia.org/wiki/Commercialization_of_the_Inter... The Dot-com bubble peaked in 2000: * https://en.wikipedia.org/wiki/Dot-com_bubble https://en.wikipedia.org/wiki/Dot-com_bubble RFC 1918 was published in 1996, and the kludge of NAPT was documented in RFC 2663 in 1999. Given all of the above, I would say it took IPv4 about 15 years to reach the mainstream.
- Macha 5y ago
  That's a different concern though - Promoting the whole use case of the internet vs migration from one protocol to another. If we compare the http to https migration, Firesheep in 2010 demonstrated that maybe migration was the right thing to do rather than just an optional security feature for banks, Lets Encrypt was released to the public in 2014 and by like... 2019 basically all of the internet was HTTPS. There is a long tail to go for the last few sites, and some that have objections to the CA system and are holding out, but really https is just expected these days, which is a much better place than IPv6.
  - throw0101a 5y ago
    > Lets Encrypt was released to the public in 2014 and by like... 2019 basically all of the internet was HTTPS. This is apples and oranges: absolutely zero software upgrades needed to be done to get HTTPS going and/or Let's Encrypt running. I was able to get LE going on our F5 appliances in a few working days with zero changes to the base system/appliance software by simply installing the dehydrated ACME client and all of a sudden dozens of sites where we previously didn't want to pay for a cert were "secure". Network hardware can stay in place for quite a while. Our previous generation of core switches lasted us 7 years before we swapped them out. I wouldn't be surprised some of the mega-chassis routers in ISPs and other telcos sit around as long.
mabbo 5y ago
I recall being at Amazon some years ago when we were running out of IP addresses internally. A natural answer was "Why don't we all just switch to IPv6?". The senior principle project manager in charge put it very simply: "The number of routers that don't support IPv6 that we'd need to replace exceeds the world-wide yearly production of IPv6 routers capable of replacing them. At our current rate of growth, we have less than a year until we run out of IPs." (I'm badly quoting a brilliant person many years after the fact, but that's roughly my memory of the talk she gave.) Major tech companies often have constraints like that which the rest of us wouldn't even imagine.
- smoldesu 5y ago
  I don't know how long ago that was, but I kinda have to call bullshit on her claim (even if it was hyperbole for the sake of making a point). Companies exist to make bespoke solutions for this very purpose, and nowadays outsourcing that kind of work is just natural for Amazon. Hell, they made a deal with Rivian to get a fleet of electric delivery trucks, getting some Chinese manufacturer to slap a Cortex m53 into a shitty plastic enclosure with Ethernet ports can't be that difficult. I bet there are AmazonBasics products that have required more forethought than that.
  - mabbo 5y ago
    It could very well be. But how many of those routers could they make, and how quickly? And for how much? And could they really handle the kind of load that Amazon needed to handle? And how quickly could these bespoke solutions be installed, tested at scale, verified to work? Would the manufacturer provide support if they don't work as expected? The solution that was done was to split the network into sub-networks with just the few proxy gateways between them that were needed. And it worked- I think it's still working that way. That's not free to do (every service owner had to do some networking work), but it's also perhaps less expensive than switching out all the hardware, overall. And rest assured, Amazon always chooses the option that maximizes profit in the long run. Other than that stupid phone.
  - mike_d 5y ago
    A core or edge router in a terabit+ scale network is a far cry from getting someone in China to make you a bunch of Netgear clones. The Cisco 5500 series chassis is about 21 rack units (or about 3 feet) tall to give you an idea of the scale of these devices in the real world. They are also jam packed with custom ASICs that allow packet switching at extremely high speeds, which would need to be redesigned to handle 16 byte addresses.
cmroanirgo 5y ago
For me it's a few things that keep me from fully embracing it, & largely the problem is perception, as others have noted. 1. I'm a small-time self hoster. I need/want to control access to geographic locations and using IPv4 makes that pretty easy. Last time I checked, IPv6 was just so wrong that it's no good to use at all, and most IPv6 addresses were "unknown" in origin. 2. I'm used to the pseudo security that a NAT gives. I hear (ad nausea) about how NAT gives you no security. The simple truth is that obscurity does give yet another layer of protection, especially for machines that you're busily configuring to become secure. Of course, a real sysadmin here will be able to scoff and laugh, but for this homebrew old timer it's true. But also, there's the obfuscation of your IP address when you're behind a NAT. This is pretty important in these ad tracking days. AFAIK (which is almost zero), doesn't IPv6 give adware companies a very good fingerprint on you? 3. All those ICMPv6 messages sniffing (and snooping?) really don't fill me with joy joy happiness. The only recourse is to read some dead boring RFC that my poor overloaded brain doesn't really want to have anything to do with. With IPv4, if you don't want PING, you turn it off, with IPv6.... it's subtle. 4. Firewalls require two sets of independent entries for the same service. So, IPv4 is an address space that's understood. IPv6 really does feel like a Godzillian monstrosity and a chore to type in: double colons between every number and it's in Hex? At least with IPv4 you can type the numbers in pretty rapidly on a numpad. So, I know this answer will be unpopular, especially to professionals, but for everyone I've encountered that's turned it off, the above list is pretty accurate. Every few years I search around for a true "IPv4 to IPv6 for noobs" and every time I only find "It's the same... with these gajillion subtle differences". So, yeah, perception is definitely an issue, but scoffing at NAT doesn't help uptake at all. I really do try to be a good netizen, but it's hard. (that said, I do have a mail server set up to use ipv6 and all is good... except for the lists of unknown sources who hammer away at its security all day, every day)
- chippiewill 5y ago
  Your arguments regarding NAT only make sense when considering carrier grade NAT. With IPv6 you can set up your machine to use "temporary" addresses which will use random addresses from your router's subnet instead of a fixed one (based off of the NIC's mac address) and for a limited duration. The duration is normally some number of hours, but you could make it 10 seconds if you preferred.
yyyk 5y ago
>What about IPv6 makes it such a chore to become widespread? Partly some protocol choices which are quite different from IPv4, but much more importantly - existing users see relatively little benefit from conversion, so most new IPv6 installs are new installations. Eventually the monetary pressure would be enough to get a critical mass to switch, but this hasn't happened yet.
kevin_thibedeau 5y ago
> What about IPv6 makes it such a chore to become widespread? Any code storing an IPv4 address in a uint32_t can be hard to port to IPv6. Likewise, many codebases have their own ad hoc parsers for IPv4 dotted quads and would choke on anything else.
- xxpor 5y ago
  The additional 12 bytes to store the v6 address might not be trivial to find as well (connection state tables in kernels, additional space in DBs). There's also MTU issues.
geofft 5y ago
> What about IPv6 makes it such a chore to become widespread? IPv6 is not just a straightforward extension of IPv4 to bigger addresses (plus some cleverness for how to route between them, if at all). There's a whole lot of other complexity in the protocol. There's a way you're supposed to get addresses that's not DHCP, and a good chunk of clients don't have or only recently got a DHCPv6 implementation. You're supposed to have an efficient hardware multicast implementation. Addresses are structured (unlike IPv4 CIDR), and an entire /64 is supposed to be assigned to a single customer / subnet so they can auto-configure addresses based on that. In turn, the way to auto-configure your (NAT-less) IPv6 address was to use your MAC address, i.e., give advertisers a free permanent third-party cookie, and the RFC to do something else only came out in 2007. And, of course, for better or worse people have designs that involve NAT, and until very recently IPv6 basically demanded that you rip all of it out. Regardless of whether you think these changes are good or not, they are certainly a chore.
- azernik 5y ago
  Having implemented SLAAC and address anonymization: These are very, very simple protocols.
  - geofft 5y ago
    Oh, sure, but my point isn't about implementation complexity, it's about network architecture. SLAAC doesn't work the way DHCP works. Do you have an IPAM tool that assigns addresses? Do you have a VMM/private cloud where addresses are in a database and you set up firewall rules? Do you have a guest wifi network where you assign a quarantine IP with a short lease and then a real IP once they authenticate? None of that works with SLAAC. Especially if you have an existing IPv4 network and are rolling out dual-stack and have no interest in breaking IPv4, adding IPv6 via SLAAC is hardly a matter of adding another column in your schema. It's an architectural change. Again, maybe that change is good, but that's the chore - not implementing the protocol (which is basically ip link | sed | ip addr add). For privacy addresses, if you were considering implementing IPv6 before they were widespread, you'd have to figure out a way to keep from leaking them. The obvious approach is NAT, but that's effectively not an option. So you decide not to make IPv6 available to clients, only servers that already have fixed IPv4 addresses and don't roam. Or you do manual (non-SLAAC, non-DHCPv6 because that wasn't an option) configuration. Once they became available and common in people's clients, sure, but that means we didn't have "20 years" for people to offer IPv6 on guest wifi networks, we had a lot less. Same with NATs. Implementing "not using a NAT" is absolutely trivial; you just... don't. Redesigning your network architecture not to use one, however meritorious it may be, is a massive task.
forty 5y ago
It's all about incentive I guess. What do they win by supporting ipv6? From the service provider point of view, as long as their customers can reach them with ipv4, they have no reasons to switch. From the customer ISP point of view, as long as services people use provide an ipv4 option, there is no reasons to switch. Maybe the ones that have the most reasons to switch are new internet services and new ISP which might have a hard time getting ipv4 blocks. But that's just one more reason for established services not to move too fast :/
- eppp 5y ago
  Not only do you have to support ipv6, ipv4 will never go away on any meaningful timescale. So even if you do the right thing and deploy it you still have the same ipv4 address constraints. There is no winning.
azernik 5y ago
Having done some work on implementation/migration: EVERYTHING needs to work. There's a hell of a lot of software (and, even worse, hardware) that encodes assumptions about IPv4. Everything from userspace asking specifically parsing only IPv4 addresses, to only listening for IPv4 incoming connections, to variables using the IPv4-only type, &c. And let's not even start on the L3 hardware acceleration built into so much networking equipment. You can't flip the switch when 75% of the stuff on your device is ready. The remaining 25% will break, badly. You need to switch over every single piece of code. And then before you get any benefit out of it, you need to do the same on every remote system you want to talk to. This is the magic and the terror of internetworking. Before IP, you had to go through this nightmare for changes at many different layers of the stack. With the clean-ish separation of IP, only one layer was make-or-break like this: layer 3. Any change to layer 3 is horrifically difficult, purely as a deployment/management challenge.
- kazen44 5y ago
  this comments hit up a good point, the lower in the OSI stack you go, the harder it is to initiate change. There is still some (mostly industrial) hardware that has lackluster TCP/IP support at best (for instance, assuming the netmask is always a /24...). migrating these networks to ipv6 is not possible, and doing 6to4 adds a crapton of complexity.
  - azernik 5y ago
    It's not about "lower". We can, and do, make massive , non-backwards-compatible changes in layers 1 and 2 every few years and no one is the wiser. Layer 3 is special. It makes that flexibility in all the other layers possible, but keeps none for itself.
    - kazen44 5y ago
      mind you though, that layer 3 and 4 are somewhat interlinked.
bipson 5y ago
Even at organizations that have considerably smaller networks than Google, Amazon, Facebook and Co there are just seemingly insurmountable numbers of "small" problems that discourage all the involved parties to adopt. We had IPv6 at our research area 10 years ago. Admins changed, and it was wind down bit by bit, because "it made problems". Not only that, I learned that the the general view over all of the admin-staff in our organization (a larger "Technical university" in Europe) agreed that IPv6 "makes problems" and nobody wants it. Change is painful...? It is a shame, but what can you do?

zokier 5y ago

I think its more of a matter of perception than anything. IPv6 adoption has gone pretty smoothly imho, there hasn't been any major blowbacks or anything; for example the Google IPv6 adoption chart trend is steadily increasing. Another thing you can see from Google IPv6 charts that before 2011 IPv6 adoption was near zero. This matches pretty well with IPv4 exhaustion; IANA pool was exhausted in 2011, and APNIC followed later that year. Before that anyone could get IPv4 address pretty liberally, so there was very little reason to think about IPv6. Especially in western world (RIPE/ARIN) where consumption was slower than e.g. APNIC; notably ARIN reached exhaustion only in 2015. https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html In summary, I feel that having third of internet become ipv6 in about a decade seems pretty decent result, considering how complex and especially diverse internet is.

xxpor 5y ago
Someone pointed out recently on NANOG the thing that probably killed a TON of IPv6 momentum was when they missed the deadline to get it included in Windows 95. Approximately no one was on the internet before then. (Yes yes you nerds were, but most people weren't)
- zokier 5y ago
  Seems pretty far fetched to me that there would have ever been a chance to have IPv6 in Win9x. For comparison, afain FreeBSD was the forerunner with IPv6 support, and they got it in 2000. So I'd say they "missed the deadline" by 5+ years. It was probably around 2005 when we realistically had somewhat usable IPv6 support at base OS level.
  - xxpor 5y ago
    I think the point was that it changed the whole demand curve. If the major consumer OS at the time had v6 support things like FreeBSD would have added it earlier.

api 5y ago

Two reasons. First, it's just inertia and backward compatibility. Same reason we still use the x86 instruction set in spite of its issues. Second reason is that long IPs really are kind of inconvenient for IT and network administrator people.

azernik 5y ago
IT and network admin people gripe about the long addresses, but when push comes to shove they don't actually make decisions based on that.

nsoxo 5y ago

Why change something that works?

curiousmindz 5y ago
HTTP/1.1 also "works", yet we are moving to v2 (edit: more smoothly). Same for many other (low level) techs. But maybe IPv6 is so low level that it has a lot more inertia...
josephcsible 5y ago
Because we're running out of IPv4 addresses, and in a lot of cases, NAT doesn't work.
- throw0101a 5y ago
  > Because we're running out of IPv4 addresses, and in a lot of cases, NAT doesn't work. We have run out of IPv4 addresses. Past tense. Go to a RIR for some and you'll be put on a waiting list. If you want a block of IPv4 space you'll be paying about US$ 30 per IP at the moment.
supertrope 5y ago
Video chat. File transfers without a third party host. Cell phones almost always only offer a public address over v6. Internet gaming. VPNs without address conflicts. Not being banned from Wikipedia because someone else with the same CGNAT ISP got banned.
- jonathantf2 5y ago
  For the average consumer they don't notice a difference. Both my home and mobile ISPs have said they have no plans to offer IPv6 connectivity because it's not a requirement. Users don't care, and until a lot of them do ISPs won't do anything. People can still video chat, play games and use VPNs without v6.
  - supertrope 5y ago

mattashii 5y ago

It was, at some point, routing. Not all (inter)continental data highways are/were IPv6-enabled, meaning that IPv6 does/did not have the performance of IPv4 (latency, bandwidth). Global websites with no global distribution of servers thus kept using IPv4-only to prevent significant performance regressions for the early adopter clients. Similarly, IPv6 hardware accelleration was not very common on consumer/prosumer routing hardware, making it very resource-intensive (much more so than IPv4), resulting in low throughput. ... based on personal research in ~2015-2016

AceJohnny2 5y ago
Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers. Performance was abysmal, 2x-10x slower than IPv4. Turns out many of the routers out there can perform IPv4 table lookups in the data-plane (fast-path), but IPv6 is delegated to the control-plane (slow-path), for much slower performance.
- throw0101a 5y ago
  > Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers. And quite a quick deployment AFAICT: > Free deployed the IPv6 infrastructure in only 5 weeks, from 7 November to 11 December 2007, thanks to an innovative 6rd (IPv6 rapid deployment) proposal by Rémi Després.[44] * https://en.wikipedia.org/wiki/Free_(ISP)#Internet_access https://en.wikipedia.org/wiki/Free_(ISP)#Internet_access * https://en.wikipedia.org/wiki/IPv6_rapid_deployment https://en.wikipedia.org/wiki/IPv6_rapid_deployment
  - blacksmith_tb 5y ago
    Hmm, my experience in the US with CenturyLink Fiber's 6rd implementation suggests it's also slower than IPv4 (I went from ~900/900 to ~500/500 when I enabled it). I decided I could live with that, but it's still a little disappointing.
- lokedhs 5y ago
  I see the opposite right now, with transfer rates being about the same but latency over IPv4 being quite bad compared to IPv6: Pinging www.google.com with IPv6: $ ping www.google.com PING www.google.com(sc-in-x67.1e100.net (2404:6800:4003:c02::67)) 56 data bytes 64 bytes from sc-in-f103.1e100.net (2404:6800:4003:c02::67): icmp_seq=1 ttl=108 time=4.46 ms 64 bytes from sc-in-x67.1e100.net (2404:6800:4003:c02::67): icmp_seq=2 ttl=108 time=3.73 ms 64 bytes from sc-in-f103.1e100.net (2404:6800:4003:c02::67): icmp_seq=3 ttl=108 time=3.73 ms And with IPv4: $ ping -4 www.google.com PING (142.250.186.100) 56(84) bytes of data. 64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=1 ttl=107 time=317 ms 64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=2 ttl=107 time=317 ms 64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=3 ttl=107 time=317 ms I have no idea why that happens. It's not on all sites though, so it's not like my ISP adds latecy to all IPv4 sites, but rather something to do with routing. The IPv4 traffic might be routed to a google datacentre further away.

unethical_ban 5y ago

I dug into IPv6 a few weeks ago. If you learn it from the ground up, as if you were first learning IPv4, it truly is not more complicated than IPv4+ARP. Length of address may be a reason people don't look at it at first, but if you look at it from an engineering perspective, it makes sense. The only thing I don't like about it, is how they created SLAAC (a way for a client to auto-configure its own IP address without DHCP) - but didn't enable routers to provide DNS information. Therefore, in any useful deployment, you need to deal with SLAAC for IP allocation, and DHCPv6 for DNS information. Outside of that, the spec is pretty decent. ---- Also, damn every ISP and every router company that doesn't 100% support IPv6. Shockingly, this includes Ubiquiti, which is "supposed" to be medium-enterprise grade. ISPs and endpoint network devices are the only reason we don't have IPv6 more prevalent, combined with NAT, CGNAT etc. being good enough to keep the net hobbling along.

gorgoiler 5y ago
As of a few years ago you don’t need DHCPv6 to announce DNS servers. Router advertisements can announce a recursive DNS server (RDNSS) which local clients might like to use, eg: https://github.com/radvd-project/radvd/blob/master/radvd.conf.example#L106 https://github.com/radvd-project/radvd/blob/master/radvd.con... Bad luck though if you are using, ahem, AIX or Windows Phone: https://en.m.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems https://en.m.wikipedia.org/wiki/Comparison_of_IPv6_support_i...
AceJohnny2 5y ago
> Also, damn every ISP and every router company that doesn't 100% support IPv6. It's extra development and extra testing (in fact it's way more testing due to the combinatorial explosion of IPv4/IPv6 interface schemes). That comes at a cost. > ISPs and endpoint network devices are the only reason we don't have IPv6 more prevalent, combined with NAT, CGNAT etc. being good enough to keep the net hobbling along. ISPs & endpoint devices are the majority of the Internet, as far as complexity is concerned. Upgrading the equipment for HW-acceleration of IPv6 (parity with IPv4) is very costly.
mercora 5y ago
> The only thing I don't like about it, is how they created SLAAC (a way for a client to auto-configure its own IP address without DHCP) - but didn't enable routers to provide DNS information. there is RDNSS for router advertisments used with slaac. although it wasnt there initially and support for it might be lacking yet.

IshKebab 5y ago

Give it another 20 years... https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html

SilverRed 5y ago
looks like another 10 years at most going by the current rate. And I expect it will speed up at the end when we reach something like 90% and some sites go v6 only.
fulafel 5y ago
Note that this is measuring clients of Google services. It's useful for tracking consumer ISPs, but applications that really benefit from e2e connectivity have been and will be moving faster.
mprovost 5y ago
IPv6 adoption is slowing and may never converge with v4. It halved from 2019 to 2020. See "Counting IPv6 users": https://blog.apnic.net/2021/02/08/ipv6-in-2020/ https://blog.apnic.net/2021/02/08/ipv6-in-2020/

throw0101a 5y ago

> It boggles my mind that IPv6 has such a slow roll out (it's been a thing since the early 2000s = twenty years ago). IPv4 had just as slow a roll out in some ways. TCP/IP had its flag day in 1983: * https://en.wikipedia.org/wiki/Flag_day_(computing) https://en.wikipedia.org/wiki/Flag_day_(computing) There was early commercialization of the Internet around ±1990, but it didn't really start taking off until around 1994: * https://en.wikipedia.org/wiki/Commercialization_of_the_Internet https://en.wikipedia.org/wiki/Commercialization_of_the_Inter... The Dot-com bubble peaked in 2000: * https://en.wikipedia.org/wiki/Dot-com_bubble https://en.wikipedia.org/wiki/Dot-com_bubble RFC 1918 was published in 1996, and the kludge of NAPT was documented in RFC 2663 in 1999. Given all of the above, I would say it took IPv4 about 15 years to reach the mainstream.

Macha 5y ago
That's a different concern though - Promoting the whole use case of the internet vs migration from one protocol to another. If we compare the http to https migration, Firesheep in 2010 demonstrated that maybe migration was the right thing to do rather than just an optional security feature for banks, Lets Encrypt was released to the public in 2014 and by like... 2019 basically all of the internet was HTTPS. There is a long tail to go for the last few sites, and some that have objections to the CA system and are holding out, but really https is just expected these days, which is a much better place than IPv6.
- throw0101a 5y ago
  > Lets Encrypt was released to the public in 2014 and by like... 2019 basically all of the internet was HTTPS. This is apples and oranges: absolutely zero software upgrades needed to be done to get HTTPS going and/or Let's Encrypt running. I was able to get LE going on our F5 appliances in a few working days with zero changes to the base system/appliance software by simply installing the dehydrated ACME client and all of a sudden dozens of sites where we previously didn't want to pay for a cert were "secure". Network hardware can stay in place for quite a while. Our previous generation of core switches lasted us 7 years before we swapped them out. I wouldn't be surprised some of the mega-chassis routers in ISPs and other telcos sit around as long.

mabbo 5y ago

I recall being at Amazon some years ago when we were running out of IP addresses internally. A natural answer was "Why don't we all just switch to IPv6?". The senior principle project manager in charge put it very simply: "The number of routers that don't support IPv6 that we'd need to replace exceeds the world-wide yearly production of IPv6 routers capable of replacing them. At our current rate of growth, we have less than a year until we run out of IPs." (I'm badly quoting a brilliant person many years after the fact, but that's roughly my memory of the talk she gave.) Major tech companies often have constraints like that which the rest of us wouldn't even imagine.

smoldesu 5y ago
I don't know how long ago that was, but I kinda have to call bullshit on her claim (even if it was hyperbole for the sake of making a point). Companies exist to make bespoke solutions for this very purpose, and nowadays outsourcing that kind of work is just natural for Amazon. Hell, they made a deal with Rivian to get a fleet of electric delivery trucks, getting some Chinese manufacturer to slap a Cortex m53 into a shitty plastic enclosure with Ethernet ports can't be that difficult. I bet there are AmazonBasics products that have required more forethought than that.
- mabbo 5y ago
  It could very well be. But how many of those routers could they make, and how quickly? And for how much? And could they really handle the kind of load that Amazon needed to handle? And how quickly could these bespoke solutions be installed, tested at scale, verified to work? Would the manufacturer provide support if they don't work as expected? The solution that was done was to split the network into sub-networks with just the few proxy gateways between them that were needed. And it worked- I think it's still working that way. That's not free to do (every service owner had to do some networking work), but it's also perhaps less expensive than switching out all the hardware, overall. And rest assured, Amazon always chooses the option that maximizes profit in the long run. Other than that stupid phone.
- mike_d 5y ago
  A core or edge router in a terabit+ scale network is a far cry from getting someone in China to make you a bunch of Netgear clones. The Cisco 5500 series chassis is about 21 rack units (or about 3 feet) tall to give you an idea of the scale of these devices in the real world. They are also jam packed with custom ASICs that allow packet switching at extremely high speeds, which would need to be redesigned to handle 16 byte addresses.

cmroanirgo 5y ago

For me it's a few things that keep me from fully embracing it, & largely the problem is perception, as others have noted. 1. I'm a small-time self hoster. I need/want to control access to geographic locations and using IPv4 makes that pretty easy. Last time I checked, IPv6 was just so wrong that it's no good to use at all, and most IPv6 addresses were "unknown" in origin. 2. I'm used to the pseudo security that a NAT gives. I hear (ad nausea) about how NAT gives you no security. The simple truth is that obscurity does give yet another layer of protection, especially for machines that you're busily configuring to become secure. Of course, a real sysadmin here will be able to scoff and laugh, but for this homebrew old timer it's true. But also, there's the obfuscation of your IP address when you're behind a NAT. This is pretty important in these ad tracking days. AFAIK (which is almost zero), doesn't IPv6 give adware companies a very good fingerprint on you? 3. All those ICMPv6 messages sniffing (and snooping?) really don't fill me with joy joy happiness. The only recourse is to read some dead boring RFC that my poor overloaded brain doesn't really want to have anything to do with. With IPv4, if you don't want PING, you turn it off, with IPv6.... it's subtle. 4. Firewalls require two sets of independent entries for the same service. So, IPv4 is an address space that's understood. IPv6 really does feel like a Godzillian monstrosity and a chore to type in: double colons between every number and it's in Hex? At least with IPv4 you can type the numbers in pretty rapidly on a numpad. So, I know this answer will be unpopular, especially to professionals, but for everyone I've encountered that's turned it off, the above list is pretty accurate. Every few years I search around for a true "IPv4 to IPv6 for noobs" and every time I only find "It's the same... with these gajillion subtle differences". So, yeah, perception is definitely an issue, but scoffing at NAT doesn't help uptake at all. I really do try to be a good netizen, but it's hard. (that said, I do have a mail server set up to use ipv6 and all is good... except for the lists of unknown sources who hammer away at its security all day, every day)

chippiewill 5y ago
Your arguments regarding NAT only make sense when considering carrier grade NAT. With IPv6 you can set up your machine to use "temporary" addresses which will use random addresses from your router's subnet instead of a fixed one (based off of the NIC's mac address) and for a limited duration. The duration is normally some number of hours, but you could make it 10 seconds if you preferred.

yyyk 5y ago

>What about IPv6 makes it such a chore to become widespread? Partly some protocol choices which are quite different from IPv4, but much more importantly - existing users see relatively little benefit from conversion, so most new IPv6 installs are new installations. Eventually the monetary pressure would be enough to get a critical mass to switch, but this hasn't happened yet.

kevin_thibedeau 5y ago

> What about IPv6 makes it such a chore to become widespread? Any code storing an IPv4 address in a uint32_t can be hard to port to IPv6. Likewise, many codebases have their own ad hoc parsers for IPv4 dotted quads and would choke on anything else.

xxpor 5y ago
The additional 12 bytes to store the v6 address might not be trivial to find as well (connection state tables in kernels, additional space in DBs). There's also MTU issues.

geofft 5y ago

> What about IPv6 makes it such a chore to become widespread? IPv6 is not just a straightforward extension of IPv4 to bigger addresses (plus some cleverness for how to route between them, if at all). There's a whole lot of other complexity in the protocol. There's a way you're supposed to get addresses that's not DHCP, and a good chunk of clients don't have or only recently got a DHCPv6 implementation. You're supposed to have an efficient hardware multicast implementation. Addresses are structured (unlike IPv4 CIDR), and an entire /64 is supposed to be assigned to a single customer / subnet so they can auto-configure addresses based on that. In turn, the way to auto-configure your (NAT-less) IPv6 address was to use your MAC address, i.e., give advertisers a free permanent third-party cookie, and the RFC to do something else only came out in 2007. And, of course, for better or worse people have designs that involve NAT, and until very recently IPv6 basically demanded that you rip all of it out. Regardless of whether you think these changes are good or not, they are certainly a chore.

azernik 5y ago
Having implemented SLAAC and address anonymization: These are very, very simple protocols.
- geofft 5y ago
  Oh, sure, but my point isn't about implementation complexity, it's about network architecture. SLAAC doesn't work the way DHCP works. Do you have an IPAM tool that assigns addresses? Do you have a VMM/private cloud where addresses are in a database and you set up firewall rules? Do you have a guest wifi network where you assign a quarantine IP with a short lease and then a real IP once they authenticate? None of that works with SLAAC. Especially if you have an existing IPv4 network and are rolling out dual-stack and have no interest in breaking IPv4, adding IPv6 via SLAAC is hardly a matter of adding another column in your schema. It's an architectural change. Again, maybe that change is good, but that's the chore - not implementing the protocol (which is basically ip link | sed | ip addr add). For privacy addresses, if you were considering implementing IPv6 before they were widespread, you'd have to figure out a way to keep from leaking them. The obvious approach is NAT, but that's effectively not an option. So you decide not to make IPv6 available to clients, only servers that already have fixed IPv4 addresses and don't roam. Or you do manual (non-SLAAC, non-DHCPv6 because that wasn't an option) configuration. Once they became available and common in people's clients, sure, but that means we didn't have "20 years" for people to offer IPv6 on guest wifi networks, we had a lot less. Same with NATs. Implementing "not using a NAT" is absolutely trivial; you just... don't. Redesigning your network architecture not to use one, however meritorious it may be, is a massive task.

forty 5y ago

It's all about incentive I guess. What do they win by supporting ipv6? From the service provider point of view, as long as their customers can reach them with ipv4, they have no reasons to switch. From the customer ISP point of view, as long as services people use provide an ipv4 option, there is no reasons to switch. Maybe the ones that have the most reasons to switch are new internet services and new ISP which might have a hard time getting ipv4 blocks. But that's just one more reason for established services not to move too fast :/

eppp 5y ago
Not only do you have to support ipv6, ipv4 will never go away on any meaningful timescale. So even if you do the right thing and deploy it you still have the same ipv4 address constraints. There is no winning.

azernik 5y ago

Having done some work on implementation/migration: EVERYTHING needs to work. There's a hell of a lot of software (and, even worse, hardware) that encodes assumptions about IPv4. Everything from userspace asking specifically parsing only IPv4 addresses, to only listening for IPv4 incoming connections, to variables using the IPv4-only type, &c. And let's not even start on the L3 hardware acceleration built into so much networking equipment. You can't flip the switch when 75% of the stuff on your device is ready. The remaining 25% will break, badly. You need to switch over every single piece of code. And then before you get any benefit out of it, you need to do the same on every remote system you want to talk to. This is the magic and the terror of internetworking. Before IP, you had to go through this nightmare for changes at many different layers of the stack. With the clean-ish separation of IP, only one layer was make-or-break like this: layer 3. Any change to layer 3 is horrifically difficult, purely as a deployment/management challenge.

kazen44 5y ago
this comments hit up a good point, the lower in the OSI stack you go, the harder it is to initiate change. There is still some (mostly industrial) hardware that has lackluster TCP/IP support at best (for instance, assuming the netmask is always a /24...). migrating these networks to ipv6 is not possible, and doing 6to4 adds a crapton of complexity.
- azernik 5y ago
  It's not about "lower". We can, and do, make massive , non-backwards-compatible changes in layers 1 and 2 every few years and no one is the wiser. Layer 3 is special. It makes that flexibility in all the other layers possible, but keeps none for itself.
  - kazen44 5y ago
    mind you though, that layer 3 and 4 are somewhat interlinked.

bipson 5y ago

Even at organizations that have considerably smaller networks than Google, Amazon, Facebook and Co there are just seemingly insurmountable numbers of "small" problems that discourage all the involved parties to adopt. We had IPv6 at our research area 10 years ago. Admins changed, and it was wind down bit by bit, because "it made problems". Not only that, I learned that the the general view over all of the admin-staff in our organization (a larger "Technical university" in Europe) agreed that IPv6 "makes problems" and nobody wants it. Change is painful...? It is a shame, but what can you do?