Ask HN: What will IPV6 migration actually look like?
47 comments
For makers, it will hopefully look like the internet of the old days where you can just configure ACLs and/or crypto keys to allow traffic from one place to the other instead of using a towering stack of configuration tooling to manage address mappings, port forwardings and private DNS zones, and fighting rfc1918 addressing conflicts.
Security engineering is largely about managing complexity and having a firm grasp on the system you're securing, so it's definitely a win there too.
It's weird that we have IPv6 widely provided by consumer ISPs (wireless & wired) but AWS & GCE are the ones holding the whole thing back. A while ago it everyone assumed that servers are the easy part and getting consumer ISPs to play along was going to be hard...
About clients ceasing to have IPv4 connectivity, that's anybody's guess. It will definitely be a "happy problem" if/when that starts happening at some point in the distant future.
Security engineering is largely about managing complexity and having a firm grasp on the system you're securing, so it's definitely a win there too.
It's weird that we have IPv6 widely provided by consumer ISPs (wireless & wired) but AWS & GCE are the ones holding the whole thing back. A while ago it everyone assumed that servers are the easy part and getting consumer ISPs to play along was going to be hard...
About clients ceasing to have IPv4 connectivity, that's anybody's guess. It will definitely be a "happy problem" if/when that starts happening at some point in the distant future.
> AWS & GCE
that's because they have plenty of v4 space, which is now a competitive advantage. have you tried to get even a /24 lately? pay up, sucker. bitspace is now a market with exponential returns.
it's the ultimate barrier to entry. the faster they move on it, the less of a barrier it will be to the competition. so why should they?
welcome to the new microsoft. except this time, we're all eating it up and loving it for some reason (that's another post...)
that's because they have plenty of v4 space, which is now a competitive advantage. have you tried to get even a /24 lately? pay up, sucker. bitspace is now a market with exponential returns.
it's the ultimate barrier to entry. the faster they move on it, the less of a barrier it will be to the competition. so why should they?
welcome to the new microsoft. except this time, we're all eating it up and loving it for some reason (that's another post...)
> that's because they have plenty of v4 space, which is now a competitive advantage. have you tried to get even a /24 lately? pay up, sucker. bitspace is now a market with exponential returns.
Depends where you are. Maybe it's hard to get a range from ARIN, but we got a /23 from APNIC not one month ago for ~1k/yr. That is peanuts, and was not too difficult to quality for eligibility either.
Depends where you are. Maybe it's hard to get a range from ARIN, but we got a /23 from APNIC not one month ago for ~1k/yr. That is peanuts, and was not too difficult to quality for eligibility either.
They don't really... I've heard the internal addressing at some cloud providers is a real mess. Multi-layer NAT, etc.
Amazon has a significant push to VPC, so then instances will all be on e.g. 10. Address space (so they're doing NAT).
To me it looked like this:
- I've got a new modem from aaisp.net and didn't have to do anything.
- I've checked an "IPV6 (BETA!)" checkbox in my hosting provider's control panel.
- I've copied & pasted my new IP and added it to AAAA records for my domains.
And to my surprise, everything just worked. My mobile phone used IPv6 even before I knew. I didn't have to troubleshoot anything. The biggest snag I ran into is that `ping` has a separate `ping6` version.
- I've got a new modem from aaisp.net and didn't have to do anything.
- I've checked an "IPV6 (BETA!)" checkbox in my hosting provider's control panel.
- I've copied & pasted my new IP and added it to AAAA records for my domains.
And to my surprise, everything just worked. My mobile phone used IPv6 even before I knew. I didn't have to troubleshoot anything. The biggest snag I ran into is that `ping` has a separate `ping6` version.
We are in the middle of such migration. More providers are supporting it, dual stack is on almost every major OS by default and they prefer IPv6 when possible.
Eventually all your traffic will be IPv6 and you wouldn't have noticed. Unless you have to migrate IPv4 only devices, in that case you'll be tired of hearing about it :)
Eventually all your traffic will be IPv6 and you wouldn't have noticed. Unless you have to migrate IPv4 only devices, in that case you'll be tired of hearing about it :)
In many companies the IPv6 migration has already happened. For those that have not started yet it will be more expensive if they wait even longer.
The hardest part seems to be training people. IPv6 is different - it is more than just "longer addresses". It is a newer protocol that fixes many more problems with IPv4 than just address exhaustion. So this "ipv6 migration" is actually an opportunity to leverage those new features.
Designing IT infrastructure IPv6 first and IPv4 second allows for so much simpler designs. You can have your complete network IPv6 only and do IPv4 on the edge for legacy clients. (Maybe doing outgoing NAT for v4 where required) The results are a much cleaner layout (because of the larger address space), simpler firewall rules, and so on.
It is not complicated or hard to do (in contrary I think that e.g. just setting up SLAAC is much simpler than managing DHCP) but the engineers need to know how it is different. They need training for that. People are often used to the old ways, once they have seen and worked with IPv6 it is no problem.
I've helped larger and smaller companies since ~2004 with those migrations. One observation I've made is that here in europe IPv6 is a basic fact of networking where as in the US it appears as if many companies are in denial. That cloud providers like AWS don't do native v6 is absolutely ridiculous.
When you write code or security rules today that is not designed with IPv6 in mind they are outdated today. Don't do it ;-)
The hardest part seems to be training people. IPv6 is different - it is more than just "longer addresses". It is a newer protocol that fixes many more problems with IPv4 than just address exhaustion. So this "ipv6 migration" is actually an opportunity to leverage those new features.
Designing IT infrastructure IPv6 first and IPv4 second allows for so much simpler designs. You can have your complete network IPv6 only and do IPv4 on the edge for legacy clients. (Maybe doing outgoing NAT for v4 where required) The results are a much cleaner layout (because of the larger address space), simpler firewall rules, and so on.
It is not complicated or hard to do (in contrary I think that e.g. just setting up SLAAC is much simpler than managing DHCP) but the engineers need to know how it is different. They need training for that. People are often used to the old ways, once they have seen and worked with IPv6 it is no problem.
I've helped larger and smaller companies since ~2004 with those migrations. One observation I've made is that here in europe IPv6 is a basic fact of networking where as in the US it appears as if many companies are in denial. That cloud providers like AWS don't do native v6 is absolutely ridiculous.
When you write code or security rules today that is not designed with IPv6 in mind they are outdated today. Don't do it ;-)
IPv4 won't disappear or exhaust. It will fade out like a white dwarf, but it may well be still in use, 20 or 30 years from now. CGNAT at client side (already in widespread use) and server-side public IPs that cost money every month will keep usage of IPv4 addrs in check. Of course, richer protocols like P2P will have to go IPv6.
(Back in 1993, when a guy said that MS-DOS would be in use by 2000, I laughed at him. I made serious money on MS-DOS+xBase until 2005!)
(Back in 1993, when a guy said that MS-DOS would be in use by 2000, I laughed at him. I made serious money on MS-DOS+xBase until 2005!)
IPv6 usage is steadily increasing, currently hovering at 10% globally, and 23% in the US. [1]
This is driven partially by mobile deployments, partially by some ISPs rolling out support. Note, that the IPv4 address exhaustion referred to in the media is IANA-level; top-level exhaustion occurred on 31 January 2011 [2]. Also from there:
* Four of the five RIRs have exhausted allocation of all the blocks they have not reserved for IPv6 transition; this occurred on 15 April 2011 for the Asia-Pacific, on 14 September 2012 for Europe, on 10 June 2014 for Latin America and the Caribbean, and on 24 September 2015 for North America.
None of this impacts end-users, as ISPs have large reserves of non-used IPv4 addresses; and there are multiple mitigation strategies for post-exhaustion periods.
Also note, that even if all IPv4 address would be in public use currently, we still wouldn't "migrate" to IPV6 at-once: seeing how there are roughly ~25 billion Internet-connected devices (and 3.17 billion users) using it currently, migration can't take place overnight. Also note, that "pure ipv6" devices currently would be heavily disadvantaged: the majority of sites & services can't be accessed via ipv6 yet.
A probable migration pathway might be ramping up allocation of IPv6; as usage increases, servers will roll out support for it; which might hit a tipping point (similar to the current "HTTPS for everything") sometime around the 40-50% penetration rate. Once that occurs, ipv6-only users will no longer be disadvantaged; that, along with increasing price-points for dedicated ipv4 address might shift ISPs to start deploying ipv6-only, and use relays to access ipv4 services.
However, even under these conditions, servers will almost certainly will provide v4 access points, for reasons of maximum compatibility, and low cost (relative to all dev, deployment, domain, etc costs).
In conclusion, you can rest safely knowing that the code you wrote will be in use for a long time to come.
[1] https://www.google.com/intl/en/ipv6/statistics.html
[2] https://en.wikipedia.org/wiki/IPv4_address_exhaustion
This is driven partially by mobile deployments, partially by some ISPs rolling out support. Note, that the IPv4 address exhaustion referred to in the media is IANA-level; top-level exhaustion occurred on 31 January 2011 [2]. Also from there:
* Four of the five RIRs have exhausted allocation of all the blocks they have not reserved for IPv6 transition; this occurred on 15 April 2011 for the Asia-Pacific, on 14 September 2012 for Europe, on 10 June 2014 for Latin America and the Caribbean, and on 24 September 2015 for North America.
None of this impacts end-users, as ISPs have large reserves of non-used IPv4 addresses; and there are multiple mitigation strategies for post-exhaustion periods.
Also note, that even if all IPv4 address would be in public use currently, we still wouldn't "migrate" to IPV6 at-once: seeing how there are roughly ~25 billion Internet-connected devices (and 3.17 billion users) using it currently, migration can't take place overnight. Also note, that "pure ipv6" devices currently would be heavily disadvantaged: the majority of sites & services can't be accessed via ipv6 yet.
A probable migration pathway might be ramping up allocation of IPv6; as usage increases, servers will roll out support for it; which might hit a tipping point (similar to the current "HTTPS for everything") sometime around the 40-50% penetration rate. Once that occurs, ipv6-only users will no longer be disadvantaged; that, along with increasing price-points for dedicated ipv4 address might shift ISPs to start deploying ipv6-only, and use relays to access ipv4 services.
However, even under these conditions, servers will almost certainly will provide v4 access points, for reasons of maximum compatibility, and low cost (relative to all dev, deployment, domain, etc costs).
In conclusion, you can rest safely knowing that the code you wrote will be in use for a long time to come.
[1] https://www.google.com/intl/en/ipv6/statistics.html
[2] https://en.wikipedia.org/wiki/IPv4_address_exhaustion
I don't know the percentages, but several of the big home broadband ISPs are supporting native IPv6 via dual-stacking all the way to the customer premises. If you have a DOCSIS 3.0 modem, I believe that Cox and Comcast will both give you a IPv6 address via DHCPv6, at least in most areas. (I know that both of them do in Northern VA, it may not be universal particularly for Comcast.)
Many users aren't even aware of this, though, because the number of consumer-grade routers that support IPv6 is very small. I think that the Apple Airport may be one of the few, along with a few higher-end Linksys/Cisco ones (although lots of $100+ Linksys units don't, and they seem to be in absolutely no hurry to implement it via firmware updates -- I'm sure they see it as an opportunity to sell new hardware in a few years).
Consumers don't know to look for "IPv6" as a feature when they're buying a router, and so as a result Linksys et al don't bother to include it, and so even though a user might have a fully IPv6-capable uplink, there's no way to use it short of plugging their computer directly into their modem.
Many users aren't even aware of this, though, because the number of consumer-grade routers that support IPv6 is very small. I think that the Apple Airport may be one of the few, along with a few higher-end Linksys/Cisco ones (although lots of $100+ Linksys units don't, and they seem to be in absolutely no hurry to implement it via firmware updates -- I'm sure they see it as an opportunity to sell new hardware in a few years).
Consumers don't know to look for "IPv6" as a feature when they're buying a router, and so as a result Linksys et al don't bother to include it, and so even though a user might have a fully IPv6-capable uplink, there's no way to use it short of plugging their computer directly into their modem.
> I have been hearing "IPV6 is just on the horizon", "IPV4 is completely exhausted, it's only a matter of months", etc... for years now.
What you've actually been hearing about is various IPv4 exhaustion milestones. The world didn’t suddenly "run out" of IPv4 all at once.
The first big milestone was IANA running out in 2011. This meant that the regional registries (which actually hand out IP blocks to ISPs and large networks) could no longer get new space from the global pool. APNIC, the regional registry for Asia-Pacific, ran out a couple months later. (They didn’t "run out" as much as they went into a strict rationing mode.) The same thing happened to RIPE NCC (Europe) in 2012, LACNIC (Latin America) in 2014, and ARIN (North America) last September. (Interestingly, ARIN decided not to do any sort of rationing, North America is just completely out.) AFRINIC (Africa) is the only regional registry with enough space left that they're not rationing.
What does it actually mean that the regional registries are out of IPv4 space? It means you can't just go to a registry and say "hey I need more IP addresses" and pay your annual membership fees. You now have to purchase IPv4 space on a private market. Current prices actually aren't that bad - about $10/IP. So to be honest, it's not a huge crisis despite the regional registries having run out. The serious problem will be when it becomes impossible for companies to get the IP space they need at an affordable price. Ideally we should push for higher IPv6 adoption before it becomes a huge crisis.
What you've actually been hearing about is various IPv4 exhaustion milestones. The world didn’t suddenly "run out" of IPv4 all at once.
The first big milestone was IANA running out in 2011. This meant that the regional registries (which actually hand out IP blocks to ISPs and large networks) could no longer get new space from the global pool. APNIC, the regional registry for Asia-Pacific, ran out a couple months later. (They didn’t "run out" as much as they went into a strict rationing mode.) The same thing happened to RIPE NCC (Europe) in 2012, LACNIC (Latin America) in 2014, and ARIN (North America) last September. (Interestingly, ARIN decided not to do any sort of rationing, North America is just completely out.) AFRINIC (Africa) is the only regional registry with enough space left that they're not rationing.
What does it actually mean that the regional registries are out of IPv4 space? It means you can't just go to a registry and say "hey I need more IP addresses" and pay your annual membership fees. You now have to purchase IPv4 space on a private market. Current prices actually aren't that bad - about $10/IP. So to be honest, it's not a huge crisis despite the regional registries having run out. The serious problem will be when it becomes impossible for companies to get the IP space they need at an affordable price. Ideally we should push for higher IPv6 adoption before it becomes a huge crisis.
Anyone know what's the biggest hold up of IPv6 on AWS side? They must be working on this for years, but never heard of any push or beta program at all.
My guess is that their custom software defined networking infrastructure is the main holdup. There is little known about the SDN infrastructure behind AWS, but I would be surprised if large portions are not custom designed hardware and a homebrew control plane.
It is very slow to iterate on the hardware side at such a scale for cost reasons. The cost structure is very different from server hardware, where the increase in performance per watt and rack density of newer hardware essentially pays for itself at some point.
But a 10Gbps Port in your top of rack switch is good enough for many many years and multiple server generations, until you make the leap to a higher port speed.
If the chip inside your SDN switch has no understanding of IPv6, you could only tunnel such packets in software at substantial performance costs. So it takes ages until the whole physical network is using new enough gear.
It is very slow to iterate on the hardware side at such a scale for cost reasons. The cost structure is very different from server hardware, where the increase in performance per watt and rack density of newer hardware essentially pays for itself at some point.
But a 10Gbps Port in your top of rack switch is good enough for many many years and multiple server generations, until you make the leap to a higher port speed.
If the chip inside your SDN switch has no understanding of IPv6, you could only tunnel such packets in software at substantial performance costs. So it takes ages until the whole physical network is using new enough gear.
AWS does support ipv6 in ELBs in a fashion. ELBs will have both an ipv6 and a dual stack DNS entry created for them, in addition to the ipv4.
example.us-east-1.elb.amazonaws.com (A Record)
ipv6.example.us-east-1.elb.amazonaws.com (AAAA Record)
dualstack.example.us-east-1.elb.amazonaws.com (A or AAAA Record)
These records will only be displayed for ELBs in classic despite existing and being resolvable for VPC ELBs. The twist is that there is no way to add security groups with ipv6 addresses in VPC so its not possible to receive requests.
Amusingly this means ELBs in classic have an advantage on VPC when it comes to ipv6.
example.us-east-1.elb.amazonaws.com (A Record)
ipv6.example.us-east-1.elb.amazonaws.com (AAAA Record)
dualstack.example.us-east-1.elb.amazonaws.com (A or AAAA Record)
These records will only be displayed for ELBs in classic despite existing and being resolvable for VPC ELBs. The twist is that there is no way to add security groups with ipv6 addresses in VPC so its not possible to receive requests.
Amusingly this means ELBs in classic have an advantage on VPC when it comes to ipv6.
Thanks did not ipv6 version exists. Now you are bringing the right thing... IPv6 support in VPC SG.
.. or they haven't ..
VPC gives you your own entire rfc1918 space per region, which tho can be a pain to deal with overlap if you have site-to-site VPN, is enough for basically anyone.
VPC gives you your own entire rfc1918 space per region, which tho can be a pain to deal with overlap if you have site-to-site VPN, is enough for basically anyone.
You can avoid RFC1918 overlapping issues by using some overlay networking solution like Wormhole[1], which uses the CGNAT reserved IP space to build a virtual network between your servers, regardless of their location.
This pain point is one of the reasons we've built Wormhole.
[1]https://wormhole.network
This pain point is one of the reasons we've built Wormhole.
[1]https://wormhole.network
Well, public services are not. ELB for example. If AWS continues to grow, I think they will eventually exhaust their IPv4 blocks and this is an issue they can't ignore.
ELBs in EC2 Classic support IPv6, but not ELBs in VPCs, as of now at least. You may already have known this but I figured I'd point it out for others: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...
I wasn't even aware of IPv6 support for Classic. Thanks.
What cloud provider currently supports IPv6?
Linode supports IPv6:
[prhodes@doctorfeelgood ~]$ ping6 -n www.fogbeam.com
PING www.fogbeam.com(2600:3c02::f03c:91ff:fe84:7b1d) 56 data bytes
64 bytes from 2600:3c02::f03c:91ff:fe84:7b1d: icmp_seq=1 ttl=55 time=31.7 ms
64 bytes from 2600:3c02::f03c:91ff:fe84:7b1d: icmp_seq=2 ttl=55 time=39.8 ms
64 bytes from 2600:3c02::f03c:91ff:fe84:7b1d: icmp_seq=3 ttl=55 time=38.6 ms
^CThanks!
Just looking at this makes me feel for network operators that have to troubleshoot layer 3 addresses directly and without DNS. There needs to be a better approach - like an intelligent clipboard.
Just looking at this makes me feel for network operators that have to troubleshoot layer 3 addresses directly and without DNS. There needs to be a better approach - like an intelligent clipboard.
I'm far from an expert on ipv6, but I think there may be some "shortcuts" that let you work with less than the full address. See, for example:
http://networkrecipes.blogspot.com/2014/08/ipv6-shortcuts.ht...
http://networkrecipes.blogspot.com/2014/08/ipv6-shortcuts.ht...
Both VPS providers I use - DigitalOcean and TransIP - support IPv6, though only the latter does so by default.
[deleted]
SoftLayer offers v6
Google currently gets 9% of their traffic over IPv6:
https://www.google.com/intl/en/ipv6/statistics.html
IPv6 adoption is already at the point where it is relevant to your security checks. If IPv6 clients are exempt from your security, that is a problem right now.
https://www.google.com/intl/en/ipv6/statistics.html
IPv6 adoption is already at the point where it is relevant to your security checks. If IPv6 clients are exempt from your security, that is a problem right now.
I'm running the site over AWS EC2, so apparently nobody could connect to me via IPv6 at the moment anyways.
[deleted]
It will happen. I have both a DSL and a FTTH connection and both are dual stack already. When disabling IPv4 (on my CPE) most major sites are OK (Google, Facebook, Youtube). So from a consumer perspective the change will be less noticeable (DNS takes care of that). Security however is a different aspect: this could be a potential nightmare with lots of devices directly connected to the internet. Besides the security aspects, for ISPs (where I work) there are quite a lot of changes (main router vendors that are not ready yet, provisioning systems that are not ready, CPE's etc.) so the real work and part of the reason why adoption is slow, lies there.
All that being said: it's about time Hacker News itself becomes IPv6 ready!
All that being said: it's about time Hacker News itself becomes IPv6 ready!
IPv6 is happening. Consumer ISPs are rolling out out. Parts of the world depleted of IPv4 (like Africa) has no choice.
IPv6 deployment looks like now. It's finally happening, but slowly.
As a professional, you can ignore it for now, but soon you will be expected to know it and be able to operate it. I give it 5 more years.
IPv6 deployment looks like now. It's finally happening, but slowly.
As a professional, you can ignore it for now, but soon you will be expected to know it and be able to operate it. I give it 5 more years.
A lot like today. Half-in, half-out at most.
Applications are the key driver. I could see this if IOT really takes off - autoconfiguration and unique addressing are the attributes that would make IPv6 the only compelling choice. That said, IOT still has a ton of challenges.
Applications are the key driver. I could see this if IOT really takes off - autoconfiguration and unique addressing are the attributes that would make IPv6 the only compelling choice. That said, IOT still has a ton of challenges.
There won't be so much a migration as there will be a point that IPv4 traffic will be lower than IPv6 traffic.
Until that point almost everyone is going to be dual stack.
Until that point almost everyone is going to be dual stack.
Yesterday a new service was launched in RootedCON (Most Importan Security Spanish Congress): MrLooquer. It's a service focus on IPv6 Intelligence where you can navigate around a huge IPv6 services exposed database. Take a look at https://mrlooquer.com/
[deleted]
Would IPv6 addresses mean scraping would be easier?
I don't think it will. Even though most providers offer IPv6 addresses in /64 blocks, the services you might want to scrape will consider any request coming from the same /64 IPv6 block as coming from the same user.
/56 seems to be the most common, with a few people still advocating for /48s for all connections.
What do you mean scraping?
> What do you mean scraping?
Web scraping. It is the process of using software to automaticly extract information from websites: https://en.wikipedia.org/wiki/Web_scraping
Web scraping. It is the process of using software to automaticly extract information from websites: https://en.wikipedia.org/wiki/Web_scraping
Almost certainly they mean web scraping - making automated requests to websites and extracting/parsing data. It's used for e.g. getting prices/specifications of entire product catalog, or for duplicating a database that's only published in HTML.
Easy, the same way HDTV over the air was accomplished. There will be a legislated rule that ipv4 will be outdated, and the tech brokerse will need to deal with that over a decade.
Apple has started to require IPv6 support for app store approval. I see this as an interesting approach that could push adoption, at least on the backend side.
I have been hearing "IPV6 is just on the horizon", "IPV4 is completely exhausted, it's only a matter of months", etc... for years now.
IPV4 exhaustion scare-mongering has been so slow recently one might easily have assumed that it was forgotten about or that the problem has been solved.
I am sitting here writing some security checks into a new website I am working on that makes sure that IPV4 addresses aren't hammering certain important parts of the site too quickly... and I can't help but wonder when this code will become obsolete due to full IPV6 integration.
Does anyone have any insight into the current situation of IPV6?