rfc1191.txt

RFC 的详细文档！

   larger than the PMTU.  NFS implementations should not reduce the
   datagram size below this threshold, even if PMTU Discovery suggests a
   lower value.  (Of course, in this case datagrams should not be sent
   with DF set.)


6.6. Management interface

   We suggest that an implementation provide a way for a system utility
   program to:

      - Specify that PMTU Discovery not be done on a given route.

      - Change the PMTU value associated with a given route.

   The former can be accomplished by associating a flag with the routing
   entry; when a packet is sent via a route with this flag set, the IP
   layer leaves the DF bit clear no matter what the upper layer
   requests.

   These features might be used to work around an anomalous situation,
   or by a routing protocol implementation that is able to obtain Path
   MTU values.

   The implementation should also provide a way to change the timeout
   period for aging stale PMTU information.


7. Likely values for Path MTUs

   The algorithm recommended in section 5 for "searching" the space of
   Path MTUs is based on a table of values that severely restricts the
   search space.  We describe here a table of MTU values that, as of
   this writing, represents all major data-link technologies in use in
   the Internet.

   In table 7-1, data links are listed in order of decreasing MTU, and
   grouped so that each set of similar MTUs is associated with a
   "plateau" equal to the lowest MTU in the group.  (The table also


Mogul & Deering                                                [page 15]


RFC 1191                   Path MTU Discovery              November 1990




   includes some entries not currently associated with a data link, and
   gives references where available).  Where a plateau represents more
   than one MTU, the table shows the maximum inaccuracy associated with
   the plateau, as a percentage.

   We do not expect that the values in the table, especially for higher
   MTU levels, are going to be valid forever.  The values given here are
   an implementation suggestion, NOT a specification or requirement.
   Implementors should use up-to-date references to pick a set of
   plateaus; it is important that the table not contain too many entries
   or the process of searching for a PMTU might waste Internet
   resources.  Implementors should also make it convenient for customers
   without source code to update the table values in their systems (for
   example, the table in a BSD-derived Unix kernel could be changed
   using a new "ioctl" command).

          Note: It might be a good idea to add a few table entries for
          values equal to small powers of 2 plus 40 (for the IP and TCP
          headers), where no similar values exist, since this seems to
          be a reasonably non-arbitrary way of choosing arbitrary
          values.

          The table might also contain entries for values slightly less
          than large powers of 2, in case MTUs are defined near those
          values (it is better in this case for the table entries to be
          low than to be high, or else the next lowest plateau may be
          chosen instead).


7.1. A better way to detect PMTU increases

   Section 6.3 suggests detecting increases in the PMTU value by
   periodically increasing the PTMU estimate to the first-hop MTU.
   Since it is likely that this process will simply "rediscover" the
   current PTMU estimate, at the cost of several dropped datagrams, it
   should not be done often.

   A better approach is to periodically increase the PMTU estimate to
   the next-highest value in the plateau table (or the first-hop MTU, if
   that is smaller).  If the increased estimate is wrong, at most one
   round-trip time is wasted before the correct value is rediscovered.
   If the increased estimate is still too low, a higher estimate will be
   attempted somewhat later.

   Because it may take several such periods to discover a significant
   increase in the PMTU, we recommend that a short timeout period should
   be used after the estimate is increased, and a longer timeout be used


Mogul & Deering                                                [page 16]


RFC 1191                   Path MTU Discovery              November 1990




   Plateau    MTU    Comments                      Reference
   ------     ---    --------                      ---------
              65535  Official maximum MTU          RFC 791
              65535  Hyperchannel                  RFC 1044
   65535
   32000             Just in case
              17914  16Mb IBM Token Ring           ref. [6]
   17914
              8166   IEEE 802.4                    RFC 1042
   8166
              4464   IEEE 802.5 (4Mb max)          RFC 1042
              4352   FDDI (Revised)                RFC 1188
   4352 (1%)
              2048   Wideband Network              RFC 907
              2002   IEEE 802.5 (4Mb recommended)  RFC 1042
   2002 (2%)
              1536   Exp. Ethernet Nets            RFC 895
              1500   Ethernet Networks             RFC 894
              1500   Point-to-Point (default)      RFC 1134
              1492   IEEE 802.3                    RFC 1042
   1492 (3%)
              1006   SLIP                          RFC 1055
              1006   ARPANET                       BBN 1822
   1006
              576    X.25 Networks                 RFC 877
              544    DEC IP Portal                 ref. [10]
              512    NETBIOS                       RFC 1088
              508    IEEE 802/Source-Rt Bridge     RFC 1042
              508    ARCNET                        RFC 1051
   508 (13%)
              296    Point-to-Point (low delay)    RFC 1144
   296
   68                Official minimum MTU          RFC 791

                Table 7-1:  Common MTUs in the Internet

   after the PTMU estimate is decreased because of a Datagram Too Big
   message.  For example, after the PTMU estimate is decreased, the
   timeout should be set to 10 minutes; once this timer expires and a
   larger MTU is attempted, the timeout can be set to a much smaller
   value (say, 2 minutes).  In no case should the timeout be shorter
   than the estimated round-trip time, if this is known.







Mogul & Deering                                                [page 17]


RFC 1191                   Path MTU Discovery              November 1990




8. Security considerations

   This Path MTU Discovery mechanism makes possible two denial-of-
   service attacks, both based on a malicious party sending false
   Datagram Too Big messages to an Internet host.

   In the first attack, the false message indicates a PMTU much smaller
   than reality.  This should not entirely stop data flow, since the
   victim host should never set its PMTU estimate below the absolute
   minimum, but at 8 octets of IP data per datagram, progress could be
   slow.

   In the other attack, the false message indicates a PMTU greater than
   reality.  If believed, this could cause temporary blockage as the
   victim sends datagrams that will be dropped by some router.  Within
   one round-trip time, the host would discover its mistake (receiving
   Datagram Too Big messages from that router), but frequent repetition
   of this attack could cause lots of datagrams to be dropped.  A host,
   however, should never raise its estimate of the PMTU based on a
   Datagram Too Big message, so should not be vulnerable to this attack.

   A malicious party could also cause problems if it could stop a victim
   from receiving legitimate Datagram Too Big messages, but in this case
   there are simpler denial-of-service attacks available.


References

[1]   R. Braden, ed.  Requirements for Internet Hosts -- Communication
      Layers.  RFC 1122, SRI Network Information Center, October, 1989.

[2]   Geof Cooper.  IP Datagram Sizes.  Electronic distribution of the
      TCP-IP Discussion Group, Message-ID
      <[e-mail]>.

[3]   ISO.  ISO Transport Protocol Specification: ISO DP 8073.  RFC 905,
      SRI Network Information Center, April, 1984.

[4]   Van Jacobson.  Congestion Avoidance and Control.  In Proc. SIGCOMM
      '88 Symposium on Communications Architectures and Protocols, pages
      314-329.  Stanford, CA, August, 1988.

[5]   C. Kent and J. Mogul.  Fragmentation Considered Harmful.  In Proc.
      SIGCOMM '87 Workshop on Frontiers in Computer Communications
      Technology.  August, 1987.

[6]   Drew Daniel Perkins.  Private Communication.


Mogul & Deering                                                [page 18]


RFC 1191                   Path MTU Discovery              November 1990




[7]   J. Postel.  Internet Control Message Protocol.  RFC 792, SRI
      Network Information Center, September, 1981.

[8]   J. Postel.  Internet Protocol.  RFC 791, SRI Network Information
      Center, September, 1981.

[9]   J. Postel.  The TCP Maximum Segment Size and Related Topics.  RFC
      879, SRI Network Information Center, November, 1983.

[10]  Michael Reilly.  Private Communication.

[11]  Sun Microsystems, Inc.  RPC: Remote Procedure Call Protocol.  RFC
      1057, SRI Network Information Center, June, 1988.



Authors' Addresses

   Jeffrey Mogul
   Digital Equipment Corporation Western Research Laboratory
   100 Hamilton Avenue
   Palo Alto, CA  94301

   Phone: [phone]
   EMail: [e-mail]


   Steve Deering
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA  94304

   Phone: [phone]
   EMail: [e-mail]















Mogul & Deering                                                [page 19]