Wi-Fi & Network
Should you disable IPv6 at home?
Lots of advice online says to disable IPv6 to fix slow sites or VPN leaks. Usually that masks the real problem and creates new ones. This guide explains what IPv6 is, the security model people get wrong, and what to do instead.
Who this is for
Home operators who've read 'just disable IPv6 to fix it' advice and want the honest call — whether to keep IPv6 on, what its security model actually is, and what to do instead of disabling it when something on the IPv6 path misbehaves.
Outcome
A clear decision: keep IPv6 enabled (the default), understand that your firewall — not NAT — is what protects IPv6 devices, and use 'prefer IPv4' or a targeted path fix instead of permanently disabling IPv6; with disabling kept only as a temporary diagnostic.
Required inputs
- Knowledge of whether your ISP is dual-stack or IPv6-mostly (check the router's IPv6/WAN status).
- Admin access to the device (and ideally the router) where IPv6 is misbehaving.
- The specific symptom you're trying to fix (slow/hanging sites, a VPN leak, an unreachable device) — the right action differs per symptom.
- On Windows: the ability to set the documented 'prefer IPv4' option rather than unbinding IPv6.
Step-by-step procedure
Decide based on the symptom, not the myth
Do: Name the actual problem: hanging/slow sites, a VPN leak, an unreachable device, or just generic 'I heard IPv6 is bad'. If it's the last one, the answer is keep IPv6 on. Otherwise, the right fix is symptom-specific and almost never 'disable IPv6 forever'.
Expected result: You have a concrete symptom (or realize there isn't one) driving the decision.
If not: If there's no real symptom, don't disable IPv6 preemptively — you'd only lose end-to-end reachability you increasingly need.
Understand the security model before touching anything
Do: Internalize that NAT was never the security control — your stateful firewall is. With IPv6, devices have globally-routable addresses but stay unreachable from outside because the router blocks unsolicited inbound. A sane default also allows established/related and the necessary ICMPv6.
Expected result: You no longer believe 'no NAT = exposed'; you know the firewall is the protection.
If not: If you're tempted to 'lock down' IPv6 by blocking all ICMPv6, don't — it breaks neighbor discovery and path-MTU and will cause the very slowness people blame on IPv6.
Use disabling ONLY as a temporary test
Do: If you suspect the IPv6 path, turn IPv6 off briefly to confirm the symptom disappears — then turn it back on. Treat that result as a diagnosis ('it's the IPv6 path'), not a fix.
Expected result: You've confirmed whether IPv6 is implicated, with IPv6 re-enabled afterward.
If not: If disabling didn't change the symptom, IPv6 wasn't the cause — re-enable it and look elsewhere.
Fix the actual fault instead of leaving IPv6 off
Do: For slow/hanging sites, fix MTU/ICMPv6 (stop filtering ICMPv6 'Packet Too Big' or clamp MSS). For a VPN leak, configure the VPN to handle or block IPv6. For an unreachable device, recognize the firewall is working and add a narrow allow only if you want it exposed.
Expected result: The root cause is addressed with IPv6 still enabled.
If not: If you can't fix the path immediately, use 'prefer IPv4' as a stopgap rather than a permanent disable (next step).
If you must de-prioritize IPv6, prefer IPv4 (don't unbind)
Do: On Windows, set the documented 'prefer IPv4 over IPv6' option (DisabledComponents = 0x20) so IPv6 stays available but isn't tried first. Never use 0xFFFFFFFF (the correct full-disable value is 0xFF, and the wrong one causes a startup delay); don't unbind IPv6 from the adapter (unsupported).
Expected result: IPv4 wins by default while IPv6 remains functional for components that need it.
If not: If even 'prefer IPv4' doesn't help, the problem isn't IPv6 ordering — return to the path diagnosis.
Commands and settings paths
Confirm whether IPv6 is even the cause
curl -6 -m 5 https://example.com vs curl -4 -m 5 https://example.com (and test-ipv6.com)
Where: On the affected device.
Expected: If IPv4 is fine and IPv6 fails/slows, the IPv6 path is implicated; if both are fine, there's nothing to disable.
Failure means: A symptom that persists with IPv6 off lives elsewhere.
Safe next step: Fix the path (MTU/ICMPv6, VPN IPv6) rather than leaving IPv6 disabled.
Set 'prefer IPv4' instead of disabling (Windows)
netsh interface ipv6 show prefixpolicies (verify); use DisabledComponents=0x20 for prefer-IPv4
Where: On a Windows host.
Expected: Prefix policies show IPv4 preferred while IPv6 remains bound and functional.
Failure means: Using 0xFFFFFFFF or unbinding IPv6 is the wrong move (startup delay / unsupported).
Safe next step: Use 0x20 (prefer IPv4) or 0xFF only if a true disable is genuinely required.
Evidence to record
- The specific symptom and whether toggling IPv6 off temporarily changed it.
- Whether your ISP is dual-stack or IPv6-mostly (router IPv6/WAN status).
- What you actually changed (path fix, VPN IPv6 setting, or 'prefer IPv4') — and that IPv6 is left enabled.
- Confirmation you did NOT blanket-block ICMPv6 or unbind IPv6.
Common mistakes
- Disabling IPv6 permanently as a 'fix' — it masks the real fault and can break OS components (Microsoft advises against it).
- Believing 'no NAT means IPv6 is insecure' — the stateful firewall is the protection, not NAT.
- Blanket-blocking ICMPv6 to 'lock down' IPv6, which breaks neighbor discovery and path-MTU (and causes slowness).
- Using DisabledComponents=0xFFFFFFFF (wrong value, causes a startup delay) or unbinding IPv6 from the adapter (unsupported on Windows).
Stop points
- Stop before permanently disabling IPv6 to fix a symptom you haven't traced to the IPv6 path.
- Stop before blocking all ICMPv6 — keep the ICMPv6 types IPv6 needs to function.
Last reviewed
2026-06-02
Source-backed checks
HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.