And still, in the year of our lord 2026, GitHub does not support IPv6.<p><a href="https://github.com/orgs/community/discussions/10539" rel="nofollow">https://github.com/orgs/community/discussions/10539</a>
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.<p>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.
Your work is probably all exiting through the same IP, you competing with others on the same IP is causing the rate limit.
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.
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?
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.
May explain the ipv6 resistance. Hard to do effective per-ip rate-limiting with v6.
should we try going back to IPX ?
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.
IPX/SPX is datagram only. <i>BUT</i> it would be an opportunity to build a QUIC-like that runs over it :-)
Only if we're bringing back Token Ring, too.
That might be challenging, I hear people are pretty short on tokens these days.
While we're at what about older physical layers? Coaxial based stuff seems cool in 2026
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.<p>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 <i>calling</i> 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. <a href="https://infosec.exchange/@0xabad1dea/116334321751266751" rel="nofollow">https://infosec.exchange/@0xabad1dea/116334321751266751</a>
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 guys have nines?
Personally I’d look for the coveted 5 eights uptime.
As long as it is after the decimal separator I can try for that...
> <i>And still, in the year of our lord 2026, GitHub does not support IPv6.</i><p>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:<p>* <a href="https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/" rel="nofollow">https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/</a><p>* <a href="https://www.arin.net/blog/2019/04/03/microsoft-works-toward-ipv6-only-single-stack-network/" rel="nofollow">https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...</a>
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.<p>Turns out we could not connect to Twilio's API which is IPv4 only.
They supported IPv6 for a short time, but then stopped their experiment.<p>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.<p>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.<p>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).<p>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.<p>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:<p>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.<p>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.
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.
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.
Facebook is (AIUI) 100% IPv6-only on their internal network, and has been for many years:<p>* <a href="https://engineering.fb.com/2017/01/17/production-engineering/legacy-support-on-ipv6-only-infra/" rel="nofollow">https://engineering.fb.com/2017/01/17/production-engineering...</a><p>* <a href="https://www.internetsociety.org/blog/2014/09/facebook-launches-ipv6-only-data-cluster/" rel="nofollow">https://www.internetsociety.org/blog/2014/09/facebook-launch...</a><p>IPv4 is actually the "leftover" stuff they have to deal with at the front end.<p>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?<p>"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.<p>I have also found that an uncomfortable number of people do <i>not</i> consider it appropriate in any way shape or form. Even when it’s ultimately your call and no one else’s.<p>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
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...
Kinda sorta.<p>github.com doesn’t have an IPv6 address.<p>github.io <i>does</i> 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.<p>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.
Just found this little site. <a href="https://isgithubipv6.web.app/" rel="nofollow">https://isgithubipv6.web.app/</a><p>Maybe we shouldn't even measure percentage adoption and instead just if github has finally adopted..
GitHub should absolutely support IPv6, but until then... transip.eu provide IPv6 addresses which transparently proxy to github.com:
<a href="https://www.transip.eu/knowledgebase/5277-using-transip-github-ipv6-proxy" rel="nofollow">https://www.transip.eu/knowledgebase/5277-using-transip-gith...</a><p>You'll need to update your DNS server to include those as AAAA records.<p>Do providers like NextDNS or RethinkDNS allow these sorts of overrides?
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!
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.
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.
> <i>Outdated beliefs probably. When I talk about v6 support in our b2b saas, PM laughs and says nobody uses that shit.</i><p>Nobody except the 140M subscribers on T-Mobile US's network:<p>* <a href="https://www.youtube.com/watch?v=d6oBCYHzrTA" rel="nofollow">https://www.youtube.com/watch?v=d6oBCYHzrTA</a><p>But sure, be IPv4-only and add latency by forcing traffic through an extra translation box.
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.
Where can I get it, asking for a friend?
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.
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?<p>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.<p>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. <i>Most</i> users do not have a problem, even there is a CGNAT on IPv4.<p>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.<p>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<p>~60%+ of internet traffic is mobile, which is ~100% behind CGNAT.<p>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.<p>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!<p>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 - <a href="https://blog.exe.dev/ssh-host-header" rel="nofollow">https://blog.exe.dev/ssh-host-header</a>
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.<p>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?<p>>Linode and others that do /64 for a whole data center<p>That's how it's supposed to work.
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.
It could be that they don't want to implement IP bans in IPv6.
You probably need a hefty security reimplementation if you want to add IPv6 to Github.
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: <a href="https://tailscale.com/docs/reference/faq/ipv6" rel="nofollow">https://tailscale.com/docs/reference/faq/ipv6</a><p>If you're not an expert in this area it's worth a read - I certainly learned a few things!
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: <a href="https://ssg.dev/ipv6-for-the-remotely-interested-af214dd06aa7/" rel="nofollow">https://ssg.dev/ipv6-for-the-remotely-interested-af214dd06aa...</a><p>EDIT: After reading Tailscale's article, I noticed that I overlooked our neverending dependence to NAT despite that IPv6 seems to eliminate it.
"IPv6 is the next generation of the Internet Protocol (IP), the successor to IPv4."<p>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.<p>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.<p>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.<p>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.<p>^1 <a href="https://www.theregister.com/2025/08/04/asia_in_brief/" rel="nofollow">https://www.theregister.com/2025/08/04/asia_in_brief/</a>
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
> <i>They've been requiring that iOS apps work on IPv6-only networks for close to 10 years now</i><p>This was at the behest of mobile network. E.g., T-Mobile US has 140M subscribers, and moved to IPv6-only many years ago:<p>* <a href="https://www.youtube.com/watch?v=d6oBCYHzrTA" rel="nofollow">https://www.youtube.com/watch?v=d6oBCYHzrTA</a>
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.<p>[1] <a href="https://en.wikipedia.org/wiki/NAT64" rel="nofollow">https://en.wikipedia.org/wiki/NAT64</a>
The problematic low-level libraries are standard, and effectively impossible to fully deprecate since they're decades old and part of the socket API.<p>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: <a href="https://developer.apple.com/support/ipv6/" rel="nofollow">https://developer.apple.com/support/ipv6/</a>
Differential enforcement.
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.<p>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.)<p>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. This adoption rate is ridiculous despite basically all network interfaces supporting it<p>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).<p>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.<p>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.<p>> End users shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs doing that to prepare for the transition.<p>100%
The Czech government has announced it’ll stop offering its services via IPv4 in June 2032.<p>Source <a href="https://konecipv4.cz/en/" rel="nofollow">https://konecipv4.cz/en/</a>
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.<p>Yet I can still rent a VPS with IPv4 for $12/year from a wide variety of providers.
You can, but a significant portion of that money is going toward paying off that IP.<p>"Skyrocket" is wrong but the market cap of IPv4 addresses is quite high.
For now, :) Hopefully it continues.<p>> if IPv6 prevents IPv4 rental prices from going haywire, then it's served a useful purpose.<p>Competition is good.
> <i>It has barely hit 50% and it's already plateauing.</i><p>Is it plateauing? From the chart it doesn't look that way at all to me.<p>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.<p>So it still seems to be growing <i>strongly</i> to me. The rate of growth has slowed maybe the <i>tiniest</i> bit 2024-2026 compared 2018-2023, but I don't see it anywhere close to plateauing yet.
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>ISPs often fail to do this because there is always someone in the hierarchy who says, "nobody is demanding it."</i><p>I'm with an ISP whose landline/fibre division does not have IPv6, but whose mobile division gives IPv6 to handsets.
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.<p>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.<p>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.<p>It is the equivalent of shipping two programs in different languages and maintaining exact feature parity between both at all times.
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 genuinely don’t understand this. The concepts are nearly identical between the two.
Hum no, to me they are orthogonal.<p>v4 was built around the idea of multiple free standing networks linked by gateways. v6 was built around the idea of a universal network.<p>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.<p>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).<p>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.<p>Seriously v6 was created by nerds in a lab with no practical experience of what people wanted.
v4 and v6 were build around the exact same use cases.<p>> With v6, everyone is effectively in the same network.<p>Just like IPv4.<p>> I have to ask my ISP for a prefix that he will rent me for money even for my LAN.<p>Just like IPv4, if you need a static address.<p>> 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).<p>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).<p>> Also if I want any kind of privacy, I will have to manage privacy extensions<p>...which are enabled by default nearly universally<p>> and the great invention of having to use automatically generated, dynamically routed, essentially multiple random IPs per interface.<p>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.
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 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.
“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.<p>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.
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.
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 has barely hit 50% and it's already plateauing.<p>Well, the curve has got to level-out at 100%.
> Also, notice how Android and iOS don't support turning off IPv4.<p>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.
> It has barely hit 50% and it's already plateauing.<p>That makes sense. The majority of IPv6 deployment is mobile.<p>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.
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.<p>The only arguments I've ever heard against ipv6 that made any sense are that:<p>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.<p>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.<p>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.)<p>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.<p>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.<p>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 <i>doesn't work anymore</i> (basically hardware failure), it's going to be in place forever. It took <i>over 10 years</i> 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.<p>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.<p>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.
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 <i>data plane</i> supports it - but what about the management plane?<p>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".<p>Porting all of that to support ipv6 can easily be a multi-year project.
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.
> Porting all of that to support ipv6 can easily be a multi-year project.<p>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.
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.<p>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<p>We desperately need a standardized protocol to look up addresses via names. Something hierarchical, maybe.<p>> with v6 you can't rely on NAT as an ersatz firewall<p>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?<p>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
> But both of these are really only valid for DIY homelab enthusiast types. I honestly have no idea why other people resist ipv6.<p>Simple. The "homelab enthusiast types" are those that usually push new technologies.<p>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.<p>This really should be how SOHO routers do IPv6 out of the box.<p>Most people don't want 1:1 addressing for their entire home or office.
"Is there a reason why adoption has been so abysmally slow?"<p>Just the obvious one: the people who designed IPv6 didn't design for backwards compatibility.
How so? The same working group published e.g. <a href="https://www.rfc-editor.org/rfc/rfc1933" rel="nofollow">https://www.rfc-editor.org/rfc/rfc1933</a>, and it's hard to see how v6 could have been designed for backwards compatibility in ways that it wasn't already.<p>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.<p>Nor for easy transition.
<i>Has</i> 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?<p>We've never done this before at this scale. Maybe this is just how long it takes?
> 1: it's hard to remember addresses<p>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.<p>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.<p>But yes, renumbering also isn't a lot of work.
> Like surely all the big players have updated their networking equipment by now<p>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.)<p>Your wifi isn't symmetrical either.
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.<p>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.<p>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: <a href="https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-update-23.html" rel="nofollow">https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda...</a><p>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.<p>Then there's IP fragmentation and PMTU that are a burning trash fire. Or the IPv6 extension headers. Or....<p>In short, there are VERY good reasons why IPv6 has been floundering.
> <i>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><p>No, that’s not the IPv4 design. That’s an <i>incredibly ugly hack</i> to cope with IPv4 address shortage. It was never meant to work this way. IPv6 <i>fixes</i> this to again work like the original, <i>simpler</i> design, without ”local” addresses or NAT.<p>> <i>In IPv6 each host has multiple global addresses.</i><p>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.<p>> You can quite easily give each host one, and only one, static IPv6 address, just like with old-style IPv4.<p>You literally CAN NOT. On Android there's no way to put in a static IPv6 or even use stateful DHCPv6.
> 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.<p>I assume you mean "interface", not "host". Because it's absolutely not true that a host can only have one "local net address".<p>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>
> <i>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><p>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.<p>Heaven help you if your ISP uses CG-NAT.
> Then there's IP fragmentation and PMTU that are a burning trash fire.<p>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.<p>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.
> <i>but there's plenty of derpy networks out there for v4 as well.</i><p>God yes, I've helped so many users on PPPoE by telling them to set their MTU to something lower...
IPv4 allows fragmentation by the middleboxes, which in practice papers around a lot of PMTU issues.<p>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.<p>People are trying: <a href="https://datatracker.ietf.org/doc/rfc9268/" rel="nofollow">https://datatracker.ietf.org/doc/rfc9268/</a> 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.<p>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.<p>Router fragmentation is also expensive and not fast path, so there's pretty limited capacity for in path fragmentation.
> 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.<p>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 ;)<p>> 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.<p>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>).<p>> ULA was invented to solve this, but the source selection rules are STILL being debated: <a href="https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda" rel="nofollow">https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda</a>...<p>RFC6724 is still valid, they are only debating a slight update that doesn't affect a lot.<p>> Then there's DHCP.<p>DHCPv6 is an abomination. But not for the reasons you are enumerating.<p>> With IPv4 the almost-universal DHCP serves as an easy way to do network inspection.<p>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.<p>> Stateful DHCPv6 is not supported on Android (because its engineers are hell-bent on preventing IPv6).<p>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.<p>> With IPv6 there's literally _nothing_ similar.<p>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:<p>> ping6 ff02::1%eth0<p>There are also other scopes like site-local:
> ping6 ff05::1%eth0
<a href="https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml" rel="nofollow">https://www.iana.org/assignments/ipv6-multicast-addresses/ip...</a><p>(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.)<p>> And even when it's supported, the protocol doesn't require clients to identify themselves with a human-readable hostname.<p>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>".<p>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 ;)<p>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.<p>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.<p>> 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.<p>Yes. DUIDs were another stupid idea. As I said, IPv6 is a cascade of recursive WTFs at every step of the way.<p>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.<p>What matters is the actual operational practice. Do you want a challenge? Try to do this:<p>1. An IPv6 network for a small office with printers, TVs, and perhaps a bunch of smart lightbulbs.<p>2. With two Internet uplinks. One of them a cellular modem and another one a fiber connection.<p>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.<p>4. No NAT (because otherwise why bother with IPv6?).<p>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.
How do the working IPv6 deployments cope with these issues?
>For example, in IPv4 each host has one local net address<p>Most of my home devices have multiple v4 addresses, not counting 127.0.0.1, so this assumption is incorrect.
The reason: Skill issue.
Ignore all the excuses like longer addresses and incompatible hardware. The <i>actual</i> reason is that everyone hates change.
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.<p>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.<p>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.<p>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...<p>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
Worst migration plan ever.
> It should be ISPs doing that to prepare for the transition.<p>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.<p>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.<p>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.
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.<p>>it's in their best interest to ensure users can't host services without them.<p>They'll just keep blocking port 25. IPv6 won't change anything with regards to self hosting.
> You're uniquely tagged and identifiable on every website you visit.<p>Almost every modern OS enables IPv6 privacy extensions, ie address randomization, by default.
My OS gives me IPv6 privacy addresses out-the-box which rotate every few hours.
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%.<p>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).<p>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.<p>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.
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).
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.<p>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.<p>[1] <a href="https://docs.github.com/en/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization" rel="nofollow">https://docs.github.com/en/enterprise-cloud@latest/organizat...</a>
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.<p>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...<p>[1] AS202858
Anyone who relies on IP filtering for security deserves to have it broken. Change my mind.
I'll take that bait ;-)<p>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.<p>I've written rules which say that access should only be allowed when the client has both password <i>and</i> MFA <i>and</i> comes from a known IP address.
Why shouldn't I do that?<p>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.
Defense in depth is a thing but I agree that relying on it is not a good idea.
IP filtering + proper security is better than just having the security.<p>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.
> providers don't have an easy way to correlate addresses<p>Yes, they do. It's called DNSSEC.
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:<p>- 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<p>- 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.<p>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.
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.<p>One such stat is here:<p>> adoption ranging from 71% among the top 100 to 32% in the long tail<p><a href="https://commoncrawl.org/blog/ipv6-adoption-across-the-top-100k-web-hosts" rel="nofollow">https://commoncrawl.org/blog/ipv6-adoption-across-the-top-10...</a><p>Getting full coverage on AWS (/GCP/Azure) and few other key services (GitHub...) would be significant here imho.
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.
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.
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.<p>We actually have a /128 address only, and had to tweak several settings including enabling IPv6 masquerading (NAT).<p>I haven't the slightest clue why they didn't give us a block.
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.
Is most of that due to mobile?<p>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.<p>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.
It'd be annoying even in the scenario where it got quickly adopted. Complicated spec, user-unfriendly addresses, unclear defaults.
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 <i>any</i> backwards-incompatible change to layer 3, and address expansion is always going to be backwards incompatible.
CloudFlare Radar has stats for desktop (34%) vs mobile (46%) adoption: <a href="https://radar.cloudflare.com/explorer?dataSet=http&groupBy=ip_version&filters=deviceType%253DDesktop%252CbotClass%253DLikely_Human" rel="nofollow">https://radar.cloudflare.com/explorer?dataSet=http&groupBy=i...</a>
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.
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 <i>off</i> ipv6. not sure exactly when it happened, i should get around to complaining about it but i hate making phone calls
It's only a matter of time before laptops get 5G. Macbooks have been rumoured for a while to get cellular modems. [1]<p>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.<p>[1]: <a href="https://9to5mac.com/2025/08/14/apples-first-mac-with-5g-cellular-might-be-coming-sooner-than-we-thought/" rel="nofollow">https://9to5mac.com/2025/08/14/apples-first-mac-with-5g-cell...</a>
Dell, HP and Lenovo have had laptops with cellular modems for maybe 15 years at this point.
Yeah, but any given technology hasn't been invented yet, until Apple releases it.
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.
*A few select models got celluar modems.<p>I have owned several Dell, HP and Lenovo Laptops in the past 15 years and I have never had a cellular modem.<p>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.
> It's only a matter of time before laptops get 5G.<p>So you want laptops to cost <whatever the laptop costs> plus a measly 19.99/month for internet connectivity?<p>What's wrong with just tethering to my existing phone?
| Macbooks have been rumoured for a while to get cellular modems.<p>Maybe they are finally coming, however the rumors are older then the iPhone.
Example from 2008: <a href="https://pcr-online.biz/2008/11/03/3g-macbooks-on-the-way/" rel="nofollow">https://pcr-online.biz/2008/11/03/3g-macbooks-on-the-way/</a>
Thats quite surprising thing to me and weirdly obvious.<p>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.<p>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.
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.<p>They will. One from facebook, one from google, one from tiktok, several from Palantir and its partners...
As a French national, I am surprised to discover we are topping the charts according to this analysis.<p>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.<p><a href="https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/lipv6.html" rel="nofollow">https://www.arcep.fr/la-regulation/grands-dossiers-internet-...</a>
This is <i>probably</i> 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.<p>^1: <a href="https://en.wikipedia.org/wiki/Minitel" rel="nofollow">https://en.wikipedia.org/wiki/Minitel</a>
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.<p>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.<p>My personal impression is that this is the result of several cultural factors:<p>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.<p>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.<p>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.<p>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>P.S. I've spent some time in France, but was born in another country.
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.<p>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.<p>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.<p>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…<p>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 <a href="https://tunnelbroker.net/" rel="nofollow">https://tunnelbroker.net/</a> and <a href="https://route64.org/" rel="nofollow">https://route64.org/</a> although the later looks a little shady and I haven't tried them.<p>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.
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 <i>capability</i>, which does not 1:1 correspond how much <i>traffic</i> 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?<p>EDIT: Apparently it's 77% <a href="https://pulse.internetsociety.org/en/news/2026/01/china-hits-865m-ipv6-users/" rel="nofollow">https://pulse.internetsociety.org/en/news/2026/01/china-hits...</a>
"The graph shows the percentage of users that access Google over IPv6."<p>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.
The question is, "what will the graph look like in the next 10 years?"<p>I get the whole s-curve trend but if I squint at 2017, there is an inflection to slow the s-curve down.<p>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."
It's been amazingly linear since 2014.<p>amazon.com needs to get with the program. Still IPv4 only.
Just in time for ipv8 - <a href="https://www.ietf.org/archive/id/draft-thain-ipv8-00.html" rel="nofollow">https://www.ietf.org/archive/id/draft-thain-ipv8-00.html</a>
Been waiting for this for years! Now I just wish my local ISP (rural Canada) supported it.
worth noting that the google stat measures ipv6 <i>availability</i> 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.
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.<p>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.<p>Bot/crawler traffic is ironically 100% v4.<p>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.
Current submission title:<p>> IPv6 traffic crosses the 50% mark<p>Graph description:<p>> The graph shows the percentage of users that access Google over IPv6<p>There are reasons to expect both much more and much less traffic per user on IPv6 compared to IPv4...
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.
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.<p>- I don't want to have a permanent global unchanged ipv6 as in id of my traffic.<p>- 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
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?
Finally <a href="https://www.metaculus.com/questions/9558/50-of-users-access-google-over-ipv6/" rel="nofollow">https://www.metaculus.com/questions/9558/50-of-users-access-...</a> can resolve!
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.<p>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.<p>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.<p>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.<p>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.<p>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.
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).
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.
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.<p>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.
Quick, someone tell slashdot!
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.
I am in the middle of building infrastructure in GCP. The workload is your typical stateless web + db workload.<p>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.<p>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)<p>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<p>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.<p>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?<p>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.
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.<p>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.<p>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 <i>that</i> slow.
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?
My interest was piqued 20 years ago, then there was talk about Internet2 with all these amazing optimisations.<p>Things have developed so much, a Internet2 is still going on I take it, however is more focussed on university research.<p>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.<p>Further I imagine that there are some levels of criticality which when reached are more self sustaining (dare I say it the network effect?).<p>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.<p>France and Germany are at about 80%, but there's the rest of the world of course.
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.
Random test site for the consumer side: <a href="https://test-ipv6.com/" rel="nofollow">https://test-ipv6.com/</a><p>0/10 in Latvia with a local ISP, fun times.
Are any ISP's or corp intranets doing IPv6-mostly style networks yet: <a href="https://www.ietf.org/archive/id/draft-link-v6ops-6mops-00.html" rel="nofollow">https://www.ietf.org/archive/id/draft-link-v6ops-6mops-00.ht...</a><p>That seems to be a promising approach.
T-Mobile does: <a href="https://www.internetsociety.org/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/" rel="nofollow">https://www.internetsociety.org/deploy360/2014/case-study-t-...</a><p>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.<p>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 <a href="https://www.ipv6.org.uk/wp-content/uploads/2023/11/13_IPv6-Mostly-Office_-JenLinkova_UK-IPv6-Council-2023.pdf" rel="nofollow">https://www.ipv6.org.uk/wp-content/uploads/2023/11/13_IPv6-M...</a> , Google is.<p>The author of the RFC is the author of the slides.
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.<p>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.<p>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.<p>...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.<p>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).
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.<p>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.<p>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.
This is only 33 years after I took a networking class and learned all about IPv6 and the IPv4 address space crisis.
I wonder why Germany has a relative high adoption rate with 77%? They are normally behind when it comes to new technology.<p>Is it because they have more carrier NAT?<p>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.
Vodafone cable's cgnat struggles. I went v6 for home so that at least the v6 sites and my own connections avoid the congestion.
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.
Countries like India have higher adoption (>70%) because of 4G/5G abundance. Legacy broadband providers hold back IPv6 usage.
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.
In before the dinosaurs arrive to complain about the challenges of moving to IPv6 and why NAT and IPv4 are better. ;)
They have released the draft for IPv8 two days ago:
<a href="https://www.ietf.org/archive/id/draft-thain-ipv8-00.html" rel="nofollow">https://www.ietf.org/archive/id/draft-thain-ipv8-00.html</a><p>Does it mean we better put our chips on IPv8?
<a href="https://datatracker.ietf.org/doc/html/draft-wkumari-not-a-draft-24" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-wkumari-not-a-dr...</a>
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.<p>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.
This is the global curve, it looks to be flattening I had thought it would be more asymptotic to 100%.<p>My company is ipv4 still, and some customers are having issues with ipv6 only connections.<p>Also we log the ip addresses, and that's only in ipv4.
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.
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:<p><a href="https://clintonwhitehouse1.archives.gov/" rel="nofollow">https://clintonwhitehouse1.archives.gov/</a><p><a href="https://clintonwhitehouse2.archives.gov/" rel="nofollow">https://clintonwhitehouse2.archives.gov/</a>
If you have a big site and want as broad an access as possible I agree.<p>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."<p>There might be a child behind the NAT, thus IPv6 requirement.
crossed 50% on Mar 28, 2026, 3 weekends back.<p>google published the latest data only yesterday, hence the delay.
we did it, boys!<p>despite the smoothbrain naysayers:<p><a href="https://circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_28_percent_deployment_limit" rel="nofollow">https://circleid.com/posts/20190529_digging_into_ipv6_traffi...</a><p>finally, the end of the dark tunnel of NAT is in sight, and the internet will be free once more
And in the mean time, Odido on the Netherlands still don’t support ipv6 on their fiber network…
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<p>Neither is IPv6<p>> To get, basically, the same effect as moving to IPv6<p>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.<p>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.<p>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.<p>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.<p><a href="https://datatracker.ietf.org/doc/html/rfc1385" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc1385</a>
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.
IPv6 is IPv4 with 12 more bytes, right?
I'm surprised it's reporting is listed <5% - I thought it was pretty much ipv6 first?
And Virgin Media in the UK still doesn't support IPv6
I was wondering why someone proposed IPv8
There really should have been proper government pressure and fines long ago.<p>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...
It's all bots!!!
Puma 8.0+ webserver now defaults to IPv6
Good.<p>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.<p>But at least a reasonable facsimile eventually came out with NAT64.<p>(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.)
And yet I still haven't ever connected to an internet provider that supports IPv6, across two countries I spend time in...
forgive dumb question but what happens when someone on IPv6 without IPv4 tunnel visits a URL with only a IPv4 endpoint?<p>like say<p>* <a href="https://1.1.1.1/cdn-cgi/trace" rel="nofollow">https://1.1.1.1/cdn-cgi/trace</a><p>vs<p>* <a href="https://one.one.one.one/cdn-cgi/trace" rel="nofollow">https://one.one.one.one/cdn-cgi/trace</a><p>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
Waiting for github to support
The final 10% is gonna be a doozy..
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.
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.
90% spam/hack?
Spain: 9.9%<p>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.
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.<p>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).<p>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!
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.
I recently released a /24 that I registered in 1992 and I hadn’t realized it was still mine.<p>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!
A /24 is currently worth between $5,000 and $9,000 USD. Did you get them a long time ago?
None of which are any help when connecting to someone who doesn't have those.
US is significantly above average in terms of adoption
I worked for a state government agency that had a public /16
Our freaky network admins rolled it out in our global corpo.<p>Was fun seeing IPv6 running for a few days without problems.
[dead]
Great, then another 20 years and we can retire IPv4.
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.<p>Chris Siebenmann has written extensively on IPv6: <a href="https://utcc.utoronto.ca/~cks/space/?search=ipv6" rel="nofollow">https://utcc.utoronto.ca/~cks/space/?search=ipv6</a><p>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.<p>I am rather infuriated with the <i>status quo</i> 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.<p>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.)
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:<p>- IPv6 proponents are the only ones who know that NAT is not a firewall, and<p>- 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:<p><a href="https://www.ietf.org/archive/id/draft-thain-ipv8-00.html" rel="nofollow">https://www.ietf.org/archive/id/draft-thain-ipv8-00.html</a><p>Avoiding a dual-stack and making IPv4 a part of whatever superseeds it seems like the right choice to me.<p>IPv6 always seemed to me like throwing away all existing telephone numbers, just to support longer numbers.
IPv6 will never make it. Maybe IPv8 [0], which IPv6 should have actually looked like:<p>> 1.1.1.1.1.1.1.1<p>[0] <a href="https://www.ietf.org/archive/id/draft-thain-ipv8-00.html" rel="nofollow">https://www.ietf.org/archive/id/draft-thain-ipv8-00.html</a>
For observers, this draft was posted to HN earlier but quickly flagged and removed because the linked "IPv8" draft is absolute bunk.<p>See the removed thread for details: <a href="https://news.ycombinator.com/item?id=47788857">https://news.ycombinator.com/item?id=47788857</a>
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.<p>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.<p>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.
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%?
Nice idea. Always wondered why IPv6 went so ambitious with the addressing
One of the craziest aspects of IPv6 implementation is the reverse DNS lookups.<p>IPv6 uses ip6.arpa and segments each little nybble into a subdomain!<p><a href="https://en.wikipedia.org/wiki/Reverse_DNS_lookup#IPv6_reverse_resolution" rel="nofollow">https://en.wikipedia.org/wiki/Reverse_DNS_lookup#IPv6_revers...</a><p>This means there are <i>always</i> 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.
<p><pre><code> $ 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
</code></pre>
Run this, then copy/paste the output into your zone file. Remove the ; and add "example.com." or whatever to the end.<p>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?<p>If this is the craziest part of v6 then it must be incredibly well designed overall.
“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?<p>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.<p>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.<p>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.<p>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.<p>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.
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.<p>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.
Anyone who's ever had to delegate DNS authority on anything other than an 8-bit boundary can understand the value of that feature.<p>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.)<p>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 <a href="https://github.com/wttw/regexdns" rel="nofollow">https://github.com/wttw/regexdns</a> .
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?<p>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.
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.<p>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.<p>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.<p>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.<p>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.<p>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%.