I have been "about to do IPv6 properly" at home for roughly a decade. It is the kind of job that is never urgent, because IPv4 and NAT keep limping along and nothing actually demands the change. So it sat on the list, smugly, year after year. Last weekend I finally did it, and like most jobs you've avoided for too long, it was both easier and more annoying than I expected.
This is the write-up I wish I'd had: what I changed, what broke, and the handful of things that turned a day of head-scratching into a working dual-stack network.
Why bother at all
The honest answer is partly curiosity and partly that I'm tired of being the cobbler whose children have no shoes. I spend my working life on networks that have had v6 for years, and my own house was still pretending it was 2005. There are concrete wins too: no more carrier-grade NAT weirdness, addressable hosts when I actually want them, and the small pleasure of ping6 to a thing in the garage just working.
But I want to be clear up front, this is dual-stack. I am not turning IPv4 off. Anyone telling you to go v6-only at home in 2025 has a tidier life than I do, or fewer ancient devices. The goal was both stacks, side by side, with v6 as a first-class citizen rather than a thing that half-works and breaks DNS.
What the ISP actually hands you
The first surprise was that my connection had perfectly good IPv6 already, I'd just never enabled it. The router was getting a /56 prefix delegated over DHCPv6-PD and quietly throwing it away. That /56 is the important bit: it's not a single address, it's 256 /64 networks to carve up however you like. One per VLAN, with room to spare, which is the part of v6 that still feels faintly absurd after years of hoarding RFC1918 space.
So the shape of it is: the router requests a prefix from upstream, the ISP delegates a /56, and then the router hands a /64 to each internal network. On the LAN, hosts configure themselves, mostly via SLAAC and router advertisements rather than DHCP. That last point is where a lot of the friction lives, because it's a genuinely different model from "the DHCP server owns the truth".
SLAAC, RAs and the bit that confused me
On IPv4 my DHCP server is the source of truth. It hands out addresses, it knows who has what, and my reservations live there. On IPv6 the default is SLAAC: the router advertises the prefix, and hosts derive their own addresses from it. Nothing central is handing out leases. This is fine and even elegant until you, a person who likes to know which box is which, go looking for a lease table and find a void.
The fix was to run the router advertisements with the right flags and add stateful DHCPv6 alongside SLAAC for the hosts I care about. Roughly the daemon config looked like this:
interface eth1 {
AdvSendAdvert on;
AdvManagedFlag on;
AdvOtherConfigFlag on;
prefix ::/64 {
AdvOnLink on;
AdvAutonomous on;
};
};
AdvAutonomous on lets SLAAC work, AdvManagedFlag on tells clients there's also a DHCPv6 server worth asking. Belt and braces. Most of my devices happily took a SLAAC address and a DHCPv6 one and got on with life. A couple of stubborn IoT things ignored DHCPv6 entirely and only did SLAAC, which is exactly the sort of standards-optional behaviour you learn to expect from a smart plug.
The thing that actually broke: DNS and firewalling
Two real problems, both predictable in hindsight.
First, DNS. The moment hosts had v6 addresses, lots of them preferred AAAA records and tried to reach things over v6. Anything I'd only firewalled or routed on v4 suddenly had a second, wide-open path I hadn't thought about. The default IPv6 posture is "globally routable", there's no NAT hiding your hosts, so the firewall is doing real work now rather than NAT doing it by accident. I spent a good hour translating my v4 rules to v6 and finding the gaps. If you take one thing from this: your IPv6 firewall is not optional, because nothing else is protecting those hosts.
Second, the classic. A few things went slow rather than broken, the dreaded "tries v6 first, times out, falls back to v4" pause that makes everything feel sticky. Happy Eyeballs is meant to hide this, and mostly does, but a misconfigured route or a blocked ICMPv6 will still give you mysterious two-second stalls. And do not, whatever you do, blanket-block ICMPv6 the way muscle memory tells you to block ICMP on v4. Path MTU discovery depends on it, and breaking it gives you connections that establish and then hang when they try to send anything large. That one cost me an embarrassing amount of time.
Was it worth it
Yes, with caveats. The network is genuinely better. Every host is addressable, the CGNAT nonsense is gone for v6 traffic, and there's a satisfying cleanliness to per-VLAN /64s after years of subnet tetris. I learned more about how my own kit actually behaves in an afternoon than in years of it just working.
The caveat is that it is more to think about, not less. You now have two firewalls to keep in sync, two DNS paths, and a privacy story (temporary addresses rotating underneath you) that makes "which box is that" harder, not easier. It is the right kind of complexity, the kind that reflects how the network really is, but it is not zero.
If you've been putting this off like I had, do it on a quiet weekend, dual-stack, with the firewall sorted before anything else. And leave ICMPv6 alone. The future arrived ages ago; I'd just left it sitting in the delegated prefix, unused.