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.

   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.