Could IPv6 have an edge over IPv4?

I wrote about my adventures on IPv6 before. Basically, it seemed like IPv6 solved address space limitation problem with a larger address space while IPv4 just used NAT, and that meant IPv6 didn't add much value because IPv4 practically didn't have any address space concerns anymore. If we ever filled the 64-bit address space of NAT, we could just add another layer of NAT and have a 96-bit address space, and ad infinitum. Oh wait, we already did. CGNAT is exactly that.

Yes, IPv6 has other niceties like stateless auto-configuration that removes the need for DHCP, an all routable address space, allegedly better routing and multicast, but it has lots of quirks too. IPv6 addresses are too long for one. They are impossible to memorize while I'm quite comfortable writing 192.168.1.23. So, IPv6 has felt like not worth converting to.

IPv4 happens

I love WireGuard as a VPN solution, and use it to connect to my home network while I'm traveling. Last week, I tried connecting home from our Airbnb in Hawaii, but couldn't access my network. There were multiple issues with my VPN connection, and all of them turned out to have a single root cause.

The first issue was: I have this server at home that accesses APIs on a remote site using WireGuard. When I wanted to access my server, I couldn't. I didn't get a ping response. But, I could access it fine when I was home.

The problem turned out to be that both the WireGuard network to that remote site and my VLAN at home for my own VPN connection used the same subnet: 192.168.2.0/24. So, whenever I pinged my own server, it received the packet, but forwarded it to that remote site over WireGuard, and the packet would just vanish. My home network subnet could access the server fine because my home network was in a different subnet.

My second problem was that I couldn't even access other devices on my home network's default VLAN. This time, the reason was that the Airbnb Wifi and my home network were on the same and well known subnet of 192.168.1.0/24. When the IP address you want to access matches your local subnet, your packets don't get forwarded to the gateway, they are just looked up using ARP protocol, and if a device isn't found, you'd just get an error on the client.

Both problems were happening because of conflicting subnets as seen in the figure below.

Can you see the pattern? IPv4 apparently isn't designed for peer-to-peer communication between local subnets. I researched the problem and the articles and forum comments said "just change the subnet configuration, bro" which was not at all possible either with my Airbnb Wifi, the remote server, or my home network for that matter.

Some articles suggested adding firewall rules to translate a different subnet into your own, so I could use the addresses from the subnet 10.0.0.0/16, and they would be translated to to 192.168.0.0/16. If I wanted to access 192.168.1.23, I would have to type in 10.0.1.23 instead.

I mean, that was probably something I could do, but it was far from ideal. What if I'm developing a software and I need consistent addresses to connect to? What if I need using DNS or mDNS? How am I going to handle all these conflicts?

That's where IPv6 actually gets its edge.

IPv6 has no overlapping local subnets

Or, more accurately: IPv6 has no local subnets. I mean it does, but, they aren't generally used after the initial network configuration of your host (see: my previous adventures). IPv6 addresses are globally routable, hence distinct from each other regardless of your configuration. The second half of your IPv6 address is randomly generated, but theoretically, if every ISP customer on Earth assigned the same number to one IPv6 device on their network for that second half, each one would still have a unique address.

So, if our Airbnb Wifi had an IPv6 network, my local subnet wouldn't be 192.168.1.0/24, it would be something like 2600:1122:3344:5566/64. My home would have a subnet like 2605:7788:99AA:BBC0/60. The remote site my server connects to would have something else, 2603:DDEE:FF00:1122/64. Routing between these nodes would have no conflicts. My WireGuard would work like a charm.

Maybe, that's why Tailscale uses IPv6 behind the scenes.

What's the catch?

There's one good thing about local subnets: they stay. IPv6 doesn't provide such guarantees. First, because of auto-configuration, your IP address is subject to change after an OS reinstallation, or even a dual boot or so. On an IPv4 network, DHCP would give you the same address because your MAC address provided by your network adapter would remain the same. To get that on IPv6, you might have to use DHCPv6 and persist your interface ID. So, there goes one benefit of IPv6 out the window.

Second, it turns out some ISPs rotate your IPv6 prefixes frequently, like daily, to prevent you from hosting a blog or whatever I guess, God forbid. Since there's no local subnet, that means your entire network configuration changes whenever your ISP decides that it's time to redo your configuration. It's pretty much like ISP visiting your home, editing your 192.168.1.0/24 to 192.168.123.0/24 one day, and everything, every internal connectivity in your house breaks down because of that.

That means that using globally routable addresses in your private network configuration may not be sustainable. You'll have to resort to private addresses such as link-local addresses or unique local addresses (ULAs, a fancy way to say "routable local addresses") in your IPv6 network. There goes another benefit of IPv6 out of the window.

If you decide to use link-local addresses with fe80 prefix, your routing problem you had in the first place comes back to haunt you exactly like IPv4's cursing ghost predicted.

Final thoughts

Globally routable addresses for every IPv6 device is great, but the design fails to give you persistent address configurations across service providers or prefixes. So, you just shouldn't configure your internal network based on your global IPv6 addresses. Ideally, you should have a ULA-based structure with a unique prefix if you ever plan to connect to your network remotely because link-local addresses will have the same overlapping subnet problem that you had with IPv4.

Maybe ARIN could relax its criteria for IPv6 address prefix purchases and make it more affordable to get a /48 or so under a certain prefix. That way, we could have our own never-changing IPv6 block that we can carry over to the next ISP or to their next IPv6 rotation.

Regardless of what solution you use, since you can't memorize IP addresses anymore, you must rely on hostnames of your devices, and generously use mDNS. Actually, if you can afford an actual DNS server, add a domain controller in the mix, and maybe you won't even need a VPN, as IPv6 once promised.

I was excited to find out that IPv6 might finally have a strong edge over IPv4 because how it handled local subnets, but got a little bit disappointed after learning that it couldn't handle that as well as I wished. But at least, it provides us more options than "just reconfigure your network, bro".