GitHub is at the point where it immediately rate limits me if I try to look at a project's commit history without being logged in, as in the first time I even open a single URL to the commit history, I get "Too Many Requests" from GitHub thrown at me. I don't know if my work's antivirus stack is causing GitHub to be suspicious of me, but it's definitely egregious.
It’s not you or your setup. I experience the same behavior. Tried with and without Private Relay, residential and commercial ISPs at different locations, and more to debug it. Same results.
I think GitHub has just gotten so aggressive with their rate limit policies that it’s straight up incompatible with their own product. The charitable interpretation is that they aren’t keeping good track of how many requests each page actually performs in order to calibrate rate limiting.
On the other side of the coin, they also punish people who have slow connections. The acceptable speed for downloading from github on my connection is 90k/sec. No more, no less. Something prevents the rate from being higher (probably Github), and if the rate drops any lower for any length of time, the connection will suddenly abort right in the middle of the download. Since the dumpster fire that is git doesn't support resume, welcome to hell. If I didn't have a fast server elsewhere to git to then zip up and re-download, I'd be screwed.
My theory is that they rate limit that URL aggressively due to AI scrapers. At this point it's faster to just clone the repo and do your searching locally.
The very same thing happen on my residential connection, I can do one search query, then I'm rate limited for 15+ minutes, same if I access any list of commits.
I've considered this, but the company is small enough that the number of people who would be on GitHub at any moment (instead of our internal git forge) can be counted on one hand, and when I'm the first one there in the morning it still rate limits me.
Hm, I've also noticed sites being more aggressive about verifications after I started using LLMs locally. They think I'm a bot (which... fair), even on completely unrelated sites I seem to be getting prompted for human verification much more often.
No, IPv6 as it is supposed to be implemented gives (say) a single server a /64, which is for all intents and purposes an inexhaustible supply of IPs. You could in principle have an IP per site you visit and have plenty left to spare.
So if I wanted to annoy GitHub, I could connect to them without ever using the same IP twice. Their response would have to be banning my /64, or possibly /56.
> No, IPv6 as it is supposed to be implemented gives (say) a single server a /64, which is for all intents and purposes an inexhaustible supply of IPs. You could in principle have an IP per site you visit and have plenty left to spare.
No, as it's supposed to be implemented a single internet-routable /64 is used per *network* and then most devices are expected to assign themselves a single address within that network using SLAAC.
ISPs are then expected to provide each connected *site* with at least a /56 and in some cases a /48 so the site's admins can then split that apart in to /64s for whatever networks they may have running at the site. That said, I'm on AT&T fiber and I am allocated a /60 instead, which IMO is still plenty for a home internet connection because even the most insane homelab setups are rarely going to need more than 16 subnets.
> So if I wanted to annoy GitHub, I could connect to them without ever using the same IP twice. Their response would have to be banning my /64, or possibly /56.
Well yeah, but it's not like it's exactly rocket science to implement any sorts of IP rate limiting or blocking at the subnet level instead of individual IP. For those purposes you can basically assume that a v6 /64 is equivalent to a v4 /32. A /56 is more or less comparable to /25 through /29 block assignments from a normal ISP, and a /48 is comparable to a /24 as the smallest network that can be advertised in the global routing tables.
It is because the IPv6 rollout has not been consistent. Some assign /64 per machine, some assign /64 per data center. Some even go the other way and do a /56 per machine. We've had to build up a list of overrides to do some ranges by /64 and others by /128 because of how they allocate addresses. This creates extra burden on server operators and it's not surprising that some just choose not to deal with it.
What can you do to get a new IPv6 network that is easier than getting a new IPv4?
Stuff like bouncing a modem, getting a new VPS, making a VPN connection I would expect to be pretty similar. And getting a block officially allocated to you is a lot of work.
Why are we pretending that you are checking logs and adding firewall rules manually. Anything worth ddosing is going to have automatic systems that take care of this. If not put an ai agent on it.
Comically IPv6 now has almost all the neat stuff IPX did. There probably is an argument for more datagram centric networking these days as the underlying services are generally much faster and more reliable and there is so much more session tracking going on at higher application layers anyway.
twinax I think is used more like a balanced line with shielding. Twisted pair is preferred because it is cheaper, but for short stuff like SATA the cost difference is so low it might as well be used
I remember removing the IPX route entries from our Cat65 MSFC back in 2006 and from the ATM/Framerelay WAN Equipment. Wasn't very popular with the customers.
I also remember the first IPv6 Workshop on W2k SP3 back in 2002. Not that long ago.
IPv1, IPv2, and IPv3 were very early experimental versions of the Internet Protocol developed in the 1970s during the ARPANET era (the precursor to the modern internet). Has anyone tried to find out if GitHub is reliable on those?
That seems weird given NIST, and the US Government, set a requirement for IPv6 Only back several years ago, and it sort-of became part of the JWCC requirements (It wasn't in the requirements, IIRC, because it came after those were set, but the government wouldn't fully approve use for JWCC if you didn't meet it).
You'd think they'd have sprinted for that feature as fast as they could go.
USG also set a whole bunch of security requirements under FedRAMP that Microsoft can never meet, but they received an ATO anyway because they are so heavily entrenched in government.
Same with Twilio. We have an internal server that does system alerts. We recently moved it to an IPv6 only host, and a few weeks went by and noticed there were no longer receiving alerts.
Turns out we could not connect to Twilio's API which is IPv4 only.
Who? The infrastructure team that did the move didn't even tell anyone. They were decommissioning old servers, and moving the VMs to new hardware. I'm just a lowly developer that had to troubleshoot why SMSes stopped going out.
Observability and alerting is pretty standard devops. Both the dev and infrastructure teams dropped the ball here. But at least as part of remediating this you added alerting to make sure you’d notice when your twillio connection fails in the future, right?
I've been there. Management was fine with the testing but it added too much overhead for nearly no benefit to us.
One more thing to troubleshoot at 3 am, one more thing to teach to a disinterested tier 1 support team, one more thing for Chrome to be weird about, hundreds more rules to manage in a hostile load balancer, logging tools that don't understand ipv6.
Turned it off. End customer asked why the site got a little slower (CGN) and when we can turn ipv6 back on. As far as I know it's still on the backlog.
One of the big challenges with IPv6 remains that many of the knows-just-enough-about-networking people, like support staff, often never received any IPv6 training (or, for that matter, even enough IPv4 training that they don't need to Google things that come up in real life). Another is that the weird, awful, everyone-hostile corporate "solutions" often break IPv6 in stupid ways (like load balancers and logging tools being unable to cope with minor changes and requiring a full configuration rework).
Things have definitely gotten better over time, though. The massive 90s style corporate networks will probably never transition, but smaller and more modern companies don't have that issue.
Apple mandating that apps are IPv6 compatible and various government legislation forcing companies to make their shitty middleware IPv6-compatible has improved things quite a bit so far. As uptake keeps rising, the need for technologies like STUN and TURN will slowly start decreasing, and as a result more and more people will end up in "untested" situations where not having IPv6 and falling back to legacy paths starts becoming a problem.
A networking dude (he clutched his smartphone all the time) typed "spedtes" in my browser and was deeply confused when the server wasn't found. He tried several times more with slightly different spelling to the same effect, he literally couldn't even what went wrong.
Here's an example of a potential security hole caused by lack of ipv6 knowledge:
I've been setting up Snapcast (open-source multi-room audio), and needed to move the server to a different machine. While I was setting up the new system, I told it to only bind to localhost. Somehow this only affects the ipv4 networking stack, as some of my clients started automatically connecting to the new server even before I had finished all my testing.
Turns out that it was advertising some kind of ipv6 link-local address that showed up in autodiscovery. In my case there wasn't any harm, but this type of thing could very easily result in a major security vulnerability.
I don't see how this generalizes into a security hole caused be lack of IPv6 knowledge. It just sounds like a random bug in Snapcast (great program!). If a user configures a program to only bind to loopback, but the program binds to other interfaces as well, that's a bug in the program.
There are sure to be dozens or hundreds of vulnerabilities like this, that's what I'm saying. I'm not even sure it's a bug in snapcast - very possible I configured it wrong without realizing.
Without knowing exactly what happened here, it could be hundreds, dozens, or zero other such vulnerabilities.
The usual convention for configuring listening interfaces usually involves listing IP addresses or interface names. There's very little room for misconfiguration here, although it's possible. More likely to be a bug in Snapcast (it's almost certainly not an issue in the Linux kernel).
Moreover, this general problem (i.e. configuring listening interfaces) is not/should not be different between IPv4 and IPv6. So introducing IPv6 should not™ incur any additional risk at this level.
But as said, it's hard to get more concrete without knowing exactly what happened in your case.
Localhost doesn't appear on autodiscovery. Whatever you ran into had nothing to do with IPv6, but rather with your application not binding to the address you were telling it to bind to. On IPv6, localhost binds to ::1, not anything reachable by any other address. Furthermore, whatever you set up automatically seems to have added itself to your server's firewall, which is equally troubling.
The address my clients were finding automatically was a link-local address (fe80...). Can't say exactly what happened but it was very surprising since I didn't even know these addresses existed.
I'm sure it's totally my fault but that's the point: folks who know how ipv4 works may have huge blind spots for ipv6.
It also just takes actual policy will. Somebody has to actually say "No" when the supplier who promised an IPv6 product says afterwards actually they meant IPv6 "ready" and they should have put an asterisk because really only the next version will be "ready", and er, so the product they've delivered doesn't actually work with IPv6 but that's fine right?
"No". Not every human is psychologically prepared to do that. They want to acquiesce, to go along to get along, you need somebody to be firm. "No".
I have found that it is incredibly satisfying to whip out the “no” card.
I have also found that an uncomfortable number of people do not consider it appropriate in any way shape or form. Even when it’s ultimately your call and no one else’s.
Folks don’t really like waves. They like looking at them from the shore, but freak out when it’s their turn to hang 10
Suppliers doing that kind of trick is what really killed GOSIP, and why the new v6 mandates in USGOV do not allow waivers for vendors, only for individual specific use cases
From my time there, this is for the internal prod network. Corporate networking was dual stack (which was pretty useful because it was common for v4 or v6 to break, but usually not at the same time)
Our university has bad problems with ipv4. Every few days you'll notice some websites being unreachable, including github. Although with their uptime recently, you never know who's to blame...
github.io does have an IPv6 address. Indeed, one workaround for getting rate limited when using a carrier NAT with github.com is to have a github.io page and pull data from github.io instead of github.com.
Edit: About a decade ago, all of my hosting had full IPv6 support, and I tried to move over to IPv6. However, there was an issue with Letsencrypt certs not validating over IPv6, so I made my web pages IPv4 only. Recently, I gave IPv6 a go again, and the cert issue has been fixed, so now my webpages finally have both IPv4 and IPv6 addresses.
> Do providers like NextDNS or RethinkDNS allow these sorts of overrides
Not on the resolver, but on the Android client (Rethink DNS + Firewall) we do (if enabled) manipulate DNS answers to implement an opportunistic 464xlat (over Kasper Dupont's public relays [0]).
Perhaps a little tin foil hatty and definitely not the only reason but Microsoft owns Github and also makes a boatload of money off of Azure. Incumbent cloud providers like Azure have a major advantage in terms of having plenty of IPv4 addressing available whereas a new entrant to that market would have to buy or lease that space at a premium. Thus, these companies have an incentive to keep IPv4 a necessity.
IPv4 is going to be a necessity for many many decades no matter what Microsoft do. Even when IPv6 is at 99%, people aren't going to want 1 in every 100 people to not be able to access their site at all. It'll need to be like 99.9% before we start seeing serious IPv6-only services.
I don't know what the percentage would be, but we do have some historical precedent that could give us a clue.
Best one I can think of is when bigger websites started actually dropping SSLv3 and TLSv1.0 (and later TLSv1.1) support, cutting off older browsers and operating systems. Google and Amazon still support TLSv1.0, but plenty of others (including Microsoft) have dropped 1.0 and 1.1. HN itself doesn't accept 1.1 anymore either.
Then there's browser support. Lots of websites - big and small - cut off support for Internet Explorer 6 when it was somewhere below 5% marketshare because the juice was no longer worth the squeeze. Of course, few of those actually fully cut off the ability to browse the (now broken) website fully but it's a datapoint suggesting trade-offs can and will be made for this sort of thing. Or to put it in the present: a significant amount of webapps don't support Firefox (3% market share) to the extent their product is completely unusable in it.
Sure, but the implementation in the public clouds is totally backwards.
What they should have done is have their core network default to IPv6 with IPv4 an optional add-on for things like public IP addresses, CDN endpoints, edge routers, VPNs, etc...
Instead, their core networks are IPv4 only for the most part with IPv6 a distant afterthought.
Outdated beliefs probably. When I talk about v6 support in our b2b saas, PM laughs and says nobody uses that shit. Big tech are massive laggards on this funnily enough.
Definitely not for the biggest ones. Google and Meta have so many machines in their data centers that IPv6 addressing becomes a technical necessity due to the risk of exhausting the RFC 1918 address space. Naturally, they were early adopters of IPv6.
Yeah, I can't imagine managing fleets like that with only v4. Our network config is so convoluted with gateways and NATs everywhere, paying AWS through the nose for it all, when it could all be so much simpler.
IPv6 is very difficult to implement and enforce reliable rate limits on anonymous traffic. This is something we've struggled a lot with - there is no consistent implementation or standard when it comes to assigning of IPv6 addresses. sometimes a machine gets a full /64, other times a whole data center uses a full /64. So then we need to try and build knowledge of what level to block based on which IP range and for some it's just not worth the hassle.
Well, even if there was a standard, that's still not a guarantee that the other side of the /64 would be following it. It's correct for you to rate-limit the whole /64.
Anonymous rate limits for us are skewed towards preventing abusive behavior. Most users do not have a problem, even there is a CGNAT on IPv4.
For IPv6, if we block on /128 and a single machine gets /64, a malicious user has near infinite IPs.
In the case of Linode and others that do /64 for a whole data center, it's easy to rate limit the whole thing.
Wrong assumption or not, it is an issue that is made worse by IPv6
I don't doubt your experience, but I wouldn't expect it to continue. I don't think Tuna-Fish is correct that "most" of the IPv4 world is behind CGNAT, but that does appear to be the trend. You can't even assume hosting providers give their subscribers their own IPv4 addresses anymore. On the other hand, there's a chance providers like Linode will eventually wise up and start giving subscribers their own /64 - there are certainly enough IPv6 addresses available for that, unlike with IPv4.
> I don't think Tuna-Fish is correct that "most" of the IPv4 world is behind CGNAT
~60%+ of internet traffic is mobile, which is ~100% behind CGNAT.
On desktop, only ~20% of US and European web traffic uses CGNAT, but in China that number is ~80%, in India ~70% and varies among African countries but is typically well over 70%, with it being essentially universal in some countries.
Overall, something a bit over 80% of all ipv4 traffic worldwide currently uses CGNAT. It's just distributed very unevenly, with US and European consumers enjoying high IP allocations for historical reasons, and the rest of the world making do with what they have.
Since mmbleh mentioned Linode I'm guessing they're more concerned with traffic from servers, where CGNAT is uncommon. But even that may be changing - https://blog.exe.dev/ssh-host-header
Yeah, absolutely no expectations for the future. My point was more that while there may be clear benefits for users, IPv6 presents real problems for service operators with no clear solutions in sight.
Given that GitHub also offers free services for anonymous users, I can imagine they face similar problems. The easiest move is simply to just not bother, and I can't blame them for it.
It could fit best practices if your datacenter has one tenant and they want to put the entire thing on a single subnet? In general I would expect a datacenter to get something like a /48 minimum. Even home connections are supposed to get more than /64 allocated.
And Linode's default setup only gives each server a single /128. That's not how it's supposed to work. But you can request /64 or /56.
If the OS uses SLAAC by default, then it will just work, but SLAAC is for humans and makes less sense for web servers (yet can make sense for vpn servers). For web servers /128 is more meaningful.
I have not had a deal with this, but if I was going to, I would start at the /64 and move up by nibble (4-bit) boundaries: /64, /60, /56, /52, /48.
/56 is often recommended as the minimum as for a (residential) customer. /48 is considered a "site" address prefix, and is the smallest allocation that can be advertised in BGP:
I'm not sure if I'm misreading you, but a /48 would never be an entire country's v6 allocation.
If we're talking home networks, you can reliably expect a /48 to a) not be announced in BGP itself, and b) cover one to a few hundred users of one ISP. (The containing /32 or similar will be announced.) A business might structure its network so that one of its /48s corresponds to a country, but in that case the /48 would be covering just that business, which would be a sensible unit for reputation tracking.
Reputation unit is /64 block, so if you want to see a 100 people ISP as one reputation unit, it should get a /64 block. But AFAIK today in practice reputation unit is a country.
I mean, given how the site performs on average I don't think they've optimized so much that the extra cpu cycles of ANDing with the fixed constant of 2^64-1 and then looking up or hashing a 16 byte integer - whatever they do - rather than a 4 byte one would increase the load significantly. Let's be pessimistic and say it's 20 extra cpu cycles, that's not gonna be much of a problem if their load balancers were made in the past 20 years.
IPv6 rollout is a lot of operational work that ends with next to no immediate quantifiable benefit. So I’ll never be prioritized in a cost-cutting environment.
I mean, all your numbering woes vanished, so, that's probably an immediate quantifiable benefit unless you're so tiny you never needed any renumbering effort, in which case your "operational work" to deploy IPv6 was probably zero.
The irony of this is that pretty much all they'd have to do to enable IPv6 support is to use Azure Front Door as their CDN. Or... use any other CDN, they pretty much all default to providing IPv6!
> IPv6 doesn't make it easy to allocate subnets to every device on a LAN; instead, subnets might be delegated to your local router, and then only individual addresses allocated to each device. If one of those devices then wants to route traffic on behalf of other devices (for example, to a sub-subnet behind a router, where the upstream router doesn't cooperate), it will need to use NAT. For example, this is how Tailscale exit nodes work, even with IPv6.
This is quite wrong, there'd DHCPv6-PD (prefix delegation) specifically designed to do this. Even more interestingly, it has recently been made part of IETF CPE requirements (RFC 9818 update to RFC 7084, July 2025).
That was excellent, thanks for recommending it. I particularly liked how it's a pretty factual FAQ, not particularly cheerleading for IPv6 nor saying "IPv6 is a failure, give up on it".
interesting read, pretty depressing take if you're pro IPV6. I think their guess that IPV6 has low value-add when considered as part of a hybrid environment is probably one of the better explanations I've heard for poor uptake.
"IPv6 is the next generation of the Internet Protocol (IP), the successor to IPv4."
This is a misconception. It is not the successor to IPv4, it is an alternative. Maybe the alternative is so good it will eventually make the older extinct, but it does not look like that
Regardless of whatever other things may be better or worse about ipv6, it's still a reality that as we continue connecting more and more devices to the internet eventually ipv4 addresses will become so scarce and valuable that a not-insignificant minority of residential customers will be behind such aggressive CGNAT that the internet will become nearly unusable unless a majority of the services they are using support ipv6.
I agree with you. While I can see some benefits to v6 on the internet, I find v4 to be miles easier and cleaner to work with in a LAN setup. Unfortunately though v6 oversteps on LAN features and makes bridging v4 and v6 way uglier than it should.
It has barely hit 50% and it's already plateauing. This adoption rate is ridiculous despite basically all network interfaces supporting it. I thought I would see IPv6 take over in my lifetime as the default for platforms to build on but I can see I was wrong. Enterprise and commercial companies are literally going to hold back internet progress around 60 to 75 years because it's in their best interest to ensure users can't host services without them. Maybe even 75 years might be too optimistic? They are literally going to do everything in their power to avoid the transition, either being dragged out kicking and screaming or throwing their hands up and saying they can't support IPv6 because it costs too much.
Try going IPv6-only by disabling IPv4 on your computer as a test and notice that almost nothing works except Google. End users shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs doing that to prepare for the transition.
Also, notice how Android and iOS don't support turning off IPv4.
Nearly all ISPs these days are deploying IPv6 for their mobile networks and core service networks, especially in less developed markets^1. The reason is simple, a cost justification. What doesn't exist is a cost justification for Enterprises to deploy IPv6, and for ISPs to deploy Residential / Corporate Internet IPv6.
IMO with the right market conditions, IPv6 could spread really fast within 6-24 months. For example, most cloud providers are now charging for IPv4 addresses when IPv6 is free. Small changes like that push in the right direction.
I find the whole OVH web control panel atrocious. It's so buggy I couldn't even have my account deleted, not even after contacting their customer support (they just told me to fix it myself using their APIs...).
I don't even know why clouds offer public IP addresses. In my opinion all clouds should only have a gateway that routes via host header for millions of customers. IPv4 should be a special priv for special situations at a higher price. Then these clouds could own maybe 20 IPs total instead of millions.
> In my opinion all clouds should only have a gateway that routes via host header for millions of customers.
This is incompatible with TCP/IP networking. In TCP connections, (sender_address, sender_port, receiver_address, receiver_port) is a unique combination. Those numbers together uniquely identify the sender talking to the receiver. For a public webserver:
* sender_address is the client machine's IP address
* sender_port is a random number from 0..65535 (not quite, but let's pretend)
* receiver_address is the webserver's IP address
* receiver_port is 443
That means it'd be impossible for one client IP to be connected to one server IP more than 65535 times. Sounds like a lot, right?
* sender_address is the outbound NAT at an office with 10,000 employees
Now each user can have at most 6.5 connections on average to the same webserver. That's probably not an issue, as long as the site isn't a major news org and nothing critical is happening. Now given your scheme:
* receiver_address is the gateway shared by 10000 websites
Now each user can have at most 6.5 connections to all of those 10000 websites combined, at once, total, period. Or put another way, 100,000,000 client/website combos would have to fit into the same 65535 possible sender_ports. Hope you don't plan on checking your webmail and buying airline tickets at the same time.
This is actually a good point. I guess 20 IPs per cloud infra company is probably too few. But maybe these cloud companies can have 20k IPs instead of 2 million?
Imagine if one day someone came up with a "better" way to chew food, but you had to learn how to do a super complex jaw movement and it wouldn't work in restaurants. It has no obvious benefit to you. The only motivation is that a small group of obsessively passionate (but not in a good way) people say at some unknown point in the future food won't be edible anymore.
IPv6 just tried to do too much so it failed at everything. Putting letters in IP addresses made it near impossible to remember what your network settings were supposed to be.
It is nothing short of a miracle that devices can even get IPv6 addresses. SLAAC was supposed to replace DHCP, but it couldn't provide DNS server addresses. DHCPv6 was introduced to replace SLAAC, but this time they forgot to add a way to communicate a default route. This lead to Cisco, Microsoft, and Google all taking completely different approaches, and the IETF helpfully blocking any efforts at cross vendor standardization because of v6 zealots.
Meanwhile, everybody else is using a plastic skull that they carry around with them to pre-chew the inedible food, which is the majority of the food you can get these days.
"It's not inedible," they say. "Just let me get my skull out."
> IPv6 just tried to do too much so it failed at everything. Putting letters in IP addresses made it near impossible to remember what your network settings were supposed to be.
People said the same sort of thing about v4: that it was hard to configure because you needed to know four separate addresses (IP, netmask, default route AND the DNS server) and if you mix up any of these it doesn't work.
As it turns out, in both cases it's just a lack of familiarity, not actual difficulty. The super complex jaw movement is just a regular bite, but you puff your cheeks out a bit. Or er, something.
> This lead to Cisco, Microsoft, and Google all taking completely different approaches [...] but this time they forgot to add a way to communicate a default route
"There should only be one way to do things... wait, no, not like that."
Apple/iOS is probably one of the biggest individual drivers of IPv6 adoption. They've been requiring that iOS apps work on IPv6-only networks for close to 10 years now
And the higher level libraries mostly do it for you, too, even if you directly specify IPv4 addresses in your code (due to NAT64 [1]). I think it only even requires special work from you as a developer if you're using low-level or non-standard libraries.
The problematic low-level libraries are standard, and effectively impossible to fully deprecate since they're decades old and part of the socket API.
I think currently Apple still helps you with these via "bump in the stack" (i.e. they can translate internal v4 structures and addresses into NAT64-prefixed v6 at the kernel level), but they probably don't want to commit to doing that forever.
I’m guessing the app works but their prod servers don’t? If they can point the app during review at a “self hosted” GitHub Enterprise server on a test domain with AAAA that would pass the requirement as stated by gp , without requiring GitHub.com actually support ipv6.
The prod servers work. The app does a DNS lookup, receives something like 64:ff9b::140.82.112.5 and 140.82.112.5 from the ISP's DNS servers, and then connects to 64:ff9b::140.82.112.5. Some part of the ISP network translates the connection into a v4 connection to 140.82.112.5.
The requirement is simply that the app does AAAA queries, and that it attempts to connect to them if they exist. It doesn't matter whether the server does v6 natively or if the ISP is covering for a v4-only server via backwards compatibility. (Native v6 will probably perform better, but any site that wants to give up that advantage is free to do so.)
That’s DNS64, which is pretty annoying in practice. (For one thing, you can’t use your own DNS server anymore, but more importantly, anything using v4 literals will 100% break.)
What’s nicer is 464XLAT, or more generally NAT64 prefix announcements. Then your local OS can just synthesize NAT64 addresses from v4 literals, either at the socket library or kernel networking (via “bump in the stack” translation) layer.
> It has barely hit 50% and it's already plateauing.
Is it plateauing? From the chart it doesn't look that way at all to me.
You could say it's flat between August 2025 and now, but it also was from Jun 2024-Feb 2025, or August 2023-March 2024. There's just a lot of noise to it -- lots of short plateaus or even dips followed by lots of sudden jumps. Indeed, it seems to have a bit of a yearly cycle to it, suggesting we're at the inflection point of another jump upwards.
So it still seems to be growing strongly to me. The rate of growth has slowed maybe the tiniest bit 2024-2026 compared 2018-2023, but I don't see it anywhere close to plateauing yet.
> It has barely hit 50% and it's already plateauing. This adoption rate is ridiculous despite basically all network interfaces supporting it
It's fine. IPv4 and IPv6 can be used at the same time. There's no hurry. Network interfaces support anything as long as both sides agree (nothing stopping you from building your own IPX network over MPLS).
People can move to IPv6 when the IPv4-as-real-estate speculators get out of control, and if IPv6 prevents IPv4 rental prices from going haywire, then it's served a useful purpose.
I saw a news article that said something about India considering moving to IPv6-only? That's going to be interesting if the rest of the world moves to IPv6 and the U.S. doesn't.
> End users shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs doing that to prepare for the transition.
Exactly. To this point I went to a Comcast store to cancel my internet and the person asked me if I meant I wanted to cancel my “Wi-Fi”. I was very confused for a couple seconds.
v6 adoption is often an all or nothing, because if you run both stacks, you have to ensure they are consistent. While you can reasonably do it on your home LAN, doing it across an entire infrastructure is the worst.
Now you have to make sure all your subnets, routing, VLANs, firewall rules, etc work exactly the same in two protocols that have very little in common.
It is the equivalent of shipping two programs in different languages and maintaining exact feature parity between both at all times.
v4 was built around the idea of multiple free standing networks linked by gateways. v6 was built around the idea of a universal network.
I dont care about what your LAN adress space look like when I'm in my LAN, because we are not in the same v4 network. I am sovereign in my network.
With v6, everyone is effectively in the same network. I have to ask my ISP for a prefix that he will rent me for money even for my LAN. If I want some freedom from said ISP prefix, I am mercifully granted the honor of managing ULA/NAT66 (granted I paid for a fancy router).
Also if I want any kind of privacy, I will have to manage privacy extensions and the great invention of having to use automatically generated, dynamically routed, essentially multiple random IPs per interface. How lucky am I to use such a great new technology.
Seriously v6 was created by nerds in a lab with no practical experience of what people wanted.
> v4 was built around the idea of multiple free standing networks linked by gateways
It was absolutely not. This is why early companies like Apple and Ford got massive IP allocations - each computer was expected to have a unique IP address.
NAT didn't exist until 14 years after IPv4 was created, in response to the shortage of IPv4 addresses, and in the RFC it is described as a "short-term solution", very clearly stated that his not how the internet is designed to work and it should only be used as a stopgap until we get longer addresses.
v4 and v6 were build around the exact same use cases.
> With v6, everyone is effectively in the same network.
Just like IPv4.
> I have to ask my ISP for a prefix that he will rent me for money even for my LAN.
Just like IPv4, if you need a static address.
> If I want some freedom from said ISP prefix, I am mercifully granted the honor of managing ULA/NAT66 (granted I paid for a fancy router).
Compared with IPv4, where if you want some freedom from said ISP subnet, you are mercifully granted the honor of managing RFC-1918 addresses/NAT (granted you paid for a router that doesn't screw it up).
> Also if I want any kind of privacy, I will have to manage privacy extensions
...which are enabled by default nearly universally
> and the great invention of having to use automatically generated, dynamically routed, essentially multiple random IPs per interface.
Make up your mind. Are rotating, privacy-preserving addresses good or bad? The way it works in real life, not in the strawman version, is that you (automatically!) use the random addresses for outgoing connections and the fixed addresses for incoming.
This is exactly why I decided not to enable IPv6 on my colo. When money is involved, the benefits of IPv6 simply do not outweigh the risk, in my estimation. If my side gig eventually pays enough to pay a contractor to handle networking then sure, that'll be one of the first tasks. But when it's just me managing the entire stack, my number one priority is security, and for now that means keeping things simple as possible.
I switched my home ISP from cable (which supported IPv6) to fiber (which doesn't) and I've had a nagging disappointment ever since. But I guess consumers aren't really demanding it enough.
I think we'll hit a tipping point soon, just like with Python3 - for years and years it seemed almost stalled, then it became easier to start with python3 than python2 and suddenly everyone migrated.
> End users shouldn't need to set up 6to4 tunneling. It should be ISPs doing that to prepare for the transition.
Which is what ISP are doing with 464XLAT deployments. IPv6-mostly networking and IPv4-as-a-service are things that are happening in real world right now.
Yeah in Japan my ISP even lets me choose which IPv4 provider I want to use, as the fiber network is IPv6-native and IPv4 is "just another service" like IPTV.
IPv4 is provided using DS-Lite or MAP-E depending on the provider.
I'm using OpenWRT and paid for a static IP so I had to manually configure all the details for the MAP-E tunnel in OpenWRT myself, I think typically the routers sold to consumers pick up the configuration automatically somehow.
Which provider are you using? I'm curious about this since there are not many OpenWrt guides for getting connected in Japan. Is your config similar to this write-up? https://github.com/fakemanhk/openwrt-jp-ipoe
I didn't need to do any configuration for DS-Lite or MAP-E, as DHCPv6 with a configured prefix got IPv6 working, although DNS is still broken when turning off IPv4 entirely.
edit: looking this all up again to refresh my memory, it looks like with my static IP the provider switches from using their default MAP-E to using RFC2473 directly instead, the configuration matches "IPIP" in this guide https://qiita.com/kouhei-ioroi/items/cf0c6228c5c1faef415a
I'm re-learning this right now since I kind of just set it and forgot it 2 years ago but while my provider typically uses MAP-E it looks like when you use a static IP it switches to using RFC2473 (IPIP6) directly without the extra port mapping that MAP-E adds ontop
> It has barely hit 50% and it's already plateauing.
That makes sense. The majority of IPv6 deployment is mobile.
The next wave of adoption requires ISPs start offering residential IPv6. Once this happens, router manufacturers will innovate around the IPv6 offering as a differentiator, making it easy to deploy by end-users. IPv6 wifi APs will then become ubiqutious and so forth across other services. Has to start with ISPs.
Mine does and it works so well that I actually have to turn it off when working from home as a bunch of the third party servers at work doesn't have any support for it.
That sounds more like broken support then. Not having any support at all (i.e. A records or v4 literals only) should just send you to whatever v4 transition technology your ISP offers, no?
My German ISP supports it now, which was the limiting factor for me, and a new VPS I just bought also does, so finally I was able to create my first personal AAAA record. I am hoping that we're seeing a tipping point. Again.
Is there a reason why adoption has been so abysmally slow? Like surely all the big players have updated their networking equipment by now, and surely every piece of enterprise-grade kit sold in the last 20 years has supported v6.
The only arguments I've ever heard against ipv6 that made any sense are that:
1: it's hard to remember addresses, which is mayyyyybe valid for homelab enthusiast types, but for medium scale and up you ought to have a service that hands out per-machine hostnames, so the v6 address becomes merely an implementation detail that you can more or less ignore unless you're grepping logs. I have this on my home network with a whopping 15 devices, and it's easy.
and 2: with v6 you can't rely on NAT as an ersatz firewall because suddenly your printer that used to be fat dumb and happy listening on 192.168.1.42 is now accidentally globally-routable and North Korean haxors are printing black and white Kim Il Sung propaganda in your home office and using up all your toner. And while this example was clearly in jest there's a nugget of truth that if your IOT devices don't have globally-routable addresses they're a bit harder to attack, even though NAT isn't a substitute for a proper firewall.
But both of these are really only valid for DIY homelab enthusiast types. I honestly have no idea why other people resist ipv6.
The big reason is that domestic ISPs don't want to switch (not just in the US, but everywhere really.)
Data centers and most physical devices made the jump pretty early (I don't recall a time where the VPS providers I used didn't allow for IPv6 and every device I've used has allowed IPv6 in the last 2 decades besides some retro handhelds), but domestic ISPs have been lagging behind. Mobile networks are switching en masse because of them just running into internal limits of IPv4.
Domestic ISPs don't have that pressure; unlike mobile networks (where 1 connection needing an IP = 1 device), they have an extra layer in place (1 connection needing an IP = 1 router and intranet), which significantly reduces that pressure.
The lifespan of domestic ISP provided hardware is also completely unbound by anything resembling a security patch cycle, cost amortization or value depreciation. If an ISP supplies a device, unless it fundamentally breaks to a point where it quite literally doesn't work anymore (basically hardware failure), it's going to be in place forever. It took over 10 years to kill WEP in favor of WPA on consumer grade hardware. To support IPv6, domestic ISP providers need to do a mass product recall for all their ancient tech and they don't want to do that, because there's no real pressure to do it.
IPv6 exists concurrently with IPv4, so it's easier for ISPs to make anyone wanting to host things pay extra for an IPv4 address (externalizing an ever increasing cost on sysadmins as the IP space runs out of addresses) rather than upgrade the underlying tech. The internet default for user facing stuff is still IPv4, not IPv6.
If you want to force IPv6 adoption, major sites basically need to stop routing over IPv4. Let's say Google becomes inaccessible over IPv4 - I guarantee you that within a year, ISPs will suddenly see a much greater shift towards IPv6.
It's frustrating that even brand new Unifi devices that claim to support IPv6 are actually pretty broken when you try to use it. So 10 years from right now even, unless they can software patch it upwards.
Prefix delegation is completely broken for example
I had to switch to OpenWRT on my Ubiquity gear to have something that works (which on the other hand is also easier to configure, so I'm probably going to stay there).
Except that is completely wrong. Consumer/residential networks have significantly higher ipv6 adoption rates that corporate/enterprise networks. That is why you see such clear patterns (weekend vs weekday) in the adoption graphs.
Sure, the data plane supports it - but what about the management plane?
I wouldn't be surprised if ISPs did all the management tasks through a 30-year-old homebrew pile of technical debt, with lots of things relying on basic assumptions like "every connection has exactly one ip address, which is 32 bits long".
Porting all of that to support ipv6 can easily be a multi-year project.
> Porting all of that to support ipv6 can easily be a multi-year project.
FWIW, as someone who has done exactly this in a megacorp (sloshing through homebrew technical debt with 32-bit assumptions baked in), the initial wave to get the most important systems working was measured in person-months. The long tail was a slog, of course, but it's not an all-or-nothing proposition.
Comcast actually implemented IPv6 10-15 years ago so that they could unify the management of all of their cable modems. Prior to that they had many regional networks using with modems assigned management IPs in overlapping private IPv4 ranges.
This is true, I worked for an old ISP/mobile carrier that started in the 80s about 10-15 years ago. They had basically any system you could think of still running, from decently modern vmware with windows and linux to hp-ux, openvms, sunos, AIX, etc. Could walk around and see hardware 30 years old still going, I think one console router had an uptime of 14 years or so. One time I opened a cabinet and found a pentium 1 desktop pc on the floor still running and connected, served some webpage. The old SMSC from the 80s on DEC hardware was still in its racks though not operational, they didn't need the space as the room couldn't provide enough power or cooling for more than a few modern racks. The planning program for fiber, transmission, racks, etc, required such an old java that new security bugs didn't apply to it, and looked and worked like an old mainframe program.
The core team supported ipv6 for a long time, but its rather easy to do that part. The hard part is the customer edge and CPE and the stack to manage it, it may have a lifetime of 2 decades.
No idea, but people do it. Every time this comes up on HN there are dozens of comments about how they like hiding their devices behind a NAT, for security
Just because people regularly bring up a non sequitur doesn't mean there actually is a problem.
"I have a device acting as both a NAT and a stateful firewall, why are you making me switch to IPv6 and in the process drop both the NAT and the stateful firewall?" is a non sequitur.
I think we're talking about two different things, or maybe I just don't understand your reply.
What I'm saying is this: There exist people in the hobbyist space who believe that when their devices only have private IPv4 addresses such as 192.168.0.0/16 that this meaningfully increases their network security, and that if their raspberry pi has a globally-routable v6 address that this weakens their network security, even though this is bogus because NAT is orthogonal to network security considerations, and that this belief contributes to IPv6 hesitancy.
Has it been abysmally slow? What's the par time for migrating millions of independent networks, managed by as many independent uncoordinated administrators, to a new layer 3 protocol?
We've never done this before at this scale. Maybe this is just how long it takes?
I set up NAT66 recently with DHCPv6. The IPv4 and IPv6 addresses are practically the same, except IPv6 has a prefix and a double colon as the last separator.
This really should be how SOHO routers do IPv6 out of the box.
Most people don't want 1:1 addressing for their entire home or office.
Are you using ULA prefix for the nat66/dhcp6, are you also allowing GUA address assignment via slaac?
Im wondering how it works out with source-selection
How so? The same working group published e.g. https://www.rfc-editor.org/rfc/rfc1933, and it's hard to see how v6 could have been designed for backwards compatibility in ways that it wasn't already.
I've asked lots of people to describe a more backwards-compatible design, and generally the best they can manage is to copy the way v6 does things, ending up with the same problems v6 has. This has happened so often that the only reasonable conclusion is that it can't really be done any better than it was.
fd::1 is somewhere in the reserved ::/8 space where various stuff like old ipv4 mapped addresses and localhost reside. What you probably mean is something like fd00::1, but that is something you shouldn't use, because 'fd00::/8' is a probabilistically unique local address (ULA) block. You are supposed to create a /48 net by appending 40 random bits to fd00::/8. Of course, if your fair dice roll lands on all zeroes, and you are ok with probable collisions in case of a network merge, you are fine ;)
In home networks, the idea of merging with someone else's network is... most certainly not worth worrying about. Maybe you marry someone or become roommates with someone who also picked fd00::/8? And you still want two separate subnets? Other than that I don't see a scenario where it matters.
Granted, if you're doing this in a corporate setting (where merging with someone else's address space is a lot more realistic), then yes definitely pick a random 40 bits. But at home? Who cares. Same as using 192.168.1.0/24 instead of a random 10.0.0.0/24 subnet... it's not worth worrying about.
I'm having my own and my girlfriend's router (in different flats) connect to each other with a wireguard tunnel, so I can print on her printer. Non-colliding addresses make this a lot easier.
Those are designed to have static asymmetrical bandwidth though, *dm split gives ISP side more of possible shared bandwidth. Wifi bandwidth is shared and dynamic so client can use all of it.
IPv6 is a recursive WTF. It might _look_ like a conservative expansion of IPv4, but it's really not. A lot of operational experience and practices from IPv4 don't apply to IPv6.
For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
In IPv6 each host has multiple global addresses. But if your global connection goes down, these addresses are supposed to be withdrawn. So your hosts can end up with _no_ addresses. ULA was invented to solve this, but the source selection rules are STILL being debated: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda...
Then there's DHCP. With IPv4 the almost-universal DHCP serves as an easy way to do network inspection. With IPv6 there's literally _nothing_ similar. Stateful DHCPv6 is not supported on Android (because its engineers are hell-bent on preventing IPv6). And even when it's supported, the protocol doesn't require clients to identify themselves with a human-readable hostname.
Then there's IP fragmentation and PMTU that are a burning trash fire. Or the IPv6 extension headers. Or....
In short, there are VERY good reasons why IPv6 has been floundering.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
No, that’s not the IPv4 design. That’s an incredibly ugly hack to cope with IPv4 address shortage. It was never meant to work this way. IPv6 fixes this to again work like the original, simpler design, without ”local” addresses or NAT.
> In IPv6 each host has multiple global addresses.
Not necessarily. You can quite easily give each host one, and only one, static IPv6 address, just like with old-style IPv4.
The problem here is the IPv6 design. It has multiple ways of configuration, and ALL of them suck.
Manual address input is clumsy because of IPv6 address length, stateless RA is limited and doesn't allow network introspection, stateless DHCP is pointless, stateful DHCP is not supported by the most widely deployed OS. There's also prefix delegation that needs stateful DHCP.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
This is a troll right? NAT is a lot of things, but "simple and clean" is definitely not one of them. It causes complications at every step of the process.
Pure IPv6 is so much cleaner.
I will say that DHCP6 is probably misnamed. It does not fill the same niche has IPv4 DHCP, and this causes a lot of confusion with people who are new to IPv6. It should probably be called DPDP (Dynamic Prefix Distribution Protocol) or something like that. It's for routers not hosts.
In theory you should be using anycast DNS to find local hostnames, but in practice the tooling around this is somewhat underbaked.
> This is a troll right? NAT is a lot of things, but "simple and clean" is definitely not one of them. It causes complications at every step of the process.
This is something that can be done with consumer-grade routers in _minutes_ with zero configuration from endpoints apart from the usual WiFi password.
NAT is a _superior_ design in practice. It can be chained transparently, it moves all the stateful routing complexity to the border router, it enforces network isolation. And most importantly, IT ACTUALLY WORKS.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
I assume you mean "interface", not "host". Because it's absolutely not true that a host can only have one "local net address".
EDIT: a brief Google also confirms that a single interface isn't restricted to one address either: sudo ip address add <ip-address>/<prefix-length> dev <interface>
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
If you think NAT is "simple and clean", you may wish to investigate STUN/TURN/ICE. An entire stack of protocols (and accompanying infrastructure) had to be invented to deal with NAT.
> Then there's IP fragmentation and PMTU that are a burning trash fire.
It's not significantly worse on v6 compared to v4. Yes, in theory, you can send v4 packets without DF and helpful routers will fragment for you. In practice, nobody wants that: end points don't like reassembling and may drop fragments; routers have limited cpu budget off the fast path and segment too big is off the fast path, so too big may be dropped rather than be fragmented and with DF, an ICMP may not always be sent, and some routers are configured in ways where they can't ever send an ICMP.
PMTUd blackholes suck just as much on v4 and v6. 6rd tunnels maybe make it a bit easier to hit if you advertise mtu 1500 and are really mtu 1480 because of a tunnel, but there's plenty of derpy networks out there for v4 as well.
IPv4 allows fragmentation by the middleboxes, which in practice papers around a lot of PMTU issues.
The IPv6 failing was not taking advantage of the new protocol to properly engineer fragmentation handling. But wait, there's more! IPv6 also has braindead extension headers that require routers to do expensive pointer chasing, so packets with them are just dropped in the public Net. So we are stuck with the current mess without any way to fix it.
> IPv4 allows fragmentation by the middleboxes, which in practice papers around a lot of PMTU issues.
In theory yes; but actual packets are 99%+ flagged DF. Reassembly is costly, so many servers drop fragmented packets, or have tiny reassembly buffers. Back when I ran a 10G download server, I would see about 2 fragmented packets per minute, unless I was getting DDoSed with chargen reflection, so I would use a very small reassembly buffer and that avoided me burning excessive cpu on garbage, while still trying to handle people with terrible networks.
Router fragmentation is also expensive and not fast path, so there's pretty limited capacity for in path fragmentation.
I think I agree with you, that RFC you linked seems awfully hopeful... unlikely to actually happen. Better endpoint probing is probably where we're going to end up. Or things like QUIC where if you don't have the required minimum MTU, too bad so sad.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
That's only true for smalltime home networks. Try to merge 2 company IPv4 networks with overlapping RFC1918 ranges like 10.0.0.0/8. We'll talk again in 10 years when you are done sorting out that mess ;)
> In IPv6 each host has multiple global addresses. But if your global connection goes down, these addresses are supposed to be withdrawn. So your hosts can end up with _no_ addresses.
Only a problem for home users with frequently changing dialup networks from a stupid ISP. And even then: Your host can still have ULA and link-local addresses (fe80::<mangled-mac-address>).
RFC6724 is still valid, they are only debating a slight update that doesn't affect a lot.
> Then there's DHCP.
DHCPv6 is an abomination. But not for the reasons you are enumerating.
> With IPv4 the almost-universal DHCP serves as an easy way to do network inspection.
IPv4 DHCP isn't a sensible means to do network inspection. Any rougue client can steal any IP and MAC address combination by sniffing a little ARP broadcast traffic. Any rogue client can issue themselves any IPv4 address, and even well-behaved clients will sometimes use 169.254.0.0/16 (APIPA) if they somehow didn't see a DHCP answer. If you want something sensible, you need 802.1x with some strong cryptographic identity for host authentication.
> Stateful DHCPv6 is not supported on Android (because its engineers are hell-bent on preventing IPv6).
Yes, that is grade-A-stupid stubborness. On the other hand, see below for the privacy hostname thingy in IPv4 and the randomized privacy mac addresses that mobile devices use nowadays. So even if Android implemented stateful IPv6, you will never be reliably able to track mobile devices on your network. Because all those identifiers in there will be randomized, and any "state" will only last for a short time. If you want reliable state, you need secure authentication like 802.1x on Ethernet or WPA-Enterprise on Wifi, and then bind that identity to the addresses assigned/observed on that port.
> With IPv6 there's literally _nothing_ similar.
Of course there is. DHCPv6 can do everything that IPv4 DHCP can do (by now, took some time until they e.g. included MAC addresses as an option field). But in case of clients like Android that don't do DHCPv6 properly, you still have better odds in IPv6: IPv6 nodes are required to implement multicast (unlike in IPv4 where multicast was optional). So you can just find all your nodes in some network scope by just issuing an all-nodes link-local multicast ping on an interface, like:
(The interface ID (like eth0, eno1, "Wired Network", ...) is necessary here because your machine usually has multiple interfaces and all of those will support those multicast ranges, so the kernel cannot automatically choose for you.)
> And even when it's supported, the protocol doesn't require clients to identify themselves with a human-readable hostname.
DHCP option 12 ("hostname") is an option in IPv4. Clients can leave it out if they like. There is also such a thing as "privacy hostname" which is a thing mobile devices do to get around networks that really want option 12 to be set, but don't want to be trackable. So the hostname field will be something like "mobile-<daily_random>".
What you skipped are the really stupid problems with DHCPv6 which make it practically useless in many situations: DHCPv6 by default doesn't include the MAC address in requests. DHCPv6 forwarders may add that option, but in lots of equipment this is a very recent addition still (though the RFC is 10 years old by now). So if you unbox some new hardware, it will identify by some nonsensical hostname (useless), an interface identifier (IAID, useless, because it may be derived from the MAC address, but it may also be totally random for each request) and a host identifier (DUID, useless, because it may be derived from the mac address, but it may also be totally random for each request). Whats even more stupid, the interface identifier (IAID) can be derived from a MAC address that belongs to another interface than the one that the request is issued on. So in the big-company usecase of unboxing 282938 new laptops with a MAC address sticker, you've got no chance whatsoever to find out which is which, because neither IAID nor DUID are in any way predictable. You'll have to boot the installer, grab the laptop's serial number somewhere in DMI and correlate with that sticker, so tons of extra hassle and fragility because the DHCPv6 people thought that nobody should use MAC addresses anymore...
> That's only true for smalltime home networks. Try to merge 2 company IPv4 networks with overlapping RFC1918 ranges like 10.0.0.0/8. We'll talk again in 10 years when you are done sorting out that mess ;)
Look, I've been doing IPv6 for 20 years, starting with a 6to4 tunnel and then moving to HE.net before getting native connectivity. I'm probably one of the first people who started using Asterisk for SIP on an actual IPv6-enabled segmented network.
I _know_ all the pitfalls of IPv6 and IPv4. And at this point, I'm 100% convinced that NAT+IPv4 is not just an accidental artifact but a better solution for most practical purposes.
> What you skipped are the really stupid problems with DHCPv6 which make it practically useless in many situations: DHCPv6 by default doesn't include the MAC address in requests.
Yes. DUIDs were another stupid idea. As I said, IPv6 is a cascade of recursive WTFs at every step of the way.
And let me re-iterate, I'm not interested in academic "but acshually" reasons. I know that you can run IPv4 with DHCP giving out publically routable IPv4 addresses to every host in the internal network without NAT. Or that you can do NAT on IPv6 or laboriously type static IPv6 addresses in your config.
What matters is the actual operational practice. Do you want a challenge? Try to do this:
1. An IPv6 network for a small office with printers, TVs, and perhaps a bunch of smart lightbulbs.
2. With two Internet uplinks. One of them a cellular modem and another one a fiber connection.
3. You want failover support, ideally in a way that does not interrupt Zoom meetings or at least not for more than a couple of seconds.
4. No NAT (because otherwise why bother with IPv6?).
Go on, try that. This is something that I can do in 10 minutes using an off-the-shelf consumer/prosumer router and IPv4. With zero configuration for the clients, apart from typing the WiFi password.
Well, I can do that with OpenWRT, no idea which prosumer devices already implement this, but it isn't rocket science: Announce the Prefix of the currently active connection, invalidate the other one. Will interrupt all your TCP connections, but they are toast anyways, most software should handle this just fine. It's quite the same as a Wifi-to-Cellular handover.
> Announce the Prefix of the currently active connection, invalidate the other one
And this doesn't actually work. Prefix deprecation is a best-effort feature that is not implemented correctly in tons of devices, including such rarely used niche operating systems as macOS. It even technically violates RFC4862 (section 5.5.3).
I highly recommend actually trying what I proposed. Not in a theoretical hand-wavy way, but actually setting it all up and verifying that it works. I did not pose this challenge in a "gotcha" way. I really was not able to make it work cleanly with either Mikrotik or OpenWRT routers.
That was always the plan for "the future". That is get everyone to IPv6 and then get rid of IPv4. IPv4's days are numbered - but the number looks really big.
Of course there's an incredibly long tail here, but in the big picture, "nobody except some people maintaining a few legacy systems ever need to learn to work with this protocol anymore" is practically the same thing.
Comcast, one of the largest residential ISPs in the USA, has almost full IPv6 deployment by default. The majority Verizon Wireless is IPv6 by default. Residential customers in the USA have great access if they just enable the stack.
There is nothing about IPv6 that prevents ISPs from filtering ports for all customers. They almost all actively filter at least port 25, 139 and 445 regardless of the actual transport. So I'm not sure "blocking service hosting" is the actual goal here.
The problem seems to be that all of the large and wealthy nations of the world have made the necessary huge investments into IPv6 while many of their smaller neighbors and outlying countries and islands have struggled to get any appreciable deployment.
It should be a UN and IMF priority to get IPv6 networks deployed in the rest of the world so we can finally start thinking about a global cutover.
In many developing countries IPv6 adoption is far and sometimes networks are IPv6-only, because IPv4 is expensive and they have relatively little addresses compared to users...
You can see southeast Asia is pretty green on the map of the post.
How far below is the question. It could level out at 60% - that is believable. However it can't level out at 99% - Somewhere around 95% major sites will decide IPv4 isn't worth supporting and they will just ignore that final 5% of customers, which will force them to upgrade - which in turn will give others confidence to remove their final 4% of customers - until IPv4 dies.
There are also still Telex and X.25 networks around there, not to forget the whole public telephone network!
But at some point, getting a native connection to all of these started becoming increasingly rare, and now these are largely emulated/tunneled on top of IP. The same can happen for IPv4.
Can you share details on how one trivially connects via IPv6 only? I see no option in iOS Wi-Fi settings to do this, and I think it's reasonable to expect not to have to turn off IPv4 on my access point to test IPv6-only networking.
I’m going to guess no one responding to me has actually tried connecting to an IPv6 only network because it works without incident. Will your apps? Who knows - apple hasn’t always been great at enforcing that.
NAT64 doesn't make sense for consumers. There are too many apps that hardcoded IPv4 in their code. People are going to complain that their old Xbox games don't work.
For most people, dual stack works fine. For mobile, the solution is 464XLAT that translates locally. There is MAP-E that does translation on gateway with IPv4 on local network.
For businesses, NAT64 makes more sense cause they can control what software is running. Even there, usually have to make IPv4 subnet for the old printers.
In parts of the world with fewer IP addresses they already are. My ISP _only_ offers MAP-E access to the IPv4 internet for anyone not grandfathered into an older plan.
“Privacy addresses” are named because in the beginning, your auto-generated IPv6 would incorporate your hardware MAC address verbatim, and many people consider the MAC address to be PII.
On the last 64 bits, yes. On mobile phones, the first 64 bits may be fixed. This was something I argued against when I was at Vodafone Group, but didn't get any traction. That was a while back, but I'd assume that this is still the case, and that mobile phone addresses can be used for tracking.
No, not just like IPv4. My IP address is 192.168.0.23 right now, as are millions of others. Add in CG-NAT from my ISP and I do not have a globally unique identifier.
Zoom in on that graph using the controls at the bottom, and you'll see a repeating pattern of crests and troughs, weekly. There's about a 5% difference between the crests and the troughs: the crests are hitting the 50% line or just below it, and the troughs are down around 45%.
The real question is, why are the crests so predictable? They're always on Saturdays; Sunday dips down a little below the crest, then Monday-Friday is down in the 45% range before the next Saturday jumps up to 50% again. (Fridays usually have a small rise, up to the 46-47% area).
My theory: mobile access rises on weekends. People are more often accessing Google services from their work computers Monday-Friday, but on Saturdays and Sundays most (not all) people are away from the office. Many of them will end up using smartphones rather than laptops for Internet access, for various reasons such as being outdoors. And since smartphones are nearly all using IPv6 these days, that means an uptick in IPv6 usage over the weekends.
It's not just mobile networking but residential ISPs in general have better IPv6 support. In the US, Comcast was one of the first big IPv6 deployments, in Europe CGNAT+IPv6 is common in many places.
Meanwhile corporate IT for business and education networks have less incentive to upgrade and typically lag behind in adoption in general.
I've been running full dual stack for >15 years now. It has become second nature by now and I'm slowly testing IPv6 mostly, but so far it's just easier to deliver dual-stack to all users instead of dealing with workarounds to make the last few non-IPv6 capable services work without native IPv4.
This matches what I've seen too. Mobile carriers have been way ahead on IPv6 - T-Mobile in the US has been IPv6-only with NAT64 for years. The weekend pattern is pretty much a smoking gun for mobile being the driver. It also explains why the Google metric (which skews consumer) looks so much better than the Wikipedia numbers someone else posted (35% IPv6) or the server-side adoption stats from Common Crawl.
Residential vs. business. If the graph was hourly and per country, you'd see the same rise every morning and drop every evening (likely by more than 5pp).
Your mention of per-country reminded me that Google is probably using UTC for those timestamps. 11:59 PM UTC is 8:59 AM the next day in Japan (UTC+9), so Japanese people getting online early Saturday morning would register as accessing Google services on "Friday" until the time hits 9:00 AM in their timezone. Likewise Korea (also UTC+9) until 9:00 AM local, China (UTC+8) until 8:00 AM local, Vietnam (UTC+7) until 7:00 AM local, and so on.
Which means that if Japan, Korea, China, Vietnam, and other east Asian countries have a higher IPv6 adoption in residential vs business ISPs, then their Saturday-morning Internet access is likely part of the 1-2pp bump on Fridays in this chart.
P.S. Also, none of Japan, Korea, China, or Vietnam use daylight savings time (very sensible of them), so their UTC offsets are the same year-round. So their Saturday-morning contributions to the Friday chart will not vary from month to month due to timezone slippage, because they will never gain nor lose an hour relative to UTC. It might vary a little with actual seasons, as the sun rises later or earlier... but so many people use alarms to get up at 6:00 AM no matter what the sun is doing, rather than rising with daylight, so the amount of early-morning Internet access in winter months is not going to change significantly compared to summer when the sun rises earlier.
If GitHub flipped a switch and enabled IPv6 it would instantly break many of their customers who have configured IP based access controls [1]. If the customer's network supports IPv6, the traffic would switch, and if they haven't added their IPv6 addresses to the policy ... boom everything breaks.
This is a tricky problem; providers don't have an easy way to correlate addresses or update policies pro-actively. And customers hate it when things suddenly break no matter how well you go about it.
Having been messing around personally with getting my own blocks of IP addresses and routing[1] - I've become terrified at the idea of implementing access control based on IP address.
Unless your own organisation in the RR has the IP addresses assigned to you as Provider Independent resources, there just seems to be so many places where 'your' IP address could, albeit most likely accidentally, become not yours any more. And even then, just like domain names, stop renewing the registration and someone else will get them - I was that someone else recently...
It's fun and has now become an addictive rabbit hole - trying to get packets from one location to the other in the fastest, most direct way (and at hobbyist budget level).
IP filtering is a valuable factor for security. I know which IPs belong to my organisation and these can be a useful factor in allowing access.
I've written rules which say that access should only be allowed when the client has both password and MFA and comes from a known IP address.
Why shouldn't I do that?
And there are systems which only support single-factor (password) authentication so I've configured IP filtering as a second factor. I'd love them to have more options but pragmatically this works.
Why are you (re-)implementing client security on provider end? If a client requires that only requests from a particular network are permitted... Peer in some way.
I do understand the value of blocking unwanted networks/addresses, but that's a bit different problem space.
Thanks to the trend to SASE like Palo Alto GlobalProtect or ZScsler this practice is not a good idea anymore. Speaking of ZScaler, they are still IPv4 only, right?
Sometimes TCP/IP is a leaky abstraction, and recently ipv6 peeked through in two separate instances:
- In a cafe wifi, I had partial connectivity. For some reason my wifi interface had an ipv6 address but no ipv4 address. As a result, some sites worked just fine but github.com (which is, incredibly, ipv4-only) didn't
- I created a ipv6-only hetzner server (because it's 2026) but ended up giving up and bought a ipv6 address because lack of ipv4 access caused too many headaches. Docker didn't work with default settings (I had to switch to host networking) and package managers fail or just hang when there's no route to the host. All of which is hard to debug and gets in your way
You can solve this issue if you have one server with ipv6/ipv4 you can run NAT with Jool and connect ipv6 only servers to that. Like Android does.
I wish hosting providers would give you a local routed ipv4 on ipv6 servers with a default NAT server. It is not that expensive I move 10Gbps "easily" and they could charge for that traffic.
30 USD/month and 0.045 USD/GB for ingress it is ok if you are big. It is a cheap service to build yourself. I do feel the pain of it being hard to get IPv4 minimal connectivity on ipv6 only hosts, i.e. for me a 1 USD/GB would be fine.
Those are still per-customer and require you to dedicate an entire IP address to it. That's overkill for a server which mostly talks over ipv6 but needs to connect to an ipv4-only service like Github once in a blue moon.
The cafe WiFi thing (getting IPv6 only, no ipv4, on a public network) used to happen quite often to me on macOS. I never figured out why, and I haven’t noticed in a while.
I doubt it honestly. Most people are connecting to sites like Youtube, Instagram etc., which do actually support IPv6.
It's how I get 60~80% IPv6 traffic on my home network. A great portion of it was because of my mom watching Youtube.
Even when you discount the services run by FAANG, for personal sites, Cloudflare and GitHub Pages (but surprisingly, not GitHub itself) support IPv6 and enable IPv6 support by default.
It's only a matter of time before laptops get 5G. Macbooks have been rumoured for a while to get cellular modems. [1]
This will probably help adoption. On the one hand it will generate more IPv6 traffic. On the other hand it will expose more developers to IPv6; which will expose them to any lack of support for IPv6 within their own products.
I can confirm this. I work at an e-waste recycling company, and the vast majority of my inventory is corporate IT decommissioned gear. About 1 out of 10 laptops I tear down has a cellular modem, going back to about Intel Core 5th gen.
I've had laptops with cellular modems built in going back to Pentium IIIs. The Compaq N600c had a "multiport" bay on the lid, one of the options was a GSM modem.
I've never had a modern laptop with a cellular modem, but every one I've owned has supported them internally. Even when they aren't provisioned with them, they're usually still supported as aftermarket options.
Thats quite surprising thing to me and weirdly obvious.
If you are single, have a phone contract, you would need some extra contract for a landline internet and wifi router because thats what a lot of people just do and now they can just add an esim and pay a little bit more.
Interesting that this sounds/feels a lot more right or useful than it did 5 years ago.
I can't imagine a worse privacy nightmare. Always on backdoored baseband in 5G with a unique permanent IPv6 address assigned to the machine. Okay, maybe it could be worse if each user account is assigned its own unique IPv6 perma-cookie.
You're thinking of MAC addresses. Machines don't have permanently-assigned v6 addresses, rather the IP is assigned by whatever network they're currently attached to and will change based on that network's whims, just like it does in v4.
I get an IPv6 address from my ISP (a /56 I believe), but I wish there was some good information on how to update my OpenWRT VLAN configuration, routing, and firewall rules to be able to support native IPv6 on my devices. Would love to be able to have direct IPv6 connections to the internet from my devices, but I want to make sure I can do it safely.
You only need to set nothing and it should setup ipv6 on all downstream vlan interfaces.
For static prefix I'd you can set ip6hint per vlan interface.
For each vlan interface you need a stanza in the DHCP config file.
And regarding firewall, as with the default lan zone you might need to add new zones with the vlan interfaces and configure forwarding rules. That's it.
Yeah, I'm in the same boat. I like the idea of being able to remotely connect to anything on my network, but I know just enough about networking to be dangerous, and don't trust my self to set it up securely, so I have IPv6 disabled on my router. With IPv4, it's physically impossible to mess up the firewall and NAT settings enough to make local devices public.
NB: this is not "IPv6 traffic crosses the 50% mark" but "availability of IPv6 connectivity among Google users", which is a very important difference. This means roughly half of Google users have IPv6 capability, which does not 1:1 correspond how much traffic is actually transferred over IPv6, which is what this submission says in the title.
Yeah and this distinction explains the fact that because China's Great Firewall blocks Google, this website shows 4.66% adoption as a reflection of that. I think China's IPv6 support rate is actually much higher than that, maybe a little over 50% because of its central initiative to increase IPv6 adoption?
Right, but in most situations clients will prefer IPv6 if its available, so if they have access, they almost always are using it, at the very least from their local network.
The regulatory body, ARCEP, has been very proactive since 2002 (!) on IPv6. The recent uptick is due to IPv6 obligations bundled in the 5G spectrum licences.
Maybe my guess only, but France has its bit of a technological centralization. I mean, a lot of people use internet from operators like "Orange" / "Free", and in contrast to other countries, routers provided by the operators in France do not suck. The routers are OEM, but overall quality you get from them is on-par with Ubiquity/Mikrotik.
This gives operators a benefit of the vertical control for the whole ecosystem - from top to the bottom, including intricate parts of protocols and routing. And France, in contrast to other countries, does not suck here too - operators usually do a good job of meticulously maintaining their assets.
My personal impression is that this is the result of several cultural factors:
1. Ingrained respect of privacy, private property, and a peace of heart as they call it. As a practical result of that, you do not get spammy messages and ads from operators, banks, etc. You may get some, like 3 or 4 discounts/offers in a year. Compare that to other countries where you can easily get 10s/100s messages like that in a single day. In other countries, instead of upgrading the infrastructure, people are busy with spamming each other.
2. The harsh oceanic environment with hurricanes and storms fosters an appreciation for reliability and functionality. It also encourages a certain frugality: every cent matters. As a result, people tend to develop a strong sensitivity to situations where form is prioritized over function, and such approaches are quickly dismissed as impractical. This gives a certain internal freedom of being able to see through things to determine what they are in the long run and not what they appear to be on the surface.
3. French people don't like to overwork outside of working hours. So choosing something like IPv6 over IPv4 seems like a natural forward-looking investment for the future where you can have less maintenance burden and thus you can devote more time to enjoying other things in life.
Having all those things combined, it's not hard to see why France chose IPv6. It's a natural choice there and it's imposed by survival.
P.S. I've spent some time in France, but was born in another country.
This is probably not the real reason, but I find it interesting that France had Minitel (^1) before and later had to switch to the Internet, and then later became the fastest country to complete the IPv6 transition. So perhaps they had an engineering culture that was prepared for the possibility they would have to upgrade the entire network on a nationwide scale.
I worked with the internet society to mobitor ipv6 adoption for the top million sites ipv6matrix.org it's broken down by country so might answer some of your curiosity
Adding on. Jio was a late entrant, so they could not get significant ipv4 address space without great expense. They deployed as mostly v6 with a tiny CGNAT. They also had an extensive 'pre-release' offering at zero cost to subscribers which got them a huge number of subscribers and clout to encourage internet services to offer ipv6.
India has about 1.5 billion people, and has only recently been getting most of them online. Less IPv4 legacy, and it has always been obvious that IPv4 was never going to be ‘enough’ to actually onboard everyone anyway.
When I lived in India, everything had IPv6 out of the box.
It amuses me to see that according to the map, France is best in class or close to be, while just a few weeks ago, my ISP in France stopped providing me IPv6 connectivity…
The story is that at the beginning I had IPv6, and a shared dynamic IPv4 behind a CGNAT, I asked for a rollback to a full duplex static IPv4 and for three years I had both a static personal IPv4 and an IPv6. A few weeks ago my router went down and since it went back up, I no longer have an IPv6 address. I called my ISP and they explained that I could either have IPv6 or a static IPv4, but not both, and that it's abnormal that I had both for so long… welp, it's sad to see IPv6 but getting it back is not worth abandoning my static IPv4 and going back to a dynamic shared IPv4.
A cheap VPS or one with spare bandwidth with > /64 that is properly routed (some providers do NDP for some reason) and a Wireguard tunnel would also get you a simple DIY solution.
Are you with SFR? I also seem to only have a static IPv4 (I don't pay for it, but it's never changed in the lifetime of the connection). I asked for an IPv6 but they said it was not possible/difficult.
I know, but at the time I had to choose an ISP, they were the only ones with an offer with just internet (and a phone line), all others ISP forced a bundle with dozens of TV channels that I don't need along with their internet access subscription. They were also the most competitive price wise, and other than this problem (which is new for me, I had an IPv6 and a static IPv4 until a few weeks ago), I'm satisfied with the service :).
The real migration challenges are in the server side/consumer home internet space which I'm not sure if there are clear stats around the adoption there.
I think IPV6 is a great example of over engineering, trying to do too much in one iteration. In an ideal scenario this could work, but in the context of large scale change with no single responsible party, it usually doesn't work well.
On the server side, everyone is moving behind CDNs that support IPv6 by default.
On the consumer home internet side, consumer ISPs are slowly one by one lighting up IPv6, and it just works since consumer routers are mostly auto-configure (often literally controlled by the ISP). Mobile is largely IPv6 already.
The biggest challenge is in corporate/academic/medium-size business networks where they have lots of obscure subnets and firewall rules and old software and hardware running a critical task under a dusty table somewhere.
The problem has nothing to do with over engineering, or really anything to do with the actual contents of the IPv6 standard. It is just devilishly hard to make any backwards-incompatible change to layer 3, and address expansion is always going to be backwards incompatible.
IPv4 addresses are in fact a subspace of IPv6 (that's NAT64). They were not by fiat declared invalid. The actual thing I think you're complaining about - the necessity for NAT64 at all - is unavoidable, because you need a NAT/protocol-translation layer for packets to actually move between the new address space and the old one.
SLAAC-by-default is not, in my experience implementing IT automation, an actual barrier for adopters. You have a router sending out RS instead of a DHCP server, to an admin this is not a meaningful change.
NAT64 is a temp bolt on and also not the same thing. If I own 1.1.1.1 in v4, that doesn't mean I own some equivalent of 1.1.1.1 in v6. They had router nat64 and relay nat64, both with dealbreaker problems.
You don't exactly need a translation layer. If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual. Then after v4 is abandoned enough, I can sell 1.1.1.1.2:: to someone or use it instead of NAT.
SLAAC is a good design as a non-default that people who know what they're doing could enable, but a lot of people don't even want public v6 addrs for hosts, they just want NAT/DHCP.
> You don't exactly need a translation layer. If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual.
Think about this on a concrete, packet by packet level - I, from a v6 network, with a 128-bit address that cannot be represented by IPv4, decide to open a connection to 1.1.1.1. 1.1.1.1 doesn't have v6 set up, and so can't read my v6 packet and craft a response packet, because its address is invalid in v4. We need a gateway in the middle that will translate the packets from one format to another and perform the NAT function from one address space to another. This is an irreducible complexity.
> a lot of people don't even want public v6 addrs for hosts, they just want NAT/DHCP.
People don't care about whether their address is public or not, they want connectivity. SLAAC gives that to them; it is you that are insisting on adding complexity for the sake of having a non-routable address. As a user, I enable IPv6 on my router and go on my merry way; as an ISP, I assign my customer's router a /60 or /56 via DHCPv6 instead of a /24 and go on my merry way. Running an IPv6 address allocation system is a an easy, solved problem and has been for decades.
The hard problem is dual-stacking, and there is no way around that.
I mean, you own 2002:101:101::/48. You also own ::1.1.1.1, ::ffff:1.1.1.1 and 64:ff9b::1.1.1.1.
> If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual
That's not really how routes work. Or DNS.
I think you're mainly arguing we should import v4's allocations into v6, but about the only benefit is that people don't have to bother requesting new allocations. It doesn't help with any other aspect of the transition, and there are good reasons to avoid doing it -- the v4 address space is highly fragmented and also very unfairly allocated.
Plus we have plenty of people saying we should take back v4 allocations from companies that own them. That's not possible, but _not_ giving owners of v4 /8s an entire 1/256th of the v6 address space certainly is.
The question is, "what will the graph look like in the next 10 years?"
I get the whole s-curve trend but if I squint at 2017, there is an inflection to slow the s-curve down.
Annoyingly, when setting up service with a fiber company in the last couple months, I explicitly asked about IPv6 connectivity and they said, "yes." Turns out "yes, but not in my region."
Meanwhile: one of the major mobile network in my country announced cisco collab/ipv6 ~5 years ago, but still doesn't provide v6, just v4 CGNAT.
Personal web server running dual stack since early 2010s currently sees 18-20% v6 traffic. When split by type, counting only mobile users it reaches 30% at peak.
Bot/crawler traffic is ironically 100% v4.
Meanwhile: enabled h3 in september last year for the fun of it, instantly at >40% traffic by request count, passing 50% since the beginning of the year, h2 accounting almost all the remaining traffic and plain ssl/http requests <1% being just bots.
I consistently get 100x as many captchas from google over V6 as over V4, on many different networks: it is obnoxious and obviously broken on their end.
IP reputation is a tough problem with a lot of establishment behind v4. Even if they were to build up v6 reputation, since v6 addresses are cheaper, wouldn't they have lower rep?
The "reputation" concept has to be applied to network blocks in IPv6, because of privacy addresses, and they very clearly aren't doing that for whatever reason. I get at least one captcha a day from a stock Android phone that's been connecting from the same damn /64 for almost a whole year.
But there are way more /64s than /32s. They could apply it to /32s in ipv6, but then customers would share rep unless ISPs lease out /32s instead. Unfortunately gotta pay to play.
Everyone's saying progress is slow, but maybe this is just how long it takes to do massive decentralized global migrations affecting billions of people. What are we comparing against? Maybe the ICE-to-EV transition?
For example, compared to migration from 3G to 4G networks. As I understand, from the launch of 4G to complete shutdown of 3G it took around 12—14 years.
A reasonably fair comparison. The ISPs had a much stronger incentive to finish the migration, though, because the 3g spectrum could just get turned around and used for 4g after rollout. IPv6 doesn't really have that strong of an incentive structure now that CGNAT is a well-developed technology.
World IPv6 Day was in 2011, so 15 years since then. This is also requiring a consumer hardware and software upgrade on both the client and server (resource they're accessing). GitHub doesn't have to implement 4G support.
One major difference in the 3G->4G and now 4G->5G conversion was that was largely a single-party change in the end to actually implement. The client and the server hosting an application doesn't care about whether that traffic is over 3G or 4G or IP over Avian Carriers as long as the packets get there in a reasonable time. Going from IPv4 to IPv6 requires lots of very different players to all work together to make the transition, meanwhile for a carrier to go from 3G to 4G its largely on them and their direct contractors.
Currently my IPS provides IPv6, but I set up my firewall in the access router of my home LAN to block all IPv6 in both directions.
- I don't want to have a permanent global unchanged ipv6 as in id of my traffic.
- IPv6 privacy extensions would change that but then I can not reach my two devices I do want to reach from outside anymore as my access router only supports DynDNS for its own address and no NAT in IPv6
Router has a DynDNS function. I am using a reverse proxy for multiple services, but this only sets up router IP and IPv4 NAT port forwarding to the reverse proxy.
So what would be the correct setup with IPv6 when using privacy extensions?
I don't see any benefit in allowing IPv6 traffic or using IPv6, but a couple of new problems coming up with it.
Privacy extensions are additional addresses that are used by default for outbound connections. You still have the non-privacy address, which doesn't change; put that one into DNS.
This approach prevents outbound connections from leaking the address needed to connect to your servers. On v4, it's likely that any outbound connection from your network gives the server the IP they need to do that.
So you'll never have a permanent unchanging v6 address to ID your traffic with.
Privacy extensions are orthogonal here; they only affect the suffix, not the prefix. As for dealing with a changing prefix... I'm afraid you'll just have to find some way to automate the DNS updates. You can do it with a program running on one of the servers -- I can't suggest a specific one offhand since I have a static prefix and haven't needed it, but they do exist.
Never checked. But it does change once in a while. The router has a dyndns function which updates a DNS entry, but only for the router itself. But this is sufficient for the NAT port forwarding.
Let's say when your ipv6 prefix changes it is almost the same situation. Only that ipv4 bundles all traffic of all devices on one ip which obfuscates a bit.
But having the ipv6 prefix change you get a pile of problems (DNS, firewall), you don't have with ipv4.
The IPv6 prefix changes are disruptive, I agree. My prefix has been stable for a couple years, but on another ISP it would change every few months and was certainly annoying.
I recommend going through Hurricane Electric's multiple-choice tests. It's not exactly a how-to guide or course, but it'll mention all of the terms and technologies you need to look up to get things right. They'll even send you a free T-shirt if you make it through all of them.
The most difficult parts for a homelab in my experience is getting Docker to play nicely. All of the other stuff sort of just works these days. Even things like using DHCPv6 prefix delegation to obtain a routable subnet is almost trivial with how well-supported the protocol is with modern networking software.
I wish EU make it mandatory at least for all ISP to make mandatory support for IPv6 by end of this decade. I think that would push the needle even globally.
Setting up my own server (migrating off GCP LB) taught me so much about networking. I was especially surprised that providing IPv6 is such a performance boost for low bandwidth phones since they mostly only operate on IPv6 by now and IPv4 needs some sort of special roundtrip.
Cool! Could you give some concrete examples of apps or traffic patterns where you think IPv6 may noticeably improve performance on phones? Are you mainly referring to NAT traversal during connection setup, or to something that also affects traffic after the connection is established?
Many mobile ISPs handle v4 via NAT64 or CGNAT. Routers capable of doing those are far more expensive than regular routers, so there tends to be fewer of them. v4 traffic has to travel out of its way to reach one of those routers, whereas v6 traffic can be handed off sooner with a more direct physical path.
I am in the middle of building infrastructure in GCP. The workload is your typical stateless web + db workload.
As of now, there is no way to have a 100% internal ipv6. Many of the services, including CloudSQL or the connection between external and internal load balancers do not support ipv6, even when the external load balancer support ipv6 forwarding rules at the front end.
This means that careful internal ipv4 allocations still matter.
I think its incredibly ironic actually. The place where IPs are burned through rapidly (internal) is forced to use v4. (and, potentially even a subset of it, RFC1918; likely conflicting with some large company or service if they decide to plumb it together later- or you burn publicly accessible IPs in the limited address space)
But the one interface that touches the internet can use v6: the one with a functionally infinite address space.
I had the same issue a few months ago on AWS. All I want is a server (that pulls a container), a database, and a load balancer. It's all going behind CloudFront so there should be no need to pay for an IPv4 address for any internal machine. Couldn't do it. Since then I saw that there was some movement on IPv6 for RDS but IIRC there was still some other blocker.
> so there should be no need to pay for an IPv4 address for any internal machine
At what level did you need to pay for IPv4 addresses in this stack? You should have been able to make this work with a private IPv4 space, have the ECS services be dual-stack and be on both the v6 network and the v4 network to talk to the database server, have the ALB be v6, and then have Cloudfront be v6. If you wanted, you could also just ignore v6 for the ECS services and have them just live in that same v4 subnet entirely.
I could be wrong (and please tell me what I'm missing) but you shouldn't have had to pay for IPv4 in this case. I do just wish RDS (and so much else) would just support IPv6 though, you shouldn't need to have a bunch of extra subnets just to talk to your database.
Can someone reconcile for me the constant chatter about how IPv6 isn't getting impemented, versus this result that more than half of all traffic (as measured by google) is now IPv6?
It sounds to me like its a tool which is available to be used when needed and when no better workarounds exist, and it is slowly but surely being adopted as needed.
As a sometimes chatterer, it's a mix of complaining about the annoying changes in v6 that weren't just lengthening the address fields, pointing out that the migration is taking forever, and implying a less disruptive design could have rolled out faster.
For a long time, there really was next to no progress. Between the introduction in 1996 and about 2011, there was very little adoption. And since 2012 when pushing really started, we're at about 50% globally, with large variance by country and network type. 15 years between creation and real deployment seems like a lot, and 15 years of deployment getting to 50% also seems likes a lot.
But wikipedia says touch tone dialing was first offered to consumers in the 1960s and didn't become majority until the 1980s, so maybe 30 years isn't that slow.
They use 464XLAT, basically NAT64/DNS64 with some extra cooperation on the OS’s part for backwards compatibility with apps that hard-code IPv4. You get only a v6 address, and your OS basically synthesizes an v4 network on your device in cooperation with their NAT64 router. But all the bytes going from your device through to their towers are ipv6. Talking to a v4-only website uses carrier-grade NAT64 when leaving the t-mobile network.
Additionally, their fixed-wireless product gives you a physical CPE that does the CLAT (NAT46) side of the 464XLAT.
To the local network, it looks like there's native IPv4, but it's translated to IPv6 by the gateway, and sent to the "nearest" NAT64 PoP to be translated back and sent along its merry way.
Random related data point: for HTTP requests to Wikipedia (and related) for the past 7d, the IP protocol split is roughly 35% IPv6 / 65% IPv4. (this is counting by-request, so heavy usage from a small number of IPv4s can skew it).
If be curious to see what the IPv4/IPv6 breakdown looks like when looking at HTTP/2 and HTTP/3 connections only, which should exclude the vast majority of crawlers.
My interest was piqued 20 years ago, then there was talk about Internet2 with all these amazing optimisations.
Things have developed so much, a Internet2 is still going on I take it, however is more focussed on university research.
As ever a killer strength is something that draws people to a new technology, I imagine there's various demographics that benefit from use of ipv6.
Further I imagine that there are some levels of criticality which when reached are more self sustaining (dare I say it the network effect?).
I've been posting this graph over the years, and it really has slowed down hugely close to this 50%. This is a global ipv6 support, so some countries are racing ahead, others weirdly like Denmark have a stash of ipv4 addresses and seems content.
France and Germany are at about 80%, but there's the rest of the world of course.
I just recently noticed that my ISP, Frontier, quietly turned on IPv6. I know it wasn't enabled back in December, so it has to have been sometime in the past few months.
interestingly my ISP, at&t, quietly turned off ipv6. not sure exactly when it happened, i should get around to complaining about it but i hate making phone calls
The failure wasn't in the technical design of v6, but in the economic assumption. When the cost of migration exceeds the cost of 'hacks' like NAT, people will stick to the hacks for as long as humanly possible.
Somehow it's really hard to find numbers, but AFAIK at least Telekom and 1&1 don't use CGNAT for home connections, which already rules out that 77% have it.
German ISPs commonly seem to have an option of their "old" platform (v4 only, no v6) or their "new" one (v6 and CGNATed v4). Maybe you're on their old one? Or maybe they only use it for certain account tiers or somesuch.
I've been with 1&1 for a long time, previously DSL and VDSL, so I could have something grandfathered in - but I doubt it. Especially after the recent transition to fiber. And I am not paying for any special options.
I am aware of at least 2 telecoms, one publicly traded, that have very little to no IPv6 in their core networks and only use IPv6 when they have to.
Personally I think the design of IPv6 offers very little benefit; supposedly the Dept of Defense/Dept of War holds some 175 million IPv4 addresses, with other companies also holding large allocations - that should have been addressed 25-30 years ago as an administrative matter.
To what end though? 4 billion addresses is not enough on its own, even if they were reallocated from hoarders. I think that NAT and especially CGNAT have been very detrimental to the shape of the internet, where it's nearly impossible to self-host a public service without a VPN of some kind. Needing to pay some company for the ability to host a server that isn't behind NAT is a barrier that doesn't need to exist when IPv6 has a nearly limitless number of addresses.
You're not wrong, but practically speaking, hosting a VM is so cheap and comes with the advantage of serving from a datacenter that I would never want to host anything off my residential connection anyway.
The $1 to $5 a month to have excellent, reliable connectivity (that no residential connection provides), DDoS protection, and isn't tied to my home IP outweighs any home hosting benefit in my experience.
There are 16 /8's in the class E address space that were never allocated, and 19 /8's (by my count) allocated to individual companies. If you waved a wand and returned all of that space to IANA for allocation, you would have staved off IPv4 address exhaustion by... about 3 years.
2.7 - 4.0 years, by my math, so I would agree with your assessment.
...but that's based on pre-IANA-runout rates, though, and doesn't account for the pent-up backpressure of demand. So probably a lot less, in reality.
Not even remotely worth the effort, even if there were a legal pretext for "reclaiming" IPv4 space (there isn't; there's already precedent denying it).
A hidden benefit is it's no longer possible to have another "we typed the wrong IP address" raid story. IPv6 is larger than the total number of heartbeats of all heart-bearing life that has ever existed. You either nailed the abuse address or you're raiding something that doesn't even exist.
What I have asked myself the last few months: I've read about IPv4 becoming sparce a few years ago. I haven't read much about it lately. And I've thought maybe the advance of cloud computing and load balancer kind of mitigated the issue of sparce IP4?
It officially started becoming scarce in 2011, when IANA, and then APNIC, depleted their IPv4 "free" pools, FWIW. Things have only gotten worse from there.
Cloud computing doesn't mitigate IPv4 issues, it just moves it around. The big cloud providers buy up any IPv4 space they can, leaving less for everyone else. The difference is that they then get to collect rent, by the hour, on any IPs their customers use.
Load balancers...yeah, actually that is a valid approach to reduce IPv4 use, assuming you mean the "reverse proxy" variety of load balancer. Cloudflare's proxy service is doing exactly this, on a pretty huge scale. (CLoudflare can then send the traffic on to an IPv6-only server, regardless of the client's protocol.) The downside is, like cloud, consolidating a lot of infrastructure into the hands of a small number of companies.
Some internet-drafts contain useful knowledge because they specify an existing protocol that never continued through the IETF process to reach the level of an informational standard. For example, TACACS+ is best specified in a dead internet-draft.
However, in most cases, internet-drafts are just that - drafts. They are usually requests for comment (ironically enough) on the author's idea. Someone had an idea and put it out there to see what other people think. Sometimes they don't even get to that stage but die immediately upon being uploaded as the author realizes they are silly.
15 years ago I would have dismissed this immediately as an elaborate troll but nowadays you cannot be sure anymore.
I'm suggesting moving on to IPvNN which requires device and ISP forced guarantees that the originator is not under the effect nor the lack of any medication or other substance, not being coerced and not using non-human assistants in content creation.
As long as no significant websites are IPv6-only qnd no significant user base is IPv6-only, why would anyone join IPv6? What proponents could do is make their websites IPv6-only. The IETF website, for instance, should be IPv6-only.
while it looks like its slowing down, I am pretty sure it will speed up once IPv4 get even more expensive, sites start to be hosted on IPv6 only and become inaccessible to some users that dont have IPv4. Thats surely going to put pressure on ISPs
Outside of hobbyist niche uses, sites won't start being hosted IPv6-only. The financialization of IPv4 addresses will simply get worse and be even more pay-to-play than it is now. Amazon raises the price of IPv4 and everyone goes along as a cost of doing business.
My prediction is that sites will be half-IPv6 only; backends will be IPv6 and IPv4 traffic will get proxied to IPv6 by CDNs / edge LBs. I think CloudFront for example supports that scenario, avoiding IPv4 costs (in theory).
that may be true, but not being able to access hobbyist sites still feels like "being locked out" of something. My ISP provides /48 IPv6 addresses for free, and I already run a couple sites only on IPv6 - because an IPv4 would cost 20 bucks a month - it's not important enough to me personally to pay that.
With IPv6 privacy extensions it's impossible to tell which device you're talking to inside of a /64. You'd need to do something silly like DHCPv6 to get that kind of remote device-level tracking.
Nice. But note that the average is still significantly below 50%. It's also a bit concerning that the growth rate seems to be levelling off. It currently looks like a sigmoid curve with a maximum far below 100%.
I wouldn't be so worried about it. It's really hard for something as big as this to really hit 100%. If we hit 80% or thereabouts, we can at least plausibly argue to backwards ISPs that IPv6 is the default and the standard that everyone should reasonably be offering.
Generally: I'm really surprised that Norway is just at 27%. I think I've been with 3 different residential ISPs the last 15 years, and all of them have done IPv6 perfectly well (two nits: I think one required a trivial opt-in, and my current ISP is just giving me /60 which isn't perfect).
Edit: Oops, sorry to my current ISP for shaming them. Some googling told me that one can get a /56 using DHCPv6-PD. I'll try that!
Interesting to see Spain having such low IPv6 adoption. Perhaps that's exacerbated the issues caused there by blocking IPs during football matches that we've seen mentioned in recent HN posts.
Spain has one of the highest FTTx rollouts in Europe though. My theory is that they just prioritized building fiber and there was no money left for ipv6 transition.
worth noting that the google stat measures ipv6 availability among users who access google, not general internet traffic -- so it's a bit of a self-selecting sample skewed toward consumer isps that have deployed ipv6, which probaly overstates adoption for enterprise and datacenter traffic where the github situation is much more representative of reality.
IPv4-with-more-bytes is not backwards compatible with IPv4. So you'd have to replace/upgrade every existing network stack, both hardware and software. To get, basically, the same effect as moving to IPv6.
> IPv4-with-more-bytes is not backwards compatible with IPv4
Neither is IPv6
> To get, basically, the same effect as moving to IPv6
The only thing that IPv6 solves which is of interest to 99.99% of the users is having more adressable space. The rest of IPv6 features are either things that nobody asked for, or things which are genuinely worst compared to IPv4.
I consider the mere fact of enabling IPv6 an unacceptable security risk, as I would now have to make sure my IPv4 and IPv6 firewall stack are perfectly mirroring each other. That would be trivial with IPv4-with-more-bytes, it's a nightmare with IPv6.
> I would now have to make sure my IPv4 and IPv6 firewall stack are perfectly mirroring each other.
You'd still have that in your IPv4-with-more-bytes, as you'll still probably end up running dual-stack to address those old-v4-only sites. Or you'd do the same with v6 and run a tunnel to translate those v4-only addresses to your v4-with-more-bytes. So you're in the same situation either way.
There were backwards-compatible protocols proposed, such as EIP, but the committee chose a backwards-incompatible protocol for v6. Their assumption was that v4 would run out of space in a single-digit number of years and everyone would be forced to migrate. The past 30 years have shown that not to be the case.
They went with SIPP, which was one of the backwards-compatible options. It should be kind of obvious from the vast number of backwards compatibility methods available in v6 that v6 is actually backwards compatible... but for some reason a lot of people either refuse to believe this or have double standards around what counts as compatibility.
That's what IPv6 is. People get so fixated on being annoyed at IPv6 they forget to actually think. Whatever you invent won't be any better than IPv6. Many people have tried.
If you change the address format even the tiniest amount, if you add one single additional bit, your new protocol is already completely incompatible with all existing IPv4 software and equipment.
Corporate IT networks have less IPv6 and residential/mobile networks have more IPv6, so on weekdays when people are using Internet at work = more IPv4, weekends when people are using Internet at home = more IPv6. Christmas also has a big bump for the same reason.
There really should have been proper government pressure and fines long ago.
Say if you have 10% of market share or x million monthly users you must support IPv6 in say 5 years. If not you are fined say 2% revenue per year until you do...
I'd make it required that ipv6 for all customers has a higher service guarentee than anyone ipv4. If you don't support ipv6 you can't guarentee anything. give two years to to implement it.
Backward compatibility was never really the problem; the problem is that forward compatibility with ANY successor protocol (without modifying IPv4) is a fundamental impossibility.
But at least a reasonable facsimile eventually came out with NAT64.
(You can also do NAT46, but it requires one IPv4 address for every IPv6 destination you want to be reachable from the IPv4 Internet, so it doesn't scale very well.)
One of the foremost obstacles to wide adoption is that IPv4 still works great and it's ubiquitous. There is no advantage or up-side to deprecating or abandoning IPv4 support at all. The only result of disabling IPv4 is a denial of service to a certain sector of customers or clients.
The only way this will change is by increasing pressure on the resource of IPv4 networks. It was a few years ago that AWS broke the news to me that I'd be paying for IPv4 addresses but IPv6 would remain free. If enough services are forced, financially, to abandon an IPv4 presence, then their clients would be likewise forced to adopt IPv6 in order to retain connectivity.
But with the ubiquity of CGNAT and other technologies, it seems unrealistic that IPv4 will become so rare that it becomes prohibitively expensive, or must be widely abandoned. So that availability of the legacy protocol will inhibit widespread adoption and transitions to IPv6.
Yeah the reality is that the Internet is centralized now. There is no reason for two computers on the internet to connect to each other anymore, as long as you can reach Google/Microsoft/Amazon/CloudFlare, that's all anyone needs.
Just log onto AOL and type in keyword "WALMART" and save! It's friendly and safe.
In theory you can save quite a bit on AWS costs by having instances that can only use v6.
But in reality at the moment there will probably always be at least one thing that only works with v4 a lot of the time.
Incentives are misaligned as well - it saves you money as the EC2 instance user, but the owner of the website you're trying to access has to support v4 anyway so they don't have a big incentive to change anything
I know, I'm just agreeing there's a ton of IP waste in the US. Early adopters were perhaps unjustly rewarded. InterNIC (before ARIN) would just about hand out IPs to anyone who could send an email.
During the dot-com crash I had to put a /16, some /17's and a /19 on one vlan and connected a 1U Linux box running Labrea Tarpit just so those ranges would respond to ping because InterNIC used to harass us for not utilizing all the space. They threatened a few times to take them back. AFAIK nobody nags like that any more. They probably should.
I recently released a /24 that I registered in 1992 and I hadn’t realized it was still mine.
ARIN was gonna charge me $100 to authenticate and recover the account, but once I asserted and notarized my letter of relinquishment, the process went real quick!
When ipv6 threads like this come up, someone eventually mentions T-Mobile is completely IPv6 now but they must have IPv4 tunnels because I have IPv4 turned off on my modem/router and can still visit both those URLS
Not dumb. It's not exactly a tunnel, it's a double sided conversion.
Basically to reach any v4-only resource you need a translator, typically NAT64. This maps the entirety of the v4 internet into a /96 of IPv6 space (last 32 bits).
DNS64 is one way to access this, which will return a result for 'amazon.com' like:
A = `98.87.170.74`
AAAA = `64:ff9b::6257:aa4a`
Combining this with CLAT lets you punch in an IPv4 literal like 1.1.1.1 and your phone/computer will do this conversion from v4 -> v6 locally without you changing anything. So 1.1.1.1 would become `64:ff9b::101:101` on-device - and that's actually what your mobile ISP sees.
T-Mobile and most mobile operators use 464XLAT - which has been in Android & iOS for at least 8-10 years now if memory serves.
It lets you visit 1.1.1.1 because your phone is converting it automatically to T-Mobile's NAT64 prefix (CLAT - customer side), it traverses their network v6-only, and then it ends up at their translator (PLAT - provider side) and becomes normal NAT'ed v4 traffic out to CloudFlare.
Not the one down-voting you but I suspect IPv4 and IPv6 will run side-by-side dual-stack at least until 2050 and IPv4 would not be fully deprecated until probably 2323 star-date 0 as future quantum interstellar communications subspace will deprecate both standards. Only half kidding as nothing ever gets deprecated or decommissioned until it breaks something important.
It’s amazing to see this finally hit 50%. Out of curiosity for the infrastructure folks here: are you actually running IPv6 inside your internal VPCs and Kubernetes clusters now, or are you still mostly just terminating it at the edge/load balancer level?
At home, I use an Android 16 Pixel phone, and a Chromebook, and I would suspect (but cannot prove) that 100% of my LAN outages can be blamed on the dual-stacking nature of IPv6 plus IPv4.
Google has some weird way of asserting connectivity, and I suspect that when connectivity on one protocol is lost, it is impossible to maintain or establish connectivity through the other one (IPv6) even if it is available upstream.
I am rather infuriated with the status quo at this point, because it is impossible to disable IPv6 on my devices and it is also impossible for my ISP to disable IPv6 on my LAN or on the CPE router which they own and control.
Due to chronic WiFi issues I was eventually forced to place my ISP router into Bridge mode permanently, and I use a 3rd party Netgear which I own, and does not have the same WiFi issues, and where IPv6 is optional (and often fails, because its implementation is buggy and glitchy for no reason.)
I recently purchased a brand-new LaserJet printer, and since it needs nothing to do with the Internet or a WAN outside my home, I thought it'd be great to simply disable IPv4 and stop doing the DHCP dance.
Well it immediately fell off the net completely. I couldn't figure out how to expose its IPv6 address or contact its management interface.
Hypothetically, Bonjour and mDNS should make this a no-brainer. Hypothetically, disabling IPv4 shouldn't even prevent it from connecting to the Internet. But I was ultimately forced to factory-reset it.
IPv6-only LAN makes a lot of sense for most people, and perhaps reduces attack surface a little. If you have the means, I highly recommend setting it up!
::203.0.113.42 (tunnels to 203.0.113.42 over v4)
64:ff9b::203.0.113.42 (translates to v4 at nearest NAT64 point)
::ffff:203.0.113.42 (opens a v4 connection via an AF_INET6 socket)
Maybe you didn't read the draft. It's either a delayed April's Fool joke or AI slop. Even if you take it seriously, it will require updating every v4 device in existence.
Having read that thread, I guess one of the small upsides of the world I live in is that "FIFA Peace Prize" is now available as a joke award reference. FIFA really hit it out of the park there in a way that even their normal legendary levels of corruption couldn't imagine.
Edited: In hindsight I notice that "hit it out of the park" is the wrong sport metaphor for FIFA, but I stand by it anyway.
> Edited: In hindsight I notice that "hit it out of the park" is the wrong sport metaphor for FIFA, but I stand by it anyway.
For future reference, you can use: "knocked it into the top corner", "put it in the back of the net" or "smashed it past the keeper". Not a native football-talker, but hang out too much with a few.
"Back of the net" doesn't feel the same to me even though (I learn after reading far too much about a sport I do not play) "Out of the park" is basically the same thing.
In my mind "out of the park" had meant the ball leaves the actual stadium but in fact (I read) "the park" in this context is actually the field of play and so "out of the park" represents in fact the vast majority of home runs and not the over-achievement I had imagined.
True, "back of the net" is more "someone kicked the ball really hard and it hit the back of the net really hard" instead of "the ball came across the goal line" which can be very different, so in my mind that's as close to "out of the park" as you can get in soccer :)
Might as well go big. 24 extra bytes per packet is not that big deal. And having that much extra space means you can screw up design multiple times and still be able to reuse lot of infra. Also getting rid of idea that you are even trying to manually manage the address space eases many things.
But it's not human readable anymore, nor backwards compatible. The expectation was that the industry is reasonable, but it proved to be as hard as it would be to push breaking email v2 implementation.
If you think v6 isn't backwards compatible then literally anything bigger than 32 bits will never count as backwards compatible for you. The whole point of making the address space bigger is to make it bigger, so what do you expect to achieve by complaining that the result is incompatible?
As a human, I've found that e.g. "fd00::53" is perfectly readable to me, and most of the time you're interacting with strings like "news.ycombinator.com" anyway which is identical to how it works in v4, so I'm not sure how far I'd agree with that part either.
This means there are always 32 octets to a reverse-IPv6 address, and there are no shortcuts or macros to overcome this! That means if you wish to assign a singular name that maps from a legitimate /64 Network ID, you must populate 64 bits worth of octets in a zone with this data. It is an absurd non-solution. This never should've been allowed to happen, but it will basically mean that ISPs abandon reverse DNS entirely when they migrate to IPv6 implementations.
$ dig -x 2606:7100:1:67::26 | grep PTR
;6.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.6.0.0.1.0.0.0.0.0.1.7.6.0.6.2.ip6.arpa. IN PTR
Run this, then copy/paste the output into your zone file. Remove the ; and add "example.com." or whatever to the end.
I agree it's a pain to read, mostly because DNS addresses are written backwards, but an "absurd non-solution"? For a set of instructions that don't even depend on the format of the record (they work for v4 too), and which I could describe in one line in a HN comment?
If this is the craziest part of v6 then it must be incredibly well designed overall.
It is a pretty nice design, partly as a result of the fact that we've got a working system to look at (IPv4) and we have a lot more eyeballs "these days" (when IPv6 was designed, so, decades ago now) than when the Internet Protocol was a new idea.
I think perhaps the person you're responding to imagines that somehow DNS mandates a very naive implementation and so this behaviour would be incredibly expensive. The sort of person who sees a flip clock and imagines it needs 1440 different faces not 84 (or in some cases 72) because they haven't realised 12:34 and 12:35 simply use the same hour face.
“copy paste the output” is your solution? You think this somehow scales to manage entire networks like this with dynamic addressing? Do you perceive a network admin as a monkey who copy-pastes things all day?
This is exactly the absurd non-solution I am referring to, and it seems like if someone dismisses this with “one line instruction is all u need lol” they cannot even comprehend the scale at which real life operates.
Copying and pasting was just my attempt to demonstrate how simple a v6 rDNS record is to add. If you were interested in hiring me to write a solution for your ISP, that's fine, but you can't seriously expect random people to do it for you for free in a HN comment.
It should be pretty obvious that a script can generate these records from the forward records or from any other source of IPs/hosts, with no per-address effort needed on the part of the network admins.
Again, absolutely blind to the management of these things at scale. Yeah, I don't rightly care about "how easy it is" to generate them. You can't even comprehend or convey the massive number of records and zones that are involved in managing a network of devices that all require dynamic updates to reverse-DNS and add/update/remove device addresses on a regular basis.
DNS is a distributed database system, and so the challenge is not cramming in data with a brainless script, but managing how that data is distributed and accessed by thousands or millions of peer servers, caches, and clients worldwide.
IPv4 reverse-DNS was quite simple when it was broken on octet boundaries and there were only four of those boundaries in total. But even then, ISPs could often not be arsed to put the right data in there. Some left it blank and some waited until they were forced, by strict requirements that said reverse must match forward DNS in many cases.
I have never found any user-accessible software, not on any Linux distribution or on any cloud service, that would permit an ordinary consumer to manage even a /24 IPv4 network's reverse-DNS at scale, or programmatically, as opposed to by-hand "copy paste" as has been so condescendingly suggested here. There are plenty of hosted DNS providers, and there are plenty of monkey-brain Dashboard interfaces where you can pound out one A record at a time. But there was nothing to deal with dynamic addressing or DNS databases at scale. That's why IPv6's reverse DNS remains an absurd non-solution.
So... how many records and zones? I'm pretty sure I could convey it if I could work out what you were talking about.
You went from "you can't even comprehend or convey the massive number of records and zones that are involved" to one v4 /24, managed "at scale" but by an ordinary consumer, who you expect to be capable of programming. This is a bit all over the place.
It's not any harder to deal with v6 reverse DNS than it is v4. In fact, making every reverse label 4 bits instead of 8, combined with v6 being much bigger than v4, makes rDNS much easier to deal with in v6 because you can generally delegate reverse zones on exactly the same boundaries that you delegate the corresponding IP blocks. In v4, you often need to delegate on boundaries that aren't /8, /16 and /24 and it suddenly gets more annoying.
Scaling up for rDNS is no different to scaling up for forward DNS. It's a well-understood problem.
Anyone who's ever had to delegate DNS authority on anything other than an 8-bit boundary can understand the value of that feature.
At face value, yeah, that's replacing "8" with "4," but from a practical perspective, delegating authority for a customer IPv4 /25 requires, at minimum, 128 records. (Granted, there's also no practical need to be stingy about IPv6 allocations -- that IPv4 /25 customer could simply receive an IPv6 /48.)
I would firmly expect to see a lot more formulaic reverse (and presumably forward) DNS responses, where needed, since filling files with records you need to store on disk (and in memory) doesn't scale well. The tech has existed for years; I wrote my own implementation years ago, but these days I'd use something like PowerDNS with https://github.com/wttw/regexdns .
If anyone is confused on adoption is so slow when supporting it is easier than ever the reason is actually quite simple: it's expensive.
Switches and routers have a little thing called TCAM memory, the premise behind it is that it allows you to single-cycle O(1) lookup any ips destination. Usually to replicate it you could have a 4gb*2 preallocated contiguous buffer, but that's not something that is wildly supported or used and this completely breaks down when you expand to the IPv6 range.
The problem lies in that in a lot of cases TCAM can no longer hold the entire IPv4 routing table and now if you introduce IPv6 you are expected to handle double the routes which degrades switching performance as more active routes have to be evicted and fall back to software routing.
Routes are not the only thing that take up TCAM memory: the firewall rules, internal routing, vlans, everything becomes double and TCAM memory cannot be dynamically adjusted at runtime to allocate space so what happens is that you need to sacrifice IPv4 space in TCAM permenantly even if nobody is using IPv6.
This is where it gets worse: if you have ever attempted to use IPv6 you will notice that is significantly slower than IPv4 and that is because most ISPs simply opted to use software routing for IPv6 which coupled with 4-10 hops is nearly double the latency in some cases (0.5ms to 1ms) while having throttled bandwidth to not overload the CPU.
That's why network engineers will continue to refuse to (properly) support IPv6. If I had to guess the "properly" supported IPv6 percentage is less than 10%.
> if you have ever attempted to use IPv6 you will notice that is significantly slower than IPv4
The link in the OP shows that IPv6 typically gives users 10-20ms lower latency. This confers with my experience since IPv4 is typically going through some poor overloaded CGNAT box.
What shitty ISP operates like that? I frequently see IPv6 have *lower* latency because of fewer middle boxes and fewer hops in general. Your routers in the default free zone shouldn't be close to their TCAM limits with a single IPv4 routing table.
And still, in the year of our lord 2026, GitHub does not support IPv6.
https://github.com/orgs/community/discussions/10539
A non-trivial minority of the time, they don't support IPv4 either!
GitHub is at the point where it immediately rate limits me if I try to look at a project's commit history without being logged in, as in the first time I even open a single URL to the commit history, I get "Too Many Requests" from GitHub thrown at me. I don't know if my work's antivirus stack is causing GitHub to be suspicious of me, but it's definitely egregious.
It’s not you or your setup. I experience the same behavior. Tried with and without Private Relay, residential and commercial ISPs at different locations, and more to debug it. Same results.
I think GitHub has just gotten so aggressive with their rate limit policies that it’s straight up incompatible with their own product. The charitable interpretation is that they aren’t keeping good track of how many requests each page actually performs in order to calibrate rate limiting.
If you didn't specifically test without it, I'd attribute that to cgnat
On the other side of the coin, they also punish people who have slow connections. The acceptable speed for downloading from github on my connection is 90k/sec. No more, no less. Something prevents the rate from being higher (probably Github), and if the rate drops any lower for any length of time, the connection will suddenly abort right in the middle of the download. Since the dumpster fire that is git doesn't support resume, welcome to hell. If I didn't have a fast server elsewhere to git to then zip up and re-download, I'd be screwed.
My theory is that they rate limit that URL aggressively due to AI scrapers. At this point it's faster to just clone the repo and do your searching locally.
Your work is probably all exiting through the same IP, you competing with others on the same IP is causing the rate limit.
The very same thing happen on my residential connection, I can do one search query, then I'm rate limited for 15+ minutes, same if I access any list of commits.
I've considered this, but the company is small enough that the number of people who would be on GitHub at any moment (instead of our internal git forge) can be counted on one hand, and when I'm the first one there in the morning it still rate limits me.
Do you have any on-prem cicd jobs that access github? Our's kept failing, had to move over to the ECR release of some stuff.
Maybe your company's ISP is CGNat'ting you?
Hm, I've also noticed sites being more aggressive about verifications after I started using LLMs locally. They think I'm a bot (which... fair), even on completely unrelated sites I seem to be getting prompted for human verification much more often.
May explain the ipv6 resistance. Hard to do effective per-ip rate-limiting with v6.
I don't understand, wouldn't it make it easier?
No, IPv6 as it is supposed to be implemented gives (say) a single server a /64, which is for all intents and purposes an inexhaustible supply of IPs. You could in principle have an IP per site you visit and have plenty left to spare.
Random Google result with a bit more:
https://www.captaindns.com/en/blog/ipv6-subnet-sizes-48-vs-5...
So if I wanted to annoy GitHub, I could connect to them without ever using the same IP twice. Their response would have to be banning my /64, or possibly /56.
> No, IPv6 as it is supposed to be implemented gives (say) a single server a /64, which is for all intents and purposes an inexhaustible supply of IPs. You could in principle have an IP per site you visit and have plenty left to spare.
No, as it's supposed to be implemented a single internet-routable /64 is used per *network* and then most devices are expected to assign themselves a single address within that network using SLAAC.
ISPs are then expected to provide each connected *site* with at least a /56 and in some cases a /48 so the site's admins can then split that apart in to /64s for whatever networks they may have running at the site. That said, I'm on AT&T fiber and I am allocated a /60 instead, which IMO is still plenty for a home internet connection because even the most insane homelab setups are rarely going to need more than 16 subnets.
> So if I wanted to annoy GitHub, I could connect to them without ever using the same IP twice. Their response would have to be banning my /64, or possibly /56.
Well yeah, but it's not like it's exactly rocket science to implement any sorts of IP rate limiting or blocking at the subnet level instead of individual IP. For those purposes you can basically assume that a v6 /64 is equivalent to a v4 /32. A /56 is more or less comparable to /25 through /29 block assignments from a normal ISP, and a /48 is comparable to a /24 as the smallest network that can be advertised in the global routing tables.
Its not harder to rate limit a /64 though.
It is because the IPv6 rollout has not been consistent. Some assign /64 per machine, some assign /64 per data center. Some even go the other way and do a /56 per machine. We've had to build up a list of overrides to do some ranges by /64 and others by /128 because of how they allocate addresses. This creates extra burden on server operators and it's not surprising that some just choose not to deal with it.
This problem exists for ipv4 too: some machines have static address, others have dynamic, so you can implement overrides.
Ipv6 is cheap though. If I want to get past your IP or per Network limit, options abound.
What can you do to get a new IPv6 network that is easier than getting a new IPv4?
Stuff like bouncing a modem, getting a new VPS, making a VPN connection I would expect to be pretty similar. And getting a block officially allocated to you is a lot of work.
If you allocate a dedicated spam network, it will make spam easy to detect and block.
Why are we pretending that you are checking logs and adding firewall rules manually. Anything worth ddosing is going to have automatic systems that take care of this. If not put an ai agent on it.
should we try going back to IPX ?
IPX/SPX is datagram only. BUT it would be an opportunity to build a QUIC-like that runs over it :-)
Comically IPv6 now has almost all the neat stuff IPX did. There probably is an argument for more datagram centric networking these days as the underlying services are generally much faster and more reliable and there is so much more session tracking going on at higher application layers anyway.
Only if we're bringing back Token Ring, too.
That might be challenging, I hear people are pretty short on tokens these days.
There's only one token! It's just very popular.
While we're at what about older physical layers? Coaxial based stuff seems cool in 2026
Isn’t that what MoCa is for?
Isn’t twinax just “I heard you like coax so I put coax in your coax.”
twinax I think is used more like a balanced line with shielding. Twisted pair is preferred because it is cheaper, but for short stuff like SATA the cost difference is so low it might as well be used
If it’s not 10BaseT I can’t see small spread adoption.
Arcnet for me.
I remember removing the IPX route entries from our Cat65 MSFC back in 2006 and from the ATM/Framerelay WAN Equipment. Wasn't very popular with the customers.
I also remember the first IPv6 Workshop on W2k SP3 back in 2002. Not that long ago.
I've used IPX exactly once in my life, playing Diablo over modems calling my dorm neighbor to establish the connection (in 2005).
IPv1, IPv2, and IPv3 were very early experimental versions of the Internet Protocol developed in the 1970s during the ARPANET era (the precursor to the modern internet). Has anyone tried to find out if GitHub is reliable on those?
What? One nine isn’t good enough for you?
Excuse me. Zero nines. Or two nines if you relax your definition of where they are in the number. https://infosec.exchange/@0xabad1dea/116334321751266751
Excuse me, but I see 4 nines. 95 incidents in last 90 days, 89.91% uptime.
we shut down our production every day from 2pm till 5pm for a siesta :)
You jest... (but probably not!)
I remember when I was first using my alma mater's online sign up for classes in the very early 2000s, their class sign up site had office hours.
You guys have nines?
You must be from Anthropic
the ghost of twitter's past
Personally I’d look for the coveted 5 eights uptime.
66.6% uptime anyone?
Only if it's Australia.
Still better than five eighths.
As long as it is after the decimal separator I can try for that...
> And still, in the year of our lord 2026, GitHub does not support IPv6.
Especially given that it is now owned by Microsoft, which has been working on IPv6-only (at least on their corporate network) for almost a decade:
* https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/
* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...
I mean Azure doesn't really support IPv6 well either for a lot of the big-ticket services.
More importantly, it doesn’t support uptime well.
we could meet in the middle: Azure support IPv6 with 0% uptime
That seems weird given NIST, and the US Government, set a requirement for IPv6 Only back several years ago, and it sort-of became part of the JWCC requirements (It wasn't in the requirements, IIRC, because it came after those were set, but the government wouldn't fully approve use for JWCC if you didn't meet it).
You'd think they'd have sprinted for that feature as fast as they could go.
Microsoft gets special treatment.
USG also set a whole bunch of security requirements under FedRAMP that Microsoft can never meet, but they received an ATO anyway because they are so heavily entrenched in government.
Same with Twilio. We have an internal server that does system alerts. We recently moved it to an IPv6 only host, and a few weeks went by and noticed there were no longer receiving alerts.
Turns out we could not connect to Twilio's API which is IPv4 only.
So zero validation after that change?
Couldn't tell you. I'm not part of the infrastructure team. I wasn't even aware the alerting service was moving.
QA found it a couple weeks later when they were testing alerting, and SMSes weren't coming through.
Zero observability and alerting too. Seems like they’re planning to be a productive future member of that team.
Who? The infrastructure team that did the move didn't even tell anyone. They were decommissioning old servers, and moving the VMs to new hardware. I'm just a lowly developer that had to troubleshoot why SMSes stopped going out.
Observability and alerting is pretty standard devops. Both the dev and infrastructure teams dropped the ball here. But at least as part of remediating this you added alerting to make sure you’d notice when your twillio connection fails in the future, right?
Even better, infrastructure enabled IPv6, and the issue was closed.
In corporate software development, we work the tickets assigned, and keep our KPIs up so that we don't face the wrath of the bean counters.
They supported IPv6 for a short time, but then stopped their experiment.
An excellent reason to move away from Github, I find.
I've been there. Management was fine with the testing but it added too much overhead for nearly no benefit to us.
One more thing to troubleshoot at 3 am, one more thing to teach to a disinterested tier 1 support team, one more thing for Chrome to be weird about, hundreds more rules to manage in a hostile load balancer, logging tools that don't understand ipv6.
Turned it off. End customer asked why the site got a little slower (CGN) and when we can turn ipv6 back on. As far as I know it's still on the backlog.
One of the big challenges with IPv6 remains that many of the knows-just-enough-about-networking people, like support staff, often never received any IPv6 training (or, for that matter, even enough IPv4 training that they don't need to Google things that come up in real life). Another is that the weird, awful, everyone-hostile corporate "solutions" often break IPv6 in stupid ways (like load balancers and logging tools being unable to cope with minor changes and requiring a full configuration rework).
Things have definitely gotten better over time, though. The massive 90s style corporate networks will probably never transition, but smaller and more modern companies don't have that issue.
Apple mandating that apps are IPv6 compatible and various government legislation forcing companies to make their shitty middleware IPv6-compatible has improved things quite a bit so far. As uptake keeps rising, the need for technologies like STUN and TURN will slowly start decreasing, and as a result more and more people will end up in "untested" situations where not having IPv6 and falling back to legacy paths starts becoming a problem.
A networking dude (he clutched his smartphone all the time) typed "spedtes" in my browser and was deeply confused when the server wasn't found. He tried several times more with slightly different spelling to the same effect, he literally couldn't even what went wrong.
Here's an example of a potential security hole caused by lack of ipv6 knowledge:
I've been setting up Snapcast (open-source multi-room audio), and needed to move the server to a different machine. While I was setting up the new system, I told it to only bind to localhost. Somehow this only affects the ipv4 networking stack, as some of my clients started automatically connecting to the new server even before I had finished all my testing.
Turns out that it was advertising some kind of ipv6 link-local address that showed up in autodiscovery. In my case there wasn't any harm, but this type of thing could very easily result in a major security vulnerability.
I don't see how this generalizes into a security hole caused be lack of IPv6 knowledge. It just sounds like a random bug in Snapcast (great program!). If a user configures a program to only bind to loopback, but the program binds to other interfaces as well, that's a bug in the program.
There are sure to be dozens or hundreds of vulnerabilities like this, that's what I'm saying. I'm not even sure it's a bug in snapcast - very possible I configured it wrong without realizing.
Without knowing exactly what happened here, it could be hundreds, dozens, or zero other such vulnerabilities.
The usual convention for configuring listening interfaces usually involves listing IP addresses or interface names. There's very little room for misconfiguration here, although it's possible. More likely to be a bug in Snapcast (it's almost certainly not an issue in the Linux kernel).
Moreover, this general problem (i.e. configuring listening interfaces) is not/should not be different between IPv4 and IPv6. So introducing IPv6 should not™ incur any additional risk at this level.
But as said, it's hard to get more concrete without knowing exactly what happened in your case.
Localhost doesn't appear on autodiscovery. Whatever you ran into had nothing to do with IPv6, but rather with your application not binding to the address you were telling it to bind to. On IPv6, localhost binds to ::1, not anything reachable by any other address. Furthermore, whatever you set up automatically seems to have added itself to your server's firewall, which is equally troubling.
The address my clients were finding automatically was a link-local address (fe80...). Can't say exactly what happened but it was very surprising since I didn't even know these addresses existed.
I'm sure it's totally my fault but that's the point: folks who know how ipv4 works may have huge blind spots for ipv6.
Facebook is (AIUI) 100% IPv6-only on their internal network, and has been for many years:
* https://engineering.fb.com/2017/01/17/production-engineering...
* https://www.internetsociety.org/blog/2014/09/facebook-launch...
IPv4 is actually the "leftover" stuff they have to deal with at the front end.
But they are an eye-balls heavy service, with a lot of mobile devices, which also tend to be IPv6-native.
It also just takes actual policy will. Somebody has to actually say "No" when the supplier who promised an IPv6 product says afterwards actually they meant IPv6 "ready" and they should have put an asterisk because really only the next version will be "ready", and er, so the product they've delivered doesn't actually work with IPv6 but that's fine right?
"No". Not every human is psychologically prepared to do that. They want to acquiesce, to go along to get along, you need somebody to be firm. "No".
I have found that it is incredibly satisfying to whip out the “no” card.
I have also found that an uncomfortable number of people do not consider it appropriate in any way shape or form. Even when it’s ultimately your call and no one else’s.
Folks don’t really like waves. They like looking at them from the shore, but freak out when it’s their turn to hang 10
Suppliers doing that kind of trick is what really killed GOSIP, and why the new v6 mandates in USGOV do not allow waivers for vendors, only for individual specific use cases
Just wait until someone starts remembering the other archaic terms like ‘fraud’, ‘indictment’, etc.
From my time there, this is for the internal prod network. Corporate networking was dual stack (which was pretty useful because it was common for v4 or v6 to break, but usually not at the same time)
That's why ipv6 migration should be government mandated. Then it becomes just the cost of doing business
Our university has bad problems with ipv4. Every few days you'll notice some websites being unreachable, including github. Although with their uptime recently, you never know who's to blame...
Just found this little site. https://isgithubipv6.web.app/
Maybe we shouldn't even measure percentage adoption and instead just if github has finally adopted..
Kinda sorta.
github.com doesn’t have an IPv6 address.
github.io does have an IPv6 address. Indeed, one workaround for getting rate limited when using a carrier NAT with github.com is to have a github.io page and pull data from github.io instead of github.com.
Edit: About a decade ago, all of my hosting had full IPv6 support, and I tried to move over to IPv6. However, there was an issue with Letsencrypt certs not validating over IPv6, so I made my web pages IPv4 only. Recently, I gave IPv6 a go again, and the cert issue has been fixed, so now my webpages finally have both IPv4 and IPv6 addresses.
>github.io does have an IPv6 address
Are you sure? I don't see it.
Name: github.io
Addresses: 185.199.111.153 185.199.110.153 185.199.108.153 185.199.109.153
github.io doesn’t have an IPv6 address. {name}.github.io does, e.g. mats-winther.github.io resolves to 2606:50c0:8001::153:
GitHub should absolutely support IPv6, but until then... transip.eu provide IPv6 addresses which transparently proxy to github.com: https://www.transip.eu/knowledgebase/5277-using-transip-gith...
You'll need to update your DNS server to include those as AAAA records.
Do providers like NextDNS or RethinkDNS allow these sorts of overrides?
>The Github IPv6 Proxy can only be used for traffic to Github using a VPS from TransIP which uses IPv6.
Good spot. Sorry to disappoint!
rdns dev here
> Do providers like NextDNS or RethinkDNS allow these sorts of overrides
Not on the resolver, but on the Android client (Rethink DNS + Firewall) we do (if enabled) manipulate DNS answers to implement an opportunistic 464xlat (over Kasper Dupont's public relays [0]).
[0] https://github.com/celzero/firestack/blob/c10c155464e0d4a81a...
At least HN supports IPv6 now, which I remember was not the case last time I checked.
Do we know any technical reason for this? Or are we left to think this is somehow a political thing?
Perhaps a little tin foil hatty and definitely not the only reason but Microsoft owns Github and also makes a boatload of money off of Azure. Incumbent cloud providers like Azure have a major advantage in terms of having plenty of IPv4 addressing available whereas a new entrant to that market would have to buy or lease that space at a premium. Thus, these companies have an incentive to keep IPv4 a necessity.
IPv4 is going to be a necessity for many many decades no matter what Microsoft do. Even when IPv6 is at 99%, people aren't going to want 1 in every 100 people to not be able to access their site at all. It'll need to be like 99.9% before we start seeing serious IPv6-only services.
I don't know what the percentage would be, but we do have some historical precedent that could give us a clue.
Best one I can think of is when bigger websites started actually dropping SSLv3 and TLSv1.0 (and later TLSv1.1) support, cutting off older browsers and operating systems. Google and Amazon still support TLSv1.0, but plenty of others (including Microsoft) have dropped 1.0 and 1.1. HN itself doesn't accept 1.1 anymore either.
Then there's browser support. Lots of websites - big and small - cut off support for Internet Explorer 6 when it was somewhere below 5% marketshare because the juice was no longer worth the squeeze. Of course, few of those actually fully cut off the ability to browse the (now broken) website fully but it's a datapoint suggesting trade-offs can and will be made for this sort of thing. Or to put it in the present: a significant amount of webapps don't support Firefox (3% market share) to the extent their product is completely unusable in it.
a browser you at least have the ability to change though. if your ISP doesn't offer v6 you're SOL really
ISPs almost all offer IPv6. The reason the US number is not higher is lazy corporate networks.
That depends on the country though. Southern Europe is way behind in terms of IPv6 adoption even by ISPs
Meanwhile big gaming companies when Linux users are 5% of Steam users: 'eff off'.
Sure, but the implementation in the public clouds is totally backwards.
What they should have done is have their core network default to IPv6 with IPv4 an optional add-on for things like public IP addresses, CDN endpoints, edge routers, VPNs, etc...
Instead, their core networks are IPv4 only for the most part with IPv6 a distant afterthought.
IPv6 is the protocol of the future. And will be so.
I don't buy that. Do Netflix or YouTube care that people on 56k can't use their service?
Outdated beliefs probably. When I talk about v6 support in our b2b saas, PM laughs and says nobody uses that shit. Big tech are massive laggards on this funnily enough.
> Outdated beliefs probably. When I talk about v6 support in our b2b saas, PM laughs and says nobody uses that shit.
Nobody except the 140M subscribers on T-Mobile US's network:
* https://www.youtube.com/watch?v=d6oBCYHzrTA
But sure, be IPv4-only and add latency by forcing traffic through an extra translation box.
Definitely not for the biggest ones. Google and Meta have so many machines in their data centers that IPv6 addressing becomes a technical necessity due to the risk of exhausting the RFC 1918 address space. Naturally, they were early adopters of IPv6.
Yeah, I can't imagine managing fleets like that with only v4. Our network config is so convoluted with gateways and NATs everywhere, paying AWS through the nose for it all, when it could all be so much simpler.
It's because big tech is USA based mostly, where there's still a glut of ipv4 available.
IPv4 was exhausted at ARIN in 2011. Last time I bought a /24 on the open market, it was around $6k. I assume it is much more, now.
It's close to that right now. Prices more than doubled as covid set in, then dropped back down to about where they were before.
Where can I get it, asking for a friend?
Well it’s over 50%…
It's a possibly a managerial thing, which KPI are you improving when spending engineering time on adding IPv6 support?
That said, for their HTTP stack they use fastly (as far as I understand), which should make the shift moderately easier.
IPv6 is very difficult to implement and enforce reliable rate limits on anonymous traffic. This is something we've struggled a lot with - there is no consistent implementation or standard when it comes to assigning of IPv6 addresses. sometimes a machine gets a full /64, other times a whole data center uses a full /64. So then we need to try and build knowledge of what level to block based on which IP range and for some it's just not worth the hassle.
Well, even if there was a standard, that's still not a guarantee that the other side of the /64 would be following it. It's correct for you to rate-limit the whole /64.
... But that's no different from IPv4. Sometimes you have one per user, sometimes there are ~1000 users per IP.
Most of the ipv4 world is now behind CGNAT, one user per ip is simply a wrong assumption.
Anonymous rate limits for us are skewed towards preventing abusive behavior. Most users do not have a problem, even there is a CGNAT on IPv4.
For IPv6, if we block on /128 and a single machine gets /64, a malicious user has near infinite IPs. In the case of Linode and others that do /64 for a whole data center, it's easy to rate limit the whole thing.
Wrong assumption or not, it is an issue that is made worse by IPv6
I don't doubt your experience, but I wouldn't expect it to continue. I don't think Tuna-Fish is correct that "most" of the IPv4 world is behind CGNAT, but that does appear to be the trend. You can't even assume hosting providers give their subscribers their own IPv4 addresses anymore. On the other hand, there's a chance providers like Linode will eventually wise up and start giving subscribers their own /64 - there are certainly enough IPv6 addresses available for that, unlike with IPv4.
> I don't think Tuna-Fish is correct that "most" of the IPv4 world is behind CGNAT
~60%+ of internet traffic is mobile, which is ~100% behind CGNAT.
On desktop, only ~20% of US and European web traffic uses CGNAT, but in China that number is ~80%, in India ~70% and varies among African countries but is typically well over 70%, with it being essentially universal in some countries.
Overall, something a bit over 80% of all ipv4 traffic worldwide currently uses CGNAT. It's just distributed very unevenly, with US and European consumers enjoying high IP allocations for historical reasons, and the rest of the world making do with what they have.
Oh wow, thanks for those numbers!
Since mmbleh mentioned Linode I'm guessing they're more concerned with traffic from servers, where CGNAT is uncommon. But even that may be changing - https://blog.exe.dev/ssh-host-header
Yeah, our traffic is more from automated systems/servers, nothing from mobile
Yeah, absolutely no expectations for the future. My point was more that while there may be clear benefits for users, IPv6 presents real problems for service operators with no clear solutions in sight.
Given that GitHub also offers free services for anonymous users, I can imagine they face similar problems. The easiest move is simply to just not bother, and I can't blame them for it.
If a single machine gets /64 and you rate limit by /64, what doesn't work?
>Linode and others that do /64 for a whole data center
That's how it's supposed to work.
> That's how it's supposed to work.
According to who?
It could fit best practices if your datacenter has one tenant and they want to put the entire thing on a single subnet? In general I would expect a datacenter to get something like a /48 minimum. Even home connections are supposed to get more than /64 allocated.
And Linode's default setup only gives each server a single /128. That's not how it's supposed to work. But you can request /64 or /56.
If the OS uses SLAAC by default, then it will just work, but SLAAC is for humans and makes less sense for web servers (yet can make sense for vpn servers). For web servers /128 is more meaningful.
It could be that they don't want to implement IP bans in IPv6.
How does IP bans work in IPv6 case? One just blocks whole /64 or /56 address range?
I have not had a deal with this, but if I was going to, I would start at the /64 and move up by nibble (4-bit) boundaries: /64, /60, /56, /52, /48.
/56 is often recommended as the minimum as for a (residential) customer. /48 is considered a "site" address prefix, and is the smallest allocation that can be advertised in BGP:
* https://blog.apnic.net/2020/06/01/why-is-a-48-the-recommende...
* https://www.infoblox.com/blog/ipv6-coe/a-48-for-every-site-a...
You get 65k subnets with it, which is what you get with 10/8.
Yes, /64 is a reasonable starting point for blocking outright, but /48 is the right unit for scoring reputation.
APNIC blog says /48 prefixes are for global routing, i.e. site=country there, not web server.
>/48 is the minimum prefix size that will be routed globally in the BGP.
I'm not sure if I'm misreading you, but a /48 would never be an entire country's v6 allocation.
If we're talking home networks, you can reliably expect a /48 to a) not be announced in BGP itself, and b) cover one to a few hundred users of one ISP. (The containing /32 or similar will be announced.) A business might structure its network so that one of its /48s corresponds to a country, but in that case the /48 would be covering just that business, which would be a sensible unit for reputation tracking.
Reputation unit is /64 block, so if you want to see a 100 people ISP as one reputation unit, it should get a /64 block. But AFAIK today in practice reputation unit is a country.
Or the most likely more expensive rate limiting (computational wise)
I mean, given how the site performs on average I don't think they've optimized so much that the extra cpu cycles of ANDing with the fixed constant of 2^64-1 and then looking up or hashing a 16 byte integer - whatever they do - rather than a 4 byte one would increase the load significantly. Let's be pessimistic and say it's 20 extra cpu cycles, that's not gonna be much of a problem if their load balancers were made in the past 20 years.
IPv6 rollout is a lot of operational work that ends with next to no immediate quantifiable benefit. So I’ll never be prioritized in a cost-cutting environment.
I mean, all your numbering woes vanished, so, that's probably an immediate quantifiable benefit unless you're so tiny you never needed any renumbering effort, in which case your "operational work" to deploy IPv6 was probably zero.
You probably need a hefty security reimplementation if you want to add IPv6 to Github.
The irony of this is that pretty much all they'd have to do to enable IPv6 support is to use Azure Front Door as their CDN. Or... use any other CDN, they pretty much all default to providing IPv6!
Last I checked, they're on Fastly who already support IPv6.
Came here to exactly check on this to see if there are any changes on Github side too
Most websites still don't
Tailscale have a great FAQ about IPv4 vs IPv6: https://tailscale.com/docs/reference/faq/ipv6
If you're not an expert in this area it's worth a read - I certainly learned a few things!
> IPv6 doesn't make it easy to allocate subnets to every device on a LAN; instead, subnets might be delegated to your local router, and then only individual addresses allocated to each device. If one of those devices then wants to route traffic on behalf of other devices (for example, to a sub-subnet behind a router, where the upstream router doesn't cooperate), it will need to use NAT. For example, this is how Tailscale exit nodes work, even with IPv6.
This is quite wrong, there'd DHCPv6-PD (prefix delegation) specifically designed to do this. Even more interestingly, it has recently been made part of IETF CPE requirements (RFC 9818 update to RFC 7084, July 2025).
That was excellent, thanks for recommending it. I particularly liked how it's a pretty factual FAQ, not particularly cheerleading for IPv6 nor saying "IPv6 is a failure, give up on it".
Here is my article that I wrote when I wanted to learn more about IPv6: https://ssg.dev/ipv6-for-the-remotely-interested-af214dd06aa...
EDIT: After reading Tailscale's article, I noticed that I overlooked our neverending dependence to NAT despite that IPv6 seems to eliminate it.
interesting read, pretty depressing take if you're pro IPV6. I think their guess that IPV6 has low value-add when considered as part of a hybrid environment is probably one of the better explanations I've heard for poor uptake.
The linked post are also interesting reads:
https://tailscale.com/blog/two-internets-both-flakey
https://apenwarr.ca/log/20170810
a great assessment thanks I hadn't seen that
"IPv6 is the next generation of the Internet Protocol (IP), the successor to IPv4."
This is a misconception. It is not the successor to IPv4, it is an alternative. Maybe the alternative is so good it will eventually make the older extinct, but it does not look like that
Regardless of whatever other things may be better or worse about ipv6, it's still a reality that as we continue connecting more and more devices to the internet eventually ipv4 addresses will become so scarce and valuable that a not-insignificant minority of residential customers will be behind such aggressive CGNAT that the internet will become nearly unusable unless a majority of the services they are using support ipv6.
I agree with you. While I can see some benefits to v6 on the internet, I find v4 to be miles easier and cleaner to work with in a LAN setup. Unfortunately though v6 oversteps on LAN features and makes bridging v4 and v6 way uglier than it should.
> v6 oversteps on LAN features and makes bridging v4 and v6 way uglier than it should
How so?
It has barely hit 50% and it's already plateauing. This adoption rate is ridiculous despite basically all network interfaces supporting it. I thought I would see IPv6 take over in my lifetime as the default for platforms to build on but I can see I was wrong. Enterprise and commercial companies are literally going to hold back internet progress around 60 to 75 years because it's in their best interest to ensure users can't host services without them. Maybe even 75 years might be too optimistic? They are literally going to do everything in their power to avoid the transition, either being dragged out kicking and screaming or throwing their hands up and saying they can't support IPv6 because it costs too much.
Try going IPv6-only by disabling IPv4 on your computer as a test and notice that almost nothing works except Google. End users shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs doing that to prepare for the transition.
Also, notice how Android and iOS don't support turning off IPv4.
Nearly all ISPs these days are deploying IPv6 for their mobile networks and core service networks, especially in less developed markets^1. The reason is simple, a cost justification. What doesn't exist is a cost justification for Enterprises to deploy IPv6, and for ISPs to deploy Residential / Corporate Internet IPv6.
IMO with the right market conditions, IPv6 could spread really fast within 6-24 months. For example, most cloud providers are now charging for IPv4 addresses when IPv6 is free. Small changes like that push in the right direction.
^1 https://www.theregister.com/2025/08/04/asia_in_brief/
Hetzner makes you pay 1 € per IPv4, while IPv6 is free. I'd gladly get rid of all IPv4's given that I have many servers.
But their VLANs still only support ipv4, which makes it hard to route external ipv6 traffic through the VLANs. You need tunnels.
OVH does the same, but only gives you a /128. Which is ridiculously shitty of them.
I find the whole OVH web control panel atrocious. It's so buggy I couldn't even have my account deleted, not even after contacting their customer support (they just told me to fix it myself using their APIs...).
I don't even know why clouds offer public IP addresses. In my opinion all clouds should only have a gateway that routes via host header for millions of customers. IPv4 should be a special priv for special situations at a higher price. Then these clouds could own maybe 20 IPs total instead of millions.
> In my opinion all clouds should only have a gateway that routes via host header for millions of customers.
This is incompatible with TCP/IP networking. In TCP connections, (sender_address, sender_port, receiver_address, receiver_port) is a unique combination. Those numbers together uniquely identify the sender talking to the receiver. For a public webserver:
* sender_address is the client machine's IP address
* sender_port is a random number from 0..65535 (not quite, but let's pretend)
* receiver_address is the webserver's IP address
* receiver_port is 443
That means it'd be impossible for one client IP to be connected to one server IP more than 65535 times. Sounds like a lot, right?
* sender_address is the outbound NAT at an office with 10,000 employees
Now each user can have at most 6.5 connections on average to the same webserver. That's probably not an issue, as long as the site isn't a major news org and nothing critical is happening. Now given your scheme:
* receiver_address is the gateway shared by 10000 websites
Now each user can have at most 6.5 connections to all of those 10000 websites combined, at once, total, period. Or put another way, 100,000,000 client/website combos would have to fit into the same 65535 possible sender_ports. Hope you don't plan on checking your webmail and buying airline tickets at the same time.
If you multiply by 20 shared addresses, it would be 130 connections to 200000 websites.
This is actually a good point. I guess 20 IPs per cloud infra company is probably too few. But maybe these cloud companies can have 20k IPs instead of 2 million?
> host header
Not all workloads are HTTP.
> gateway .. for millions of customers
That's basically what an AWS ALB is. It's not provisioning bespoke infrastructure when you create it.. it's just a routing rule in their shared infra.
If Amazon wanted, they could easily have shared IP's but the cost of an IPv4 isn't so great that this approach has been warranted yet, clearly.
Yeah I get all that, but the only two connection types that are useful are http/s/ and ssh. SSH can have work-arounds like the way google does.
Let's let the people that want non http workloads pay more.
Remember that, at one stage, the only two types that were useful were FTP and telnet. HTTP and SSH didn't even exist.
Let's not strangle the next big thing that doesn't exist yet before it can even be born, yeah?
The next big thing can happen on IPv6
But only if you don't hide everybody away behind routers that require HTTP and a host header.
Imagine if one day someone came up with a "better" way to chew food, but you had to learn how to do a super complex jaw movement and it wouldn't work in restaurants. It has no obvious benefit to you. The only motivation is that a small group of obsessively passionate (but not in a good way) people say at some unknown point in the future food won't be edible anymore.
IPv6 just tried to do too much so it failed at everything. Putting letters in IP addresses made it near impossible to remember what your network settings were supposed to be.
It is nothing short of a miracle that devices can even get IPv6 addresses. SLAAC was supposed to replace DHCP, but it couldn't provide DNS server addresses. DHCPv6 was introduced to replace SLAAC, but this time they forgot to add a way to communicate a default route. This lead to Cisco, Microsoft, and Google all taking completely different approaches, and the IETF helpfully blocking any efforts at cross vendor standardization because of v6 zealots.
Meanwhile, everybody else is using a plastic skull that they carry around with them to pre-chew the inedible food, which is the majority of the food you can get these days.
"It's not inedible," they say. "Just let me get my skull out."
> IPv6 just tried to do too much so it failed at everything. Putting letters in IP addresses made it near impossible to remember what your network settings were supposed to be.
People said the same sort of thing about v4: that it was hard to configure because you needed to know four separate addresses (IP, netmask, default route AND the DNS server) and if you mix up any of these it doesn't work.
As it turns out, in both cases it's just a lack of familiarity, not actual difficulty. The super complex jaw movement is just a regular bite, but you puff your cheeks out a bit. Or er, something.
> This lead to Cisco, Microsoft, and Google all taking completely different approaches [...] but this time they forgot to add a way to communicate a default route
"There should only be one way to do things... wait, no, not like that."
Apple/iOS is probably one of the biggest individual drivers of IPv6 adoption. They've been requiring that iOS apps work on IPv6-only networks for close to 10 years now
> They've been requiring that iOS apps work on IPv6-only networks for close to 10 years now
This was at the behest of mobile network. E.g., T-Mobile US has 140M subscribers, and moved to IPv6-only many years ago:
* https://www.youtube.com/watch?v=d6oBCYHzrTA
The requirement is to support IPv6 only networks with IPv4 transition mechanisms. It does not preclude contacting v4-only servers.
And the higher level libraries mostly do it for you, too, even if you directly specify IPv4 addresses in your code (due to NAT64 [1]). I think it only even requires special work from you as a developer if you're using low-level or non-standard libraries.
[1] https://en.wikipedia.org/wiki/NAT64
The problematic low-level libraries are standard, and effectively impossible to fully deprecate since they're decades old and part of the socket API.
I think currently Apple still helps you with these via "bump in the stack" (i.e. they can translate internal v4 structures and addresses into NAT64-prefixed v6 at the kernel level), but they probably don't want to commit to doing that forever.
If that's the case, how does the Github app work on iOS?
Nat64: https://developer.apple.com/support/ipv6/
Differential enforcement.
Apple’s App Store enforcement is very arbitrary. For example, if the app developer offends steve jobs, you’re banned for life.
[dead]
I’m guessing the app works but their prod servers don’t? If they can point the app during review at a “self hosted” GitHub Enterprise server on a test domain with AAAA that would pass the requirement as stated by gp , without requiring GitHub.com actually support ipv6.
The prod servers work. The app does a DNS lookup, receives something like 64:ff9b::140.82.112.5 and 140.82.112.5 from the ISP's DNS servers, and then connects to 64:ff9b::140.82.112.5. Some part of the ISP network translates the connection into a v4 connection to 140.82.112.5.
The requirement is simply that the app does AAAA queries, and that it attempts to connect to them if they exist. It doesn't matter whether the server does v6 natively or if the ISP is covering for a v4-only server via backwards compatibility. (Native v6 will probably perform better, but any site that wants to give up that advantage is free to do so.)
That’s DNS64, which is pretty annoying in practice. (For one thing, you can’t use your own DNS server anymore, but more importantly, anything using v4 literals will 100% break.)
What’s nicer is 464XLAT, or more generally NAT64 prefix announcements. Then your local OS can just synthesize NAT64 addresses from v4 literals, either at the socket library or kernel networking (via “bump in the stack” translation) layer.
> It has barely hit 50% and it's already plateauing.
Is it plateauing? From the chart it doesn't look that way at all to me.
You could say it's flat between August 2025 and now, but it also was from Jun 2024-Feb 2025, or August 2023-March 2024. There's just a lot of noise to it -- lots of short plateaus or even dips followed by lots of sudden jumps. Indeed, it seems to have a bit of a yearly cycle to it, suggesting we're at the inflection point of another jump upwards.
So it still seems to be growing strongly to me. The rate of growth has slowed maybe the tiniest bit 2024-2026 compared 2018-2023, but I don't see it anywhere close to plateauing yet.
> It has barely hit 50% and it's already plateauing. This adoption rate is ridiculous despite basically all network interfaces supporting it
It's fine. IPv4 and IPv6 can be used at the same time. There's no hurry. Network interfaces support anything as long as both sides agree (nothing stopping you from building your own IPX network over MPLS).
People can move to IPv6 when the IPv4-as-real-estate speculators get out of control, and if IPv6 prevents IPv4 rental prices from going haywire, then it's served a useful purpose.
I saw a news article that said something about India considering moving to IPv6-only? That's going to be interesting if the rest of the world moves to IPv6 and the U.S. doesn't.
> End users shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs doing that to prepare for the transition.
100%
The Czech government has announced it’ll stop offering its services via IPv4 in June 2032.
Source https://konecipv4.cz/en/
I've been hearing that those speculators were going to get out of control and the IPv4 price was going to skyrocket for 10+ years.
Yet I can still rent a VPS with IPv4 for $12/year from a wide variety of providers.
For now, :) Hopefully it continues.
> if IPv6 prevents IPv4 rental prices from going haywire, then it's served a useful purpose.
Competition is good.
You can, but a significant portion of that money is going toward paying off that IP.
"Skyrocket" is wrong but the market cap of IPv4 addresses is quite high.
ISPs often fail to do this because there is always someone in the hierarchy who says, "nobody is demanding it."
Nobody is demanding IPv4 either. Or Ethernet. People buy "Wi-Fi", literally "Wi-Fi", not Internet access.
Exactly. To this point I went to a Comcast store to cancel my internet and the person asked me if I meant I wanted to cancel my “Wi-Fi”. I was very confused for a couple seconds.
It has been interesting to me to see how the usage of "my wifi bill" instead of "my internet bill" has shifted.
I worked at a place where they refused to run it _anywhere_ because a couple of people were insistent that it was “insecure”.
... and they were right.
v6 adoption is often an all or nothing, because if you run both stacks, you have to ensure they are consistent. While you can reasonably do it on your home LAN, doing it across an entire infrastructure is the worst.
Now you have to make sure all your subnets, routing, VLANs, firewall rules, etc work exactly the same in two protocols that have very little in common.
It is the equivalent of shipping two programs in different languages and maintaining exact feature parity between both at all times.
I genuinely don’t understand this. The concepts are nearly identical between the two.
Hum no, to me they are orthogonal.
v4 was built around the idea of multiple free standing networks linked by gateways. v6 was built around the idea of a universal network.
I dont care about what your LAN adress space look like when I'm in my LAN, because we are not in the same v4 network. I am sovereign in my network.
With v6, everyone is effectively in the same network. I have to ask my ISP for a prefix that he will rent me for money even for my LAN. If I want some freedom from said ISP prefix, I am mercifully granted the honor of managing ULA/NAT66 (granted I paid for a fancy router).
Also if I want any kind of privacy, I will have to manage privacy extensions and the great invention of having to use automatically generated, dynamically routed, essentially multiple random IPs per interface. How lucky am I to use such a great new technology.
Seriously v6 was created by nerds in a lab with no practical experience of what people wanted.
> v4 was built around the idea of multiple free standing networks linked by gateways
It was absolutely not. This is why early companies like Apple and Ford got massive IP allocations - each computer was expected to have a unique IP address.
NAT didn't exist until 14 years after IPv4 was created, in response to the shortage of IPv4 addresses, and in the RFC it is described as a "short-term solution", very clearly stated that his not how the internet is designed to work and it should only be used as a stopgap until we get longer addresses.
> v4 was built around the idea of multiple free standing networks linked by gateways.
I don't think this is what v4 was built around, but rather what v4 turned into.
CIDR wasn't introduced until 1993. NAT in 1994. Both to handle depleting IP addresses.
v4 and v6 were build around the exact same use cases.
> With v6, everyone is effectively in the same network.
Just like IPv4.
> I have to ask my ISP for a prefix that he will rent me for money even for my LAN.
Just like IPv4, if you need a static address.
> If I want some freedom from said ISP prefix, I am mercifully granted the honor of managing ULA/NAT66 (granted I paid for a fancy router).
Compared with IPv4, where if you want some freedom from said ISP subnet, you are mercifully granted the honor of managing RFC-1918 addresses/NAT (granted you paid for a router that doesn't screw it up).
> Also if I want any kind of privacy, I will have to manage privacy extensions
...which are enabled by default nearly universally
> and the great invention of having to use automatically generated, dynamically routed, essentially multiple random IPs per interface.
Make up your mind. Are rotating, privacy-preserving addresses good or bad? The way it works in real life, not in the strawman version, is that you (automatically!) use the random addresses for outgoing connections and the fixed addresses for incoming.
If you want static addresses in LAN, you can use link local addresses for that.
This is exactly why I decided not to enable IPv6 on my colo. When money is involved, the benefits of IPv6 simply do not outweigh the risk, in my estimation. If my side gig eventually pays enough to pay a contractor to handle networking then sure, that'll be one of the first tasks. But when it's just me managing the entire stack, my number one priority is security, and for now that means keeping things simple as possible.
> ISPs often fail to do this because there is always someone in the hierarchy who says, "nobody is demanding it."
I'm with an ISP whose landline/fibre division does not have IPv6, but whose mobile division gives IPv6 to handsets.
I with I knew how to get through that I want it. I'm supposed to be a tech guy - that means I need experience with the latest tech in my house
I switched my home ISP from cable (which supported IPv6) to fiber (which doesn't) and I've had a nagging disappointment ever since. But I guess consumers aren't really demanding it enough.
I think we'll hit a tipping point soon, just like with Python3 - for years and years it seemed almost stalled, then it became easier to start with python3 than python2 and suddenly everyone migrated.
This seems like wishful thinking. Python3 vs. Python2 seems different than IPv6 vs. IPv4.
"seems" is doing a lot of heavy-lifting in your message
“Gradually, then suddenly.”
[dead]
> End users shouldn't need to set up 6to4 tunneling. It should be ISPs doing that to prepare for the transition.
Which is what ISP are doing with 464XLAT deployments. IPv6-mostly networking and IPv4-as-a-service are things that are happening in real world right now.
Yeah in Japan my ISP even lets me choose which IPv4 provider I want to use, as the fiber network is IPv6-native and IPv4 is "just another service" like IPTV.
Wow, that’s very cool! Do you know how that works? Do they just connect you to a NAT64 gateway of your choice?
IPv4 is provided using DS-Lite or MAP-E depending on the provider.
I'm using OpenWRT and paid for a static IP so I had to manually configure all the details for the MAP-E tunnel in OpenWRT myself, I think typically the routers sold to consumers pick up the configuration automatically somehow.
Which provider are you using? I'm curious about this since there are not many OpenWrt guides for getting connected in Japan. Is your config similar to this write-up? https://github.com/fakemanhk/openwrt-jp-ipoe
I didn't need to do any configuration for DS-Lite or MAP-E, as DHCPv6 with a configured prefix got IPv6 working, although DNS is still broken when turning off IPv4 entirely.
I'm using en hikari on Flets Cross (10 gigabit) with v6plus.
I set it up like 2 years ago but this was in my bookmarks: https://zenn.dev/ebi68k/articles/6df7cfec64c281
edit: looking this all up again to refresh my memory, it looks like with my static IP the provider switches from using their default MAP-E to using RFC2473 directly instead, the configuration matches "IPIP" in this guide https://qiita.com/kouhei-ioroi/items/cf0c6228c5c1faef415a
Woah, MAP-E allows static v4 (and presumably inbound connections)? That seems neat and much better than DS-Lite!
I'm re-learning this right now since I kind of just set it and forgot it 2 years ago but while my provider typically uses MAP-E it looks like when you use a static IP it switches to using RFC2473 (IPIP6) directly without the extra port mapping that MAP-E adds ontop
> It has barely hit 50% and it's already plateauing.
That makes sense. The majority of IPv6 deployment is mobile.
The next wave of adoption requires ISPs start offering residential IPv6. Once this happens, router manufacturers will innovate around the IPv6 offering as a differentiator, making it easy to deploy by end-users. IPv6 wifi APs will then become ubiqutious and so forth across other services. Has to start with ISPs.
ISPs in the US and Europe mostly have been offering IPv6 for a while now
Unfortunately my ISP here in Europe is not one of those offering IPv6.
Mine does and it works so well that I actually have to turn it off when working from home as a bunch of the third party servers at work doesn't have any support for it.
That sounds more like broken support then. Not having any support at all (i.e. A records or v4 literals only) should just send you to whatever v4 transition technology your ISP offers, no?
Other than France or Germany its far from mostly.
My German ISP supports it now, which was the limiting factor for me, and a new VPS I just bought also does, so finally I was able to create my first personal AAAA record. I am hoping that we're seeing a tipping point. Again.
Is there a reason why adoption has been so abysmally slow? Like surely all the big players have updated their networking equipment by now, and surely every piece of enterprise-grade kit sold in the last 20 years has supported v6.
The only arguments I've ever heard against ipv6 that made any sense are that:
1: it's hard to remember addresses, which is mayyyyybe valid for homelab enthusiast types, but for medium scale and up you ought to have a service that hands out per-machine hostnames, so the v6 address becomes merely an implementation detail that you can more or less ignore unless you're grepping logs. I have this on my home network with a whopping 15 devices, and it's easy.
and 2: with v6 you can't rely on NAT as an ersatz firewall because suddenly your printer that used to be fat dumb and happy listening on 192.168.1.42 is now accidentally globally-routable and North Korean haxors are printing black and white Kim Il Sung propaganda in your home office and using up all your toner. And while this example was clearly in jest there's a nugget of truth that if your IOT devices don't have globally-routable addresses they're a bit harder to attack, even though NAT isn't a substitute for a proper firewall.
But both of these are really only valid for DIY homelab enthusiast types. I honestly have no idea why other people resist ipv6.
The big reason is that domestic ISPs don't want to switch (not just in the US, but everywhere really.)
Data centers and most physical devices made the jump pretty early (I don't recall a time where the VPS providers I used didn't allow for IPv6 and every device I've used has allowed IPv6 in the last 2 decades besides some retro handhelds), but domestic ISPs have been lagging behind. Mobile networks are switching en masse because of them just running into internal limits of IPv4.
Domestic ISPs don't have that pressure; unlike mobile networks (where 1 connection needing an IP = 1 device), they have an extra layer in place (1 connection needing an IP = 1 router and intranet), which significantly reduces that pressure.
The lifespan of domestic ISP provided hardware is also completely unbound by anything resembling a security patch cycle, cost amortization or value depreciation. If an ISP supplies a device, unless it fundamentally breaks to a point where it quite literally doesn't work anymore (basically hardware failure), it's going to be in place forever. It took over 10 years to kill WEP in favor of WPA on consumer grade hardware. To support IPv6, domestic ISP providers need to do a mass product recall for all their ancient tech and they don't want to do that, because there's no real pressure to do it.
IPv6 exists concurrently with IPv4, so it's easier for ISPs to make anyone wanting to host things pay extra for an IPv4 address (externalizing an ever increasing cost on sysadmins as the IP space runs out of addresses) rather than upgrade the underlying tech. The internet default for user facing stuff is still IPv4, not IPv6.
If you want to force IPv6 adoption, major sites basically need to stop routing over IPv4. Let's say Google becomes inaccessible over IPv4 - I guarantee you that within a year, ISPs will suddenly see a much greater shift towards IPv6.
It's frustrating that even brand new Unifi devices that claim to support IPv6 are actually pretty broken when you try to use it. So 10 years from right now even, unless they can software patch it upwards.
Interesting, what's broken for you? I have some unifi gear and it handles v6 no problem.
Not parent but:
Prefix delegation is completely broken for example
I had to switch to OpenWRT on my Ubiquity gear to have something that works (which on the other hand is also easier to configure, so I'm probably going to stay there).
Except that is completely wrong. Consumer/residential networks have significantly higher ipv6 adoption rates that corporate/enterprise networks. That is why you see such clear patterns (weekend vs weekday) in the adoption graphs.
There are still a lot that have not.
Sure, the data plane supports it - but what about the management plane?
I wouldn't be surprised if ISPs did all the management tasks through a 30-year-old homebrew pile of technical debt, with lots of things relying on basic assumptions like "every connection has exactly one ip address, which is 32 bits long".
Porting all of that to support ipv6 can easily be a multi-year project.
> Porting all of that to support ipv6 can easily be a multi-year project.
FWIW, as someone who has done exactly this in a megacorp (sloshing through homebrew technical debt with 32-bit assumptions baked in), the initial wave to get the most important systems working was measured in person-months. The long tail was a slog, of course, but it's not an all-or-nothing proposition.
Comcast actually implemented IPv6 10-15 years ago so that they could unify the management of all of their cable modems. Prior to that they had many regional networks using with modems assigned management IPs in overlapping private IPv4 ranges.
This is true, I worked for an old ISP/mobile carrier that started in the 80s about 10-15 years ago. They had basically any system you could think of still running, from decently modern vmware with windows and linux to hp-ux, openvms, sunos, AIX, etc. Could walk around and see hardware 30 years old still going, I think one console router had an uptime of 14 years or so. One time I opened a cabinet and found a pentium 1 desktop pc on the floor still running and connected, served some webpage. The old SMSC from the 80s on DEC hardware was still in its racks though not operational, they didn't need the space as the room couldn't provide enough power or cooling for more than a few modern racks. The planning program for fiber, transmission, racks, etc, required such an old java that new security bugs didn't apply to it, and looked and worked like an old mainframe program.
The core team supported ipv6 for a long time, but its rather easy to do that part. The hard part is the customer edge and CPE and the stack to manage it, it may have a lifetime of 2 decades.
> it's hard to remember addresses
We desperately need a standardized protocol to look up addresses via names. Something hierarchical, maybe.
> with v6 you can't rely on NAT as an ersatz firewall
Why would you not just use a regular firewall? Any device that is able to act as a NAT could act as a firewall, with less complexity at that.
>Why would you not just use a regular firewall?
No idea, but people do it. Every time this comes up on HN there are dozens of comments about how they like hiding their devices behind a NAT, for security
Just because people regularly bring up a non sequitur doesn't mean there actually is a problem.
"I have a device acting as both a NAT and a stateful firewall, why are you making me switch to IPv6 and in the process drop both the NAT and the stateful firewall?" is a non sequitur.
I think we're talking about two different things, or maybe I just don't understand your reply.
What I'm saying is this: There exist people in the hobbyist space who believe that when their devices only have private IPv4 addresses such as 192.168.0.0/16 that this meaningfully increases their network security, and that if their raspberry pi has a globally-routable v6 address that this weakens their network security, even though this is bogus because NAT is orthogonal to network security considerations, and that this belief contributes to IPv6 hesitancy.
Has it been abysmally slow? What's the par time for migrating millions of independent networks, managed by as many independent uncoordinated administrators, to a new layer 3 protocol?
We've never done this before at this scale. Maybe this is just how long it takes?
> But both of these are really only valid for DIY homelab enthusiast types. I honestly have no idea why other people resist ipv6.
Simple. The "homelab enthusiast types" are those that usually push new technologies.
This is one they don't care about, so they don't push it. Other people don't care about any technology if it's not pushed on them.
Nothing stops you running a NAT for v6 too, its just people tend to choose not to when given the choice
I set up NAT66 recently with DHCPv6. The IPv4 and IPv6 addresses are practically the same, except IPv6 has a prefix and a double colon as the last separator.
This really should be how SOHO routers do IPv6 out of the box.
Most people don't want 1:1 addressing for their entire home or office.
Q on your setup
Are you using ULA prefix for the nat66/dhcp6, are you also allowing GUA address assignment via slaac? Im wondering how it works out with source-selection
"Is there a reason why adoption has been so abysmally slow?"
Just the obvious one: the people who designed IPv6 didn't design for backwards compatibility.
How so? The same working group published e.g. https://www.rfc-editor.org/rfc/rfc1933, and it's hard to see how v6 could have been designed for backwards compatibility in ways that it wasn't already.
I've asked lots of people to describe a more backwards-compatible design, and generally the best they can manage is to copy the way v6 does things, ending up with the same problems v6 has. This has happened so often that the only reasonable conclusion is that it can't really be done any better than it was.
> Just the obvious one: the people who designed IPv6 didn't design for backwards compatibility.
Nor for easy transition.
> 1: it's hard to remember addresses
fd::1 is perfectly valid internal IPv6 address (along with fd::2 ... fd::n)
fd::1 is somewhere in the reserved ::/8 space where various stuff like old ipv4 mapped addresses and localhost reside. What you probably mean is something like fd00::1, but that is something you shouldn't use, because 'fd00::/8' is a probabilistically unique local address (ULA) block. You are supposed to create a /48 net by appending 40 random bits to fd00::/8. Of course, if your fair dice roll lands on all zeroes, and you are ok with probable collisions in case of a network merge, you are fine ;)
In home networks, the idea of merging with someone else's network is... most certainly not worth worrying about. Maybe you marry someone or become roommates with someone who also picked fd00::/8? And you still want two separate subnets? Other than that I don't see a scenario where it matters.
Granted, if you're doing this in a corporate setting (where merging with someone else's address space is a lot more realistic), then yes definitely pick a random 40 bits. But at home? Who cares. Same as using 192.168.1.0/24 instead of a random 10.0.0.0/24 subnet... it's not worth worrying about.
I'm having my own and my girlfriend's router (in different flats) connect to each other with a wireguard tunnel, so I can print on her printer. Non-colliding addresses make this a lot easier.
But yes, renumbering also isn't a lot of work.
> Like surely all the big players have updated their networking equipment by now
My home isp can't even do symmetrical gigabit, let alone ipv6...
That's extremely common unless on "active" fiber (vs GPON, DOCSIS3, DSL, most fixed wireless, satellite, mobile, etc.)
Your wifi isn't symmetrical either.
Those are designed to have static asymmetrical bandwidth though, *dm split gives ISP side more of possible shared bandwidth. Wifi bandwidth is shared and dynamic so client can use all of it.
> Those are designed to have static asymmetrical bandwidth though
Yes, that's why I said that?
> *dm split
No idea what you're trying to say here.
Ignore all the excuses like longer addresses and incompatible hardware. The actual reason is that everyone hates change.
IPv6 is a recursive WTF. It might _look_ like a conservative expansion of IPv4, but it's really not. A lot of operational experience and practices from IPv4 don't apply to IPv6.
For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
In IPv6 each host has multiple global addresses. But if your global connection goes down, these addresses are supposed to be withdrawn. So your hosts can end up with _no_ addresses. ULA was invented to solve this, but the source selection rules are STILL being debated: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda...
Then there's DHCP. With IPv4 the almost-universal DHCP serves as an easy way to do network inspection. With IPv6 there's literally _nothing_ similar. Stateful DHCPv6 is not supported on Android (because its engineers are hell-bent on preventing IPv6). And even when it's supported, the protocol doesn't require clients to identify themselves with a human-readable hostname.
Then there's IP fragmentation and PMTU that are a burning trash fire. Or the IPv6 extension headers. Or....
In short, there are VERY good reasons why IPv6 has been floundering.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
No, that’s not the IPv4 design. That’s an incredibly ugly hack to cope with IPv4 address shortage. It was never meant to work this way. IPv6 fixes this to again work like the original, simpler design, without ”local” addresses or NAT.
> In IPv6 each host has multiple global addresses.
Not necessarily. You can quite easily give each host one, and only one, static IPv6 address, just like with old-style IPv4.
Hyrum's law. That's how IPv4 is being used in practice.
> You can quite easily give each host one, and only one, static IPv6 address, just like with old-style IPv4.
You literally CAN NOT. On Android there's no way to put in a static IPv6 or even use stateful DHCPv6.
> Hyrum's law. That's how IPv4 is being used in practice.
It's still very ugly to mess with the ports that way.
The only clean NAT is 1:1 IP NAT.
> You literally CAN NOT. On Android there's no way to put in a static IPv6 or even use stateful DHCPv6.
Blame the closed and proprietary Android platform for that; not IPv6.
The problem here is the IPv6 design. It has multiple ways of configuration, and ALL of them suck.
Manual address input is clumsy because of IPv6 address length, stateless RA is limited and doesn't allow network introspection, stateless DHCP is pointless, stateful DHCP is not supported by the most widely deployed OS. There's also prefix delegation that needs stateful DHCP.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
This is a troll right? NAT is a lot of things, but "simple and clean" is definitely not one of them. It causes complications at every step of the process.
Pure IPv6 is so much cleaner.
I will say that DHCP6 is probably misnamed. It does not fill the same niche has IPv4 DHCP, and this causes a lot of confusion with people who are new to IPv6. It should probably be called DPDP (Dynamic Prefix Distribution Protocol) or something like that. It's for routers not hosts.
In theory you should be using anycast DNS to find local hostnames, but in practice the tooling around this is somewhat underbaked.
> This is a troll right? NAT is a lot of things, but "simple and clean" is definitely not one of them. It causes complications at every step of the process.
I invite you to try this challenge: https://news.ycombinator.com/item?id=47796992
This is something that can be done with consumer-grade routers in _minutes_ with zero configuration from endpoints apart from the usual WiFi password.
NAT is a _superior_ design in practice. It can be chained transparently, it moves all the stateful routing complexity to the border router, it enforces network isolation. And most importantly, IT ACTUALLY WORKS.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
I assume you mean "interface", not "host". Because it's absolutely not true that a host can only have one "local net address".
EDIT: a brief Google also confirms that a single interface isn't restricted to one address either: sudo ip address add <ip-address>/<prefix-length> dev <interface>
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
If you think NAT is "simple and clean", you may wish to investigate STUN/TURN/ICE. An entire stack of protocols (and accompanying infrastructure) had to be invented to deal with NAT.
Heaven help you if your ISP uses CG-NAT.
I can type entire SIP handshakes from memory. And by now I'm convinced that STUN/TURN are a superior solution to IPv6, even with CGNAT.
Others agree with me. Don't believe me? Try to find a SIP provider in the US that has IPv6 connectivity. Go on. Try it.
> Then there's IP fragmentation and PMTU that are a burning trash fire.
It's not significantly worse on v6 compared to v4. Yes, in theory, you can send v4 packets without DF and helpful routers will fragment for you. In practice, nobody wants that: end points don't like reassembling and may drop fragments; routers have limited cpu budget off the fast path and segment too big is off the fast path, so too big may be dropped rather than be fragmented and with DF, an ICMP may not always be sent, and some routers are configured in ways where they can't ever send an ICMP.
PMTUd blackholes suck just as much on v4 and v6. 6rd tunnels maybe make it a bit easier to hit if you advertise mtu 1500 and are really mtu 1480 because of a tunnel, but there's plenty of derpy networks out there for v4 as well.
> but there's plenty of derpy networks out there for v4 as well.
God yes, I've helped so many users on PPPoE by telling them to set their MTU to something lower...
In my case, I set the MTU of the physical NIC to 1508 and kept the PPPoE interface at 1500. Best of both worlds. Needs the ISP to support it though.
IPv4 allows fragmentation by the middleboxes, which in practice papers around a lot of PMTU issues.
The IPv6 failing was not taking advantage of the new protocol to properly engineer fragmentation handling. But wait, there's more! IPv6 also has braindead extension headers that require routers to do expensive pointer chasing, so packets with them are just dropped in the public Net. So we are stuck with the current mess without any way to fix it.
People are trying: https://datatracker.ietf.org/doc/rfc9268/ but it's futile. It's waaaay too late and too fundamental.
> IPv4 allows fragmentation by the middleboxes, which in practice papers around a lot of PMTU issues.
In theory yes; but actual packets are 99%+ flagged DF. Reassembly is costly, so many servers drop fragmented packets, or have tiny reassembly buffers. Back when I ran a 10G download server, I would see about 2 fragmented packets per minute, unless I was getting DDoSed with chargen reflection, so I would use a very small reassembly buffer and that avoided me burning excessive cpu on garbage, while still trying to handle people with terrible networks.
Router fragmentation is also expensive and not fast path, so there's pretty limited capacity for in path fragmentation.
I think I agree with you, that RFC you linked seems awfully hopeful... unlikely to actually happen. Better endpoint probing is probably where we're going to end up. Or things like QUIC where if you don't have the required minimum MTU, too bad so sad.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
That's only true for smalltime home networks. Try to merge 2 company IPv4 networks with overlapping RFC1918 ranges like 10.0.0.0/8. We'll talk again in 10 years when you are done sorting out that mess ;)
> In IPv6 each host has multiple global addresses. But if your global connection goes down, these addresses are supposed to be withdrawn. So your hosts can end up with _no_ addresses.
Only a problem for home users with frequently changing dialup networks from a stupid ISP. And even then: Your host can still have ULA and link-local addresses (fe80::<mangled-mac-address>).
> ULA was invented to solve this, but the source selection rules are STILL being debated: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda...
RFC6724 is still valid, they are only debating a slight update that doesn't affect a lot.
> Then there's DHCP.
DHCPv6 is an abomination. But not for the reasons you are enumerating.
> With IPv4 the almost-universal DHCP serves as an easy way to do network inspection.
IPv4 DHCP isn't a sensible means to do network inspection. Any rougue client can steal any IP and MAC address combination by sniffing a little ARP broadcast traffic. Any rogue client can issue themselves any IPv4 address, and even well-behaved clients will sometimes use 169.254.0.0/16 (APIPA) if they somehow didn't see a DHCP answer. If you want something sensible, you need 802.1x with some strong cryptographic identity for host authentication.
> Stateful DHCPv6 is not supported on Android (because its engineers are hell-bent on preventing IPv6).
Yes, that is grade-A-stupid stubborness. On the other hand, see below for the privacy hostname thingy in IPv4 and the randomized privacy mac addresses that mobile devices use nowadays. So even if Android implemented stateful IPv6, you will never be reliably able to track mobile devices on your network. Because all those identifiers in there will be randomized, and any "state" will only last for a short time. If you want reliable state, you need secure authentication like 802.1x on Ethernet or WPA-Enterprise on Wifi, and then bind that identity to the addresses assigned/observed on that port.
> With IPv6 there's literally _nothing_ similar.
Of course there is. DHCPv6 can do everything that IPv4 DHCP can do (by now, took some time until they e.g. included MAC addresses as an option field). But in case of clients like Android that don't do DHCPv6 properly, you still have better odds in IPv6: IPv6 nodes are required to implement multicast (unlike in IPv4 where multicast was optional). So you can just find all your nodes in some network scope by just issuing an all-nodes link-local multicast ping on an interface, like:
> ping6 ff02::1%eth0
There are also other scopes like site-local: > ping6 ff05::1%eth0 https://www.iana.org/assignments/ipv6-multicast-addresses/ip...
(The interface ID (like eth0, eno1, "Wired Network", ...) is necessary here because your machine usually has multiple interfaces and all of those will support those multicast ranges, so the kernel cannot automatically choose for you.)
> And even when it's supported, the protocol doesn't require clients to identify themselves with a human-readable hostname.
DHCP option 12 ("hostname") is an option in IPv4. Clients can leave it out if they like. There is also such a thing as "privacy hostname" which is a thing mobile devices do to get around networks that really want option 12 to be set, but don't want to be trackable. So the hostname field will be something like "mobile-<daily_random>".
What you skipped are the really stupid problems with DHCPv6 which make it practically useless in many situations: DHCPv6 by default doesn't include the MAC address in requests. DHCPv6 forwarders may add that option, but in lots of equipment this is a very recent addition still (though the RFC is 10 years old by now). So if you unbox some new hardware, it will identify by some nonsensical hostname (useless), an interface identifier (IAID, useless, because it may be derived from the MAC address, but it may also be totally random for each request) and a host identifier (DUID, useless, because it may be derived from the mac address, but it may also be totally random for each request). Whats even more stupid, the interface identifier (IAID) can be derived from a MAC address that belongs to another interface than the one that the request is issued on. So in the big-company usecase of unboxing 282938 new laptops with a MAC address sticker, you've got no chance whatsoever to find out which is which, because neither IAID nor DUID are in any way predictable. You'll have to boot the installer, grab the laptop's serial number somewhere in DMI and correlate with that sticker, so tons of extra hassle and fragility because the DHCPv6 people thought that nobody should use MAC addresses anymore...
> That's only true for smalltime home networks. Try to merge 2 company IPv4 networks with overlapping RFC1918 ranges like 10.0.0.0/8. We'll talk again in 10 years when you are done sorting out that mess ;)
Look, I've been doing IPv6 for 20 years, starting with a 6to4 tunnel and then moving to HE.net before getting native connectivity. I'm probably one of the first people who started using Asterisk for SIP on an actual IPv6-enabled segmented network.
I _know_ all the pitfalls of IPv6 and IPv4. And at this point, I'm 100% convinced that NAT+IPv4 is not just an accidental artifact but a better solution for most practical purposes.
> What you skipped are the really stupid problems with DHCPv6 which make it practically useless in many situations: DHCPv6 by default doesn't include the MAC address in requests.
Yes. DUIDs were another stupid idea. As I said, IPv6 is a cascade of recursive WTFs at every step of the way.
And let me re-iterate, I'm not interested in academic "but acshually" reasons. I know that you can run IPv4 with DHCP giving out publically routable IPv4 addresses to every host in the internal network without NAT. Or that you can do NAT on IPv6 or laboriously type static IPv6 addresses in your config.
What matters is the actual operational practice. Do you want a challenge? Try to do this:
1. An IPv6 network for a small office with printers, TVs, and perhaps a bunch of smart lightbulbs.
2. With two Internet uplinks. One of them a cellular modem and another one a fiber connection.
3. You want failover support, ideally in a way that does not interrupt Zoom meetings or at least not for more than a couple of seconds.
4. No NAT (because otherwise why bother with IPv6?).
Go on, try that. This is something that I can do in 10 minutes using an off-the-shelf consumer/prosumer router and IPv4. With zero configuration for the clients, apart from typing the WiFi password.
Well, I can do that with OpenWRT, no idea which prosumer devices already implement this, but it isn't rocket science: Announce the Prefix of the currently active connection, invalidate the other one. Will interrupt all your TCP connections, but they are toast anyways, most software should handle this just fine. It's quite the same as a Wifi-to-Cellular handover.
> Announce the Prefix of the currently active connection, invalidate the other one
And this doesn't actually work. Prefix deprecation is a best-effort feature that is not implemented correctly in tons of devices, including such rarely used niche operating systems as macOS. It even technically violates RFC4862 (section 5.5.3).
As usual, IETF only recently woke up to that reality: https://datatracker.ietf.org/doc/html/rfc8978
I highly recommend actually trying what I proposed. Not in a theoretical hand-wavy way, but actually setting it all up and verifying that it works. I did not pose this challenge in a "gotcha" way. I really was not able to make it work cleanly with either Mikrotik or OpenWRT routers.
How do the working IPv6 deployments cope with these issues?
The simple answer is: they just don't deploy IPv6.
These days you can use ULA and third-party monitoring tools instead of DHCP.
The reason: Skill issue.
>For example, in IPv4 each host has one local net address
Most of my home devices have multiple v4 addresses, not counting 127.0.0.1, so this assumption is incorrect.
Since when was there ever a plan to disable IPv4 on the Internet? Just because IPv6 is around doesn't mean that IPv4 is going to go away.
That was always the plan for "the future". That is get everyone to IPv6 and then get rid of IPv4. IPv4's days are numbered - but the number looks really big.
Why would we keep around a whole separate Internet? Dual stack was always only intended for the transition period.
It's very hard to get rid of old standards.
"The past is never dead. It's not even past"
Of course there's an incredibly long tail here, but in the big picture, "nobody except some people maintaining a few legacy systems ever need to learn to work with this protocol anymore" is practically the same thing.
Comcast, one of the largest residential ISPs in the USA, has almost full IPv6 deployment by default. The majority Verizon Wireless is IPv6 by default. Residential customers in the USA have great access if they just enable the stack.
There is nothing about IPv6 that prevents ISPs from filtering ports for all customers. They almost all actively filter at least port 25, 139 and 445 regardless of the actual transport. So I'm not sure "blocking service hosting" is the actual goal here.
The problem seems to be that all of the large and wealthy nations of the world have made the necessary huge investments into IPv6 while many of their smaller neighbors and outlying countries and islands have struggled to get any appreciable deployment.
It should be a UN and IMF priority to get IPv6 networks deployed in the rest of the world so we can finally start thinking about a global cutover.
In many developing countries IPv6 adoption is far and sometimes networks are IPv6-only, because IPv4 is expensive and they have relatively little addresses compared to users...
You can see southeast Asia is pretty green on the map of the post.
A UN priority!? They have real issues they should be dealing with like the life and death of millions of people
To be fair to the grand parent, the International Telecommunications Union is a specialized agency of the UN and actively promoting IPv6: https://www.itu.int/en/ITU-T/ipv6/Pages/default.aspx
I think it's fine if they have more than one priority.
>> It has barely hit 50% and it's already plateauing.
Well, the curve has got to level-out at 100%.
No, it can level out below that and is (as the parent was saying).
How far below is the question. It could level out at 60% - that is believable. However it can't level out at 99% - Somewhere around 95% major sites will decide IPv4 isn't worth supporting and they will just ignore that final 5% of customers, which will force them to upgrade - which in turn will give others confidence to remove their final 4% of customers - until IPv4 dies.
There are still ascii dialup bulletin boards out there. and operating model T’s. IPv4 will be around for longer than you or I.
There are also still Telex and X.25 networks around there, not to forget the whole public telephone network!
But at some point, getting a native connection to all of these started becoming increasingly rare, and now these are largely emulated/tunneled on top of IP. The same can happen for IPv4.
> IPv4 will be around for longer than you or I.
That's a matter for the legacy network on the other side of the internet to handle, as it converts my IPv6 packets to IPv4.
That’s indeed what they’re saying, but they’re simply wrong which is obvious from looking at the graph and accounting for seasonal variation.
> Also, notice how Android and iOS don't support turning off IPv4.
You can trivially connect an iOS device via IPv6 only.
Can you share details on how one trivially connects via IPv6 only? I see no option in iOS Wi-Fi settings to do this, and I think it's reasonable to expect not to have to turn off IPv4 on my access point to test IPv6-only networking.
Presumably thats with the network having a PLAT somewhere if you’re relying on CLAT for any v4-only connections when you use safari
I think they're saying you can't force disable ipv4 entirely.
I’m going to guess no one responding to me has actually tried connecting to an IPv6 only network because it works without incident. Will your apps? Who knows - apple hasn’t always been great at enforcing that.
> It should be ISPs doing that to prepare for the transition.
Yeah, I dont get why more ISPs don't offer carrier-grade NAT64 instead of the typical CGNAT
NAT64 doesn't make sense for consumers. There are too many apps that hardcoded IPv4 in their code. People are going to complain that their old Xbox games don't work.
For most people, dual stack works fine. For mobile, the solution is 464XLAT that translates locally. There is MAP-E that does translation on gateway with IPv4 on local network.
For businesses, NAT64 makes more sense cause they can control what software is running. Even there, usually have to make IPv4 subnet for the old printers.
> There are too many apps that hardcoded IPv4 in their code
That would work over CLAT, which most operating systems support. Steam has this issue, clat works around it while still using a ipv6-only net.
https://github.com/ValveSoftware/steam-for-linux/issues/3372...
In parts of the world with fewer IP addresses they already are. My ISP _only_ offers MAP-E access to the IPv4 internet for anyone not grandfathered into an older plan.
Worst migration plan ever.
I don't want IPv6. Why would I? It's like a permanent global cookie. You're uniquely tagged and identifiable on every website you visit.
>it's in their best interest to ensure users can't host services without them.
They'll just keep blocking port 25. IPv6 won't change anything with regards to self hosting.
My OS gives me IPv6 privacy addresses out-the-box which rotate every few hours.
The prefix is your globally unique identifier. "Privacy addresses" provide zero privacy.
“Privacy addresses” are named because in the beginning, your auto-generated IPv6 would incorporate your hardware MAC address verbatim, and many people consider the MAC address to be PII.
Hard to believe the committee thought that was a good idea.
> You're uniquely tagged and identifiable on every website you visit.
Almost every modern OS enables IPv6 privacy extensions, ie address randomization, by default.
On the last 64 bits, yes. On mobile phones, the first 64 bits may be fixed. This was something I argued against when I was at Vodafone Group, but didn't get any traction. That was a while back, but I'd assume that this is still the case, and that mobile phone addresses can be used for tracking.
The prefix is your globally unique identifier. "Privacy addresses" provide zero privacy.
Just like IPv4, then. Ultimately some part of the address has to identify the physical router.
No, not just like IPv4. My IP address is 192.168.0.23 right now, as are millions of others. Add in CG-NAT from my ISP and I do not have a globally unique identifier.
Zoom in on that graph using the controls at the bottom, and you'll see a repeating pattern of crests and troughs, weekly. There's about a 5% difference between the crests and the troughs: the crests are hitting the 50% line or just below it, and the troughs are down around 45%.
The real question is, why are the crests so predictable? They're always on Saturdays; Sunday dips down a little below the crest, then Monday-Friday is down in the 45% range before the next Saturday jumps up to 50% again. (Fridays usually have a small rise, up to the 46-47% area).
My theory: mobile access rises on weekends. People are more often accessing Google services from their work computers Monday-Friday, but on Saturdays and Sundays most (not all) people are away from the office. Many of them will end up using smartphones rather than laptops for Internet access, for various reasons such as being outdoors. And since smartphones are nearly all using IPv6 these days, that means an uptick in IPv6 usage over the weekends.
It's not just mobile networking but residential ISPs in general have better IPv6 support. In the US, Comcast was one of the first big IPv6 deployments, in Europe CGNAT+IPv6 is common in many places.
Meanwhile corporate IT for business and education networks have less incentive to upgrade and typically lag behind in adoption in general.
I've been running full dual stack for >15 years now. It has become second nature by now and I'm slowly testing IPv6 mostly, but so far it's just easier to deliver dual-stack to all users instead of dealing with workarounds to make the last few non-IPv6 capable services work without native IPv4.
This matches what I've seen too. Mobile carriers have been way ahead on IPv6 - T-Mobile in the US has been IPv6-only with NAT64 for years. The weekend pattern is pretty much a smoking gun for mobile being the driver. It also explains why the Google metric (which skews consumer) looks so much better than the Wikipedia numbers someone else posted (35% IPv6) or the server-side adoption stats from Common Crawl.
Residential vs. business. If the graph was hourly and per country, you'd see the same rise every morning and drop every evening (likely by more than 5pp).
Your mention of per-country reminded me that Google is probably using UTC for those timestamps. 11:59 PM UTC is 8:59 AM the next day in Japan (UTC+9), so Japanese people getting online early Saturday morning would register as accessing Google services on "Friday" until the time hits 9:00 AM in their timezone. Likewise Korea (also UTC+9) until 9:00 AM local, China (UTC+8) until 8:00 AM local, Vietnam (UTC+7) until 7:00 AM local, and so on.
Which means that if Japan, Korea, China, Vietnam, and other east Asian countries have a higher IPv6 adoption in residential vs business ISPs, then their Saturday-morning Internet access is likely part of the 1-2pp bump on Fridays in this chart.
P.S. Also, none of Japan, Korea, China, or Vietnam use daylight savings time (very sensible of them), so their UTC offsets are the same year-round. So their Saturday-morning contributions to the Friday chart will not vary from month to month due to timezone slippage, because they will never gain nor lose an hour relative to UTC. It might vary a little with actual seasons, as the sun rises later or earlier... but so many people use alarms to get up at 6:00 AM no matter what the sun is doing, rather than rising with daylight, so the amount of early-morning Internet access in winter months is not going to change significantly compared to summer when the sun rises earlier.
If GitHub flipped a switch and enabled IPv6 it would instantly break many of their customers who have configured IP based access controls [1]. If the customer's network supports IPv6, the traffic would switch, and if they haven't added their IPv6 addresses to the policy ... boom everything breaks.
This is a tricky problem; providers don't have an easy way to correlate addresses or update policies pro-actively. And customers hate it when things suddenly break no matter how well you go about it.
[1] https://docs.github.com/en/enterprise-cloud@latest/organizat...
Having been messing around personally with getting my own blocks of IP addresses and routing[1] - I've become terrified at the idea of implementing access control based on IP address.
Unless your own organisation in the RR has the IP addresses assigned to you as Provider Independent resources, there just seems to be so many places where 'your' IP address could, albeit most likely accidentally, become not yours any more. And even then, just like domain names, stop renewing the registration and someone else will get them - I was that someone else recently...
[1] AS202858
Oh, cool! that's on my bucket list as well. I am still grappling with some concepts, though.
Do you have a writeup of your setup somewhere or can you recommend some learning materials ?
It's fun and has now become an addictive rabbit hole - trying to get packets from one location to the other in the fastest, most direct way (and at hobbyist budget level).
Initial writeup based on IPv6: https://abarber.com/Setting-Up-ASN-IPv6-Routing-BIRD-Teltoni...
Have been having fun recently with an IPv4 block and Asynchronous routing, working on writing that up right now :)
Thank you for sharing! I really enjoyed reading that and learned a something too.
And thanks for the feedback - I've really been trying to write more so always nice when someone takes the time to read :D
Anyone who relies on IP filtering for security deserves to have it broken. Change my mind.
I'll take that bait ;-)
IP filtering is a valuable factor for security. I know which IPs belong to my organisation and these can be a useful factor in allowing access.
I've written rules which say that access should only be allowed when the client has both password and MFA and comes from a known IP address. Why shouldn't I do that?
And there are systems which only support single-factor (password) authentication so I've configured IP filtering as a second factor. I'd love them to have more options but pragmatically this works.
Why are you (re-)implementing client security on provider end? If a client requires that only requests from a particular network are permitted... Peer in some way.
I do understand the value of blocking unwanted networks/addresses, but that's a bit different problem space.
Defense in depth is a thing but I agree that relying on it is not a good idea.
Defense in depth is not the point, zero trust networking is.
Actual curiosity, how would the new filtering be/is?
I've done a lot of IP filtering, it's what a lot of systems and services allow us to, so I'm curious what the IPv6 mechanism is
IP filtering + proper security is better than just having the security.
There's value in restricting access and reducing ones attack surface, if only to reduce noice in monitoring.
If you can't handle sites switching to ipv6 in 2015 (ten years ago) your security plan is garbage.
Thanks to the trend to SASE like Palo Alto GlobalProtect or ZScsler this practice is not a good idea anymore. Speaking of ZScaler, they are still IPv4 only, right?
> providers don't have an easy way to correlate addresses
Yes, they do. It's called DNSSEC.
Sometimes TCP/IP is a leaky abstraction, and recently ipv6 peeked through in two separate instances:
- In a cafe wifi, I had partial connectivity. For some reason my wifi interface had an ipv6 address but no ipv4 address. As a result, some sites worked just fine but github.com (which is, incredibly, ipv4-only) didn't
- I created a ipv6-only hetzner server (because it's 2026) but ended up giving up and bought a ipv6 address because lack of ipv4 access caused too many headaches. Docker didn't work with default settings (I had to switch to host networking) and package managers fail or just hang when there's no route to the host. All of which is hard to debug and gets in your way
You can solve this issue if you have one server with ipv6/ipv4 you can run NAT with Jool and connect ipv6 only servers to that. Like Android does.
I wish hosting providers would give you a local routed ipv4 on ipv6 servers with a default NAT server. It is not that expensive I move 10Gbps "easily" and they could charge for that traffic.
> I wish hosting providers would give you a local routed ipv4 on ipv6 servers with a default NAT server.
You mean like AWS NatGW https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gat...
30 USD/month and 0.045 USD/GB for ingress it is ok if you are big. It is a cheap service to build yourself. I do feel the pain of it being hard to get IPv4 minimal connectivity on ipv6 only hosts, i.e. for me a 1 USD/GB would be fine.
Those are still per-customer and require you to dedicate an entire IP address to it. That's overkill for a server which mostly talks over ipv6 but needs to connect to an ipv4-only service like Github once in a blue moon.
Any services like this for Hetzner?
The cafe WiFi thing (getting IPv6 only, no ipv4, on a public network) used to happen quite often to me on macOS. I never figured out why, and I haven’t noticed in a while.
This google metric measures adoption in access networks, but at this point I feel more interesting metric is adoption in services.
One such stat is here:
> adoption ranging from 71% among the top 100 to 32% in the long tail
https://commoncrawl.org/blog/ipv6-adoption-across-the-top-10...
Getting full coverage on AWS (/GCP/Azure) and few other key services (GitHub...) would be significant here imho.
Yeah, a large portion of those ipv6 Google searches are afterwards connecting to an ipv4 host.
I doubt it honestly. Most people are connecting to sites like Youtube, Instagram etc., which do actually support IPv6.
It's how I get 60~80% IPv6 traffic on my home network. A great portion of it was because of my mom watching Youtube.
Even when you discount the services run by FAANG, for personal sites, Cloudflare and GitHub Pages (but surprisingly, not GitHub itself) support IPv6 and enable IPv6 support by default.
Actually yeah, especially if you measure it in bandwidth, and even if you just measure it in requests
great resource. Common crawl is a goldmine
It's only a matter of time before laptops get 5G. Macbooks have been rumoured for a while to get cellular modems. [1]
This will probably help adoption. On the one hand it will generate more IPv6 traffic. On the other hand it will expose more developers to IPv6; which will expose them to any lack of support for IPv6 within their own products.
[1]: https://9to5mac.com/2025/08/14/apples-first-mac-with-5g-cell...
Dell, HP and Lenovo have had laptops with cellular modems for maybe 15 years at this point.
I can confirm this. I work at an e-waste recycling company, and the vast majority of my inventory is corporate IT decommissioned gear. About 1 out of 10 laptops I tear down has a cellular modem, going back to about Intel Core 5th gen.
I've had laptops with cellular modems built in going back to Pentium IIIs. The Compaq N600c had a "multiport" bay on the lid, one of the options was a GSM modem.
Jesus, what a waste
*A few select models got celluar modems.
I have owned several Dell, HP and Lenovo Laptops in the past 15 years and I have never had a cellular modem.
When Apple makes a change like that it impacts a lot of customers because they have way fewer skews.
I've never had a modern laptop with a cellular modem, but every one I've owned has supported them internally. Even when they aren't provisioned with them, they're usually still supported as aftermarket options.
Yeah, but any given technology hasn't been invented yet, until Apple releases it.
| Macbooks have been rumoured for a while to get cellular modems.
Maybe they are finally coming, however the rumors are older then the iPhone. Example from 2008: https://pcr-online.biz/2008/11/03/3g-macbooks-on-the-way/
> It's only a matter of time before laptops get 5G.
So you want laptops to cost <whatever the laptop costs> plus a measly 19.99/month for internet connectivity?
What's wrong with just tethering to my existing phone?
Thats quite surprising thing to me and weirdly obvious.
If you are single, have a phone contract, you would need some extra contract for a landline internet and wifi router because thats what a lot of people just do and now they can just add an esim and pay a little bit more.
Interesting that this sounds/feels a lot more right or useful than it did 5 years ago.
5G services all give you an ipv4 too, so devs won't be exposed to lack of v6 support.
I can't imagine a worse privacy nightmare. Always on backdoored baseband in 5G with a unique permanent IPv6 address assigned to the machine. Okay, maybe it could be worse if each user account is assigned its own unique IPv6 perma-cookie.
You're thinking of MAC addresses. Machines don't have permanently-assigned v6 addresses, rather the IP is assigned by whatever network they're currently attached to and will change based on that network's whims, just like it does in v4.
As if people doesn't already carry always online machine in their pockets
> Okay, maybe it could be worse if each user account is assigned its own unique IPv6 perma-cookie.
They will. One from facebook, one from google, one from tiktok, several from Palantir and its partners...
I get an IPv6 address from my ISP (a /56 I believe), but I wish there was some good information on how to update my OpenWRT VLAN configuration, routing, and firewall rules to be able to support native IPv6 on my devices. Would love to be able to have direct IPv6 connections to the internet from my devices, but I want to make sure I can do it safely.
You only need to set nothing and it should setup ipv6 on all downstream vlan interfaces. For static prefix I'd you can set ip6hint per vlan interface. For each vlan interface you need a stanza in the DHCP config file. And regarding firewall, as with the default lan zone you might need to add new zones with the vlan interfaces and configure forwarding rules. That's it.
This was surprisingly complicated for me on Altice/Optimum, which is why my home didn't have IPv6 for a while even after they started provisioning.
We actually have a /128 address only, and had to tweak several settings including enabling IPv6 masquerading (NAT).
I haven't the slightest clue why they didn't give us a block.
Yeah, I'm in the same boat. I like the idea of being able to remotely connect to anything on my network, but I know just enough about networking to be dangerous, and don't trust my self to set it up securely, so I have IPv6 disabled on my router. With IPv4, it's physically impossible to mess up the firewall and NAT settings enough to make local devices public.
NB: this is not "IPv6 traffic crosses the 50% mark" but "availability of IPv6 connectivity among Google users", which is a very important difference. This means roughly half of Google users have IPv6 capability, which does not 1:1 correspond how much traffic is actually transferred over IPv6, which is what this submission says in the title.
Yeah and this distinction explains the fact that because China's Great Firewall blocks Google, this website shows 4.66% adoption as a reflection of that. I think China's IPv6 support rate is actually much higher than that, maybe a little over 50% because of its central initiative to increase IPv6 adoption?
EDIT: Apparently it's 77% https://pulse.internetsociety.org/en/news/2026/01/china-hits...
"The graph shows the percentage of users that access Google over IPv6."
How would Google know what users have the potential for IPv6 if they are not using it?
Right, but in most situations clients will prefer IPv6 if its available, so if they have access, they almost always are using it, at the very least from their local network.
It also means you're excluding China, who has has it as a long-term priority to deploy IPv6 and have made huge strides.
Wouldn’t it be close? AFAIK modern network libraries on modern OSs default to IPv6 when available.
As a French national, I am surprised to discover we are topping the charts according to this analysis.
Does anybody know why that might be the case? What's the story of IPv6 deployment in France?
The regulatory body, ARCEP, has been very proactive since 2002 (!) on IPv6. The recent uptick is due to IPv6 obligations bundled in the 5G spectrum licences.
https://www.arcep.fr/la-regulation/grands-dossiers-internet-...
Maybe my guess only, but France has its bit of a technological centralization. I mean, a lot of people use internet from operators like "Orange" / "Free", and in contrast to other countries, routers provided by the operators in France do not suck. The routers are OEM, but overall quality you get from them is on-par with Ubiquity/Mikrotik.
This gives operators a benefit of the vertical control for the whole ecosystem - from top to the bottom, including intricate parts of protocols and routing. And France, in contrast to other countries, does not suck here too - operators usually do a good job of meticulously maintaining their assets.
My personal impression is that this is the result of several cultural factors:
1. Ingrained respect of privacy, private property, and a peace of heart as they call it. As a practical result of that, you do not get spammy messages and ads from operators, banks, etc. You may get some, like 3 or 4 discounts/offers in a year. Compare that to other countries where you can easily get 10s/100s messages like that in a single day. In other countries, instead of upgrading the infrastructure, people are busy with spamming each other.
2. The harsh oceanic environment with hurricanes and storms fosters an appreciation for reliability and functionality. It also encourages a certain frugality: every cent matters. As a result, people tend to develop a strong sensitivity to situations where form is prioritized over function, and such approaches are quickly dismissed as impractical. This gives a certain internal freedom of being able to see through things to determine what they are in the long run and not what they appear to be on the surface.
3. French people don't like to overwork outside of working hours. So choosing something like IPv6 over IPv4 seems like a natural forward-looking investment for the future where you can have less maintenance burden and thus you can devote more time to enjoying other things in life.
Having all those things combined, it's not hard to see why France chose IPv6. It's a natural choice there and it's imposed by survival.
P.S. I've spent some time in France, but was born in another country.
This is probably not the real reason, but I find it interesting that France had Minitel (^1) before and later had to switch to the Internet, and then later became the fastest country to complete the IPv6 transition. So perhaps they had an engineering culture that was prepared for the possibility they would have to upgrade the entire network on a nationwide scale.
^1: https://en.wikipedia.org/wiki/Minitel
I worked with the internet society to mobitor ipv6 adoption for the top million sites ipv6matrix.org it's broken down by country so might answer some of your curiosity
I'm wondering the same thing for India. Not the top but looks surprisingly surprisingly high. Perhaps I'm reading the data wrong.
Reliance Jio deployed cheap native v6 and tool massive market share. They single-handedly moved the market.
It's been discussed on the apnic blog and at meetings heaps
Adding on. Jio was a late entrant, so they could not get significant ipv4 address space without great expense. They deployed as mostly v6 with a tiny CGNAT. They also had an extensive 'pre-release' offering at zero cost to subscribers which got them a huge number of subscribers and clout to encourage internet services to offer ipv6.
India has about 1.5 billion people, and has only recently been getting most of them online. Less IPv4 legacy, and it has always been obvious that IPv4 was never going to be ‘enough’ to actually onboard everyone anyway.
When I lived in India, everything had IPv6 out of the box.
Technical literacy, hacker culture, and culture of well-considered infrastructure, have been French characteristics - at least, historically.
Has something changed for the worse?
It amuses me to see that according to the map, France is best in class or close to be, while just a few weeks ago, my ISP in France stopped providing me IPv6 connectivity…
The story is that at the beginning I had IPv6, and a shared dynamic IPv4 behind a CGNAT, I asked for a rollback to a full duplex static IPv4 and for three years I had both a static personal IPv4 and an IPv6. A few weeks ago my router went down and since it went back up, I no longer have an IPv6 address. I called my ISP and they explained that I could either have IPv6 or a static IPv4, but not both, and that it's abnormal that I had both for so long… welp, it's sad to see IPv6 but getting it back is not worth abandoning my static IPv4 and going back to a dynamic shared IPv4.
You might be interested in https://tunnelbroker.net/ and https://route64.org/ although the later looks a little shady and I haven't tried them.
A cheap VPS or one with spare bandwidth with > /64 that is properly routed (some providers do NDP for some reason) and a Wireguard tunnel would also get you a simple DIY solution.
Are you with SFR? I also seem to only have a static IPv4 (I don't pay for it, but it's never changed in the lifetime of the connection). I asked for an IPv6 but they said it was not possible/difficult.
Yep, with "RED by SFR" specifically.
Among all the major French providers, SFR lags far behind its competition unfortunately
I know, but at the time I had to choose an ISP, they were the only ones with an offer with just internet (and a phone line), all others ISP forced a bundle with dozens of TV channels that I don't need along with their internet access subscription. They were also the most competitive price wise, and other than this problem (which is new for me, I had an IPv6 and a static IPv4 until a few weeks ago), I'm satisfied with the service :).
Is most of that due to mobile?
The real migration challenges are in the server side/consumer home internet space which I'm not sure if there are clear stats around the adoption there.
I think IPV6 is a great example of over engineering, trying to do too much in one iteration. In an ideal scenario this could work, but in the context of large scale change with no single responsible party, it usually doesn't work well.
CloudFlare Radar has stats for desktop (34%) vs mobile (46%) adoption: https://radar.cloudflare.com/explorer?dataSet=http&groupBy=i...
On the server side, everyone is moving behind CDNs that support IPv6 by default.
On the consumer home internet side, consumer ISPs are slowly one by one lighting up IPv6, and it just works since consumer routers are mostly auto-configure (often literally controlled by the ISP). Mobile is largely IPv6 already.
The biggest challenge is in corporate/academic/medium-size business networks where they have lots of obscure subnets and firewall rules and old software and hardware running a critical task under a dusty table somewhere.
The problem has nothing to do with over engineering, or really anything to do with the actual contents of the IPv6 standard. It is just devilishly hard to make any backwards-incompatible change to layer 3, and address expansion is always going to be backwards incompatible.
There were some choices of v6 that made it extra hard, like declaring all v4 addresses no longer valid in v6, or making slaac default
IPv4 addresses are in fact a subspace of IPv6 (that's NAT64). They were not by fiat declared invalid. The actual thing I think you're complaining about - the necessity for NAT64 at all - is unavoidable, because you need a NAT/protocol-translation layer for packets to actually move between the new address space and the old one.
SLAAC-by-default is not, in my experience implementing IT automation, an actual barrier for adopters. You have a router sending out RS instead of a DHCP server, to an admin this is not a meaningful change.
NAT64 is a temp bolt on and also not the same thing. If I own 1.1.1.1 in v4, that doesn't mean I own some equivalent of 1.1.1.1 in v6. They had router nat64 and relay nat64, both with dealbreaker problems.
You don't exactly need a translation layer. If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual. Then after v4 is abandoned enough, I can sell 1.1.1.1.2:: to someone or use it instead of NAT.
SLAAC is a good design as a non-default that people who know what they're doing could enable, but a lot of people don't even want public v6 addrs for hosts, they just want NAT/DHCP.
> You don't exactly need a translation layer. If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual.
Think about this on a concrete, packet by packet level - I, from a v6 network, with a 128-bit address that cannot be represented by IPv4, decide to open a connection to 1.1.1.1. 1.1.1.1 doesn't have v6 set up, and so can't read my v6 packet and craft a response packet, because its address is invalid in v4. We need a gateway in the middle that will translate the packets from one format to another and perform the NAT function from one address space to another. This is an irreducible complexity.
> a lot of people don't even want public v6 addrs for hosts, they just want NAT/DHCP.
People don't care about whether their address is public or not, they want connectivity. SLAAC gives that to them; it is you that are insisting on adding complexity for the sake of having a non-routable address. As a user, I enable IPv6 on my router and go on my merry way; as an ISP, I assign my customer's router a /60 or /56 via DHCPv6 instead of a /24 and go on my merry way. Running an IPv6 address allocation system is a an easy, solved problem and has been for decades.
The hard problem is dual-stacking, and there is no way around that.
I mean, you own 2002:101:101::/48. You also own ::1.1.1.1, ::ffff:1.1.1.1 and 64:ff9b::1.1.1.1.
> If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual
That's not really how routes work. Or DNS.
I think you're mainly arguing we should import v4's allocations into v6, but about the only benefit is that people don't have to bother requesting new allocations. It doesn't help with any other aspect of the transition, and there are good reasons to avoid doing it -- the v4 address space is highly fragmented and also very unfairly allocated.
Plus we have plenty of people saying we should take back v4 allocations from companies that own them. That's not possible, but _not_ giving owners of v4 /8s an entire 1/256th of the v6 address space certainly is.
I was wondering how much is "last mile" between end-user devices and the next hop vs. within cloud networks, but the bit about mobile is a good point.
It'd be annoying even in the scenario where it got quickly adopted. Complicated spec, user-unfriendly addresses, unclear defaults.
Precisely the reasons for lack of adoption I would say.
The question is, "what will the graph look like in the next 10 years?"
I get the whole s-curve trend but if I squint at 2017, there is an inflection to slow the s-curve down.
Annoyingly, when setting up service with a fiber company in the last couple months, I explicitly asked about IPv6 connectivity and they said, "yes." Turns out "yes, but not in my region."
>I explicitly asked about IPv6 connectivity and they said, "yes."
ABC, Always Be Closing.
It's been amazingly linear since 2014.
amazon.com needs to get with the program. Still IPv4 only.
Just in time for ipv8 - https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
This proposal is absolutely wild.
this is so dogshit oh my god
Current submission title:
> IPv6 traffic crosses the 50% mark
Graph description:
> The graph shows the percentage of users that access Google over IPv6
There are reasons to expect both much more and much less traffic per user on IPv6 compared to IPv4...
Meanwhile: one of the major mobile network in my country announced cisco collab/ipv6 ~5 years ago, but still doesn't provide v6, just v4 CGNAT.
Personal web server running dual stack since early 2010s currently sees 18-20% v6 traffic. When split by type, counting only mobile users it reaches 30% at peak.
Bot/crawler traffic is ironically 100% v4.
Meanwhile: enabled h3 in september last year for the fun of it, instantly at >40% traffic by request count, passing 50% since the beginning of the year, h2 accounting almost all the remaining traffic and plain ssl/http requests <1% being just bots.
Maybe the best anti-scraper/LLM protection is going IPv6 only. I'd do that on my website, but I'm afraid some clients might not connect.
I consistently get 100x as many captchas from google over V6 as over V4, on many different networks: it is obnoxious and obviously broken on their end.
IP reputation is a tough problem with a lot of establishment behind v4. Even if they were to build up v6 reputation, since v6 addresses are cheaper, wouldn't they have lower rep?
The "reputation" concept has to be applied to network blocks in IPv6, because of privacy addresses, and they very clearly aren't doing that for whatever reason. I get at least one captcha a day from a stock Android phone that's been connecting from the same damn /64 for almost a whole year.
But there are way more /64s than /32s. They could apply it to /32s in ipv6, but then customers would share rep unless ISPs lease out /32s instead. Unfortunately gotta pay to play.
That could never work, my entire ISP is a /32
I'm guessing because the spec defines a network as a /64. Couldn't the ISP buy more space if they wanted to?
Finally https://www.metaculus.com/questions/9558/50-of-users-access-... can resolve!
Everyone's saying progress is slow, but maybe this is just how long it takes to do massive decentralized global migrations affecting billions of people. What are we comparing against? Maybe the ICE-to-EV transition?
For example, compared to migration from 3G to 4G networks. As I understand, from the launch of 4G to complete shutdown of 3G it took around 12—14 years.
A reasonably fair comparison. The ISPs had a much stronger incentive to finish the migration, though, because the 3g spectrum could just get turned around and used for 4g after rollout. IPv6 doesn't really have that strong of an incentive structure now that CGNAT is a well-developed technology.
World IPv6 Day was in 2011, so 15 years since then. This is also requiring a consumer hardware and software upgrade on both the client and server (resource they're accessing). GitHub doesn't have to implement 4G support.
One major difference in the 3G->4G and now 4G->5G conversion was that was largely a single-party change in the end to actually implement. The client and the server hosting an application doesn't care about whether that traffic is over 3G or 4G or IP over Avian Carriers as long as the packets get there in a reasonable time. Going from IPv4 to IPv6 requires lots of very different players to all work together to make the transition, meanwhile for a carrier to go from 3G to 4G its largely on them and their direct contractors.
Latin1 to UTF8
And I still, to this day, see mojibake from time to time.
The exception that proves its success
Currently my IPS provides IPv6, but I set up my firewall in the access router of my home LAN to block all IPv6 in both directions.
- I don't want to have a permanent global unchanged ipv6 as in id of my traffic.
- IPv6 privacy extensions would change that but then I can not reach my two devices I do want to reach from outside anymore as my access router only supports DynDNS for its own address and no NAT in IPv6
And how exactly is your NATed ipv4 address better? This seems backwards.
Router has a DynDNS function. I am using a reverse proxy for multiple services, but this only sets up router IP and IPv4 NAT port forwarding to the reverse proxy.
So what would be the correct setup with IPv6 when using privacy extensions?
I don't see any benefit in allowing IPv6 traffic or using IPv6, but a couple of new problems coming up with it.
Privacy extensions are additional addresses that are used by default for outbound connections. You still have the non-privacy address, which doesn't change; put that one into DNS.
This approach prevents outbound connections from leaking the address needed to connect to your servers. On v4, it's likely that any outbound connection from your network gives the server the IP they need to do that.
My ISP changes the prefix on a regular base (and on request)
So you'll never have a permanent unchanging v6 address to ID your traffic with.
Privacy extensions are orthogonal here; they only affect the suffix, not the prefix. As for dealing with a changing prefix... I'm afraid you'll just have to find some way to automate the DNS updates. You can do it with a program running on one of the servers -- I can't suggest a specific one offhand since I have a static prefix and haven't needed it, but they do exist.
How often does your IPv4 address actually change?
Never checked. But it does change once in a while. The router has a dyndns function which updates a DNS entry, but only for the router itself. But this is sufficient for the NAT port forwarding.
Ok, so most of the time you are trackable by your public IPv4. The situation is not much better.
Let's say when your ipv6 prefix changes it is almost the same situation. Only that ipv4 bundles all traffic of all devices on one ip which obfuscates a bit.
But having the ipv6 prefix change you get a pile of problems (DNS, firewall), you don't have with ipv4.
The IPv6 prefix changes are disruptive, I agree. My prefix has been stable for a couple years, but on another ISP it would change every few months and was certainly annoying.
My next project, IPv6 in my homelab. It will be a challenge but it is time. My ISP gives me a static /48, I should use it.
I recommend going through Hurricane Electric's multiple-choice tests. It's not exactly a how-to guide or course, but it'll mention all of the terms and technologies you need to look up to get things right. They'll even send you a free T-shirt if you make it through all of them.
The most difficult parts for a homelab in my experience is getting Docker to play nicely. All of the other stuff sort of just works these days. Even things like using DHCPv6 prefix delegation to obtain a routable subnet is almost trivial with how well-supported the protocol is with modern networking software.
Where do I find that? https://www.ipv6.he.net/ has an invalid certificate and is the first result on Google.
Their www sub-subdomain is broken it seems.
https://ipv6.he.net/certification/ has instructions on how to get started.
You need to omit the "www" subdomain: https://ipv6.he.net
I wish EU make it mandatory at least for all ISP to make mandatory support for IPv6 by end of this decade. I think that would push the needle even globally.
Setting up my own server (migrating off GCP LB) taught me so much about networking. I was especially surprised that providing IPv6 is such a performance boost for low bandwidth phones since they mostly only operate on IPv6 by now and IPv4 needs some sort of special roundtrip.
Cool! Could you give some concrete examples of apps or traffic patterns where you think IPv6 may noticeably improve performance on phones? Are you mainly referring to NAT traversal during connection setup, or to something that also affects traffic after the connection is established?
Many mobile ISPs handle v4 via NAT64 or CGNAT. Routers capable of doing those are far more expensive than regular routers, so there tends to be fewer of them. v4 traffic has to travel out of its way to reach one of those routers, whereas v6 traffic can be handed off sooner with a more direct physical path.
It affects anything where latency matters, e.g. from Facebook: "We’ve observed that accessing Facebook can be 10-15 percent faster over IPv6." (https://engineering.fb.com/2015/09/14/networking-traffic/ipv...).
I am in the middle of building infrastructure in GCP. The workload is your typical stateless web + db workload.
As of now, there is no way to have a 100% internal ipv6. Many of the services, including CloudSQL or the connection between external and internal load balancers do not support ipv6, even when the external load balancer support ipv6 forwarding rules at the front end.
This means that careful internal ipv4 allocations still matter.
I think its incredibly ironic actually. The place where IPs are burned through rapidly (internal) is forced to use v4. (and, potentially even a subset of it, RFC1918; likely conflicting with some large company or service if they decide to plumb it together later- or you burn publicly accessible IPs in the limited address space)
But the one interface that touches the internet can use v6: the one with a functionally infinite address space.
GCP encourages customers to use Class E (240.0.0.0/4) as internal IPs. That helps.
What I am building won’t exhaust that, but I hear some customers are blowing through even that.
PSC has a builtin NAT. That also helps stitch things together.
… or we can have ipv6.
I had the same issue a few months ago on AWS. All I want is a server (that pulls a container), a database, and a load balancer. It's all going behind CloudFront so there should be no need to pay for an IPv4 address for any internal machine. Couldn't do it. Since then I saw that there was some movement on IPv6 for RDS but IIRC there was still some other blocker.
> so there should be no need to pay for an IPv4 address for any internal machine
At what level did you need to pay for IPv4 addresses in this stack? You should have been able to make this work with a private IPv4 space, have the ECS services be dual-stack and be on both the v6 network and the v4 network to talk to the database server, have the ALB be v6, and then have Cloudfront be v6. If you wanted, you could also just ignore v6 for the ECS services and have them just live in that same v4 subnet entirely.
I could be wrong (and please tell me what I'm missing) but you shouldn't have had to pay for IPv4 in this case. I do just wish RDS (and so much else) would just support IPv6 though, you shouldn't need to have a bunch of extra subnets just to talk to your database.
Can someone reconcile for me the constant chatter about how IPv6 isn't getting impemented, versus this result that more than half of all traffic (as measured by google) is now IPv6?
It sounds to me like its a tool which is available to be used when needed and when no better workarounds exist, and it is slowly but surely being adopted as needed.
Most of the chatter comes from the peanut gallery who have no real insight on what ISPs and other large networks are actually doing.
This. "Vibes," vs. data.
As a sometimes chatterer, it's a mix of complaining about the annoying changes in v6 that weren't just lengthening the address fields, pointing out that the migration is taking forever, and implying a less disruptive design could have rolled out faster.
For a long time, there really was next to no progress. Between the introduction in 1996 and about 2011, there was very little adoption. And since 2012 when pushing really started, we're at about 50% globally, with large variance by country and network type. 15 years between creation and real deployment seems like a lot, and 15 years of deployment getting to 50% also seems likes a lot.
But wikipedia says touch tone dialing was first offered to consumers in the 1960s and didn't become majority until the 1980s, so maybe 30 years isn't that slow.
Are any ISP's or corp intranets doing IPv6-mostly style networks yet: https://www.ietf.org/archive/id/draft-link-v6ops-6mops-00.ht...
That seems to be a promising approach.
T-Mobile does: https://www.internetsociety.org/deploy360/2014/case-study-t-...
They use 464XLAT, basically NAT64/DNS64 with some extra cooperation on the OS’s part for backwards compatibility with apps that hard-code IPv4. You get only a v6 address, and your OS basically synthesizes an v4 network on your device in cooperation with their NAT64 router. But all the bytes going from your device through to their towers are ipv6. Talking to a v4-only website uses carrier-grade NAT64 when leaving the t-mobile network.
Additionally, their fixed-wireless product gives you a physical CPE that does the CLAT (NAT46) side of the 464XLAT.
To the local network, it looks like there's native IPv4, but it's translated to IPv6 by the gateway, and sent to the "nearest" NAT64 PoP to be translated back and sent along its merry way.
According to https://www.ipv6.org.uk/wp-content/uploads/2023/11/13_IPv6-M... , Google is.
The author of the RFC is the author of the slides.
Random related data point: for HTTP requests to Wikipedia (and related) for the past 7d, the IP protocol split is roughly 35% IPv6 / 65% IPv4. (this is counting by-request, so heavy usage from a small number of IPv4s can skew it).
> heavy usage from a small number of IPv4s
Basically, all crawlers.
If be curious to see what the IPv4/IPv6 breakdown looks like when looking at HTTP/2 and HTTP/3 connections only, which should exclude the vast majority of crawlers.
My interest was piqued 20 years ago, then there was talk about Internet2 with all these amazing optimisations.
Things have developed so much, a Internet2 is still going on I take it, however is more focussed on university research.
As ever a killer strength is something that draws people to a new technology, I imagine there's various demographics that benefit from use of ipv6.
Further I imagine that there are some levels of criticality which when reached are more self sustaining (dare I say it the network effect?).
I've been posting this graph over the years, and it really has slowed down hugely close to this 50%. This is a global ipv6 support, so some countries are racing ahead, others weirdly like Denmark have a stash of ipv4 addresses and seems content.
France and Germany are at about 80%, but there's the rest of the world of course.
I just recently noticed that my ISP, Frontier, quietly turned on IPv6. I know it wasn't enabled back in December, so it has to have been sometime in the past few months.
interestingly my ISP, at&t, quietly turned off ipv6. not sure exactly when it happened, i should get around to complaining about it but i hate making phone calls
The failure wasn't in the technical design of v6, but in the economic assumption. When the cost of migration exceeds the cost of 'hacks' like NAT, people will stick to the hacks for as long as humanly possible.
I wonder why Germany has a relative high adoption rate with 77%? They are normally behind when it comes to new technology.
Is it because they have more carrier NAT?
In Denmark I can get cheap 1 / 1 Gbit/s fiber, but still no ipv6 :(
We have enough IPv4 addresses (combined with CGNAT) in Denmark so the providers have no business incentive to spend money on supporting IPv6 :/
Carrier-grade NAT for home connections is pretty rare in Germany. I only know of Deutsche Glasfaser - a fairly new ISP that isn't doing too well.
It's very common. German ISPs collectively went with DS-Lite, so most of that 77% with v6 have CGNATed v4.
Somehow it's really hard to find numbers, but AFAIK at least Telekom and 1&1 don't use CGNAT for home connections, which already rules out that 77% have it.
Questions like this suggest that 1&1 do: https://forum.openwrt.org/t/solved-dsl-over-ds-lite-with-isp...
I'm less sure about Telekom. For obvious reasons, it's hard to find info in English.
My anecdata is that I'm on 1&1 fiber and I have a public IPv4 address.
German ISPs commonly seem to have an option of their "old" platform (v4 only, no v6) or their "new" one (v6 and CGNATed v4). Maybe you're on their old one? Or maybe they only use it for certain account tiers or somesuch.
I've been with 1&1 for a long time, previously DSL and VDSL, so I could have something grandfathered in - but I doubt it. Especially after the recent transition to fiber. And I am not paying for any special options.
Vodafone cable's cgnat struggles. I went v6 for home so that at least the v6 sites and my own connections avoid the congestion.
Random test site for the consumer side: https://test-ipv6.com/
0/10 in Latvia with a local ISP, fun times.
I am aware of at least 2 telecoms, one publicly traded, that have very little to no IPv6 in their core networks and only use IPv6 when they have to.
Personally I think the design of IPv6 offers very little benefit; supposedly the Dept of Defense/Dept of War holds some 175 million IPv4 addresses, with other companies also holding large allocations - that should have been addressed 25-30 years ago as an administrative matter.
To what end though? 4 billion addresses is not enough on its own, even if they were reallocated from hoarders. I think that NAT and especially CGNAT have been very detrimental to the shape of the internet, where it's nearly impossible to self-host a public service without a VPN of some kind. Needing to pay some company for the ability to host a server that isn't behind NAT is a barrier that doesn't need to exist when IPv6 has a nearly limitless number of addresses.
You're not wrong, but practically speaking, hosting a VM is so cheap and comes with the advantage of serving from a datacenter that I would never want to host anything off my residential connection anyway.
The $1 to $5 a month to have excellent, reliable connectivity (that no residential connection provides), DDoS protection, and isn't tied to my home IP outweighs any home hosting benefit in my experience.
There are 16 /8's in the class E address space that were never allocated, and 19 /8's (by my count) allocated to individual companies. If you waved a wand and returned all of that space to IANA for allocation, you would have staved off IPv4 address exhaustion by... about 3 years.
2.7 - 4.0 years, by my math, so I would agree with your assessment.
...but that's based on pre-IANA-runout rates, though, and doesn't account for the pent-up backpressure of demand. So probably a lot less, in reality.
Not even remotely worth the effort, even if there were a legal pretext for "reclaiming" IPv4 space (there isn't; there's already precedent denying it).
A hidden benefit is it's no longer possible to have another "we typed the wrong IP address" raid story. IPv6 is larger than the total number of heartbeats of all heart-bearing life that has ever existed. You either nailed the abuse address or you're raiding something that doesn't even exist.
Countries like India have higher adoption (>70%) because of 4G/5G abundance. Legacy broadband providers hold back IPv6 usage.
This is only 33 years after I took a networking class and learned all about IPv6 and the IPv4 address space crisis.
This is pretty remarkable, given that RFC 1883 is only 30 years old.
In before the dinosaurs arrive to complain about the challenges of moving to IPv6 and why NAT and IPv4 are better. ;)
What I have asked myself the last few months: I've read about IPv4 becoming sparce a few years ago. I haven't read much about it lately. And I've thought maybe the advance of cloud computing and load balancer kind of mitigated the issue of sparce IP4?
It officially started becoming scarce in 2011, when IANA, and then APNIC, depleted their IPv4 "free" pools, FWIW. Things have only gotten worse from there.
Cloud computing doesn't mitigate IPv4 issues, it just moves it around. The big cloud providers buy up any IPv4 space they can, leaving less for everyone else. The difference is that they then get to collect rent, by the hour, on any IPs their customers use.
Load balancers...yeah, actually that is a valid approach to reduce IPv4 use, assuming you mean the "reverse proxy" variety of load balancer. Cloudflare's proxy service is doing exactly this, on a pretty huge scale. (CLoudflare can then send the traffic on to an IPv6-only server, regardless of the client's protocol.) The downside is, like cloud, consolidating a lot of infrastructure into the hands of a small number of companies.
They have released the draft for IPv8 two days ago: https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
Does it mean we better put our chips on IPv8?
https://datatracker.ietf.org/doc/html/draft-wkumari-not-a-dr...
Some internet-drafts contain useful knowledge because they specify an existing protocol that never continued through the IETF process to reach the level of an informational standard. For example, TACACS+ is best specified in a dead internet-draft.
However, in most cases, internet-drafts are just that - drafts. They are usually requests for comment (ironically enough) on the author's idea. Someone had an idea and put it out there to see what other people think. Sometimes they don't even get to that stage but die immediately upon being uploaded as the author realizes they are silly.
Guess you didn’t read it.
15 years ago I would have dismissed this immediately as an elaborate troll but nowadays you cannot be sure anymore.
I'm suggesting moving on to IPvNN which requires device and ISP forced guarantees that the originator is not under the effect nor the lack of any medication or other substance, not being coerced and not using non-human assistants in content creation.
That goes for me?
Depends on the degrees of separation between you and the draft author.
I guess we both agree that both humor and sarcasm are difficult to convey on the internet and LLMs do not make the job any easier :-)
As long as no significant websites are IPv6-only qnd no significant user base is IPv6-only, why would anyone join IPv6? What proponents could do is make their websites IPv6-only. The IETF website, for instance, should be IPv6-only.
crossed 50% on Mar 28, 2026, 3 weekends back.
google published the latest data only yesterday, hence the delay.
we did it, boys!
despite the smoothbrain naysayers:
https://circleid.com/posts/20190529_digging_into_ipv6_traffi...
finally, the end of the dark tunnel of NAT is in sight, and the internet will be free once more
while it looks like its slowing down, I am pretty sure it will speed up once IPv4 get even more expensive, sites start to be hosted on IPv6 only and become inaccessible to some users that dont have IPv4. Thats surely going to put pressure on ISPs
Outside of hobbyist niche uses, sites won't start being hosted IPv6-only. The financialization of IPv4 addresses will simply get worse and be even more pay-to-play than it is now. Amazon raises the price of IPv4 and everyone goes along as a cost of doing business.
My prediction is that sites will be half-IPv6 only; backends will be IPv6 and IPv4 traffic will get proxied to IPv6 by CDNs / edge LBs. I think CloudFront for example supports that scenario, avoiding IPv4 costs (in theory).
Yeah, hobbyist niche sites like these:
https://clintonwhitehouse1.archives.gov/
https://clintonwhitehouse2.archives.gov/
If you have a big site and want as broad an access as possible I agree.
But I wouldn't be surpised if we start seeing self-hosted minecraft or factorio servers with ipv6 only.
that may be true, but not being able to access hobbyist sites still feels like "being locked out" of something. My ISP provides /48 IPv6 addresses for free, and I already run a couple sites only on IPv6 - because an IPv4 would cost 20 bucks a month - it's not important enough to me personally to pay that.
Maybe "think of the children."
There might be a child behind the NAT, thus IPv6 requirement.
With IPv6 privacy extensions it's impossible to tell which device you're talking to inside of a /64. You'd need to do something silly like DHCPv6 to get that kind of remote device-level tracking.
This is the global curve, it looks to be flattening I had thought it would be more asymptotic to 100%.
My company is ipv4 still, and some customers are having issues with ipv6 only connections.
Also we log the ip addresses, and that's only in ipv4.
Nice. But note that the average is still significantly below 50%. It's also a bit concerning that the growth rate seems to be levelling off. It currently looks like a sigmoid curve with a maximum far below 100%.
I wouldn't be so worried about it. It's really hard for something as big as this to really hit 100%. If we hit 80% or thereabouts, we can at least plausibly argue to backwards ISPs that IPv6 is the default and the standard that everyone should reasonably be offering.
Generally: I'm really surprised that Norway is just at 27%. I think I've been with 3 different residential ISPs the last 15 years, and all of them have done IPv6 perfectly well (two nits: I think one required a trivial opt-in, and my current ISP is just giving me /60 which isn't perfect).
Edit: Oops, sorry to my current ISP for shaming them. Some googling told me that one can get a /56 using DHCPv6-PD. I'll try that!
Interesting to see Spain having such low IPv6 adoption. Perhaps that's exacerbated the issues caused there by blocking IPs during football matches that we've seen mentioned in recent HN posts.
Spain has one of the highest FTTx rollouts in Europe though. My theory is that they just prioritized building fiber and there was no money left for ipv6 transition.
It seems the biggest hurdle to IPv6 adoption is legacy software and hardware. Anything new that gets built can easily be v6 only.
worth noting that the google stat measures ipv6 availability among users who access google, not general internet traffic -- so it's a bit of a self-selecting sample skewed toward consumer isps that have deployed ipv6, which probaly overstates adoption for enterprise and datacenter traffic where the github situation is much more representative of reality.
Every year I just wish someone will come up with IPv4-with-more-bytes and we can switch to it before IPv6 gets another percent usage share.
IPv4-with-more-bytes is not backwards compatible with IPv4. So you'd have to replace/upgrade every existing network stack, both hardware and software. To get, basically, the same effect as moving to IPv6.
> IPv4-with-more-bytes is not backwards compatible with IPv4
Neither is IPv6
> To get, basically, the same effect as moving to IPv6
The only thing that IPv6 solves which is of interest to 99.99% of the users is having more adressable space. The rest of IPv6 features are either things that nobody asked for, or things which are genuinely worst compared to IPv4.
I consider the mere fact of enabling IPv6 an unacceptable security risk, as I would now have to make sure my IPv4 and IPv6 firewall stack are perfectly mirroring each other. That would be trivial with IPv4-with-more-bytes, it's a nightmare with IPv6.
Do NAT64 and just worry about IPv6 if not wanting dual stack.
All of IPv6 features are just direct effects of having more space and not. Basically IPv6 "features" is just getting rid of IPv4 workarounds.
> I would now have to make sure my IPv4 and IPv6 firewall stack are perfectly mirroring each other.
You'd still have that in your IPv4-with-more-bytes, as you'll still probably end up running dual-stack to address those old-v4-only sites. Or you'd do the same with v6 and run a tunnel to translate those v4-only addresses to your v4-with-more-bytes. So you're in the same situation either way.
There were backwards-compatible protocols proposed, such as EIP, but the committee chose a backwards-incompatible protocol for v6. Their assumption was that v4 would run out of space in a single-digit number of years and everyone would be forced to migrate. The past 30 years have shown that not to be the case.
https://datatracker.ietf.org/doc/html/rfc1385
They went with SIPP, which was one of the backwards-compatible options. It should be kind of obvious from the vast number of backwards compatibility methods available in v6 that v6 is actually backwards compatible... but for some reason a lot of people either refuse to believe this or have double standards around what counts as compatibility.
That's what IPv6 is. People get so fixated on being annoyed at IPv6 they forget to actually think. Whatever you invent won't be any better than IPv6. Many people have tried.
If you change the address format even the tiniest amount, if you add one single additional bit, your new protocol is already completely incompatible with all existing IPv4 software and equipment.
IPv6 is IPv4 with 12 more bytes, right?
Been waiting for this for years! Now I just wish my local ISP (rural Canada) supported it.
And in the mean time, Odido on the Netherlands still don’t support ipv6 on their fiber network…
I'm surprised it's reporting is listed <5% - I thought it was pretty much ipv6 first?
Any idea why it oscillates?
Corporate IT networks have less IPv6 and residential/mobile networks have more IPv6, so on weekdays when people are using Internet at work = more IPv4, weekends when people are using Internet at home = more IPv6. Christmas also has a big bump for the same reason.
Awesome, thanks.
No change in trend during COVID years, interesting.
There is -- you can see the weekday/weekend difference is smaller when people are working from home en masse.
I guess most of this is mobile use in India.
And Virgin Media in the UK still doesn't support IPv6
There really should have been proper government pressure and fines long ago.
Say if you have 10% of market share or x million monthly users you must support IPv6 in say 5 years. If not you are fined say 2% revenue per year until you do...
I'd make it required that ipv6 for all customers has a higher service guarentee than anyone ipv4. If you don't support ipv6 you can't guarentee anything. give two years to to implement it.
I was wondering why someone proposed IPv8
Puma 8.0+ webserver now defaults to IPv6
Quick, someone tell slashdot!
Good.
I think most of us know that their design failure here was a lack of backwards compatibility. But at least it's getting adopted.
Backward compatibility was never really the problem; the problem is that forward compatibility with ANY successor protocol (without modifying IPv4) is a fundamental impossibility.
But at least a reasonable facsimile eventually came out with NAT64.
(You can also do NAT46, but it requires one IPv4 address for every IPv6 destination you want to be reachable from the IPv4 Internet, so it doesn't scale very well.)
Another reference is Cloudflare's metrics, which show IPv6 at more like 40%, excluding bot traffic.
[1] https://radar.cloudflare.com/adoption-and-usage#ipv4-vs-ipv6
Waiting for github to support
One of the foremost obstacles to wide adoption is that IPv4 still works great and it's ubiquitous. There is no advantage or up-side to deprecating or abandoning IPv4 support at all. The only result of disabling IPv4 is a denial of service to a certain sector of customers or clients.
The only way this will change is by increasing pressure on the resource of IPv4 networks. It was a few years ago that AWS broke the news to me that I'd be paying for IPv4 addresses but IPv6 would remain free. If enough services are forced, financially, to abandon an IPv4 presence, then their clients would be likewise forced to adopt IPv6 in order to retain connectivity.
But with the ubiquity of CGNAT and other technologies, it seems unrealistic that IPv4 will become so rare that it becomes prohibitively expensive, or must be widely abandoned. So that availability of the legacy protocol will inhibit widespread adoption and transitions to IPv6.
Yeah the reality is that the Internet is centralized now. There is no reason for two computers on the internet to connect to each other anymore, as long as you can reach Google/Microsoft/Amazon/CloudFlare, that's all anyone needs.
Just log onto AOL and type in keyword "WALMART" and save! It's friendly and safe.
In theory you can save quite a bit on AWS costs by having instances that can only use v6.
But in reality at the moment there will probably always be at least one thing that only works with v4 a lot of the time.
Incentives are misaligned as well - it saves you money as the EC2 instance user, but the owner of the website you're trying to access has to support v4 anyway so they don't have a big incentive to change anything
Maybe it's time to tax IPv4 usages or holders.
It's all bots!!!
Every company I have ever worked for in the US didn't use IPv6 and actually blocked it at the FW
The US has something like 80% of the world's IPv4 addresses, so they feel a lot less pressure to migrate.
I’ve worked for a company that was barely using its /16. I know several individuals, including myself, with personal /24s.
None of which are any help when connecting to someone who doesn't have those.
I know, I'm just agreeing there's a ton of IP waste in the US. Early adopters were perhaps unjustly rewarded. InterNIC (before ARIN) would just about hand out IPs to anyone who could send an email.
During the dot-com crash I had to put a /16, some /17's and a /19 on one vlan and connected a 1U Linux box running Labrea Tarpit just so those ranges would respond to ping because InterNIC used to harass us for not utilizing all the space. They threatened a few times to take them back. AFAIK nobody nags like that any more. They probably should.
I recently released a /24 that I registered in 1992 and I hadn’t realized it was still mine.
ARIN was gonna charge me $100 to authenticate and recover the account, but once I asserted and notarized my letter of relinquishment, the process went real quick!
You could've recovered it and sold it for $7K, or rented it out for $500/month.
Dude /24s are worth at least $5,000
A /24 is currently worth between $5,000 and $9,000 USD. Did you get them a long time ago?
Yes, over 32 years ago. It was before ARIN and is considered a legacy block.
With your own /24 you can get an AS number and potentially BGP multi-home it.
Yes, I've already done that. I have the /24 tunneled to my home network.
That would be so cool to see your own AS in the global BGP table. I suppose I could still try this using IPv6
You can get that going pretty cheap through various RIPE LIRs!
I worked for a state government agency that had a public /16
US is significantly above average in terms of adoption
Our freaky network admins rolled it out in our global corpo.
Was fun seeing IPv6 running for a few days without problems.
And yet I still haven't ever connected to an internet provider that supports IPv6, across two countries I spend time in...
90% spam/hack?
The final 10% is gonna be a doozy..
meanwhile I just disabled ipv6 on all my vm's last night due to ubuntu package servers being down and needing to get something critical out the door.
Spain: 9.9%
What's going on in Spain?
Bizarrely, Telefonica doesn't see a need. But, their subsidiaries in LatAM do heaps! And, they do central purchasing.
forgive dumb question but what happens when someone on IPv6 without IPv4 tunnel visits a URL with only a IPv4 endpoint?
like say
* https://1.1.1.1/cdn-cgi/trace
vs
* https://one.one.one.one/cdn-cgi/trace
When ipv6 threads like this come up, someone eventually mentions T-Mobile is completely IPv6 now but they must have IPv4 tunnels because I have IPv4 turned off on my modem/router and can still visit both those URLS
Not dumb. It's not exactly a tunnel, it's a double sided conversion.
Basically to reach any v4-only resource you need a translator, typically NAT64. This maps the entirety of the v4 internet into a /96 of IPv6 space (last 32 bits).
DNS64 is one way to access this, which will return a result for 'amazon.com' like:
A = `98.87.170.74` AAAA = `64:ff9b::6257:aa4a`
Combining this with CLAT lets you punch in an IPv4 literal like 1.1.1.1 and your phone/computer will do this conversion from v4 -> v6 locally without you changing anything. So 1.1.1.1 would become `64:ff9b::101:101` on-device - and that's actually what your mobile ISP sees.
T-Mobile and most mobile operators use 464XLAT - which has been in Android & iOS for at least 8-10 years now if memory serves.
It lets you visit 1.1.1.1 because your phone is converting it automatically to T-Mobile's NAT64 prefix (CLAT - customer side), it traverses their network v6-only, and then it ends up at their translator (PLAT - provider side) and becomes normal NAT'ed v4 traffic out to CloudFlare.
Great, then another 20 years and we can retire IPv4.
Not the one down-voting you but I suspect IPv4 and IPv6 will run side-by-side dual-stack at least until 2050 and IPv4 would not be fully deprecated until probably 2323 star-date 0 as future quantum interstellar communications subspace will deprecate both standards. Only half kidding as nothing ever gets deprecated or decommissioned until it breaks something important.
[dead]
It’s amazing to see this finally hit 50%. Out of curiosity for the infrastructure folks here: are you actually running IPv6 inside your internal VPCs and Kubernetes clusters now, or are you still mostly just terminating it at the edge/load balancer level?
[dead]
At home, I use an Android 16 Pixel phone, and a Chromebook, and I would suspect (but cannot prove) that 100% of my LAN outages can be blamed on the dual-stacking nature of IPv6 plus IPv4.
Chris Siebenmann has written extensively on IPv6: https://utcc.utoronto.ca/~cks/space/?search=ipv6
Google has some weird way of asserting connectivity, and I suspect that when connectivity on one protocol is lost, it is impossible to maintain or establish connectivity through the other one (IPv6) even if it is available upstream.
I am rather infuriated with the status quo at this point, because it is impossible to disable IPv6 on my devices and it is also impossible for my ISP to disable IPv6 on my LAN or on the CPE router which they own and control.
Due to chronic WiFi issues I was eventually forced to place my ISP router into Bridge mode permanently, and I use a 3rd party Netgear which I own, and does not have the same WiFi issues, and where IPv6 is optional (and often fails, because its implementation is buggy and glitchy for no reason.)
I am rather infuriated that it's impossible to disable IPv4 on my devices, so does that make us even?
Yes I believe so!
I recently purchased a brand-new LaserJet printer, and since it needs nothing to do with the Internet or a WAN outside my home, I thought it'd be great to simply disable IPv4 and stop doing the DHCP dance.
Well it immediately fell off the net completely. I couldn't figure out how to expose its IPv6 address or contact its management interface.
Hypothetically, Bonjour and mDNS should make this a no-brainer. Hypothetically, disabling IPv4 shouldn't even prevent it from connecting to the Internet. But I was ultimately forced to factory-reset it.
IPv6-only LAN makes a lot of sense for most people, and perhaps reduces attack surface a little. If you have the means, I highly recommend setting it up!
Sounds like it's time to abandon it for something new and more stupid
But I still have to pay Hetzner separately to rent out an IPv4.
I am waiting for the flood of evangelist to explain:
- IPv6 proponents are the only ones who know that NAT is not a firewall, and
- Everyone in the world would love IPv6 if they just didn't hate learning new things
I still do not support IPv6 on my servers and I think I will skip it and wait for IPv8:
https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
Avoiding a dual-stack and making IPv4 a part of whatever superseeds it seems like the right choice to me.
IPv6 always seemed to me like throwing away all existing telephone numbers, just to support longer numbers.
Maybe you didn't read the draft. It's either a delayed April's Fool joke or AI slop. Even if you take it seriously, it will require updating every v4 device in existence.
IPv6 will never make it. Maybe IPv8 [0], which IPv6 should have actually looked like:
> 1.1.1.1.1.1.1.1
[0] https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
Why do people keep proposing alternatives to IPv6 that are no easier than IPv6 but still require the whole world to start the deployment over from 0%?
I'd say it's either because they're just having fun, or because they're dumb.
[dead]
For observers, this draft was posted to HN earlier but quickly flagged and removed because the linked "IPv8" draft is absolute bunk.
See the removed thread for details: https://news.ycombinator.com/item?id=47788857
Having read that thread, I guess one of the small upsides of the world I live in is that "FIFA Peace Prize" is now available as a joke award reference. FIFA really hit it out of the park there in a way that even their normal legendary levels of corruption couldn't imagine.
Edited: In hindsight I notice that "hit it out of the park" is the wrong sport metaphor for FIFA, but I stand by it anyway.
> Edited: In hindsight I notice that "hit it out of the park" is the wrong sport metaphor for FIFA, but I stand by it anyway.
For future reference, you can use: "knocked it into the top corner", "put it in the back of the net" or "smashed it past the keeper". Not a native football-talker, but hang out too much with a few.
"Back of the net" doesn't feel the same to me even though (I learn after reading far too much about a sport I do not play) "Out of the park" is basically the same thing.
In my mind "out of the park" had meant the ball leaves the actual stadium but in fact (I read) "the park" in this context is actually the field of play and so "out of the park" represents in fact the vast majority of home runs and not the over-achievement I had imagined.
So TIL but thanks for the suggestions.
True, "back of the net" is more "someone kicked the ball really hard and it hit the back of the net really hard" instead of "the ball came across the goal line" which can be very different, so in my mind that's as close to "out of the park" as you can get in soccer :)
Nice idea. Always wondered why IPv6 went so ambitious with the addressing
Might as well go big. 24 extra bytes per packet is not that big deal. And having that much extra space means you can screw up design multiple times and still be able to reuse lot of infra. Also getting rid of idea that you are even trying to manually manage the address space eases many things.
But it's not human readable anymore, nor backwards compatible. The expectation was that the industry is reasonable, but it proved to be as hard as it would be to push breaking email v2 implementation.
If you think v6 isn't backwards compatible then literally anything bigger than 32 bits will never count as backwards compatible for you. The whole point of making the address space bigger is to make it bigger, so what do you expect to achieve by complaining that the result is incompatible?
As a human, I've found that e.g. "fd00::53" is perfectly readable to me, and most of the time you're interacting with strings like "news.ycombinator.com" anyway which is identical to how it works in v4, so I'm not sure how far I'd agree with that part either.
One of the craziest aspects of IPv6 implementation is the reverse DNS lookups.
IPv6 uses ip6.arpa and segments each little nybble into a subdomain!
https://en.wikipedia.org/wiki/Reverse_DNS_lookup#IPv6_revers...
This means there are always 32 octets to a reverse-IPv6 address, and there are no shortcuts or macros to overcome this! That means if you wish to assign a singular name that maps from a legitimate /64 Network ID, you must populate 64 bits worth of octets in a zone with this data. It is an absurd non-solution. This never should've been allowed to happen, but it will basically mean that ISPs abandon reverse DNS entirely when they migrate to IPv6 implementations.
I agree it's a pain to read, mostly because DNS addresses are written backwards, but an "absurd non-solution"? For a set of instructions that don't even depend on the format of the record (they work for v4 too), and which I could describe in one line in a HN comment?
If this is the craziest part of v6 then it must be incredibly well designed overall.
It is a pretty nice design, partly as a result of the fact that we've got a working system to look at (IPv4) and we have a lot more eyeballs "these days" (when IPv6 was designed, so, decades ago now) than when the Internet Protocol was a new idea.
I think perhaps the person you're responding to imagines that somehow DNS mandates a very naive implementation and so this behaviour would be incredibly expensive. The sort of person who sees a flip clock and imagines it needs 1440 different faces not 84 (or in some cases 72) because they haven't realised 12:34 and 12:35 simply use the same hour face.
“copy paste the output” is your solution? You think this somehow scales to manage entire networks like this with dynamic addressing? Do you perceive a network admin as a monkey who copy-pastes things all day?
This is exactly the absurd non-solution I am referring to, and it seems like if someone dismisses this with “one line instruction is all u need lol” they cannot even comprehend the scale at which real life operates.
Copying and pasting was just my attempt to demonstrate how simple a v6 rDNS record is to add. If you were interested in hiring me to write a solution for your ISP, that's fine, but you can't seriously expect random people to do it for you for free in a HN comment.
It should be pretty obvious that a script can generate these records from the forward records or from any other source of IPs/hosts, with no per-address effort needed on the part of the network admins.
Again, absolutely blind to the management of these things at scale. Yeah, I don't rightly care about "how easy it is" to generate them. You can't even comprehend or convey the massive number of records and zones that are involved in managing a network of devices that all require dynamic updates to reverse-DNS and add/update/remove device addresses on a regular basis.
DNS is a distributed database system, and so the challenge is not cramming in data with a brainless script, but managing how that data is distributed and accessed by thousands or millions of peer servers, caches, and clients worldwide.
IPv4 reverse-DNS was quite simple when it was broken on octet boundaries and there were only four of those boundaries in total. But even then, ISPs could often not be arsed to put the right data in there. Some left it blank and some waited until they were forced, by strict requirements that said reverse must match forward DNS in many cases.
I have never found any user-accessible software, not on any Linux distribution or on any cloud service, that would permit an ordinary consumer to manage even a /24 IPv4 network's reverse-DNS at scale, or programmatically, as opposed to by-hand "copy paste" as has been so condescendingly suggested here. There are plenty of hosted DNS providers, and there are plenty of monkey-brain Dashboard interfaces where you can pound out one A record at a time. But there was nothing to deal with dynamic addressing or DNS databases at scale. That's why IPv6's reverse DNS remains an absurd non-solution.
So... how many records and zones? I'm pretty sure I could convey it if I could work out what you were talking about.
You went from "you can't even comprehend or convey the massive number of records and zones that are involved" to one v4 /24, managed "at scale" but by an ordinary consumer, who you expect to be capable of programming. This is a bit all over the place.
It's not any harder to deal with v6 reverse DNS than it is v4. In fact, making every reverse label 4 bits instead of 8, combined with v6 being much bigger than v4, makes rDNS much easier to deal with in v6 because you can generally delegate reverse zones on exactly the same boundaries that you delegate the corresponding IP blocks. In v4, you often need to delegate on boundaries that aren't /8, /16 and /24 and it suddenly gets more annoying.
Scaling up for rDNS is no different to scaling up for forward DNS. It's a well-understood problem.
Anyone who's ever had to delegate DNS authority on anything other than an 8-bit boundary can understand the value of that feature.
At face value, yeah, that's replacing "8" with "4," but from a practical perspective, delegating authority for a customer IPv4 /25 requires, at minimum, 128 records. (Granted, there's also no practical need to be stingy about IPv6 allocations -- that IPv4 /25 customer could simply receive an IPv6 /48.)
I would firmly expect to see a lot more formulaic reverse (and presumably forward) DNS responses, where needed, since filling files with records you need to store on disk (and in memory) doesn't scale well. The tech has existed for years; I wrote my own implementation years ago, but these days I'd use something like PowerDNS with https://github.com/wttw/regexdns .
If anyone is confused on adoption is so slow when supporting it is easier than ever the reason is actually quite simple: it's expensive.
Switches and routers have a little thing called TCAM memory, the premise behind it is that it allows you to single-cycle O(1) lookup any ips destination. Usually to replicate it you could have a 4gb*2 preallocated contiguous buffer, but that's not something that is wildly supported or used and this completely breaks down when you expand to the IPv6 range.
The problem lies in that in a lot of cases TCAM can no longer hold the entire IPv4 routing table and now if you introduce IPv6 you are expected to handle double the routes which degrades switching performance as more active routes have to be evicted and fall back to software routing.
Routes are not the only thing that take up TCAM memory: the firewall rules, internal routing, vlans, everything becomes double and TCAM memory cannot be dynamically adjusted at runtime to allocate space so what happens is that you need to sacrifice IPv4 space in TCAM permenantly even if nobody is using IPv6.
This is where it gets worse: if you have ever attempted to use IPv6 you will notice that is significantly slower than IPv4 and that is because most ISPs simply opted to use software routing for IPv6 which coupled with 4-10 hops is nearly double the latency in some cases (0.5ms to 1ms) while having throttled bandwidth to not overload the CPU.
That's why network engineers will continue to refuse to (properly) support IPv6. If I had to guess the "properly" supported IPv6 percentage is less than 10%.
> if you have ever attempted to use IPv6 you will notice that is significantly slower than IPv4
The link in the OP shows that IPv6 typically gives users 10-20ms lower latency. This confers with my experience since IPv4 is typically going through some poor overloaded CGNAT box.
What shitty ISP operates like that? I frequently see IPv6 have *lower* latency because of fewer middle boxes and fewer hops in general. Your routers in the default free zone shouldn't be close to their TCAM limits with a single IPv4 routing table.