Two steps backwards on IPv6 adoption in 2017

The web as a whole might be steadily progressing towards greater IPv6 adoption, but my own journey has hit some rough patches in the last year. My website is now IPv4-only and so is my home internet connection. Here is my year in IPv6.

Ctrl blog off IPv6

I removed IPv6 support here on Ctrl blog in when I stopped maintaining a bunch of edge servers and migrated it to BunnyCDN — my budget content delivery network of choice.

After signing up for BunnyCDN, I tested and confirmed that IPv6 was unavailable right away when I signed up. There wasn’t any notices about IPv6 connectivity issues on BunnyCDN’s status page, blog, or Twitter stream so I reached out to support to inquire about it. One of my deciding factors when choosing a CDN for this website was BunnyCDN’s advertised IPv6 support, but IPv6 hasn’t been available on their platform since .

It feels like a bit of a set-back to revert to an IPv4 only website after successfully serving 18,8 % of its monthly visitors over IPv6. Ultimately, I felt that it was worth the sacrifice and that my own interests and those of my visitors were better served by reducing page load times and by the reduced complexity offered by moving everything over to a content delivery network.

Home ISP off IPv6

A new local internet service provider, Lynet Internett, expanded into my neighborhood in . They offered free installation, twice the download speed, and ten times the upload speed for the same price I was paying my old ISP. I did some quick research and was pleased to learn that they were among the first to offer residential customers IPv6 in the country starting in 2010. My old ISP had random service outages of random durations several times per month, so I was more than happy to switch to a different provider who had also been an IPv6 pioneer.

Unfortunately, the new ISP’s network expansion meant that they’d also invested in new network equipment for their own core networking infrastructure. Long story short, the new hardware had introduced a problem that meant they’d had to turn off DHCPv6, which means my border gateway device (“router”) won’t get an IPv6 address prefix delegated. In other words, I can’t get an IPv6 address for any device behind my border gateway device. When I complained about the problem, their support representative summed up the situation nicely:

We were among the first to offer IPv6 services in Norway, and we’re the first to take it away again.

They haven’t communicated the issue publicly in any channel, and they’ve not been able to give me a time frame for when the issue will be resolved. They have delivered on the faster speeds (plus 2 Megabits per second up/down above and beyond their promised speeds) and they’ve not had a single minute of downtime that I’ve noticed.

So, I’m off IPv6 entirely now for the first time since 2012.

What else happened in the IPv6-year 2017?

The Jetpack plugin for WordPress had a serious bug that locked every IPv6 address out of the WordPress administration interface. This turned out to be yet another case of port-number “cutting”, a programming shortcut for IPv4 addresses notation that entirely breaks IPv6 addresses.

I looked in to why the Windows IPv6 Control Message service consumes so much bandwidth in the Data usage report in Windows 10. (Most likely caused by a crowded local network or a faulty network interface.)

I extended SSHGuard — the brute-force-login blocking service — to support IP subnet blocking A standard residential network gets a whole /64 subnet’s worth of IPv6 addresses, so SSHGuard needed to provide better tools for blocking large subnets. Detection is currently limited per-address, but stay tuned for same-origin subnet detection!

Fail2Ban, an alternative to SSHGuard, finally released version 0.10 with IPv6 support after more than a year of development. It’s better late than never, but the Fail2Ban project hasn’t stayed on top of IPv6 support. SSHGuard has had IPv6 support since the 1.0 release over .

I tested some website certificate monitoring services and found that SSLPing didn’t support IPv6 websites at all, and KeyChest supports IPv6 but doesn’t do a good job with it — or certificate monitoring.

For my own sake, I hope that both BunnyCDN and my ISP can work out their IPv6 compatibility issues and restore IPv6 connectivity as soon as possible.

For the web as a whole, I hope we’ll see global IPv6 adoption skyrocket in 2018 without causing issues for the masses. I won’t hold my breath for a smooth IPv6 transition year, however.