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