IPv6 MTU Gotchas and other ICMP issues
From my home network, I can successfully ping or traceroute to some IPv6 hosts, but I cannot subsequently open a web page or use other applications with it. How can this be? Maximum Transmission Unit (MTU) gotchas…
There is a subtle difference between IPv4 and IPv6 fragmentation strategies. IPv4 routers fragment traffic in the network when needed and then the receiving host reassembles those fragments. This generally works well, but there are a number of potential issues. Because of these issues, the IETF developed means for higher layer protocols such as TCP to determine the smallest MTU on a path and send appropriately sized datagrams in order to avoid fragmentation. The IPv6 designers presumed the presence of this Path MTU Discovery so that in IPv6, fragmentation no longer happens in the network but only at the hosts – and then only in special cases in that absolutely require it.
The designers also made another assumption. Since modern networks use MTUs of 1500 bytes or larger, they raised the IPv4 MTU minimum of 576 bytes to 1500 bytes for IPv6. Now, when tunnels are in use, the tunnel MTU has to be reduced so that the outer datagram is no larger than the link MTU (usually 1500 bytes). As a result, IPv6 hosts will accept a Path MTU that is as low as 1280 bytes, but not necessarily smaller.
There is an unfortunate interaction between those decisions and the implementation of Path MTU algorithm prescribed by RFC 1981, which is discussed in RFC 2923. Path MTU historically depends on an ICMP/ICMPv6 Packet Too Big message from the system that discards a datagram because it is too large for the next link. If for some reason the sender of the datagram never gets the signal, it doesn’t know to change its behavior; that might happen if a firewall filters such messages out or a router is configured to not send them. As a result, a web page, file, or video stream that seems like it should get through doesn’t. There is a newer proposal in RFC 4821 that tries various packet sizes to see what works; that helps, but isn’t yet widely implemented. Stay tuned on that score.
The scariest part of this phenomenon is that it isn’t limited to the network; add-on security software could be configured configured to not accept ICMPv6 messages resulting in delays in opening connections, MTU problems, and stalled connections. Such a rule might be compared to configuring an IPv4 host to not accept ARP and then wondering why it can’t communicate with its neighbors.
WHAT CAN YOU DO?
A word to the wise: in today’s IPv6 Internet, there are many tunnels. That will change, but they never quite go away because of IP/IP VPNs. Do not filter out ICMPv6 Packet Too Big or Destination Unreachable messages, and while you might rate-limit them, do not configure routers to not send them, nor your hosts not to accept them. They enable the network to inform the transport of issues, and as a result, to work around them. More generally, RFC 4890 contains “Recommendations for Filtering ICMPv6 Messages in Firewalls,” which includes filters in the network and those in hosts.