> GitHub seems to be enabling IPv6 for GitHub Pages
This is extremely misleading at best. As far as I can tell from reading this stuff, the only thing that has changed recently is that github-repository-files.githubusercontent.com has started serving an AAAA record. (Perhaps other subdomains as well, but that’s the only one reported and it’s definitely not all.) That’s nothing to do with GitHub Pages. GitHub Pages has unofficially supported IPv6 for more than three years apart from the DNS records, so if you’re brave or foolish enough you could add AAAA records on a custom domain that’s handled by GitHub Pages.
Don't underestimate the amount of backend plumbing necessary to enable this kind of thing at scale, even if it's "just" a CDN feature flag (analytics pipeline, authorization, rate limiting, and so much more...)
Fun fact: I mulled over whether to write “an AAAA record” or “a AAAA record”. I ended up deciding to go with “an AAAA record” even though I would read it “a quadruple A record” which is physically easier to say than “an A A A A record”.
In Australia I can’t recall hearing anything other than “double you double you double you”. (But if we could do a bit of language reform, shortening w, 7 and 0 each to a single syllable like all the other letters and digits would be the first thing I’d do.) But then, “double you” flows in sequence a bit better than “ay”.
Probably because they wanted to keep them short. AAAA records are so named because it is the ipv6 equivalent of an A record, and ipv6 addresses are four times as long as ipv4 addresses. I agree it is pretty terrible though.
Apologies for the silly question, but what’s so difficult in adopting v6? Cloud providers spend billions on new hardware every year, I’m honestly surprised at reading that some of them don’t fully support it yet? Is there some specific technical issue preventing them from mass adoption?
It's a chicken and egg problem - websites, etc don't want to enable IPv6 because clients have broken IPv6 implementations and that causes delays and issues, and clients have broken IPv6 implementations because the internet providers don't care to fix it because nobody uses it.
(Many computers THINK they have IPv6 connectivity when they do NOT and so if they see an AAAA record and try to connect to it, it can cause a delay while that fails. Most browsers are better at this now (they will try to connect to both and show whichever answers faster), but not all network things are browsers.)
In the past, one of the factors was SEO. A few years ago (in 2018, to be precise), the company I worked for tried enabling IPv6 on some of our websites, and observed some drop in Google ranking, that recovered when the IPv6 experiment was undone.
Sorry but this is just too anecdotal for me. There are so many factors that go into Google rankings and Google itself makes it pretty easy to discover any crawling or indexing issues on a website that it seems the root cause of the issue should have been discovered (if it was due to a crawl/index) and I doubt it was a properly working ipv6 setup (something broke somewhere on your company's end is what I'm getting at). Cloudflare uses ipv6 and I doubt all their customers websites were being penalized by Google
Well, it was just a stock Hetzner dedicated server. All that was added/removed is a DNS AAAA record pointing to the server's IPv6 address. We used IPv6 before in order to access LXC containers hosted on that server. If THAT counts as a broken setup (which I doubt, see below), then, sorry, I don't see how we could do better.
I have personally checked the result from my then-home connection (unfortunately, through he.net tunnel) and it worked, and it was properly logged by Apache. The CEO had native IPv6 on the phone, and it also worked for him, and, according to Apache logs, IPv6 was also used. I have also checked that the site was still accessible over IPv4. So I indeed don't know what went wrong.
On the other hand, I did not have access to Google webmaster console and had to trust the CEO that the SEO problem exists. It might have been a coincidence. And again, the SEO problem was in 2018, and is likely irrelevant today even if it really existed back then, that's why I said "in the past".
Having access to GSC is really a must for stuff like this. You can see exactly how Google sees your page and it's status (error fetching, not indexed, different canonical, etc etc)
Too bad I often have to disable IPv6 because my ISP suddenly decides to stop routing it from time to time.
This is Comcast, so arguing with them doesn't get me anywhere, all I get is "Thanks for expressing your concern." "Rest assured that I will solve all your problems." from the support dude in some random call/chat center.
Sort of. There needs to be more intelligence at the client end though. I have a fairly decent IPv6 link but it can still fail in strange ways, that does not mirror the IPv4 link. Then again the IPv4 link has moved in mysterious ways from time to time.
Happy Eyeballs isn't quite fully prevalent and it hasn't seen all failure modes yet nor how to deal with them.
Internets is a really hard problem. For starters: define "connected". My wife will sometimes suggest that our internet connection is not working - she implies that her laptop (Arch Linux - obvs) is completely broken. What is really happening is that Mr Zuckerberg's thang has wandered off for a break and a smoko.
This morning it was our mail server. Hit the wifi kill switch by accident then internet will not work.
Depends. Anecdotal evidence: Most "normal user" software handles it fine. (Chrome and Apple Mail on my Mac, Android apps, etc.)
With terminal apps I use as a developer, it's more of a crapshoot. curl and SSH work fine. I've seen others that don't.
Notably, Node.js's socket libraries can't fall back to IPv4 at all, even after the v6 connection times out. Node's DNS library actually overrides the default system behavior to prefer v4 over v6, probably for this reason. (This can be changed globally within a particular program, or on a per-lookup basis, but preferring v6 will allegedly become the default in an upcoming release.)
I've unfortunately had much experience with this due to major bugs in Comcast's modems.
Same here. I had enough random problems when IPv6 was enabled and got tired of troubleshooting things. Just disabled it and will enable again in a few years. Hopefully things will be better.
It should be as simple as not being allowed to advertise a service as providing Internet unless it provides 100% native, full-featured IPv6.
Imagine if in 2001 some company tried to sell an "Internet service" that didn't provide IPv4, or only provided RFC1918 addresses, or didn't allow something as trivial as non-NAT routing of IPv4, even as an option. They'd be sued for false advertising, and rightly so.
Meanwhile, in 2021 tier-1 cloud providers like Azure have an absolute shitshow of partial IPv6 support, yet they get away with advertising that they provide "Internet connectivity". They provide only private ranges, and force NAT for all IPv6 traffic. The vast majority of their services are IPv4 only, so enabling IPv6 is mostly pointless. Worse, if you do enable IPv6 on their virtual networks, this then disables unrelated IPv4 functionality. It's madness.
>as simple as not being allowed to advertise a service as providing Internet
so then they'll advertise "network connection service" or something instead of internet service. people are pretty willing to accept when marketing makes up new words to avoid regulation, as long as the they are still getting a product that meets their needs. if consumers don't care about ipv6, no amount of renaming things is going to change that.
if you really want to drive ipv6 adoption, find a way to get free porn on it.
Microsoft voluntarily admits the following limitations on the page you linked:
• ExpressRoute gateways CAN be used for IPv4-only traffic in a VNET with IPv6 enabled. Support for IPv6 traffic is on our roadmap.
• VPN gateways CANNOT be used in a VNET with IPv6 enabled, either directly or peered with "UseRemoteGateway".
• The Azure platform (AKS, etc.) does not support IPv6 communication for Containers.
• IPv6-only Virtual Machines or Virtual Machines Scale Sets are not supported, each NIC must include at least one IPv4 IP configuration.
• When adding IPv6 to existing IPv4 deployments, IPv6 ranges can not be added to a VNET with existing resource navigation links.
• Forward DNS for IPv6 is supported for Azure public DNS today but Reverse DNS is not yet supported.
That doesn't even being to cover it! There's all sorts of other fun limitations scattered all over the place, you'd have to spend weeks scraping them together into a pile of shame.
1) Further entrenches the big players by making it harder to enter the market.
2) Making decisions for companies with no understanding of the costs is a bad strategy. If it was easy to support they'd just do it.
3) It is still arguable if IPv6 is even necessary. I think yes, but the situation isn't clear enough to legislate. Maybe some better solution will be found when the pressure is on.
> Further entrenches the big players by making it harder to enter the market.
On the contrary, I think dual stack from the ground up is cheap. Big corps are reluctant to switch because it means paying the "interest" in their tech debt.
> Making decisions for companies with no understanding of the costs is a bad strategy. If it was easy to support they'd just do it.
Who said we don't understand the costs? You are underestimating the stringiness of the bean counters that got us into this coordination failure. You are also assuming the aggregate demand for abstract public goods like IPv6 availability could ever be sufficient in already-developed countries for market-based solutions to work.
> It is still arguable if IPv6 is even necessary. I think yes, but the situation isn't clear enough to legislate. Maybe some better solution will be found when the pressure is on.
IPv6 is necessary for a bunch of decentralization to work better. Thks isn't good for profits (no, "crypto" isn't the decentralization I have in mind), but it is good for society. This is clear to me, but the exact sort of abstract thing which is hard to put political weight behind.
I'm surprised they didn't have it until now. Every cloud provider's load balancer and CDN has had IPv6 for a while. That they don't have it for the site or SSH is less surprising, but GitHub Pages is static content.
Maybe AWS, Azure, and GCP, but not places like Digital Ocean. IPv6 is still very niche, and it's suffering from that effect where it being very niche keeps it very niche. Nobody wants to be an early adopter (and momentum seems to be dying), and the result is that there's no adoption.
I think we've been trying to make IPv6 happen since 1998, and ... it's not happening.
It's absolutely glacial, but IPv6 adoption has been steadily rising over the last 8 or so years. Unfortunately the increase has been linear rather than exponential.
That is, according to Google's stats of clients accessing their properties. Not a perfect snapshot of worldwide Internet users, but a pretty decent one. https://www.google.com/intl/en/ipv6/statistics.html
Even a linear growth is fine. By 2030 there will be pretty much 100% adoption at this pace. There may even be a tipping point when places like India are so stretched for v4 addresses and v6 is so widespread where local sites go v6 only which triggers a much faster adoption rate on the consumer side.
Linode fully supports IPv6 and it works quite nicely.
I used to have a Hurricane Electric IPv6 tunnel but I've abandoned mine as my small rural cable provider turned IPv6 on quietly (all you have to do is have your router ask for a /48).
I recently moved to a new city and signed up with a medium-sized regional ISP. I was disappointed when I set up my router and saw I didn’t have an IPv6 address. I searched the web for “${MY_ISP} IPv6” and found their FAQ page with the following entry (paraphrased):
> Q: Does $ISP support IPv6?
> A: Yes! $ISP supports IPv6. For instructions on configuring your router….
I spent an hour trying and failing to get it working. Frustrated that I’d just invested so much time and not wanting it to be a total waste, I called customer service and, as you can imagine, I had an extremely difficult time trying to convince anyone that I didn’t need to turn my router off and on again.
Over the span of a few weeks, I tried calling twice and using their live chat once to ask about IPv6. At this point it was a matter of principle, if their website said they supported it I was going to hold them to it. Each time I communicated with them, I got a different answer as to why IPv6 wasn’t working: one person told me they do support it but not in my area, another person told me they don’t support it at all, and the third person told me that they did “offer” it but did not “support” it. Each time I read them the FAQ page entry which explicitly said they do support it with no conditions. By their responses, it was obvious that they thought I was a weirdo, but I just really wanted them to give me the IPv6 that they’d promised.
After all of this failed, I tried one last thing: I submitted a complaint with the FCC about misleading advertising. Before you call me a Karen, I wasn’t trying to get anyone in trouble or to get special treatment or whatever. I just wanted them to provide the services they promised. I specifically mentioned that I had nothing but positive experiences with the staff that I’d interacted with and that my issue was just a technical/marketing one. Well, whaddya know, I got a lovely email within 6 hours thanking me for bringing the issue to their attention, saying that they had identified a configuration issue in my local area, and that they had scheduled maintenance for the next day to fix it. And within 24 hours I (and presumably hundreds of my neighbors) had working IPv6!
Was it worth the time and effort? For IPv6, no. But for the satisfaction of getting a corporation to follow through with their word? Also, no. But for the ability to write this comment? Well, no. And I suspect this is how just about everyone who has ever spent more than an hour banging their head against a wall trying to get IPv6 working has felt in the end. Like, wow, I can now look at literally the same exact cat pictures as I did before but now I have access to 79 octillion times as many addresses, yay?
That’s my best guess as to why we’re still in the dark ages of 2^32 internet addresses.
Side note, their FAQ page has been changed to say “IPv6 is supported in most areas”. I’m at least proud to know I’m the reason for a few more weasel words on a corporate marketing website. Success.
The world owes you a debt of gratitude. I've often thought about siccing the FTC on companies, but you pulled it off. How long did it take between your report and the company responding?
It was really fast like I said, under 6 hours until I got a response. I submitted it to the fcc in the morning and had the email by the afternoon, and had IPv6 by the next day at 10am. Goes to show what you can accomplish if you go up the chain, I could have probably called their tech support every day for the next 5 years and gotten nowhere.
There are more and more networks that are native IPv6. And IPv4 connectivity is done with double NAT, NAT64, 464XLAT and other heroics.
The faster we can allow native IPv6 end-to-end, the faster we can get rid of the complex IPv4 compatibility technologies and simplify the entire internet. At some point, you may start to see networks with no v4 connectivity whatsoever (maybe they already exist, but I can't imagine them being useful), so this allows those users to reach github pages.
To directly answer your question, it's investment and maintenance in infrastructure, not for user features.
It's nothing critical but some ISPs use multiple layers of hacks to work IPv4 and certain types of networking become very unreliable over it. Things like long running connections will be dropped because the ISP routers do not maintain the NAT mapping forever.
For github pages its probably not going to make a huge difference but for things like SSH or file transfers it could be an issue. For things like video game servers or home servers you just flat out can not work them on v4 if your ISP uses CG-NAT.
This is extremely misleading at best. As far as I can tell from reading this stuff, the only thing that has changed recently is that github-repository-files.githubusercontent.com has started serving an AAAA record. (Perhaps other subdomains as well, but that’s the only one reported and it’s definitely not all.) That’s nothing to do with GitHub Pages. GitHub Pages has unofficially supported IPv6 for more than three years apart from the DNS records, so if you’re brave or foolish enough you could add AAAA records on a custom domain that’s handled by GitHub Pages.