IP MTU discovery options
RFC 1063

Document Type RFC - Unknown (July 1988; No errata)
Obsoleted by RFC 1191
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1063 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      J.  Mogul
Request For Comments: 1063                                   C. Kent
                                                                 DEC
                                                        C. Partridge
                                                                 BBN
                                                       K. McCloghrie
                                                                 TWG
                                                           July 1988

                        IP MTU Discovery Options

STATUS OF THIS MEMO

   A pair of IP options that can be used to learn the minimum MTU of a
   path through an internet is described, along with its possible uses.
   This is a proposal for an Experimental protocol.  Distribution of
   this memo is unlimited.

INTRODUCTION

   Although the Internet Protocol allows gateways to fragment packets
   that are too large to forward, fragmentation is not always desirable.
   It can lead to poor performance or even total communication failure
   in circumstances that are surprisingly common.  (For a thorough
   discussion of this issue, see [1]).

   A datagram will be fragmented if it is larger than the Maximum
   Transmission Unit (MTU) of some network along the path it follows.
   In order to avoid fragmentation, a host sending an IP datagram must
   ensure that the datagram is no larger than the Minimum MTU (MINMTU)
   over the entire path.

   It has long been recognized that the methods for discovering the
   MINMTU of an IP internetwork path are inadequate.  The methods
   currently available fall into two categories: (1) choosing small MTUs
   to avoid fragmentation or (2) using additional probe packets to
   discover when fragmentation will occur.  Both methods have problems.

   Choosing MTUs requires a balance between network utilization (which
   requires the use of the largest possible datagram) and fragmentation
   avoidance (which in the absence of knowledge about the network path
   encourages the use of small, and thus too many, datagrams).  Any
   choice for the MTU size, without information from the network, is
   likely to either fail to properly utilize the network or fail to
   avoid fragmentation.

   Probe packets have the problem of burdening the network with

Mogul, Kent, Partridge, & McCloghrie                            [Page 1]
RFC 1063                IP MTU Discovery Options               July 1988

   unnecessary packets.  And because network paths often change during
   the lifetime of a TCP connection, probe packets will have to be sent
   on a regular basis to detect any changes in the effective MINMTU.

   Implementors sometimes mistake the TCP MSS option as a mechanism for
   learning the network MINMTU.  In fact, the MSS option is only a
   mechanism for learning about buffering capabilities at the two TCP
   peers.  Separate provisions must be made to learn the IP MINMTU.

   In this memo, we propose two new IP options that, when used in
   conjunction will permit two peers to determine the MINMTU of the
   paths between them.  In this scheme, one option is used to determine
   the lowest MTU in a path; the second option is used to convey this
   MTU back to the sender (possibly in the IP datagram containing the
   transport acknowledgement to the datagram which contained the MTU
   discovery option).

OPTION FORMATS

   Probe MTU Option (Number 11)

      Format

              +--------+--------+--------+--------+
              |00001011|00000100|   2 octet value |
              +--------+--------+--------+--------+

      Definition

      This option always contains the lowest MTU of all the networks
      that have been traversed so far by the datagram.

      A host that sends this option must initialize the value field to
      be the MTU of the directly-connected network.  If the host is
      multi-homed, this should be for the first-hop network.

      Each gateway that receives a datagram containing this option must
      compare the MTU field with the MTUs of the inbound and outbound
      links for the datagram.  If either MTU is lower than the value in
      the MTU field of the option, the option value should be set to the
      lower MTU.  (Note that gateways conforming to RFC-1009 may not
      know either the inbound interface or the outbound interface at the
      time that IP options are processed.  Accordingly, support for this
      option may require major gateway software changes).

      Any host receiving a datagram containing this option should
      confirm that value of the MTU field of the option is less than or
      equal to that of the inbound link, and if necessary, reduce the

Mogul, Kent, Partridge, & McCloghrie                            [Page 2]
RFC 1063                IP MTU Discovery Options               July 1988

      MTU field value, before processing the option.

      If the receiving host is not able to accept datagrams as large as
Show full document text