FULL AI ANALYSIS

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

Generated Oct 3, 2026, 12:35:03 AM

Analysis 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.

Possible 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%

Router or firewall misconfiguration dropping or rate-limiting IPv6 TCP SYN/ACK (incorrect NAT64/DNS64 or firewall rule).

25%

Suggested fixes

1

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.

2

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.

3

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.

4

Diagnostic step 4

Temporarily set affected clients to prefer IPv4 only (avoid disabling IPv6 globally on infrastructure) and collect packet captures showing failed IPv6 attempts. Use those captures when contacting the ISP; ask them to confirm IPv6 reachability from their edge.

5

Diagnostic step 5

If possible, test from a different upstream (mobile hotspot v4/v6) or tunnel (e.g., Hurricane Electric IPv6 tunnel) to see if the destination is reachable over IPv6 from another path — helps identify whether issue is local ISP-specific or destination-specific.