Path maximum transmission unit (PMTU) discovery is the process of discovering the maximum size of packet that can be sent across the network between two hosts without fragmentation (that is, without the packet being broken into multiple frames during transmission). For more information, see RFC 1191: Path MTU Discovery.

Avoiding Packet Fragmentation

Different media technologies and networks support different maximum sizes for data frames traveling across the network. When sending large amounts of data between two hosts, it is advantageous to minimize the amount of fragmentation that occurs. One reason for this is that disassembly into multiple packets and reassembly of the fragmented packets into the original packet requires extra processing time, increasing latency. Another reason is that each additional packet transmitted also requires header information, resulting in a greater number of both frames and bytes being sent across the network.

If the sending and receiving sides of a network conversation both have information about the MTU, the stack can ensure that fragmentation does not occur, thus improving throughput and the users' perception of application performance.

Determining Path MTU Size from MSS

When a Transmission Control Protocol (TCP) connection is established, the two hosts involved exchange their TCP maximum segment size (MSS) values. The smaller of the two MSS values is used for the connection.

In the past, the MSS for a host has been the MTU at the link layer minus 40 bytes for the Internet Protocol (IP) and TCP headers, where no IP or TCP options are in use. If IP or TCP options are specified, the MSS is further reduced by the number of bytes taken up by the options, each of which may be a single octet or multiple octets in size. Note that each multiple-octet TCP option specified includes a 1-octet type indicating which option is being negotiated, a 1-octet option length, and a variable-length value.

However, support in Windows 2000, Windows XP, and Windows Server 2003 for additional TCP options, such as time stamps, has increased the typical TCP/IP header to 52 or more octets. Once all options have been added to the header, the header is padded to a 32-bit boundary. The resulting header length is subtracted from the MSS to determine the effective path MTU.

The diagram following shows the difference between MTU and MSS.

Sending an ICMP Error Message to Adjust MSS Size

When TCP segments are destined for a nonlocal network, the Don't Fragment (DF) flag is set in the IP header. This flag is set to prevent data fragmentation along the path between the two hosts. Any link along the path between the two hosts can have an MTU smaller than that of the hosts, indicating a smaller low-level frame size is being used to send data along that link. If the DF bit is not set in the IP header and a link has an MTU that is too small for the IP datagram being routed, the router attempts to fragment the datagram, placing it into multiple frames for transmission on that link. Fragmenting a datagram results in it being broken up into multiple segments, which in turn results in an increase in bytes transmitted (and thus transmission time). Fragmenting a datagram also creates issues such as a packet's potentially not making it to its destination because it has to cross a network security perimeter that rejects fragmented packets. In general, any time an intermediate link exists for which the MTU is smaller than that of the sending host, the datagram must be fragmented to pass through that link.

When a router encounters a too-small MTU for a segment with the DF flag set, it should inform the sending host that the datagram cannot be forwarded further without fragmentation. To inform the host, the router sends a Destination Unreachable-Fragmentation Needed and DF Set message, an Internet Control Message Protocol (ICMP) error message. Most routers also specify the MTU for the next hop (which would cause fragmentation due to being smaller than the sending MTU) by putting the value for it in the low-order 16 bits of the ICMP header field that RFC 792: Internet Control Message Protocol DARPA Internet Program Protocol Specification designates as unused. Doing so informs the sender of the maximum acceptable packet size for that communication path. For the format of this message, see section 4 of RFC 1191: Path MTU Discovery. For more information on , see RFC 792: Internet Control Message Protocol DARPA Internet Program Protocol Specification.

Upon receiving this ICMP error message, TCP automatically adjusts its MSS for the connection to the MTU specified in the ICMP message, minus the combined size of the TCP and IP headers, so that any further packets sent on the connection are no larger than the maximum size that can traverse the path without fragmentation.

The minimum MTU permitted is 88 bytes, and Windows Server 2003 TCP/IP enforces this limit.

Working Around Noncompliant Routers

Some noncompliant routers silently drop IP datagrams that cannot be fragmented or do not correctly report their next-hop MTU.

To work around these problematic devices, changes can be made to the Windows Server 2003 TCP/IP stack by editing these registry values within the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters key:

• EnablePMTUBHDetect. This value adjusts the PMTU discovery algorithm to attempt to detect noncompliant routers, also called PMTU black hole routers. PMTU black hole detection is disabled by default but can be enabled by adding this value to the registry key and setting it to 1.
• EnablePMTUDiscovery. This value enables or disables the PMTU discovery mechanism, helping to diagnose problems with black hole routers. PMTU discovery is enabled by default but can be disabled by adding this value to the registry key and setting it to 0.

  PMTU discovery is enabled so that the two sides of a conversation can negotiate the most efficient MTU. When PMTU discovery is disabled, an MSS of 536 bytes and an MTU of 540 bytes are used for all non-local destination addresses.

  Note   On nonsecure networks, allowing PMTU discovery carries the risk that an attacker might force the MTU to a very small value and overwork the local system's TCP/IP stack.

See Also

Windows TCP Implementation Features