rfc1191.txt

RFC 的详细文档！

   Actually, many TCP implementations always send an MSS option, but set
   the value to 536 if the destination is non-local.  This behavior was
   correct when the Internet was full of hosts that did not follow the
   rule that datagrams larger than 576 octets should not be sent to
   non-local destinations.  Now that most hosts do follow this rule, it
   is unnecessary to limit the value in the TCP MSS option to 536 for
   non-local peers.

   Moreover, doing this prevents PMTU Discovery from discovering PMTUs
   larger than 576, so hosts SHOULD no longer lower the value they send


Mogul & Deering                                                 [page 5]


RFC 1191                   Path MTU Discovery              November 1990




   in the MSS option.  The MSS option should be 40 octets less than the
   size of the largest datagram the host is able to reassemble (MMS_R,
   as defined in [1]); in many cases, this will be the architectural
   limit of 65495 (65535 - 40) octets.  A host MAY send an MSS value
   derived from the MTU of its connected network (the maximum MTU over
   its connected networks, for a multi-homed host); this should not
   cause problems for PMTU Discovery, and may dissuade a broken peer
   from sending enormous datagrams.

          Note: At the moment, we see no reason to send an MSS greater
          than the maximum MTU of the connected networks, and we
          recommend that hosts do not use 65495.  It is quite possible
          that some IP implementations have sign-bit bugs that would be
          tickled by unnecessary use of such a large MSS.


4. Router specification

   When a router is unable to forward a datagram because it exceeds the
   MTU of the next-hop network and its Don't Fragment bit is set, the
   router is required to return an ICMP Destination Unreachable message
   to the source of the datagram, with the Code indicating
   "fragmentation needed and DF set".  To support the Path MTU Discovery
   technique specified in this memo, the router MUST include the MTU of
   that next-hop network in the low-order 16 bits of the ICMP header
   field that is labelled "unused" in the ICMP specification [7].  The
   high-order 16 bits remain unused, and MUST be set to zero.  Thus, the
   message has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 3    |   Code = 4    |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           unused = 0          |         Next-Hop MTU          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Internet Header + 64 bits of Original Datagram Data      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The value carried in the Next-Hop MTU field is:

          The size in octets of the largest datagram that could be
          forwarded, along the path of the original datagram, without
          being fragmented at this router.  The size includes the IP
          header and IP data, and does not include any lower-level
          headers.


Mogul & Deering                                                 [page 6]


RFC 1191                   Path MTU Discovery              November 1990




   This field will never contain a value less than 68, since every
   router "must be able to forward a datagram of 68 octets without
   fragmentation" [8].


5. Host processing of old-style messages

   In this section we outline several possible strategies for a host to
   follow upon receiving a Datagram Too Big message from an unmodified
   router (i.e., one where the Next-Hop MTU field is zero).  This
   section is not part of the protocol specification.

   The simplest thing for a host to do in response to such a message is
   to assume that the PMTU is the minimum of its currently-assumed PMTU
   and 576, and to stop setting the DF bit in datagrams sent on that
   path.  Thus, the host falls back to the same PMTU as it would choose
   under current practice (see section 3.3.3 of "Requirements for
   Internet Hosts -- Communication Layers" [1]).  This strategy has the
   advantage that it terminates quickly, and does no worse than existing
   practice.  It fails, however, to avoid fragmentation in some cases,
   and to make the most efficient utilization of the internetwork in
   other cases.

   More sophisticated strategies involve "searching" for an accurate
   PMTU estimate, by continuing to send datagrams with the DF bit while
   varying their sizes.  A good search strategy is one that obtains an
   accurate estimate of the Path MTU without causing many packets to be
   lost in the process.

   Several possible strategies apply algorithmic functions to the
   previous PMTU estimate to generate a new estimate.  For example, one
   could multiply the old estimate by a constant (say, 0.75).  We do NOT
   recommend this; it either converges far too slowly, or it
   substantially underestimates the true PMTU.

   A more sophisticated approach is to do a binary search on the packet
   size.  This converges somewhat faster, although it still takes 4 or 5
   steps to converge from an FDDI MTU to an Ethernet MTU.  A serious
   disadvantage is that it requires a complex implementation in order to
   recognize when a datagram has made it to the other end (indicating
   that the current estimate is too low).  We also do not recommend this
   strategy.

   One strategy that appears to work quite well starts from the
   observation that there are, in practice, relatively few MTU values in
   use in the Internet.  Thus, rather than blindly searching through
   arbitrarily chosen values, we can search only the ones that are


Mogul & Deering                                                 [page 7]


RFC 1191                   Path MTU Discovery              November 1990




   likely to appear.  Moreover, since designers tend to chose MTUs in
   similar ways, it is possible to collect groups of similar MTU values
   and use the lowest value in the group as our search "plateau".  (It
   is clearly better to underestimate an MTU by a few per cent than to
   overestimate it by one octet.)

   In section 7, we describe how we arrived at a table of representative
   MTU plateaus for use in PMTU estimation.  With this table,
   convergence is as good as binary search in the worst case, and is far
   better in common cases (for example, it takes only two round-trip
   times to go from an FDDI MTU to an Ethernet MTU).  Since the plateaus
   lie near powers of two, if an MTU is not represented in this table,
   the algorithm will not underestimate it by more than a factor of 2.

   Any search strategy must have some "memory" of previous estimates in
   order to chose the next one.  One approach is to use the
   currently-cached estimate of the Path MTU, but in fact there is
   better information available in the Datagram Too Big message itself.
   All ICMP Destination Unreachable messages, including this one,
   contain the IP header of the original datagram, which contains the
   Total Length of the datagram that was too big to be forwarded without
   fragmentation.  Since this Total Length may be less than the current
   PMTU estimate, but is nonetheless larger than the actual PMTU, it may
   be a good input to the method for choosing the next PMTU estimate.

          Note: routers based on implementations derived from 4.2BSD
          Unix send an incorrect value for the Total Length of the
          original IP datagram.  The value sent by these routers is the
          sum of the original Total Length and the original Header
          Length (expressed in octets).  Since it is impossible for the
          host receiving such a Datagram Too Big message to know if it
          sent by one of these routers, the host must be conservative
          and assume that it is.  If the Total Length field returned is
          not less than the current PMTU estimate, it must be reduced by
          4 times the value of the returned Header Length field.

   The strategy we recommend, then, is to use as the next PMTU estimate
   the greatest plateau value that is less than the returned Total
   Length field (corrected, if necessary, according to the Note above).


6. Host implementation

   In this section we discuss how PMTU Discovery is implemented in host
   software.  This is not a specification, but rather a set of
   suggestions.

   The issues include:

Mogul & Deering                                                 [page 8]


RFC 1191                   Path MTU Discovery              November 1990




      - What layer or layers implement PMTU Discovery?

      - Where is the PMTU information cached?

      - How is stale PMTU information removed?

      - What must transport and higher layers do?


6.1. Layering

   In the IP architecture, the choice of what size datagram to send is
   made by a protocol at a layer above IP.  We refer to such a protocol
   as a "packetization protocol".  Packetization protocols are usually
   transport protocols (for example, TCP) but can also be higher-layer
   protocols (for example, protocols built on top of UDP).

   Implementing PMTU Discovery in the packetization layers simplifies
   some of the inter-layer issues, but has several drawbacks: the
   implementation may have to be redone for each packetization protocol,
   it becomes hard to share PMTU information between different
   packetization layers, and the connection-oriented state maintained by
   some packetization layers may not easily extend to save PMTU
   information for long periods.

   We therefore believe that the IP layer should store PMTU information
   and that the ICMP layer should process received Datagram Too Big
   messages.  The packetization layers must still be able to respond to
   changes in the Path MTU, by changing the size of the datagrams they
   send, and must also be able to specify that datagrams are sent with
   the DF bit set.  We do not want the IP layer to simply set the DF bit
   in every packet, since it is possible that a packetization layer,
   perhaps a UDP application outside the kernel, is unable to change its
   datagram size.  Protocols involving intentional fragmentation, while
   inelegant, are sometimes successful (NFS being the primary example),
   and we do not want to break such protocols.

   To support this layering, packetization layers require an extension
   of the IP service interface defined in [1]:

          A way to learn of changes in the value of MMS_S, the "maximum
          send transport-message size", which is derived from the Path
          MTU by subtracting the minimum IP header size.






Mogul & Deering                                                 [page 9]


RFC 1191                   Path MTU Discovery              November 1990




6.2. Storing PMTU information

   In general, the IP layer should associate each PMTU value that it has
   learned with a specific path.  A path is identified by a source
   address, a destination address and an IP type-of-service.  (Some
   implementations do not record the source address of paths; this is
   acceptable for single-homed hosts, which have only one possible
   source address.)

          Note: Some paths may be further distinguished by different
          security classifications.  The details of such classifications
          are beyond the scope of this memo.

   The obvious place to store this association is as a field in the
   routing table entries.  A host will not have a route for every
   possible destination, but it should be able to cache a per-host route
   for every active destination.  (This requirement is already imposed
   by the need to process ICMP Redirect messages.)

   When the first packet is sent to a host for which no per-host route
   exists, a route is chosen either from the set of per-network routes,
   or from the set of default routes.  The PMTU fields in these route