6 ms·

And yet, three of the four most valuable companies in the world are cloud providers, and none of them have more than rudimentary support for IPv6. This is a di

by squeed 9y ago

And yet, three of the four most valuable companies in the world are cloud providers, and none of them have more than rudimentary support for IPv6. This is a disaster. Half the world is not yet online. If we're going to change that, then we need to move to ipv6, and soon.

cronjobber 9y ago
"We" don't have to move to ipv6, even if "they" have to. The internet can plausibly support both protocols forever.
- libeclipse 9y ago
  I disagree, but even still suppose you're right. Why? ipv6 is so much better than ipv4 it's insane that we're even discussing this.
  - cronjobber 9y ago
    It sucks at being compatible with ipv4. The "billion dollar mistake" :-) It also sucks at having software/hardware stacks nearly as well debugged as those for ipv4, which means running ipv6 at all is a security risk. Nobody would switch for sundry technical advantages. The main driver for conversion is that ipv4 addresses are scarce. As soon as "we" seriously "move to ipv6", however, the scarcity driven pressure to convert is relieved. We're bound to reach an equilibrium that will include ipv4 for a long time, possibly forever.
    - zAy0LfpBZLC8mAC 9y ago
      > It sucks at being compatible with ipv4. The "billion dollar mistake" :-) You cannot make it compatible. The whole point is address extension, and a legacy IPv4 endpoint cannot possibly talk to a new, extended-address endpoint. > It also sucks at having software/hardware stacks nearly as well debugged as those for ipv4, which means running ipv6 at all is a security risk. There is no "stack". The software above the IP layer is still UDP, TCP, HTTP, SMTP, ... > Nobody would switch for sundry technical advantages. Yeah, actually, lots of competent people do, because NAT and duplicate addresses just cause so many pointless problems. > As soon as "we" seriously "move to ipv6", however, the scarcity driven pressure to convert is relieved. Yep, the pressure to convert will be relieved because people simply won't bother setting up IPv4 in the first place at some point because it adds so much unnecessary complexity, so no need to convert. And once that happens, even the last holdouts will enable IPv6, at which point IPv4 will be a largely useless legacy protocol that just causes maintenance costs for nothing.
      - pjc50 9y ago
        > The software above the IP layer is still UDP, TCP, HTTP, SMTP Yes, almost all of which has to be aware of which address family it's using in order to work.
        stephen_g 9y ago
        I've been writing all my socket code (this is embedded so plain C) to be automatically compatible with either IPv4 or IPv6 for, what, ten years? I thought everybody did that (it's best practice). Don't most higher level languages also just do this by default under the hood?
    - libeclipse 9y ago
      Meh, not major problems. Those will inevitably go away as more and more people adopt ipv6. However, I feel as though maybe developing countries might stubbornly stay on ipv4. They're already double-NATing right now, and it's likely that developed countries will sell off their ipv4 ranges once they've made the switch.
      - fermuch 9y ago
        Brazilian here. Not sure if I'm part of the "developing country" category, but most major ISPs already give ipv6 for home users. I've been using ipv6 since a few years without even realizing until I entered the router and saw an ipv6 address along with an ipv4.
    - mgbmtl 9y ago
      IPv4 has a lot of complexity: - NAT and CG-NAT for big networks is complex, resource-intensive. - Fragmentation on IPv4 requires more work/complexity from routers. - Some of my friends seem to think that calculating /29 IPv4 networks is simple, but I don't deal with this often and it really annoys me (yes, even with ipcalc). Not to mention the number of addresses lost due to routing (I often use link-local addresses on IPv6). Start moving now, progressively, or you'll be forced to do it in a rush later on. This isn't too different than https adoption. Those who minimized its importance ("oh, that's just internal communication, it can be plain http") got seriously bit.
- simias 9y ago
  The main reason I haven't switched my networks to IPv6 is that I plainly don't want to support both protocols at the same time. If I could just switch over to IPv6 and leave v4 behind I would, but I just can't be bothered to do twice the work every time I setup a firewall or a router. Double the config, double the tests and on top of that you have to make sure everything inter-operates smoothly when IPv4 alone still just works. As you mention in your other post it really is the "billion dollar mistake", it's obvious to me in hindsight that they should have made IPv6 completely backwards compatible with IPv4, no matter the cost. Have a deprecation procedure later on if you want to remove the hacks necessary to support IPv4. Have a clear and simple upgrade path, one step at a time. Sure, having a clean new standard is compelling but clearly it's making things way more difficult that they ought to be. And that's how we end up more than 20 years after RFC1883 was released with "barely" 20% adoption. NATing was easier than IPv6, so people NAT'ed everything and the internet became the net.
  - zAy0LfpBZLC8mAC 9y ago
    > As you mention in your other post it really is the "billion dollar mistake", it's obvious to me in hindsight that they should have made IPv6 completely backwards compatible with IPv4, no matter the cost. It's not a matter of cost, it's simply impossible. IPv4 has a 32 bit field for the source address and a 32 bit field for the destination address, and every connection over IP needs to send packets back and forth between the two addresses. As soon as one party has a longer address, the other party has to know how to handle that, otherwise, they cannot possibly communicate. The only point where compatibility would be possible to some degree is the network, but (a) that compatibility is in effect a tunnel, and there are lots of ways to tunnel IPv6 over IPv4 just fine, and (b) most of the global internet supports IPv6 just fine, and has been for a long time. The problem is the migration of the endpoints, not so much the network.
    - simias 9y ago
      I actually started replying to your comment with my master plan to make an "IPv6 in IPv4" but I realized that I was probably going to make an ass of myself since plenty of much more clever people have worked on the subject for a long longer than I did. But I guess my main issue with this is: >(a) that compatibility is in effect a tunnel, and there are lots of ways to tunnel IPv6 over IPv4 just fine I agree that no matter how you slice it, at some point if you want to transition you'll have to tunnel things. But why are there "lots of ways" to do it? Why isn't there one single, "it just works" way to add compatibility? IMO this should have been a core feature of the standard, bullet point #2, just below "add more addresses". Explain in details how the transition will be made, how you convert an IPv4 into IPv6 incrementally while not breaking anything. Sure it's hard to make a one-size-fits all, but all the corners you have to cut and just make it work. Why isn't the IPv6 my ISP provides simply an extension of my IPv4? If my IPv4 is 216.58.213.174, why isn't the IPv6 216.58.213.174.[more stuff]? Why can I just concatenate my IPv4 public and NAT'ed LAN IP to get a valid IPv6? `ifconfig eth0 inet6 216.58.213.174:192.168.0.101/32` and here we go. It looks familiar, I understand what it means. You could even standardize it to make the IPv4 always be the low bytes of the IPv6 address or something like that, this way I don't have to worry about two sets of addresses. Instead it's `ifconfig eth0 inet6 2001:41d0:000a:050d::1 prefixlen 128 accept_rtadv no_radr`. Ah. I'm sure there's a good reason to make those changes but I can't really be bothered to figure them out as long as IPv4 just works. I'll get around to learn it, eventually, maybe in a few months when I read an article on HN telling me that we're at 21% worldwide adoption.
re 9y ago
What is "more than rudimentary" support? AWS supports public IPv6 for virtual instances, all three support it for their load balancer products, and AWS supports it for a number of additional services (S3, CloudFront, WAF). Most of this support has been released within the last year, and I'm sure that this is work that's been in progress for a while and that improved support is coming. Cloud providers are ready for developers to build products accessible over IPv6. Are developers ready to build them?
- buzer 9y ago
  Let me past something that I posted to Calico Slack about a week ago: > Has anyone tried running IPv6 in AWS? It kinda seems like using it for containers is still very messy. IPs are assigned via DHCPv6 and you cannot actually turn off src/dest checking, so to assign public IPv6 address on each container, you would need to assign each IP address one by one on the interface via AWS API and use a hook in host's DHCPv6 client that adds the IPv6 address to NDP proxy (not 100% sure if this is required) and disables assigning it to interface. With this, you would get 10-30 IPv6 addresses per interface and with some additional hacks to use multiple interfaces you could possibly get 240 IPv6 addresses per instance on larger instances (or well, 16xlarge instances give 15*50) Though admittedly even if there was a support for getting prefixes to instances, it would still take time for other things to get support for it (e.g. Kubernetes)
  - wmf 9y ago
    You have to admit you are pushing it to the limit there. Most people just want one IPv6 address per VM and that is working.
    - zAy0LfpBZLC8mAC 9y ago
      Just because most people want a broken setup, doesn't make it any less broken.

by squeed 9y ago

cronjobber 9y ago

"We" don't have to move to ipv6, even if "they" have to. The internet can plausibly support both protocols forever.

libeclipse 9y ago
I disagree, but even still suppose you're right. Why? ipv6 is so much better than ipv4 it's insane that we're even discussing this.
- cronjobber 9y ago
  It sucks at being compatible with ipv4. The "billion dollar mistake" :-) It also sucks at having software/hardware stacks nearly as well debugged as those for ipv4, which means running ipv6 at all is a security risk. Nobody would switch for sundry technical advantages. The main driver for conversion is that ipv4 addresses are scarce. As soon as "we" seriously "move to ipv6", however, the scarcity driven pressure to convert is relieved. We're bound to reach an equilibrium that will include ipv4 for a long time, possibly forever.
  - zAy0LfpBZLC8mAC 9y ago
    > It sucks at being compatible with ipv4. The "billion dollar mistake" :-) You cannot make it compatible. The whole point is address extension, and a legacy IPv4 endpoint cannot possibly talk to a new, extended-address endpoint. > It also sucks at having software/hardware stacks nearly as well debugged as those for ipv4, which means running ipv6 at all is a security risk. There is no "stack". The software above the IP layer is still UDP, TCP, HTTP, SMTP, ... > Nobody would switch for sundry technical advantages. Yeah, actually, lots of competent people do, because NAT and duplicate addresses just cause so many pointless problems. > As soon as "we" seriously "move to ipv6", however, the scarcity driven pressure to convert is relieved. Yep, the pressure to convert will be relieved because people simply won't bother setting up IPv4 in the first place at some point because it adds so much unnecessary complexity, so no need to convert. And once that happens, even the last holdouts will enable IPv6, at which point IPv4 will be a largely useless legacy protocol that just causes maintenance costs for nothing.
    - pjc50 9y ago
      > The software above the IP layer is still UDP, TCP, HTTP, SMTP Yes, almost all of which has to be aware of which address family it's using in order to work.
      - stephen_g 9y ago
        I've been writing all my socket code (this is embedded so plain C) to be automatically compatible with either IPv4 or IPv6 for, what, ten years? I thought everybody did that (it's best practice). Don't most higher level languages also just do this by default under the hood?
  - libeclipse 9y ago
    Meh, not major problems. Those will inevitably go away as more and more people adopt ipv6. However, I feel as though maybe developing countries might stubbornly stay on ipv4. They're already double-NATing right now, and it's likely that developed countries will sell off their ipv4 ranges once they've made the switch.
    - fermuch 9y ago
      Brazilian here. Not sure if I'm part of the "developing country" category, but most major ISPs already give ipv6 for home users. I've been using ipv6 since a few years without even realizing until I entered the router and saw an ipv6 address along with an ipv4.
  - mgbmtl 9y ago
    IPv4 has a lot of complexity: - NAT and CG-NAT for big networks is complex, resource-intensive. - Fragmentation on IPv4 requires more work/complexity from routers. - Some of my friends seem to think that calculating /29 IPv4 networks is simple, but I don't deal with this often and it really annoys me (yes, even with ipcalc). Not to mention the number of addresses lost due to routing (I often use link-local addresses on IPv6). Start moving now, progressively, or you'll be forced to do it in a rush later on. This isn't too different than https adoption. Those who minimized its importance ("oh, that's just internal communication, it can be plain http") got seriously bit.
simias 9y ago
The main reason I haven't switched my networks to IPv6 is that I plainly don't want to support both protocols at the same time. If I could just switch over to IPv6 and leave v4 behind I would, but I just can't be bothered to do twice the work every time I setup a firewall or a router. Double the config, double the tests and on top of that you have to make sure everything inter-operates smoothly when IPv4 alone still just works. As you mention in your other post it really is the "billion dollar mistake", it's obvious to me in hindsight that they should have made IPv6 completely backwards compatible with IPv4, no matter the cost. Have a deprecation procedure later on if you want to remove the hacks necessary to support IPv4. Have a clear and simple upgrade path, one step at a time. Sure, having a clean new standard is compelling but clearly it's making things way more difficult that they ought to be. And that's how we end up more than 20 years after RFC1883 was released with "barely" 20% adoption. NATing was easier than IPv6, so people NAT'ed everything and the internet became the net.
- zAy0LfpBZLC8mAC 9y ago
  > As you mention in your other post it really is the "billion dollar mistake", it's obvious to me in hindsight that they should have made IPv6 completely backwards compatible with IPv4, no matter the cost. It's not a matter of cost, it's simply impossible. IPv4 has a 32 bit field for the source address and a 32 bit field for the destination address, and every connection over IP needs to send packets back and forth between the two addresses. As soon as one party has a longer address, the other party has to know how to handle that, otherwise, they cannot possibly communicate. The only point where compatibility would be possible to some degree is the network, but (a) that compatibility is in effect a tunnel, and there are lots of ways to tunnel IPv6 over IPv4 just fine, and (b) most of the global internet supports IPv6 just fine, and has been for a long time. The problem is the migration of the endpoints, not so much the network.
  - simias 9y ago
    I actually started replying to your comment with my master plan to make an "IPv6 in IPv4" but I realized that I was probably going to make an ass of myself since plenty of much more clever people have worked on the subject for a long longer than I did. But I guess my main issue with this is: >(a) that compatibility is in effect a tunnel, and there are lots of ways to tunnel IPv6 over IPv4 just fine I agree that no matter how you slice it, at some point if you want to transition you'll have to tunnel things. But why are there "lots of ways" to do it? Why isn't there one single, "it just works" way to add compatibility? IMO this should have been a core feature of the standard, bullet point #2, just below "add more addresses". Explain in details how the transition will be made, how you convert an IPv4 into IPv6 incrementally while not breaking anything. Sure it's hard to make a one-size-fits all, but all the corners you have to cut and just make it work. Why isn't the IPv6 my ISP provides simply an extension of my IPv4? If my IPv4 is 216.58.213.174, why isn't the IPv6 216.58.213.174.[more stuff]? Why can I just concatenate my IPv4 public and NAT'ed LAN IP to get a valid IPv6? `ifconfig eth0 inet6 216.58.213.174:192.168.0.101/32` and here we go. It looks familiar, I understand what it means. You could even standardize it to make the IPv4 always be the low bytes of the IPv6 address or something like that, this way I don't have to worry about two sets of addresses. Instead it's `ifconfig eth0 inet6 2001:41d0:000a:050d::1 prefixlen 128 accept_rtadv no_radr`. Ah. I'm sure there's a good reason to make those changes but I can't really be bothered to figure them out as long as IPv4 just works. I'll get around to learn it, eventually, maybe in a few months when I read an article on HN telling me that we're at 21% worldwide adoption.

re 9y ago

What is "more than rudimentary" support? AWS supports public IPv6 for virtual instances, all three support it for their load balancer products, and AWS supports it for a number of additional services (S3, CloudFront, WAF). Most of this support has been released within the last year, and I'm sure that this is work that's been in progress for a while and that improved support is coming. Cloud providers are ready for developers to build products accessible over IPv6. Are developers ready to build them?

buzer 9y ago
Let me past something that I posted to Calico Slack about a week ago: > Has anyone tried running IPv6 in AWS? It kinda seems like using it for containers is still very messy. IPs are assigned via DHCPv6 and you cannot actually turn off src/dest checking, so to assign public IPv6 address on each container, you would need to assign each IP address one by one on the interface via AWS API and use a hook in host's DHCPv6 client that adds the IPv6 address to NDP proxy (not 100% sure if this is required) and disables assigning it to interface. With this, you would get 10-30 IPv6 addresses per interface and with some additional hacks to use multiple interfaces you could possibly get 240 IPv6 addresses per instance on larger instances (or well, 16xlarge instances give 15*50) Though admittedly even if there was a support for getting prefixes to instances, it would still take time for other things to get support for it (e.g. Kubernetes)
- wmf 9y ago
  You have to admit you are pushing it to the limit there. Most people just want one IPv6 address per VM and that is working.
  - zAy0LfpBZLC8mAC 9y ago
    Just because most people want a broken setup, doesn't make it any less broken.