IPv6 at Home: Why It Matters Now and How to Stop Ignoring It

Most of us have spent two decades treating IPv6 as someone else’s problem — a thing that exists, that we’ll get round to, that the internet seems to run fine without. Meanwhile it quietly crept onto your network anyway. Your phone is probably using it right now. A large slice of traffic to Google, Netflix and the big CDNs is already IPv6 over your home connection, and you never lifted a finger. The question stopped being “should I enable IPv6” some time ago. It’s now “should I keep pretending the IPv6 that’s already running is something I understand.”

You should stop pretending. Not because IPv4 is about to vanish — it isn’t — but because IPv6 is no longer the future, it’s the present, and ignoring it means running a network with a whole protocol you don’t monitor, don’t firewall properly, and can’t reason about when something breaks.

Why it actually matters now

Three things have changed. First, carrier-grade NAT. To cope with IPv4 exhaustion, many ISPs now hide hundreds of customers behind one public IPv4 address. That breaks inbound connections, ruins port-forwarding, and makes self-hosting miserable. IPv6 hands every device a real, globally routable address — no NAT, no sharing — so the thing you couldn’t expose over a CGNAT’d IPv4 link just works over IPv6.

Second, performance. Major content networks frequently serve IPv6 faster, with fewer NAT hops in the path. Eyeball networks prefer it via Happy Eyeballs, the algorithm that races both protocols and usually picks v6. The gains are real but modest, and they’re not the headline reason to bother — they’re the pleasant side effect of being on the path the big CDNs actually optimise for. Treat performance as a tiebreaker, not the argument; the connectivity and visibility points above are what make the case.

Third, security by omission. If IPv6 is running on your LAN — and it almost certainly is — but your firewall rules only cover IPv4, you may have devices reachable over v6 that you never intended to expose. An unfirewalled IPv6 stack is the kind of thing that bites quietly.

How do you tell whether you’re behind CGNAT in the first place? Compare the address your router shows on its WAN interface with the address a “what is my IP” lookup reports. If the WAN address sits in the shared-CGNAT range (the 100.64/10 block reserved for exactly this) or simply doesn’t match what the outside world sees, your ISP is multiplexing you behind a shared public IPv4 — and no amount of port-forwarding on your own router will help, because the port you forward lives on a box you don’t control. IPv6 is the clean way out: a globally routable address per device, no carrier in the middle deciding which ports exist.

Turning it on deliberately

On most home routers IPv6 is either already on or one checkbox away; the work is in doing it on purpose rather than by accident. Confirm the WAN side has a delegated prefix, that your router is handing out addresses via SLAAC or DHCPv6, and that clients actually received one. A quick end-to-end check from any Linux box:

1
2
3

# Do I have a global v6 address, a default route, and reachability?
ip -6 route show default
ping6 -c2 2001:4860:4860::8888    # Google public DNS over v6

If the route is missing, your router isn’t advertising itself; if the route is there but the ping fails, you’re back in the troubleshooting section below. Get a clean result here before you touch a single AAAA record, because everything downstream assumes the basic path works.

The mental model is different, embrace it

The single biggest unlearning: IPv6 has no NAT, and that’s good. Every device gets a globally unique address from a prefix your ISP delegates to you — typically a /56 or /64, which is an absurd number of addresses. Instead of one public IP and a NAT table, you get a routed prefix and a stateful firewall doing the gatekeeping.

That firewall now matters enormously, because there’s no NAT accidentally hiding things. Default-deny inbound is non-negotiable:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# nftables: allow established/related, drop new inbound, permit ICMPv6
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iifname "lo" accept
    ip6 nexthdr icmpv6 accept       # don't break PMTUD/ND
    tcp dport 22 accept
  }
}

Note the ICMPv6 line — IPv6 genuinely needs ICMP to function. Path MTU discovery and neighbour discovery ride on it, so the old IPv4 habit of blanket-dropping ICMP will leave you with a network that mysteriously half-works. If you want to be more surgical than a blanket accept, permit the specific types — echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert, packet-too-big — and drop the rest. But “allow all ICMPv6 inbound on a default-deny chain” is a perfectly defensible starting point and far safer than the reflex to block it.

There is a second trap here that the segment-everything crowd will recognise. If you run separate networks for trusted machines and untrusted gear — and you should; the reasoning is the same as in keeping your smart toaster away from your NAS — every one of those segments gets its own IPv6 prefix and its own set of inter-segment rules. The work you did to isolate VLANs on IPv4 does not carry over for free; router advertisements and prefix delegation happen per-segment, and a forgotten accept between zones reopens exactly the hole you closed on v4.

Getting your addresses in order

Run ip -6 addr on a Linux box and you’ll likely see several addresses on one interface: a link-local fe80:: one, a stable global address, and a temporary “privacy” address that rotates so you’re not trackable by a fixed identifier across the web.

1
2
3
4

ip -6 addr show dev eth0
# inet6 2001:db8:abcd:1::42/64 scope global      <- stable, use for servers
# inet6 2001:db8:abcd:1:9c3f::8d2/64 temporary    <- rotates, for outbound
# inet6 fe80::5054:ff:fe12:3456/64 scope link      <- link-local only

(Those 2001:db8:: addresses are the documentation prefix — RFC 3849 reserves it precisely so examples like this don’t print someone’s real allocation. Your own machine will show the prefix your ISP delegated.)

For a server you want a stable address, so set a static one or use DHCPv6 with a reservation. For self-hosting, you point an AAAA record at that global address and — firewall permitting — it’s reachable from the internet directly, no port-forward, no CGNAT misery. Just remember that “directly reachable” cuts both ways, which is why the firewall section came first.

The privacy address deserves a word, because people see it and panic. Modern operating systems generate a temporary, randomised global address for outbound connections and rotate it every day or so, specifically so a fixed interface identifier can’t be used to track you across sites. That’s a feature, not a misconfiguration — you want clients using it. The mistake is letting a server answer on a rotating address; pin servers to the stable one, let clients roam. The two addresses coexisting on one interface is normal and correct, and once you internalise that “one interface, several addresses, each with a job” model, ip -6 addr stops looking like noise and starts looking like a sensible division of labour.

Troubleshooting: the symptoms and what they mean

IPv6 problems are sneaky because dual-stack hides them. Happy Eyeballs races v4 and v6 and quietly uses whichever answers first, so a thoroughly broken v6 path can look like “the internet works, just a bit slow sometimes”. Here is how to drag the failure into the light.

Symptom: pages hang for a few seconds then load. Classic broken-v6-with-v4-fallback. The browser tries v6, waits for a timeout, then falls back. Confirm by forcing each protocol:

1
2

curl -6 -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com
curl -4 -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com

If the -6 call hangs or fails while -4 is instant, your v6 path is broken upstream — usually a firewall dropping ICMPv6, a bad route, or an MTU problem.

Symptom: small requests work, large transfers stall. Almost always Path MTU discovery being broken by dropped packet-too-big ICMPv6. This is why the firewall section insisted on permitting ICMPv6. Test by pinging with a large payload and the don’t-fragment behaviour IPv6 enforces by default:

1

ping6 -s 1400 -M do example.com    # if this fails but small pings work, it's PMTUD

Symptom: addresses keep changing and break your AAAA records. Your machine is using SLAAC privacy addresses for everything, or your ISP prefix rotated. Pin a stable address on servers (static or a DHCPv6 reservation) and only let clients use the rotating temporary addresses.

Symptom: a device is reachable from the internet that shouldn’t be. Your v6 firewall has a gap your v4 rules masked. Audit from outside — an online IPv6 port scanner, or nmap -6 from a machine on a different network — and never assume “I never opened that port” means it is closed on v6.

For a home lab where this kind of misconfiguration is a real risk, it pays to have something watching. A self-hosted SIEM like the one in is Wazuh worth the RAM will flag unexpected inbound connections on v6 as readily as v4 — which matters precisely because v6 removes the accidental NAT cloak you used to rely on.

The honest caveats

It’s not all clean. Your ISP-delegated prefix may change when your connection resets, which makes static AAAA records flaky unless you use dynamic DNS for v6 too. Some ISPs are still embarrassingly behind and hand you a single /64 or nothing at all. And dual-stack means twice the firewall surface and twice the things to debug when something’s slow — Happy Eyeballs can mask a broken v6 path by silently falling back to v4, so a half-working IPv6 setup hides itself.

There is also a tooling tax. Plenty of scripts, monitoring dashboards, allowlists and home-grown automation were written assuming an address is four dotted decimals, and they choke on a colon-separated 128-bit address or on the fact that one interface now has several. Budget time to find and fix those assumptions rather than discovering them during an outage.

The verdict

If you self-host, if you’re stuck behind CGNAT, or if you simply want to actually understand the network you run, it’s well past time to take IPv6 seriously — and in 2025 that’s most people reading this. You don’t need to rip out IPv4; dual-stack is the sane goal. But enable IPv6 deliberately, firewall it as carefully as you firewall v4, and learn to read the addresses on your own machines.

The protocol is already on your network whether you engage with it or not. The only choice you’re really making is whether you’re the one in control of it, or the one surprised by it.