Cloudflare sees over 40%, and it hasn't gone up even with the overall traffic increase. Personally, as the APNIC article also says about their own observations, the overall adoption is somewhere in between.
But we have to remember that this is reflects the adoption on the client side. With many high profile services still IPv4-only, the fraction of IPv6 on the public Internet is probably much lower.
> It would be awesome if they supported something like Hurricane Electric’s tunneling.
HE tunnel IP space is now sufficiently penalized as non-residential/office that I’ve had to turn it off anyway. YouTube, for example, largely seems to block users in HE space unless they are logged in.
It is entertaining that the situation becomes opposite in T-Mobile on States does not support IPv4 and only assigns IPv6 with 464xlat for "Fake-NAT" to IPv4.
Old Nanostations as a client seem to need to do proxy arp or something, which doesn't handle ipv6. That said it's probably 15 year old hardware. I ended up using a wireguard tunnel across it instead.
Reason that Google isn't seeing more is a) some BigCo v4 holdouts b) happy eyeballs sometimes landing on v4 because their v6 is shitty 6rd or something (e.g Free SAS)
In my experience not true in practice cause I have experienced way more issues with the IPv6 endpoints of sites than their IPv4 counterparts.
This becomes noticeable when pipelines on IPv6 connected servers suddenly have random request/post failures to public services. Then either the whole service is temporarily having issues or there are a few bad IPv6 endpoints while all the IPv4 endpoints are fine.
Seemingly this failure mode can go unnoticed for days while the same won't be true for IPv4 due IPv4-only still being the norm for corporate networks. And no, current form of happy eyeballs v2 won't account for this.
Besides bad endpoints it could also be a problem with bgp route advertisements where the IPv6 prefix takes a weird path and ends up being blocked by a CDN at the other side of the ocean.
This happens more than you'd think. Obtaining pypi packages was quite a challenge last year for us for a couple of weeks due to this.
Not really a fault of IPv6 technology wise, and in general can be solved client side through retry functionality, but in practice it still can lead to a worse outcome due to lackluster IPv6 adoption.
I used to think ISPs, organisations, admins and users were just being lazy for not implementing IPv6 or turning it off as the first thing to do when network problems happen, but when this far in the rollout such basic things still lead to difficult troubleshooting sessions then perhaps time has come to say something has gone terribly wrong.
It saddens me to say that I totally understand that businesses do not want to pay the price for implementing IPv6 unless absolutely necessary, because until the majority of traffic is IPv6 or even IPv6-only it does not make a lot of sense.
The flipping point is nearer than ever, though I fear it will in the short term lead to even worse stability for both protocols until IPv6 truly becomes the norm, whenever that may be.
Faster webrtc establishments and other negotiated connections. CGNAT means more relayed than P2P connections so it should be possible to have more direct traffic for services that want to save that bandwidth.
Google hits 50% IPv6, very good for accessing websites.
But my TP-Link router blocks by default inbound IPv6 connections, without any option to configure it, still bad for pure IPv6 bidirectional streaming, gaming or services on home networks.
Put OpenWRT on the thing and you'll be able to do what you want. Experience the joy of adding not port forwarding rules for IPv4 but more or less identical (same ports) access rules for IPv6.
All these systems are a reflection of the time that they were designed. IPv6 is 30 years old. At that time a lot of threats just didn't exist. One of my favorite is the decision to default to /64 blocks. There was a time when the designers believed that you'd use your 48 bit MAC address as part of this. Now we know that's a PII nightmare and nobody does it. Yet we're still stuck with the 128 bit addresses that came from that.
To your point, IPv6 sought to replace NAT with just having enough addresses but interestingly, that created a problem. If you used NAT and had a service on your computer request a port for incoming connections, that showed intent on behalf of the owner of that service. IPv6 doesn't have that intent, which forces home router makers do block addresses by default because you don't want most PCs on the Internet such that an external agent can scan your PC. You may end up with an unintended service on the open Internet.
So is the bigger address range better? Technically, maybe? But you have to consider defaults and intents of users. And that can take a good technical solution to a bad solution or at least create a whole bunch of problems.
I don't think this is inherently a problem. It's good for home routers to have sensible defaults. Blocking incoming IPv6 connections is such a thing. Opening a port in the firewall shows the same kind of intent as forwarding a port with NAT. The burden is on the router manufacturers to expose these options in a sensible way. My router for example has a similar UI to forwarding a port with IPv4 and opening the port for IPv6.
Using NAT as a firewall might work but it brings it's own problems. I find the IPv6 way better.
> There was a time when the designers believed that you'd use your 48 bit MAC address as part of this. Now we know that's a PII nightmare and nobody does it.
Nobody includes their MAC address in their public IPv6 addresses anymore, but every IPv6 setup that I've seen still gives every device a unique globally-routable IPv6 address, with no NAT at all.
> One of my favorite is the decision to default to /64 blocks.
The nice thing is that a /64 is big enough that clients can just randomly pick any address, and it will almost certainly be available, meaning that you don't need DHCP. This is actually widely implemented, and is known as SLAAC [0].
> Yet we're still stuck with the 128 bit addresses that came from that.
The extra address space only adds 16 bytes to every packet, and it ensures that we will never run out of addresses like we did with IPv4.
> Now we know that's a PII nightmare and nobody does it. Yet we're still stuck with the 128 bit addresses that came from that.
Randomizing the local address doesn't mean it isn't useful. You can't scan a /64 so that's already a major improvement. The fact that randomly selecting a number is effectively never going to collide greatly simplifies automatic network configuration.
The major issue is that the /64 isn't mandatory from a technical perspective. Being merely a subset of the larger address it's nothing more than a convention. In the end not all providers make it available to you even though supposedly they ought to.
If we're going to complain about anything it should be the godawful notation that so easily breaks parsers. Or the fact that the width is massively excessive which creates a usability nightmare due to normal humans not being able to readily recall 128 bit numbers (let alone how long it takes to type them in).
I made my homepage (www.makonea.com) support IPv6 too, but the number of people actually using it is much smaller than I expected. Is IPv6 really that widely used? I'm supporting both because I heard it's good to support both, but I'm not sure what the actual benefit is. Sometimes, when behind Cloudflare, I think even if someone connects via IPv6, it ends up coming through as IPv4
I accidentally became the user of an IPv6-only device a while back for some obscure reason I never could figure out. Let me tell you: There are no IPv6-only users. Absolutely nothing except Google, Facebook, and YouTube works. Any website not in the top 20 are IPv4-only. It was so bad I briefly thought I didn't have an internet connection at all. Anyone stuck on an IPv6-only connection would immediately cancel their contract on the grounds that they don't have de-facto internet access.
When hosting a server IPv6 doesn't make a huge difference beyond your logs will probably be a bit more accurate, people behind CGNAT where an ISP has multiple customers sharing a block of IPv4 will show up with their actual IPv6 address. They'll maybe also find it slightly quicker because they're not being funnelled through NAT gateways but realistically not enough to notice.
From the user side IPv6 is great for me. My ISP is using CGNAT and would bill me ten pounds a month for a static IPv4 address but I automatically get a vast block of IPv6. I'm using that block to allow me to VPN back home when out and about, and if I wanted to I could also host services from devices on my home network without needing any NAT nonsense, I can just open access to the relevant device on the router. (Because this is a world where not everywhere supports IPv6 yet if I'm on an IPv4 only network the VPN endpoint is a dedicated server I rent which forwards the relevant port back to my home router over IPv6)
Thank you for the advice. By any chance, have you worked with Ruby before? I remember seeing your username back when Ruby was popular and I first started learning it in university
It's good to support it to resolve the chicken egg problem. If no service supports it, there is no sense in deploying it to the customers and the other way around.
Also you made the life better of people who have DS lite. They only get a public IPv6 and all their IPv4 traffic goes through a CGNAT.
Yes, it is old, many examples are outdated, but the main points still hold. Decades later his suggestions for making IPv6 succeed are still not implemented.
For client server web browsing what's the downside of CGNAT? I'd understand if we were talking about self hosting a service from home but for typical consumer usage?
1. Peer-to-peer networking won't usually work correctly. And quite a bit of software uses P2P networking these days---BitTorrent, Zoom/Teams (via WebRTC), Tailscale, PlayStation/Xbox multiplayer, etc. Most of these services have automatic fallbacks when P2P networking doesn't work, but these fallbacks are usually slower and less reliable.
2. Most websites assume that 1 IPv4 address==1 household, so you'll often run into rate limits. Or even worse, you might be blocked entirely if your CGNAT neighbours are spammers or otherwise breaking website rules.
While true, neither of those are relevant in context (and I even explicitly acknowledged your first bullet in my comment above). It was suggested that a website operator deploying IPv6 would somehow improve the end user experience by virtue of avoiding CGNAT and I was questioning that. I do of course appreciate that going via CGNAT to a clueless operator that eagerly adds IPv4 bans can be problematic but that's more a question of why you as a consumer might want IPv6 connectivity not why a service provider would want to deploy it.
First thing I do on a fresh Linux install is set ipv6 to deactivated. Fixes all my initial Linux install problems. I don't question it, it just works every time.
Similar experience. I bought an ASUS router and enabled IPv6. It slowed down everything down. Immediately flashed OpenWrt on it, IPv6 works like charm.
It's usually bad configuration done by the router vendors. It doesn't mean IPv6 is bad.
There are maybe many buggy routers still out there that reset the IPv6 flow label field when they shouldn't, breaking hash-based load-balancers (the symptom is TCP connections spontaneously reset).
IIRC, a workaround was to prevent Linux from setting this field, or force-reset it on every outbound packet using netfilter.
UX issue, and UX issues are often downplayed by engineers, leading to adoption failures.
Another such example is SELinux, which would have prevented so many vulnerabilities from being exploited, but whose poor UX also caused everyone to disable it at install time.
SELinux's UX was significantly improved many years later, but already too late to change ingrained opinions. There are a lot of ingrained opinions about IPv6 too.
I’ve yet to live anywhere where the available mainstream ISPs were willing or able to provide IPv6 service. I’d be happy to use it, if I were able.
I also have built cloud infrastructure for multiple SaaS providers with tens of thousands of customers over the past decade. Only one customer I’m aware of has ever even requested IPv6 support. And if customers aren’t asking for it, my employers have never been interested in the full network re-architecture required to truly support it internally.
There are still several basic services you can’t run IPv6-only in AWS, and a handful of AWS service features that don’t support it at all.
As a sysadmin for decades now, I’ve always found IPv6 to be overengineered and in many ways completely ridiculous. But I’d love to be supporting it in everything I do. Only I still can’t, even after 20+ years of being lectured about it; even after complete IPv4 exhaustion has been reached. I don’t think we’re ever going to turn IPv4 off. At best it will be progressively hidden, even from technical users. And folks like me will just have to keep building workarounds to patch the holes where IPv6 still doesn’t work.
Apart from the chicken egg problem what are things that are bad about IPv6. What do you think is overengineered?
I personally found that the features I interacted with were useful (SLAAC, address size, router advertisements, ...) and the changes made it cleaner (removal of broadcast for multicast, removal of fragmentation fields, ...).
Just remove the A record, and nearly all the scrapers disappear. :-) (And then you get one email per month or so that “your host does not resolve in DNS”.)
Google is having a real issue with LLMs using it for search. As in, real load issues. Unless you're running a publicly accessible search engine, and the top one at that, the LLM traffic you're seeing is not representative.
I want Google gone. This company is causing too many problems.
I am still sometimes using Google Search. First results are now
almost always videos on youtube, aka self-promo. These videos are
in 99.9% of the search results I use, totally useless and worthless.
Even searching on youtube has recently gotten worse. It is also
crap now. I know that because I bookmark various videos, and I
can not find older videos anymore either. I can eliminate some
results I don't care via ublock origin hero-blocking this Google
garbage, but I really think we should no longer allow this de-facto
monopoly to worsen the global situation any longer. The USA is
protecting these gangsters - it is time to have true legislation
that gets rid of that mafia bloc that is Google.
Great example of how fixing things "the correct way" does not seem to work sometimes.
They added those new addresses that can store more information.. but this requires a rewrite of old software to make it work.
If they used the old >bolting on top< method by extending ip4 from 4 octets to 8 (or more) octets, then old software could be extended much easier too / probably addresses could be simply mechanically translated too, so ancient software can work.
There is no space to put the additional octets. Supporting this would have needed a rewrite anyways. Nothing won there. They took that as a chance to improve the protocol overall.
Software availability isn't really the problem. For most software there was no change at all ("connect to that host" or "listen to any device" and operating system will handle details), most software which needed adaption had it for a while (picking up a devices explicitly, handling of IPv6 addressees, ...) while maybe not equally good (missing GUI improvements for better handling of IPV6 addresses)
The problems, as I observe, are more in network infrastructure, routing, etc.
You have not heard if before, because that is the most naive and stupid take imaginable. It is the “let them eat cake” of networking.
It does not work like that. Put extra octets where exactly? Where would a hardware router put the extra bytes? Where would software with 32 bit buffers?
You would still need to replace all of the software and hardware and have the exact same problem.
But we have to remember that this is reflects the adoption on the client side. With many high profile services still IPv4-only, the fraction of IPv6 on the public Internet is probably much lower.
https://radar.cloudflare.com/adoption-and-usage#ipv4-vs-ipv6