rfc1191.txt

RFC 的详细文档！

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




Abstract

   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.


Acknowledgements

   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
   modified.


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]


RFC 1191                   Path MTU Discovery              November 1990




   generated, because in most cases the PMTU of the path will not have
   changed, so it should be done infrequently.

   Since this mechanism essentially guarantees that host will not
   receive any fragments from a peer doing PMTU Discovery, it may aid in
   interoperating with certain hosts that (improperly) are unable to
   reassemble fragmented datagrams.


3. Host specification

   When a host receives a Datagram Too Big message, it MUST reduce its
   estimate of the PMTU for the relevant path, based on the value of the
   Next-Hop MTU field in the message (see section 4).  We do not specify
   the precise behavior of a host in this circumstance, since different
   applications may have different requirements, and since different
   implementation architectures may favor different strategies.

   We do require that after receiving a Datagram Too Big message, a host
   MUST attempt to avoid eliciting more such messages in the near
   future.  The host may either reduce the size of the datagrams it is
   sending along the path, or cease setting the Don't Fragment bit in
   the headers of those datagrams.  Clearly, the former strategy may
   continue to elicit Datagram Too Big messages for a while, but since
   each of these messages (and the dropped datagrams they respond to)
   consume Internet resources, the host MUST force the PMTU Discovery
   process to converge.

   Hosts using PMTU Discovery MUST detect decreases in Path MTU as fast
   as possible.  Hosts MAY detect increases in Path MTU, but because
   doing so requires sending datagrams larger than the current estimated
   PMTU, and because the likelihood is that the PMTU will not have
   increased, this MUST be done at infrequent intervals.  An attempt to
   detect an increase (by sending a datagram larger than the current
   estimate) MUST NOT be done less than 5 minutes after a Datagram Too
   Big message has been received for the given destination, or less than
   1 minute after a previous, successful attempted increase.  We
   recommend setting these timers at twice their minimum values (10
   minutes and 2 minutes, respectively).

   Hosts MUST be able to deal with Datagram Too Big messages that do not
   include the next-hop MTU, since it is not feasible to upgrade all the
   routers in the Internet in any finite time.  A Datagram Too Big
   message from an unmodified router can be recognized by the presence
   of a zero in the (newly-defined) Next-Hop MTU field.  (This is
   required by the ICMP specification [7], which says that "unused"
   fields must be zero.)  In section 5, we discuss possible strategies


Mogul & Deering                                                 [page 4]


RFC 1191                   Path MTU Discovery              November 1990




   for a host to follow in response to an old-style Datagram Too Big
   message (one sent by an unmodified router).

   A host MUST never reduce its estimate of the Path MTU below 68
   octets.

   A host MUST not increase its estimate of the Path MTU in response to
   the contents of a Datagram Too Big message.  A message purporting to
   announce an increase in the Path MTU might be a stale datagram that
   has been floating around in the Internet, a false packet injected as
   part of a denial-of-service attack, or the result of having multiple
   paths to the destination.


3.1. TCP MSS Option

   A host doing PMTU Discovery must obey the rule that it not send IP
   datagrams larger than 576 octets unless it has permission from the
   receiver.  For TCP connections, this means that a host must not send
   datagrams larger than 40 octets plus the Maximum Segment Size (MSS)
   sent by its peer.

          Note: The TCP MSS is defined to be the relevant IP datagram
          size minus 40 [9].  The default of 576 octets for the maximum
          IP datagram size yields a default of 536 octets for the TCP
          MSS.

   Section 4.2.2.6 of "Requirements for Internet Hosts -- Communication
   Layers" [1] says:

          Some TCP implementations send an MSS option only if the
          destination host is on a non-connected network.  However, in
          general the TCP layer may not have the appropriate information
          to make this decision, so it is preferable to leave to the IP
          layer the task of determining a suitable MTU for the Internet
          path.