IPv6 in the homelab: why it breaks, and how to diagnose it without disabling everything

Key takeaways

• With IPv6, every machine gets a routable public address: without address translation, the implicit barrier IPv4 provided is gone.
• The IPv6 firewall is separate from the IPv4 one: rules written on one side do not protect the other.
• Temporary addresses rotate regularly by design — hence internal services that become unreachable.
• An unstable prefix handed out by the ISP renumbers the entire network on every renegotiation.
• Classic slowness symptom: the client tries IPv6 first, fails, then falls back to IPv4 after a timeout.

IPv6 rarely half-works: either you never notice it, or it produces baffling symptoms. A service that answers over IPv4 but not over IPv6, an address you wrote down that stops working the following week, a firewall that seems not to apply.

The reflex is to disable the whole thing. That is a deferred problem — and often a source of further inconsistent behavior.

The fundamental difference: no more address translation

On home IPv4, all your machines share one public address through address translation. That translation was never a security device, but it had the effect of one: without an explicit forward, nothing from the outside can initiate a connection to your machines.

Under IPv6, that mechanism disappears. Every machine receives a directly routable public address. It is a return to the internet's original model, technically cleaner — but the implicit barrier you were benefiting from without knowing it no longer exists.

Protection now rests entirely on the firewall. And that is where the first problem shows up.

The firewall that protects only half

IPv4 and IPv6 rules are separate. Many configuration tools do not apply them to both protocols automatically.

The typical scenario: you write your rules, you check from the outside that a port is indeed closed, everything looks right. But your test went out over IPv4, while the service is listening and still reachable over IPv6.

A machine can therefore be directly reachable from the internet while its IPv4 counterpart is perfectly protected.

Addresses that change on their own

Second source of confusion: a machine normally holds several IPv6 addresses at once.

A link-local address, usable only on the segment. One or more global addresses built from the advertised prefix. And temporary addresses, renewed regularly for outbound connections, meant to limit tracking.

That last mechanism is intended, and desirable on a client workstation. It is a problem on a server: the address you noted down is no longer valid a few days later, and the service becomes unreachable with nothing having visibly changed.

Anything that needs to be reached requires a stable address — explicitly configured, or derived from an identifier that does not vary — and that one, and only that one, is what belongs in your DNS.

The prefix that moves

Sometimes the problem sits further upstream. Some providers do not delegate a stable prefix: on every renegotiation, you receive a new block of addresses.

The whole network is then renumbered. Addresses change, hard-coded firewall rules no longer match, DNS records point nowhere.

Two possible answers. Ask for a fixed prefix, where the plan allows it. Or use unique local addresses internally: a private, stable space, not routable on the internet, for everything that has to keep a constant address. Your internal services rely on those, external connectivity uses the public prefix — variable, but without consequence, since nothing critical depends on it any more.

Connections that are slow to start

A frequent and poorly identified symptom: connections take a few seconds to establish, then work normally.

That is the signature of IPv6 being advertised but not working. The client sees an IPv6 address available, prefers it, attempts the connection, waits for the timeout, then falls back to IPv4.

The fast-fallback mechanism in modern systems shortens that delay but does not eliminate it. And the cause is almost always an incomplete configuration: a prefix advertised without a working route, or a firewall blocking the control messages the protocol needs.

The control-message trap

One last point, and it deserves emphasis: under IPv6, control messages are not optional.

Neighbor discovery, router advertisement and path MTU discovery depend on them entirely. Under IPv4, blocking ICMP degraded operation; under IPv6, it breaks the protocol.

A firewall rule that blanket-drops ICMPv6 produces spectacular symptoms that are hard to trace back to their cause: machines that can no longer find their gateway, connections that hang on large transfers, addresses that stop configuring themselves.

The diagnostic method

In order, stopping at the first problem found:

1. Does the machine have a stable global address, or only temporary ones?
2. Does the gateway answer over IPv6 from that machine?
3. Does the firewall have IPv6 rules, and does it let the control messages through?
4. Is the service really listening on IPv6, or only on the IPv4 address?
5. Is DNS returning an address that is still valid?

Four times out of five, the answer is at step 1 or 3. And in every case, testing explicitly over IPv6 rather than letting the system pick the protocol keeps you from concluding too fast.