10 ms·

An update on IPv6

99 points by AndrewDucker 11y ago

ghshephard 11y ago
The article engages in a little bit of hyperbole with statements like this: "Not only is this a protracted calamity for the Internet". I work in a lot of regions in the world, (Mexico, UAE), where they've been used to the reality that they won't be assigned any IPv4 addresses. I'm talking about large $Billion+ organizations that made it abundantly clear to me, that the applications we were deploying ($100million plus network deployments) - would have to operate with PAT, or we would not be able to deploy them. And so we worked around the requirements that we deploy everything on PAT, and our network deployments (sometimes with thousands of IPV4 network elements) would have to operate purely within RFC1918 address space. Speaking as someone who has worked on million+ IPv6 node deployments, (So I clearly don't have a bias against IPv6) I can say with some certainty that the only "calamity" we are going to see is increased use of PAT on clients, and somewhat more expensive IPv4 addresses for those who need to act as a server. Everyone else will be fine. (Have been fine for years in places where public IPv4 addresses ceased to be available). The reality is that this lack of pressure to transfer to IPv6 means that we're going to see an extended period of time in which we migrate. It will happen eventually (IPv6 has a lot of awesome features, particularly around self-addressing, and lord is it wonderful not to have to play CIDR addressing games, everything is a ::/64) - but it's going to be a lot longer than most IPv6 advocates would prefer.
- danellis 11y ago
  > lord is it wonderful not to have to play CIDR addressing games, everything is a ::/64 /64 is the smallest network, but there are certainly larger aggregates with smaller prefixes.
  - kordless 11y ago
    Honestly, did he say otherwise? "Everything" in his world is "I use /64s everywhere."
    - danellis 11y ago
      "I use /64s everywhere" would be unusual for "someone who has worked on million+ IPv6 node deployments".
  - plq 11y ago
    I think he's talking from an end-user point of view.
    - danellis 11y ago
      Even from an end user point of view, the recommendation is to assign a /64 for a single network or a /48 for multiple networks. (Assuming 'end user = homeowner' here.)
      - ghshephard 11y ago
        And, as it turns out, the original recommendation to go with /48s turned out to be insufficiently flexible, and was overridden with https://tools.ietf.org/html/rfc6177 https://tools.ietf.org/html/rfc6177. In particular, some ISPs will hand out a /56 - allowing the home user 256 /64s. But, once again, these are administrative routing decisions - on the interface, it's always a /64 or (in some rare cases - though I'd love to hear if people still see this in the wild) /127s for router-router connections. You will never, ever see, for example, a /72 IPv6 network in the wild.
  - ghshephard 11y ago
    Yes - you're absolutely right. There are administrative collections of /32s, /48s, /56s - but when it comes time to lighting up a network interface - it's a /64. Even if I only have two devices on a network segment, (two routers that can perform ND with each other), a place that would have used a /30 in the IPv4 space, I'll light up a /64 and burn the other (2^64)-2 addresses. With the possible exception of some security scenarios in which a /127 might be desirable, there is no "address conservation" requirement to use blocks smaller than a /64. For those IPv4 network engineers who have a decade+ of jugglings /25s, /26s, /27s, /28s and /29s, and trying to preserve IP space (particularly globally routable), this is nice change of affairs.
    - danellis 11y ago
      Okay, sure, on hosts you're only going to see /64s, but unless I'm seriously misunderstanding something, anyone dealing with route aggregation is going to have to deal with smaller prefixes. And even just talking about "this is global unicast space", "this is 6to4 space" and "this is link local space" involves small prefixes. So, for example, you still need to do the same mental juggling to know that 2000::/3 is 2000... to 3fff....
      - ghshephard 11y ago
        Agreed. You can't get away from network blocks at the administrative routing level. But, at least life is a bit easier by making more common use of /48s and /32s - I.E. 2001:1868::/32 being 2001:1868:0000:0000::/64 -> 2001:1868:FFFF:FFFF::/64. Thankfully, the 100x more common task of configuring an interface, will always be a /64.
- loup-vaillant 11y ago
  > I can say with some certainty that the only "calamity" we are going to see is increased use of PAT on clients, and somewhat more expensive IPv4 addresses for those who need to act as a server. Quite the calamity if you ask me: Users have to actively ask for the permission to act as a server. And at a significant monetary cost, if I understand the constraints correctly. Sure, right now, nobody has a server at home. But if we did (and this is certainly technically possible), then centralised spying-ridden services such as Gmail, Facebook, and YouTube would be mostly useless. (Assuming peer to peer distribution, you don't need a server farm to scale.) This would also help with routing by the way, by keeping communications more local.
  - xorcist 11y ago
    > right now, nobody has a server at home I don't think it's that uncommon (and I say that not only because I have one myself). Home routers make it trivial to add one, and NAS boxes are more common than ever. Almost every game and torrent client needs to have ports forwarded (which it a server in the network sense), and UPnP is a "feature" most people have that makes it possible to be unaware of it all.
    - freehunter 11y ago
      In the US, every ISP contract I've seen says you're not allowed to run a server from your home. And when they structure your connection to have 50mbps down and 0.5mbps up, that's the enforcement.
      - hobarrera 11y ago
        And that's a pretty unenforceable contract. A lot of video-games have the host of a match actually work as a server. NAS as servers. In lots of inter-device applications, one of them works as a server. Oh, right, and Xorg.
  - ghshephard 11y ago
    What will happen is that IPv4 addresses won't be free anymore, and you'll have to pay a surcharge. This is already happening with some providers. Also, instead of being given a /29, providers will start handing out /32s. I'm not suggesting this is a good thing, but "calamity" isn't the word that comes to mind.
p1mrx 11y ago
Figures 3, 4, 5, and 6 are all showing the thumbnail for Figure 6.
cm2187 11y ago
What I don't understand is what is the cost to an ISP of switching. Whether it is network devices or users devices, unless they are more than 10yo, I would expect them to be all IPv6 compatible. So yes it will involve some reconfiguration, training engineers and support, but it looks like a relatively small investment to me. The switch to optic fibre is a way bigger investment.
- pyvpx 11y ago
  training and reconfiguration - and more pointedly B/OSS changes - are generally more expensive (opex) than upgrading equipment (capex) I personally believe the biggest driver for IPv6 adoption will be Apple requiring support in iOS apps. Right now, IPv4 space is still comparatively "cheap"
- ghshephard 11y ago
  Financial cost, even in training, isn't high. It's mostly two things - Inertia, and ROI. All of the network engineers know IPv4 ins and out really, really well, and have a mindset of not messing with stuff that's working. And ROI - what financial incentives does an ISP have to switch to IPv6, either in increased revenue or reduced costs?
  - vacri 11y ago
    There's also considerable cost in being an early bird. You get to find all the chinks in the protocol, all the bodgy firmware issues... all for no substantial change to the income stream.
- cyanoacry 11y ago
  The cost (in addition to those that other replies have pointed out) is also one of support. While a <10yr old device may support IPv6, it is often that they don't always perform exactly as designed. IPv4 & IPv6 co-existence is a little bit of a crapshoot at the device level. This translates into super-large ramifications, especially for companies like Comcast--I can only imagine that they don't want to add yet another possible moving part, especially when there's almost zero benefit to the average customer.
mino 11y ago
This are the video/slides of the talk that Geoff Huston (author of the post) gave at the last RIPE70: https://ripe70.ripe.net/archives/video/118/ https://ripe70.ripe.net/archives/video/118/ Very interesting point of view imho ("bring IPv6 to the rich first, the others will follow").
sz4kerto 11y ago
IPv4+NAT still works well, because the internet is more and more centralized. Sadly.
- pdkl95 11y ago
  No, NAT doesn't work well at all. Everybody that says this isn't taking into account the massive amount of software that wasn't even started in the first place because it wouldn't work behind a NAT. In fact, I would suggest that NAT is responsible for a lot of that centralization, as the workaround for not being able to listen(2) for your friend you want to communicate with is a centralized service to manage that connection. One of the original benefits of TCP/IP networking was that every peer was equally client and server in the eyes of the protocol. The damage done by NAT has been the de facto removal of that benefit. Even now when reasonably-reliable (but INCREDIBLY complicated) NAT-traversal protocols exist, a centralized service is still required, nullifying the benefit of being able to publish without the permission[1] of a central authority. [1] https://www.fourmilab.ch/documents/digital-imprimatur/ https://www.fourmilab.ch/documents/digital-imprimatur/
  - m_mueller 11y ago
    > In fact, I would suggest that NAT is responsible for a lot of that centralization (...) Wasn't that exactly GP's point?
  - sz4kerto 11y ago
    > In fact, I would suggest that NAT is responsible for a lot of that centralization, They are mutually reinforcing each other. Unfortunately, ISPs would only act on consumer pressure, and consumer pressure won't exist because they don't know of all the other nonexisting software that could exists without NAT. We have centralized internet because of NAT, and we have NAT because centralized services are dominant.
  - pilif 11y ago
    >In fact, I would suggest that NAT is responsible for a lot of that centralization, as the workaround for not being able to listen(2) for your friend you want to communicate with is a centralized service to manage that connection. IMHO, IPv6 won't fix this problem for many cases. Consumer routers still won't allow inbound connections, so there will still be the need for some kind of way to allow the client to tell the router to forward traffic on a specific port (likely https://en.wikipedia.org/wiki/Port_Control_Protocol https://en.wikipedia.org/wiki/Port_Control_Protocol). Which is exactly the same as we get these days with NAP-PMP or UPnP. Maybe once listening on all local interfaces will not listen on temporary addresses, we can move to a one-address-per-service model at which point it becomes more feasible to forego the central firewall dropping all incoming connections as port-scanning the machine you just got a connection from will involve scanning 65536 * 2^64 ports As it stands now, I'm not willing to expose all open ports of my internal machines over IPv6. Instead I still have specific port opening rules on my central firewall. While I have no issue exposing, say, Skype on some port, I certainly don't want to expose, say, my local NTP port of my Mac, or, worse some local port mapper needed for NFS mounts. Yes. I could use a local firewall, but these by default only allow a per-application setup. "Do you want to allow NTP to be reachable?" - To my local network? Yeah. Maybe. To the internet? Hell no. Current simple built-in firewalls don't allow this kind of answer - at least on the mac.
1ris 11y ago
What I think will really start the network effect is the fact that apple requires APPs for the new iOS to work in a IPv6 only environment. That means if Twitter wants to use the latest and greatest features they will have to make their service available via IPv6. So IPv6 only connections will start to become a vialbe end-user product. These will be cheaper than dual-stack installations, so the ISPs will push them.
- mirashii 11y ago
  > That means if Twitter wants to use the latest and greatest features they will have to make their service available via IPv6. This isn't really necessarily the case. The full details on the requirements for Apple's required "support" for IPv6 are sparse still, but there's no reason that this can't be done with NAT64.
rwmj 11y ago
I know this idea has long missed the boat, but why wasn't IPv4 address space extended by adding an IPv4 Option header that could carry extra address bits? You could even have made IPv4 addresses variable length this way, from 32 up to a very large number of bits, and hierarchical. And it's relatively easy to make such a scheme backwards compatible, because you can have (say) a webserver sitting on 1.2.3.4 answering queries for older clients that don't know how to form a 1.2.3.4.5.6 address packet.
- xorcist 11y ago
  Given that you don't want to tie next-generation allocations to existing v4 prefixes, that scheme ends up more complicated than what we got with v6. You would still need a gateway to keep state if you're moving traffic between v4-only endpoints and v6-only, which would end up pretty much like NAT64. The opportunity to break backwards compatibility in v6 brought many other good things as well: fixed fields that are easier to route, more sane network allocation schemes, router discovery for LANs, and lots of other bits and pieces.
- josteink 11y ago
  > I know this idea has long missed the boat, but why wasn't IPv4 address space extended by adding an IPv4 Option header that could carry extra address bits? Because that wouldn't be compatible with existing IPv4 deployments and would cause a reliability havoc when a node not configured to deal with it mangled packets transparently somewhere in between your source and destination end-points. I don't get the resistance against IPv6. It works. It's a fresh take. Yes it requires some new stuff to be deployed and configured here and there, maybe even requires you to learn something new, but if you thought extending IPv4 would have been any other way you are deluding yourself. If you're going to do a significant change to something as big as the internet (and introducing a new address scheme is that, no matter how you implement it), you might as well step back and think it all through instead of applying yet another hack. So tell me. Why are you opposed to IPv6? Why do you want to hang on to this old IPv4-thing which is already at the bursting point, at the edge of what it can take?
  - mirimir 11y ago
jorangreef 11y ago
If I'm not mistaken, I think the MTU for IPv6 is at least 1280? But possibly also going to end up as no more than that because IPv6 does not necessarily require people to support more than that? If so, then that could mean that packet sizes are going to be constant over the next 20 years, all the while that protocols and pipes get many times faster and bigger. If I'm not mistaken, those smaller and smaller packet sizes (relative to faster and faster networks) are going to mean tremendous packet switching overhead (routing, encryption) especially in protocols such as QUIC which try to align encryption with packets. Sort of like a plane having to stop at every red light in a traffic grid designed for cars.
- cm2187 11y ago
  Are they really going to increase in speed? With 10GBit ethernet, we are getting close to the speed at which you transfer data in and out of RAM. I am sure we would like to have faster networks but will we be able to use faster networks (I mean for the end user)?
  - corobo 11y ago
    > close to the speed at which you transfer data in and out of RAM On a single machine. There's still a bit of room for faster connectivity now that everything's hooked up to the internet and streaming ever-bigger HD video. Infrastructure devices might need a bit of an upgrade though when we hit their limits
- pjc50 11y ago
  https://tools.ietf.org/html/rfc1981 https://tools.ietf.org/html/rfc1981 : path MTU discovery SHOULD be implemented in IPv6.
  - jorangreef 11y ago
    Thanks, that is my concern. I think the "SHOULD" should have been a "MUST" (or should still be changed to a "MUST") to ensure a forward upgrade path for larger MTU in future. Otherwise, the network is going to be limited by the lowest common denominator, namely those clients which do not implement any path MTU discovery because it's not a MUST, and only support an MTU of at least 1280 (but no more).
bencollier49 11y ago
Have to say I'm fairly unimpressed by how bad the UK looks in these rankings. The government ought to be incentivising take-up if they don't want the country to be a technology backwater.
facepalm 11y ago
Wall of text. I still don't know how to use IPV6. Maybe it is just too complicated and they should come up with something simpler?
- q3k 11y ago
  IPv6 is not complicated. 128 bits of address space. Everyone gets a /64's (128-64=>64 bits of address space). Larger entities get /48's (128-48=>80 bits of address space). So everyone (you, your device, your network) has plenty of addresses to spare. Addresses are written in hex, in the form 0011:2233:4455:6677:8899:aabb:ccdd:eeff (that's 8 groups of 16 bits -> 128 bits). If there are zeroes in an address on, you can omit them (ie. 1122:3344:5566:0000:0000:0000:0000:1234 => 1122:3344:5566::1234). Some protocols (ARP, kinda DHCP, ICMP) are merged into a single procotol called NDP (neighbor discovery protocol). When you're a home user, your router/gateway/CPE would get a /64 from your ISP, for example 2001:1234:4567:89ab::0/64. to use for your local devices. For example, in your LAN, your router would probably be 2001:1234:4567:89ab::1, while your devices would probably be addressed between 2001:1234:4567:89ab::2 and 2001:1234:4567:89ab:ffff:ffff:ffff:ffff. If your router is not using DHCPv6, but instead only NDP, it would simply respond with a “we're using 2001:1234:4567:89ab::0/64 here, I'm your gateway” to every device coming into the LAN, and the device would choose an address based on it's NIC MAC and some other facts. If your router would be using DHCPv6, the exchange would be just like in ordinary DHCP (dhcp request -> dhcp reply with IPv6 address to use). There is some extra (standarized) link-local magic with IPv6 - if you seen an fe80::0/16 address on your link, then it means that there was no IPv6 router/DHCP server on there and the devices in the LAN are establishing connection independently - but of course, without any access to the rest of the IPv6 Internet. This is also done via NDP, IIRC. And that's basically it. No NAT. The devices in your LAN are directly routable to devices in your friend's LAN, or to Facebook's server
  - facepalm 11y ago
    OK, but how do I turn it on? Why is it not turned on everywhere yet? How do I turn it on on my router, and how do I turn it on on my server? Can I just write "useipv6=true" in some config file and I am good? Do I want to turn it on - do I get some benefit, or would I just do it for the greater good? I've heard it's actually better for the spying agencies?
suprjami 11y ago
I am looking forward to the day when global IPv4 gets turned off. They should do it on a World IPv6 Day, how about 6/6/16?
- AndrewDucker 11y ago
  Might take a bit longer. Looking at http://www.google.com/intl/en/ipv6/statistics.html http://www.google.com/intl/en/ipv6/statistics.html it's doubling every year. So it's going to take another four to reach everywhere. Maybe 6/6/2020 :-) (And there are plenty of IPv4-only devices out there, like printers, Consoles, etc. So I suspect another five years after that before there's so little left that the address space starts clearing up again.)
abvdasker 11y ago
The article briefly touches on this, but I'm mainly interested in IPv6 adoption for the possibilities it opens up in peer-to-peer communications by removing the need for NAT. Imagine the possibilities if WebRTC didn't require the use of STUN/TURN/ICE servers to work properly and browsers could simply talk directly to one another.
- whistlerbrk 11y ago
  I think that is (tin foil hat) perhaps one of the reasons for the hold up. IPv6 makes true p2p possible and will open up a lot of pirating possibilities.
AndrewDMcG 11y ago
2002 explanation by Dan Bernstein of why IPv6 will never happen. http://cr.yp.to/djbdns/ipv6mess.html http://cr.yp.to/djbdns/ipv6mess.html
- anderiv 11y ago
  DJB was not arguing that IPv6 would never happen. He was arguing that there are some significant barriers that need to be overcome before meaningful adoption will occur. I'd argue that many, if not all of the issues with v6 back in 2002 have been resolved, and that v6 adoption is accelerating, both on eyeball networks as well as on public-facing internet services.
- stephen_g 11y ago
  Daniel is a smart guy, but this particular post doesn't really come off as being super coherent... I don't know if it's because of how far IPv6 has come and things are competly different now, making his concerns solved problems, or if he just didn't really grasp everything about IPv6 then (the examples of IPv6 addresses look nothing like actual addresses, and he seems to not have heard of dual stack...). I'd guess it's a bit of both.

99 points by AndrewDucker 11y ago

The article engages in a little bit of hyperbole with statements like this: "Not only is this a protracted calamity for the Internet". I work in a lot of regions in the world, (Mexico, UAE), where they've been used to the reality that they won't be assigned any IPv4 addresses. I'm talking about large $Billion+ organizations that made it abundantly clear to me, that the applications we were deploying ($100million plus network deployments) - would have to operate with PAT, or we would not be able to deploy them. And so we worked around the requirements that we deploy everything on PAT, and our network deployments (sometimes with thousands of IPV4 network elements) would have to operate purely within RFC1918 address space. Speaking as someone who has worked on million+ IPv6 node deployments, (So I clearly don't have a bias against IPv6) I can say with some certainty that the only "calamity" we are going to see is increased use of PAT on clients, and somewhat more expensive IPv4 addresses for those who need to act as a server. Everyone else will be fine. (Have been fine for years in places where public IPv4 addresses ceased to be available). The reality is that this lack of pressure to transfer to IPv6 means that we're going to see an extended period of time in which we migrate. It will happen eventually (IPv6 has a lot of awesome features, particularly around self-addressing, and lord is it wonderful not to have to play CIDR addressing games, everything is a ::/64) - but it's going to be a lot longer than most IPv6 advocates would prefer.

danellis 11y ago
> lord is it wonderful not to have to play CIDR addressing games, everything is a ::/64 /64 is the smallest network, but there are certainly larger aggregates with smaller prefixes.
- kordless 11y ago
  Honestly, did he say otherwise? "Everything" in his world is "I use /64s everywhere."
  - danellis 11y ago
    "I use /64s everywhere" would be unusual for "someone who has worked on million+ IPv6 node deployments".
- plq 11y ago
  I think he's talking from an end-user point of view.
  - danellis 11y ago
    Even from an end user point of view, the recommendation is to assign a /64 for a single network or a /48 for multiple networks. (Assuming 'end user = homeowner' here.)
    - ghshephard 11y ago
      And, as it turns out, the original recommendation to go with /48s turned out to be insufficiently flexible, and was overridden with https://tools.ietf.org/html/rfc6177 https://tools.ietf.org/html/rfc6177. In particular, some ISPs will hand out a /56 - allowing the home user 256 /64s. But, once again, these are administrative routing decisions - on the interface, it's always a /64 or (in some rare cases - though I'd love to hear if people still see this in the wild) /127s for router-router connections. You will never, ever see, for example, a /72 IPv6 network in the wild.
- ghshephard 11y ago
  Yes - you're absolutely right. There are administrative collections of /32s, /48s, /56s - but when it comes time to lighting up a network interface - it's a /64. Even if I only have two devices on a network segment, (two routers that can perform ND with each other), a place that would have used a /30 in the IPv4 space, I'll light up a /64 and burn the other (2^64)-2 addresses. With the possible exception of some security scenarios in which a /127 might be desirable, there is no "address conservation" requirement to use blocks smaller than a /64. For those IPv4 network engineers who have a decade+ of jugglings /25s, /26s, /27s, /28s and /29s, and trying to preserve IP space (particularly globally routable), this is nice change of affairs.
  - danellis 11y ago
    Okay, sure, on hosts you're only going to see /64s, but unless I'm seriously misunderstanding something, anyone dealing with route aggregation is going to have to deal with smaller prefixes. And even just talking about "this is global unicast space", "this is 6to4 space" and "this is link local space" involves small prefixes. So, for example, you still need to do the same mental juggling to know that 2000::/3 is 2000... to 3fff....
    - ghshephard 11y ago
      Agreed. You can't get away from network blocks at the administrative routing level. But, at least life is a bit easier by making more common use of /48s and /32s - I.E. 2001:1868::/32 being 2001:1868:0000:0000::/64 -> 2001:1868:FFFF:FFFF::/64. Thankfully, the 100x more common task of configuring an interface, will always be a /64.
loup-vaillant 11y ago
> I can say with some certainty that the only "calamity" we are going to see is increased use of PAT on clients, and somewhat more expensive IPv4 addresses for those who need to act as a server. Quite the calamity if you ask me: Users have to actively ask for the permission to act as a server. And at a significant monetary cost, if I understand the constraints correctly. Sure, right now, nobody has a server at home. But if we did (and this is certainly technically possible), then centralised spying-ridden services such as Gmail, Facebook, and YouTube would be mostly useless. (Assuming peer to peer distribution, you don't need a server farm to scale.) This would also help with routing by the way, by keeping communications more local.
- xorcist 11y ago
  > right now, nobody has a server at home I don't think it's that uncommon (and I say that not only because I have one myself). Home routers make it trivial to add one, and NAS boxes are more common than ever. Almost every game and torrent client needs to have ports forwarded (which it a server in the network sense), and UPnP is a "feature" most people have that makes it possible to be unaware of it all.
  - freehunter 11y ago
    In the US, every ISP contract I've seen says you're not allowed to run a server from your home. And when they structure your connection to have 50mbps down and 0.5mbps up, that's the enforcement.
    - hobarrera 11y ago
      And that's a pretty unenforceable contract. A lot of video-games have the host of a match actually work as a server. NAS as servers. In lots of inter-device applications, one of them works as a server. Oh, right, and Xorg.
- ghshephard 11y ago
  What will happen is that IPv4 addresses won't be free anymore, and you'll have to pay a surcharge. This is already happening with some providers. Also, instead of being given a /29, providers will start handing out /32s. I'm not suggesting this is a good thing, but "calamity" isn't the word that comes to mind.

p1mrx 11y ago

Figures 3, 4, 5, and 6 are all showing the thumbnail for Figure 6.

cm2187 11y ago

What I don't understand is what is the cost to an ISP of switching. Whether it is network devices or users devices, unless they are more than 10yo, I would expect them to be all IPv6 compatible. So yes it will involve some reconfiguration, training engineers and support, but it looks like a relatively small investment to me. The switch to optic fibre is a way bigger investment.

pyvpx 11y ago
training and reconfiguration - and more pointedly B/OSS changes - are generally more expensive (opex) than upgrading equipment (capex) I personally believe the biggest driver for IPv6 adoption will be Apple requiring support in iOS apps. Right now, IPv4 space is still comparatively "cheap"
ghshephard 11y ago
Financial cost, even in training, isn't high. It's mostly two things - Inertia, and ROI. All of the network engineers know IPv4 ins and out really, really well, and have a mindset of not messing with stuff that's working. And ROI - what financial incentives does an ISP have to switch to IPv6, either in increased revenue or reduced costs?
- vacri 11y ago
  There's also considerable cost in being an early bird. You get to find all the chinks in the protocol, all the bodgy firmware issues... all for no substantial change to the income stream.
cyanoacry 11y ago
The cost (in addition to those that other replies have pointed out) is also one of support. While a <10yr old device may support IPv6, it is often that they don't always perform exactly as designed. IPv4 & IPv6 co-existence is a little bit of a crapshoot at the device level. This translates into super-large ramifications, especially for companies like Comcast--I can only imagine that they don't want to add yet another possible moving part, especially when there's almost zero benefit to the average customer.

mino 11y ago

This are the video/slides of the talk that Geoff Huston (author of the post) gave at the last RIPE70: https://ripe70.ripe.net/archives/video/118/ https://ripe70.ripe.net/archives/video/118/ Very interesting point of view imho ("bring IPv6 to the rich first, the others will follow").

sz4kerto 11y ago

IPv4+NAT still works well, because the internet is more and more centralized. Sadly.

pdkl95 11y ago
No, NAT doesn't work well at all. Everybody that says this isn't taking into account the massive amount of software that wasn't even started in the first place because it wouldn't work behind a NAT. In fact, I would suggest that NAT is responsible for a lot of that centralization, as the workaround for not being able to listen(2) for your friend you want to communicate with is a centralized service to manage that connection. One of the original benefits of TCP/IP networking was that every peer was equally client and server in the eyes of the protocol. The damage done by NAT has been the de facto removal of that benefit. Even now when reasonably-reliable (but INCREDIBLY complicated) NAT-traversal protocols exist, a centralized service is still required, nullifying the benefit of being able to publish without the permission[1] of a central authority. [1] https://www.fourmilab.ch/documents/digital-imprimatur/ https://www.fourmilab.ch/documents/digital-imprimatur/
- m_mueller 11y ago
  > In fact, I would suggest that NAT is responsible for a lot of that centralization (...) Wasn't that exactly GP's point?
- sz4kerto 11y ago
  > In fact, I would suggest that NAT is responsible for a lot of that centralization, They are mutually reinforcing each other. Unfortunately, ISPs would only act on consumer pressure, and consumer pressure won't exist because they don't know of all the other nonexisting software that could exists without NAT. We have centralized internet because of NAT, and we have NAT because centralized services are dominant.
- pilif 11y ago
  >In fact, I would suggest that NAT is responsible for a lot of that centralization, as the workaround for not being able to listen(2) for your friend you want to communicate with is a centralized service to manage that connection. IMHO, IPv6 won't fix this problem for many cases. Consumer routers still won't allow inbound connections, so there will still be the need for some kind of way to allow the client to tell the router to forward traffic on a specific port (likely https://en.wikipedia.org/wiki/Port_Control_Protocol https://en.wikipedia.org/wiki/Port_Control_Protocol). Which is exactly the same as we get these days with NAP-PMP or UPnP. Maybe once listening on all local interfaces will not listen on temporary addresses, we can move to a one-address-per-service model at which point it becomes more feasible to forego the central firewall dropping all incoming connections as port-scanning the machine you just got a connection from will involve scanning 65536 * 2^64 ports As it stands now, I'm not willing to expose all open ports of my internal machines over IPv6. Instead I still have specific port opening rules on my central firewall. While I have no issue exposing, say, Skype on some port, I certainly don't want to expose, say, my local NTP port of my Mac, or, worse some local port mapper needed for NFS mounts. Yes. I could use a local firewall, but these by default only allow a per-application setup. "Do you want to allow NTP to be reachable?" - To my local network? Yeah. Maybe. To the internet? Hell no. Current simple built-in firewalls don't allow this kind of answer - at least on the mac.

1ris 11y ago

What I think will really start the network effect is the fact that apple requires APPs for the new iOS to work in a IPv6 only environment. That means if Twitter wants to use the latest and greatest features they will have to make their service available via IPv6. So IPv6 only connections will start to become a vialbe end-user product. These will be cheaper than dual-stack installations, so the ISPs will push them.

mirashii 11y ago
> That means if Twitter wants to use the latest and greatest features they will have to make their service available via IPv6. This isn't really necessarily the case. The full details on the requirements for Apple's required "support" for IPv6 are sparse still, but there's no reason that this can't be done with NAT64.

rwmj 11y ago

I know this idea has long missed the boat, but why wasn't IPv4 address space extended by adding an IPv4 Option header that could carry extra address bits? You could even have made IPv4 addresses variable length this way, from 32 up to a very large number of bits, and hierarchical. And it's relatively easy to make such a scheme backwards compatible, because you can have (say) a webserver sitting on 1.2.3.4 answering queries for older clients that don't know how to form a 1.2.3.4.5.6 address packet.

xorcist 11y ago
Given that you don't want to tie next-generation allocations to existing v4 prefixes, that scheme ends up more complicated than what we got with v6. You would still need a gateway to keep state if you're moving traffic between v4-only endpoints and v6-only, which would end up pretty much like NAT64. The opportunity to break backwards compatibility in v6 brought many other good things as well: fixed fields that are easier to route, more sane network allocation schemes, router discovery for LANs, and lots of other bits and pieces.
josteink 11y ago
> I know this idea has long missed the boat, but why wasn't IPv4 address space extended by adding an IPv4 Option header that could carry extra address bits? Because that wouldn't be compatible with existing IPv4 deployments and would cause a reliability havoc when a node not configured to deal with it mangled packets transparently somewhere in between your source and destination end-points. I don't get the resistance against IPv6. It works. It's a fresh take. Yes it requires some new stuff to be deployed and configured here and there, maybe even requires you to learn something new, but if you thought extending IPv4 would have been any other way you are deluding yourself. If you're going to do a significant change to something as big as the internet (and introducing a new address scheme is that, no matter how you implement it), you might as well step back and think it all through instead of applying yet another hack. So tell me. Why are you opposed to IPv6? Why do you want to hang on to this old IPv4-thing which is already at the bursting point, at the edge of what it can take?
- mirimir 11y ago

jorangreef 11y ago

If I'm not mistaken, I think the MTU for IPv6 is at least 1280? But possibly also going to end up as no more than that because IPv6 does not necessarily require people to support more than that? If so, then that could mean that packet sizes are going to be constant over the next 20 years, all the while that protocols and pipes get many times faster and bigger. If I'm not mistaken, those smaller and smaller packet sizes (relative to faster and faster networks) are going to mean tremendous packet switching overhead (routing, encryption) especially in protocols such as QUIC which try to align encryption with packets. Sort of like a plane having to stop at every red light in a traffic grid designed for cars.

cm2187 11y ago
Are they really going to increase in speed? With 10GBit ethernet, we are getting close to the speed at which you transfer data in and out of RAM. I am sure we would like to have faster networks but will we be able to use faster networks (I mean for the end user)?
- corobo 11y ago
  > close to the speed at which you transfer data in and out of RAM On a single machine. There's still a bit of room for faster connectivity now that everything's hooked up to the internet and streaming ever-bigger HD video. Infrastructure devices might need a bit of an upgrade though when we hit their limits
pjc50 11y ago
https://tools.ietf.org/html/rfc1981 https://tools.ietf.org/html/rfc1981 : path MTU discovery SHOULD be implemented in IPv6.
- jorangreef 11y ago
  Thanks, that is my concern. I think the "SHOULD" should have been a "MUST" (or should still be changed to a "MUST") to ensure a forward upgrade path for larger MTU in future. Otherwise, the network is going to be limited by the lowest common denominator, namely those clients which do not implement any path MTU discovery because it's not a MUST, and only support an MTU of at least 1280 (but no more).

bencollier49 11y ago

Have to say I'm fairly unimpressed by how bad the UK looks in these rankings. The government ought to be incentivising take-up if they don't want the country to be a technology backwater.

facepalm 11y ago

Wall of text. I still don't know how to use IPV6. Maybe it is just too complicated and they should come up with something simpler?

q3k 11y ago
IPv6 is not complicated. 128 bits of address space. Everyone gets a /64's (128-64=>64 bits of address space). Larger entities get /48's (128-48=>80 bits of address space). So everyone (you, your device, your network) has plenty of addresses to spare. Addresses are written in hex, in the form 0011:2233:4455:6677:8899:aabb:ccdd:eeff (that's 8 groups of 16 bits -> 128 bits). If there are zeroes in an address on, you can omit them (ie. 1122:3344:5566:0000:0000:0000:0000:1234 => 1122:3344:5566::1234). Some protocols (ARP, kinda DHCP, ICMP) are merged into a single procotol called NDP (neighbor discovery protocol). When you're a home user, your router/gateway/CPE would get a /64 from your ISP, for example 2001:1234:4567:89ab::0/64. to use for your local devices. For example, in your LAN, your router would probably be 2001:1234:4567:89ab::1, while your devices would probably be addressed between 2001:1234:4567:89ab::2 and 2001:1234:4567:89ab:ffff:ffff:ffff:ffff. If your router is not using DHCPv6, but instead only NDP, it would simply respond with a “we're using 2001:1234:4567:89ab::0/64 here, I'm your gateway” to every device coming into the LAN, and the device would choose an address based on it's NIC MAC and some other facts. If your router would be using DHCPv6, the exchange would be just like in ordinary DHCP (dhcp request -> dhcp reply with IPv6 address to use). There is some extra (standarized) link-local magic with IPv6 - if you seen an fe80::0/16 address on your link, then it means that there was no IPv6 router/DHCP server on there and the devices in the LAN are establishing connection independently - but of course, without any access to the rest of the IPv6 Internet. This is also done via NDP, IIRC. And that's basically it. No NAT. The devices in your LAN are directly routable to devices in your friend's LAN, or to Facebook's server
- facepalm 11y ago
  OK, but how do I turn it on? Why is it not turned on everywhere yet? How do I turn it on on my router, and how do I turn it on on my server? Can I just write "useipv6=true" in some config file and I am good? Do I want to turn it on - do I get some benefit, or would I just do it for the greater good? I've heard it's actually better for the spying agencies?

suprjami 11y ago

I am looking forward to the day when global IPv4 gets turned off. They should do it on a World IPv6 Day, how about 6/6/16?

AndrewDucker 11y ago
Might take a bit longer. Looking at http://www.google.com/intl/en/ipv6/statistics.html http://www.google.com/intl/en/ipv6/statistics.html it's doubling every year. So it's going to take another four to reach everywhere. Maybe 6/6/2020 :-) (And there are plenty of IPv4-only devices out there, like printers, Consoles, etc. So I suspect another five years after that before there's so little left that the address space starts clearing up again.)

abvdasker 11y ago

The article briefly touches on this, but I'm mainly interested in IPv6 adoption for the possibilities it opens up in peer-to-peer communications by removing the need for NAT. Imagine the possibilities if WebRTC didn't require the use of STUN/TURN/ICE servers to work properly and browsers could simply talk directly to one another.

whistlerbrk 11y ago
I think that is (tin foil hat) perhaps one of the reasons for the hold up. IPv6 makes true p2p possible and will open up a lot of pirating possibilities.

AndrewDMcG 11y ago

2002 explanation by Dan Bernstein of why IPv6 will never happen. http://cr.yp.to/djbdns/ipv6mess.html http://cr.yp.to/djbdns/ipv6mess.html

anderiv 11y ago
DJB was not arguing that IPv6 would never happen. He was arguing that there are some significant barriers that need to be overcome before meaningful adoption will occur. I'd argue that many, if not all of the issues with v6 back in 2002 have been resolved, and that v6 adoption is accelerating, both on eyeball networks as well as on public-facing internet services.
stephen_g 11y ago
Daniel is a smart guy, but this particular post doesn't really come off as being super coherent... I don't know if it's because of how far IPv6 has come and things are competly different now, making his concerns solved problems, or if he just didn't really grasp everything about IPv6 then (the examples of IPv6 addresses look nothing like actual addresses, and he seems to not have heard of dual stack...). I'd guess it's a bit of both.