Dual‑stack clients time out to specific websites when DNS returns IPv6 (AAAA) records

Environment

Home/office dual‑stack network: clients (Windows 11, Ubuntu 22.04, Android) get both IPv4 and IPv6 addresses via SLAAC + DHCPv4. Upstream ISP supports native IPv6. Local router runs OpenWrt 21.02 with custom firewall and MTU 1500.

Symptoms

Certain public websites intermittently time out in browsers and curl when the DNS resolver returns an AAAA record; the same sites work if client forces IPv4. The problem affects web browsing, API calls from apps, and some CDN-hosted resources.

Observations

dig returns both A and AAAA for affected hosts. curl -4 <url> succeeds while curl -6 <url> times out or shows TCP handshake stalls. traceroute6 shows packets never reach beyond the ISP edge; traceroute4 completes. tcpdump on client shows SYN sent but no SYN-ACK on IPv6. MTU tests show differing path MTU behaviour; ping6 with large payloads fragments or fails. Transparent IPv6 firewall rules exist on router; no obvious DENY logs. No ISP-wide outage reported.

Already attempted

Disabled IPv6 on client as temporary workaround (connectivity restored). Flushed DNS cache and switched clients to public DNS (1.1.1.1, 9.9.9.9) with mixed results. Rebooted router and modem. Enabled/disabled firewall IPv6 rules and logged traffic — no matching deny entries. Performed tcpdump on WAN interface; saw no reply for IPv6 SYN beyond ISP gateway. Contacted ISP support, who reported no known service outage but suggested running trace.

Question

How to systematically determine whether the root cause is a broken IPv6 path (ISP/peering), MTU/fragmentation issue, or client-side misconfiguration? What diagnostic commands and temporary mitigations are recommended that avoid disabling IPv6 globally?

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

Upstream ISP or transit provider is blackholing or misrouting IPv6 traffic to specific destinations (peering/V6 transit issue). 80%

ICMPv6 'Packet Too Big' or PMTUD replies blocked upstream, causing MTU black holes for IPv6 flows that require fragmentation. 60%

Edge CDN or origin has misconfigured IPv6 announcement or rate-limits IPv6 connections from the ISP's prefix. 45%

Summary

Symptoms (AAAA responses but no TCP/handshake replies, successful IPv4, client-level IPv6 pings failing past ISP edge) point to an asymmetric/broken IPv6 path or filtering at the ISP/peering edge. MTU/fragmentation may cause some flows to fail (especially if ICMPv6 'Packet Too Big' is blocked), but pure connection failures with no SYN-ACK suggest blackholing or upstream filtering. Local firewall misconfiguration is possible but lower likelihood given traceroute6 stops at ISP. Temporary disabling of IPv6 on clients removes the symptom but masks the underlying path issue.

Suggested Fixes

Diagnostic step 1

On a failing client, run traceroute6 (tracepath6) to the destination and note the last hop that responds; capture tcpdump on client and WAN side to show IPv6 SYN packets and absence of reply.

Diagnostic step 2

From the router, run ping6 and tracepath6 toward the same destination to determine whether the path fails before or after the ISP handoff.

Diagnostic step 3

Check whether ICMPv6 'Packet Too Big' messages are being received by sending progressively larger ping6 packets (start small and increase) and/or use tracepath6 to detect PMTU. If ICMPv6 is blocked, enable/allow ICMPv6 on upstream devices temporarily for testing.