I’m not a network engineer or very educated in the field (I feel) but I know some things that I’ve been able to gather over the years in having to traverse my own rabbit-holes of networks.
Years ago I setup an Asus mesh setup with Merlin covering my whole property with a Pi-hole filtering both v4 and v6. I was initially skeptical about the extra hassle, but every time I tried shutting IPv6 off to “simplify” things, the entire network took an immediate, noticeable hit in responsiveness—especially link resolution and initial page rendering.
I found out why it felt that lag and it comes down to how modern stacks actually behave:
Modern OSes and browsers query A (IPv4) and AAAA (IPv6) simultaneously and try IPv6 first. If IPv6 is disabled at the router or broken upstream, the client stack hangs waiting on a timeout (around 250–300ms per connection attempt) before failing back to IPv4. When a single webpage pulls assets from 40 different domains, those split-second timeouts stack up fast.
Major CDNs and edge hosts simply route cleaner and faster over native IPv6 without getting dragged through legacy ISP translation boxes.
I found that a setup that actually works without turning your homelab into a second job is a simple hybrid:
Keep internal management on IPv4: Put your static reservations, local servers, and management interfaces on standard private IPv4 (192.168.x.x). It’s 100% deterministic, easy to remember, and immune to upstream ISP changes.
Let WAN egress run on IPv6: Let your router pull a prefix delegation from the ISP and hand out addresses via SLAAC. Your workstations, phones, and consoles route outbound over native IPv6 at full speed.
Lock Pi-hole (or whatever you use, and should be using) DNS to Link-Local: In your router’s IPv6 DNS settings, point it to your Pi-hole’s Link-Local address (fe80::...), not its public GUA. Link-local is tied to hardware, so if your ISP bounces your connection and changes your delegated prefix, your local DNS resolution won’t die.
Leave the router’s IPv6 stateful firewall on: Unsolicited inbound traffic gets dropped at the perimeter by default, exactly like NAT did, while outbound connections track cleanly.
You don’t need to rebuild your internal network around 128-bit hex strings. Let IPv4 run your local devices, let IPv6 handle the outbound internet traffic, and you skip the fallback penalties entirely. Now I know a lot of (if not all) this is trivial to many that know more and or work in the field, but I don’t and this is only what I’ve learned setting it up for myself.
That RFC is not implemented as strictly defined, at least by Linux systems. I use ULAs extensively in a dual stack environment where hosts have both A and AAAA records, and the ULAs are very much used. No idea if GUAs are preferenced over ULAs, but I’d argue that putting ULAs in a public zone or GUAs in a private/internal zone is a misconfiguration.
I mean a lot of these issues are due to how it’s implemented.
You can have devices that do not interact with each other except whatever connects to your network. I think thread is the one that commonly does this, but they also offer ones that do relay. I’m not sure if zigbee or matter has these options as well. You can also just not have any wireless devices at all and use hardwired ethernet. You can control them at that level
I think that’s why my hybrid approach ends up being the sweet spot for a homelab—especially once you scale up. I have over 70 devices connected across my property at any given time (workstations, servers, phones, streaming boxes, and random IoT / homeassistant gear), and while I know that’s not a lot compared to many; introducing ULAs into that mix, imo, is just asking for edge-case headaches.
Now again, based on my limited experience - if you curate split-horizon DNS and have homogeneous Linux clients, ULAs can definitely work. But across 70+ varied devices, you quickly run into a resolver lottery where different OSes and runtimes treat ULA precedence differently. Nobody wants to spend their weekend debugging why a random smart TV or embedded gadget is choking on internal A vs AAAA lookups. Again, not turning your home network into a second job.
By skipping ULAs entirely, you don’t even have to care about the RFC 6724 debate:
Local management stays on IPv4: Standard 192.168.x.x with DHCP reservations.
Local L2 chatter stays on Link-Local (fe80::): Handled automatically by the hardware. Pointing my router’s IPv6 DNS to the Pi-hole’s link-local address means local filtering never dies, even if the ISP rotates my prefix.
Outbound WAN runs on native GUA via SLAAC: Devices pull a public prefix from the ISP and route to the internet over IPv6 at speed.
My Linux workstation puts IPv6 first by default (I think most do now), connects to WAN targets in ~50ms, and all 70+ devices stay stable without having to manage internal IPv6 address schemes or fight OS routing priorities. For a real-world home network, it gives you the speed benefits of IPv6 with zero of the internal management headaches. Again, IMO as I’m running this setup, have for years and I simply don’t have the screw with it… it just works.
From my perspective, IPv4 is the exception/outlier that is a pain to manage I would agree that dual stack is a management burden especially in a homelab - all my internal infrastructure only knows of their various partners via IPv6 (eg. dns primaries and secondaries only talk via v6).
I generally only offer IPv4 to things that I know can’t connect over IPv6, namely my mikrotik switches (much to my disappointment). Even my shitty laser printer works on v6.
I think the biggest thing you’re missing is that dual-stack isn’t really twice the work for normal clients. Modern systems use Happy Eyeballs to prefer IPv6 while quickly falling back to IPv4 if needed, so you get the compatibility of IPv4 without necessarily noticing much extra complexity.
For me, the main reason to keep IPv6 enabled would be future compatibility and avoiding dependence on IPv4/CGNAT infrastructure. If IPv4-only is currently working fine for you, though, I can understand not seeing much immediate benefit from changing it.
On local area networks, ULA will have highest precedence. Only Linux has implemented it so far. Apple operating systems still rely on its neat Happy Eyeballs algo. Windows is Wild West, up to application layers.
I would agree that dual stack is a management burden especially in a homelab - all my internal infrastructure only knows of their various partners via IPv6 (eg. dns primaries and secondaries only talk via v6).