GitHub is at the point where it immediately rate limits me if I try to look at a project's commit history without being logged in, as in the first time I even open a single URL to the commit history, I get "Too Many Requests" from GitHub thrown at me. I don't know if my work's antivirus stack is causing GitHub to be suspicious of me, but it's definitely egregious.
It’s not you or your setup. I experience the same behavior. Tried with and without Private Relay, residential and commercial ISPs at different locations, and more to debug it. Same results.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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...
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.
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!
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.
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.
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.
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.
IPv6 is very difficult to implement and enforce reliable rate limits on anonymous traffic. This is something we've struggled a lot with - there is no consistent implementation or standard when it comes to assigning of IPv6 addresses. sometimes a machine gets a full /64, other times a whole data center uses a full /64. So then we need to try and build knowledge of what level to block based on which IP range and for some it's just not worth the hassle.
Well, even if there was a standard, that's still not a guarantee that the other side of the /64 would be following it. It's correct for you to rate-limit the whole /64.
IPv6 rollout is a lot of operational work that ends with next to no immediate quantifiable benefit. So I’ll never be prioritized in a cost-cutting environment.
I mean, all your numbering woes vanished, so, that's probably an immediate quantifiable benefit unless you're so tiny you never needed any renumbering effort, in which case your "operational work" to deploy IPv6 was probably zero.
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".
"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
Regardless of whatever other things may be better or worse about ipv6, it's still a reality that as we continue connecting more and more devices to the internet eventually ipv4 addresses will become so scarce and valuable that a not-insignificant minority of residential customers will be behind such aggressive CGNAT that the internet will become nearly unusable unless a majority of the services they are using support ipv6.
I agree with you. While I can see some benefits to v6 on the internet, I find v4 to be miles easier and cleaner to work with in a LAN setup. Unfortunately though v6 oversteps on LAN features and makes bridging v4 and v6 way uglier than it should.
It has barely hit 50% and it's already plateauing. This adoption rate is ridiculous despite basically all network interfaces supporting it. I thought I would see IPv6 take over in my lifetime as the default for platforms to build on but I can see I was wrong. Enterprise and commercial companies are literally going to hold back internet progress around 60 to 75 years because it's in their best interest to ensure users can't host services without them. Maybe even 75 years might be too optimistic? They are literally going to do everything in their power to avoid the transition, either being dragged out kicking and screaming or throwing their hands up and saying they can't support IPv6 because it costs too much.
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.
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.
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.
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.
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
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.
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.
> 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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
> 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.
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.
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.
It's frustrating that even brand new Unifi devices that claim to support IPv6 are actually pretty broken when you try to use it. So 10 years from right now even, unless they can software patch it upwards.
Except that is completely wrong. Consumer/residential networks have significantly higher ipv6 adoption rates that corporate/enterprise networks. That is why you see such clear patterns (weekend vs weekday) in the adoption graphs.
Sure, the 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.
> 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.
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.
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.
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 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.
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.
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?
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 ;)
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.
> 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.
> 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.
> 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>
> 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.
> 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.
> 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...
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.
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.
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.
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.
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.
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.
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.
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.
Residential vs. business. If the graph was hourly and per country, you'd see the same rise every morning and drop every evening (likely by more than 5pp).
If GitHub flipped a switch and enabled IPv6 it would instantly break many of their customers who have configured IP based access controls [1]. If the customer's network supports IPv6, the traffic would switch, and if they haven't added their IPv6 addresses to the policy ... boom everything breaks.
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...
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).
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.
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.
Thanks to the trend to SASE like Palo Alto GlobalProtect or ZScsler this practice is not a good idea anymore. Speaking of ZScaler, they are still IPv4 only, right?
Sometimes TCP/IP is a leaky abstraction, and recently ipv6 peeked through in two separate instances:
- 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
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.
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.
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.
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.
I get an IPv6 address from my ISP (a /56 I believe), but I wish there was some good information on how to update my OpenWRT VLAN configuration, routing, and firewall rules to be able to support native IPv6 on my devices. Would love to be able to have direct IPv6 connections to the internet from my devices, but I want to make sure I can do it safely.
Yeah, I'm in the same boat. I like the idea of being able to remotely connect to anything on my network, but I know just enough about networking to be dangerous, and don't trust my self to set it up securely, so I have IPv6 disabled on my router. With IPv4, it's physically impossible to mess up the firewall and NAT settings enough to make local devices public.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I can't imagine a worse privacy nightmare. Always on backdoored baseband in 5G with a unique permanent IPv6 address assigned to the machine. Okay, maybe it could be worse if each user account is assigned its own unique IPv6 perma-cookie.
You're thinking of MAC addresses. Machines don't have permanently-assigned v6 addresses, rather the IP is assigned by whatever network they're currently attached to and will change based on that network's whims, just like it does in v4.
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.
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.
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.
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
Adding on. Jio was a late entrant, so they could not get significant ipv4 address space without great expense. They deployed as mostly v6 with a tiny CGNAT. They also had an extensive 'pre-release' offering at zero cost to subscribers which got them a huge number of subscribers and clout to encourage internet services to offer ipv6.
India has about 1.5 billion people, and has only recently been getting most of them online. Less IPv4 legacy, and it has always been obvious that IPv4 was never going to be ‘enough’ to actually onboard everyone anyway.
When I lived in India, everything had IPv6 out of the box.
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.
Are you with SFR? I also seem to only have a static IPv4 (I don't pay for it, but it's never changed in the lifetime of the connection). I asked for an IPv6 but they said it was not possible/difficult.
NB: this is not "IPv6 traffic crosses the 50% mark" but "availability of IPv6 connectivity among Google users", which is a very important difference. This means roughly half of Google users have IPv6 capability, which does not 1:1 correspond how much traffic is actually transferred over IPv6, which is what this submission says in the title.
Yeah and this distinction explains the fact that because China's Great Firewall blocks Google, this website shows 4.66% adoption as a reflection of that. I think China's IPv6 support rate is actually much higher than that, maybe a little over 50% because of its central initiative to increase IPv6 adoption?
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.
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."
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.
I just recently noticed that my ISP, Frontier, quietly turned on IPv6. I know it wasn't enabled back in December, so it has to have been sometime in the past few months.
interestingly my ISP, at&t, quietly turned off ipv6. not sure exactly when it happened, i should get around to complaining about it but i hate making phone calls
I consistently get 100x as many captchas from google over V6 as over V4, on many different networks: it is obnoxious and obviously broken on their end.
Currently my IPS provides IPv6, but I set up my firewall in the access router of my home LAN to block all IPv6 in both directions.
- 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
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.
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.
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?
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.
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.
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.
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.
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.
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.
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
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.
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.
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).
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.
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.
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?
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.
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.
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.
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.
I had the same issue a few months ago on AWS. All I want is a server (that pulls a container), a database, and a load balancer. It's all going behind CloudFront so there should be no need to pay for an IPv4 address for any internal machine. Couldn't do it. Since then I saw that there was some movement on IPv6 for RDS but IIRC there was still some other blocker.
> so there should be no need to pay for an IPv4 address for any internal machine
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.
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.
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.
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.
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.
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?
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.
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.
To what end though? 4 billion addresses is not enough on its own, even if they were reallocated from hoarders. I think that NAT and especially CGNAT have been very detrimental to the shape of the internet, where it's nearly impossible to self-host a public service without a VPN of some kind. Needing to pay some company for the ability to host a server that isn't behind NAT is a barrier that doesn't need to exist when IPv6 has a nearly limitless number of addresses.
You're not wrong, but practically speaking, hosting a VM is so cheap and comes with the advantage of serving from a datacenter that I would never want to host anything off my residential connection anyway.
The $1 to $5 a month to have excellent, reliable connectivity (that no residential connection provides), DDoS protection, and isn't tied to my home IP outweighs any home hosting benefit in my experience.
There are 16 /8's in the class E address space that were never allocated, and 19 /8's (by my count) allocated to individual companies. If you waved a wand and returned all of that space to IANA for allocation, you would have staved off IPv4 address exhaustion by... about 3 years.
2.7 - 4.0 years, by my math, so I would agree with your assessment.
...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).
What I have asked myself the last few months: I've read about IPv4 becoming sparce a few years ago. I haven't read much about it lately. And I've thought maybe the advance of cloud computing and load balancer kind of mitigated the issue of sparce IP4?
It officially started becoming scarce in 2011, when IANA, and then APNIC, depleted their IPv4 "free" pools, FWIW. Things have only gotten worse from there.
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.
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.
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.
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.
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.
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.
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.
while it looks like its slowing down, I am pretty sure it will speed up once IPv4 get even more expensive, sites start to be hosted on IPv6 only and become inaccessible to some users that dont have IPv4. Thats surely going to put pressure on ISPs
Outside of hobbyist niche uses, sites won't start being hosted IPv6-only. The financialization of IPv4 addresses will simply get worse and be even more pay-to-play than it is now. Amazon raises the price of IPv4 and everyone goes along as a cost of doing business.
My prediction is that sites will be half-IPv6 only; backends will be IPv6 and IPv4 traffic will get proxied to IPv6 by CDNs / edge LBs. I think CloudFront for example supports that scenario, avoiding IPv4 costs (in theory).
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.
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.
IPv4-with-more-bytes is not backwards compatible with IPv4. So you'd have to replace/upgrade every existing network stack, both hardware and software. To get, basically, the same effect as moving to IPv6.
> IPv4-with-more-bytes is not backwards compatible with IPv4
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.
> 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.
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.
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...
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.
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.)
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.
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
Nice. But note that the average is still significantly below 50%. It's also a bit concerning that the growth rate seems to be levelling off. It currently looks like a sigmoid curve with a maximum far below 100%.
I wouldn't be so worried about it. It's really hard for something as big as this to really hit 100%. If we hit 80% or thereabouts, we can at least plausibly argue to backwards ISPs that IPv6 is the default and the standard that everyone should reasonably be offering.
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!
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!
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.)
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!
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.
::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)
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.
> 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.
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.
$ 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.
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 .
Might as well go big. 24 extra bytes per packet is not that big deal. And having that much extra space means you can screw up design multiple times and still be able to reuse lot of infra. Also getting rid of idea that you are even trying to manually manage the address space eases many things.
But it's not human readable anymore, nor backwards compatible. The expectation was that the industry is reasonable, but it proved to be as hard as it would be to push breaking email v2 implementation.
If 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%.
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.
And still, in the year of our lord 2026, GitHub does not support IPv6.
https://github.com/orgs/community/discussions/10539
A non-trivial minority of the time, they don't support IPv4 either!
GitHub is at the point where it immediately rate limits me if I try to look at a project's commit history without being logged in, as in the first time I even open a single URL to the commit history, I get "Too Many Requests" from GitHub thrown at me. I don't know if my work's antivirus stack is causing GitHub to be suspicious of me, but it's definitely egregious.
It’s not you or your setup. I experience the same behavior. Tried with and without Private Relay, residential and commercial ISPs at different locations, and more to debug it. Same results.
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.
My theory is that they rate limit that URL aggressively due to AI scrapers. At this point it's faster to just clone the repo and do your searching locally.
Your work is probably all exiting through the same IP, you competing with others on the same IP is causing the rate limit.
should we try going back to IPX ?
Comically IPv6 now has almost all the neat stuff IPX did. There probably is an argument for more datagram centric networking these days as the underlying services are generally much faster and more reliable and there is so much more session tracking going on at higher application layers anyway.
IPX/SPX is datagram only. BUT it would be an opportunity to build a QUIC-like that runs over it :-)
Only if we're bringing back Token Ring, too.
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.
I've used IPX exactly once in my life, playing Diablo over modems calling my dorm neighbor to establish the connection (in 2005).
IPv1, IPv2, and IPv3 were very early experimental versions of the Internet Protocol developed in the 1970s during the ARPANET era (the precursor to the modern internet). Has anyone tried to find out if GitHub is reliable on those?
What? One nine isn’t good enough for you?
Excuse me. Zero nines. Or two nines if you relax your definition of where they are in the number. https://infosec.exchange/@0xabad1dea/116334321751266751
You guys have nines?
Personally I’d look for the coveted 5 eights uptime.
As long as it is after the decimal separator I can try for that...
> And still, in the year of our lord 2026, GitHub does not support IPv6.
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-...
I mean Azure doesn't really support IPv6 well either for a lot of the big-ticket services.
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.
More importantly, it doesn’t support uptime well.
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.
So zero validation after that change?
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.
Zero observability and alerting too. Seems like they’re planning to be a productive future member of that team.
They supported IPv6 for a short time, but then stopped their experiment.
An excellent reason to move away from Github, I find.
I've been there. Management was fine with the testing but it added too much overhead for nearly no benefit to us.
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.
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.
Facebook is (AIUI) 100% IPv6-only on their internal network, and has been for many years:
* 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.
That's why ipv6 migration should be government mandated. Then it becomes just the cost of doing business
Our university has bad problems with ipv4. Every few days you'll notice some websites being unreachable, including github. Although with their uptime recently, you never know who's to blame...
At least HN supports IPv6 now, which I remember was not the case last time I checked.
Just found this little site. https://isgithubipv6.web.app/
Maybe we shouldn't even measure percentage adoption and instead just if github has finally adopted..
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.
>github.io does have an IPv6 address
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
GitHub should absolutely support IPv6, but until then... transip.eu provide IPv6 addresses which transparently proxy to github.com: https://www.transip.eu/knowledgebase/5277-using-transip-gith...
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?
>The Github IPv6 Proxy can only be used for traffic to Github using a VPS from TransIP which uses IPv6.
Good spot. Sorry to disappoint!
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!
Last I checked, they're on Fastly who already support IPv6.
Do we know any technical reason for this? Or are we left to think this is somehow a political thing?
Perhaps a little tin foil hatty and definitely not the only reason but Microsoft owns Github and also makes a boatload of money off of Azure. Incumbent cloud providers like Azure have a major advantage in terms of having plenty of IPv4 addressing available whereas a new entrant to that market would have to buy or lease that space at a premium. Thus, these companies have an incentive to keep IPv4 a necessity.
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.
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.
> 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:
* https://www.youtube.com/watch?v=d6oBCYHzrTA
But sure, be IPv4-only and add latency by forcing traffic through an extra translation box.
It's because big tech is USA based mostly, where there's still a glut of ipv4 available.
Definitely not for the biggest ones. Google and Meta have so many machines in their data centers that IPv6 addressing becomes a technical necessity due to the risk of exhausting the RFC 1918 address space. Naturally, they were early adopters of IPv6.
Well it’s over 50%…
It's a possibly a managerial thing, which KPI are you improving when spending engineering time on adding IPv6 support?
That said, for their HTTP stack they use fastly (as far as I understand), which should make the shift moderately easier.
IPv6 is very difficult to implement and enforce reliable rate limits on anonymous traffic. This is something we've struggled a lot with - there is no consistent implementation or standard when it comes to assigning of IPv6 addresses. sometimes a machine gets a full /64, other times a whole data center uses a full /64. So then we need to try and build knowledge of what level to block based on which IP range and for some it's just not worth the hassle.
Well, even if there was a standard, that's still not a guarantee that the other side of the /64 would be following it. It's correct for you to rate-limit the whole /64.
... But that's no different from IPv4. Sometimes you have one per user, sometimes there are ~1000 users per IP.
Most of the ipv4 world is now behind CGNAT, one user per ip is simply a wrong assumption.
IPv6 rollout is a lot of operational work that ends with next to no immediate quantifiable benefit. So I’ll never be prioritized in a cost-cutting environment.
I mean, all your numbering woes vanished, so, that's probably an immediate quantifiable benefit unless you're so tiny you never needed any renumbering effort, in which case your "operational work" to deploy IPv6 was probably zero.
It could be that they don't want to implement IP bans in IPv6.
How does IP bans work in IPv6 case? One just blocks whole /64 or /56 address range?
Or the most likely more expensive rate limiting (computational wise)
You probably need a hefty security reimplementation if you want to add IPv6 to Github.
Came here to exactly check on this to see if there are any changes on Github side too
Most websites still don't
Tailscale have a great FAQ about IPv4 vs IPv6: https://tailscale.com/docs/reference/faq/ipv6
If you're not an expert in this area it's worth a read - I certainly learned a few things!
That was excellent, thanks for recommending it. I particularly liked how it's a pretty factual FAQ, not particularly cheerleading for IPv6 nor saying "IPv6 is a failure, give up on it".
Here is my article that I wrote when I wanted to learn more about IPv6: https://ssg.dev/ipv6-for-the-remotely-interested-af214dd06aa...
EDIT: After reading Tailscale's article, I noticed that I overlooked our neverending dependence to NAT despite that IPv6 seems to eliminate it.
a great assessment thanks I hadn't seen that
"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
Regardless of whatever other things may be better or worse about ipv6, it's still a reality that as we continue connecting more and more devices to the internet eventually ipv4 addresses will become so scarce and valuable that a not-insignificant minority of residential customers will be behind such aggressive CGNAT that the internet will become nearly unusable unless a majority of the services they are using support ipv6.
I agree with you. While I can see some benefits to v6 on the internet, I find v4 to be miles easier and cleaner to work with in a LAN setup. Unfortunately though v6 oversteps on LAN features and makes bridging v4 and v6 way uglier than it should.
> v6 oversteps on LAN features and makes bridging v4 and v6 way uglier than it should
How so?
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.
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.
^1 https://www.theregister.com/2025/08/04/asia_in_brief/
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.
But their VLANs still only support ipv4, which makes it hard to route external ipv6 traffic through the VLANs. You need tunnels.
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.
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.
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
> 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:
* https://www.youtube.com/watch?v=d6oBCYHzrTA
The requirement is to support IPv6 only networks with IPv4 transition mechanisms. It does not preclude contacting v4-only servers.
And the higher level libraries mostly do it for you, too, even if you directly specify IPv4 addresses in your code (due to NAT64 [1]). I think it only even requires special work from you as a developer if you're using low-level or non-standard libraries.
[1] https://en.wikipedia.org/wiki/NAT64
If that's the case, how does the Github app work on iOS?
Nat64: https://developer.apple.com/support/ipv6/
Differential enforcement.
I’m guessing the app works but their prod servers don’t? If they can point the app during review at a “self hosted” GitHub Enterprise server on a test domain with AAAA that would pass the requirement as stated by gp , without requiring GitHub.com actually support ipv6.
> 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.
> 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%
The Czech government has announced it’ll stop offering its services via IPv4 in June 2032.
Source https://konecipv4.cz/en/
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.
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.
For now, :) Hopefully it continues.
> if IPv6 prevents IPv4 rental prices from going haywire, then it's served a useful purpose.
Competition is good.
ISPs often fail to do this because there is always someone in the hierarchy who says, "nobody is demanding it."
Nobody is demanding IPv4 either. Or Ethernet. People buy "Wi-Fi", literally "Wi-Fi", not Internet access.
Exactly. To this point I went to a Comcast store to cancel my internet and the person asked me if I meant I wanted to cancel my “Wi-Fi”. I was very confused for a couple seconds.
It has been interesting to me to see how the usage of "my wifi bill" instead of "my internet bill" has shifted.
> 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.
I worked at a place where they refused to run it _anywhere_ because a couple of people were insistent that it was “insecure”.
... and they were right.
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.
I with I knew how to get through that I want it. I'm supposed to be a tech guy - that means I need experience with the latest tech in my house
I 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.
I think we'll hit a tipping point soon, just like with Python3 - for years and years it seemed almost stalled, then it became easier to start with python3 than python2 and suddenly everyone migrated.
This seems like wishful thinking. Python3 vs. Python2 seems different than IPv6 vs. IPv4.
"seems" is doing a lot of heavy-lifting in your message
“Gradually, then suddenly.”
> 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.
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.
Wow, that’s very cool! Do you know how that works? Do they just connect you to a NAT64 gateway of your choice?
My German ISP supports it now, which was the limiting factor for me, and a new VPS I just bought also does, so finally I was able to create my first personal AAAA record. I am hoping that we're seeing a tipping point. Again.
Since when was there ever a plan to disable IPv4 on the Internet? Just because IPv6 is around doesn't mean that IPv4 is going to go away.
That was always the plan for "the future". That is get everyone to IPv6 and then get rid of IPv4. IPv4's days are numbered - but the number looks really big.
Why would we keep around a whole separate Internet? Dual stack was always only intended for the transition period.
It's very hard to get rid of old standards.
"The past is never dead. It's not even past"
>> It has barely hit 50% and it's already plateauing.
Well, the curve has got to level-out at 100%.
No, it can level out below that and is (as the parent was saying).
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.
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.
> Also, notice how Android and iOS don't support turning off IPv4.
You can trivially connect an iOS device via IPv6 only.
Can you share details on how one trivially connects via IPv6 only? I see no option in iOS Wi-Fi settings to do this, and I think it's reasonable to expect not to have to turn off IPv4 on my access point to test IPv6-only networking.
Presumably thats with the network having a PLAT somewhere if you’re relying on CLAT for any v4-only connections when you use safari
I think they're saying you can't force disable ipv4 entirely.
> It has barely hit 50% and it's already plateauing.
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.
ISPs in the US and Europe mostly have been offering IPv6 for a while now
Unfortunately my ISP here in Europe is not one of those offering IPv6.
Other than France or Germany its far from mostly.
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.
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.
It's frustrating that even brand new Unifi devices that claim to support IPv6 are actually pretty broken when you try to use it. So 10 years from right now even, unless they can software patch it upwards.
Except that is completely wrong. Consumer/residential networks have significantly higher ipv6 adoption rates that corporate/enterprise networks. That is why you see such clear patterns (weekend vs weekday) in the adoption graphs.
Sure, the 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.
> 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.
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.
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.
> 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.
>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
> 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.
Nothing stops you running a NAT for v6 too, its just people tend to choose not to when given the choice
I set up NAT66 recently with DHCPv6. The IPv4 and IPv6 addresses are practically the same, except IPv6 has a prefix and a double colon as the last separator.
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.
"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.
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.
> Just the obvious one: the people who designed IPv6 didn't design for backwards compatibility.
Nor for easy transition.
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?
> 1: it's hard to remember addresses
fd::1 is perfectly valid internal IPv6 address (along with fd::2 ... fd::n)
fd::1 is somewhere in the reserved ::/8 space where various stuff like old ipv4 mapped addresses and localhost reside. What you probably mean is something like fd00::1, but that is something you shouldn't use, because 'fd00::/8' is a probabilistically unique local address (ULA) block. You are supposed to create a /48 net by appending 40 random bits to fd00::/8. Of course, if your fair dice roll lands on all zeroes, and you are ok with probable collisions in case of a network merge, you are fine ;)
> 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...
That's extremely common unless on "active" fiber (vs GPON, DOCSIS3, DSL, most fixed wireless, satellite, mobile, etc.)
Your wifi isn't symmetrical either.
IPv6 is a recursive WTF. It might _look_ like a conservative expansion of IPv4, but it's really not. A lot of operational experience and practices from IPv4 don't apply to IPv6.
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.
> 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.
> 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.
> 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>
> 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.
> 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.
> 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>).
> 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...
How do the working IPv6 deployments cope with these issues?
>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.
The reason: Skill issue.
Ignore all the excuses like longer addresses and incompatible hardware. The actual reason is that everyone hates change.
Comcast, one of the largest residential ISPs in the USA, has almost full IPv6 deployment by default. The majority Verizon Wireless is IPv6 by default. Residential customers in the USA have great access if they just enable the stack.
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.
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.
A UN priority!? They have real issues they should be dealing with like the life and death of millions of people
To be fair to the grand parent, the International Telecommunications Union is a specialized agency of the UN and actively promoting IPv6: https://www.itu.int/en/ITU-T/ipv6/Pages/default.aspx
I think it's fine if they have more than one priority.
Worst migration plan ever.
> 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
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.
> 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.
https://github.com/ValveSoftware/steam-for-linux/issues/3372...
In parts of the world with fewer IP addresses they already are. My ISP _only_ offers MAP-E access to the IPv4 internet for anyone not grandfathered into an older plan.
I don't want IPv6. Why would I? It's like a permanent global cookie. You're uniquely tagged and identifiable on every website you visit.
>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.
> You're uniquely tagged and identifiable on every website you visit.
Almost every modern OS enables IPv6 privacy extensions, ie address randomization, by default.
My OS gives me IPv6 privacy addresses out-the-box which rotate every few hours.
Zoom in on that graph using the controls at the bottom, and you'll see a repeating pattern of crests and troughs, weekly. There's about a 5% difference between the crests and the troughs: the crests are hitting the 50% line or just below it, and the troughs are down around 45%.
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.
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.
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.
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.
Residential vs. business. If the graph was hourly and per country, you'd see the same rise every morning and drop every evening (likely by more than 5pp).
If GitHub flipped a switch and enabled IPv6 it would instantly break many of their customers who have configured IP based access controls [1]. If the customer's network supports IPv6, the traffic would switch, and if they haven't added their IPv6 addresses to the policy ... boom everything breaks.
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...
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
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 ?
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).
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 :)
Anyone who relies on IP filtering for security deserves to have it broken. Change my mind.
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.
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.
Defense in depth is a thing but I agree that relying on it is not a good idea.
Defense in depth is not the point, zero trust networking is.
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.
If you can't handle sites switching to ipv6 in 2015 (ten years ago) your security plan is garbage.
> providers don't have an easy way to correlate addresses
Yes, they do. It's called DNSSEC.
Thanks to the trend to SASE like Palo Alto GlobalProtect or ZScsler this practice is not a good idea anymore. Speaking of ZScaler, they are still IPv4 only, right?
Sometimes TCP/IP is a leaky abstraction, and recently ipv6 peeked through in two separate instances:
- 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
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.
> I wish hosting providers would give you a local routed ipv4 on ipv6 servers with a default NAT server.
You mean like AWS NatGW https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gat...
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.
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.
Any services like this for Hetzner?
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.
It seems the biggest hurdle to IPv6 adoption is legacy software and hardware. Anything new that gets built can easily be v6 only.
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
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.
great resource. Common crawl is a goldmine
I get an IPv6 address from my ISP (a /56 I believe), but I wish there was some good information on how to update my OpenWRT VLAN configuration, routing, and firewall rules to be able to support native IPv6 on my devices. Would love to be able to have direct IPv6 connections to the internet from my devices, but I want to make sure I can do it safely.
Yeah, I'm in the same boat. I like the idea of being able to remotely connect to anything on my network, but I know just enough about networking to be dangerous, and don't trust my self to set it up securely, so I have IPv6 disabled on my router. With IPv4, it's physically impossible to mess up the firewall and NAT settings enough to make local devices public.
This was surprisingly complicated for me on Altice/Optimum, which is why my home didn't have IPv6 for a while even after they started provisioning.
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.
You only need to set nothing and it should setup ipv6 on all downstream vlan interfaces. For static prefix I'd you can set ip6hint per vlan interface. For each vlan interface you need a stanza in the DHCP config file. And regarding firewall, as with the default lan zone you might need to add new zones with the vlan interfaces and configure forwarding rules. That's it.
Is most of that due to mobile?
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.
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.
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
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.
CloudFlare Radar has stats for desktop (34%) vs mobile (46%) adoption: https://radar.cloudflare.com/explorer?dataSet=http&groupBy=i...
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.
It'd be annoying even in the scenario where it got quickly adopted. Complicated spec, user-unfriendly addresses, unclear defaults.
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.
[1]: https://9to5mac.com/2025/08/14/apples-first-mac-with-5g-cell...
Dell, HP and Lenovo have had laptops with cellular modems for maybe 15 years at this point.
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.
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.
Jesus, what a waste
Yeah, but any given technology hasn't been invented yet, until Apple releases it.
*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.
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.
| Macbooks have been rumoured for a while to get cellular modems.
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/
> 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?
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.
I can't imagine a worse privacy nightmare. Always on backdoored baseband in 5G with a unique permanent IPv6 address assigned to the machine. Okay, maybe it could be worse if each user account is assigned its own unique IPv6 perma-cookie.
You're thinking of MAC addresses. Machines don't have permanently-assigned v6 addresses, rather the IP is assigned by whatever network they're currently attached to and will change based on that network's whims, just like it does in v4.
As if people doesn't already carry always online machine in their pockets
> Okay, maybe it could be worse if each user account is assigned its own unique IPv6 perma-cookie.
They will. One from facebook, one from google, one from tiktok, several from Palantir and its partners...
As a French national, I am surprised to discover we are topping the charts according to this analysis.
Does anybody know why that might be the case? What's the story of IPv6 deployment in France?
The regulatory body, ARCEP, has been very proactive since 2002 (!) on IPv6. The recent uptick is due to IPv6 obligations bundled in the 5G spectrum licences.
https://www.arcep.fr/la-regulation/grands-dossiers-internet-...
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.
^1: https://en.wikipedia.org/wiki/Minitel
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.
I worked with the internet society to mobitor ipv6 adoption for the top million sites ipv6matrix.org it's broken down by country so might answer some of your curiosity
I'm wondering the same thing for India. Not the top but looks surprisingly surprisingly high. Perhaps I'm reading the data wrong.
Reliance Jio deployed cheap native v6 and tool massive market share. They single-handedly moved the market.
It's been discussed on the apnic blog and at meetings heaps
Adding on. Jio was a late entrant, so they could not get significant ipv4 address space without great expense. They deployed as mostly v6 with a tiny CGNAT. They also had an extensive 'pre-release' offering at zero cost to subscribers which got them a huge number of subscribers and clout to encourage internet services to offer ipv6.
India has about 1.5 billion people, and has only recently been getting most of them online. Less IPv4 legacy, and it has always been obvious that IPv4 was never going to be ‘enough’ to actually onboard everyone anyway.
When I lived in India, everything had IPv6 out of the box.
Technical literacy, hacker culture, and culture of well-considered infrastructure, have been French characteristics - at least, historically.
Has something changed for the worse?
It amuses me to see that according to the map, France is best in class or close to be, while just a few weeks ago, my ISP in France stopped providing me IPv6 connectivity…
The story is that at the beginning I had IPv6, and a shared dynamic IPv4 behind a CGNAT, I asked for a rollback to a full duplex static IPv4 and for three years I had both a static personal IPv4 and an IPv6. A few weeks ago my router went down and since it went back up, I no longer have an IPv6 address. I called my ISP and they explained that I could either have IPv6 or a static IPv4, but not both, and that it's abnormal that I had both for so long… welp, it's sad to see IPv6 but getting it back is not worth abandoning my static IPv4 and going back to a dynamic shared IPv4.
You might be interested in https://tunnelbroker.net/ and https://route64.org/ although the later looks a little shady and I haven't tried them.
A cheap VPS or one with spare bandwidth with > /64 that is properly routed (some providers do NDP for some reason) and a Wireguard tunnel would also get you a simple DIY solution.
Are you with SFR? I also seem to only have a static IPv4 (I don't pay for it, but it's never changed in the lifetime of the connection). I asked for an IPv6 but they said it was not possible/difficult.
Yep, with "RED by SFR" specifically.
Among all the major French providers, SFR lags far behind its competition unfortunately
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.
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?
EDIT: Apparently it's 77% https://pulse.internetsociety.org/en/news/2026/01/china-hits...
"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?
Right, but in most situations clients will prefer IPv6 if its available, so if they have access, they almost always are using it, at the very least from their local network.
It also means you're excluding China, who has has it as a long-term priority to deploy IPv6 and have made huge strides.
Wouldn’t it be close? AFAIK modern network libraries on modern OSs default to IPv6 when available.
The question is, "what will the graph look like in the next 10 years?"
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."
>I explicitly asked about IPv6 connectivity and they said, "yes."
ABC, Always Be Closing.
It's been amazingly linear since 2014.
amazon.com needs to get with the program. Still IPv4 only.
Just in time for ipv8 - https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
This proposal is absolutely wild.
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.
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.
I just recently noticed that my ISP, Frontier, quietly turned on IPv6. I know it wasn't enabled back in December, so it has to have been sometime in the past few months.
interestingly my ISP, at&t, quietly turned off ipv6. not sure exactly when it happened, i should get around to complaining about it but i hate making phone calls
Current submission title:
> 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...
I consistently get 100x as many captchas from google over V6 as over V4, on many different networks: it is obnoxious and obviously broken on their end.
Currently my IPS provides IPv6, but I set up my firewall in the access router of my home LAN to block all IPv6 in both directions.
- 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
And how exactly is your NATed ipv4 address better? This seems backwards.
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.
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.
How often does your IPv4 address actually change?
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?
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.
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.
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.
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.
Latin1 to UTF8
And I still, to this day, see mojibake from time to time.
The exception that proves its success
Finally https://www.metaculus.com/questions/9558/50-of-users-access-... can resolve!
One of the foremost obstacles to wide adoption is that IPv4 still works great and it's ubiquitous. There is no advantage or up-side to deprecating or abandoning IPv4 support at all. The only result of disabling IPv4 is a denial of service to a certain sector of customers or clients.
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.
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.
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
Maybe it's time to tax IPv4 usages or holders.
I wish EU make it mandatory at least for all ISP to make mandatory support for IPv6 by end of this decade. I think that would push the needle even globally.
My next project, IPv6 in my homelab. It will be a challenge but it is time. My ISP gives me a static /48, I should use it.
I recommend going through Hurricane Electric's multiple-choice tests. It's not exactly a how-to guide or course, but it'll mention all of the terms and technologies you need to look up to get things right. They'll even send you a free T-shirt if you make it through all of them.
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.
Where do I find that? https://www.ipv6.he.net/ has an invalid certificate and is the first result on Google.
Their www sub-subdomain is broken it seems.
https://ipv6.he.net/certification/ has instructions on how to get started.
You need to omit the "www" subdomain: https://ipv6.he.net
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).
> heavy usage from a small number of IPv4s
Basically, all crawlers.
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.
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.
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?
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.
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...).
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.
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.
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.
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.
I had the same issue a few months ago on AWS. All I want is a server (that pulls a container), a database, and a load balancer. It's all going behind CloudFront so there should be no need to pay for an IPv4 address for any internal machine. Couldn't do it. Since then I saw that there was some movement on IPv6 for RDS but IIRC there was still some other blocker.
> so there should be no need to pay for an IPv4 address for any internal machine
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.
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.
Most of the chatter comes from the peanut gallery who have no real insight on what ISPs and other large networks are actually doing.
This. "Vibes," vs. data.
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.
Been waiting for this for years! Now I just wish my local ISP (rural Canada) supported it.
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.
Are any ISP's or corp intranets doing IPv6-mostly style networks yet: https://www.ietf.org/archive/id/draft-link-v6ops-6mops-00.ht...
That seems to be a promising approach.
T-Mobile does: https://www.internetsociety.org/deploy360/2014/case-study-t-...
They use 464XLAT, basically NAT64/DNS64 with some extra cooperation on the OS’s part for backwards compatibility with apps that hard-code IPv4. You get only a v6 address, and your OS basically synthesizes an v4 network on your device in cooperation with their NAT64 router. But all the bytes going from your device through to their towers are ipv6. Talking to a v4-only website uses carrier-grade NAT64 when leaving the t-mobile network.
Additionally, their fixed-wireless product gives you a physical CPE that does the CLAT (NAT46) side of the 464XLAT.
To the local network, it looks like there's native IPv4, but it's translated to IPv6 by the gateway, and sent to the "nearest" NAT64 PoP to be translated back and sent along its merry way.
According to https://www.ipv6.org.uk/wp-content/uploads/2023/11/13_IPv6-M... , Google is.
The author of the RFC is the author of the slides.
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?
Random test site for the consumer side: https://test-ipv6.com/
0/10 in Latvia with a local ISP, fun times.
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.
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.
To what end though? 4 billion addresses is not enough on its own, even if they were reallocated from hoarders. I think that NAT and especially CGNAT have been very detrimental to the shape of the internet, where it's nearly impossible to self-host a public service without a VPN of some kind. Needing to pay some company for the ability to host a server that isn't behind NAT is a barrier that doesn't need to exist when IPv6 has a nearly limitless number of addresses.
You're not wrong, but practically speaking, hosting a VM is so cheap and comes with the advantage of serving from a datacenter that I would never want to host anything off my residential connection anyway.
The $1 to $5 a month to have excellent, reliable connectivity (that no residential connection provides), DDoS protection, and isn't tied to my home IP outweighs any home hosting benefit in my experience.
There are 16 /8's in the class E address space that were never allocated, and 19 /8's (by my count) allocated to individual companies. If you waved a wand and returned all of that space to IANA for allocation, you would have staved off IPv4 address exhaustion by... about 3 years.
2.7 - 4.0 years, by my math, so I would agree with your assessment.
...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).
What I have asked myself the last few months: I've read about IPv4 becoming sparce a few years ago. I haven't read much about it lately. And I've thought maybe the advance of cloud computing and load balancer kind of mitigated the issue of sparce IP4?
It officially started becoming scarce in 2011, when IANA, and then APNIC, depleted their IPv4 "free" pools, FWIW. Things have only gotten worse from there.
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.
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 :(
We have enough IPv4 addresses (combined with CGNAT) in Denmark so the providers have no business incentive to spend money on supporting IPv6 :/
Carrier-grade NAT for home connections is pretty rare in Germany. I only know of Deutsche Glasfaser - a fairly new ISP that isn't doing too well.
It's very common. German ISPs collectively went with DS-Lite, so most of that 77% with v6 have CGNATed v4.
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.
Vodafone cable's cgnat struggles. I went v6 for home so that at least the v6 sites and my own connections avoid the congestion.
This is only 33 years after I took a networking class and learned all about IPv6 and the IPv4 address space crisis.
This is pretty remarkable, given that RFC 1883 is only 30 years old.
As long as no significant websites are IPv6-only qnd no significant user base is IPv6-only, why would anyone join IPv6? What proponents could do is make their websites IPv6-only. The IETF website, for instance, should be IPv6-only.
Countries like India have higher adoption (>70%) because of 4G/5G abundance. Legacy broadband providers hold back IPv6 usage.
Quick, someone tell slashdot!
In before the dinosaurs arrive to complain about the challenges of moving to IPv6 and why NAT and IPv4 are better. ;)
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.
They have released the draft for IPv8 two days ago: https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
Does it mean we better put our chips on IPv8?
https://datatracker.ietf.org/doc/html/draft-wkumari-not-a-dr...
Guess you didn’t read it.
15 years ago I would have dismissed this immediately as an elaborate troll but nowadays you cannot be sure anymore.
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.
That goes for me?
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.
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.
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.
while it looks like its slowing down, I am pretty sure it will speed up once IPv4 get even more expensive, sites start to be hosted on IPv6 only and become inaccessible to some users that dont have IPv4. Thats surely going to put pressure on ISPs
Outside of hobbyist niche uses, sites won't start being hosted IPv6-only. The financialization of IPv4 addresses will simply get worse and be even more pay-to-play than it is now. Amazon raises the price of IPv4 and everyone goes along as a cost of doing business.
My prediction is that sites will be half-IPv6 only; backends will be IPv6 and IPv4 traffic will get proxied to IPv6 by CDNs / edge LBs. I think CloudFront for example supports that scenario, avoiding IPv4 costs (in theory).
Yeah, hobbyist niche sites like these:
https://clintonwhitehouse1.archives.gov/
https://clintonwhitehouse2.archives.gov/
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.
that may be true, but not being able to access hobbyist sites still feels like "being locked out" of something. My ISP provides /48 IPv6 addresses for free, and I already run a couple sites only on IPv6 - because an IPv4 would cost 20 bucks a month - it's not important enough to me personally to pay that.
Maybe "think of the children."
There might be a child behind the NAT, thus IPv6 requirement.
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.
crossed 50% on Mar 28, 2026, 3 weekends back.
google published the latest data only yesterday, hence the delay.
we did it, boys!
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
Every year I just wish someone will come up with IPv4-with-more-bytes and we can switch to it before IPv6 gets another percent usage share.
IPv4-with-more-bytes is not backwards compatible with IPv4. So you'd have to replace/upgrade every existing network stack, both hardware and software. To get, basically, the same effect as moving to IPv6.
> IPv4-with-more-bytes is not backwards compatible with IPv4
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.
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.
> 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.
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.
https://datatracker.ietf.org/doc/html/rfc1385
They went with SIPP, which was one of the backwards-compatible options. It should be kind of obvious from the vast number of backwards compatibility methods available in v6 that v6 is actually backwards compatible... but for some reason a lot of people either refuse to believe this or have double standards around what counts as compatibility.
IPv6 is IPv4 with 12 more bytes, right?
And in the mean time, Odido on the Netherlands still don’t support ipv6 on their fiber network…
I'm surprised it's reporting is listed <5% - I thought it was pretty much ipv6 first?
And Virgin Media in the UK still doesn't support IPv6
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...
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.
I was wondering why someone proposed IPv8
Puma 8.0+ webserver now defaults to IPv6
It's all bots!!!
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.
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.)
And yet I still haven't ever connected to an internet provider that supports IPv6, across two countries I spend time in...
Waiting for github to support
Any idea why it oscillates?
Corporate IT networks have less IPv6 and residential/mobile networks have more IPv6, so on weekdays when people are using Internet at work = more IPv4, weekends when people are using Internet at home = more IPv6. Christmas also has a big bump for the same reason.
Awesome, thanks.
No change in trend during COVID years, interesting.
There is -- you can see the weekday/weekend difference is smaller when people are working from home en masse.
The final 10% is gonna be a doozy..
forgive dumb question but what happens when someone on IPv6 without IPv4 tunnel visits a URL with only a IPv4 endpoint?
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
meanwhile I just disabled ipv6 on all my vm's last night due to ubuntu package servers being down and needing to get something critical out the door.
90% spam/hack?
Spain: 9.9%
What's going on in Spain?
Bizarrely, Telefonica doesn't see a need. But, their subsidiaries in LatAM do heaps! And, they do central purchasing.
Nice. But note that the average is still significantly below 50%. It's also a bit concerning that the growth rate seems to be levelling off. It currently looks like a sigmoid curve with a maximum far below 100%.
I wouldn't be so worried about it. It's really hard for something as big as this to really hit 100%. If we hit 80% or thereabouts, we can at least plausibly argue to backwards ISPs that IPv6 is the default and the standard that everyone should reasonably be offering.
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!
Every company I have ever worked for in the US didn't use IPv6 and actually blocked it at the FW
The US has something like 80% of the world's IPv4 addresses, so they feel a lot less pressure to migrate.
I’ve worked for a company that was barely using its /16. I know several individuals, including myself, with personal /24s.
I recently released a /24 that I registered in 1992 and I hadn’t realized it was still mine.
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!
None of which are any help when connecting to someone who doesn't have those.
A /24 is currently worth between $5,000 and $9,000 USD. Did you get them a long time ago?
US is significantly above average in terms of adoption
I worked for a state government agency that had a public /16
Our freaky network admins rolled it out in our global corpo.
Was fun seeing IPv6 running for a few days without problems.
Great, then another 20 years and we can retire IPv4.
At home, I use an Android 16 Pixel phone, and a Chromebook, and I would suspect (but cannot prove) that 100% of my LAN outages can be blamed on the dual-stacking nature of IPv6 plus IPv4.
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 am rather infuriated that it's impossible to disable IPv4 on my devices, so does that make us even?
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!
Sounds like it's time to abandon it for something new and more stupid
But I still have to pay Hetzner separately to rent out an IPv4.
I am waiting for the flood of evangelist to explain:
- 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
I still do not support IPv6 on my servers and I think I will skip it and wait for IPv8:
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.
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.
IPv6 will never make it. Maybe IPv8 [0], which IPv6 should have actually looked like:
> 1.1.1.1.1.1.1.1
[0] https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
For observers, this draft was posted to HN earlier but quickly flagged and removed because the linked "IPv8" draft is absolute bunk.
See the removed thread for details: https://news.ycombinator.com/item?id=47788857
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.
> 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.
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%?
I'd say it's either because they're just having fun, or because they're dumb.
Nice idea. Always wondered why IPv6 went so ambitious with the addressing
One of the craziest aspects of IPv6 implementation is the reverse DNS lookups.
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.
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 .
Might as well go big. 24 extra bytes per packet is not that big deal. And having that much extra space means you can screw up design multiple times and still be able to reuse lot of infra. Also getting rid of idea that you are even trying to manually manage the address space eases many things.
But it's not human readable anymore, nor backwards compatible. The expectation was that the industry is reasonable, but it proved to be as hard as it would be to push breaking email v2 implementation.
If 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%.
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.