The graph is interesting when you zoom in, much more IPv6 use over the holiday period and also recently during the period of lockdown measures. I would guess the majority of IPv6 traffic comes from devices on 4G networks. More devices are on 4G when visiting family and friends over the Christmas period and when working remotely.
It's not just 4G. It's consumer networking in general, which isn't held back by legacy enterprise networking equipment. When your residential ISP turns on IPv6 for their network, they also tend to turn on IPv6 for the modem+router combo devices they lease to run your LAN. Or if you're the kind of power user that buys your own router, it's almost certainly new enough to support IPv6.
My parent's BT internet connection got upgraded in the last few months and they were provided a new BT Hub 2 with IPv4/IPv6 enabled. They live in a moderately rural village in the UK.
It is very different week days vs weekends too. Mobile connectivity is part of the answer, especially in the US - but more over businesses tend to have crappy network connectivity which is perversely small-C conservative and that means lots of them are still doing IPv4 even when that's directly contrary to their own needs.
Corporate networks tend to have a lot of local policy, and so that's a maintenance burden that probably nobody is paying for so it's just a growing debt for the organisation. Even if every policy was excellent when it was deployed many of them probably hurt by now. At home that stuff tends to get flushed periodically but medium-large businesses have processes to preserve the status quo. The same underlying mechanism that prefers to terminate the 25 year secretary who "made fuss" about a VP putting his hand up her skirt rather than do anything about that senior executive will also prefer to buy $5000 Cisco switches and then disable everything that makes them better than a $50 Costco switch over just buying the Costco switch (let alone using the features of the expensive switch). Change is seen as bad and must be prevented.
This hurts for security a lot too. There's a very good chance that accessing work email from a work laptop in the office is meaningfully less safe than accessing GMail on your phone in a random coffee shop because of such policies.
The highest weekly peak so far is 33.42%, and the troughs are just below 30% at the moment. The last time the weekly peak was ~30% was in December last year.
Maybe I'm weird, but I would assume that less devices are using 4G because of the lockdown, at least in the US are similar countries... most people are staying at home, i.e. on their Wifi, right?
And yet, when I beg my google cloud rep for IPv6 addresses on instances (or on anything that isn’t the load balancer) I get told that it is not on the immediate roadmap.
The cloud providers have pushed back ipv6 adoption so hard imo. At least native ipv6 access.
I know they’ve thrown in some token support and you /can/ make something work; but compared to VPS providers which consistently deliver machines with IPv6 addresses by default- it’s a huge barrier to adoption. You have to really /want/ it, and most people don’t see the value. Unless it’s a backend for an iOS App.
Azure's IPv6 "support" saddens me. It's just painful how minimal their support is.
For one, they NAT all IPv6 traffic.
Let that sink in. Let it percolate. Mull over the fact that the entire purpose of IPv6 is to eliminate NAT, and that it's practically impossible to get an IPv6 NAT-ing network device.
Microsoft must have had to write their own, custom network load balancers to NAT IPv6. It's madness.
Oh, if that's not bad enough, they also hand out ludicrously small /124 ranges of just 16 addresses. Sixteen! Not sixteen trillion or some crazy huge number like that, which is what I've got on my home internet. Sixteen. Six and ten.
But no worries, right? Just allocate more blocks! Bzzt... that would run up against the subscription IP limits with just 100 addresses.
Okay, fine, just because my lab environment needed more than a couple of addresses doesn't mean that everybody is so wasteful with the precious IPv6 address pool. Some people can constrain themselves to just a handful of addresses, and don't have a problem with any of the above.
Except that when Azure finally adds proper, native IPv6 support, whatever work their early adopter customers have done will have to be thrown out and redone. Subnets. DNS addresses. Load balancer rules. NAT rules. Security Groups. Everything will have to be revisited.
We've been experimenting with Azure's IPv6 support at work recently. The fact it uses NAT is insane - though we could tolerate that. Even worse is that the NAT is broken - it doesn't update the ICMPv6 checksum when it rewrites the source/destination address, so the machines on both ends drop all ICMPv6 traffic that passes through Azure.
This is rather bad considering the importance of ICMPv6 in IPv6 (for Path MTU Discovery, for example).
Their support is being rather useless, despite us having to pay for the privilege of reporting a bug in their own infrastructure to them!
It's natural because AWS/GCP/etc are against internet style system architectures (=natural IP addressing of your components), they are all about RFC1918 subnets, NAT gateways and L7 proxying. AWS even tells you it's bad architecture (or at least not "Well Architected") to build internet-style systems.
RFC1918 was forced upon the cloud providers only because there weren't enough IPv4 addresses to go around.
If Amazon had started in 1980, they would have simply allocated a /8 for each region and be done with it. No NAT, no gateways, no address translation of any sort. Everything routing to everything else natively.
IIRC, all GCPs IPv6 support is complicated by the fact that they adopted IPv6 from the get-go for internal routing, and layer the user-visible virtual address space on top of it, embedding the user-visible addresses inside the invisible "actual" VM addresses, and that layering strategy allows for something super amazing or fast or something. Something like that.
So then you ask the engineers, "when are you going to adopt IPv6?" And they're like: "What do you mean? We've never NOT used IPv6 for everything important."
On the one had my GCP server's "native" IP address that the OS sees is always an IPv4 address. On the other hand, it's always in the 10.x.x.x/8 range. Everything else is NAT and LB.
Google definitely uses IPv6 internally (ie office WiFi is now using IPv6 only (with the router doing translations to IPv4 if the site doesn’t support IPv6) and afaik most of the servers in the datacenter/clusters are IPv6 only now as they ran out of IPv4 LAN IPs for their clusters.
I just think that there’s little demand on cloud (and tons of other high prior work)
AWS supports IPv6 almost everywhere. Azure has some support but requires IPv6 NAT for some mysterious reason. Most of the smaller cloud/VPS providers support it: Digital Ocean, Vultr, Linode, OVH, Packet.net, and so on.
The AWS elastic load balancers don’t support IPv6 targets, and since they are used in almost all circumstances means that AWS’ support for IPv6 is practically irrelevant. Plus, it’s not on their road map to fix.
My ISP supports IPv6, and while I can understand why a large organisation would want to use it (especially given the increasing cost and scarcity of IPv4 blocks), I'm still yet to be persuaded of its benefits for home users. I admit that I only have a very cursory understanding of how it works, and perhaps I'm just stuck in my ways, but the scale and complexity seems so extreme compared to IPv4, with no compensating advantages that I can see. So all my devices become globally routable. And? I can already do everything I want and need to do with a single IPv4 address and NAT.
Even just working out what IPv6 devices are on my network and who they're communicating with seems very difficult given the giant address space. I'm slightly ashamed to admit this (feels very anti progress!), but I've blocked all the IPv6 traffic on my home LAN. Devices can still talk to each other, but no IPv6 packets are allowed out to the internet. Everything still works fine. My firewall blocks a few hundred MB per day of IPv6 traffic, and I have no idea what any of it is.
Very happy to be told why I shouldn't do this though.
You've had a few replies so I guess mine will be lost to the aether.
NAT vs Direct addressing is an interesting topic, because we've gotten so used to working around the issues inherent in NAT that we take them as a sort of given. I'll lay them out here:
1) The actual NAT state table in your router is much slower than a simple bit-map firewall lookup. This will show up as a bit of latency on every new connection.
2) The state table can get full. When that happens some connection needs to be evicted. For web technologies this wont look too bad.. Maybe a websocket connection gets closed and re-connects in the background. But if you're streaming something over raw TCP then that's annoying. Basically it makes your internet connection just that little less stable.
3) uPnP exists to try to mitigate the p2p issues with NAT; but does a poor job. -- Take for instance, a video game with VOIP, consoles are notorious for this; centralising and muxing everyones audio is expensive, so it's more useful to help people build peer meshes. So "NAT PUNCHING" is the normal way to go, but of course that doesn't always work, so you have weird tutorials on "how to port forward" when in reality this shouldn't be needed, a stateful firewall would be enough if not for NAT. Some guides even suggest putting your devices in the DMZ with direct port forwards on every port from the internet[!!]
> The state table can get full. When that happens some connection needs to be evicted.
This would be so much more convincing with some numbers to show it actually does happen in reality, especially at a rate that's comparable to other random connection drop-outs.
Anecdotal, but IPv6 saved me a lot of headache recently.
I got a warning about an unauthorized attempted login to my gmail account. They gave me the IP of the offending login. I was able to track that IP not only back to my house, but to a specific device in my house.
It was my NAS, and it was trying to log into gmail to send me an email about a failing drive. Gmail no longer allows username/password logins from third party apps, so I got a warning instead.
Without IPv6, I would have just chalked it up to a misbehaving device and ignored it since it came from my own IP, but because of IPv6, I was able to see it was from the NAS and investigate further.
What complexity? Devices being autoconfigurable without DHCP is less complex. Having no NAT is less complex. Having a public IP is less complex. You just got used to the complexity of IPv4.
Why the hell would you block IPv6. You ARE stuck in your ways. OS vendors consider it necessary on LAN for various functionality.
Devices configuring without DHCP as a network administrator is really hard. There is no longer a single method to be given an IP6 address, and with the auto methods, there is no log either. Only some clients will do dhcpv6 which means you often have two different auto configuring services on a network.
Similarly, to see devices on a network I now have to use neighborhood discovery whice gives me a bunch of IPs, but very hard to figure out which IP is for that raspberrypi next to me. Port scans are much harder.
Public IP address are great, but now a filtering firewall is always required at the edge, since I don't want my printer being reachable on the internet. There isn't a upnp for IP6 to punch wholes automatically either. Ironically P2P over ipv6 is harder because the firewalls are so unforgiving.
1. What the hell is DHCP-PD and is it better on or off?
2. What are 6to4, 6in4, 6rd, etc. and should the user care?
3. When should autoconf be stateless vs. stateful? I thought the point of IPv6 was to allow things to be stateless?
4. When should DHCPv6 be enabled vs. disabled? Why the hell is this even a question on some routers if devices are supposed to be "autoconfigurable without DHCP"?
5. What are the more subtle implications of all of the above that are not necessarily mentioned?
6. Give one good reason why in the world every single one of every user's devices should be reachable from anywhere on the internet for even a single moment in time? Why exactly do you feel you should even have a reachable path to my computer, and everyone else's too? Common sense precautions would suggest this shouldn't be possible by default.
Note: I personally don't need responses to all of these. I'm just listing some examples of questions that come up for people configuring it to illustrate why the choice to use IPv6 is hardly as simple as you depict it to be.
> Very happy to be told why I shouldn't do this though.
Because your IPv4 traffic goes (or will, in the future, as IPv4 depletes further) through a slow, overprovisioned CGNAT - making IPv4 much slower then IPv6.
That's scaremongering and simply false. Cgnat servers are not necessarily congested. I've been to several isps with cgnat and none of them suffered from congestion.
On a more personal note, if ipv6 were so great, their fans wouldn't have to make up things to badmouth ipv4.
While NAT works very well for home users, servers still need distinct IPs if they are to be accessible by the public. You can get away with shared IPs with some protocols but sometimes you need a whole IP to yourself.
The advantage of ipv6 for consumers is that many ISPs (especially non american ISPs) don't and can't hand out public IPv4 addresses, due to the lack of remaining IPv4 addresses for them to allocate.
The choice isn't between every device being globally routable (which is easily solved by a firewall WITHOUT NAT) and a single routable address, the choice is between zero public routable addresses, and as many as you need.
A large part of the problem with IPv6 is that most developers and SA's don't have a lot of knowledge about it. This is why everything new is still built with IPv4 in mind, instead of thinking forward to IPv6. I think we could easily blame lack of IPv6 support at cloud providers to lack of knowledge with the developers and SA's they attract.
If more developers and SA's would have access to IPv6 at home, the practical knowledge of how to work with IPv6 would build up more quickly. I would experiment with it more, and build up more knowledge.
Unfortunately, my ISP does not support IPv6. This severely limits experimentation with it, since all experimentation is locked behind my home network.
> Unfortunately, my ISP does not support IPv6. This severely limits experimentation with it, since all experimentation is locked behind my home network.
You probably know about this already, but there are free IPv6 tunnel brokers you can use to experiment. I previously used Hurricane Electric's tunnel, back before Comcast had native IPv6 support: https://www.tunnelbroker.net/
I previously used Hurricane Electric, too, but Netflix blocked it.
A more practical challenge, Hurricane Electric is a 6in4 tunnel, not layered over TCP nor UDP. Some ISP-provided residential gateway devices (AT&T) don’t support 6in4, not even if you configure your device as a “DMZ” with a public IP address. Also, I frequently find myself in situations with IPv4 NAT and no public IPv4 addresses at all.
The only free IPv6 tunnel service that supported UDP was SixXS, which shut down in 2017.
Nowadays, AT&T supports IPv6 natively, and I went through an annoying amount of effort to bypass their gateway device and control the entire /60 instead of being limited to a /64 and being limited by their NAT.
https://github.com/jaysoffian/eap_proxy
In Japan, consumer Internet is generally IPv6 first since years. For my ISP, I get IPv6 directly but have to configure a provided ipip6 tunnel (or set up my own) to get external IPv4 connectivity.
I host some services at home, mainly targeted at friends and family.
Some are IPv6-only, because it's much easier to manage from my side. I whish I could add an A record for these that pointed to a reserved IP address that would inform clients the service is IPv6-only.
For now, I just don't put any, and browsers just display a generic error. Since some DNS don't answer with IPv6 addresses, the browser couldn't even provide a meaningful error message if it tried to.
Would that be worth an RFC? What IP address should be used?
* I don't know any browser or app that display a special, informative message in that specific case.
* You need a DNS server that answers AAAA record to detect this. Some ISPs do not provide IPv6 connectivity, nor do their DNS servers provide AAAA records. In most places I know, especially when talking about individuals, people use their ISP-provided DNS servers.
For web services, one sad way to handle it is to proxy through Cloudflare. IPv4, IPv6, DNSSEC, TLS at the cost of selling your users out to a budding monopoly.
Readit News
Corporate networks tend to have a lot of local policy, and so that's a maintenance burden that probably nobody is paying for so it's just a growing debt for the organisation. Even if every policy was excellent when it was deployed many of them probably hurt by now. At home that stuff tends to get flushed periodically but medium-large businesses have processes to preserve the status quo. The same underlying mechanism that prefers to terminate the 25 year secretary who "made fuss" about a VP putting his hand up her skirt rather than do anything about that senior executive will also prefer to buy $5000 Cisco switches and then disable everything that makes them better than a $50 Costco switch over just buying the Costco switch (let alone using the features of the expensive switch). Change is seen as bad and must be prevented.
This hurts for security a lot too. There's a very good chance that accessing work email from a work laptop in the office is meaningfully less safe than accessing GMail on your phone in a random coffee shop because of such policies.
I don’t have it on 4G, either.
edit: am I missing something? The graph shows total IPv6 is 29.86% (which is clearly less than 33.33…%)
The highest weekly peak so far is 33.42%, and the troughs are just below 30% at the moment. The last time the weekly peak was ~30% was in December last year.
The cloud providers have pushed back ipv6 adoption so hard imo. At least native ipv6 access.
I know they’ve thrown in some token support and you /can/ make something work; but compared to VPS providers which consistently deliver machines with IPv6 addresses by default- it’s a huge barrier to adoption. You have to really /want/ it, and most people don’t see the value. Unless it’s a backend for an iOS App.
It really frustrates me.
For one, they NAT all IPv6 traffic.
Let that sink in. Let it percolate. Mull over the fact that the entire purpose of IPv6 is to eliminate NAT, and that it's practically impossible to get an IPv6 NAT-ing network device.
Microsoft must have had to write their own, custom network load balancers to NAT IPv6. It's madness.
Oh, if that's not bad enough, they also hand out ludicrously small /124 ranges of just 16 addresses. Sixteen! Not sixteen trillion or some crazy huge number like that, which is what I've got on my home internet. Sixteen. Six and ten.
But no worries, right? Just allocate more blocks! Bzzt... that would run up against the subscription IP limits with just 100 addresses.
Okay, fine, just because my lab environment needed more than a couple of addresses doesn't mean that everybody is so wasteful with the precious IPv6 address pool. Some people can constrain themselves to just a handful of addresses, and don't have a problem with any of the above.
Except that when Azure finally adds proper, native IPv6 support, whatever work their early adopter customers have done will have to be thrown out and redone. Subnets. DNS addresses. Load balancer rules. NAT rules. Security Groups. Everything will have to be revisited.
So why would you bother?
https://docs.microsoft.com/en-us/azure/virtual-network/ipv6-...
This is rather bad considering the importance of ICMPv6 in IPv6 (for Path MTU Discovery, for example).
Their support is being rather useless, despite us having to pay for the privilege of reporting a bug in their own infrastructure to them!
That’s why adoption is slow.
NAT isn’t such a huge problem that the industry thinks it’s urgent enough to push hard to solve.
RFC1918 was forced upon the cloud providers only because there weren't enough IPv4 addresses to go around.
If Amazon had started in 1980, they would have simply allocated a /8 for each region and be done with it. No NAT, no gateways, no address translation of any sort. Everything routing to everything else natively.
So then you ask the engineers, "when are you going to adopt IPv6?" And they're like: "What do you mean? We've never NOT used IPv6 for everything important."
On the one had my GCP server's "native" IP address that the OS sees is always an IPv4 address. On the other hand, it's always in the 10.x.x.x/8 range. Everything else is NAT and LB.
Take a look at kubernetes, which is based on google's Borg. It's only now, slowly getting IPv6 support
I just think that there’s little demand on cloud (and tons of other high prior work)
Laughable, right?
IPv6 was available in Windows 2000. Just saying.
Why? What problem does this solve?
Even just working out what IPv6 devices are on my network and who they're communicating with seems very difficult given the giant address space. I'm slightly ashamed to admit this (feels very anti progress!), but I've blocked all the IPv6 traffic on my home LAN. Devices can still talk to each other, but no IPv6 packets are allowed out to the internet. Everything still works fine. My firewall blocks a few hundred MB per day of IPv6 traffic, and I have no idea what any of it is.
Very happy to be told why I shouldn't do this though.
NAT vs Direct addressing is an interesting topic, because we've gotten so used to working around the issues inherent in NAT that we take them as a sort of given. I'll lay them out here:
1) The actual NAT state table in your router is much slower than a simple bit-map firewall lookup. This will show up as a bit of latency on every new connection.
2) The state table can get full. When that happens some connection needs to be evicted. For web technologies this wont look too bad.. Maybe a websocket connection gets closed and re-connects in the background. But if you're streaming something over raw TCP then that's annoying. Basically it makes your internet connection just that little less stable.
3) uPnP exists to try to mitigate the p2p issues with NAT; but does a poor job. -- Take for instance, a video game with VOIP, consoles are notorious for this; centralising and muxing everyones audio is expensive, so it's more useful to help people build peer meshes. So "NAT PUNCHING" is the normal way to go, but of course that doesn't always work, so you have weird tutorials on "how to port forward" when in reality this shouldn't be needed, a stateful firewall would be enough if not for NAT. Some guides even suggest putting your devices in the DMZ with direct port forwards on every port from the internet[!!]
https://www.denofgeek.com/games/how-to-change-nat-type-on-ps...
This would be so much more convincing with some numbers to show it actually does happen in reality, especially at a rate that's comparable to other random connection drop-outs.
I got a warning about an unauthorized attempted login to my gmail account. They gave me the IP of the offending login. I was able to track that IP not only back to my house, but to a specific device in my house.
It was my NAS, and it was trying to log into gmail to send me an email about a failing drive. Gmail no longer allows username/password logins from third party apps, so I got a warning instead.
Without IPv6, I would have just chalked it up to a misbehaving device and ignored it since it came from my own IP, but because of IPv6, I was able to see it was from the NAS and investigate further.
Why the hell would you block IPv6. You ARE stuck in your ways. OS vendors consider it necessary on LAN for various functionality.
Devices configuring without DHCP as a network administrator is really hard. There is no longer a single method to be given an IP6 address, and with the auto methods, there is no log either. Only some clients will do dhcpv6 which means you often have two different auto configuring services on a network.
Similarly, to see devices on a network I now have to use neighborhood discovery whice gives me a bunch of IPs, but very hard to figure out which IP is for that raspberrypi next to me. Port scans are much harder.
Public IP address are great, but now a filtering firewall is always required at the edge, since I don't want my printer being reachable on the internet. There isn't a upnp for IP6 to punch wholes automatically either. Ironically P2P over ipv6 is harder because the firewalls are so unforgiving.
1. What the hell is DHCP-PD and is it better on or off?
2. What are 6to4, 6in4, 6rd, etc. and should the user care?
3. When should autoconf be stateless vs. stateful? I thought the point of IPv6 was to allow things to be stateless?
4. When should DHCPv6 be enabled vs. disabled? Why the hell is this even a question on some routers if devices are supposed to be "autoconfigurable without DHCP"?
5. What are the more subtle implications of all of the above that are not necessarily mentioned?
6. Give one good reason why in the world every single one of every user's devices should be reachable from anywhere on the internet for even a single moment in time? Why exactly do you feel you should even have a reachable path to my computer, and everyone else's too? Common sense precautions would suggest this shouldn't be possible by default.
Note: I personally don't need responses to all of these. I'm just listing some examples of questions that come up for people configuring it to illustrate why the choice to use IPv6 is hardly as simple as you depict it to be.
According to Apple, IPv6 is 1.4 times faster than IPv4 (latency wise AFAICT):
* https://www.zdnet.com/article/apple-tells-app-devs-to-use-ip...
This is supposedly "due to reduced NAT usage and improved routing."
It is great marketing to list 40%. But we need to know 40% of what. If it was 1ms, than 0.4ms faster isn't much of a performance.
Because your IPv4 traffic goes (or will, in the future, as IPv4 depletes further) through a slow, overprovisioned CGNAT - making IPv4 much slower then IPv6.
On a more personal note, if ipv6 were so great, their fans wouldn't have to make up things to badmouth ipv4.
The choice isn't between every device being globally routable (which is easily solved by a firewall WITHOUT NAT) and a single routable address, the choice is between zero public routable addresses, and as many as you need.
If more developers and SA's would have access to IPv6 at home, the practical knowledge of how to work with IPv6 would build up more quickly. I would experiment with it more, and build up more knowledge.
Unfortunately, my ISP does not support IPv6. This severely limits experimentation with it, since all experimentation is locked behind my home network.
You probably know about this already, but there are free IPv6 tunnel brokers you can use to experiment. I previously used Hurricane Electric's tunnel, back before Comcast had native IPv6 support: https://www.tunnelbroker.net/
A more practical challenge, Hurricane Electric is a 6in4 tunnel, not layered over TCP nor UDP. Some ISP-provided residential gateway devices (AT&T) don’t support 6in4, not even if you configure your device as a “DMZ” with a public IP address. Also, I frequently find myself in situations with IPv4 NAT and no public IPv4 addresses at all.
The only free IPv6 tunnel service that supported UDP was SixXS, which shut down in 2017.
Nowadays, AT&T supports IPv6 natively, and I went through an annoying amount of effort to bypass their gateway device and control the entire /60 instead of being limited to a /64 and being limited by their NAT. https://github.com/jaysoffian/eap_proxy
It's surprising that China doesn't show as dark green on the world map. China was into IPv6 early; the address space was needed.
This one better describes the situation: https://blog.apnic.net/2019/01/03/ipv6-in-china/
Some are IPv6-only, because it's much easier to manage from my side. I whish I could add an A record for these that pointed to a reserved IP address that would inform clients the service is IPv6-only.
For now, I just don't put any, and browsers just display a generic error. Since some DNS don't answer with IPv6 addresses, the browser couldn't even provide a meaningful error message if it tried to.
Would that be worth an RFC? What IP address should be used?
Even better if web browsers could display a message of their own, recognizing this IP address.
* I don't know any browser or app that display a special, informative message in that specific case.
* You need a DNS server that answers AAAA record to detect this. Some ISPs do not provide IPv6 connectivity, nor do their DNS servers provide AAAA records. In most places I know, especially when talking about individuals, people use their ISP-provided DNS servers.