IPv6 Large Transfers Stall Behind a Filtered Tunnel
A university research building has migrated its 1 Gbit/s campus uplink to dual-stack IPv4/IPv6. IPv4 transfers are normal, but after the change, several Linux compute nodes cannot complete large HTTPS downloads over IPv6: the TCP handshake finishes, the TLS ClientHello is sent, then the connection stalls until timeout. Small ICMPv6 pings succeed, but pings with 1500-byte payloads fail while 1400-byte payloads succeed. The path includes a 6in4 tunnel between two routers; its interface MTU is 1480 bytes. A new border firewall rule permits established/related traffic and ICMPv6 echo request/reply, but drops other ICMPv6 types. Application logs show retransmissions and no ICMP errors reaching the servers. The network team wants a quick workaround without disabling IPv6 or reducing all interface MTUs to 1280.
1. Explain the most likely root cause and why the failure appears only for large IPv6 transfers even though the TCP handshake succeeds.
Read the worked answer
This is an IPv6 Path MTU Discovery black hole. IPv6 routers do not fragment packets in transit; the sender must learn a smaller path MTU from an ICMPv6 Packet Too Big message, type 2. The 6in4 tunnel lowers the path MTU to 1480 bytes, so a 1500-byte packet should cause the tunnel ingress router to return a PTB. The firewall permits echo and established traffic but drops other ICMPv6 types, so the PTB never reaches the server. The handshake and ClientHello are small enough to pass; the large TLS record and data segments are not. TCP retransmits the same oversized segments until timeout, which looks like an application stall. IPv4 may appear healthy because the tunnel router can fragment IPv4 or because the IPv4 MSS is already lower.
2. Give an immediate mitigation and a durable configuration fix. Include specific values and where they should be applied.
Read the worked answer
Immediate mitigation: permit ICMPv6 type 2 in both directions at the border firewall and at any tunnel ACL, and rate-limit rather than drop it. Durable fix: set the tunnel interfaces to MTU 1480 and clamp IPv6 TCP MSS to 1400 on both tunnel routers; the calculated value is 1420 bytes (1480 minus 40 bytes IPv6 header minus 20 bytes TCP header), so 1400 leaves room for additional encapsulation. Apply the clamp where traffic enters the tunnel, and on the servers if they originate large transfers. Do not lower every interface to 1280. Confirm with packet captures that the SYN/SYN-ACK advertises the clamped MSS and that PTB messages are visible.
3. Describe a validation plan and the residual risk of simply allowing all ICMPv6.
Read the worked answer
Validate from an affected server with large pings and a controlled download, checking that PTB messages arrive and that retransmissions stop. Capture traffic at the server and tunnel ingress, inspect the MSS option, and test both directions because PMTUD depends on return-path ICMPv6. Use tracepath6 or equivalent to confirm the working path MTU. Allowing all ICMPv6 is not safe: neighbor discovery and router advertisement messages can be abused if accepted from untrusted segments. Permit only the required types, rate-limit them, and filter ICMPv6 at network boundaries. Residual risk remains if a middlebox rewrites or drops PTB after validation.