Since we're slowly coming up to 25 years of having IPv6, but still not actually having IPv6, I tried making a seperate local network that only has v6 access. In theory quite a few of the popular internet services should have IPv6 connectivity working.

From previous network configuration mistakes, I've learned that it takes quite a while before I notice the loss of IPv4 connectivity if IPv6 is still working. Usually, I notice that by having the search engine work perfectly fine, but none of the websites I click loading.

Setting up the network

It was quite easy to set up the v6-only network for me. I already have all the network traffic running through a Linux router so I just made a new bridge that gets IPv6 addresses only and drop all IPv4 traffic. I've assigned a network interface to this bridge and also an SSID on the wireless network.

$ brctl addbr v6only
$ iptables -A FORWARD -i v6only -j DROP
$ iptables -A INPUT -i v6only -j DROP
$ ip6tables -A FORWARD -i v6only -j ACCEPT
$ ip6tables -A INPUT -i v6only -j ACCEPT

First problems

The first problem didn't take very long, I had a complete lack of ipv6 reachable nameservers in my network.

The nameserver in my network is unbound running on a Linux machine. It's configured to do recursive resolving and caching and I had never set it up for IPv6.

I ran into a few interesting issues with setting up unbound. I had created an ACL that allowed the IPv6 subnet on my LAN to use the recursive resolver by marking that subnet as a private network. It took quite a bit of debugging to figure out why it refused to return AAAA records for my local services. I had created an AAAA record for my local Matrix server and I could resolve it just fine through third-party nameservers, but got no results at all from unbound. It turns out that marking an IPv6 subnet as private also makes DNS responses that return an address in that subnet dissapear due to the scrubber.

The scrubber makes a lot of sense. It prevents a website called evil.com to make a DNS record called local.evil.com pointing to 127.0.0.1 or any other local address. The issue with such a record is that browsers will allow JavaScript to connect to services on your machine this way. This works absolutely fine for IPv4 for me, but on IPv6 the public address for the service is the same as my local address for it since there's no NAT involved. After quite a bunch of searching the fix turned out to be adding a single line to the config:

private-domain: brixit.nl

This allowed my matrix.brixit.nl AAAA record to function both inside and outside the network.

Infrastructure fixes

Now I've been connected to the internet again I ran into my second issue. While all the postmarketOS infrastructure has IPv6 addresses, none of it had it's AAAA records created after the last infrastructure migration. This was luckily quite easy to fix.

Beside the infrastructure that postmarketOS runs itself there's also gitlab.com/postmarketOS. Luckily IPv6 is also fully supported on Gitlab. It looks like Github and Sourcehut are behind in this and are not reachable over IPv6 at all.

This means most postmarketOS work is possible on an IPv6-only connection. Issues are mostly that the sources for quite a lot of project are on github or sourcehut which means builds are failing locally. Also the build infrastructure for postmarketOS is running on Sourcehut builds which means I can't see the logs of build failures (but the artefacts are on the postmarketOS infrastructure and accessible again)

Inaccessible websites

So in my testing I come across several websites that didn't work yet.

  • Reddit
  • Hackernews
  • Twitter
  • Github
  • Sourcehut
  • Hackaday
  • Stackoverflow

I guess killing a bunch of the social media would make me a bit more productive. The code forge access is quite a lot more problematic. I can totally understand though that Microsoft doesn't have the funds to deploy IPv6, it's a tiny startup after all.

So is this useful at all

Running an IPv6-only network isn't super useful for daily use. There's simply too many services that still fully rely on IPv4 to function.

Occasionally plugging into the IPv6 testnet though is very useful. It's great for finding bugs, the kinds of bugs that lead to still not being able to use IPv6 after decades. Since practically all IPv6 deployments are dualstack it's not very noticable when IPv6 is misconfigured because practically all software silently falls back to IPv4.

Just using this network for an hour was enough to iron all the IPv6 issues on the postmarketOS and my own infrastructure so I'd say this was worth it.