Cisco Blogs


Cisco Blog > Enterprise Networks

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…

HISTORY

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.

FALLOUT

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.

Tags: , ,

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

4 Comments.


  1. I’m not sure if your home network includes routers but an issue I’m discovering while trying to implement ipv6 in my application is that there doesn’t seem to be a way to discover the optimal MTU on a LAN that doesn’t include routers.

    The IP_PACKET_TOO_BIG reply is not returned by a receiving software host (at least Windows 7 doesn’t) and so there is no way to confirm that a packet larger then 1280 is getting through without fragmentation.

       0 likes

    • Phillip Remaker

      How are you implementing IPv6 in your application? I would think that the Windows Sockets APIs would handle a lot of that heavy lifting for you. What exactly are you observing?

         0 likes

  2. Hi Phillip

    The issue has turned out to be that Windows doesn’t supply the header info AT ALL to the socket functions so I’m not able to read the reply. I’m at a bit of a loss as to how to do path MTU discovery if I’m not able to know when the packets are requiring fragmentation…

       0 likes

  3. I should expand on my last post and mention that I’ve also attempted to use the Icmp6SendEcho2() function and parse the replies using IcmpParseReplies().

    What I’m seeing in this case is that the EchoReply -> Status is always 0 even if the packet had to be fragmented. The other info (ReturnTripTime and the Address info) are correct.

       0 likes