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-...
Turns out we could not connect to Twilio's API which is IPv4 only.
An excellent reason to move away from Github, I find.
One more thing to troubleshoot at 3 am, one more thing to teach to a disinterested tier 1 support team, one more thing for Chrome to be weird about, hundreds more rules to manage in a hostile load balancer, logging tools that don't understand ipv6.
Turned it off. End customer asked why the site got a little slower (CGN) and when we can turn ipv6 back on. As far as I know it's still on the backlog.
Maybe we shouldn't even measure percentage adoption and instead just if github has finally adopted..
github.com doesn’t have an IPv6 address.
github.io does have an IPv6 address. Indeed, one workaround for getting rate limited when using a carrier NAT with github.com is to have a github.io page and pull data from github.io instead of github.com.
Edit: About a decade ago, all of my hosting had full IPv6 support, and I tried to move over to IPv6. However, there was an issue with Letsencrypt certs not validating over IPv6, so I made my web pages IPv4 only. Recently, I gave IPv6 a go again, and the cert issue has been fixed, so now my webpages finally have both IPv4 and IPv6 addresses.
Are you sure? I don't see it.
Name: github.io
Addresses: 185.199.111.153 185.199.110.153 185.199.108.153 185.199.109.153
You'll need to update your DNS server to include those as AAAA records.
Do providers like NextDNS or RethinkDNS allow these sorts of overrides?
> Do providers like NextDNS or RethinkDNS allow these sorts of overrides
Not on the resolver, but on the Android client (Rethink DNS + Firewall) we do (if enabled) manipulate DNS answers to implement an opportunistic 464xlat (over Kasper Dupont's public relays [0]).
[0] https://github.com/celzero/firestack/blob/c10c155464e0d4a81a...
That said, for their HTTP stack they use fastly (as far as I understand), which should make the shift moderately easier.
If you're not an expert in this area it's worth a read - I certainly learned a few things!
This is quite wrong, there'd DHCPv6-PD (prefix delegation) specifically designed to do this. Even more interestingly, it has recently been made part of IETF CPE requirements (RFC 9818 update to RFC 7084, July 2025).
EDIT: After reading Tailscale's article, I noticed that I overlooked our neverending dependence to NAT despite that IPv6 seems to eliminate it.
The linked post are also interesting reads:
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
Try going IPv6-only by disabling IPv4 on your computer as a test and notice that almost nothing works except Google. End users shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs doing that to prepare for the transition.
Also, notice how Android and iOS don't support turning off IPv4.
IMO with the right market conditions, IPv6 could spread really fast within 6-24 months. For example, most cloud providers are now charging for IPv4 addresses when IPv6 is free. Small changes like that push in the right direction.
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.
This was at the behest of mobile network. E.g., T-Mobile US has 140M subscribers, and moved to IPv6-only many years ago:
Is it plateauing? From the chart it doesn't look that way at all to me.
You could say it's flat between August 2025 and now, but it also was from Jun 2024-Feb 2025, or August 2023-March 2024. There's just a lot of noise to it -- lots of short plateaus or even dips followed by lots of sudden jumps. Indeed, it seems to have a bit of a yearly cycle to it, suggesting we're at the inflection point of another jump upwards.
So it still seems to be growing strongly to me. The rate of growth has slowed maybe the tiniest bit 2024-2026 compared 2018-2023, but I don't see it anywhere close to plateauing yet.
It's fine. IPv4 and IPv6 can be used at the same time. There's no hurry. Network interfaces support anything as long as both sides agree (nothing stopping you from building your own IPX network over MPLS).
People can move to IPv6 when the IPv4-as-real-estate speculators get out of control, and if IPv6 prevents IPv4 rental prices from going haywire, then it's served a useful purpose.
I saw a news article that said something about India considering moving to IPv6-only? That's going to be interesting if the rest of the world moves to IPv6 and the U.S. doesn't.
> End users shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs doing that to prepare for the transition.
100%
Source https://konecipv4.cz/en/
Yet I can still rent a VPS with IPv4 for $12/year from a wide variety of providers.
I'm with an ISP whose landline/fibre division does not have IPv6, but whose mobile division gives IPv6 to handsets.
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.
That makes sense. The majority of IPv6 deployment is mobile.
The next wave of adoption requires ISPs start offering residential IPv6. Once this happens, router manufacturers will innovate around the IPv6 offering as a differentiator, making it easy to deploy by end-users. IPv6 wifi APs will then become ubiqutious and so forth across other services. Has to start with ISPs.
The only arguments I've ever heard against ipv6 that made any sense are that:
1: it's hard to remember addresses, which is mayyyyybe valid for homelab enthusiast types, but for medium scale and up you ought to have a service that hands out per-machine hostnames, so the v6 address becomes merely an implementation detail that you can more or less ignore unless you're grepping logs. I have this on my home network with a whopping 15 devices, and it's easy.
and 2: with v6 you can't rely on NAT as an ersatz firewall because suddenly your printer that used to be fat dumb and happy listening on 192.168.1.42 is now accidentally globally-routable and North Korean haxors are printing black and white Kim Il Sung propaganda in your home office and using up all your toner. And while this example was clearly in jest there's a nugget of truth that if your IOT devices don't have globally-routable addresses they're a bit harder to attack, even though NAT isn't a substitute for a proper firewall.
But both of these are really only valid for DIY homelab enthusiast types. I honestly have no idea why other people resist ipv6.
Data centers and most physical devices made the jump pretty early (I don't recall a time where the VPS providers I used didn't allow for IPv6 and every device I've used has allowed IPv6 in the last 2 decades besides some retro handhelds), but domestic ISPs have been lagging behind. Mobile networks are switching en masse because of them just running into internal limits of IPv4.
Domestic ISPs don't have that pressure; unlike mobile networks (where 1 connection needing an IP = 1 device), they have an extra layer in place (1 connection needing an IP = 1 router and intranet), which significantly reduces that pressure.
The lifespan of domestic ISP provided hardware is also completely unbound by anything resembling a security patch cycle, cost amortization or value depreciation. If an ISP supplies a device, unless it fundamentally breaks to a point where it quite literally doesn't work anymore (basically hardware failure), it's going to be in place forever. It took over 10 years to kill WEP in favor of WPA on consumer grade hardware. To support IPv6, domestic ISP providers need to do a mass product recall for all their ancient tech and they don't want to do that, because there's no real pressure to do it.
IPv6 exists concurrently with IPv4, so it's easier for ISPs to make anyone wanting to host things pay extra for an IPv4 address (externalizing an ever increasing cost on sysadmins as the IP space runs out of addresses) rather than upgrade the underlying tech. The internet default for user facing stuff is still IPv4, not IPv6.
If you want to force IPv6 adoption, major sites basically need to stop routing over IPv4. Let's say Google becomes inaccessible over IPv4 - I guarantee you that within a year, ISPs will suddenly see a much greater shift towards IPv6.
We've never done this before at this scale. Maybe this is just how long it takes?
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.
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.
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.
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.
Just the obvious one: the people who designed IPv6 didn't design for backwards compatibility.
fd::1 is perfectly valid internal IPv6 address (along with fd::2 ... fd::n)
My home isp can't even do symmetrical gigabit, let alone ipv6...
There is nothing about IPv6 that prevents ISPs from filtering ports for all customers. They almost all actively filter at least port 25, 139 and 445 regardless of the actual transport. So I'm not sure "blocking service hosting" is the actual goal here.
The problem seems to be that all of the large and wealthy nations of the world have made the necessary huge investments into IPv6 while many of their smaller neighbors and outlying countries and islands have struggled to get any appreciable deployment.
It should be a UN and IMF priority to get IPv6 networks deployed in the rest of the world so we can finally start thinking about a global cutover.
You can see southeast Asia is pretty green on the map of the post.
Well, the curve has got to level-out at 100%.
You can trivially connect an iOS device via IPv6 only.
Yeah, I dont get why more ISPs don't offer carrier-grade NAT64 instead of the typical CGNAT
For most people, dual stack works fine. For mobile, the solution is 464XLAT that translates locally. There is MAP-E that does translation on gateway with IPv4 on local network.
For businesses, NAT64 makes more sense cause they can control what software is running. Even there, usually have to make IPv4 subnet for the old printers.
>it's in their best interest to ensure users can't host services without them.
They'll just keep blocking port 25. IPv6 won't change anything with regards to self hosting.
Almost every modern OS enables IPv6 privacy extensions, ie address randomization, by default.
The real question is, why are the crests so predictable? They're always on Saturdays; Sunday dips down a little below the crest, then Monday-Friday is down in the 45% range before the next Saturday jumps up to 50% again. (Fridays usually have a small rise, up to the 46-47% area).
My theory: mobile access rises on weekends. People are more often accessing Google services from their work computers Monday-Friday, but on Saturdays and Sundays most (not all) people are away from the office. Many of them will end up using smartphones rather than laptops for Internet access, for various reasons such as being outdoors. And since smartphones are nearly all using IPv6 these days, that means an uptick in IPv6 usage over the weekends.
Meanwhile corporate IT for business and education networks have less incentive to upgrade and typically lag behind in adoption in general.
Which means that if Japan, Korea, China, Vietnam, and other east Asian countries have a higher IPv6 adoption in residential vs business ISPs, then their Saturday-morning Internet access is likely part of the 1-2pp bump on Fridays in this chart.
P.S. Also, none of Japan, Korea, China, or Vietnam use daylight savings time (very sensible of them), so their UTC offsets are the same year-round. So their Saturday-morning contributions to the Friday chart will not vary from month to month due to timezone slippage, because they will never gain nor lose an hour relative to UTC. It might vary a little with actual seasons, as the sun rises later or earlier... but so many people use alarms to get up at 6:00 AM no matter what the sun is doing, rather than rising with daylight, so the amount of early-morning Internet access in winter months is not going to change significantly compared to summer when the sun rises earlier.
This is a tricky problem; providers don't have an easy way to correlate addresses or update policies pro-actively. And customers hate it when things suddenly break no matter how well you go about it.
[1] https://docs.github.com/en/enterprise-cloud@latest/organizat...
Unless your own organisation in the RR has the IP addresses assigned to you as Provider Independent resources, there just seems to be so many places where 'your' IP address could, albeit most likely accidentally, become not yours any more. And even then, just like domain names, stop renewing the registration and someone else will get them - I was that someone else recently...
[1] AS202858
Do you have a writeup of your setup somewhere or can you recommend some learning materials ?
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.
There's value in restricting access and reducing ones attack surface, if only to reduce noice in monitoring.
I've done a lot of IP filtering, it's what a lot of systems and services allow us to, so I'm curious what the IPv6 mechanism is
Yes, they do. It's called DNSSEC.
- In a cafe wifi, I had partial connectivity. For some reason my wifi interface had an ipv6 address but no ipv4 address. As a result, some sites worked just fine but github.com (which is, incredibly, ipv4-only) didn't
- I created a ipv6-only hetzner server (because it's 2026) but ended up giving up and bought a ipv6 address because lack of ipv4 access caused too many headaches. Docker didn't work with default settings (I had to switch to host networking) and package managers fail or just hang when there's no route to the host. All of which is hard to debug and gets in your way
I wish hosting providers would give you a local routed ipv4 on ipv6 servers with a default NAT server. It is not that expensive I move 10Gbps "easily" and they could charge for that traffic.
You mean like AWS NatGW https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gat...
One such stat is here:
> adoption ranging from 71% among the top 100 to 32% in the long tail
https://commoncrawl.org/blog/ipv6-adoption-across-the-top-10...
Getting full coverage on AWS (/GCP/Azure) and few other key services (GitHub...) would be significant here imho.
This will probably help adoption. On the one hand it will generate more IPv6 traffic. On the other hand it will expose more developers to IPv6; which will expose them to any lack of support for IPv6 within their own products.
[1]: https://9to5mac.com/2025/08/14/apples-first-mac-with-5g-cell...
I have owned several Dell, HP and Lenovo Laptops in the past 15 years and I have never had a cellular modem.
When Apple makes a change like that it impacts a lot of customers because they have way fewer skews.
Maybe they are finally coming, however the rumors are older then the iPhone. Example from 2008: https://pcr-online.biz/2008/11/03/3g-macbooks-on-the-way/
So you want laptops to cost <whatever the laptop costs> plus a measly 19.99/month for internet connectivity?
What's wrong with just tethering to my existing phone?
If you are single, have a phone contract, you would need some extra contract for a landline internet and wifi router because thats what a lot of people just do and now they can just add an esim and pay a little bit more.
Interesting that this sounds/feels a lot more right or useful than it did 5 years ago.
They will. One from facebook, one from google, one from tiktok, several from Palantir and its partners...
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.
EDIT: Apparently it's 77% https://pulse.internetsociety.org/en/news/2026/01/china-hits...
How would Google know what users have the potential for IPv6 if they are not using it?
Does anybody know why that might be the case? What's the story of IPv6 deployment in France?
https://www.arcep.fr/la-regulation/grands-dossiers-internet-...
This gives operators a benefit of the vertical control for the whole ecosystem - from top to the bottom, including intricate parts of protocols and routing. And France, in contrast to other countries, does not suck here too - operators usually do a good job of meticulously maintaining their assets.
My personal impression is that this is the result of several cultural factors:
1. Ingrained respect of privacy, private property, and a peace of heart as they call it. As a practical result of that, you do not get spammy messages and ads from operators, banks, etc. You may get some, like 3 or 4 discounts/offers in a year. Compare that to other countries where you can easily get 10s/100s messages like that in a single day. In other countries, instead of upgrading the infrastructure, people are busy with spamming each other.
2. The harsh oceanic environment with hurricanes and storms fosters an appreciation for reliability and functionality. It also encourages a certain frugality: every cent matters. As a result, people tend to develop a strong sensitivity to situations where form is prioritized over function, and such approaches are quickly dismissed as impractical. This gives a certain internal freedom of being able to see through things to determine what they are in the long run and not what they appear to be on the surface.
3. French people don't like to overwork outside of working hours. So choosing something like IPv6 over IPv4 seems like a natural forward-looking investment for the future where you can have less maintenance burden and thus you can devote more time to enjoying other things in life.
Having all those things combined, it's not hard to see why France chose IPv6. It's a natural choice there and it's imposed by survival.
P.S. I've spent some time in France, but was born in another country.
Has something changed for the worse?
When I lived in India, everything had IPv6 out of the box.
It's been discussed on the apnic blog and at meetings heaps
The story is that at the beginning I had IPv6, and a shared dynamic IPv4 behind a CGNAT, I asked for a rollback to a full duplex static IPv4 and for three years I had both a static personal IPv4 and an IPv6. A few weeks ago my router went down and since it went back up, I no longer have an IPv6 address. I called my ISP and they explained that I could either have IPv6 or a static IPv4, but not both, and that it's abnormal that I had both for so long… welp, it's sad to see IPv6 but getting it back is not worth abandoning my static IPv4 and going back to a dynamic shared IPv4.
A cheap VPS or one with spare bandwidth with > /64 that is properly routed (some providers do NDP for some reason) and a Wireguard tunnel would also get you a simple DIY solution.
I get the whole s-curve trend but if I squint at 2017, there is an inflection to slow the s-curve down.
Annoyingly, when setting up service with a fiber company in the last couple months, I explicitly asked about IPv6 connectivity and they said, "yes." Turns out "yes, but not in my region."
ABC, Always Be Closing.
amazon.com needs to get with the program. Still IPv4 only.
The real migration challenges are in the server side/consumer home internet space which I'm not sure if there are clear stats around the adoption there.
I think IPV6 is a great example of over engineering, trying to do too much in one iteration. In an ideal scenario this could work, but in the context of large scale change with no single responsible party, it usually doesn't work well.
On the consumer home internet side, consumer ISPs are slowly one by one lighting up IPv6, and it just works since consumer routers are mostly auto-configure (often literally controlled by the ISP). Mobile is largely IPv6 already.
The biggest challenge is in corporate/academic/medium-size business networks where they have lots of obscure subnets and firewall rules and old software and hardware running a critical task under a dusty table somewhere.
> IPv6 traffic crosses the 50% mark
Graph description:
> The graph shows the percentage of users that access Google over IPv6
There are reasons to expect both much more and much less traffic per user on IPv6 compared to IPv4...
Personal web server running dual stack since early 2010s currently sees 18-20% v6 traffic. When split by type, counting only mobile users it reaches 30% at peak.
Bot/crawler traffic is ironically 100% v4.
Meanwhile: enabled h3 in september last year for the fun of it, instantly at >40% traffic by request count, passing 50% since the beginning of the year, h2 accounting almost all the remaining traffic and plain ssl/http requests <1% being just bots.
- I don't want to have a permanent global unchanged ipv6 as in id of my traffic.
- IPv6 privacy extensions would change that but then I can not reach my two devices I do want to reach from outside anymore as my access router only supports DynDNS for its own address and no NAT in IPv6
So what would be the correct setup with IPv6 when using privacy extensions?
I don't see any benefit in allowing IPv6 traffic or using IPv6, but a couple of new problems coming up with it.
The only way this will change is by increasing pressure on the resource of IPv4 networks. It was a few years ago that AWS broke the news to me that I'd be paying for IPv4 addresses but IPv6 would remain free. If enough services are forced, financially, to abandon an IPv4 presence, then their clients would be likewise forced to adopt IPv6 in order to retain connectivity.
But with the ubiquity of CGNAT and other technologies, it seems unrealistic that IPv4 will become so rare that it becomes prohibitively expensive, or must be widely abandoned. So that availability of the legacy protocol will inhibit widespread adoption and transitions to IPv6.
Just log onto AOL and type in keyword "WALMART" and save! It's friendly and safe.
But in reality at the moment there will probably always be at least one thing that only works with v4 a lot of the time.
Incentives are misaligned as well - it saves you money as the EC2 instance user, but the owner of the website you're trying to access has to support v4 anyway so they don't have a big incentive to change anything
The most difficult parts for a homelab in my experience is getting Docker to play nicely. All of the other stuff sort of just works these days. Even things like using DHCPv6 prefix delegation to obtain a routable subnet is almost trivial with how well-supported the protocol is with modern networking software.
It affects anything where latency matters, e.g. from Facebook: "We’ve observed that accessing Facebook can be 10-15 percent faster over IPv6." (https://engineering.fb.com/2015/09/14/networking-traffic/ipv...).
As of now, there is no way to have a 100% internal ipv6. Many of the services, including CloudSQL or the connection between external and internal load balancers do not support ipv6, even when the external load balancer support ipv6 forwarding rules at the front end.
This means that careful internal ipv4 allocations still matter.
But the one interface that touches the internet can use v6: the one with a functionally infinite address space.
What I am building won’t exhaust that, but I hear some customers are blowing through even that.
PSC has a builtin NAT. That also helps stitch things together.
… or we can have ipv6.
At what level did you need to pay for IPv4 addresses in this stack? You should have been able to make this work with a private IPv4 space, have the ECS services be dual-stack and be on both the v6 network and the v4 network to talk to the database server, have the ALB be v6, and then have Cloudfront be v6. If you wanted, you could also just ignore v6 for the ECS services and have them just live in that same v4 subnet entirely.
I could be wrong (and please tell me what I'm missing) but you shouldn't have had to pay for IPv4 in this case. I do just wish RDS (and so much else) would just support IPv6 though, you shouldn't need to have a bunch of extra subnets just to talk to your database.
It sounds to me like its a tool which is available to be used when needed and when no better workarounds exist, and it is slowly but surely being adopted as needed.
For a long time, there really was next to no progress. Between the introduction in 1996 and about 2011, there was very little adoption. And since 2012 when pushing really started, we're at about 50% globally, with large variance by country and network type. 15 years between creation and real deployment seems like a lot, and 15 years of deployment getting to 50% also seems likes a lot.
But wikipedia says touch tone dialing was first offered to consumers in the 1960s and didn't become majority until the 1980s, so maybe 30 years isn't that slow.
That seems to be a promising approach.
They use 464XLAT, basically NAT64/DNS64 with some extra cooperation on the OS’s part for backwards compatibility with apps that hard-code IPv4. You get only a v6 address, and your OS basically synthesizes an v4 network on your device in cooperation with their NAT64 router. But all the bytes going from your device through to their towers are ipv6. Talking to a v4-only website uses carrier-grade NAT64 when leaving the t-mobile network.
To the local network, it looks like there's native IPv4, but it's translated to IPv6 by the gateway, and sent to the "nearest" NAT64 PoP to be translated back and sent along its merry way.
The author of the RFC is the author of the slides.
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.
Basically, all crawlers.
Is it because they have more carrier NAT?
In Denmark I can get cheap 1 / 1 Gbit/s fiber, but still no ipv6 :(
0/10 in Latvia with a local ISP, fun times.
google published the latest data only yesterday, hence the delay.
despite the smoothbrain naysayers:
https://circleid.com/posts/20190529_digging_into_ipv6_traffi...
finally, the end of the dark tunnel of NAT is in sight, and the internet will be free once more
Personally I think the design of IPv6 offers very little benefit; supposedly the Dept of Defense/Dept of War holds some 175 million IPv4 addresses, with other companies also holding large allocations - that should have been addressed 25-30 years ago as an administrative matter.
The $1 to $5 a month to have excellent, reliable connectivity (that no residential connection provides), DDoS protection, and isn't tied to my home IP outweighs any home hosting benefit in my experience.
...but that's based on pre-IANA-runout rates, though, and doesn't account for the pent-up backpressure of demand. So probably a lot less, in reality.
Not even remotely worth the effort, even if there were a legal pretext for "reclaiming" IPv4 space (there isn't; there's already precedent denying it).
Cloud computing doesn't mitigate IPv4 issues, it just moves it around. The big cloud providers buy up any IPv4 space they can, leaving less for everyone else. The difference is that they then get to collect rent, by the hour, on any IPs their customers use.
Load balancers...yeah, actually that is a valid approach to reduce IPv4 use, assuming you mean the "reverse proxy" variety of load balancer. Cloudflare's proxy service is doing exactly this, on a pretty huge scale. (CLoudflare can then send the traffic on to an IPv6-only server, regardless of the client's protocol.) The downside is, like cloud, consolidating a lot of infrastructure into the hands of a small number of companies.
Does it mean we better put our chips on IPv8?
However, in most cases, internet-drafts are just that - drafts. They are usually requests for comment (ironically enough) on the author's idea. Someone had an idea and put it out there to see what other people think. Sometimes they don't even get to that stage but die immediately upon being uploaded as the author realizes they are silly.
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.
But I wouldn't be surpised if we start seeing self-hosted minecraft or factorio servers with ipv6 only.
There might be a child behind the NAT, thus IPv6 requirement.
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.
like say
* https://1.1.1.1/cdn-cgi/trace
vs
* https://one.one.one.one/cdn-cgi/trace
When ipv6 threads like this come up, someone eventually mentions T-Mobile is completely IPv6 now but they must have IPv4 tunnels because I have IPv4 turned off on my modem/router and can still visit both those URLS
Basically to reach any v4-only resource you need a translator, typically NAT64. This maps the entirety of the v4 internet into a /96 of IPv6 space (last 32 bits).
DNS64 is one way to access this, which will return a result for 'amazon.com' like:
A = `98.87.170.74` AAAA = `64:ff9b::6257:aa4a`
Combining this with CLAT lets you punch in an IPv4 literal like 1.1.1.1 and your phone/computer will do this conversion from v4 -> v6 locally without you changing anything. So 1.1.1.1 would become `64:ff9b::101:101` on-device - and that's actually what your mobile ISP sees.
T-Mobile and most mobile operators use 464XLAT - which has been in Android & iOS for at least 8-10 years now if memory serves.
It lets you visit 1.1.1.1 because your phone is converting it automatically to T-Mobile's NAT64 prefix (CLAT - customer side), it traverses their network v6-only, and then it ends up at their translator (PLAT - provider side) and becomes normal NAT'ed v4 traffic out to CloudFlare.
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!
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.
If you change the address format even the tiniest amount, if you add one single additional bit, your new protocol is already completely incompatible with all existing IPv4 software and equipment.
Say if you have 10% of market share or x million monthly users you must support IPv6 in say 5 years. If not you are fined say 2% revenue per year until you do...
I think most of us know that their design failure here was a lack of backwards compatibility. But at least it's getting adopted.
But at least a reasonable facsimile eventually came out with NAT64.
(You can also do NAT46, but it requires one IPv4 address for every IPv6 destination you want to be reachable from the IPv4 Internet, so it doesn't scale very well.)
Was fun seeing IPv6 running for a few days without problems.
What's going on in Spain?
[1] https://radar.cloudflare.com/adoption-and-usage#ipv4-vs-ipv6
Chris Siebenmann has written extensively on IPv6: https://utcc.utoronto.ca/~cks/space/?search=ipv6
Google has some weird way of asserting connectivity, and I suspect that when connectivity on one protocol is lost, it is impossible to maintain or establish connectivity through the other one (IPv6) even if it is available upstream.
I am rather infuriated with the status quo at this point, because it is impossible to disable IPv6 on my devices and it is also impossible for my ISP to disable IPv6 on my LAN or on the CPE router which they own and control.
Due to chronic WiFi issues I was eventually forced to place my ISP router into Bridge mode permanently, and I use a 3rd party Netgear which I own, and does not have the same WiFi issues, and where IPv6 is optional (and often fails, because its implementation is buggy and glitchy for no reason.)
I recently purchased a brand-new LaserJet printer, and since it needs nothing to do with the Internet or a WAN outside my home, I thought it'd be great to simply disable IPv4 and stop doing the DHCP dance.
Well it immediately fell off the net completely. I couldn't figure out how to expose its IPv6 address or contact its management interface.
Hypothetically, Bonjour and mDNS should make this a no-brainer. Hypothetically, disabling IPv4 shouldn't even prevent it from connecting to the Internet. But I was ultimately forced to factory-reset it.
IPv6-only LAN makes a lot of sense for most people, and perhaps reduces attack surface a little. If you have the means, I highly recommend setting it up!
- IPv6 proponents are the only ones who know that NAT is not a firewall, and
- Everyone in the world would love IPv6 if they just didn't hate learning new things
https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
Avoiding a dual-stack and making IPv4 a part of whatever superseeds it seems like the right choice to me.
IPv6 always seemed to me like throwing away all existing telephone numbers, just to support longer numbers.
::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)
> 1.1.1.1.1.1.1.1
[0] https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
See the removed thread for details: https://news.ycombinator.com/item?id=47788857
Edited: In hindsight I notice that "hit it out of the park" is the wrong sport metaphor for FIFA, but I stand by it anyway.
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.
Switches and routers have a little thing called TCAM memory, the premise behind it is that it allows you to single-cycle O(1) lookup any ips destination. Usually to replicate it you could have a 4gb*2 preallocated contiguous buffer, but that's not something that is wildly supported or used and this completely breaks down when you expand to the IPv6 range.
The problem lies in that in a lot of cases TCAM can no longer hold the entire IPv4 routing table and now if you introduce IPv6 you are expected to handle double the routes which degrades switching performance as more active routes have to be evicted and fall back to software routing.
Routes are not the only thing that take up TCAM memory: the firewall rules, internal routing, vlans, everything becomes double and TCAM memory cannot be dynamically adjusted at runtime to allocate space so what happens is that you need to sacrifice IPv4 space in TCAM permenantly even if nobody is using IPv6.
This is where it gets worse: if you have ever attempted to use IPv6 you will notice that is significantly slower than IPv4 and that is because most ISPs simply opted to use software routing for IPv6 which coupled with 4-10 hops is nearly double the latency in some cases (0.5ms to 1ms) while having throttled bandwidth to not overload the CPU.
That's why network engineers will continue to refuse to (properly) support IPv6. If I had to guess the "properly" supported IPv6 percentage is less than 10%.
The link in the OP shows that IPv6 typically gives users 10-20ms lower latency. This confers with my experience since IPv4 is typically going through some poor overloaded CGNAT box.