Could IPv6 have an edge over IPv4?

Sign in<br>Subscribe

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.<br>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.<br>IPv4 happens<br>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.<br>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.<br>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.<br>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.<br>Both problems were happening because of conflicting subnets as seen in the figure below.<br>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.<br>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.<br>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?<br>That's where IPv6 actually gets its edge.<br>IPv6 has no overlapping local subnets<br>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.<br>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.<br>Look ma, no conflicting subnets!Maybe, that's why Tailscale uses IPv6 behind the scenes.<br>What's the catch?<br>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.<br>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...