Why IPv6 quietly breaks in small offices

An ISP hands over IPv6. A router advertises it. Nothing is configured wrong, and yet one or two services feel slow for months while everything else is fine.

The mechanism is usually Happy Eyeballs working as designed against a stack that is only half usable. A client prefers IPv6 when it is available; if the IPv6 path is broken beyond the first hop, the connection attempt has to time out before falling back. Users experience this as "sometimes the page takes three seconds", which is easy to dismiss.

Two things make it worse: an advertised prefix that the upstream does not actually route, and DNS returning AAAA records for hosts that never had working IPv6. Both look healthy from the router's dashboard.

The pragmatic fix for small networks is boring — either make the IPv6 path work end to end and verify it from a client, or do not advertise it at all. Half-configured dual stack is worse than single stack, because it fails in a way that looks like the application's fault.

← All notes