UPDATE 2017-07-31: The information in this post is no longer accurate; GitHub Pages and Fastly now do support IPv6.

The problem

As I noted in my previous post, GitHub Pages (just like GitHub itself) does not support IPv6. This is because GitHub Pages’ CDN provider, Fastly, doesn’t support it:

$ host toreanderson.github.io
toreanderson.github.io is an alias for github.map.fastly.net.
github.map.fastly.net has address

I find this very disappointing. Fastly was founded in 2011, so they are a rather new CDN. Their platform is built on top of Varnish, which has to the best of my knowledge supported IPv6 even before Fastly was founded, so it’s not like their lack of IPv6 could be explained by having legacy and difficult to upgrade IPv4-only internal infrastructure. I find it rather ironic that a provider calling themselves Fastly fails to support the protocol that was recently reported by Facebook to yield 30-40% faster time-to-last-byte web page load times than IPv4. So in case anyone from Fastly is reading this, I suggest you either a) start supporting IPv6 ASAP, or failing that, b) rename your CDN platform to something more appropriate, like Slowly.

The workaround

My employer is kind enough to provide me with a virtual machine I can use for personal purposes. This server runs Linux, Ubuntu Trusty LTS to be specific. It is of course available over both IPv6 as well as IPv4 (using SIIT-DC), so the idea here is to use it to provide a dual-stacked façade, thus concealing the fact that the GitHub Pages service doesn’t support IPv6.

As this server is already hosting my sorry excuse for a home page, it had already the Apache web server software installed. Apache comes with mod_proxy, which is perfectly suited for what I want to do.

The first order of business is to ensure the mod_proxy module is loaded. On Ubuntu, this is easiest done using the a2enmod utility:

# a2enmod proxy_http
Considering dependency proxy for proxy_http:
Enabling module proxy.
Enabling module proxy_http.
To activate the new configuration, you need to run:
  service apache2 restart
# service apache2 restart
 * Restarting web server apache2                              [ OK ]

The next order of business is to create a VirtualHost definition that uses mod_proxy to forward all incoming HTTP requests to GitHub Pages. I did this by creating a new file /etc/apache2/sites-enabled/http_blog.fud.no.conf with the contents below, before reloading the configuration with the command apache2ctl graceful.

<VirtualHost *:80>
	ServerName blog.toreanderson.no
	ServerAlias blog.fud.no
	ProxyPass "/" "http://toreanderson.github.io/"
	ProxyPassReverse "/" "http://toreanderson.github.io/"

The ProxyPass directive makes incoming HTTP requests from clients be forwarded to http://toreanderson.github.io/. ProxyPassReverse ensures that any HTTP headers containing the string http://toreanderson.github.io/ in the server response from GitHub Pages will be changed back to http://blog.toreanderson.no/ (or http://blog.fud.no/). I’m not exactly sure if ProxyPassReverse is really needed for GitHub Pages, but it doesn’t hurt to have it in the configuration anyway.

The final order of business is to ensure that the two hostnames mentioned in the ServerName and ServerAlias directives exist in DNS and are pointing to the server. I did this by adding simply adding IN CNAME records that points to an already existing hostname with IPv4 IN A and IPv6 IN AAAA records:

$ host -t CNAME blog.fud.no.
blog.fud.no is an alias for fud.no.
$ host -t CNAME blog.toreanderson.no.
blog.toreanderson.no is an alias for fud.no.
$ host -t A fud.no.
fud.no has address
$ host -t AAAA fud.no.
fud.no has IPv6 address 2a02:c0:1001:100::145

Another thing worth mentioning here: By using my own domain names, I am also making sure that my blog’s URL is secured using DNSSEC, another important piece of Internet technology that GitHub Pages and Fastly currently neglect to support.


With the help of Apache mod_proxy, http://blog.toreanderson.no is now available over both IPv4 and IPv6. I am therefore now comfortable with letting people know that this blog actually exists. While this workaround is far from ideal from a technical point of view, it is better than the alternative - having to wait an indeterminate amount of time for Fastly to get around to dual-stacking their CDN.