* 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...
1. Sites that help shoppers choose can add a big visual red flag to any ISP that doesn’t support IPv6. Consumers don’t know what IPv6 is by and large but they do understand seeing a big red flag.
2. Same thing for websites. Add a banner that says “hey your ISP doesn’t support proper internet connectivity which this site utilizes. Contact them to let them know that you are having internet issues.” Again, consumers do not know what’s IPv6 is, but they do know what annoying banners are.
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.
>Individual economies such as India, Viet Nam, and Saudi Arabia exhibit adoption curves that differ markedly from the global average. As the APNIC Labs data shows, this global trend does not necessarily reflect the experience of individual economies.
>APNIC’s own measurement records a 42% worldwide IPv6 capability (Figure 2). That’s a substantial difference, which also needs clarifying."
The nuance is that IPv6 is growing faster in developing countries with poorer economies. I'm guessing this is because building modern IPv6 network from scratch is cheaper & more efficient than acquiring scarce and expensive IPv4 addresses. This is a major advantage for newer providers in growing economies.
So while the Google is showing it at 50%, APNIC's weighted global measurement shows it at 42%.
HE shows 41% ASNs support v6: https://ipv6.he.net/
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
Think about the migration plan, and nearly every positive force to move to ipv6 has been exhausted. Routing hardware, consumer hardware, server hardware & software all have the capability. Mobile deployments were a big driver of ipv6, and that didn’t reach the level of adoption expected. Now hosting providers are charging for ipv4 addresses, and it’s not having a measurable impact.
Most migrations start to hit the hockey stick well before this stage, and the taper occurs around 95%+ when outlier hardware or legacy devices are the last remnants. We are not seeing a pattern like that here.
We knew bot traffic is more than half of the internet, right?
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.
I've never seen this chart before, was taking a peek from the link in the article. Does anyone with networking knowledge know why IPv6 usage peaks on Saturdays and dips during the middle of the week? (something related to mobile ISPs?)
It's Optimum Communications and Frontier (my provider) that are really holding the numbers down at ~15% each. The latter is improving very slowly, but not a lot of evidence of change in the former.
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.
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?
Ubiquity gateways also seem to not support it sadly. It would be awesome if they supported something like Hurricane Electric’s tunneling.
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.
But simply it is impossible to go full ipv6, as many of isps of the clients do not support it.
Currently there is no pressure to the isps to move to ipv6. In fact the incentives are OPPOSITE! They love charging for static IPs.
[1] https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
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.
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.
I wish they had just made an IPv5 though. With e.g. 6 bytes instead of 4. 65535 times the current internet should be plenty. I feel like IPv6 is overengineered and I'm glad it didn't take off yet. I like being able to memorise IP addresses, it really helps testing.
If I ever do switch it on on my home network I'll probably use NAT on the router so I can still keep it exclusively IPv4 internally on the network.
I first learned about IPv6 when I was studying (1993) and I already felt like it was an overengineered monstrosity back then. They were campaigning like it would be the internet next year. Well that aged well, lol. That's now 33 years ago.
I truly think that if they had made it simpler and more IPv4 compatible we would have been moved over in 2-3 years. But no they had to keep supporting this thing. Well, at this point I'm going to avoid playing ball as long as I can.
New regex: IP(any collection of numbers and dots).
Now we have infinite IP address possibilities and no one controls the space.
Done.
(It’s true that you can use cellular for your home internet, but I consider that extremely compromised.)
That plus other ISPs v6 implementations breaking things randomly, I understand why they don't bother.
Their core network has IPv6, but not their customers, 17% market share in telecom in the Netherlands.
Are there more?
I don't think I bothered asking them again!!
(Edit "them" = Virgin Media)
The great news is those vulnerability scans from random IPs are coming just on ipv4, there hasn't been any yet on ipv6 :)
This is one of those “if everyone just” solutions that doesn’t work because shopping websites would never do that. Amazon has tons of evidence that even the slightest bits of friction result in noticeable drops in sales.
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.
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.
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)
> 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.
That was probably a reasonable take 15 years ago. But we're at 50% v6 globally, and the ISPs that are doing v6 + cgnat would not want to move all that v6 traffic to cgnat. v6 traffic is managed with stateless routing; cgnat is stateful and costly.
There are many lessons that can be learned, but v4 only is not the future. v6 only might never happen... people are going to keep running old software in emulation that will never support v6... But global routability of v4 will likely end one day. And I'd suspect the tail of the migration will be much shorter than the head was.
I think the future is bright and most problems will be solved by 2040, and almost all by 2050.
The problems, as I observe, are more in network infrastructure, routing, etc.
In what metrics? IPv6 is more simple to implement than IPv4. In Linux 7.1.1 IPv4 is 84kLOC, IPv6 is 59kLOC.
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.
* https://datatracker.ietf.org/doc/html/rfc1726#section-5.5> 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.
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, ...).
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.
In every fucking IPv6 thread this "just add more addresses" idea comes up. There is no "just" in expanding the address space:
"""
Whether you expand the address size to 33, 64 or 128 bits, all IPv4 implementations will discard the packets. So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately:
1. You have to change the version number.
2. You have to add new code to handle the new version.
Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So,
3. You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol.
Two minutes of thought show that this third requirement has only two solutions:
(3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses between the old and new protocols.
This has been known for more than 30 years [RFC1671], although people still sometimes try to deny it.
"""
* https://github.com/becarpenter/book6/blob/main/01.%20Introdu...
Any IPv4+ idea that "just" adds more address bits will same issues we've faced with IPv6.
And as for memorization: do you actually memorize MAC addresses for your interfaces? The answer is no, you don't, becase ARP handles all that for you. Well, for IPv6, DNS, mDNS and so on handles all that for both your IPv4 and your IPv6 addresses - or should, if you know what you are doing, as memorizing IPs doesn't really scale beyond a few dozen machines.
Yes, IPv6 is overengineered, but it gets the pain of having larger addresses in the packet done once and for all - the odds of needing more than 128 bits in the rest of human history are very small indeed. And if something radically new needs to replace the current IPv6 architecture, which is much more likely, the extra address bits are already there; only 2000::/3 is assigned for public use so far, and the new addresses would fit in the current IPv6 packet format already.
This is even easier with IPv6. At work we have a bunch of test devices, and you calculate the IPv6 from the device's serial number. Simple as that, no memorization at all.
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.
More on this: https://vincent.bernat.ch/en/blog/2024-why-ipv6
$ curl -v https://news.ycombinator.com
* Host news.ycombinator.com:443 was resolved.
* IPv6: 2606:7100:1:67::26
* IPv4: 209.216.230.207
* Trying [2606:7100:1:67::26]:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
Works fine through a Ubiquiti gateway here.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.
While T-Mobile US has been IPv6-only since ~2018:
We need to pretend we overengineer. But some in the committee made it sure data exfil would be basically impossible to detect / block with IPv6, which all the others, always in love with the most rube-goldberg design possibles, loved the "overengineered" solution.
With rube-goldberg designs, you can then always say stuff like:
"The xz backdoor was TOTALLY unrelated to systemd"
Yet it only concerned distro that shipped with systemd.
Go figure.
It's always "because insert-crazy-non-sensical-hair-pulling-reason-here".
Ah yes, it's because of that. So it's so totally unrelated right?
Except it still only affect distro using systemd.
Or maybe, you know, backdoors and exfils were the plan from the very start.
"The protocol won't work correctly unless you let crazy ping packets doing you-know-what". And nobody is ever going to properly firewall all that.
Overengineering is one thing, yes.
But we know for a fact that there are xxxINTs infiltrating committees and pushing "solutions" that are only solutions to them.
Good example of the 2020s on why there is practically truly only one Internet instead of many.
This graph even shows them doing step deployments:
https://radar.cloudflare.com/adoption-and-usage/as2860?dateR...
I selfhost web and email over my Wireguard VPN using a free VPS (at OCI but I did it with AWS Lightsail too, though it wasn't free but cheap). This can work for you too or you can use easier to configure solutions like Tailscale. This way, your home isn't exposed directly to the Internet.
As far as IPv6, both provide it, but after running with IPv6 on AT&T for about a year, I disabled it because whenever I had a rare random connection issue, I never knew whether IPv6 was the culprit and it was one less variable to debug.
With AI companies using botnets ("residential proxies") for scraping, they're probably going to be in the 50% that doesn't use IPv6.
This has taken pressure off the IPv4 legacy address pool, reducing the urgency for older providers.
End-users are typically completely unaware of whether their traffic is being carried over IPv6 or IPv4, and so simply do not care one way or the other. (This particular post is more than likely being made over IPv6, since news.ycombinator.com has an IPv6 address and my OS, browser, router and ISP all support IPv6 straight out of the box, as is now true for the majority of users in my country.)
PS: From the millions of customers' details leaked it sounds like their market share is a hell of a lot higher than 17%!
I only found out because I could no longer access a swath of things I used to be able to.
not virgin media, but in the EU
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.
That's already the case. IPv6 is often faster because most ISPs these days use cgnat for IPv4.
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.
Put all work into reorg, for what? Some numbers to change? Why when IPv4 works?
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.
Had the original plan been simply "extend address space" instead of "extend address space and while we are at it revamp and rewrite every part of the whole scheme including assignment, discovery, and everything else we see wrong with ipv4"; we would be in a much better place.
Adding extra address bytes would of course require new changes across the internet, but that change would be easier to swallow compared to having to rip and replace large swaths of processes to make ipv6 work because of all of the other changes that came with ipv6.
Also, the stupid idea of turning addresses to hex as the default, and more specifically the dumb :: shortening methods really made it confusing for everyone and didnt help at all in the efforts.
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.
Prior to that programs used gethostbyname() etc, which only works with ipv4.
DNS and mDNS don't "just work". You don't need but probably really want HA for DNS which is overkill for a homelab user, and you really want a fixed address for that DNS, because who wants to fix issues when you can't even address your services, and you really want your routers to have fixed addresses for the same reasons; you need VLAN and/or Avahi reflecting for mDNS, and if you need firewalling on your LAN, have fun dealing with the fact that mDNS clients prefer GUAs, then IPv4s, then ULAs in that order, by RFC rule, and managing GUAs sensibly when your ISP keeps changing your prefix -- well, IPv6 is almost 30 years old and home/SMB equipment still can't handle that reliably or flexibly, if it even lets you do anything besides assign /64s, and there's nothing stopping your ISP from saying "here just have a single /64, sorry if you wanted to actually use IPv6 for anything clever like having multiple subnets, who would ever want that?" So you say "I'll just use DHCPv6" and it turns out that DHCPv6 kind of sucks and it also turns out many devices don't support that by default or at all, including every single Android and Chrome device, for starters.
IPv6 is full of these design issues where you have a lot of things that are supposed to Just Work, Look It's So Much Simpler Than IPv4, and look at all these address bytes (excuse us while we take 64 of them away for no reason), except you discover that nothing Just Works with anything else in mildly nontrivial cases. You end up on a yak shave only to discover no yak underneath, and you end up just having a broken network while standing in a pile of yak hair. The whole story above is just one example. IPv6 is a migraine in RFC form, and if it weren't that I accidentally bought some expensive IOT devices that are IPv6-only, I'd be happy to never touch it. At this point, it would have been a better time-money tradeoff to have thrown those in the trash as soon as I had seen the problem.
If that’s not a failure I hate to see what is.
"But other than that, Ms. Lincoln, how was the play?"
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.
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)
Like I own 8.8.8.8. You want to add more bits, fine, I'm 8.8.8.8.0.0.0.0 now. If anyone switches to the new thing, they know where to find me.
And the problem seems to be solving itself as the world is turning its back on globalism. China and North Korea already have separated themselves. Iran too. China still uses the same address space but it's not like there's open connectivity with the rest of the world. We'll probably cut off Russia at some point completely as part of some sanction (they've been preparing for that for years), and Europe will break with America if things continue. We'll just have interoperability at a few controlled border points then, like China already does with its great firewall. It'll be easy to do some address translation then.
Ps that's not something I'm necessarily happy about but I do see this trend emerging of every region trying to wall itself off.
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)
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.
IPv6 traffic crosses the 50% mark - https://news.ycombinator.com/item?id=47777894 - April 2026 (621 comments)
---
Other recent threads, if anyone would like a thousand more IPv6 comments:
The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=47821429 - April 2026 (166 comments)
IPv6 is the only way forward - https://news.ycombinator.com/item?id=47680124 - April 2026 (339 comments)
IPv6 Adoption in 2026 - https://news.ycombinator.com/item?id=47083086 - Feb 2026 (21 comments)
IPv6 is not insecure because it lacks a NAT - https://news.ycombinator.com/item?id=46696303 - Jan 2026 (577 comments)
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.
Users doing speed tests in CGNAT may be seeing numbers that aren't exactly real for a (still) mostly IPv4 Internet.
Most people can pick up calculating subnets in their head in ipv4 pretty quickly and ipv4 addresses are easy to memorize on accident. My brain turns to mush as soon as I start seeing hexadecimal characters in addresses.
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.
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
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.
Infact the only isp I have seen do it is starlink and I have contacts with ISPs in 60 different counties.
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.
Is there a law mandating this?
Also IPv6 addresses are ugly
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.
But the way that they dealt with the whole thing smelt very "we don't know what we're talking about", enough to put us off.
And shifting all the IP space about would have had costs with very little return, so little business appetite to go through it.
Yup [0].
> How is that different from setting a “don’t fragment” option on a router.
It's the exact same, of course with the difference that it's the default and that nothing needs to support packets with the “don’t fragment” option disabled (since it's mandatory).
> And v4 has the 169.254 range for this purpose.
Sure, but seeing 169.254.x.x usually means that something is broken, while seeing IPv6 link-local address is perfectly normal.
> 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.
Well it's part of the reason why 802.11 tries so hard to pretend that it's Ethernet, and I've seen ARP storms a few times but never any NDP storms.
> but given almost every v6 deployment for the last 30 years is dual stack all it does is increase complexity.
Yeah, IPv6 is great, but dual-stack is fairly annoying, and given that IPv4 is the older protocol and still essentially mandatory, I definitely get why people dislike IPv6 (even when it's really IPv4 that's the problem).
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...
IIRC, a workaround was to prevent Linux from setting this field, or force-reset it on every outbound packet using netfilter.
and
> 7. give every device its own public IP by default.
Both of these are optional. Don’t want them? Don’t use them - if you don’t configure them, it won’t happen.
> 6. make routers accept inbound connections by default
That’s not a new feature with v6.
> Like I own 8.8.8.8. You want to add more bits, fine, I'm 8.8.8.8.0.0.0.0 now. If anyone switches to the new thing, they know where to find me.
Now you (and everything in between) have to be able to handle packets addressed to 8.8.8.8 and 8.8.8.8.0.0.0.0, so you’ve done point 4 without knowing it.
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”.
It was averted: how do you think we got several billion smartphones connected to the Internet? Do you think that would have been practicable without IPv6?
Comcast—not even mobile—had to move to IPv6 on their landline ISP business because they ran out of IPv4 addresses for TR-069: they were using multiple 10/8 networks in different regions NATed to hide them from each other. IPv4 became untenable.
How would several billion smartphones be able to connect to the Internet without IPv6?
There isn't enough RFC 1918 (or 100.64.0.0/10) space for IPv4-only to be practical: Comcast—not even mobile—went to IPv6 because running their TR-069 management over multiple 10/8 became untenable.
IPv6 is making all sorts of things possible without most people realizing it.
It's usually bad configuration done by the router vendors. It doesn't mean IPv6 is bad.
People also thought that 4 byte wide IPv4 Adresses would be large enough. It's really hard to estimate how much you will need. And because numbers are effectively a free resource, it is better to overestimate.
IPv6 also gives you shortcuts to write addresses. You can abbreviate the longest run of zeroes with `::` and leading zeroes within a hextet can be omitted. This makes IPv6 address notation elastic.
Or if you're feeling playful, <prefix>::b0d, <prefix>::bed, <prefix>::dad, <prefix>::b1d...
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).
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).

You may have seen headlines noting that Google’s measurements have shown IPv6 reaching 50% for the first time. These measurements are based on Google’s continuous monitoring of the availability of IPv6 connectivity among its users, and reflect the proportion of users who access Google services over IPv6. Reaching the 50% mark is a significant milestone, demonstrating that IPv6 is a mature, fully capable protocol that is being deployed at a global scale and used effectively in real-world networks.
Figure 1 — Google’s global IPv6 adoption graph, as at 23 April 2026. Source.
The global uptake of IPv6 follows a complex and varied path that isn’t apparent in a single, aggregated trend line. Google does not publish per‑region IPv6 statistics, and its per‑economy data is limited to overall totals, so these nuances are hard to see in Google’s figures alone. To understand how adoption really unfolds, it’s more instructive to look at the APNIC Labs data. Individual economies such as India, Viet Nam, and Saudi Arabia exhibit adoption curves that differ markedly from the global average. As the APNIC Labs data shows, this global trend does not necessarily reflect the experience of individual economies.
APNIC’s own measurement records a 42% worldwide IPv6 capability (Figure 2). That’s a substantial difference, which also needs clarifying.
Figure 2 — APNIC Labs’ global IPv6 capability measurement, as at 23 April 2026. Source.
APNIC’s measurement program is run by APNIC Labs and uses online advertising distributed through Google Ads, which appear in end users’ web browsers, games, and apps wherever Google advertisements are placed. APNIC does not select specific users and seeks the broadest possible exposure in every economy, 24/7. Normal advertising tracking systems are used with APNIC Labs logic, which ensures a unique set of tests are run, measuring IP, BGP routing and DNS, amongst other technology choices. No end-user Personally Identifiable Information (PII) data is held, and raw measurements are never shared, only collations at the ISP, economy and region level.
This work is carried out with the assistance of Google Research, ICANN, and others who help fund and support the activity. Given this close involvement, it’s natural to ask why APNIC’s measurement results don’t always align with Google’s own published statistics. If Google is used to conduct the research, how can the results differ?
APNIC’s measurement approach applies statistical weighting to the collected data and uses external sources, such as World Bank statistics, to model Internet usage by economy. This is necessary because the number of measurement samples APNIC Labs receives each day is not uniform. Advertising placements are optimized by Google to maximize delivery and revenue, which means that, on any given day, more advertisements, and therefore more measurement samples, may be shown in certain economies than others. For example, if advertising demand is higher in North African economies such as Egypt or Tunisia on a particular day, more measurements will be collected there, while fewer may be gathered from South America or Asia.
As a result, the raw sample counts cannot simply be aggregated to calculate global IPv6 capability. Instead, APNIC Labs aggregates the measured IPv6 capability for each economy and then weights it according to that economy’s estimated Internet user population.
In practice, this means that large Internet populations, such as those in India, China, Indonesia, and other major economies, contribute proportionally more to the global result than smaller economies, even if the raw sample volumes on a given day might suggest otherwise. This weighting ensures that the final measurements reflect global Internet usage more accurately, rather than daily advertising distribution patterns.
At the level of individual economies, APNIC Labs’ measurements generally align with the totals published by Google and with data from Cloudflare, Akamai, Cisco, and others. This suggests that the underlying measurements are comparable and that the larger differences observed at the global level are likely due to differences between APNIC’s weighting model. This may be why we see the large variances between the two measurements.
In practice, APNIC’s measurements tend to be lower than Google’s. As a result, it’s useful to view the two data sets together, as they effectively bracket the likely range of actual IPv6 capability at any given point in time.
Some point to the long path toward a 50% adoption milestone as evidence of a systemic failure in IPv6. Nothing could be further from the truth. Deploying IPv6 has required substantial technical effort and significant capital investment. It’s therefore entirely expected that progress has varied across regions and economies, as individual ISPs and economies make their own decisions about how best to balance network growth, user expectations, and the practical realities of operating Internet infrastructure.
The global Internet is not a ‘command economy‘, it evolves through collaboration and cooperation within market-driven conditions. Many providers made substantial capital investments in IPv4 in earlier periods and have naturally sought to maximize the return on those investments. In doing so, they built sustainable and commercially viable IPv4-based networks within their existing footprints.
By contrast, for newer market entrants, it has often been more rational to adopt IPv6 as the primary protocol, as it can demonstrably reduce the total cost of ownership. This pattern is particularly evident in the mobile sector, most notably in large-scale IPv6 deployments such as Reliance Jio’s network in India.
Yes, but it could be simpler.
Certainly, it would be easier logistically to run a global internet under a single protocol. However, that is not the environment we have ended up with. Instead, the Internet today operates across a mix of direct IPv4 connectivity, IPv4 mediated through Network Address Translation (NAT), either in home networks or at the carrier level via Carrier‑Grade NAT (CGNAT), and IPv6.
Managing address translation through NAT is not materially less complex than alternatives such as protocol translation, IPv4 encapsulation over IPv6, or other transition and proxy mechanisms. As a result, claims that ‘IPv4 is working fine’ often overlook the underlying reality: Modern IPv4 networks already rely on layers of operational complexity, and there is no inherently lower‑cost or simpler approach available within IPv4 alone.
From the outset, it was understood that the lack of direct interoperability between IPv4 and IPv6 would be a challenge that needed to be addressed. Early efforts explored the idea of protocols that could subsume IPv4 unchanged and enable direct connectivity across both worlds, but these approaches did not prove viable.
Instead, interoperability has emerged at higher layers, with transport protocols such as TCP, UDP, and QUIC operating independently of the underlying IP version. This model necessarily relies on some form of intermediary. This is visible in the way large content and caching providers, such as Cloudflare, are able to offer dual‑stack services regardless of whether the backend systems themselves support both protocols.
The absence of native dual‑stack capability at some services, for example, certain Git platforms or national television broadcasters, is often perceived as a major barrier to IPv6 progress. However, this may reflect pragmatic constraints, such as operational complexity, or, in the case of national broadcasters, legal and regulatory requirements around data access and geolocation, rather than resistance.
Whatever one’s view on the decision to introduce a second addressing and protocol model beneath today’s Internet services, the reality is clear: IPv6 is now deployed on a global scale. Around half of the Internet users visible to Google already reach its services over IPv6. IPv6 is used every day, every hour, across developed and developing economies alike, on fixed and mobile networks, on small personal devices, and within vast data‑centre‑backed services. It is no longer experimental or marginal; it is part of the Internet’s day‑to‑day operation.
That achievement reflects the collective effort of those working to build, operate, and grow the Internet worldwide, and it is something worth recognizing and taking pride in.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
The internet would be much less centralized if IPv6 happened when it was supposed to.
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:
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.
Using NAT as a firewall might work but it brings it's own problems. I find the IPv6 way better.
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.
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...
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)
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.
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.
2) if cg nat is as popular as people claim then they won’t be doing that as it’s not an edge case
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.
I forgot one detail: your ISP could pay a different tier-1 ISP, as they all interconnect. Nonetheless, your ISP pays top rates for that traffic - tier-1 routes are usually last-resort routes.
you can send a packet from an extended address host to a vanilla v4 host if you map the address space into a range like you suggest..but that v4 host just has no way of sending a message back..so its kinda useless
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.
All my packets go through Seattle, using a Seattle tunnel server adds negligble latency.
But as someone else said, being connected with an he.net tunnel gets you marked as undesirable traffic these days, so that's annoying.
It also just reduces resource waste (of labor time). Countries like China that have insufficient IPv4 addresses and political power have mandated it. One IP per home is manageable, for now, but CGNAT is really bad.
Only because of NAT. Those cellular CGNATs are v6 on the inside but v4 on the outside (well also v6 but customers need the v4 more).
But it's not free, after all every packet carries this burden. I know about the annotation but it also makes it very difficult to parse.
Every client, server, and router, every device that uses the address needs to understand where it comes from and where it's going. That means all the software needs to understand the protocol. So instead of having incompatible implementations live within the same protocol and make a lot of chaos it's better to have a new separate protocol that can be implemented gradually. Now the distinction is between having or not having IPv6 connectivity and my package on IPv4 goes no where because it hit a router that doesn't understand the extension.
IPv6 not being supported in many places means the internet is more centralised, less likely to use proper p2p tech- because it's a lot harder to make it work rather than throwing up a TURN box and relaying everything.
"The latency? Who cares? IPv6 sometimes breaks right now" - because nobody is testing it, so why should people be the first to support it? There's no easy upside.
The only real upside for businesses is not having to pay for increasingly expensive IPv4 allocations. But they don't really care, its not nearly expensive enough yet. Customers will get GCNAT, businesses will continue as normal.
All that will happen is that the internet gets slower and less equal.
Which is exactly the same thing that's happening with inefficient memory hungry software: people either have to buy a more expensive laptop or they have a shitty experience.. Nobody is advocating for them, they just feel things getting shittier year on year and many are just choosing to avoid technology instead.
If I'm with a small-time ISP that has to use CG-NAT because they don't have the cash to buy/lease enough IPv4 addresses to give one to each CPE WAN interface, then using things like Xbox/PS multiplayer/P2P gaming is no longer possible. Want to host a Minecraft server? Too bad.
Are those two use-cases "useful to the consumer"?
The reason to regulate in maybe 2000 or so was that staying with IPv4 led to NAT. NAT led to it being impossible for users to receive incoming connections. Inability to receive incoming connections led to (a) horrendous protocol complexity, (b) probably some applications never even being invented, and, (c) everybody using ultra-centralized services. Ultra-centralized services led to advertising-driven distortions of service utility, concentration of political and economic power, and choke points. Choke points led to surveillance state bullshit that's just fully ripening today.
And, yes, this was (in broad outline) foreseeable in 2000. I wasn't the only one.
Put another way, we can drop v6 completely and the Internet will still work. Obviously wouldn't work the other way around.
As for telco addressing handsets, they could use any addressing scheme to be honest. When people talk about averting address exhaustion, they're not talking about internal addressing of networks, different problem altogether.
When I'm at a different location, the biggest problem is usually figuring out if they use 192.168.0 or 192.168.1 :)
LTE arch with the PGW handles IP allocation to devices
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.
Also there are cases where the ISP didn't bother even optimizing their routing in v6. I understand that some ISPs in Asia (and especially in Japan, where it shows up on ordinary customers in terms like MAP-E and VNEs) have separate backplanes for v4 and v6 (some are legacy reasons, some are business reasons). Guess which one is being devoted more in practice (hint: not the one being devoted more by IETF).
Edit: I thought this was just in Asia, but apparently this is also the case in an ISP in UK (https://news.ycombinator.com/item?id=48618403)
Glad to hear that you don't have a problem with your router, but how does that relate to GPs problems with theirs?
Crucially though, if we change it, we just have to change how addresses are allocated, not change the protocol again.
Mine all have link-local addresses (I do have a real static IPv6 address block from my ISP, at great expense…) - so I’m not sure what I did wrong in my Ubiquiti gear.
Your CPE is probably running UPnP IGD and/or PCP for hole punching of P2P services, and IGD/PCP can hole punch just as easily for IPv6.
> 2) if cg nat is as popular as people claim then they won’t be doing that as it’s not an edge case
It's not whether CG-NAT is an edge case or not, it's whether there are things that are completely impossible with it or not. Want to play with your friends on your Xbox/PS? Too bad, CG-NAT makes it completely impossible.
Why should we be happy with a technology that makes certain use cases impossible? On what planet is that a good thing?
I prefer to run scrapers behind CGNAT because websites can't ban it without causing collateral damage, which matters more to some than to others. The website probably has to put up a captcha. Which hurts its human traffic. Think about how much more traffic you could have if you didn't show everyone a captcha, and you might see that you should also be in favour of IPv6.
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.
Only because it is overengineered. Parents pragmatic protocol would have been adopted faster
And how would they have gotten first-hop connectivity without IPv6?
Comcast added IPv6 many years ago on their wired ISP side because they ran out of IPv4 for TR-069 management, and they had way fewer subscribers (at least at the time) than many mobile telcos.
And that half of the Internet is also some of the most bandwidth intensive stuff: Youtube, Netflix, Instagram. The CG-NAT hardware costs of streaming would be huge.
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.
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.
Non-legacy, newly formed ISPs have to spend a lot of money on either buying or leasing IPv4 address space, and even then if they grow they probably won't be able to keep up, and so have to deploy 100.64.0.0/10 to the WAN interface of CPEs and then buy a bunch of CG-NAT hardware.
The problems are on not entirely visible at the end-user side of things because of the Herculean efforts by ISPs.
IPv4-only services are thus externalizing the costs of connectivity to ISPs (especially newly formed ones).
Obviously if the ISP is buying transit from HE, they'd have to pay for it, but it'd be surprising if HE was strongarming their customers by adding a clause that's like "oh also, if any of your customers use our ipv6 tunnel, we'll charge you $x/user/month" or whatever.
The real security risk is thinking that just because you have an internal RFC 1918 address space your security has improved.
It's been a decade+ since a firewall being considered a castle/moat of security being best practice. Any IT person that thinks that if they see a device with an 10/8 (or 172.16/12 or 192.168/16) IP and think you're safe you should be fired: it's lazy thinking.
At least if you had a GUA address it would force you to pay more attention to the rest of your security controls. Just recently a co-worker retired some systems that were accessible to the outside via DNAT—but forget to clean up the firewall rules. So he then—for some fucking stupid reason—decided to re-use those same IPs, even though we had so many fucking other IPs available, and one of the boxes got compromised because it happened to have a simple, guessable password on the initial image install.
Realistically nobody outside some devoted HN readers are going to self host their own content. At best you'd see something like netflix trying to offload their video hosting costs onto their customers.
So p2p stuff still doesn’t work without explicit configuration that rules out 99% of your users. It’s super annoying.
If you can process 512 then you get access to those, else you don’t.
Let the free market decide where it’s comfortable like it did with wireless security.
It wasn't meaningfully more difficult than setting up the server.
This is factually difficult to support. (Sent from my iPad which doesn’t have an ipv4 address… to hacker news which has an ipv6 address)
Yup, and only less than an eighth of the total IPv6 address space has been allocated [0] [1], so there's still plenty of room to expand, even if we have to throw every current address out and start from scratch.
[0]: https://www.iana.org/assignments/ipv6-address-space/ipv6-add...
[1]: https://datatracker.ietf.org/doc/html/rfc3513#section-4
My ISP doesn't do CGNAT in FTTH deployments, but I'm paying extra for a static IPv4 allocation anyway since I was increasingly getting hit with captchas every time my IPv4 rotated to flagged IPs that were trashed by my fellow subscribers with poor infosec practices - i.e. 99.9% of residential subscribers.
Once I got a static allocation, captchas are getting easy to pass.
Isn't that literally their raison d'être? Point taken that in aggregate it increases the costs of network operators but still that's got nothing to do with an individual instance of an individual user visiting an individual website.
(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.)
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.
Some ISPs are reportedly giving out a /128, and SLAAC works adequately with a router performing IPv6 NAT, so those ISPs don't see a problem.
Mobile phone as WiFi access point is another common way people access the net nowadays. I've occasionally seen permanent installations, with a phone taped to a window. I've never seen a mobile phone AP offer IPv6 to clients, but if they do they have to use SLAAC-compatible IPv6 NAT in that situation.
The only ISP not putting out v6 widely is SFR, and thankfully they've gone bankrupt and we will be rid of this scourge.
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.
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)
Isn't self hosting, and small, private/semi-private communities the only way forwards for much of the internet? AI has made content extremely valuable, which in turn has started to destroy the openness of the web. Things are getting more and more siloed, with entry fees.
There's a world where self hosting comes back in a big way. AI ironically makes it much easier.
How about Xbox/PS multiplayer/P2P gaming? Hosting a Minecraft server?
When Skype first came out it was P2P, but had to come up with the "supernode" concept (basically STUN/TURN/ICE) because of NAT: now all of our communication methods basically have to phone into the mothership.
Do we want the Internet to be more centralized (possibly given more power to the tech bros) or more decentralized?
It's a shame because if we could only get over stateful firewalling we'd be one step closer to the impossible task of using voice chat in console video games.
Right now they don't have that of course and the only hurdle is "NAT Types" which, as we all know, is a much easier problem to solve for the average person...
(this was sarcasm, if it wasn't clear).
It’s gotten much worse.
No reason you can’t carry IPv4 over any protocol you want. Multi tennant vxlans can carry whatever you want over your base network. Maybe an IPv6 underlay makes sense there, doesn’t really matter
It's almost always faster than anything else available, and ipv6 would make that method of sending files closer to the default for most people.
Having VOIP in games or 1v1 lobbies is, in the strictest sense, "hosting" something in the same way.
FD: I work in video games so I speak from this bias.
192.168/16 is a private IPv4 subnet (https://en.wikipedia.org/wiki/Private_network#IPv4) and the equivalent for IPv6 is the fd00/8 subnet (RFC 4193).
The connection is solid, though - thus my lack of enthusiasm.
For example here is how to achieve the same result in PF, note the single additional operator needed to specify nat.
block in on $EXT_IF
#NAT
pass in on $INT_IF to any rdr-to $EXT_IF
#statefullfirewall
pass in on $INT_IF to any
The bigger issues is not remembering hostnames vs IP addresses.
Unless you have explicitly changed it what is the hostname of your mobile device? How about your PC?
The reality is with an even mildly competent DNS+DHCP implementation that is all you would need...
And mDNS otherwise but it seems only Apple ever bothered with that being default.
I've only read that on HN, I've never heard this anywhere else. Since it's been a good 20+ years since my CCNA (and haven't needed to renew it since), could you please offer a real-world example where NAT is not a firewall w/ practical examples relating to 99.9% of cases of home use? I just can't get why people say this a lot here.
NAT works and passes the grandma test. If grandma buys a crappy vulnerable 40$ printer and plugs it in, even if it accepts unauthenticated stuff on every local port, you will not be able to connect to it behind NAT. So what's the difference? The only way I could think this can apply is if the ISP is compromised or criminally mismanaged, in which case you probably already have bigger problems.
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.
bittorent has been around for decades and nobody used it. They emailed files to themselves instead, or used dropbox. This all happened before the ipv4 shortage and people getting moved to CGNAT.
Most people run dual stack and as $favoriteHost gets AAAA, their traffic moves over.
My broader point was that your use of overstatement and a false dichotomy isn't _helping_ us get to a world where IPv6 is dominant.
Free market decides where it lands.
If there’s nothing of value at 512, it’ll naturally flop.
Well-regarded networking architect, author, and instructor:
* https://blog.ipspace.net/2011/12/is-nat-security-feature/
> NAT works and passes the grandma test.
So does my Asus with a default deny IPv6 rule on incoming connections.
You're more likely to click on a link that installs malware that attacks your network from the inside, and that attack works regardless of IPv4 or IPv6.
Treating a firewall as some impenetrable moat has not been network security practice for a decade(+), and waving around RFC 1918 address space like systems with a 10.8 or 192.168/16 can't get infected is lazy thinking. It leads to complacency: I'm behind NAT, I'm safe.
* 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?
ISPs had/have whole groups trying to stomp it out.
And it was a nightmare due to NAT even then.
It just got worse with CGNAT.
Even Linux distros push you so direct downloads now rather than pointing to trackers.
BitTorrent only has healthy usage for content that’s untenable to host legitimately.
But why would you rather have an always-broken network that might block attackers instead of a deliberate "deny incoming" rule that does exactly what you want -- and that you can punch holes in if desired?
Instead we have apps circumventing this accidental barrier with STUN, uPNP, etc with little/no oversight and we also regularly encounter brokenness.
no reason this has to be centralised.
in fact, Jitsi uses p2p with WebRTC until a third person joins the call: then migrates the call to be relayed.
A really nice latency win.
Also, hey now - I have a lot of (actual) Linux disk images, and it works well for that!