Just to add to the 'but the ISPs do not' anecdotes, it has been six months since someone last commented so it is probably time to mention this again on Hacker News:
A major ISP in the U.K., that said in a public statement on World IPv6 Day in 2011 that
> As well as our core and access networks being capable of supporting IPv6, we're rigorously testing our entire network to ensure that all customers have a smooth and simple transition when the time comes to flick the switch and turn IPv6 on. We're really pleased with how our tests are advancing and are happy to say that by the end of 2012, we'll be able to fully support customers looking to switch to IPv6.
has not managed to actually flick that switch in 15 years.
15 years is plenty of time to switch away from them. IPv6 is just one reason. It's a shit ISP. I ditched them as soon as I could and cited IPv6 as a reason, in case it made a difference (I also questioned my new ISP before I joined).
Virgin Media exist for two reasons: first they were given a monopoly by their Tory chums (Thatcher) and, second, all ISPs are allowed to make you sign absurdly long, anti-competitive contracts (18 months is common). If ISPs were treated the same as utility suppliers we'd probably be in a better place.
Purely from a business perspective, for VM there is no point. They have more than enough v4 to keep them going, customers (outside of a tiny technical minority who probably wouldn't chose VM anyway) do not see any benefit.
That plus other ISPs v6 implementations breaking things randomly, I understand why they don't bother.
The corporate world tend to be easy to do, just put a gateway to IPv6 on their zScaler (or similar) exit points and done. However, that is not really needed as they are "only" consuming a few IPs around the world (for that purpose). No one in the corporate world wants to go back to the days of Public IPs on all devices. Internally the enterprises have no reason to switch as it just complicates their setups.
Prices have been coming down for years in nominal terms, let alone real terms. Cg nat does everything that’s needed, there are no significant ip6 only services, there are plenty of ip4 only services, so you have to support ip4 anyway, so why bother with ip6
My company has just turned off all ip6 connectivity for its corporate laptops because it’s considered a security risk. I disagree, but I do agree that having 4 and 6 is a higher risk than 4 alone or 6 alone, and 6 alone sadly still doesn’t work reliably.
All the “promise” of ip6, direct connections etc, were lost when stateful firewalls became required and memory became cheaper than $20 a megabyte. Some bespoke old protocols don’t like ports changing, which can be a problem, but it’s a very small number and easier to work around with modern protocols than support a dual stack environment securely for the majority of places that struggle securing a single stack.
Except for making it convenient for end-user to, say, play P2P video games, or host Mindcraft servers, etc.
> […] and 6 alone sadly still doesn’t work reliably.
It's so unreliable that half of all Internet traffic uses it. It's so unreliable that Microsoft has been going IPv6-only in their corporate networks (a decade ago):
Everything that's needed besides letting computers talk to each other, that is.
With ipv4 you have a two tier internet. Computers talk to servers, servers talk to servers, computers can't talk to computers so every video call must be routed through a server.
I hear this as a cited as a benefit of IPv6 a lot. Honest question: Isn't this at least a privacy issue, at most a security issue? SLAAC seems like what we already have with extra, breakable steps, which doesn't effectively address the privacy issue anyway.
That the server can figure out that two computers in the same house are different since your laptop and phone no longer share the same ipv4 address but instead have two ipv6 address?
Security? NAT is not a firewall, you need a firewall, and switching to IPv6 does not remove your firewall.
Before IPv6: The server gets "1.2.3.4:56789" for your device. After IPv6: the server gets "1:2:3:4::56" or whatever for your device. In either case, if the server makes a connection to 1.2.3.4:56789 or 1:2:3:4::56, your router sees the packet and firewalls the connection. Cool.
Want to give me a concrete example of where IPv6 is hurting my privacy or security, because I've been using it for over a decade with zero mishaps, zero privacy issues, zero security issues (to my knowledge at least)
They used to recommend using the MAC address. This was ok 30 years ago when a computer sat in an office on a desk but it makes it very easy to fingerprint a moving computer as it moves across different networks.
Using a random address (Privacy Extensions) solves this problem though, but do we expect everyone to know what that is and check it's enabled? Mine wasn't enabled by default (on Linux) and I only noticed when a bittorrent site warned me.
Everything useful is a security issue. Security is a trade-off, not a positive stat you maximize. Every security tightening removes some utility from a system; the hope is that this disproportionally disrupts the "bad actors" over "good ones".
(All of that hinges on the key question that people seldom ask: what is being protected, and from who. The "two-tier" Internet is, in a way, pointing out a case where regular users are seen as threat actors.)
Yes. Letting anyone talk to anyone was the point of the internet. It's been co-opted by these massive centralising forces and you know what? They're right. With IPv4 everything has to be centralised, we don't even have the faintest chance to avoid it. With IPv6 at least we have a chance to take it back.
Some people will mention stateful firewalls. They're pretty easy to holepunch through because you just need each side to send a packet to the other, then each firewall sees it as an outgoing connection and allows it. It's nothing like IPv4 NAT.
> My company has just turned off all ip6 connectivity for its corporate laptops because it’s considered a security risk. I disagree, but I do agree that having 4 and 6 is a higher risk than 4 alone or 6 alone, and 6 alone sadly still doesn’t work reliably.
I had a very concreteish security risk with IPv6 and openvpn. At least in Debian config openvpn tunneled only IPv4 by default. I only noticed this by being surprised I got results tailored to my origin country instead of the VPN out node country.
It's eternal (dual stack) paper cuts like this why just turning IPv6 off makes life a lot easier.
> 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, and I frequently ran into neverending captchas.
Every ISP has to pay Hurricane Electric for their tunnels, that's why it's free to you. If enough people start using HE tunnels, ISPs will get native IPv6.
But you can't use HE tunnels because every website you visit will block you. You also can't use them from CGNAT or if your home router doesn't have a DMZ.
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 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.
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.
> I don't think this is inherently a problem. [...] My router for example has a similar UI to forwarding a port with IPv4 and opening the port for IPv6.
Glad to hear that you don't have a problem with your router, but how does that relate to GPs problems with theirs?
The solution for them is "get a better router" because the problem is not the IPv6 protocol. Opening a port is not harder than creating a NAT forwarding and if your hardware can't do it then it's bad.
> 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.
With current addressing scheme we only have 2^13 times more site addresses than IPv4, which is plenty in absolute numbers, but not necessarily enough for more coarse aggregation, and definitely not infinitely future proof.
Crucially though, if we change it, we just have to change how addresses are allocated, not change the protocol again.
> 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.
Every residential router already has PCP (RFC 6887) and UPnP IGD to deal with the NAT44 non-sense that is the status quo, and both protocols support IPv6 hole punching, so IPv6 default deny as a policy is hardly an issue in the residential space.
MiniUPnPd, which many Linux-based CPEs use, has supported IGDv2 (needed for IPv6) since 2012 (as well as PCP).
The point of local networks of a minimum size of 64 bit isn't only to have MAC-based addresses (48 bit would have been enough for that, fwiw), but in general to support non-coordinated/probabilistic self-assignment schemes with negligible collision probability.
Picking a random local address (which is very important for privacy, as you've mentioned) is much easier if you don't have to do an elaborate dance of listen, announce, listen for collisions etc. first (practically that still happens, but collisions are the absolute exception).
> So is the bigger address range better?
Yes, because consider the alternative of re-doing all of this again in a future in which IP usage for some reason jumps by a few orders of magnitude again.
Due to hardware getting better over time, the per-packet cost of a few extra bits is going down all the time, while the cost of rolling out a future IPv7 increases with every new deployed host.
The best thing about SLAAC is that it forces your ISP to give you at least 64 bits. Otherwise you know Comcast would only give out a /128 and charge you for more, so you'd use NAT at home just like 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).
Cloudflare sees over 40%, and it hasn't gone up in the last year even with the overall traffic increase. Personally, as the APNIC article also says about their own observations, I guess the overall adoption is somewhere in between.
But we have to remember that this reflects the adoption on the client side. With many high profile services still IPv4-only, the fraction of IPv6 flowing on the public Internet might be much lower.
I wonder what incentives are needed to push this forward, because it's not the same incentives as years ago for sure. We've long since exhausted new IPv4 allocations.
Here in Belgium it's the other way around. we've had IPv6 for over 10 years for basically all home internet, but mobile is still ipv4 only. Not sure why since it's all the same companies.
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)
I'd however mention, the two biggest ISPs that remain today both have adopted IPv6 on their fiber connections. They're also heavily using CGNAT for IPv4. It makes sense, the volume at which they're working makes dedicated IPv4 very uneconomical.
Even smaller ISP have done that. But I switched to JioFiber last year and it loses its IPv6 network every week for a few hours. Diagnostics tell me that everything is okay and the customer support just doesn’t understand the problem.
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.
> In my experience not true in practice cause I have experienced way more issues with the IPv6 endpoints of sites than their IPv4 counterparts.
If you've ever visited a website from your smartphone (over 4G/5G), your first hop has in all likelihood been over IPv6. If you have visited a website from your phone that only had an A record then you probably went through a CG-NAT box, which added latency.
If you streamed a Youtube video to your phone, or checked Gmail, or Instagram or Facebook, then it was over IPv6.
People (including probably you) use IPv6 everyday, multiple times, without knowing it.
> 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.
Do you have examples for this? I've never experienced this, and I've been using IPv6 for years.
Also, how can you be sure that the same request to IPv4 would have been fine? Did you actually see consistent failures on v6 and consistent success on v4? Otherwise, if a service has a reasonably low error rate, success on retry is the expected outcome, regardless of the path the retry takes.
There were indeed consistent failures to specific IPv6 endpoints, clearly identifiable through curl, while all the IPv4 endpoints were ok.
This happened with pypi (IPv6 BGP routing problem caused by a bad route from one of our peers combined with their fastly CDN not reply to us on IPv6 from the other side of the ocean for some weird reason), but also with yum and apt mirrors (seemingly random problems with the IPv6 service or firewall of the remote endpoint), and various other web resources accessed from pipelines.
The solution always was to temporarily block the bad IPv6 endpoint(s) or temporarily completely disabling IPv6 on the server itself or on the squid proxy server for workloads without direct connectivity.
Obviously it also can be the other way around, but in practice it appears to happen less often with IPv4, and if it does things get addressed quickly instead of taking hours or days or weeks.
I have been on a dual stack IPv4 and IPv6 connection for a while now. IPv6 is the preferred protocol. I think I'd have noticed if there were widespread IPv6 issues. It used to be worse, but that was years ago.
I have yet to see any ISP use CGNAT here in Sweden. It seems to be a highly regional problem for some reason. Both on mobile and on broadband I get publicly routable IPv4.
That's because Sweden joined the internet relatively early when enough addresses were available. It's like that in most 1st-world countries. Places like Argentina, on the other hand, may have to share 8 IPv4 addresses per city.
That depends on your isp. Mine certainly doesn’t, and I’ve never had an isp on the U.K. which didn’t give me at least a dynamic ipv4 address to my router.
Infact the only isp I have seen do it is starlink and I have contacts with ISPs in 60 different counties.
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.
and anything P2P. Maybe that would have been a driver 20 years ago, but now everything is expected to be centralised. Our culture has shifted. Remember when people used to host their game servers? If you're under 16, you don't because it was never in your lifetime.
I have to open a hole in my firewall to host any service. Nat doesn’t change that.
Unless you want to host multiple minecraft servers on the same port on different servers at home?
Indeed hosting anything at home is such a rare workflow that someone wanting it can choose an isp which gives them the facilities they need.
Unless you don’t live in a competitive market based economy and just have the single government mandated isp aimed at the lowest common denominator, in which case you’ve got far worse problems.
Or unless you do live in a competitive market based economy, and have a choice of several ISPs with practically equivalent offering aimed at the lowest common denominator, none of whom supports something niche like "giving you facilities for hosting stuff at home".
If there's one thing market competition does well, is remove any kind of meaningful variety - because supporting a niche offering costs money, and is not worth it unless it nets positive, otherwise it's just a drag that makes you fall behind your competition.
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
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.
> 1) my stateful firewall is going to break most of that anyway
Stateful firewalls and even regular NAT aren't much of an issue for P2P, but CGNAT is much more problematic [0].
> 2) if cg nat is as popular as people claim then they won’t be doing that as it’s not an edge case
You'd hope, but people tend to be pretty slow to update their networking assumptions, so this is still pretty common. And it doesn't help that most CGNAT users tend to be either from poorer, since poorer countries and mobile data providers are far more likely to use CGNAT than legacy North American ISPs.
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.
> While true, neither of those are relevant in context (and I even explicitly acknowledged your first bullet in my comment above).
Yeah, I just mentioned that because P2P networking is used a lot more than most people think these days, since even things like Zoom that look like typical client–server web browsing actually use P2P networking internally.
> 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.
Reliability and latency will be marginally better with IPv6 than with CGNAT, but this is so minor that I doubt that most people will notice this. And many CGNATs will RST connections that last too long, but most protocols have some sort of automatic retry/reconnect built in, so this shouldn't cause issues very often either.
IPv6 addresses are quite a bit cheaper than IPv4 addresses in most clouds, but since most servers still need to support IPv4, this doesn't help you directly. Supporting IPv6 means that others using the cheaper IPv6-only cloud services will be able to connect to your server, but this doesn't matter for consumer-only services.
So yeah, you're probably right that enabling IPv6 server-side won't have (m)any benefits.
> 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.
Being able to ban IP addresses without worrying about collateral damage is a pretty big benefit to the service provider though, for certain applications at least.
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)
So your isp is rinsing you for the cost of a an IPv4 address. £10 a month will pay for a whole /24 in 3 years.
Chances are they also skimping on other areas including over subscription. Choose a better isp if you want a better service.
Your “just open traffic to internal host 1 on your firewall is the same no matter if it has nat or not, unless you are using a non stateful firewall? Or perhaps your configuration layer splits the two for reasons.
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
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.
You can do IPv6 only if you have a 64 nat on your edge and use dns64 and just use a limited set of applications and devices.
Some applications will still fail to work though unless you also have 46 nat on your device which still doesn’t work transparently on majority of types of device.
You also need all devices on your lan to support v6 natively, and v6 only. From your printer to your speaker.
You might be able to do something with mdns and nat64 to get them working on an IPv4 only subnet. But you’re talking layers and layers of complexity for things which just have to work.
I’m posting this from my phone on my IPv6 only subnet, not sure if it’s using a 64 gateway or 6 native to HN, but it’s possible.
All the more reason to support it. There are lots of ISPs that only assign you an IPv6, and do hacky trickery to make IPv4 work over that. We wouldn’t need all of this.
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.
> I’ve always found IPv6 to be overengineered and in many ways completely ridiculous.
Most software continues to have horrible IPv6 support and documentation making it look more complicated, but the actual protocol is considerably simpler than IPv4. For example:
1. An IPv4 packet header is variable-length, and the checksum must be recalculated by every router because the TTL is included in the checksum. Whereas an IPv6 packet header is fixed-length and has no checksum.
2. NAT is effectively required with IPv4, but it makes everything much more complicated, since it means that most computers don't even know their "real" IP address, it makes peer-to-peer networking very challenging, and it's tricky for routers to implement. Whereas with IPv6, no NAT is required.
3. Any router along the network path is allowed to fragment an IPv4 packet, and is in fact required to if its MTU is smaller than the packet's size. Whereas only the originating node is allowed to fragment an IPv6 packet.
4. To acquire an IPv4 address, both clients and routers must implement DHCP, which is a fairly complicated protocol, and both clients and routers must remember the list of assigned addresses. Whereas with IPv6, the client can just choose a random address (via SLAAC) and then start using it immediately.
5. IPv6 multicast is considerably simpler than IPv4 multicast, and NDP (v6) is considerably simpler than ARP (v4).
Despite all this, I agree with you that setting up IPv6 networking is harder than setting up IPv4 networking, but this is more of a software problem than a protocol problem.
2 is a security nightmare but that’s why firewalls prevent it by default
3 well you can set the dont fragment bit at a client side or a router can drop the packet. These are choices. If a 1500 byte IPv6 packet arrives on a router with an 1100 byte next hop, does it just drop? Or send back a fragmentation needed icmp? How is that different from setting a “don’t fragment” option on a router.
4 isn’t created from a security or management point of view either. And v4 has the 169.254 range for this purpose. I guess the lack of router advertisement is the primary difference. And the operational expectations.
5a I’m not sure about. My main experience with multicast is pim-sm on v4. SSM v4 multicast however seems simple, and while I don’t use it as I have kit that’s too old for it is v6 really easier than v4/ssm/igmp3?
As for arp, I don’t see any real complexity with it as a network operator, but maybe that’s because I’m used to it. Perhaps it’s easier to implement nd rather than arp, but given almost every v6 deployment for the last 30 years is dual stack all it does is increase complexity.
The only one I don't understand is how NDP is simpler than ARP. ARP is an Ethernet broadcast while NDP is built on IPv6 multicast which creates a recursive chicken and egg situation.
I'm interested, apart from the chicken egg problem, what are things that you found 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, ...).
In America I've never had a non-mobile ISP offer IPv6. At this point it would be best to recognize the sunk cost and give up on the migration. IPv6 will never reach the 100% needed to turn off IPv4.
> IPv6 will never reach the 100% needed to turn off IPv4.
As was predicted in 1994:
Furthermore, we note that, in all probability, there will be IPv4
hosts on the Internet effectively forever. IPng must provide
mechanisms to allow these hosts to communicate, even after IPng
has become the dominant network layer protocol in the Internet.
Thugs are slowly moving. Another 5 years and most windows machines will support clat. Another 20 and most machines will hopefully support it. I wish it was embedded in the Linux kernel though as that increases the chance of your device working transparently on an IPv6 only subnet using slaac and the application creator doesn’t need to know anything other than their internal dhcp gets a 10.x address and everything works using 464.
I think the future is bright and most problems will be solved by 2040, and almost all by 2050.
And I've only ever had v6, both on DOCSIS and fiber. Both observations are pretty useless in the grand scheme of things; actual adoption rates are what matter.
> At this point it would be best to recognize the sunk cost and give up on the migration.
That's a pretty wild thing to say in the comment section of an article about v6 reaching 50% eyeballs-side deployment.
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.
Do you think routers perform their work using the human-readable addresses?
If so, that is incorrect. They use the binary values. The actual difference between IPv4 and IPv6 is that IPv6 uses 128-bit addresses, not 32. So you can devise whatever human-readable abstraction you like, it won't change how networking actually operates.
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.
Actually no software rewrite is needed because the Berkeley Sockets API is agnostic to address format. If your software requires a particular address format, that's a bug. if you pass an IPv6 literal to getaddrinfo, you get a result with an IPv6 address structure and it tells you the IPv6 socket type you need to connect to it.
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.
Are you just talking about how you write the addresses or are you talking about the actual protocol?
The IPv4 protocol has 4 octets each for source and destination address. Period. If you change that, your packets won't work on any IPv4 routers or software any more.
If you want to write IPv6 addresses as numbers separated by dots no one's stopping you but I don't see how it's better. They switched to hex because the old format was too long.
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.
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.
Conversely it means people who have ISPs that do IPv6 just have IPv6 and don't need to turn it off. Because it just works. The other day my IPv4 was down and I didn't even notice.
Most of what people see as "SELinux" is actually the default policy, which started out as way too strict. Then SELinux-enabled distros such as Red Hat moved to a policy that only applies to system services, and leaves user-launched binaries as if SELinux was disabled.
And even for system services, you can disable SELinux for one service (permissive mode) and leave it enabled for the rest.
This has been the case for more than 10 years, but the damage was done. It's now very hard for users even considering learning the basics (which are not hard).
Just to add to the 'but the ISPs do not' anecdotes, it has been six months since someone last commented so it is probably time to mention this again on Hacker News:
* https://havevirginmediaenabledipv6yet.co.uk/
A major ISP in the U.K., that said in a public statement on World IPv6 Day in 2011 that
> As well as our core and access networks being capable of supporting IPv6, we're rigorously testing our entire network to ensure that all customers have a smooth and simple transition when the time comes to flick the switch and turn IPv6 on. We're really pleased with how our tests are advancing and are happy to say that by the end of 2012, we'll be able to fully support customers looking to switch to IPv6.
has not managed to actually flick that switch in 15 years.
* https://ispreview.co.uk/story/2011/06/08/uk-isp-fluidata-hai...
15 years is plenty of time to switch away from them. IPv6 is just one reason. It's a shit ISP. I ditched them as soon as I could and cited IPv6 as a reason, in case it made a difference (I also questioned my new ISP before I joined).
Virgin Media exist for two reasons: first they were given a monopoly by their Tory chums (Thatcher) and, second, all ISPs are allowed to make you sign absurdly long, anti-competitive contracts (18 months is common). If ISPs were treated the same as utility suppliers we'd probably be in a better place.
Purely from a business perspective, for VM there is no point. They have more than enough v4 to keep them going, customers (outside of a tiny technical minority who probably wouldn't chose VM anyway) do not see any benefit.
That plus other ISPs v6 implementations breaking things randomly, I understand why they don't bother.
Specifically on weekends, which seems to indicate that it's the corporate/business network side of things that is not bothering with implementing it.
The real milestone is when it's over 50% all the time.
You frame "not bothering" as if its a checkbox with "enable IPv6" to check and all done...
Put all work into reorg, for what? Some numbers to change? Why when IPv4 works?
The corporate world tend to be easy to do, just put a gateway to IPv6 on their zScaler (or similar) exit points and done. However, that is not really needed as they are "only" consuming a few IPs around the world (for that purpose). No one in the corporate world wants to go back to the days of Public IPs on all devices. Internally the enterprises have no reason to switch as it just complicates their setups.
Noooo, my /22 IPv4 subnet allocation is my personal 401k, I need this money to retire.
You joke, but its exactly how society thinks about housing…
Time to cash in?
Prices have been coming down for years in nominal terms, let alone real terms. Cg nat does everything that’s needed, there are no significant ip6 only services, there are plenty of ip4 only services, so you have to support ip4 anyway, so why bother with ip6
My company has just turned off all ip6 connectivity for its corporate laptops because it’s considered a security risk. I disagree, but I do agree that having 4 and 6 is a higher risk than 4 alone or 6 alone, and 6 alone sadly still doesn’t work reliably.
All the “promise” of ip6, direct connections etc, were lost when stateful firewalls became required and memory became cheaper than $20 a megabyte. Some bespoke old protocols don’t like ports changing, which can be a problem, but it’s a very small number and easier to work around with modern protocols than support a dual stack environment securely for the majority of places that struggle securing a single stack.
> My company has just turned off all ip6 connectivity for its corporate laptops because it’s considered a security risk.
If your corporate laptops are running Windows, then you're going against the officially supported configuration of the vendor (Microsoft):
> Internet Protocol version 6 (IPv6) is a mandatory part of Windows Vista and Windows Server 2008 and newer versions.
> We don't recommend that you disable IPv6 or IPv6 components or unbind IPv6 from interfaces. If you do, some Windows components might not function.
* https://learn.microsoft.com/en-us/troubleshoot/windows-serve...
> Cg nat does everything that’s needed […]
Except for making it convenient for end-user to, say, play P2P video games, or host Mindcraft servers, etc.
> […] and 6 alone sadly still doesn’t work reliably.
It's so unreliable that half of all Internet traffic uses it. It's so unreliable that Microsoft has been going IPv6-only in their corporate networks (a decade ago):
* https://labs.ripe.net/author/mirjam/ipv6-only-at-microsoft/
It's so unreliable that Google is now 99% IPv6-only/mostly on their corporate networks:
* https://www.youtube.com/watch?v=UTRsi6mbAWM
Everything that's needed besides letting computers talk to each other, that is.
With ipv4 you have a two tier internet. Computers talk to servers, servers talk to servers, computers can't talk to computers so every video call must be routed through a server.
I hear this as a cited as a benefit of IPv6 a lot. Honest question: Isn't this at least a privacy issue, at most a security issue? SLAAC seems like what we already have with extra, breakable steps, which doesn't effectively address the privacy issue anyway.
Where's the privacy issue?
That the server can figure out that two computers in the same house are different since your laptop and phone no longer share the same ipv4 address but instead have two ipv6 address?
Your phone and laptop can just have multiple ipv6 addresses and rotate through them regularly... as apple does by default https://support.apple.com/en-ca/guide/security/seccb625dcd9/...
Security? NAT is not a firewall, you need a firewall, and switching to IPv6 does not remove your firewall.
Before IPv6: The server gets "1.2.3.4:56789" for your device. After IPv6: the server gets "1:2:3:4::56" or whatever for your device. In either case, if the server makes a connection to 1.2.3.4:56789 or 1:2:3:4::56, your router sees the packet and firewalls the connection. Cool.
Want to give me a concrete example of where IPv6 is hurting my privacy or security, because I've been using it for over a decade with zero mishaps, zero privacy issues, zero security issues (to my knowledge at least)
They used to recommend using the MAC address. This was ok 30 years ago when a computer sat in an office on a desk but it makes it very easy to fingerprint a moving computer as it moves across different networks.
Using a random address (Privacy Extensions) solves this problem though, but do we expect everyone to know what that is and check it's enabled? Mine wasn't enabled by default (on Linux) and I only noticed when a bittorrent site warned me.
As mentioned by GP, Apple enables privacy extensions on all their OSes:
* https://support.apple.com/en-ca/guide/security/seccb625dcd9/...
As does Windows (since Vista), and Android (8+).
So why are we still talking about this?
Everything useful is a security issue. Security is a trade-off, not a positive stat you maximize. Every security tightening removes some utility from a system; the hope is that this disproportionally disrupts the "bad actors" over "good ones".
(All of that hinges on the key question that people seldom ask: what is being protected, and from who. The "two-tier" Internet is, in a way, pointing out a case where regular users are seen as threat actors.)
And wasn't that THE POINT of the internet and it's decentralised design?
Yes. Letting anyone talk to anyone was the point of the internet. It's been co-opted by these massive centralising forces and you know what? They're right. With IPv4 everything has to be centralised, we don't even have the faintest chance to avoid it. With IPv6 at least we have a chance to take it back.
Some people will mention stateful firewalls. They're pretty easy to holepunch through because you just need each side to send a packet to the other, then each firewall sees it as an outgoing connection and allows it. It's nothing like IPv4 NAT.
> My company has just turned off all ip6 connectivity for its corporate laptops because it’s considered a security risk. I disagree, but I do agree that having 4 and 6 is a higher risk than 4 alone or 6 alone, and 6 alone sadly still doesn’t work reliably.
I had a very concreteish security risk with IPv6 and openvpn. At least in Debian config openvpn tunneled only IPv4 by default. I only noticed this by being surprised I got results tailored to my origin country instead of the VPN out node country.
It's eternal (dual stack) paper cuts like this why just turning IPv6 off makes life a lot easier.
About 2023 I think
You'll be really screwed in around the year 2100!
Meanwhile T-Mobile/Odido in the Netherlands is still not supporting IPv6 despite promising to have been working on it for years.
Ubiquity gateways also seem to not support it sadly. It would be awesome if they supported something like Hurricane Electric’s tunneling.
> 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, and I frequently ran into neverending captchas.
Every ISP has to pay Hurricane Electric for their tunnels, that's why it's free to you. If enough people start using HE tunnels, ISPs will get native IPv6.
But you can't use HE tunnels because every website you visit will block you. You also can't use them from CGNAT or if your home router doesn't have a DMZ.
And wouldn’t it add a considerable latency?
Possibly. They let you pick your nearest server, and HE is a tier-1 ISP which a lot of your packets may traverse already.
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.
They support it. I have it enabled with Spectrum. No file modification necessary; all configurable from the UI.
https://help.ui.com/hc/en-us/articles/36378535649687-Configu...
Huh? Ubiquity has dropped support? I can't believe that, even the older EdgeRouter series supported it.
Old Nanostations as a client 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.
Thread from two months ago (626 comments): https://news.ycombinator.com/item?id=47777894
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.
> I don't think this is inherently a problem. [...] My router for example has a similar UI to forwarding a port with IPv4 and opening the port for IPv6.
Glad to hear that you don't have a problem with your router, but how does that relate to GPs problems with theirs?
It isn't. But It's also not an answer to GP.
The solution for them is "get a better router" because the problem is not the IPv6 protocol. Opening a port is not harder than creating a NAT forwarding and if your hardware can't do it then it's bad.
Exactly, and “there are a lot of bad v6 implementation CPEs out there” is an important data point worth acknowledging.
> 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.
[0]: https://en.wikipedia.org/wiki/IPv6#Stateless_address_autocon...
With current addressing scheme we only have 2^13 times more site addresses than IPv4, which is plenty in absolute numbers, but not necessarily enough for more coarse aggregation, and definitely not infinitely future proof.
Crucially though, if we change it, we just have to change how addresses are allocated, not change the protocol again.
> 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.
Every residential router already has PCP (RFC 6887) and UPnP IGD to deal with the NAT44 non-sense that is the status quo, and both protocols support IPv6 hole punching, so IPv6 default deny as a policy is hardly an issue in the residential space.
MiniUPnPd, which many Linux-based CPEs use, has supported IGDv2 (needed for IPv6) since 2012 (as well as PCP).
The point of local networks of a minimum size of 64 bit isn't only to have MAC-based addresses (48 bit would have been enough for that, fwiw), but in general to support non-coordinated/probabilistic self-assignment schemes with negligible collision probability.
Picking a random local address (which is very important for privacy, as you've mentioned) is much easier if you don't have to do an elaborate dance of listen, announce, listen for collisions etc. first (practically that still happens, but collisions are the absolute exception).
> So is the bigger address range better?
Yes, because consider the alternative of re-doing all of this again in a future in which IP usage for some reason jumps by a few orders of magnitude again.
Due to hardware getting better over time, the per-packet cost of a few extra bits is going down all the time, while the cost of rolling out a future IPv7 increases with every new deployed host.
The best thing about SLAAC is that it forces your ISP to give you at least 64 bits. Otherwise you know Comcast would only give out a /128 and charge you for more, so you'd use NAT at home just like 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).
Cloudflare sees over 40%, and it hasn't gone up in the last year even with the overall traffic increase. Personally, as the APNIC article also says about their own observations, I guess the overall adoption is somewhere in between.
https://radar.cloudflare.com/adoption-and-usage#ipv4-vs-ipv6
But we have to remember that this reflects the adoption on the client side. With many high profile services still IPv4-only, the fraction of IPv6 flowing on the public Internet might be much lower.
I wonder what incentives are needed to push this forward, because it's not the same incentives as years ago for sure. We've long since exhausted new IPv4 allocations.
Interesting to see the per-country rates[1]. France is up to 85%, apparently!
[1] https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Anyone know why there is a high frequency signal on top of the long term trend in that graph?
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
People connect through cellphones more on weekends, and cellular has higher IPv6 usage.
The more mobile traffic, the more IPv6. Have a look at India, it is not as if everyone has a fibre connection running IPv6.
Here in Belgium it's the other way around. we've had IPv6 for over 10 years for basically all home internet, but mobile is still ipv4 only. Not sure why since it's all the same companies.
Mobile and fixed broadband is a separate infra/boxes (virtual).
LTE arch with the PGW handles IP allocation to devices
https://mobilepacketcore.com/lte-4g-network-architecture/
Well, France has 99% IPv6 deployment through both mobile and landline these days
https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arc...
(2025, from 2024 data)
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)
You mean that Free's ipv6 is not implemented correctly?
I'd however mention, the two biggest ISPs that remain today both have adopted IPv6 on their fiber connections. They're also heavily using CGNAT for IPv4. It makes sense, the volume at which they're working makes dedicated IPv4 very uneconomical.
Even smaller ISP have done that. But I switched to JioFiber last year and it loses its IPv6 network every week for a few hours. Diagnostics tell me that everything is okay and the customer support just doesn’t understand the problem.
My home internet has IPv6 but my mobile carrier doesn't. IPv6 on mobile carriers is unfortunately still not universal.
I wonder if there will ever come a day when IPv6 will provide a better web experience than IPv4.
At the moment pretty much every website is reachable via IPv4 but a lot not via IPv6. Will there be a day when this turns around?
> a better web experience than IPv4
That's already the case. IPv6 is often faster because most ISPs these days use cgnat for IPv4.
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.
> In my experience not true in practice cause I have experienced way more issues with the IPv6 endpoints of sites than their IPv4 counterparts.
If you've ever visited a website from your smartphone (over 4G/5G), your first hop has in all likelihood been over IPv6. If you have visited a website from your phone that only had an A record then you probably went through a CG-NAT box, which added latency.
If you streamed a Youtube video to your phone, or checked Gmail, or Instagram or Facebook, then it was over IPv6.
People (including probably you) use IPv6 everyday, multiple times, without knowing it.
> 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.
Do you have examples for this? I've never experienced this, and I've been using IPv6 for years.
Also, how can you be sure that the same request to IPv4 would have been fine? Did you actually see consistent failures on v6 and consistent success on v4? Otherwise, if a service has a reasonably low error rate, success on retry is the expected outcome, regardless of the path the retry takes.
There were indeed consistent failures to specific IPv6 endpoints, clearly identifiable through curl, while all the IPv4 endpoints were ok.
This happened with pypi (IPv6 BGP routing problem caused by a bad route from one of our peers combined with their fastly CDN not reply to us on IPv6 from the other side of the ocean for some weird reason), but also with yum and apt mirrors (seemingly random problems with the IPv6 service or firewall of the remote endpoint), and various other web resources accessed from pipelines.
The solution always was to temporarily block the bad IPv6 endpoint(s) or temporarily completely disabling IPv6 on the server itself or on the squid proxy server for workloads without direct connectivity.
Obviously it also can be the other way around, but in practice it appears to happen less often with IPv4, and if it does things get addressed quickly instead of taking hours or days or weeks.
I have been on a dual stack IPv4 and IPv6 connection for a while now. IPv6 is the preferred protocol. I think I'd have noticed if there were widespread IPv6 issues. It used to be worse, but that was years ago.
I have yet to see any ISP use CGNAT here in Sweden. It seems to be a highly regional problem for some reason. Both on mobile and on broadband I get publicly routable IPv4.
That's because Sweden joined the internet relatively early when enough addresses were available. It's like that in most 1st-world countries. Places like Argentina, on the other hand, may have to share 8 IPv4 addresses per city.
That makes sense. However, I also don't get IPv6 on either my broadband or my mobile. So we seem to be far behind there.
True but not deploying any IPv4 connectivity would be a worse experience than not deploying IPv6.
That depends on your isp. Mine certainly doesn’t, and I’ve never had an isp on the U.K. which didn’t give me at least a dynamic ipv4 address to my router.
Infact the only isp I have seen do it is starlink and I have contacts with ISPs in 60 different counties.
Note that most ISPs are cellphone networks and most end devices are cellphones.
That fraction of a millisecond doesn't meaningfully translate into a better experience for users.
You're assuming the ISP has dimensioned their CGNAT properly and it's not congested.
Milliseconds matter for gaming, for example.
Vast majority of people gaming are doing it via wifi
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.
I would expect online video games to be a more important driver.
and anything P2P. Maybe that would have been a driver 20 years ago, but now everything is expected to be centralised. Our culture has shifted. Remember when people used to host their game servers? If you're under 16, you don't because it was never in your lifetime.
it's more like that the IPv6 switchover was so fumbled that we went from fast P2P like with Skype, to shitty, centralized and data-mined Discord.
The internet would be much less centralized if IPv6 happened when it was supposed to.
I have to open a hole in my firewall to host any service. Nat doesn’t change that.
Unless you want to host multiple minecraft servers on the same port on different servers at home?
Indeed hosting anything at home is such a rare workflow that someone wanting it can choose an isp which gives them the facilities they need.
Unless you don’t live in a competitive market based economy and just have the single government mandated isp aimed at the lowest common denominator, in which case you’ve got far worse problems.
Or unless you do live in a competitive market based economy, and have a choice of several ISPs with practically equivalent offering aimed at the lowest common denominator, none of whom supports something niche like "giving you facilities for hosting stuff at home".
If there's one thing market competition does well, is remove any kind of meaningful variety - because supporting a niche offering costs money, and is not worth it unless it nets positive, otherwise it's just a drag that makes you fall behind your competition.
The average person finds port forwarding much more confusing than "allow Minecraft y/n"
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
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.
For people like me: DS Lite stands for "IPv6 dual-stack lite". My mind went directly to Nintendo and I was confused.
Unfortunately, individual actions would never be enough to solve the IPv6 chicken and egg problem. See djb's "IPv6 mess" article:
https://cr.yp.to/djbdns/ipv6mess.html
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.
This stuff is obvious now, but I think back then this was probably quite clever.
It's not a lot but it's better to be part of the solution than the problem even if it is an insignificant contribution.
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.
1) my stateful firewall is going to break most of that anyway
2) if cg nat is as popular as people claim then they won’t be doing that as it’s not an edge case
> 1) my stateful firewall is going to break most of that anyway
Stateful firewalls and even regular NAT aren't much of an issue for P2P, but CGNAT is much more problematic [0].
> 2) if cg nat is as popular as people claim then they won’t be doing that as it’s not an edge case
You'd hope, but people tend to be pretty slow to update their networking assumptions, so this is still pretty common. And it doesn't help that most CGNAT users tend to be either from poorer, since poorer countries and mobile data providers are far more likely to use CGNAT than legacy North American ISPs.
[0]: https://tailscale.com/blog/how-nat-traversal-works
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.
> While true, neither of those are relevant in context (and I even explicitly acknowledged your first bullet in my comment above).
Yeah, I just mentioned that because P2P networking is used a lot more than most people think these days, since even things like Zoom that look like typical client–server web browsing actually use P2P networking internally.
> 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.
Reliability and latency will be marginally better with IPv6 than with CGNAT, but this is so minor that I doubt that most people will notice this. And many CGNATs will RST connections that last too long, but most protocols have some sort of automatic retry/reconnect built in, so this shouldn't cause issues very often either.
IPv6 addresses are quite a bit cheaper than IPv4 addresses in most clouds, but since most servers still need to support IPv4, this doesn't help you directly. Supporting IPv6 means that others using the cheaper IPv6-only cloud services will be able to connect to your server, but this doesn't matter for consumer-only services.
So yeah, you're probably right that enabling IPv6 server-side won't have (m)any benefits.
> 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.
Being able to ban IP addresses without worrying about collateral damage is a pretty big benefit to the service provider though, for certain applications at least.
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)
So your isp is rinsing you for the cost of a an IPv4 address. £10 a month will pay for a whole /24 in 3 years.
Chances are they also skimping on other areas including over subscription. Choose a better isp if you want a better service.
Your “just open traffic to internal host 1 on your firewall is the same no matter if it has nat or not, unless you are using a non stateful firewall? Or perhaps your configuration layer splits the two for reasons.
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
> Is IPv6 really that widely used?
Mobile carriers use it almost exclusively, which is already a huge chunk of the internet, and newer ISPs are switching to it too.
> I'm supporting both because I heard it's good to support both, but I'm not sure what the actual benefit is.
The benefit is that you allow IPv4-only and IPv6-only clients to connect.
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.
You can do IPv6 only if you have a 64 nat on your edge and use dns64 and just use a limited set of applications and devices.
Some applications will still fail to work though unless you also have 46 nat on your device which still doesn’t work transparently on majority of types of device.
You also need all devices on your lan to support v6 natively, and v6 only. From your printer to your speaker.
You might be able to do something with mdns and nat64 to get them working on an IPv4 only subnet. But you’re talking layers and layers of complexity for things which just have to work.
I’m posting this from my phone on my IPv6 only subnet, not sure if it’s using a 64 gateway or 6 native to HN, but it’s possible.
So, like, the three most popular things still worked. I wonder if working more is related to their popularity.
All the more reason to support it. There are lots of ISPs that only assign you an IPv6, and do hacky trickery to make IPv4 work over that. We wouldn’t need all of this.
How does IPV6 affect ip blocking. As a VPN user I wish it wasn't used as a metric for sites shaking you down.
It's just as easy or hard to map out a VPN's egress subnets on v6 than it is on v4.
I assume for aggressive blocking the only prefix size will change. What is a /32 for IPv4 might become a /64 or smaller for IPv6.
Larger. A /56 and get multiple hits from nearby /56s and you block the /48.
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.
> I’ve always found IPv6 to be overengineered and in many ways completely ridiculous.
Most software continues to have horrible IPv6 support and documentation making it look more complicated, but the actual protocol is considerably simpler than IPv4. For example:
1. An IPv4 packet header is variable-length, and the checksum must be recalculated by every router because the TTL is included in the checksum. Whereas an IPv6 packet header is fixed-length and has no checksum.
2. NAT is effectively required with IPv4, but it makes everything much more complicated, since it means that most computers don't even know their "real" IP address, it makes peer-to-peer networking very challenging, and it's tricky for routers to implement. Whereas with IPv6, no NAT is required.
3. Any router along the network path is allowed to fragment an IPv4 packet, and is in fact required to if its MTU is smaller than the packet's size. Whereas only the originating node is allowed to fragment an IPv6 packet.
4. To acquire an IPv4 address, both clients and routers must implement DHCP, which is a fairly complicated protocol, and both clients and routers must remember the list of assigned addresses. Whereas with IPv6, the client can just choose a random address (via SLAAC) and then start using it immediately.
5. IPv6 multicast is considerably simpler than IPv4 multicast, and NDP (v6) is considerably simpler than ARP (v4).
Despite all this, I agree with you that setting up IPv6 networking is harder than setting up IPv4 networking, but this is more of a software problem than a protocol problem.
2 is a security nightmare but that’s why firewalls prevent it by default
3 well you can set the dont fragment bit at a client side or a router can drop the packet. These are choices. If a 1500 byte IPv6 packet arrives on a router with an 1100 byte next hop, does it just drop? Or send back a fragmentation needed icmp? How is that different from setting a “don’t fragment” option on a router.
4 isn’t created from a security or management point of view either. And v4 has the 169.254 range for this purpose. I guess the lack of router advertisement is the primary difference. And the operational expectations.
5a I’m not sure about. My main experience with multicast is pim-sm on v4. SSM v4 multicast however seems simple, and while I don’t use it as I have kit that’s too old for it is v6 really easier than v4/ssm/igmp3?
As for arp, I don’t see any real complexity with it as a network operator, but maybe that’s because I’m used to it. Perhaps it’s easier to implement nd rather than arp, but given almost every v6 deployment for the last 30 years is dual stack all it does is increase complexity.
The only one I don't understand is how NDP is simpler than ARP. ARP is an Ethernet broadcast while NDP is built on IPv6 multicast which creates a recursive chicken and egg situation.
> The only one I don't understand is how NDP is simpler than ARP. ARP is an Ethernet broadcast while NDP is built on IPv6 multicast
ARP is a special protocol implemented on the data link layer, while NDP is just another type of ICMPv6 packet.
> which creates a recursive chicken and egg situation
I believe that NDP mostly uses the special ff02::/16 link-local multicast addresses [0], which don't require any configuration to use.
[0]: https://www.iana.org/assignments/ipv6-multicast-addresses/ip...
I'm interested, apart from the chicken egg problem, what are things that you found 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, ...).
> apart from the chicken egg problem
"But other than that, Ms. Lincoln, how was the play?"
I am more interested in the technical perspective than the deployment perspective.
Did you call your ISP and ask? Some of them support it but won't enable it by default.
In America I've never had a non-mobile ISP offer IPv6. At this point it would be best to recognize the sunk cost and give up on the migration. IPv6 will never reach the 100% needed to turn off IPv4.
> IPv6 will never reach the 100% needed to turn off IPv4.
As was predicted in 1994:
* https://datatracker.ietf.org/doc/html/rfc1726#section-5.5Thugs are slowly moving. Another 5 years and most windows machines will support clat. Another 20 and most machines will hopefully support it. I wish it was embedded in the Linux kernel though as that increases the chance of your device working transparently on an IPv6 only subnet using slaac and the application creator doesn’t need to know anything other than their internal dhcp gets a 10.x address and everything works using 464.
I think the future is bright and most problems will be solved by 2040, and almost all by 2050.
And I've only ever had v6, both on DOCSIS and fiber. Both observations are pretty useless in the grand scheme of things; actual adoption rates are what matter.
> At this point it would be best to recognize the sunk cost and give up on the migration.
That's a pretty wild thing to say in the comment section of an article about v6 reaching 50% eyeballs-side deployment.
After 30 years, with 99% of servers and devices having been designed decades after ip6 was created, half of traffic is still ip4.
If that’s not a failure I hate to see what is.
> If that’s not a failure I hate to see what is.
How would several billion smartphones be able to connect to the Internet without IPv6?
And 32% is all llm/bots using AWS and other "pay for ipv4 IP" use cases.
As someone on the fighting end of scrapers, this is absolutely not true. If anything I should bais towards v6 as the traffic is on par better than v4
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.
Every scraper I have blocked seemed to use IPv4 primarily. Only when IPv4 gets blocked, some of them fall back to IPv6. Others just stay dead.
With AI companies using botnets ("residential proxies") for scraping, they're probably going to be in the 50% that doesn't use IPv6.
Citation needed. These numbers are quite consistent with the growth pattern that started well before usable LLMs were even a thing.
2026. Literally no reason to be using this outdated limited addressing.
New regex: IP(any collection of numbers and dots).
Now we have infinite IP address possibilities and no one controls the space.
Done.
Do you think routers perform their work using the human-readable addresses?
If so, that is incorrect. They use the binary values. The actual difference between IPv4 and IPv6 is that IPv6 uses 128-bit addresses, not 32. So you can devise whatever human-readable abstraction you like, it won't change how networking actually operates.
And there’s no reason we should be limited to 128. It’s all just so dated and stagnant.
Chips can be made that dwarf that limitation, instead we’re stuck with this decade old nonsense to “work around” again.
Flip flopping between “the code needs it” and “the chips need it”.
What does a packet header look like?
Took them long enough. Now if only Google would follow with their own services.
Sure Gmail has ipv6 enabled and routable ip6 MX. but sending to those addresses is often rejected and forced to retry over ipv4.
Don’t get me started on gh
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.
Actually no software rewrite is needed because the Berkeley Sockets API is agnostic to address format. If your software requires a particular address format, that's a bug. if you pass an IPv6 literal to getaddrinfo, you get a result with an IPv6 address structure and it tells you the IPv6 socket type you need to connect to it.
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.
I never heard this idea before, but more octets would be a lot prettier!!
Are you just talking about how you write the addresses or are you talking about the actual protocol?
The IPv4 protocol has 4 octets each for source and destination address. Period. If you change that, your packets won't work on any IPv4 routers or software any more.
If you want to write IPv6 addresses as numbers separated by dots no one's stopping you but I don't see how it's better. They switched to hex because the old format was too long.
They added 12 more octets. I mean we could have written IPv6 addresses in the old format but I don't think that
42.0.20.80.64.1.192.15.0.0.0.0.0.0.0.113
is easier to remember than
2a00:1450:4001:c0f::71 (or 2a00:1450:4001:0c0f:0000:0000:0000:0071)
Tell that via phone to your grandmother.
Why would I do that?
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.
Your hardware can do Natural Address Translation. More octets is basically taking this idea further, to make a "big NAT".
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.
Something is very wrong with your network then. I never needed to disable IPv6. Maybe you should question it.
It is harder to maintain two networks instead of one. Potential problems double. Hacks like RFC8305 "Happy Eyeballs" become a must.
Fair enough. I do question it often.
It's a standard Asus router but it's given me a lot of ire. I hate to say it but it's never a problem when I install windows on the same machines
(I'm currently in the process of trying to completely remove windows from my life)
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.
Skill issue.
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.
Conversely it means people who have ISPs that do IPv6 just have IPv6 and don't need to turn it off. Because it just works. The other day my IPv4 was down and I didn't even notice.
> SELinux's UX was significantly improved many years later
in what way?
Most of what people see as "SELinux" is actually the default policy, which started out as way too strict. Then SELinux-enabled distros such as Red Hat moved to a policy that only applies to system services, and leaves user-launched binaries as if SELinux was disabled.
And even for system services, you can disable SELinux for one service (permissive mode) and leave it enabled for the rest.
This has been the case for more than 10 years, but the damage was done. It's now very hard for users even considering learning the basics (which are not hard).