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:
- Does the machine have a stable global address, or only temporary ones?
- Does the gateway answer over IPv6 from that machine?
- Does the firewall have IPv6 rules, and does it let the control messages through?
- Is the service really listening on IPv6, or only on the IPv4 address?
- 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.
Comments