Network Working Group                                           J. Mogul
Request for Comments: 1191                                        DECWRL
Obsoletes: RFC 1063                                           S. Deering
                                                     Stanford University
                                                           November 1990

                           Path MTU Discovery

Status of this Memo

   This RFC specifies a protocol on the IAB Standards Track for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "IAB
   Official Protocol Standards" for the standardization state and status
   of this protocol.  Distribution of this memo is unlimited.

                           Table of Contents

       Status of this Memo                                             1
       Abstract                                                        2
       Acknowledgements                                                2
       1. Introduction                                                 2
       2. Protocol overview                                            3
       3. Host specification                                           4
           3.1. TCP MSS Option                                         5
       4. Router specification                                         6
       5. Host processing of old-style messages                        7
       6. Host implementation                                          8
           6.1. Layering                                               9
           6.2. Storing PMTU information                              10
           6.3. Purging stale PMTU information                        11
           6.4. TCP layer actions                                     13
           6.5. Issues for other transport protocols                  14
           6.6. Management interface                                  15
       7. Likely values for Path MTUs                                 15
           7.1. A better way to detect PMTU increases                 16
       8. Security considerations                                     18
       References                                                     18
       Authors' Addresses                                             19

                             List of Tables

       Table 7-1:   Common MTUs in the Internet                       17

Mogul & Deering                                                 [page 1]

RFC 1191                   Path MTU Discovery              November 1990


   This memo describes a technique for dynamically discovering the
   maximum transmission unit (MTU) of an arbitrary internet path.  It
   specifies a small change to the way routers generate one type of ICMP
   message.  For a path that passes through a router that has not been
   so changed, this technique might not discover the correct Path MTU,
   but it will always choose a Path MTU as accurate as, and in many
   cases more accurate than, the Path MTU that would be chosen by
   current practice.


   This proposal is a product of the IETF MTU Discovery Working Group.

   The mechanism proposed here was first suggested by Geof Cooper [2],
   who in two short paragraphs set out all the basic ideas that took the
   Working Group months to reinvent.

1. Introduction

   When one IP host has a large amount of data to send to another host,
   the data is transmitted as a series of IP datagrams.  It is usually
   preferable that these datagrams be of the largest size that does not
   require fragmentation anywhere along the path from the source to the
   destination.  (For the case against fragmentation, see [5].)  This
   datagram size is referred to as the Path MTU (PMTU), and it is equal
   to the minimum of the MTUs of each hop in the path.  A shortcoming of
   the current Internet protocol suite is the lack of a standard
   mechanism for a host to discover the PMTU of an arbitrary path.

          Note: The Path MTU is what in [1] is called the "Effective MTU
          for sending" (EMTU_S).  A PMTU is associated with a path,
          which is a particular combination of IP source and destination
          address and perhaps a Type-of-service (TOS).

   The current practice [1] is to use the lesser of 576 and the
   first-hop MTU as the PMTU for any destination that is not connected
   to the same network or subnet as the source.  In many cases, this
   results in the use of smaller datagrams than necessary, because many
   paths have a PMTU greater than 576.  A host sending datagrams much
   smaller than the Path MTU allows is wasting Internet resources and
   probably getting suboptimal throughput.  Furthermore, current
   practice does not prevent fragmentation in all cases, since there are
   some paths whose PMTU is less than 576.

Mogul & Deering                                                 [page 2]

RFC 1191                   Path MTU Discovery              November 1990

   It is expected that future routing protocols will be able to provide
   accurate PMTU information within a routing area, although perhaps not
   across multi-level routing hierarchies.  It is not clear how soon
   that will be ubiquitously available, so for the next several years
   the Internet needs a simple mechanism that discovers PMTUs without
   wasting resources and that works before all hosts and routers are

2. Protocol overview

   In this memo, we describe a technique for using the Don't Fragment
   (DF) bit in the IP header to dynamically discover the PMTU of a path.
   The basic idea is that a source host initially assumes that the PMTU
   of a path is the (known) MTU of its first hop, and sends all
   datagrams on that path with the DF bit set.  If any of the datagrams
   are too large to be forwarded without fragmentation by some router
   along the path, that router will discard them and return ICMP
   Destination Unreachable messages with a code meaning "fragmentation
   needed and DF set" [7].  Upon receipt of such a message (henceforth
   called a "Datagram Too Big" message), the source host reduces its
   assumed PMTU for the path.

   The PMTU discovery process ends when the host's estimate of the PMTU
   is low enough that its datagrams can be delivered without
   fragmentation.  Or, the host may elect to end the discovery process
   by ceasing to set the DF bit in the datagram headers; it may do so,
   for example, because it is willing to have datagrams fragmented in
   some circumstances.  Normally, the host continues to set DF in all
   datagrams, so that if the route changes and the new PMTU is lower, it
   will be discovered.

   Unfortunately, the Datagram Too Big message, as currently specified,
   does not report the MTU of the hop for which the rejected datagram
   was too big, so the source host cannot tell exactly how much to
   reduce its assumed PMTU.  To remedy this, we propose that a currently
   unused header field in the Datagram Too Big message be used to report
   the MTU of the constricting hop.  This is the only change specified
   for routers in support of PMTU Discovery.

   The PMTU of a path may change over time, due to changes in the
   routing topology.  Reductions of the PMTU are detected by Datagram
   Too Big messages, except on paths for which the host has stopped
   setting the DF bit.  To detect increases in a path's PMTU, a host
   periodically increases its assumed PMTU (and if it had stopped,
   resumes setting the DF bit).  This will almost always result in
   datagrams being discarded and Datagram Too Big messages being

Mogul & Deering                                                 [page 3]