Ctrl.blog

Ctrl blog off IPv6

I removed IPv6 support here on Ctrl blog in mid-September 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 August 2017.

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 the beginning of September. 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:

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 10 years ago.

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.