It's been a quarter of a century since the first IPv6 standard was finalized as RFC 2460, and to say adoption has been slow is an understatement. The pool of available IPv4 addresses has been exhausted for quite a while now, and in fact, was running out for public use years ago. Yet it's still not gone, with most systems that have adopted IPv6 running a dual-stack configuration that also includes IPv4.

I wondered if you could survive on just IPv6. Surely, it's an established enough protocol that it would work for daily use. Oh, dear reader, if it were only so. The things I rely on daily to actually do work did not want to cooperate at all. Well, there was one exception—a big shout-out to Gmail for supporting modern internet protocols. On the other hand, the things that try to distract me during the workday all worked flawlessly.

Oh, and my smartphone worked for everything, but that's down to Apple requiring App Store developers to support IPv6-only networks and a bunch of networking shenanigans on the back end of cellular connectivity. This whole experiment felt deeply ironic, as my cellular provider and ISP both use IPv6 on the back end for routing, but getting that to translate to a usable internet experience was a chore.

Time to turn off IPv4

This was harder than I expected it would be

The thing about trying to turn off an internet protocol that's been established for decades is, well, it's bloody everywhere. Some hardware has IPv4-only network stacks, and while the major operating systems all support IPv6, not every program they rely on does. But that's part of the point of this experiment. The tech world has had decades to adapt to IPv6, and I wanted to see how they'd handled things.

I'd put together the basic parts of a plan. I'd use an OPNsense router and remove the IPv4 address from the interface so it could only use IPv6. I also removed IPv4 from the network adapter on the laptop I'd be using that day, so it only had IPv6 routing, and confirmed that it worked. The only thing I use daily that I couldn't remove IPv4 from completely was my smartphone because while my network carrier uses IPv6, it also uses 464XLAT. This would be no good for our test, as 464XLAT uses stateless translation from customer-side translators (CLAT) and stateful translation on the provider-side (PLAT).. That design keeps an IPv4 software stack on the phone for legacy apps, but every packet on the air-link is pure IPv6. Outbound IPv4 traffic is translated to IPv6 by the CLAT, crosses the network as IPv6, and is converted back to IPv4 by the carrier's NAT64 just before it hits the legacy internet. In other words, the transport path is all IPv6, yet the handset still carries an IPv4 stack, so using it would kind of undermine the entire purpose of an IPv6-only experiment.

Thankfully, Verizon FiOS rolled out IPv6 support to my area a while ago; otherwise, this whole thing would have ended here. It's also a minor blessing that they slowed the 2 Gig rollout; otherwise, I'd have no IPv6 because it's not enabled on the highest tier in my region, which I assume is for troubleshooting purposes. I do have a T-Mobile 5G router that is IPv6-only, but that's also subject to 464XLAT translation like my cell phone and would derail everything because I have no control over the translation to IPv4. In other words, everything would work as usual. Even after all of that, you'll need something like DNS64 to resolve IPv4-only hostnames. Any service without an AAAA DNS record (a DNS A record specifically for an IPv6 address) won't load on an IPv6-only network.

It went about as well as I expected, really

I couldn't do my job, but that meant I had plenty of time to browse Facebook

The stage was set for trying to survive with an IPv6-only network and connection to the Internet. I couldn't quite turn everything IPv4 off because I'm not the only person using the Internet in the house, but segregating some devices with an IPv6-only router was the next best thing. I had some thoughts about what would likely work and what wouldn't, but I wasn't sure if I'd be able to get any work done, let alone my usual workflow.

As it turned out, I couldn't. XDA's CMS wouldn't load on the IPv6-only connection. Neither would Slack, but I was granted some reprieve by Gmail, and the rest of Google Workplace happily connected. I couldn't upload any work to the site, but at least I could write in Google Docs for later use. I also couldn't connect to Proton VPN, and after a bit of searching, I found the reason: while traffic will go through the tunnel as IPv6, it needs IPv4 to make the initial connection. You can edit the WireGuard profile ProtonVPN uses to allow for it, but by default, it won't work out of the box. From the documentation:

Note that by default, our WireGuard config files don’t currently support IPv6 connections. If you have an IPv6 connection, you’ll need to edit the downloaded .conf configuration file to ensure that IPv6 connections are routed through the VPN tunnel. To do this, open the file in a text editor and change the line:

AllowedIPs = 0.0.0.0/0 → AllowedIPs = 0.0.0.0/0, ::/0

Save the file and close it when you’re done.

Spending time on an IPv6-only Internet has taught me a few things, but it's also highlighted the business world's complete refusal to do anything that doesn't immediately raise the stock ticker. I expected Google and Cloudflare to work, but other tech giants surprised me. Amazon worked if I wanted to buy things, but AWS refused to cooperate on many tasks. As it turns out, there's a pretty long list of AWS services that don't support IPv6-only access. GitHub is completely running on IPv4 (aside from GitHub Pages, which supports AAAA), and Microsoft needs to stop dragging its feet. But it's not just them; roughly half of the sites or services I tried didn't work without IPv4.

The other side of the coin is that turning off IPv6 in your home also comes with issues. Microsoft might not be migrating GitHub to IPv6 any time soon. Still, its perspective on IPv6 on Windows is that it's an essential part of the operating system, and turning it off in any version since Windows 7 will stop some components from working. Web browsing on any system will first initiate the connection with IPv6, then race IPv4 after a short delay, so that page-loading latency is minimized while still preferring IPv6. This feature is wonderfully named Happy Eyeballs, and essentially means you use both protocols in parallel for a request.

My smart home was smarter than I thought

The rest of my devices were a mixed bag, but most worked apart from a Wi-Fi camera that refused to connect to anything but IPv4. Anything that supports Matter and Thread was fine, as Thread uses IPv6 for addressing, and there were no issues with local control. Smart home device control is much better on IPv6 anyway, with multicast allowing sending commands to multiple devices simultaneously, Neighbor Discovery Protocol, and mDNS making it easy for your controllers to find your devices, and the inclusion of IPsec for built-in encryption to enhance security. IPsec isn't a requirement of IPv6, but is fundamentally integrated in IPv6 as opposed to being just an add-on in IPv4.

The Internet and your home are not ready to fully switch to IPv6, but that's why we have dual-stack networking

At this stage, I'm not entirely sure that IPv6 will ever replace IPv4 during my lifetime, but I don't think it matters. For what it's worth, a huge chunk of mobile traffic is delivered primarily over IPv6, and systems can realistically support both IPv4 and IPv6, which shouldn't matter to the end user. The issues with translation between the two protocols have been addressed for the most part, and while NAT and CGNAT are band-aids over the problem of address space in IPv4, we're getting close to the tipping point where, at the carrier level, everything can be switched to IPv6, and the annoyances of double-NAT can disappear.