Home networking can be a lot of fun: setting up a name service, a guest network, or traffic rules, leads to an endless joy of discovering new RFCs or creativity in the very active field of artistic configuration file syntax.
I thought I had seen everything until I tried to set up IPv6 connectivity for my home network. Little did I know that this would eat up so many of my precious free evenings. The following writeup is here to remind me never to try that kind of shit ever again, and as a warning to future generations who might want to dig into this kind of topic. Life is short, there are many better things to do than attempt to set up a new addressing scheme for your home network. Long live the NAT king!
It all began when I noticed that my ISP provided me with a unique (native!) IPv6 prefix to use on my home network. Something like:
Since I was not familiar with IPv6 addresses, it took me a while to find out that the first 64 bits of a 128-bit IPv6 address designate a network, and the last 64 are reserved to differentiate hosts on that network. My provider handing me a /56 means I have 64-56 = 8 bits to play with, i.e. I can instantiate 256 home networks, each having up to 2^64 = 18,446,744,073,709,551,616 hosts. Overshot a bit, maybe.
So where do I start? Do I have to install specific software? Where? Do I need to buy specific hardware? How many services are needed? And thereby started my long painful descent into the horrific world of IPv6. Toss and loose 1d20 sanity points immediately.
My ISP unfortunately did not provide any help as to what I am supposed to do with the IPv6 thingie they gave me. No single help page, very few discussions on their forums, and all exchanges I had with customer service were completely useless. Best I could find were discussions between customers of an ISP in the US that provides a similar setup. That is thin.
Say you received a /56 prefix from your ISP. If that prefix ever changes e.g. because you switched to a new ISP, you want things to work automagically because that is the way things currently work with IPv4: changing my public IPv4 address does not change anything to my home network.
In order to do that, IPv6 suggests that home networks use two sets of addresses: the public ones derived from the ISP-provided /56, and another private address space based on something else called a ULA (Unique Local Addresses). You get to choose your own ULA on your home network(s), preferrably based on a good random number generator, but nothing prevents you from taking something like fc00:caca:caca:caca:caca::/48. If anybody else on the Internet picks the same network prefix you will get into trouble when trying to get intimate with each other, e.g. by establishing a VPN between both worlds. We had exactly the same problem when trying to join two sites using IPv4 NAT'd 10.0.0.0/8 subnets, so this is not really a regression. Fun fact: if you have no ULA in France you can always say "Il manque ULA sur mon réseau".
How do you get to choose this ULA? If you happen to have a single router on your home network it should just be a matter of digging through the router IPv6 setup until you find it. But most home networks are now running multiple routers that are all unaware of each other, and all convinced they are masters of the universe. You will most certainly end up with several ULAs. Some of your devices will get several addresses and you will have to understand your own network topology to know which address to use to access them. Prepare for glorious hours of debugging, which is particularly great when facing addresses that are mostly made of bloody random bits.
Why several routers on the same home network? Simply because you may be running several DSL connections, or maybe you have a VPN started somewhere away from your edge router, or maybe you connected your smartphone and it offers another potential exit to the Internet. You also get a virtual router when you start virtual machines on a desktop.
To make things simpler, every network interface on your machines will also generate a local address that is only valid for its closest neighbours, called a link-local address. Unfortunately you won't go far with that one as it is not supposed to cross boundaries. Think of it as a 127.0.0.1 that extends to the other side of the cable but not further.
Ok so we have now several adresses for each machine on the network. Figuring out which one should be used (incoming or outgoing) is just an unspecified, incredible mess. The link-local address can only be used on very specific physical links, the ULA address cannot be routed to the Internet, and the public addresses you have may change at any moment, e.g. through your smartphone sharing a 4G access.
At that point we have just determined that your printer currently identified as 'printer' also known as 192.168.1.20 in IPv4 will now be accessible as:
Of course normal human beings are not meant to remember this kind of random shit. For this kind of thing you have DNS.
DNS you said? What DNS?
There are really two ways machines can obtain an IPv6 address: SLAAC and DHCPv6. SLAAC means Stateless Address Auto Configuration, whereby a machine obtains a prefix and derives its own IP address from it, e.g. based on its own MAC address. Cool, right? You do not have to assign individual addresses in static DHCP leases, every machine does it on its own. But then: how do you know which address was self-assigned by your very smart printer?
There are dedicated neighbour-discovery protocols for that, but they are mainly designed to make sure that addresses are locally unique and routers know where to find them. This is only taking care of establishing a link, there is nothing dedicated to associating a name to a self-assigned IP address. And if there was, how would you know who to believe? If two machines on the local network claimed to be 'joe', what should happen?
To be fair, there are solutions like Bonjour, also known as zeroconf, but they are unlikely to work on lightweight or old devices. Shoot again.
Back to square one: if you want to reach your own machines using human-usable names you need to run DHCPv6, a protocol that was designed to compensate for such things. And there you go: back to static leases, addresses assigned by a router, attached to a name, and you end up doing exactly the same kind of shit you used to do with IPv4 local networks, except this time the addresses are much easier to screw up.
Even worse: if the self-assigned IPv6 addresses are not related to MAC addresses, it means every single host on your local network will have generated its own random address, forcing you to manually harvest them from all devices. But you know how to do that on your connected toaster, right?
What's in it for the average home network user? Pretty much nothing. The fact that every single one of your home devices has a potentially reachable address on the intertubes is downright scary. Internet service is for internet servers, not for sensors and other IoT bullshit. First thing you will want to do is bullet-proof your firewall to make sure nobody but you can access your printer from the Internet, and hope things are Ok with your IoT shit.
The story did not just end up with me reading thousands of pages on the Internet and a couple of paper books. I hacked every single computer in my house to run IPv6, starting with the routers under OpenWRT, LEDE, FreeBSD, OpenBSD, pfSense, OPNSense, and later moving on to all client OS machines: OSX, Linux, Android, *BSD, and even some Windows boxes, blimey. I instantiated dedicated DHCP and DNS servers, configured static addresses, automatic ones, bridges and NATs and firewall rules and what-have-you, and I ended up with some machines working under IPv6 only, some under IPv4 only, some that could use both stacks, and some (a lot) that were just unreachable no matter what. Yeah, I also crashed my Internet access several times. Omelet and eggs.
Let me try to put it this way: some of my home machines are servers, e.g. a NAS or a printer. I want to be able to print on 'printer' or mount a share on 'NAS' without having to remember random 128-bit numbers. Silly me. Since I want to use names I have to assign addresses myself from a router running DHCPv6. Neither NAS nor printer need to be available to the public. So what did I gain compared to a local IPv4 network? Hmm... Address management is not fun with 32 bits, imagine with 128.
Or maybe I am just old-fashioned, trying to manually assign names to my home machines. This might be an idea for a new product: a router that would automatically identify hosts on the home network and show them on a single web interface, allowing you to assign names and forget about addressing altogether. Might get in trouble when you have several identical devices but I'm sure there would be a way. If such a product exists I have not seen it yet.
On the other hand, if I want to browse the Interwebs in v6, I found out that mounting a SOCKS proxy on a remote cloud box works perfectly well. No need to configure anything, just ssh -D and the IPv6 world is mine to browse.
Summing it all up
Address assignment is not easier than IPv4. Still requires a dedicated DHCP and DNS server, only more complicated to configure. You are facing the tedious task of gathering self-assigned IPv6 addresses from all hosts and copying them onto your DHCPv6 server, hoping the self-assignment method won't change soon.
Routing is now different, but not easier. New constraints are imposed on knowing which interface to bind to when reaching out to the Internet.
Firewalling the whole thing with a mix of IPv4 and IPv6 might tear you a new one. I can already lock myself out of a router with human-readable firewall rules, I cannot imagine doing the same thing with batshit-crazy addresses and feel safe.
You know what? I will stick to glorious NAT'ing until this mess is sorted out. Good news is that there are many bright people currently working on the topic. All I hope is they eventually come up with something that you and me can use without having to read through a million pages of RFCs, compile obscure daemons, or purchase new boxes as if I did not have enough of them.
Talking about RFCs, this one is trying to gather very sensible requirements about home networks:
If you have 20 minutes to spare, you should watch this talk:
If you really insist on switching your home network to IPv6, I would recommend reading this rant first:
In its current state I can only dismiss the current IPv6 definition for home networks as very incomplete and unworkable for non-professionals. Let's hope RFC 7368 will be handled by qualified, creative, and pragmatic people.
Til then, there is no place like 127.0.0.1