I wonder when a country is going to overtake Belgium in IPv6 adoption. Belgium has been slightly above 50% IPv6 traffic to Google for quite a while now, thanks to major ISPs switching to native dual-stack setups (and those ISPs being in full control of home networks in general).
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), ...
> 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.
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".
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.
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.
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.
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...
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].
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.
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.
> 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.
> 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 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.)
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.
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.
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?
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.
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.
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 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.
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.
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.
"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.
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.
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.
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...
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.
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.
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".)
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.
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.
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.
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, 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.
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?
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].
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.
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.
Here’s the paper outlining the methodology https://ai.google/research/pubs/pub36240
(I imagine some specifics have changed in the past 8 years but I believe the basic concept is still pretty similar)
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!
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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), ...