Sep 1, 2018 Tags: meta
This post is at least a year old.
As of this morning, both my main site and this blog
now support IPv6 connections! That means that you should be able to connect through each and every
single one of these curl
permutations:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
#############
# main site #
#############
# IPv4, HTTP -> HTTPS redirection
$ curl -L http://yossarian.net
# IPv4, CNAME redirection, HTTP -> HTTPS redirection
$ curl -L http://www.yossarian.net
# IPv4, HTTPS
$ curl https://yossarian.net
# IPv4, CNAME redirection, HTTPS
$ curl https://www.yossarian.net
# IPv6, HTTP -> HTTPS redirection
$ curl -6 -L http://yossarian.net
# IPv6, CNAME redirection, HTTP -> HTTPS redirection
$ curl -6 -L http://www.yossarian.net
# IPv6, HTTPS
$ curl -6 https://yossarian.net
# IPv6, CNAME redirection, HTTPS
$ curl -6 https://www.yossarian.net
########
# blog #
########
# IPv4, HTTP -> HTTPS redirection
$ curl -L http://blog.yossarian.net
# IPv4, CNAME redirection, HTTP -> HTTPS redirection
$ curl -L http://www.blog.yossarian.net
# IPv4, HTTPS
$ curl https://blog.yossarian.net
# IPv4, CNAME redirection, HTTPS
$ curl https://www.blog.yossarian.net
# IPv6, HTTP -> HTTPS redirection
$ curl -6 -L http://blog.yossarian.net
# IPv6, CNAME redirection, HTTP -> HTTPS redirection
$ curl -6 -L http://www.blog.yossarian.net
# IPv6, HTTPS
$ curl -6 https://blog.yossarian.net
# IPv6, CNAME redirection, HTTPS
$ curl -6 https://www.blog.yossarian.net
That’s a lot of options!
A huge thank you to the reader who emailed me about the lack of IPv6 support and helped me debug the setup — please let me know if you’d like a shoutout for the help you gave me.
Here are the changes I had to make:
I had to enable IPv6 on the Droplet that hosts my sites. That part was pretty easy.
I then had to edit my /etc/network/interfaces
to configure the IPv6 link:
1
2
3
4
5
6
iface eth0 inet6 static
address 2604:a880:800:10::2d:5001
netmask 64
gateway 2604:a880:800:10::1
autoconf 0
dns-nameservers 2001:4860:4860::8844 2001:4860:4860::8888 209.244.0.3
(DigitalOcean provides a udev
rule that enables old-style interface names like eth0
).
I ran into some issues with the link refusing to come back up. An ip addr flush
solved the
problem:
1
$ sudo ip addr flush dev eth0
…and then kicked the service over:
1
$ sudo service networking restart
Next, I added two new AAAA records:
1
2
@ AAAA 2604:a880:800:10::2d:5001
blog AAAA 2604:a880:800:10::2d:5001
Finally, I had to configure Nginx to accept IPv6 connections. There are quite a few resources online that make this look as simple as adding two new listening rules:
1
2
listen [::]:443;
listen [::]:80;
However, my rats’ nest of server blocks
(one each for yossarian.net and blog.yossarian.net, plus one each for CertBot’s HTTP -> HTTPS
301 redirects, plus a default_server
) made things go a little haywire — adding IPv6
listeners to each of the blocks caused random SSL failures and other bizarre behavior. I still don’t
know what exactly happened there, but my guess is that it had something to do with
SNI.
Ultimately, the following appears to have worked (simplified from my real configuration):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# Main site, listening only on 443 (both IPv4 and IPv6)
server {
server_name yossarian.net www.yossarian.net;
listen 443 ssl;
listen [::]:443 ssl;
}
# Blog, listening only on 443 (both IPv4 and IPv6)
server {
server_name blog.yossarian.net www.blog.yossarian.net;
listen 443 ssl;
listen [::]:443 ssl;
}
# Default handler, listening only on 80 (both IPv4 and IPv6) for redirects.
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
server_name _;
return 301 https://$host$request_uri;
}
Please let me know if you run into any issues!