IPv6 breaks the 25% barrier(google.com)
google.com
IPv6 breaks the 25% barrier
https://www.google.com/intl/en/ipv6/statistics.html?25%
144 comments
Based on Cloudflare traffic data we see this over the last 7 days:
US 39.56%
IN 39.03%
BE 36.97%
IE 36.23%
MY 30.55%
DE 28.24%Huh, interesting! I wonder where the discrepancy comes from.
> Huh, interesting! I wonder where the discrepancy comes from.
Probably because the Cloudflare data is percentage of traffic (e.g. total requests), and the Google data is percentage of users. Mobile traffic is more likely to be IPv6, and that would skew the numbers.
Probably because the Cloudflare data is percentage of traffic (e.g. total requests), and the Google data is percentage of users. Mobile traffic is more likely to be IPv6, and that would skew the numbers.
Yeah, cloudflare sees a lot of backend systems too (servers); whereas Google probably gets more from (and is reporting on) devices attached to humans.
https://blog.cloudflare.com/ipv6-in-china/
There are some large countries out there. Note that according to my sibling comment, Belgium isn't #1, or above 50%, right now.
There are some large countries out there. Note that according to my sibling comment, Belgium isn't #1, or above 50%, right now.
It's an apples vs. oranges comparison.
I (Cloudflare) am talking about traffic %; Google is talking about % of users. Cloudflare doesn't have a concept of 'user'.
I (Cloudflare) am talking about traffic %; Google is talking about % of users. Cloudflare doesn't have a concept of 'user'.
> Belgium has been slightly above 50% IPv6 traffic to Google for quite a while now
That sounds like percentage of traffic to me?
That sounds like percentage of traffic to me?
That's what the parent comment says but the linked page on Google is talking about users: "The graph shows the percentage of users that access Google over IPv6".
Google's own GCE still doesn't have IPv6 support on the instance level:
https://googlecloudplatform.uservoice.com/forums/302595-comp...
https://googlecloudplatform.uservoice.com/forums/302595-comp...
I'm a huge fan of IPv6 as it's a huge contributor to ensure the continued openness of the internet. Also, I'm in the privileged position of having a native dual-stack provided by my ISP, so I have native IPv4 and IPv6 both at home and in the office.
And yet, even in this position, I think having IPv6 native inside of a production network isn't absolutely necessary (our production env runs in the RFC1918 space too even though v6 would be available at both ends):
Access to the private production network should all happen over an encrypted and authenticated VPN and all access form the production network to the public network (if needed at all) should go through a filtering proxy server.
Which means that the addressing used in your internal network becomes completely irrelevant and can easily be IPv4.
This only becomes an issue once you need more hosts than the /8 offered by the 10/8 RFC1918 network, but the days when you need (and can afford) more than 16.7M nodes on a cloud computing provider are probably still a ways off.
If you want instance level IPv6 in order to access an instance directly or in order to access a resource directly, you're probably doing something wrong.
Then again, as services become v6 only (which will still be a few years off) and you need to access them from your production network, then your frontend proxy will of course need access to the v6 network. At that point, yes, instance level v6 becomes necessary too.
And yet, even in this position, I think having IPv6 native inside of a production network isn't absolutely necessary (our production env runs in the RFC1918 space too even though v6 would be available at both ends):
Access to the private production network should all happen over an encrypted and authenticated VPN and all access form the production network to the public network (if needed at all) should go through a filtering proxy server.
Which means that the addressing used in your internal network becomes completely irrelevant and can easily be IPv4.
This only becomes an issue once you need more hosts than the /8 offered by the 10/8 RFC1918 network, but the days when you need (and can afford) more than 16.7M nodes on a cloud computing provider are probably still a ways off.
If you want instance level IPv6 in order to access an instance directly or in order to access a resource directly, you're probably doing something wrong.
Then again, as services become v6 only (which will still be a few years off) and you need to access them from your production network, then your frontend proxy will of course need access to the v6 network. At that point, yes, instance level v6 becomes necessary too.
Using IPv4 internally becomes an issue as soon as you need to interconnect with someone else's internal network which uses overlapping IPv4 address space. The most famous example is probably Facebook's acquisition of Instagram, which required an incredible amount of iptables hackery to work around overlapping IPv4 address space: https://instagram-engineering.com/migrating-from-aws-to-fb-8...
In contrast, even if you use "private" IPv6 addresses (ULA), the address space is large enough that everyone can have their own prefix. Or better, just use public IPv6 addresses and firewall them.
In contrast, even if you use "private" IPv6 addresses (ULA), the address space is large enough that everyone can have their own prefix. Or better, just use public IPv6 addresses and firewall them.
Then again, IPv6 hasn't really been built with NAT in mind, precisely because "there are so many addresses out there you won't need it". So if you decide for an IPv6 deployment for your servers, you're essentially between a rock (you can't easily transfer an IPv6 address space from one cloud provider to the next) and a hard place (use ULA addresses internally and having to NAT to the outside anyway, but with less software and hardware support). As for me personally, I'm totally fine with IPv4 behind the load balancer: it gives me a much easier time with basically everything and I can still support both v4 and v6 for all clients connecting to my site as well.
IPv4 also hasn't been built with NAT in mind. And given the disaster it has been ... no, obviously, noone in their right mind would build a new protocol with NAT in mind.
For one, you don't need NAT to use ULA internally. You just use ULA for internal stuff and global addresses for everything else.
But really, if renumbering is a problem in the first place, you are doing something fundamentally very wrong. Renumbering should be a matter of adding a new prefix of the same length to your addressing plan and replicating in it the exact same subnet structure you had before, then deprecating the old prefix (so it's not used for new outbound connections), waiting a bit, and then removing the old prefix. If your problem is hard-coded addresses everywhere, that is also a problem with your system design. Almost all of your configuration should only contain host names, and your DNS should either use dynamic updates so that hosts register their current primary addresses with the DNS server, or some other mechanism that generates records from an addressing plan of sorts and a prefix. There should be very few places where you need to change addresses in order to switch prefixes.
For one, you don't need NAT to use ULA internally. You just use ULA for internal stuff and global addresses for everything else.
But really, if renumbering is a problem in the first place, you are doing something fundamentally very wrong. Renumbering should be a matter of adding a new prefix of the same length to your addressing plan and replicating in it the exact same subnet structure you had before, then deprecating the old prefix (so it's not used for new outbound connections), waiting a bit, and then removing the old prefix. If your problem is hard-coded addresses everywhere, that is also a problem with your system design. Almost all of your configuration should only contain host names, and your DNS should either use dynamic updates so that hosts register their current primary addresses with the DNS server, or some other mechanism that generates records from an addressing plan of sorts and a prefix. There should be very few places where you need to change addresses in order to switch prefixes.
Yes, renumbering is a PITA.
NAT66 does exist and over time more software and hardware will support it. But you don't need NAT if you are using ULA; instead you would configure each system with both its ULA address and the global address from your provider (SLAAC can advertise multiple prefixes). Traffic to other internal systems would use the ULA addresses, while traffic to the Internet would use the global address.
NAT66 does exist and over time more software and hardware will support it. But you don't need NAT if you are using ULA; instead you would configure each system with both its ULA address and the global address from your provider (SLAAC can advertise multiple prefixes). Traffic to other internal systems would use the ULA addresses, while traffic to the Internet would use the global address.
Why would it be important to be able to switch cloud providers and keep the same addresses on your internal network? Changing providers while keeping addresses seems abstractly like a nice capability to have but it also seems that it might or might not end up being just as much logistical trouble as re-addressing everything when it came down to the implementation...
Change prefix, keep the suffix.
While GCP has IPv6 support for their global load balancers, it's very limited and not sufficient for many uses.
For example, I've been working on contributing IPv6 support to GitLab.com [0], which is hosted on GCP. Turns out it's impossible for the main site right now, because none of the global load balancer types allow port 22, which is used for Git traffic. I've no idea why there are even such restrictions, but there's of course a "feature" request for allowing port 22 [1]. I was able to repurpose the work for other parts of GitLab.com, but I've yet to get even those to work, due to the load balancers gobbling up HTTPS/SSL requests [2].
[0] https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merg...
[1] https://issuetracker.google.com/issues/77944636
[2] https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merg...
For example, I've been working on contributing IPv6 support to GitLab.com [0], which is hosted on GCP. Turns out it's impossible for the main site right now, because none of the global load balancer types allow port 22, which is used for Git traffic. I've no idea why there are even such restrictions, but there's of course a "feature" request for allowing port 22 [1]. I was able to repurpose the work for other parts of GitLab.com, but I've yet to get even those to work, due to the load balancers gobbling up HTTPS/SSL requests [2].
[0] https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merg...
[1] https://issuetracker.google.com/issues/77944636
[2] https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merg...
GLB can't even support TCP and UDP listeners on the same IP, which means you can't put a DNS server behind it.
Having two IP addresses is all that is necessary for most private networks, it's just a dumb and over complicated way of traversing nodes. Same with 2^24 IPs.
"Access to the private production network should all happen over an encrypted and authenticated VPN"
IPsec, likely the same thing that'd be encrypting your VPN, can just be used directly between hosts without complication if you have all public addresses.
"and all access form the production network to the public network (if needed at all) should go through a filtering proxy server."
Why does it have to be a proxy? Why not just a firewall sitting in the route path? Again, the way you're use to working around a limited address space is leading to complicated solutions to problems easily solved by having more addresses.
In computing very little is "necessary" but it doesn't mean it makes much sense for it to be that way the same as programming your cloud application with NAND logic doesn't make sense.
"Access to the private production network should all happen over an encrypted and authenticated VPN"
IPsec, likely the same thing that'd be encrypting your VPN, can just be used directly between hosts without complication if you have all public addresses.
"and all access form the production network to the public network (if needed at all) should go through a filtering proxy server."
Why does it have to be a proxy? Why not just a firewall sitting in the route path? Again, the way you're use to working around a limited address space is leading to complicated solutions to problems easily solved by having more addresses.
In computing very little is "necessary" but it doesn't mean it makes much sense for it to be that way the same as programming your cloud application with NAND logic doesn't make sense.
The amount of work that was done at the last two ISP's I worked due to being out of RFC1918 space and thus needing to do overlay networks, and all kinds of fun translating and gateways and overall making a HUGE mess of everything...
Because while there is a 10/8, once you start subnetting that and advertising it from multiple sites and start running labs that look and act like production that /8 goes quick.
Give me IPv6 any day.
Because while there is a 10/8, once you start subnetting that and advertising it from multiple sites and start running labs that look and act like production that /8 goes quick.
Give me IPv6 any day.
> And yet, even in this position, I think having IPv6 native inside of a production network isn't absolutely necessary
Not necessary, but it could be quite useful. The 64bit suffix of ULA addresses lets you group your containers into separate blocks with static prefixes. E.g. you could always have the :0000 - :FFFF block be your reverse proxies, the next block the storage shards and so on.
Not necessary, but it could be quite useful. The 64bit suffix of ULA addresses lets you group your containers into separate blocks with static prefixes. E.g. you could always have the :0000 - :FFFF block be your reverse proxies, the next block the storage shards and so on.
NAT is the devil. RFC1918 is the devil. Want to filter inbound traffic? It's called a firewall.
> This only becomes an issue once you need more hosts than the /8 offered by the 10/8 RFC1918 network, but the days when you need (and can afford) more than 16.7M nodes on a cloud computing provider are probably still a ways off.
It's not that you require more than a /8 can provide, it's more a function of convenience. I have 10 customers, each one of those has 4 environments (Dev, QA, Stage, Prod) and each of these environments need to live in 3 regions, and each region has 3 AZs, and each AZ has 6 subnets. Splitting that up with a 10.0.0.0/8 gets complicated. I would much rather say 2006:abcd:0001:::: is customer A, ::0002::: is customer B, etc. IPv6 gives me plenty of room to maneuver and eliminates the need to worry about IP exhaustion.
It's not that you require more than a /8 can provide, it's more a function of convenience. I have 10 customers, each one of those has 4 environments (Dev, QA, Stage, Prod) and each of these environments need to live in 3 regions, and each region has 3 AZs, and each AZ has 6 subnets. Splitting that up with a 10.0.0.0/8 gets complicated. I would much rather say 2006:abcd:0001:::: is customer A, ::0002::: is customer B, etc. IPv6 gives me plenty of room to maneuver and eliminates the need to worry about IP exhaustion.
It's not necessary for most applications, but it's extremely helpful for some. It can also be used to realize deployment scenarios where you cluster across clouds very easily provided you ensure connections are secure between nodes/containers/services.
> the days when you need (and can afford) more than 16.7M nodes on a cloud computing provider are probably still a ways off
And the days when you need 16M nodes all of which need to talk to each other directly are probably even further off.
(In fact, I would go even further and say that if you find yourself ever facing that situation you've done something badly wrong in your architectural design.)
And the days when you need 16M nodes all of which need to talk to each other directly are probably even further off.
(In fact, I would go even further and say that if you find yourself ever facing that situation you've done something badly wrong in your architectural design.)
Even if you need more IPs than the 10/8 network provides, there are other prefixes you can use, as long as your hosts do not need to ever directly connect to them, so you effectively have billions of private ips at your service.
Pro-tip: never do this outside of ranges explicitly reserved for private use. Multiple times a year I have to deal with some hospital somewhere saying "well <xyz> didn't use to come from that range!" and then dealing with the fact 10,000 medical devices can't have their IPs changed. Recently a similar thing happened with 1.1.1.1 and 1.0.0.1 when Cloudflare went live with them, nobody ever thought those IPs would be handed out.
But it does at the redirector/Traefik level.
Worse, Kubernetes as a model doesn't use IPv6 internally when it should. No reason not to use e.g. ULAs.
Worse, Kubernetes as a model doesn't use IPv6 internally when it should. No reason not to use e.g. ULAs.
dig +short aaaa news.ycombinator.com
[no output]I use the SixOrNot browser extension to see which sites have IPv6 enabled (and to test the IPv6 on my own website). Yep, YC has been IPv4 for a good long while.
There's also IPvFoo[0] for those on Chrome (it supports Firefox too, but is a bit buggier there).
[0] https://github.com/pmarks-net/ipvfoo
[0] https://github.com/pmarks-net/ipvfoo
They're working on it.
Why this pattern? From for example Jan to July 2018 there are 27 "cycles" - probably weeks. They go from say 18% to 22% in a week in a regular pattern. Peaks are sharper than the valleys. Are those weekends? Is there more use of IPv6 in the weekend?
> Is there more use of IPv6 in the weekend?
Most probably yes. Since IPv6 is deployed more on consumers side rather than enterprises. So it's not surprising that over the weekend IPv6 traffic hits a peak.
Most probably yes. Since IPv6 is deployed more on consumers side rather than enterprises. So it's not surprising that over the weekend IPv6 traffic hits a peak.
That makes a lot of sense. If you move to a new house and get a new router from your ISP, you're not going to notice or have to reconfigure a bunch of stuff if you're an average home user, for IPv6 (unless you're one of the people here on HN and have a complex network topology).
By default, most ISP routers firewall all IPv6 traffic (and IPv4 is implicitly firewalled via NAT). In an enterprise environment, dual stack support can get a lot more tricky and you need to ensure firewalls are property configured, or else regular workstations can be accessible via the public network.
By default, most ISP routers firewall all IPv6 traffic (and IPv4 is implicitly firewalled via NAT). In an enterprise environment, dual stack support can get a lot more tricky and you need to ensure firewalls are property configured, or else regular workstations can be accessible via the public network.
Yes.
Home connections have more IPv6 integration than businesses that have to configure their firewalls, etc.
Home connections have more IPv6 integration than businesses that have to configure their firewalls, etc.
As a web user, the ipv6 internet is basically Google, Facebook, and Wikipedia.. and freenode. that's pretty much it.
LinkedIn. Cloudflare. Akamai. Fastly. the CDNs can't enable webs who dont sign a consent. But.. you kinda need to look a bit harder.
Cloudflare enables IPv6 by default: https://blog.cloudflare.com/always-on-ipv6/
Good point. +1 for CloudFlare
[deleted]
Verizon FIOS seems to have given up any hope at implementing IPv6 :(
Seriously...its a shame. Comcast's dual stack is impressive. I've been debating about moving back to Comcast just for this reason (in the rare part of the country where I actually have a choice of two decent providers). I've asked a few different CSR's to mention up the chain about losing a potential customer over this, but I doubt anyone cares, especially since I haven't talked to a CSR that actually knows what ipv6 is. I've "heard" the issue is due to Verizon's old peering agreements.
They started rolling out IPv6 in a couple areas a few weeks ago [0].
[0] https://www.dslreports.com/forum/r32136440-Networking-IPv6-w...
[0] https://www.dslreports.com/forum/r32136440-Networking-IPv6-w...
Yeah I just stumbled upon that a few minutes ago. Hopefully it's the real deal this time.
oh wow, thanks for this! I gave up hunting for info after a few years ;)
Same with frontier. I hate that Verizon sold off parts of Fios to this awful company.
What makes you say that?
It's been 7+ years since they said they were implementing it and I haven't seen any users post that they have IPv6 enabled on FIOS. Also customer support says they dont support it and dont know if/when they would be (I asked when I was ordering 4 months ago).
I'd like to see a per ISP distribution. I gather that the majority of v6 adoption is by cellphone ISPs.
In switzerland, there is (still) no IPv6 from any cellphone provider.
I was working for one of the "big" 3 planning the rollout of IPv6 in their cellphone network. They stopped the project due to budget concerns. Doesn't seem to be too high of a priority for them.
Only the police is driving ipv6 hard in the carrier market (since tracing back connections via CGN is hard if not impossible).
There is little to no incentive to change a well working network, it makes (business) sense to introduce v6 in the upcoming G5 but not in the running setups.
There is little to no incentive to change a well working network, it makes (business) sense to introduce v6 in the upcoming G5 but not in the running setups.
Parents' laptop recently had an inscrutable problem where only a handful of sites worked. Turned out to only be able to load ipv6 websites. On virtually every Google result while fixing the issue, the only way to see the contents was from Google's cache, so it seems like server side adoption is still pretty scarce.
Did you find out what the issue was in the end? Was it because the IPv4 adapters were disabled?
Server side adoption is honestly not that bad. Quite a few major datacenters implement IPv6, but people don't set their A records or slightly modify their config for an IPv6 interface. Cloudflare provides a temporary proxy solution in that it offers IPv6, but it isn't really true IPv6.
Server side adoption is honestly not that bad. Quite a few major datacenters implement IPv6, but people don't set their A records or slightly modify their config for an IPv6 interface. Cloudflare provides a temporary proxy solution in that it offers IPv6, but it isn't really true IPv6.
I believe it was the ipv4 adapters being disabled, or something else being disabled or set wrong in the adapter settings. No idea how it gets like that in the first place, but apparently it's a problem that's happened to other people often enough for there to be a few threads about it on various support forums.
Why was there a barrier? I mean what was at the 25% mark that prevented surpassing it?
If you look at the graph, a year ago we were at 15%, so the it doesn't seem like there is a barrier, just growth finally hit that mark.
There may well be a barrier in the future, but so far there isn't any sign of one.
There may well be a barrier in the future, but so far there isn't any sign of one.
So from what I understand, when I use my tmobile phone over 4g,I don't have an ipv4 address that is routable.
So I am basically NATed to ipv6.
Is Google including this kind of mobile traffic? I would guess that they are.
So I am basically NATed to ipv6.
Is Google including this kind of mobile traffic? I would guess that they are.
"So from what I understand, when I use my tmobile phone over 4g,I don't have an ipv4 address that is routable."
T-Mobile is IPv6 only, you will have no IPv4 address assigned to your phone.
"So I am basically NATed to ipv6."
Other way around, your IPv6 connection is NATed to IPv4 via one of DNS64 or NAT64.
"Is Google including this kind of mobile traffic? I would guess that they are."
Yes, but maybe not in the way you're thinking if I'm reading your comment correctly. The IPv6 only portion is just INSIDE T-Mobile, when you need to leave T-Mobile to access services you will be using v6 if the services support v6 and v4 if the services support v4. Since Google is measuring this by how you connect to Google and most Google services are v6 enabled then you'll be counted as v6 properly. For the ones that aren't v6 enabled you'll be counted as v4 properly as they are measuring how you go over the general internet not how you traverse a private network.
T-Mobile is IPv6 only, you will have no IPv4 address assigned to your phone.
"So I am basically NATed to ipv6."
Other way around, your IPv6 connection is NATed to IPv4 via one of DNS64 or NAT64.
"Is Google including this kind of mobile traffic? I would guess that they are."
Yes, but maybe not in the way you're thinking if I'm reading your comment correctly. The IPv6 only portion is just INSIDE T-Mobile, when you need to leave T-Mobile to access services you will be using v6 if the services support v6 and v4 if the services support v4. Since Google is measuring this by how you connect to Google and most Google services are v6 enabled then you'll be counted as v6 properly. For the ones that aren't v6 enabled you'll be counted as v4 properly as they are measuring how you go over the general internet not how you traverse a private network.
My phone shows both an IPv6 address and, 192.168.0.x IPv4.
If it shows that address while connected to WWAN only, then it's probably coming from 464xlat -- basically your phone synthesizing its own internal v4 network, with any outbound v4 connections being translated into v6 connections to 64:ff9b::/96 (or whatever your ISP's NAT64 range is).
464xlat works well for letting legacy v4-only programs access v4 via NAT64, but it doesn't help them reach native v6 hosts.
464xlat works well for letting legacy v4-only programs access v4 via NAT64, but it doesn't help them reach native v6 hosts.
That 192.168.0.X address in an IPv4 private address. I'm assuming your phone is connected to Wi-Fi.
I specifically turned off Wi-Fi for the test. Although it is possible that the phone kept it as an ip address. I don't have a way to find out.
Normally this means if your phone supports IPv6 then you will actually be connecting with Google over IPv6 and if you can only use IPv4 then it's be tunnelled, v4 → v6 → v4. So the stats should be accurate.
I like NAT and the associated partial anonymity it can provide. (At least, you may have to hit up multiple organizations, maybe in different countries, to trace the endpoint(s).)
I'm not looking forward to IPv6 enabling/escalating yet another factor in tracking everything and everyone, online.
Maybe this is a grossly (as in, large) wrong and ill-informed perspective, on my part. If so, please disabuse me of it. I remain concerned.
I'm not looking forward to IPv6 enabling/escalating yet another factor in tracking everything and everyone, online.
Maybe this is a grossly (as in, large) wrong and ill-informed perspective, on my part. If so, please disabuse me of it. I remain concerned.
Are there any VPN services that don't have IP leaks for IPv6? I gave up and disabled it last time I investigated this issue.
Why was 25% a barrier? Will it get higher adoption now that it has passed the "barrier"?
It's an arbitrary number that looks nice and can be used to generate publicity for IPv6.
Also, it can be used as a selling point to stakeholders. Much easier to advocate for when > 25% of traffic is using it than say 10%
It looks like the problem of unique digital addressing will only get harder as more and more people are introduced to the internet. I wonder what will come after IPv6...
I would have expected an S-curve with an inflexion point at 50% but it seems to have already happened. We will probably have IPV4 for a long time.
Would be interesting to know how much of those are bots.
Seeing that IPv4 and IPv6 aren't interoperable and seeing as 75% of the internet is still running on IPv4 and assuming that the amount of v6 only hosts is absolutely minuscule, I would say that adapting and then running a bot on v6 is absolutely not worth it yet at this time.
Any reason to suspect that it wouldn't be a similar percentage as IPv4 traffic?
Only reason I can think of is it's way easier to get loads of ips to bypass rate limits with ipv6 than it is with ipv4
Which is only useful in the narrow case in which your target supports IPv6 and doesn't treat each /64 block as one address for the purposes of rate limiting. This combination seems quite rare.
Why would you think it's rare? I've seen places running multiple projects were developers were barely aware that the sysadmins gave everyone an IPv6 address, and therefore the rate limiting has to be IPv6-aware.
It's trivial to fix once it becomes a problem (at least in our case it was), but I wouldn't expect it to be an uncommon mistake.
It's trivial to fix once it becomes a problem (at least in our case it was), but I wouldn't expect it to be an uncommon mistake.
It’s pretty easy to acquire blocks larger than /64.
It would be trivial to rate-limit the whole subnet then.
Maybe, but that does not mean a lot of ISPs haven't done that.
if you rate-limit, you should probably be rate-limiting on the /64 prefix and those are about as hard to get as individual v4 addresses.
I got my ipv6 activated through a web forum from my isp (not even a small one) and writing one of the moderators a PM with my customer id :D
That was 3 years ago =)
That was 3 years ago =)
Comcast has had IPv6 enabled for all supporting devices since at least 2012.
* I've been running two IPv6 hosts without any issues since then.
* I've been running two IPv6 hosts without any issues since then.
I'm also a Comcast customer, but I'm nearly certain I didn't get an IPv6 deployment until at least 2013/2014; I remember looking at their rather hidden signup form for beta testing IPv6 in ~2012, and I remember it being a rather long wait after that before it finally happened.
(Some places definitely were seeing initial rollouts around that time, but it was a far cry from "all".)
(Some places definitely were seeing initial rollouts around that time, but it was a far cry from "all".)
I guess they officially started rolling it out in 2012. I'm in Atlanta and I noticed my modem's IP mode flip to "IPv6 Only" sometime in 2011. I've been hosting from two different machines since then and about 30% of my network traffic is IPv6.
IPv6 goes up on the weekends according to this graph?
Total guess, but might be better adoption of IPv6 amongst consumer ISPs comapred to business ISPs?
And still no signs of support from Virgin Media...
Not _no_ sign. There are teeny-tiny signs:
https://community.virginmedia.com/t5/QuickStart-set-up-and/I...
Virgin Media in IE certainly supports IPv6. Used it for over four years.
Why the extra 5 percentage points every weekend?
Because of people not working. IPv6 deployement on consumer internet providers is much higher than those of corporate environments.
Lack of IPv6 on corporate networks isn't very surprising, considering how hard/annoying enabling it is for business connections [0].
[0] https://www.reddit.com/r/ipv6/comments/9jxp2c/isps_and_busin...
Lack of IPv6 on corporate networks isn't very surprising, considering how hard/annoying enabling it is for business connections [0].
[0] https://www.reddit.com/r/ipv6/comments/9jxp2c/isps_and_busin...
I would believe it's because users are connecting in bigger proportions from their smartphones/home networks on weekends, compared to office networks during the week.
How is India so far ahead in IPv6 adoption?
Because with IPV4 addresses getting ever more expensive[1] going straight to IPV6 for as much as possible, and placing everything else behind a provider-wide NAT saves you a lot of money. And in India they're trying to modernise as cheaply as possible.
[1]https://www.ipv4auctions.com/
[1]https://www.ipv4auctions.com/
Is it usually cellular ISP that first adopt IPv6?
Because there's been a new disruptive player in telecom space called Jio and I am guessing they are behind this rise in IPv6 popularity.
Yes, but not always. In my country (Estonia) the biggest ISP (Telia) provides IPv6 for home connections, but not on the mobile network.
As for Reliance Jio, they have over 300 million IPv6 users, with a total IPv6 adoption of 88% [0][1].
[0] http://www.worldipv6launch.org/now-we-are-six/
[1] http://www.worldipv6launch.org/apps/ipv6week/measurement/ima...
As for Reliance Jio, they have over 300 million IPv6 users, with a total IPv6 adoption of 88% [0][1].
[0] http://www.worldipv6launch.org/now-we-are-six/
[1] http://www.worldipv6launch.org/apps/ipv6week/measurement/ima...
Even in the US, I believe the first large-scale IPv6 rollouts were by Verizon and Sprint.
Yes, buying IPv4 address is expensive today. If you have been an ISP for years there is no problem because you bought your IPv4 addresses at yesterday's low prices. If you are a new ISP you pay today's high prices - but ipv6 is nearly free so you roll that out to save money.
Mobile networks (3g/4g) in India operate on ipv6. Thanks to Jio everyone and their dog has a 4g connection nowadays.
That also makes sense considering the sheer amount of people. With that many devices and people, it just makes more sense than trying to NAT everything at the carrier level.
I wonder if China's ISPs are doing the same thing?
I wonder if China's ISPs are doing the same thing?
A year back the party decreed a plan to have all Internet users on IPv6 by 2025, with a quarter of them already by the end of this year [0]. There was a test rollout back at the beginning of the summer [1]. I guess we might see a huge rollout before the end of the year to meet the deadline. There's been a slight rebound already [2][3].
[0] https://en.wikipedia.org/wiki/IPv6_deployment#China
[1] https://blog.cloudflare.com/ipv6-in-china/
[2] https://stats.labs.apnic.net/ipv6/AS9808
[3] http://www.worldipv6launch.org/apps/ipv6week/measurement/ima...
[0] https://en.wikipedia.org/wiki/IPv6_deployment#China
[1] https://blog.cloudflare.com/ipv6-in-china/
[2] https://stats.labs.apnic.net/ipv6/AS9808
[3] http://www.worldipv6launch.org/apps/ipv6week/measurement/ima...
I speculate this is not true for China. ISPs in China have to deal with country-wide censorship system which has to be upgraded to support IPv6 traffic. This might be the reason why China has a low IPv6 traffic.
Yes. That's what I thought too.
A quick google search gave me this blog.
https://blog.apnic.net/2017/02/07/reliance-jio-boosts-india-...
disclaimer: I know nothing about specifically Indian internet infrastructure.
Probably because they ran into the IPv4 shortage relatively early (address allocations were based on the distribution of nodes in the 1980s or so), and because they didn't get massive internet adoption early enough to need to fall back on carrier-grade NAT like Russia or China.
Probably because they ran into the IPv4 shortage relatively early (address allocations were based on the distribution of nodes in the 1980s or so), and because they didn't get massive internet adoption early enough to need to fall back on carrier-grade NAT like Russia or China.
Obligatory xkcd https://xkcd.com/865/
kolderman(2)
hannob(3)
Heh. The only reason things are the way they are now is that the proponents of IPv6 were some cocky idiots who believed transition systems were not necessary because IPv6 was the best thing since sliced bread and IPv4 was going to implode anyway.
Looks like they've been proven wrong. ISPs are happily using CG-NAT, all services are being adapted to that (moving away from p2p like Skype did) and end users don't care too much. Ouch!
Looks like they've been proven wrong. ISPs are happily using CG-NAT, all services are being adapted to that (moving away from p2p like Skype did) and end users don't care too much. Ouch!
> ISPs are happily using CG-NAT
I wonder how "happily" they are using CG-NAT. NAT is inherently stateful and keeping track of that state becomes more expensive as the amount of hosts behind the NAT is increasing.
Running CG-NAT at scale is complicated and resource-intensive, so I'm totally willing to imagine that it's better long-term value for a carrier to switch to IPv6 than to expand CG-NAT.
I wonder how "happily" they are using CG-NAT. NAT is inherently stateful and keeping track of that state becomes more expensive as the amount of hosts behind the NAT is increasing.
Running CG-NAT at scale is complicated and resource-intensive, so I'm totally willing to imagine that it's better long-term value for a carrier to switch to IPv6 than to expand CG-NAT.
You cannot for now just stop providing the CG-NAT, not when so much of the Internet is still v4 only. V6 deployment will reduce the load on it though.
ISPs don't usually care too much about long-term value.
When most of your core network is IPv4-only, getting some CG-NAT equipment is indeed cheaper than buying a completely new core network.
When most of your core network is IPv4-only, getting some CG-NAT equipment is indeed cheaper than buying a completely new core network.
The cost of maintaining the state tables used to be a concern in the ninties...
Right now, my laptop has 4 open TCP sockets, and my phone has 3.
Even assuming the average user has 50 sockets open, and assuming you are an ISP with 300 million users, that's still only 175 gigabytes of RAM. The total cost is under $1000, or peanuts for what would be the worlds largest ISP.
Right now, my laptop has 4 open TCP sockets, and my phone has 3.
Even assuming the average user has 50 sockets open, and assuming you are an ISP with 300 million users, that's still only 175 gigabytes of RAM. The total cost is under $1000, or peanuts for what would be the worlds largest ISP.
except that for high performance networking, storing stuff in normal RAM is simply not an option if you want to keep an acceptable throughput. (>40gbit). One would need to store NAT state in some sort of TCAM/CAM table.
Guess what, having a 175 gigabyte of (T)CAM is drastically more expensive.
Guess what, having a 175 gigabyte of (T)CAM is drastically more expensive.
v6 has dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... it has pretty much every possible transition method that can work with v4.
You could make a reasonable argument that it has too many of them, even. Where did you get the idea that we didn't think it needed any?
You could make a reasonable argument that it has too many of them, even. Where did you get the idea that we didn't think it needed any?
My websites do not support IPv6. Is there any incentive for me to make them support it?
CGNAT tables can become saturated, making new IPv4 connections flaky while v6 remains reliable. Thus you would improve user experience.
How would the user notice that? I don't have the feeling something is unreliable.
Similar for HN. It also does not support IPv6. From my experience it is in the 99 percentile of websites when it comes to reliability. Aka it works pretty much all the time. Better then almost every other website.
Similar for HN. It also does not support IPv6. From my experience it is in the 99 percentile of websites when it comes to reliability. Aka it works pretty much all the time. Better then almost every other website.
That's your experience, which just means you don't run into saturated CGNATs. For those affected ipv6 sites provide fewer connection drops.
> How would the user notice that?
Initial connections taking multiple TCP syn retries leading to an initial stall or random assets from 3rd party sites or subdomains not being loaded which can break sites in many ways.
> How would the user notice that?
Initial connections taking multiple TCP syn retries leading to an initial stall or random assets from 3rd party sites or subdomains not being loaded which can break sites in many ways.
Amazing how the companies that have the biggest interest in tracking users also are pushing ipv6 the hardest.
IPv6 does not really help with user tracking. IPv6 privacy extensions rotate the suffix your browser uses for outgoing connections on a daily basis. And it's enabled by default on most operating systems.
It was somewhat broken for a while on windows 10, but they fixed that in march.
It was somewhat broken for a while on windows 10, but they fixed that in march.
But shouldn't the rotation take place connection-wise instead of on a daily basis?
If a user browses with a given address and gets identified by one specific agent that shares that information with 3rd parties (e.g. a social network that collects and shares users' IP addresses), every time that happens the then generated new browsing data will have a solid past reference to which it will be added, thanks to that one correct identification.
If a user browses with a given address and gets identified by one specific agent that shares that information with 3rd parties (e.g. a social network that collects and shares users' IP addresses), every time that happens the then generated new browsing data will have a solid past reference to which it will be added, thanks to that one correct identification.
Most ISPs have dynamic IPv4 addresses, but IPv6 removes that necessity. This WILL help tracking.
They might consider them dynamic but in 18 years the only time they ever changed was when I actually switched providers. They were essentially static IP addresses. With one ISP it was the same for 5-6 years.
Depends on your ISP, no? I've been in a few and for most of them I would have a different IP just by rebooting my router.
Im sure it will vary depending on the ISP, but I've just had a different experience. I put a dns record on a domain I had so I could ssh in because the IP never changed for years. But every ISP after dialup has never changed my address after installing. That includes att, charter, Comcast, Comcast again, att and att again, and some regional ISP I can't even remember the name of.
Late to the party but:
Friendly reminder that IPv6 by default uses your mac address as part of your address and hence you are recognizable to any server in the world to track you around.
Friendly reminder that IPv6 by default uses your mac address as part of your address and hence you are recognizable to any server in the world to track you around.
This is no longer the default on Mac and Windows at least: https://superuser.com/questions/243669/how-to-avoid-exposing...
Nice! Thanks for the link. Been some time since my telco years!
Extremely late – this hasn't been the case since Mac OS 10.7 (2010) and Windows XP SP2 (2004).
I didn't know this. Is there an alternative?
From another response: https://superuser.com/questions/243669/how-to-avoid-exposing...
[deleted]
It seems that we in Belgium are somewhat stuck at this rate though. Consumer routers behind ISP modems that only provide IPv4, enterprises not adopting IPv6, mobile networks not adopting IPv6 (all IPv4 only with CGNAT if I'm not mistaken), ...