Website lacks IPv6 support

[tambry]

The website cannot be loaded over IPv6.

Since the website seems to use Fastly, I believe, per Fastly's IPv6 documentation, that fixing this should be as simple as changing the CNAME on bestpractices.coreinfrastructure.org from p.ssl.fastly.net to dualstack.p.shared.global.fastly.net.

PS. Emailing cii-badges-questions-owner@lists.coreinfrastructure.org, which is listed in the footer, doesn't work: 510 The group 'cii-badges-questions-owner' does not exist.

[david-a-wheeler]

Thanks, we will need to check it out. I'll create a separate issue for the mailing list problem.

[david-a-wheeler]

Unfortunately, reconfiguring fastly will not solve anything. Heroku does not support IPv6 at all, and we are running on Heroku. See here: https://help.heroku.com/I8L6RW01/does-heroku-support-ipv6

I submitted a help ticket to Heroku this morning asking for an estimated time of arrival for IPv6.

Typical clients using IPv6 should have no problems accessing the site, since they can use a transparent nat64 Gateway.

Sorry I didn't have a better answer for you at this time.

[tambry]

@david-a-wheeler Thanks for investigating this!

The backend server doesn't have to have IPv6 connectivity. In fact, Fastly doesn't even support IPv6 connections to origin servers. This means that reconfiguring the Fastly CNAME does fix it – e.g. curl https://dualstack.p.shared.global.fastly.net/en -H "Host:bestpractices.coreinfrastructure.org" -k -6 works fine (assuming your connection supports IPv6, of course). I forced bestpractices.coreinfrastructure.org to the IPv6 address from dualstack.p.shared.global.fastly.net and my browser is indeed loading the website over IPv6 without problems.

[david-a-wheeler]

Fair enough. It bothers me that in this configuration the CDN supports IPv6 while the backend does not, but I can't see any immediate problem with it.

Does anyone know of a downside to doing this?

[david-a-wheeler]

I can't see any reason to not do this, thanks for the tip. I've asked the Linux Foundation IT staff to change the entry for master.bestpractices.coreinfrastructure.org as a test. If it works as expected, we'll do it with the real site.

Thanks so much for the idea, and for tracking down how to do that easily!!

[tambry]

No problem, happy to help! 🙂
I also forgot to mention, that the added benefit of this will be HTTP/2 support.

[david-a-wheeler]

Wow, that's a big win from a DNS entry change. LF has the ticket but has not responded yet, I may need to nag them soon :-).

[david-a-wheeler]

I just got confirmation from Brendan OSullivan that this request is in the infrastructure team's queue. I only proposed the change to the test site master.bestpractices.coreinfrastructure.org to start with; if that works, we'll do it in production too.

[david-a-wheeler]

We've made the change on https://master.bestpractices.coreinfrastructure.org/en.

It seems to work flawlessly!! I can't praise this enough - we now directly support IPv6 (in addition to IPv4) and have a significant speed improvement.

I tested IPv6 connectivity using http://ipv6-test.com/validate.php and the site now works on IPv6 (while https://bestpractices.coreinfrastructure.org/en does not yet directly support IPv6, as expected).

I ran a speed test on master using https://www.webpagetest.org/. There's a significant speed improvement from the HTTPS/2 support. For example, median front page load time dropped to 0.784s (3 samples). Contrast that to staging, where I got a median time of 0.937s (3 samples), for a speedup = old_time/new_time = 0.937/0.784 = 1.2x!!!. That's because all the support materials load "simultaneously" resulting in a significant speed improvement.

It's rare that such a small configuration change yields such a significant improvement. I definitely plan to send a request to make this change for the real site. I'll send that request tomorrow unless someone finds a problem with this...!

@tambry - thanks for the dynamite suggestion!

[david-a-wheeler]

To be fair: These times are for first-ever load by a user. We aggressively cache things, so once a user sees a page, a lot doesn't need to be reloaded by the browser - so real-world times should be faster. But we certainly want good times on a cold cache, since we want to make a good first impression (and not drive away the impatient).

[david-a-wheeler]

Zero problems. I've sent a request to the Linux Foundation support team to make the change on the other sites.

[david-a-wheeler]

LF hasn't made the change yet. I've sent a whine / reminder.

[david-a-wheeler]

All done!! Thanks so much. I'm closing this issue.