home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1981.txt < prev    next >
Text File  |  1996-08-15  |  35KB  |  844 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          J. McCann
  8. Request for Comments: 1981                 Digital Equipment Corporation
  9. Category: Standards Track                                     S. Deering
  10.                                                               Xerox PARC
  11.                                                                 J. Mogul
  12.                                            Digital Equipment Corporation
  13.                                                              August 1996
  14.  
  15.  
  16.                   Path MTU Discovery for IP version 6
  17.  
  18. Status of this Memo
  19.  
  20.    This document specifies an Internet standards track protocol for the
  21.    Internet community, and requests discussion and suggestions for
  22.    improvements.  Please refer to the current edition of the "Internet
  23.    Official Protocol Standards" (STD 1) for the standardization state
  24.    and status of this protocol.  Distribution of this memo is unlimited.
  25.  
  26. Abstract
  27.  
  28.    This document describes Path MTU Discovery for IP version 6.  It is
  29.    largely derived from RFC 1191, which describes Path MTU Discovery for
  30.    IP version 4.
  31.  
  32. Table of Contents
  33.  
  34.    1. Introduction.................................................2
  35.    2. Terminology..................................................2
  36.    3. Protocol overview............................................3
  37.    4. Protocol Requirements........................................4
  38.    5. Implementation Issues........................................5
  39.    5.1. Layering...................................................5
  40.    5.2. Storing PMTU information...................................6
  41.    5.3. Purging stale PMTU information.............................8
  42.    5.4. TCP layer actions..........................................9
  43.    5.5. Issues for other transport protocols......................11
  44.    5.6. Management interface......................................12
  45.    6. Security Considerations.....................................12
  46.    Acknowledgements...............................................13
  47.    Appendix A - Comparison to RFC 1191............................14
  48.    References.....................................................14
  49.    Authors' Addresses.............................................15
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. McCann, Deering & Mogul     Standards Track                     [Page 1]
  59.  
  60. RFC 1981              Path MTU Discovery for IPv6            August 1996
  61.  
  62.  
  63. 1. Introduction
  64.  
  65.    When one IPv6 node has a large amount of data to send to another
  66.    node, the data is transmitted in a series of IPv6 packets.  It is
  67.    usually preferable that these packets be of the largest size that can
  68.    successfully traverse the path from the source node to the
  69.    destination node.  This packet size is referred to as the Path MTU
  70.    (PMTU), and it is equal to the minimum link MTU of all the links in a
  71.    path.  IPv6 defines a standard mechanism for a node to discover the
  72.    PMTU of an arbitrary path.
  73.  
  74.    IPv6 nodes SHOULD implement Path MTU Discovery in order to discover
  75.    and take advantage of paths with PMTU greater than the IPv6 minimum
  76.    link MTU [IPv6-SPEC].  A minimal IPv6 implementation (e.g., in a boot
  77.    ROM) may choose to omit implementation of Path MTU Discovery.
  78.  
  79.    Nodes not implementing Path MTU Discovery use the IPv6 minimum link
  80.    MTU defined in [IPv6-SPEC] as the maximum packet size.  In most
  81.    cases, this will result in the use of smaller packets than necessary,
  82.    because most paths have a PMTU greater than the IPv6 minimum link
  83.    MTU.  A node sending packets much smaller than the Path MTU allows is
  84.    wasting network resources and probably getting suboptimal throughput.
  85.  
  86. 2. Terminology
  87.  
  88.    node        - a device that implements IPv6.
  89.  
  90.    router      - a node that forwards IPv6 packets not explicitly
  91.                  addressed to itself.
  92.  
  93.    host        - any node that is not a router.
  94.  
  95.    upper layer - a protocol layer immediately above IPv6.  Examples are
  96.                  transport protocols such as TCP and UDP, control
  97.                  protocols such as ICMP, routing protocols such as OSPF,
  98.                  and internet or lower-layer protocols being "tunneled"
  99.                  over (i.e., encapsulated in) IPv6 such as IPX,
  100.                  AppleTalk, or IPv6 itself.
  101.  
  102.    link        - a communication facility or medium over which nodes can
  103.                  communicate at the link layer, i.e., the layer
  104.                  immediately below IPv6.  Examples are Ethernets (simple
  105.                  or bridged); PPP links; X.25, Frame Relay, or ATM
  106.                  networks; and internet (or higher) layer "tunnels",
  107.                  such as tunnels over IPv4 or IPv6 itself.
  108.  
  109.    interface   - a node's attachment to a link.
  110.  
  111.  
  112.  
  113.  
  114. McCann, Deering & Mogul     Standards Track                     [Page 2]
  115.  
  116. RFC 1981              Path MTU Discovery for IPv6            August 1996
  117.  
  118.  
  119.    address     - an IPv6-layer identifier for an interface or a set of
  120.                  interfaces.
  121.  
  122.    packet      - an IPv6 header plus payload.
  123.  
  124.    link MTU    - the maximum transmission unit, i.e., maximum packet
  125.                  size in octets, that can be conveyed in one piece over
  126.                  a link.
  127.  
  128.    path        - the set of links traversed by a packet between a source
  129.                  node and a destination node
  130.  
  131.    path MTU    - the minimum link MTU of all the links in a path between
  132.                  a source node and a destination node.
  133.  
  134.    PMTU        - path MTU
  135.  
  136.    Path MTU
  137.    Discovery   - process by which a node learns the PMTU of a path
  138.  
  139.    flow        - a sequence of packets sent from a particular source
  140.                  to a particular (unicast or multicast) destination for
  141.                  which the source desires special handling by the
  142.                  intervening routers.
  143.  
  144.    flow id     - a combination of a source address and a non-zero
  145.                  flow label.
  146.  
  147. 3. Protocol overview
  148.  
  149.    This memo describes a technique to dynamically discover the PMTU of a
  150.    path.  The basic idea is that a source node initially assumes that
  151.    the PMTU of a path is the (known) MTU of the first hop in the path.
  152.    If any of the packets sent on that path are too large to be forwarded
  153.    by some node along the path, that node will discard them and return
  154.    ICMPv6 Packet Too Big messages [ICMPv6].  Upon receipt of such a
  155.    message, the source node reduces its assumed PMTU for the path based
  156.    on the MTU of the constricting hop as reported in the Packet Too Big
  157.    message.
  158.  
  159.    The Path MTU Discovery process ends when the node's estimate of the
  160.    PMTU is less than or equal to the actual PMTU.  Note that several
  161.    iterations of the packet-sent/Packet-Too-Big-message-received cycle
  162.    may occur before the Path MTU Discovery process ends, as there may be
  163.    links with smaller MTUs further along the path.
  164.  
  165.    Alternatively, the node may elect to end the discovery process by
  166.    ceasing to send packets larger than the IPv6 minimum link MTU.
  167.  
  168.  
  169.  
  170. McCann, Deering & Mogul     Standards Track                     [Page 3]
  171.  
  172. RFC 1981              Path MTU Discovery for IPv6            August 1996
  173.  
  174.  
  175.    The PMTU of a path may change over time, due to changes in the
  176.    routing topology.  Reductions of the PMTU are detected by Packet Too
  177.    Big messages.  To detect increases in a path's PMTU, a node
  178.    periodically increases its assumed PMTU.  This will almost always
  179.    result in packets being discarded and Packet Too Big messages being
  180.    generated, because in most cases the PMTU of the path will not have
  181.    changed.  Therefore, attempts to detect increases in a path's PMTU
  182.    should be done infrequently.
  183.  
  184.    Path MTU Discovery supports multicast as well as unicast
  185.    destinations.  In the case of a multicast destination, copies of a
  186.    packet may traverse many different paths to many different nodes.
  187.    Each path may have a different PMTU, and a single multicast packet
  188.    may result in multiple Packet Too Big messages, each reporting a
  189.    different next-hop MTU.  The minimum PMTU value across the set of
  190.    paths in use determines the size of subsequent packets sent to the
  191.    multicast destination.
  192.  
  193.    Note that Path MTU Discovery must be performed even in cases where a
  194.    node "thinks" a destination is attached to the same link as itself.
  195.    In a situation such as when a neighboring router acts as proxy [ND]
  196.    for some destination, the destination can to appear to be directly
  197.    connected but is in fact more than one hop away.
  198.  
  199. 4. Protocol Requirements
  200.  
  201.    As discussed in section 1, IPv6 nodes are not required to implement
  202.    Path MTU Discovery.  The requirements in this section apply only to
  203.    those implementations that include Path MTU Discovery.
  204.  
  205.    When a node receives a Packet Too Big message, it MUST reduce its
  206.    estimate of the PMTU for the relevant path, based on the value of the
  207.    MTU field in the message.  The precise behavior of a node in this
  208.    circumstance is not specified, since different applications may have
  209.    different requirements, and since different implementation
  210.    architectures may favor different strategies.
  211.  
  212.    After receiving a Packet Too Big message, a node MUST attempt to
  213.    avoid eliciting more such messages in the near future.  The node MUST
  214.    reduce the size of the packets it is sending along the path.  Using a
  215.    PMTU estimate larger than the IPv6 minimum link MTU may continue to
  216.    elicit Packet Too Big messages.  Since each of these messages (and
  217.    the dropped packets they respond to) consume network resources, the
  218.    node MUST force the Path MTU Discovery process to end.
  219.  
  220.    Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast
  221.    as possible.  Nodes MAY detect increases in PMTU, but because doing
  222.    so requires sending packets larger than the current estimated PMTU,
  223.  
  224.  
  225.  
  226. McCann, Deering & Mogul     Standards Track                     [Page 4]
  227.  
  228. RFC 1981              Path MTU Discovery for IPv6            August 1996
  229.  
  230.  
  231.    and because the likelihood is that the PMTU will not have increased,
  232.    this MUST be done at infrequent intervals.  An attempt to detect an
  233.    increase (by sending a packet larger than the current estimate) MUST
  234.    NOT be done less than 5 minutes after a Packet Too Big message has
  235.    been received for the given path.  The recommended setting for this
  236.    timer is twice its minimum value (10 minutes).
  237.  
  238.    A node MUST NOT reduce its estimate of the Path MTU below the IPv6
  239.    minimum link MTU.
  240.  
  241.       Note: A node may receive a Packet Too Big message reporting a
  242.       next-hop MTU that is less than the IPv6 minimum link MTU.  In that
  243.       case, the node is not required to reduce the size of subsequent
  244.       packets sent on the path to less than the IPv6 minimun link MTU,
  245.       but rather must include a Fragment header in those packets [IPv6-
  246.       SPEC].
  247.  
  248.    A node MUST NOT increase its estimate of the Path MTU in response to
  249.    the contents of a Packet Too Big message.  A message purporting to
  250.    announce an increase in the Path MTU might be a stale packet that has
  251.    been floating around in the network, a false packet injected as part
  252.    of a denial-of-service attack, or the result of having multiple paths
  253.    to the destination, each with a different PMTU.
  254.  
  255. 5. Implementation Issues
  256.  
  257.    This section discusses a number of issues related to the
  258.    implementation of Path MTU Discovery.  This is not a specification,
  259.    but rather a set of notes provided as an aid for implementors.
  260.  
  261.    The issues include:
  262.  
  263.    - What layer or layers implement Path MTU Discovery?
  264.  
  265.    - How is the PMTU information cached?
  266.  
  267.    - How is stale PMTU information removed?
  268.  
  269.    - What must transport and higher layers do?
  270.  
  271. 5.1. Layering
  272.  
  273.    In the IP architecture, the choice of what size packet to send is
  274.    made by a protocol at a layer above IP.  This memo refers to such a
  275.    protocol as a "packetization protocol".  Packetization protocols are
  276.    usually transport protocols (for example, TCP) but can also be
  277.    higher-layer protocols (for example, protocols built on top of UDP).
  278.  
  279.  
  280.  
  281.  
  282. McCann, Deering & Mogul     Standards Track                     [Page 5]
  283.  
  284. RFC 1981              Path MTU Discovery for IPv6            August 1996
  285.  
  286.  
  287.    Implementing Path MTU Discovery in the packetization layers
  288.    simplifies some of the inter-layer issues, but has several drawbacks:
  289.    the implementation may have to be redone for each packetization
  290.    protocol, it becomes hard to share PMTU information between different
  291.    packetization layers, and the connection-oriented state maintained by
  292.    some packetization layers may not easily extend to save PMTU
  293.    information for long periods.
  294.  
  295.    It is therefore suggested that the IP layer store PMTU information
  296.    and that the ICMP layer process received Packet Too Big messages.
  297.    The packetization layers may respond to changes in the PMTU, by
  298.    changing the size of the messages they send.  To support this
  299.    layering, packetization layers require a way to learn of changes in
  300.    the value of MMS_S, the "maximum send transport-message size".  The
  301.    MMS_S is derived from the Path MTU by subtracting the size of the
  302.    IPv6 header plus space reserved by the IP layer for additional
  303.    headers (if any).
  304.  
  305.    It is possible that a packetization layer, perhaps a UDP application
  306.    outside the kernel, is unable to change the size of messages it
  307.    sends.  This may result in a packet size that exceeds the Path MTU.
  308.    To accommodate such situations, IPv6 defines a mechanism that allows
  309.    large payloads to be divided into fragments, with each fragment sent
  310.    in a separate packet (see [IPv6-SPEC] section "Fragment Header").
  311.    However, packetization layers are encouraged to avoid sending
  312.    messages that will require fragmentation (for the case against
  313.    fragmentation, see [FRAG]).
  314.  
  315. 5.2. Storing PMTU information
  316.  
  317.    Ideally, a PMTU value should be associated with a specific path
  318.    traversed by packets exchanged between the source and destination
  319.    nodes.  However, in most cases a node will not have enough
  320.    information to completely and accurately identify such a path.
  321.    Rather, a node must associate a PMTU value with some local
  322.    representation of a path.  It is left to the implementation to select
  323.    the local representation of a path.
  324.  
  325.    In the case of a multicast destination address, copies of a packet
  326.    may traverse many different paths to reach many different nodes.  The
  327.    local representation of the "path" to a multicast destination must in
  328.    fact represent a potentially large set of paths.
  329.  
  330.    Minimally, an implementation could maintain a single PMTU value to be
  331.    used for all packets originated from the node.  This PMTU value would
  332.    be the minimum PMTU learned across the set of all paths in use by the
  333.    node.  This approach is likely to result in the use of smaller
  334.    packets than is necessary for many paths.
  335.  
  336.  
  337.  
  338. McCann, Deering & Mogul     Standards Track                     [Page 6]
  339.  
  340. RFC 1981              Path MTU Discovery for IPv6            August 1996
  341.  
  342.  
  343.    An implementation could use the destination address as the local
  344.    representation of a path.  The PMTU value associated with a
  345.    destination would be the minimum PMTU learned across the set of all
  346.    paths in use to that destination.  The set of paths in use to a
  347.    particular destination is expected to be small, in many cases
  348.    consisting of a single path.  This approach will result in the use of
  349.    optimally sized packets on a per-destination basis.  This approach
  350.    integrates nicely with the conceptual model of a host as described in
  351.    [ND]: a PMTU value could be stored with the corresponding entry in
  352.    the destination cache.
  353.  
  354.    If flows [IPv6-SPEC] are in use, an implementation could use the flow
  355.    id as the local representation of a path.  Packets sent to a
  356.    particular destination but belonging to different flows may use
  357.    different paths, with the choice of path depending on the flow id.
  358.    This approach will result in the use of optimally sized packets on a
  359.    per-flow basis, providing finer granularity than PMTU values
  360.    maintained on a per-destination basis.
  361.  
  362.    For source routed packets (i.e. packets containing an IPv6 Routing
  363.    header [IPv6-SPEC]), the source route may further qualify the local
  364.    representation of a path.  In particular, a packet containing a type
  365.    0 Routing header in which all bits in the Strict/Loose Bit Map are
  366.    equal to 1 contains a complete path specification.  An implementation
  367.    could use source route information in the local representation of a
  368.    path.
  369.  
  370.       Note: Some paths may be further distinguished by different
  371.       security classifications.  The details of such classifications are
  372.       beyond the scope of this memo.
  373.  
  374.    Initially, the PMTU value for a path is assumed to be the (known) MTU
  375.    of the first-hop link.
  376.  
  377.    When a Packet Too Big message is received, the node determines which
  378.    path the message applies to based on the contents of the Packet Too
  379.    Big message.  For example, if the destination address is used as the
  380.    local representation of a path, the destination address from the
  381.    original packet would be used to determine which path the message
  382.    applies to.
  383.  
  384.       Note: if the original packet contained a Routing header, the
  385.       Routing header should be used to determine the location of the
  386.       destination address within the original packet.  If Segments Left
  387.       is equal to zero, the destination address is in the Destination
  388.       Address field in the IPv6 header.  If Segments Left is greater
  389.       than zero, the destination address is the last address
  390.       (Address[n]) in the Routing header.
  391.  
  392.  
  393.  
  394. McCann, Deering & Mogul     Standards Track                     [Page 7]
  395.  
  396. RFC 1981              Path MTU Discovery for IPv6            August 1996
  397.  
  398.  
  399.    The node then uses the value in the MTU field in the Packet Too Big
  400.    message as a tentative PMTU value, and compares the tentative PMTU to
  401.    the existing PMTU.  If the tentative PMTU is less than the existing
  402.    PMTU estimate, the tentative PMTU replaces the existing PMTU as the
  403.    PMTU value for the path.
  404.  
  405.    The packetization layers must be notified about decreases in the
  406.    PMTU.  Any packetization layer instance (for example, a TCP
  407.    connection) that is actively using the path must be notified if the
  408.    PMTU estimate is decreased.
  409.  
  410.       Note: even if the Packet Too Big message contains an Original
  411.       Packet Header that refers to a UDP packet, the TCP layer must be
  412.       notified if any of its connections use the given path.
  413.  
  414.    Also, the instance that sent the packet that elicited the Packet Too
  415.    Big message should be notified that its packet has been dropped, even
  416.    if the PMTU estimate has not changed, so that it may retransmit the
  417.    dropped data.
  418.  
  419.       Note: An implementation can avoid the use of an asynchronous
  420.       notification mechanism for PMTU decreases by postponing
  421.       notification until the next attempt to send a packet larger than
  422.       the PMTU estimate.  In this approach, when an attempt is made to
  423.       SEND a packet that is larger than the PMTU estimate, the SEND
  424.       function should fail and return a suitable error indication.  This
  425.       approach may be more suitable to a connectionless packetization
  426.       layer (such as one using UDP), which (in some implementations) may
  427.       be hard to "notify" from the ICMP layer.  In this case, the normal
  428.       timeout-based retransmission mechanisms would be used to recover
  429.       from the dropped packets.
  430.  
  431.    It is important to understand that the notification of the
  432.    packetization layer instances using the path about the change in the
  433.    PMTU is distinct from the notification of a specific instance that a
  434.    packet has been dropped.  The latter should be done as soon as
  435.    practical (i.e., asynchronously from the point of view of the
  436.    packetization layer instance), while the former may be delayed until
  437.    a packetization layer instance wants to create a packet.
  438.    Retransmission should be done for only for those packets that are
  439.    known to be dropped, as indicated by a Packet Too Big message.
  440.  
  441. 5.3. Purging stale PMTU information
  442.  
  443.    Internetwork topology is dynamic; routes change over time.  While the
  444.    local representation of a path may remain constant, the actual
  445.    path(s) in use may change.  Thus, PMTU information cached by a node
  446.    can become stale.
  447.  
  448.  
  449.  
  450. McCann, Deering & Mogul     Standards Track                     [Page 8]
  451.  
  452. RFC 1981              Path MTU Discovery for IPv6            August 1996
  453.  
  454.  
  455.    If the stale PMTU value is too large, this will be discovered almost
  456.    immediately once a large enough packet is sent on the path.  No such
  457.    mechanism exists for realizing that a stale PMTU value is too small,
  458.    so an implementation should "age" cached values.  When a PMTU value
  459.    has not been decreased for a while (on the order of 10 minutes), the
  460.    PMTU estimate should be set to the MTU of the first-hop link, and the
  461.    packetization layers should be notified of the change.  This will
  462.    cause the complete Path MTU Discovery process to take place again.
  463.  
  464.       Note: an implementation should provide a means for changing the
  465.       timeout duration, including setting it to "infinity".  For
  466.       example, nodes attached to an FDDI link which is then attached to
  467.       the rest of the Internet via a small MTU serial line are never
  468.       going to discover a new non-local PMTU, so they should not have to
  469.       put up with dropped packets every 10 minutes.
  470.  
  471.    An upper layer must not retransmit data in response to an increase in
  472.    the PMTU estimate, since this increase never comes in response to an
  473.    indication of a dropped packet.
  474.  
  475.    One approach to implementing PMTU aging is to associate a timestamp
  476.    field with a PMTU value.  This field is initialized to a "reserved"
  477.    value, indicating that the PMTU is equal to the MTU of the first hop
  478.    link.  Whenever the PMTU is decreased in response to a Packet Too Big
  479.    message, the timestamp is set to the current time.
  480.  
  481.    Once a minute, a timer-driven procedure runs through all cached PMTU
  482.    values, and for each PMTU whose timestamp is not "reserved" and is
  483.    older than the timeout interval:
  484.  
  485.    - The PMTU estimate is set to the MTU of the first hop link.
  486.  
  487.    - The timestamp is set to the "reserved" value.
  488.  
  489.    - Packetization layers using this path are notified of the increase.
  490.  
  491. 5.4. TCP layer actions
  492.  
  493.    The TCP layer must track the PMTU for the path(s) in use by a
  494.    connection; it should not send segments that would result in packets
  495.    larger than the PMTU.  A simple implementation could ask the IP layer
  496.    for this value each time it created a new segment, but this could be
  497.    inefficient.  Moreover, TCP implementations that follow the "slow-
  498.    start" congestion-avoidance algorithm [CONG] typically calculate and
  499.    cache several other values derived from the PMTU.  It may be simpler
  500.    to receive asynchronous notification when the PMTU changes, so that
  501.    these variables may be updated.
  502.  
  503.  
  504.  
  505.  
  506. McCann, Deering & Mogul     Standards Track                     [Page 9]
  507.  
  508. RFC 1981              Path MTU Discovery for IPv6            August 1996
  509.  
  510.  
  511.    A TCP implementation must also store the MSS value received from its
  512.    peer, and must not send any segment larger than this MSS, regardless
  513.    of the PMTU.  In 4.xBSD-derived implementations, this may require
  514.    adding an additional field to the TCP state record.
  515.  
  516.    The value sent in the TCP MSS option is independent of the PMTU.
  517.    This MSS option value is used by the other end of the connection,
  518.    which may be using an unrelated PMTU value.  See [IPv6-SPEC] sections
  519.    "Packet Size Issues" and "Maximum Upper-Layer Payload Size" for
  520.    information on selecting a value for the TCP MSS option.
  521.  
  522.    When a Packet Too Big message is received, it implies that a packet
  523.    was dropped by the node that sent the ICMP message.  It is sufficient
  524.    to treat this as any other dropped segment, and wait until the
  525.    retransmission timer expires to cause retransmission of the segment.
  526.    If the Path MTU Discovery process requires several steps to find the
  527.    PMTU of the full path, this could delay the connection by many
  528.    round-trip times.
  529.  
  530.    Alternatively, the retransmission could be done in immediate response
  531.    to a notification that the Path MTU has changed, but only for the
  532.    specific connection specified by the Packet Too Big message.  The
  533.    packet size used in the retransmission should be no larger than the
  534.    new PMTU.
  535.  
  536.       Note: A packetization layer must not retransmit in response to
  537.       every Packet Too Big message, since a burst of several oversized
  538.       segments will give rise to several such messages and hence several
  539.       retransmissions of the same data.  If the new estimated PMTU is
  540.       still wrong, the process repeats, and there is an exponential
  541.       growth in the number of superfluous segments sent.
  542.  
  543.       This means that the TCP layer must be able to recognize when a
  544.       Packet Too Big notification actually decreases the PMTU that it
  545.       has already used to send a packet on the given connection, and
  546.       should ignore any other notifications.
  547.  
  548.    Many TCP implementations incorporate "congestion avoidance" and
  549.    "slow-start" algorithms to improve performance [CONG].  Unlike a
  550.    retransmission caused by a TCP retransmission timeout, a
  551.    retransmission caused by a Packet Too Big message should not change
  552.    the congestion window.  It should, however, trigger the slow-start
  553.    mechanism (i.e., only one segment should be retransmitted until
  554.    acknowledgements begin to arrive again).
  555.  
  556.    TCP performance can be reduced if the sender's maximum window size is
  557.    not an exact multiple of the segment size in use (this is not the
  558.    congestion window size, which is always a multiple of the segment
  559.  
  560.  
  561.  
  562. McCann, Deering & Mogul     Standards Track                    [Page 10]
  563.  
  564. RFC 1981              Path MTU Discovery for IPv6            August 1996
  565.  
  566.  
  567.    size).  In many systems (such as those derived from 4.2BSD), the
  568.    segment size is often set to 1024 octets, and the maximum window size
  569.    (the "send space") is usually a multiple of 1024 octets, so the
  570.    proper relationship holds by default.  If Path MTU Discovery is used,
  571.    however, the segment size may not be a submultiple of the send space,
  572.    and it may change during a connection; this means that the TCP layer
  573.    may need to change the transmission window size when Path MTU
  574.    Discovery changes the PMTU value.  The maximum window size should be
  575.    set to the greatest multiple of the segment size that is less than or
  576.    equal to the sender's buffer space size.
  577.  
  578. 5.5. Issues for other transport protocols
  579.  
  580.    Some transport protocols (such as ISO TP4 [ISOTP]) are not allowed to
  581.    repacketize when doing a retransmission.  That is, once an attempt is
  582.    made to transmit a segment of a certain size, the transport cannot
  583.    split the contents of the segment into smaller segments for
  584.    retransmission.  In such a case, the original segment can be
  585.    fragmented by the IP layer during retransmission.  Subsequent
  586.    segments, when transmitted for the first time, should be no larger
  587.    than allowed by the Path MTU.
  588.  
  589.    The Sun Network File System (NFS) uses a Remote Procedure Call (RPC)
  590.    protocol [RPC] that, when used over UDP, in many cases will generate
  591.    payloads that must be fragmented even for the first-hop link.  This
  592.    might improve performance in certain cases, but it is known to cause
  593.    reliability and performance problems, especially when the client and
  594.    server are separated by routers.
  595.  
  596.    It is recommended that NFS implementations use Path MTU Discovery
  597.    whenever routers are involved.  Most NFS implementations allow the
  598.    RPC datagram size to be changed at mount-time (indirectly, by
  599.    changing the effective file system block size), but might require
  600.    some modification to support changes later on.
  601.  
  602.    Also, since a single NFS operation cannot be split across several UDP
  603.    datagrams, certain operations (primarily, those operating on file
  604.    names and directories) require a minimum payload size that if sent in
  605.    a single packet would exceed the PMTU.  NFS implementations should
  606.    not reduce the payload size below this threshold, even if Path MTU
  607.    Discovery suggests a lower value.  In this case the payload will be
  608.    fragmented by the IP layer.
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. McCann, Deering & Mogul     Standards Track                    [Page 11]
  619.  
  620. RFC 1981              Path MTU Discovery for IPv6            August 1996
  621.  
  622.  
  623. 5.6. Management interface
  624.  
  625.    It is suggested that an implementation provide a way for a system
  626.    utility program to:
  627.  
  628.    - Specify that Path MTU Discovery not be done on a given path.
  629.  
  630.    - Change the PMTU value associated with a given path.
  631.  
  632.    The former can be accomplished by associating a flag with the path;
  633.    when a packet is sent on a path with this flag set, the IP layer does
  634.    not send packets larger than the IPv6 minimum link MTU.
  635.  
  636.    These features might be used to work around an anomalous situation,
  637.    or by a routing protocol implementation that is able to obtain Path
  638.    MTU values.
  639.  
  640.    The implementation should also provide a way to change the timeout
  641.    period for aging stale PMTU information.
  642.  
  643. 6. Security Considerations
  644.  
  645.    This Path MTU Discovery mechanism makes possible two denial-of-
  646.    service attacks, both based on a malicious party sending false Packet
  647.    Too Big messages to a node.
  648.  
  649.    In the first attack, the false message indicates a PMTU much smaller
  650.    than reality.  This should not entirely stop data flow, since the
  651.    victim node should never set its PMTU estimate below the IPv6 minimum
  652.    link MTU.  It will, however, result in suboptimal performance.
  653.  
  654.    In the second attack, the false message indicates a PMTU larger than
  655.    reality.  If believed, this could cause temporary blockage as the
  656.    victim sends packets that will be dropped by some router.  Within one
  657.    round-trip time, the node would discover its mistake (receiving
  658.    Packet Too Big messages from that router), but frequent repetition of
  659.    this attack could cause lots of packets to be dropped.  A node,
  660.    however, should never raise its estimate of the PMTU based on a
  661.    Packet Too Big message, so should not be vulnerable to this attack.
  662.  
  663.    A malicious party could also cause problems if it could stop a victim
  664.    from receiving legitimate Packet Too Big messages, but in this case
  665.    there are simpler denial-of-service attacks available.
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. McCann, Deering & Mogul     Standards Track                    [Page 12]
  675.  
  676. RFC 1981              Path MTU Discovery for IPv6            August 1996
  677.  
  678.  
  679. Acknowledgements
  680.  
  681.    We would like to acknowledge the authors of and contributors to
  682.    [RFC-1191], from which the majority of this document was derived.  We
  683.    would also like to acknowledge the members of the IPng working group
  684.    for their careful review and constructive criticisms.
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. McCann, Deering & Mogul     Standards Track                    [Page 13]
  731.  
  732. RFC 1981              Path MTU Discovery for IPv6            August 1996
  733.  
  734.  
  735. Appendix A - Comparison to RFC 1191
  736.  
  737.    This document is based in large part on RFC 1191, which describes
  738.    Path MTU Discovery for IPv4.  Certain portions of RFC 1191 were not
  739.    needed in this document:
  740.  
  741.    router specification    - Packet Too Big messages and corresponding
  742.                              router behavior are defined in [ICMPv6]
  743.  
  744.    Don't Fragment bit      - there is no DF bit in IPv6 packets
  745.  
  746.    TCP MSS discussion      - selecting a value to send in the TCP MSS
  747.                              option is discussed in [IPv6-SPEC]
  748.  
  749.    old-style messages      - all Packet Too Big messages report the
  750.                              MTU of the constricting link
  751.  
  752.    MTU plateau tables      - not needed because there are no old-style
  753.                              messages
  754.  
  755. References
  756.  
  757.    [CONG]      Van Jacobson.  Congestion Avoidance and Control.  Proc.
  758.                SIGCOMM '88 Symposium on Communications Architectures and
  759.                Protocols, pages 314-329.  Stanford, CA, August, 1988.
  760.  
  761.    [FRAG]      C. Kent and J. Mogul.  Fragmentation Considered Harmful.
  762.                In Proc. SIGCOMM '87 Workshop on Frontiers in Computer
  763.                Communications Technology.  August, 1987.
  764.  
  765.    [ICMPv6]    Conta, A., and S. Deering, "Internet Control Message
  766.                Protocol (ICMPv6) for the Internet Protocol Version 6
  767.                (IPv6) Specification", RFC 1885, December 1995.
  768.  
  769.    [IPv6-SPEC] Deering, S., and R. Hinden, "Internet Protocol, Version
  770.                6 (IPv6) Specification", RFC 1883, December 1995.
  771.  
  772.    [ISOTP]     ISO.  ISO Transport Protocol Specification: ISO DP 8073.
  773.                RFC 905, SRI Network Information Center, April, 1984.
  774.  
  775.    [ND]        Narten, T., Nordmark, E., and W. Simpson, "Neighbor
  776.                Discovery for IP Version 6 (IPv6)", Work in Progress.
  777.  
  778.    [RFC-1191]  Mogul, J., and S. Deering, "Path MTU Discovery",
  779.                RFC 1191, November 1990.
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. McCann, Deering & Mogul     Standards Track                    [Page 14]
  787.  
  788. RFC 1981              Path MTU Discovery for IPv6            August 1996
  789.  
  790.  
  791.    [RPC]       Sun Microsystems, Inc., "RPC: Remote Procedure Call
  792.                Protocol", RFC 1057, SRI Network Information Center,
  793.                June, 1988.
  794.  
  795. Authors' Addresses
  796.  
  797.    Jack McCann
  798.    Digital Equipment Corporation
  799.    110 Spitbrook Road, ZKO3-3/U14
  800.    Nashua, NH 03062
  801.    Phone: +1 603 881 2608
  802.  
  803.    Fax:   +1 603 881 0120
  804.    Email: mccann@zk3.dec.com
  805.  
  806.  
  807.    Stephen E. Deering
  808.    Xerox Palo Alto Research Center
  809.    3333 Coyote Hill Road
  810.    Palo Alto, CA 94304
  811.    Phone: +1 415 812 4839
  812.  
  813.    Fax:   +1 415 812 4471
  814.    EMail: deering@parc.xerox.com
  815.  
  816.  
  817.    Jeffrey Mogul
  818.    Digital Equipment Corporation Western Research Laboratory
  819.    250 University Avenue
  820.    Palo Alto, CA 94301
  821.    Phone: +1 415 617 3304
  822.  
  823.    EMail: mogul@pa.dec.com
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. McCann, Deering & Mogul     Standards Track                    [Page 15]
  843.  
  844.