doc: Add RFC documents

1 files changed, 1084 insertions, 0 deletions

diff --git a/doc/rfc/rfc1191.txt b/doc/rfc/rfc1191.txt
new file mode 100644
index 0000000..b0af14f
--- /dev/null
+++ b/doc/rfc/rfc1191.txt
@@ -0,0 +1,1084 @@
+
+
+
+
+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.
+
+   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
+   entries should be initialized to be the MTU of the associated
+   first-hop data link, and must never be changed by the PMTU Discovery
+   process.  (PMTU Discovery only creates or changes entries for
+   per-host routes).  Until a Datagram Too Big message is received, the
+   PMTU associated with the initially-chosen route is presumed to be
+   accurate.
+
+   When a Datagram Too Big message is received, the ICMP layer
+   determines a new estimate for the Path MTU (either from a non-zero
+   Next-Hop MTU value in the packet, or using the method described in
+   section 5).  If a per-host route for this path does not exist, then
+   one is created (almost as if a per-host ICMP Redirect is being
+   processed; the new route uses the same first-hop router as the
+   current route).  If the PMTU estimate associated with the per-host
+   route is higher than the new estimate, then the value in the routing
+   entry is changed.
+
+   The packetization layers must be notified about decreases in the
+   PMTU.  Any packetization layer instance (for example, a TCP
+   connection) that is actively using the path must be notified if the
+   PMTU estimate is decreased.
+
+          Note: even if the Datagram Too Big message contains an
+          Original Datagram Header that refers to a UDP packet, the TCP
+          layer must be notified if any of its connections use the given
+
+
+Mogul & Deering                                                [page 10]
+
+
+RFC 1191                   Path MTU Discovery              November 1990
+
+
+
+
+          path.
+
+   Also, the instance that sent the datagram that elicited the Datagram
+   Too Big message should be notified that its datagram has been
+   dropped, even if the PMTU estimate has not changed, so that it may
+   retransmit the dropped datagram.
+
+          Note: The notification mechanism can be analogous to the
+          mechanism used to provide notification of an ICMP Source
+          Quench message.  In some implementations (such as
+          4.2BSD-derived systems), the existing notification mechanism
+          is not able to identify the specific connection involved, and
+          so an additional mechanism is necessary.
+
+          Alternatively, an implementation can avoid the use of an
+          asynchronous notification mechanism for PMTU decreases by
+          postponing notification until the next attempt to send a
+          datagram larger than the PMTU estimate.  In this approach,
+          when an attempt is made to SEND a datagram with the DF bit
+          set, and the datagram is larger than the PMTU estimate, the
+          SEND function should fail and return a suitable error
+          indication.  This approach may be more suitable to a
+          connectionless packetization layer (such as one using UDP),
+          which (in some implementations) may be hard to "notify" from
+          the ICMP layer.  In this case, the normal timeout-based
+          retransmission mechanisms would be used to recover from the
+          dropped datagrams.
+
+   It is important to understand that the notification of the
+   packetization layer instances using the path about the change in the
+   PMTU is distinct from the notification of a specific instance that a
+   packet has been dropped.  The latter should be done as soon as
+   practical (i.e., asynchronously from the point of view of the
+   packetization layer instance), while the former may be delayed until
+   a packetization layer instance wants to create a packet.
+   Retransmission should be done for only for those packets that are
+   known to be dropped, as indicated by a Datagram Too Big message.
+
+
+6.3. Purging stale PMTU information
+
+   Internetwork topology is dynamic; routes change over time.  The PMTU
+   discovered for a given destination may be wrong if a new route comes
+   into use.  Thus, PMTU information cached by a host can become stale.
+
+   Because a host using PMTU Discovery always sets the DF bit, if the
+   stale PMTU value is too large, this will be discovered almost
+
+
+Mogul & Deering                                                [page 11]
+
+
+RFC 1191                   Path MTU Discovery              November 1990
+
+
+
+
+   immediately once a datagram is sent to the given destination.  No
+   such mechanism exists for realizing that a stale PMTU value is too
+   small, so an implementation should "age" cached values.  When a PMTU
+   value has not been decreased for a while (on the order of 10
+   minutes), the PMTU estimate should be set to the first-hop data-link
+   MTU, and the packetization layers should be notified of the change.
+   This will cause the complete PMTU Discovery process to take place
+   again.
+
+          Note: an implementation should provide a means for changing
+          the timeout duration, including setting it to "infinity".  For
+          example, hosts attached to an FDDI network which is then
+          attached to the rest of the Internet via a slow serial line
+          are never going to discover a new non-local PMTU, so they
+          should not have to put up with dropped datagrams every 10
+          minutes.
+
+   An upper layer MUST not retransmit datagrams in response to an
+   increase in the PMTU estimate, since this increase never comes in
+   response to an indication of a dropped datagram.
+
+   One approach to implementing PMTU aging is to add a timestamp field
+   to the routing table entry.  This field is initialized to a
+   "reserved" value, indicating that the PMTU has never been changed.
+   Whenever the PMTU is decreased in response to a Datagram Too Big
+   message, the timestamp is set to the current time.
+
+   Once a minute, a timer-driven procedure runs through the routing
+   table, and for each entry whose timestamp is not "reserved" and is
+   older than the timeout interval:
+
+      - The PMTU estimate is set to the MTU of the associated first
+        hop.
+
+      - Packetization layers using this route are notified of the
+        increase.
+
+   PMTU estimates may disappear from the routing table if the per-host
+   routes are removed; this can happen in response to an ICMP Redirect
+   message, or because certain routing-table daemons delete old routes
+   after several minutes.  Also, on a multi-homed host a topology change
+   may result in the use of a different source interface.  When this
+   happens, if the packetization layer is not notified then it may
+   continue to use a cached PMTU value that is now too small.  One
+   solution is to notify the packetization layer of a possible PMTU
+   change whenever a Redirect message causes a route change, and
+   whenever a route is simply deleted from the routing table.
+
+
+Mogul & Deering                                                [page 12]
+
+
+RFC 1191                   Path MTU Discovery              November 1990
+
+
+
+
+          Note: a more sophisticated method for detecting PMTU increases
+          is described in section 7.1.
+
+
+6.4. TCP layer actions
+
+   The TCP layer must track the PMTU for the destination of a
+   connection; it should not send datagrams that would be larger than
+   this.  A simple implementation could ask the IP layer for this value
+   (using the GET_MAXSIZES interface described in [1]) each time it
+   created a new segment, but this could be inefficient.  Moreover, TCP
+   implementations that follow the "slow-start" congestion-avoidance
+   algorithm [4] typically calculate and cache several other values
+   derived from the PMTU.  It may be simpler to receive asynchronous
+   notification when the PMTU changes, so that these variables may be
+   updated.
+
+   A TCP implementation must also store the MSS value received from its
+   peer (which defaults to 536), and not send any segment larger than
+   this MSS, regardless of the PMTU.  In 4.xBSD-derived implementations,
+   this requires adding an additional field to the TCP state record.
+
+   Finally, when a Datagram Too Big message is received, it implies that
+   a datagram was dropped by the router that sent the ICMP message.  It
+   is sufficient to treat this as any other dropped segment, and wait
+   until the retransmission timer expires to cause retransmission of the
+   segment.  If the PMTU Discovery process requires several steps to
+   estimate the right PMTU, this could delay the connection by many
+   round-trip times.
+
+   Alternatively, the retransmission could be done in immediate response
+   to a notification that the Path MTU has changed, but only for the
+   specific connection specified by the Datagram Too Big message.  The
+   datagram size used in the retransmission should, of course, be no
+   larger than the new PMTU.
+
+          Note: One MUST not retransmit in response to every Datagram
+          Too Big message, since a burst of several oversized segments
+          will give rise to several such messages and hence several
+          retransmissions of the same data.  If the new estimated PMTU
+          is still wrong, the process repeats, and there is an
+          exponential growth in the number of superfluous segments sent!
+
+          This means that the TCP layer must be able to recognize when a
+          Datagram Too Big notification actually decreases the PMTU that
+          it has already used to send a datagram on the given
+          connection, and should ignore any other notifications.
+
+
+Mogul & Deering                                                [page 13]
+
+
+RFC 1191                   Path MTU Discovery              November 1990
+
+
+
+
+   Modern TCP implementations incorporate "congestion advoidance" and
+   "slow-start" algorithms to improve performance [4].  Unlike a
+   retransmission caused by a TCP retransmission timeout, a
+   retransmission caused by a Datagram Too Big message should not change
+   the congestion window.  It should, however, trigger the slow-start
+   mechanism (i.e., only one segment should be retransmitted until
+   acknowledgements begin to arrive again).
+
+   TCP performance can be reduced if the sender's maximum window size is
+   not an exact multiple of the segment size in use (this is not the
+   congestion window size, which is always a multiple of the segment
+   size).  In many system (such as those derived from 4.2BSD), the
+   segment size is often set to 1024 octets, and the maximum window size
+   (the "send space") is usually a multiple of 1024 octets, so the
+   proper relationship holds by default.  If PMTU Discovery is used,
+   however, the segment size may not be a submultiple of the send space,
+   and it may change during a connection; this means that the TCP layer
+   may need to change the transmission window size when PMTU Discovery
+   changes the PMTU value.  The maximum window size should be set to the
+   greatest multiple of the segment size (PMTU - 40) that is less than
+   or equal to the sender's buffer space size.
+
+   PMTU Discovery does not affect the value sent in the TCP MSS option,
+   because that value is used by the other end of the connection, which
+   may be using an unrelated PMTU value.
+
+
+6.5. Issues for other transport protocols
+
+   Some transport protocols (such as ISO TP4 [3]) are not allowed to
+   repacketize when doing a retransmission.  That is, once an attempt is
+   made to transmit a datagram of a certain size, its contents cannot be
+   split into smaller datagrams for retransmission.  In such a case, the
+   original datagram should be retransmitted without the DF bit set,
+   allowing it to be fragmented as necessary to reach its destination.
+   Subsequent datagrams, when transmitted for the first time, should be
+   no larger than allowed by the Path MTU, and should have the DF bit
+   set.
+
+   The Sun Network File System (NFS) uses a Remote Procedure Call (RPC)
+   protocol [11] that, in many cases, sends datagrams that must be
+   fragmented even for the first-hop link.  This might improve
+   performance in certain cases, but it is known to cause reliability
+   and performance problems, especially when the client and server are
+   separated by routers.
+
+   We recommend that NFS implementations use PMTU Discovery whenever
+
+
+Mogul & Deering                                                [page 14]
+
+
+RFC 1191                   Path MTU Discovery              November 1990
+
+
+
+
+   routers are involved.  Most NFS implementations allow the RPC
+   datagram size to be changed at mount-time (indirectly, by changing
+   the effective file system block size), but might require some
+   modification to support changes later on.
+
+   Also, since a single NFS operation cannot be split across several UDP
+   datagrams, certain operations (primarily, those operating on file
+   names and directories) require a minimum datagram size that may be
+   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
+      <8705240517.AA01407@apolling.imagen.uucp>.
+
+[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: (415) 853-6643
+   EMail: mogul@decwrl.dec.com
+
+
+   Steve Deering
+   Xerox Palo Alto Research Center
+   3333 Coyote Hill Road
+   Palo Alto, CA  94304
+
+   Phone: (415) 494-4839
+   EMail: deering@xerox.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mogul & Deering                                                [page 19]
+
\ No newline at end of file