Initially, Internet practice was to use an MTU of 576 bytes and to configure routers to allow a larger packet size. Even if intermediate routers used encapsulation (tunnels) that appended a few header bytes to packets, the maximum packet size wasn't reached. This generally worked, but was somewhat inefficient as it resulted in more packets and more bytes of header information than were really needed for any given amount of data sent. It also ran into trouble if a path included a link that couldn't handle 576 byte packets properly. The last was important because some hosts and clients have trouble reassembling fragmented packets.
RFC1911 proposed an MTU discovery algorithm that worked by sending packets with a "Do not fragment" bit set, and adding a value to the Destination Host Unreachable response that returned the maximum MTU for the device that took umbrage at an overly large packet. This allowed an IP server to determine the smallest MTU in a path -- the path MTU. Typically a host configured to use PMTUD will set the DF bit on all packets it sends so that it can initiate a new MTU discovery if the path changes such that the previous MTU is no longer usable. There is considerably more to RFC1911 than this incidentally -- such as definition of when it is permissible to reinitiate PMTUD to see if a larger MTU can be used. There are also a number of fine points that must be dealt with. For example, datagram lengths are not really determined by the IP protocol, they are determined by the layers like TCP that use it. If IP discovery determines a new MTU, it really needs to tell the higher level protocols about it so they can reset their maximum datagram lengths (MSS in the case of TCP).
RFC1911 also defines a Datagram Too Big message -- which is really an existing ICMP Destination Host Unreachable message with specific flags and codes set that identify the message as being due to a non-fragmentable message that is too large. The intermediate router MTU is part of that message.
The RFC1911 algorithm generally works, but may encounter several problems. A router on the path may not return its MTU because its design predates RFC1911 or it is configured to emulate such a router. Or, a router on the path may not even return a Destination Unreachable ICMP packet. Even a fully RFC1911 compliant router may encounter problem if a router between it and the host trying to perform PMTUD is configured to drop ICMP packets. The host's PMTUD messages never get a response. It is also possible for routers in a path to simply have their MTU set too high for the transport medium they are trying to use resulting in large packets failing for reasons that appear to be unrelated to message size. PMTUD won't detect that.
It is possible to turn off PMTUD and manually assign MTUs, but if that is done, it is generally strongly recommended that any two pieces of equipment that pass datagrams to each other and have manually assigned MTUs use the same MTU,
Under Windows (and presumably Linux) the path MTU can be determined by using the command "ping -l xxxx -f" where xxxx is a trial packet size. The MTU is 28 more than the largest xxxx that can be sent without getting a "packet needs fragmenting but DF set" response. When I tried this, I got an MTU of 1362 bytes over my DSL link even though everything I had read indicated that the MTU would be about 1492 bytes.
Return To Index Copyright 1994-2002 by Donald Kenney.