rfc1063.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 619 行 · 第 1/2 页

      IP to fit the options into the datagram.  Thus, insertion of the
      Probe MTU or Reply MTU option may violate the MSS restriction.
      Because, unlike other IP options, the MTU options can be inserted
      without the knowledge of the transport layer, the implementor must
      carefully consider the implications of adding options to an IP
      datagram.

      One approach is to reserve 4 bytes from the MINMTU reported to the
      transport layer; this will allow the IP layer to insert at least
      one MTU option in every datagram (it can compare the size of the
      outgoing datagram with the MINMTU stored in the route cache to see
      how much room there actually is).  This is simple to implement,
      but does waste a little bandwidth in the normal case.

      Another approach is to provide a means for the IP layer to notify
      the transport layer that space must be reserved for sending an
      option; the transport layer would then make a forthcoming segment
      somewhat smaller than usual.

   When a Probe Can Be Sent

      A system that receives a Probe MTU option should always respond
      with a Reply MTU option, unless the probe was sent to an IP or LAN
      broadcast address.



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


      A Probe MTU option should be sent in any of the following
      situations:

         (1) The MINMTU for the path is not yet known;

         (2) A received datagram suffers a fragmentation re-assembly
             timeout. (This is a strong hint the path has changed;
             send a probe to the datagram's source);

         (3) An ICMP Time Exceeded/Fragmentation Reassembly Timeout is
             received (this is the only message we will get that
             indicates fragmentation occurred along the network path);

         (4) The transport layer requests it.

      Implementations may also wish to periodically probe a path, even
      if there is no indication that fragmentation is occurring.  This
      practice is perfectly reasonable; if fragmentation and reassembly
      is working perfectly, the sender may never get any indication that
      the path MINMTU has changed unless a probe is sent.  We recommend,
      however, that implementations send such periodic probes sparingly.
      Once every few minutes, or once every few hundred datagrams is
      probably sufficient.

      There are also some scenarios in which the Probe MTU should not be
      sent, even though there may be some indication of an MINMTU
      change:

         (1) Probes should not be sent in response to the receipt of
             a probe option.  Although the fact that the remote peer
             is probing indicates that the MINMTU may have changed,
             sending a probe in response to a probe causes a continuous
             exchange of probe options.

         (2) Probes must not be sent in response to fragmented
             datagrams except when the fragmentation reassembly
             of the datagram fails.  The problem in this case is
             that the receiver has no mechanism for informing the remote
             peer that fragmentation has occurred, unless fragmentation
             reassembly fails (in which case an ICMP message is sent).
             Thus, a peer may use the wrong MTU for some time before
             discovering a problem.  If we probe on fragmented
             datagrams, we may probe, unnecessarily, for some time
             until the remote peer corrects its MTU.

         (3) For compatibility with hosts that do not implement the
             option, no Probe MTU Option should be sent more than
             ten times without receiving a Reply MTU Option or a



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


             Probe MTU Option from the remote peer.  Peers which
             ignore probes and do not send probes must be treated
             as not supporting probes.

         (4) Probes should not be sent to an IP or LAN broadcast
             address.

         (5) We recommend that Probe MTUs not be sent to other hosts
             on the directly-connected network, but that this feature
             be configurable.  There are situations (for example, when
             Proxy ARP is in use) where it may be difficult to determine
             which systems are on the directly-connected network.  In
             this case, probing may make sense.

SAMPLE IMPLEMENTATION SKETCH

   We present here a somewhat more concrete description of how an IP-
   layer implementation of MTU probing might be designed.

   First, the routing cache entries are enhanced to store seven
   additional values:

      MINMTU: The current MINMTU of the path.

      ProbeRetry: A timestamp indicating when the next probe
                  should be sent.

      LastDecreased: A timestamp showing when the MTU was
                     last decreased.

      ProbeReply: A bit indicating a Reply MTU option should be
                  sent.

      ReplyMTU: The value to go in the Reply MTU option.

      SupportsProbes: A bit indicating that the remote peer
                      can deal with probes (always defaults to
                      1=true).

      ConsecutiveProbes: The number of probes sent without
                         the receipt of a Probe MTU or Reply
                         MTU option.

   There are also several configuration parameters; these should be
   configurable by appropriate network management software; the values
   we suggest are "reasonable":

      Default_MINMTU: The default value for the MINMTU field of the



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


                      routing cache entry, to be used when the real
                      MINMTU is unknown.  Recommended value: 576.

      Max_ConsecutiveProbs: The maximum number of probes to send
                            before assuming that the destination does
                            not support the probe option.
                            Recommended value: 10.

      ProbeRetryTime: The time (in seconds) to wait before retrying
                      an unanswered probe.  Recommended value:
                      60 seconds, or 2*RTT if the the RTT is available
                      to the IP layer.

      ReprobeInterval: The time to wait before sending a probe after
                       receiving a successful Reply MTU, in order to
                       detect increases in the route's MINMTU.
                       Recommended value: 5 times the ProbeRetryTime.

      IncreaseInterval: The time to wait before increasing the MINMTU
                        after the value has been decreased, to prevent
                        flapping.  Recommended value: same as
                        ProbeRetryTime.

   When a new route is entered into the routing cache, the initial
   values should be set as follows:

      MINMTU = Default_MINMTU

      ProbeRetry = Current Time

      LastDecreased = Current Time - IncreaseInterval

      ProbeReply = false

      SupportsProbes = true

      ConsecutiveProbes = 0

   This initialization is done before attempting to send the first
   packet along this route, so that the first packet will contain a
   Probe MTU option.

   Whenever the IP layer sends a datagram on this route it checks the
   SupportsProbes bit to see if the remote system supports probing.  If
   the SupportsProbes bit is set, and the timestamp in ProbeRetry is
   less than or equal to the current time, a Probe option should be sent
   in the datagram, and the ProbeRetry field incremented by
   ProbeRetryTime.



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


   Whether or not the Probe MTU option is sent in a datagram, if the
   ProbeReply bit is set, then a Reply MTU option with the value of the
   ReplyMTU field is placed in the outbound datagram.  The ProbeReply
   bit is then cleared.

   Every time a Probe option is sent, the ConsecutiveProbes value should
   be incremented.  If this value reaches Max_ConsecutiveProbes, the
   SupportsProbe bit should be cleared.

   When an IP datagram containing the Probe MTU option is received, the
   receiving IP sets the ReplyMTU to the Probe MTU option value and sets
   the ProbeReply bit in its outbound route to the source of the
   datagram.  The SupportsProbe bit is set, and the ConsecutiveProbes
   value is reset to 0.

   If an IP datagram containing the Reply MTU option is received, the IP
   layer must locate the routing cache entry corresponding to the source
   of the Reply MTU option; if no such entry exists, a new one (with
   default values) should be created.  The SupportsProbe bit is set, and
   the ConsecutiveProbes value is reset to 0.  The ProbeRetry field is
   set to the current time plus ReprobeInterval.

   Four cases are possible when a Reply MTU option is received:

      (1) The Reply MTU option value is less than the current
          MINMTU: the MINMTU field is set to the new value, and
          the LastDecreased field is set to the current time.

      (2) The Reply MTU option value is greater than the
          current MINMTU and the LastDecreased field plus
          IncreaseInterval is less than the current time: set the
          ProbeRetry field to LastDecreased plus IncreaseInterval,
          but do not change MINMTU.

      (3) The Reply MTU option value is greater than the
          current MINMTU and the LastDecreased field plus
          IncreaseInterval is greater than the current time: set
          the MINMTU field to the new value.

      (4) The Reply MTU option value is equal to the current
          MINMTU: do nothing more.

   Whenever the MTU field is changed, the transport layer should be
   notified, either by an upcall or by a change in a shared variable
   (which may be accessed from the transport layer by a downcall).

   If a fragmentation reassembly timeout occurs, if an ICMP Time
   Exceeded/Fragmentation Reassembly Timeout is received, or if the IP



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


   layer is asked to send a probe by a higher layer, the ProbeRetry
   field for the appropriate routing cache entry is set to the current
   time.  This will cause a Probe option to be sent with the next
   datagram (unless the SupportsProbe bit is turned off).

MANAGEMENT PARAMETERS

   We suggest that the following parameters be made available to local
   applications and remote network management systems:

      (1) The number of probe retries to be made before determining
          a system is down.  The value of 10 is certain to be wrong
          in some situations.

      (2) The frequency with which probes are sent.  Systems may
          find that more or less frequent probing is more cost
          effective.

      (3) The default MINMTU used to initialize routes.

      (4) Applications should have the ability to force a probe
          on a particular route.  There are cases where a probe
          needs to be sent but the sender doesn't know it.  An
          operator must be able to cause a probe in such situations.
          Furthermore, it may be useful for applications to "ping"
          for the MTU.

REFERENCES

   [1]  Kent, C. and J. Mogul, "Fragmentation Considered
        Harmful", Proc. ACM SIGCOMM '87, Stowe, VT, August 1987.

   [2]  Postel, J., Ed., "Internet Protocol", RFC-791,
        USC/Information Sciences Institute, Marina del Rey, CA,
        September 1981.

   [3]  Postel, J., Ed., "Transmission Control Protocol", RFC-793,
        USC/Information Sciences Institute, Marina del Rey, CA,
        September 1981.

   [4]  Postel, J., "The TCP Maximum Segment Size and Related Topics",
        RFC-879, USC/Information Sciences Institute, Marina del Rey,
        CA, November 1983.








Mogul, Kent, Partridge, & McCloghrie                           [Page 11]