IPv6 connections open but certain websites time out after enabling SLAAC on home router

Environment

Home network: consumer dual-stack ISP (native IPv6 + IPv4 CGNAT), Linux laptop (Ubuntu 22.04) and iPhone 13 on same Wi‑Fi SSID, router running custom open-source firmware with SLAAC/RDNSS enabled

Symptoms

Most sites load normally over IPv4. Clients obtain global IPv6 addresses via SLAAC and can ping IPv6-only hosts (e.g., ipv6.google.com). However, several external websites (including some large CDNs and certain banking sites) consistently time out or hang during the TCP handshake when the client attempts IPv6 connections; forcing IPv4 (curl -4) works instantly.

Observations

On the Linux laptop: 'ip -6 addr' shows global IPv6; 'dig AAAA' resolves the hostnames to AAAA records. 'curl -v --ipv6' stalls on 'TCP_NODELAY' / during TLS handshake. Traceroute6 from laptop shows packets reach ISP border then stop. Router firewall logs show outbound IPv6 connections allowed. Temporary disabling router firewall did not change behavior. Using cellular or tethered phone (IPv4/IPv6 via carrier) connects fine to the same problematic sites.

Already attempted

Rebooted router and clients; flushed DNS caches on router and laptop; disabled IPv6 on client to fall back to IPv4 (works); changed router DNS to Cloudflare/Google; replaced Ethernet uplink cable; tested with different devices (same result). Captured tcpdump on client and observed SYN packets leaving but no SYN-ACK for problematic hosts over IPv6.

Question

What commonly causes selective IPv6 connection failures that do not affect DNS resolution or operate over other networks, and what targeted diagnostics and fixes should I run on the router and ISP link before escalating to ISP support?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

ISP or transit provider has incorrect routing for specific IPv6 prefix ranges (packets lost after border). 90%

ICMPv6 messages blocked on router or by ISP (broken Path MTU Discovery causes TCP stalls for some sites). 55%

MTU mismatch on PPPoE or tunnel causing packets to be dropped when DF set and ICMPv6 unreachable replies blocked by middlebox/ISP. 45%

Summary

Symptoms indicate IPv6 reachability is partial: name resolution and local IPv6 addressing are fine but end-to-end TCP connectivity to some prefixes fails. Likely causes include: ISP-side IPv6 routing blackholes or filtering for specific provider prefixes, PMTU/ICMPv6 filtering causing handshake stalls for paths requiring path MTU discovery, router misconfiguration of RA/RDNSS or incorrect next-hop delegation, or transit middlebox (CDN/edge) blocking from the assigned IPv6 prefix. Local client problems are less likely since tethered/cellular networks succeed and multiple clients show same behavior.

Suggested Fixes

Diagnostic step 1

From the client, run 'tracepath -6 <hostname>' or 'mtr -6' to detect where IPv6 packets stop; capture tcpdump at the client and (if possible) at router WAN to confirm where SYNs disappear.

Diagnostic step 2

Check router IPv6 prefix delegation and routing table; ensure upstream gateway using the delegated prefix is present and that the router advertises the correct prefix via RA.

Diagnostic step 3

Temporarily set MTU lower on client (e.g., 1280) and retry to see if PMTU issues are the cause; if lowering MTU fixes connections, investigate ICMPv6 filtering.