rfc1981.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          J. McCann
Request for Comments: 1981                 Digital Equipment Corporation
Category: Standards Track                                     S. Deering
                                                              Xerox PARC
                                                                J. Mogul
                                           Digital Equipment Corporation
                                                             August 1996


                  Path MTU Discovery for IP version 6

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes Path MTU Discovery for IP version 6.  It is
   largely derived from RFC 1191, which describes Path MTU Discovery for
   IP version 4.

Table of Contents

   1. Introduction.................................................2
   2. Terminology..................................................2
   3. Protocol overview............................................3
   4. Protocol Requirements........................................4
   5. Implementation Issues........................................5
   5.1. Layering...................................................5
   5.2. Storing PMTU information...................................6
   5.3. Purging stale PMTU information.............................8
   5.4. TCP layer actions..........................................9
   5.5. Issues for other transport protocols......................11
   5.6. Management interface......................................12
   6. Security Considerations.....................................12
   Acknowledgements...............................................13
   Appendix A - Comparison to RFC 1191............................14
   References.....................................................14
   Authors' Addresses.............................................15








McCann, Deering & Mogul     Standards Track                     [Page 1]

RFC 1981              Path MTU Discovery for IPv6            August 1996


1. Introduction

   When one IPv6 node has a large amount of data to send to another
   node, the data is transmitted in a series of IPv6 packets.  It is
   usually preferable that these packets be of the largest size that can
   successfully traverse the path from the source node to the
   destination node.  This packet size is referred to as the Path MTU
   (PMTU), and it is equal to the minimum link MTU of all the links in a
   path.  IPv6 defines a standard mechanism for a node to discover the
   PMTU of an arbitrary path.

   IPv6 nodes SHOULD implement Path MTU Discovery in order to discover
   and take advantage of paths with PMTU greater than the IPv6 minimum
   link MTU [IPv6-SPEC].  A minimal IPv6 implementation (e.g., in a boot
   ROM) may choose to omit implementation of Path MTU Discovery.

   Nodes not implementing Path MTU Discovery use the IPv6 minimum link
   MTU defined in [IPv6-SPEC] as the maximum packet size.  In most
   cases, this will result in the use of smaller packets than necessary,
   because most paths have a PMTU greater than the IPv6 minimum link
   MTU.  A node sending packets much smaller than the Path MTU allows is
   wasting network resources and probably getting suboptimal throughput.

2. Terminology

   node        - a device that implements IPv6.

   router      - a node that forwards IPv6 packets not explicitly
                 addressed to itself.

   host        - any node that is not a router.

   upper layer - a protocol layer immediately above IPv6.  Examples are
                 transport protocols such as TCP and UDP, control
                 protocols such as ICMP, routing protocols such as OSPF,
                 and internet or lower-layer protocols being "tunneled"
                 over (i.e., encapsulated in) IPv6 such as IPX,
                 AppleTalk, or IPv6 itself.

   link        - a communication facility or medium over which nodes can
                 communicate at the link layer, i.e., the layer
                 immediately below IPv6.  Examples are Ethernets (simple
                 or bridged); PPP links; X.25, Frame Relay, or ATM
                 networks; and internet (or higher) layer "tunnels",
                 such as tunnels over IPv4 or IPv6 itself.

   interface   - a node's attachment to a link.




McCann, Deering & Mogul     Standards Track                     [Page 2]

RFC 1981              Path MTU Discovery for IPv6            August 1996


   address     - an IPv6-layer identifier for an interface or a set of
                 interfaces.

   packet      - an IPv6 header plus payload.

   link MTU    - the maximum transmission unit, i.e., maximum packet
                 size in octets, that can be conveyed in one piece over
                 a link.

   path        - the set of links traversed by a packet between a source
                 node and a destination node

   path MTU    - the minimum link MTU of all the links in a path between
                 a source node and a destination node.

   PMTU        - path MTU

   Path MTU
   Discovery   - process by which a node learns the PMTU of a path

   flow        - a sequence of packets sent from a particular source
                 to a particular (unicast or multicast) destination for
                 which the source desires special handling by the
                 intervening routers.

   flow id     - a combination of a source address and a non-zero
                 flow label.

3. Protocol overview

   This memo describes a technique to dynamically discover the PMTU of a
   path.  The basic idea is that a source node initially assumes that
   the PMTU of a path is the (known) MTU of the first hop in the path.
   If any of the packets sent on that path are too large to be forwarded
   by some node along the path, that node will discard them and return
   ICMPv6 Packet Too Big messages [ICMPv6].  Upon receipt of such a
   message, the source node reduces its assumed PMTU for the path based
   on the MTU of the constricting hop as reported in the Packet Too Big
   message.

   The Path MTU Discovery process ends when the node's estimate of the
   PMTU is less than or equal to the actual PMTU.  Note that several
   iterations of the packet-sent/Packet-Too-Big-message-received cycle
   may occur before the Path MTU Discovery process ends, as there may be
   links with smaller MTUs further along the path.

   Alternatively, the node may elect to end the discovery process by
   ceasing to send packets larger than the IPv6 minimum link MTU.



McCann, Deering & Mogul     Standards Track                     [Page 3]

RFC 1981              Path MTU Discovery for IPv6            August 1996


   The PMTU of a path may change over time, due to changes in the
   routing topology.  Reductions of the PMTU are detected by Packet Too
   Big messages.  To detect increases in a path's PMTU, a node
   periodically increases its assumed PMTU.  This will almost always
   result in packets being discarded and Packet Too Big messages being
   generated, because in most cases the PMTU of the path will not have
   changed.  Therefore, attempts to detect increases in a path's PMTU
   should be done infrequently.

   Path MTU Discovery supports multicast as well as unicast
   destinations.  In the case of a multicast destination, copies of a
   packet may traverse many different paths to many different nodes.
   Each path may have a different PMTU, and a single multicast packet
   may result in multiple Packet Too Big messages, each reporting a
   different next-hop MTU.  The minimum PMTU value across the set of
   paths in use determines the size of subsequent packets sent to the
   multicast destination.

   Note that Path MTU Discovery must be performed even in cases where a
   node "thinks" a destination is attached to the same link as itself.
   In a situation such as when a neighboring router acts as proxy [ND]
   for some destination, the destination can to appear to be directly
   connected but is in fact more than one hop away.

4. Protocol Requirements

   As discussed in section 1, IPv6 nodes are not required to implement
   Path MTU Discovery.  The requirements in this section apply only to
   those implementations that include Path MTU Discovery.

   When a node receives a Packet Too Big message, it MUST reduce its
   estimate of the PMTU for the relevant path, based on the value of the
   MTU field in the message.  The precise behavior of a node in this
   circumstance is not specified, since different applications may have
   different requirements, and since different implementation
   architectures may favor different strategies.

   After receiving a Packet Too Big message, a node MUST attempt to
   avoid eliciting more such messages in the near future.  The node MUST
   reduce the size of the packets it is sending along the path.  Using a
   PMTU estimate larger than the IPv6 minimum link MTU may continue to
   elicit Packet Too Big messages.  Since each of these messages (and
   the dropped packets they respond to) consume network resources, the
   node MUST force the Path MTU Discovery process to end.

   Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast
   as possible.  Nodes MAY detect increases in PMTU, but because doing
   so requires sending packets larger than the current estimated PMTU,



McCann, Deering & Mogul     Standards Track                     [Page 4]

RFC 1981              Path MTU Discovery for IPv6            August 1996


   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 packet larger than the current estimate) MUST
   NOT be done less than 5 minutes after a Packet Too Big message has
   been received for the given path.  The recommended setting for this
   timer is twice its minimum value (10 minutes).

   A node MUST NOT reduce its estimate of the Path MTU below the IPv6
   minimum link MTU.

      Note: A node may receive a Packet Too Big message reporting a
      next-hop MTU that is less than the IPv6 minimum link MTU.  In that
      case, the node is not required to reduce the size of subsequent
      packets sent on the path to less than the IPv6 minimun link MTU,
      but rather must include a Fragment header in those packets [IPv6-
      SPEC].

   A node MUST NOT increase its estimate of the Path MTU in response to
   the contents of a Packet Too Big message.  A message purporting to
   announce an increase in the Path MTU might be a stale packet that has
   been floating around in the network, a false packet injected as part
   of a denial-of-service attack, or the result of having multiple paths
   to the destination, each with a different PMTU.

5. Implementation Issues

   This section discusses a number of issues related to the
   implementation of Path MTU Discovery.  This is not a specification,
   but rather a set of notes provided as an aid for implementors.

   The issues include:

   - What layer or layers implement Path MTU Discovery?

   - How is the PMTU information cached?

   - How is stale PMTU information removed?

   - What must transport and higher layers do?

5.1. Layering

   In the IP architecture, the choice of what size packet to send is
   made by a protocol at a layer above IP.  This memo refers 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).




McCann, Deering & Mogul     Standards Track                     [Page 5]