summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8201.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8201.txt')
-rw-r--r--doc/rfc/rfc8201.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc8201.txt b/doc/rfc/rfc8201.txt
new file mode 100644
index 0000000..6a85b77
--- /dev/null
+++ b/doc/rfc/rfc8201.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. McCann
+Request for Comments: 8201 Digital Equipment Corporation
+STD: 87 S. Deering
+Obsoletes: 1981 Retired
+Category: Standards Track J. Mogul
+ISSN: 2070-1721 Digital Equipment Corporation
+ R. Hinden, Ed.
+ Check Point Software
+ July 2017
+
+
+ Path MTU Discovery for IP version 6
+
+Abstract
+
+ This document describes Path MTU Discovery (PMTUD) for IP version 6.
+ It is largely derived from RFC 1191, which describes Path MTU
+ Discovery for IP version 4. It obsoletes RFC 1981.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc8201.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCann, et al. Standards Track [Page 1]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCann, et al. Standards Track [Page 2]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7
+ 5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 8
+ 5.1. Layering . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.2. Storing PMTU Information . . . . . . . . . . . . . . . . 9
+ 5.3. Purging Stale PMTU Information . . . . . . . . . . . . . 11
+ 5.4. Packetization Layer Actions . . . . . . . . . . . . . . . 12
+ 5.5. Issues for Other Transport Protocols . . . . . . . . . . 13
+ 5.6. Management Interface . . . . . . . . . . . . . . . . . . 14
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 15
+ Appendix A. Comparison to RFC 1191 . . . . . . . . . . . . . . . 17
+ Appendix B. Changes Since RFC 1981 . . . . . . . . . . . . . . . 17
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCann, et al. Standards Track [Page 3]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+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. These
+ packets can have a size less than or equal to the Path MTU (PMTU).
+ Alternatively, they can be larger packets that are fragmented into a
+ series of fragments each with a size less than or equal to the PMTU.
+
+ 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 without the need for IPv6 fragmentation. This
+ packet size is referred to as the Path MTU, and it is equal to the
+ minimum link MTU of all the links in a path. This document 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 [RFC8200]. 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 must use the IPv6 minimum
+ link MTU defined in [RFC8200] 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.
+
+ Nodes implementing Path MTU Discovery and sending packets larger than
+ the IPv6 minimum link MTU are susceptible to problematic connectivity
+ if ICMPv6 [ICMPv6] messages are blocked or not transmitted. For
+ example, this will result in connections that complete the TCP three-
+ way handshake correctly but then hang when data is transferred. This
+ state is referred to as a black-hole connection [RFC2923]. Path MTU
+ Discovery relies on ICMPv6 Packet Too Big (PTB) to determine the MTU
+ of the path.
+
+ An extension to Path MTU Discovery defined in this document can be
+ found in [RFC4821]. RFC 4821 defines a method for Packetization
+ Layer Path MTU Discovery (PLPMTUD) designed for use over paths where
+ delivery of ICMPv6 messages to a host is not assured.
+
+ Note: This document is an update to [RFC1981] that was published
+ prior to [RFC2119] being published. Consequently, although RFC 1981
+ used the "should/must" style language in upper and lower case, this
+ document does not cite the RFC 2119 definitions and only uses lower
+ case for these words.
+
+
+
+
+McCann, et al. Standards Track [Page 4]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+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 ICMPv6, routing
+ protocols such as OSPF, and internet-layer or
+ lower-layer protocols being "tunneled" over
+ (i.e., encapsulated in) IPv6 such as Internetwork
+ Packet Exchange (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-layer
+ or higher-layer "tunnels", such as tunnels over
+ IPv4 or IPv6 itself.
+
+ interface a node's attachment to a link.
+
+ address an IPv6-layer identifier for an interface or a
+ set of interfaces.
+
+ packet an IPv6 header plus payload. The packet can have
+ a size less than or equal to the PMTU.
+ Alternatively, this can be a larger packet that
+ is fragmented into a series of fragments each
+ with a size less than or equal to the PMTU.
+
+ 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.
+
+
+
+
+McCann, et al. Standards Track [Page 5]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+ Path MTU Discovery the process by which a node learns the PMTU of a
+ path.
+
+ EMTU_S Effective MTU for sending; used by upper-layer
+ protocols to limit the size of IP packets they
+ queue for sending [RFC6691] [RFC1122].
+
+ EMTU_R Effective MTU for receiving; the largest packet
+ that can be reassembled at the receiver
+ [RFC1122].
+
+ 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. 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
+ decreased PMTU causes the source to send smaller packets or change
+ EMTU_S to cause the upper layer to reduce the size of IP packets it
+ sends.
+
+ The Path MTU Discovery process ends when the source 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.
+
+ 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
+
+
+
+
+McCann, et al. Standards Track [Page 6]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+ 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,
+ as it might have a PMTU lower than the link MTU. In a situation such
+ as when a neighboring router acts as proxy [ND] for some destination,
+ the destination can appear to be directly connected, but it 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.
+
+ Nodes should appropriately validate the payload of ICMPv6 PTB
+ messages to ensure these are received in response to transmitted
+ traffic (i.e., a reported error condition that corresponds to an IPv6
+ packet actually sent by the application) per [ICMPv6].
+
+ If a node receives a Packet Too Big message reporting a next-hop MTU
+ that is less than the IPv6 minimum link MTU, it must discard it. A
+ node must not reduce its estimate of the Path MTU below the IPv6
+ minimum link MTU on receipt of a Packet Too Big message.
+
+ 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. Because each of these messages (and
+
+
+
+McCann, et al. Standards Track [Page 7]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+ the dropped packets they respond to) consume network resources, 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, 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 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 (DoS) 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 implementers.
+
+ 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).
+
+ Implementing Path MTU 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
+
+
+
+McCann, et al. Standards Track [Page 8]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+ packetization layers, and the connection-oriented state maintained by
+ some packetization layers may not easily extend to save PMTU
+ information for long periods.
+
+ It is therefore suggested that the IP layer store PMTU information
+ and that the ICMPv6 layer process received Packet Too Big messages.
+ The packetization layers may respond to changes in the PMTU by
+ changing the size of the messages they send. To support this
+ layering, packetization layers require a way to learn of changes in
+ the value of MMS_S, the "maximum send transport-message size"
+ [RFC1122].
+
+ MMS_S is a transport message size calculated by subtracting the size
+ of the IPv6 header (including IPv6 extension headers) from the
+ largest IP packet that can be sent, EMTU_S. MMS_S is limited by a
+ combination of factors, including the PMTU, support for packet
+ fragmentation and reassembly, and the packet reassembly limit (see
+ "Fragment Header", Section 4.5 of [RFC8200]). When source
+ fragmentation is available, EMTU_S is set to EMTU_R, as indicated by
+ the receiver using an upper-layer protocol or based on protocol
+ requirements (1500 octets for IPv6). When a message larger than PMTU
+ is to be transmitted, the source creates fragments, each limited by
+ PMTU. When source fragmentation is not desired, EMTU_S is set to
+ PMTU, and the upper-layer protocol is expected to either perform its
+ own fragmentation and reassembly or otherwise limit the size of its
+ messages accordingly.
+
+ However, packetization layers are encouraged to avoid sending
+ messages that will require source fragmentation (for the case against
+ fragmentation, see [FRAG]).
+
+5.2. Storing PMTU Information
+
+ Ideally, a PMTU value should be associated with a specific path
+ traversed by packets exchanged between the source and destination
+ nodes. However, in most cases a node will not have enough
+ information to completely and accurately identify such a path.
+ Rather, a node must associate a PMTU value with some local
+ representation of a path. It is left to the implementation to select
+ the local representation of a path. For nodes with multiple
+ interfaces, Path MTU information should be maintained for each IPv6
+ link.
+
+ In the case of a multicast destination address, copies of a packet
+ may traverse many different paths to reach many different nodes. The
+ local representation of the "path" to a multicast destination must
+ represent a potentially large set of paths.
+
+
+
+
+McCann, et al. Standards Track [Page 9]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+ Minimally, an implementation could maintain a single PMTU value to be
+ used for all packets originated from the node. This PMTU value would
+ be the minimum PMTU learned across the set of all paths in use by the
+ node. This approach is likely to result in the use of smaller
+ packets than is necessary for many paths. In the case of multipath
+ routing (e.g., Equal-Cost Multipath Routing (ECMP)), a set of paths
+ can exist even for a single source and destination pair.
+
+ An implementation could use the destination address as the local
+ representation of a path. The PMTU value associated with a
+ destination would be the minimum PMTU learned across the set of all
+ paths in use to that destination. This approach will result in the
+ use of optimally sized packets on a per-destination basis. This
+ approach integrates nicely with the conceptual model of a host as
+ described in [ND]: a PMTU value could be stored with the
+ corresponding entry in the destination cache.
+
+ If flows [RFC8200] are in use, an implementation could use the flow
+ id as the local representation of a path. Packets sent to a
+ particular destination but belonging to different flows may use
+ different paths, as with ECMP, in which the choice of path might
+ depend on the flow id. This approach might result in the use of
+ optimally sized packets on a per-flow basis, providing finer
+ granularity than PMTU values maintained on a per-destination basis.
+
+ For source-routed packets (i.e. packets containing an IPv6 Routing
+ header [RFC8200]), the source route may further qualify the local
+ representation of a path.
+
+ Initially, the PMTU value for a path is assumed to be the (known) MTU
+ of the first-hop link.
+
+ When a Packet Too Big message is received, the node determines which
+ path the message applies to based on the contents of the Packet Too
+ Big message. For example, if the destination address is used as the
+ local representation of a path, the destination address from the
+ original packet would be used to determine which path the message
+ applies to.
+
+ Note: if the original packet contained a Routing header, the
+ Routing header should be used to determine the location of the
+ destination address within the original packet. If Segments Left
+ is equal to zero, the destination address is in the Destination
+ Address field in the IPv6 header. If Segments Left is greater
+ than zero, the destination address is the last address
+ (Address[n]) in the Routing header.
+
+
+
+
+
+McCann, et al. Standards Track [Page 10]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+ The node then uses the value in the MTU field in the Packet Too Big
+ message as a tentative PMTU value or the IPv6 minimum link MTU if
+ that is larger, and compares the tentative PMTU to the existing PMTU.
+ If the tentative PMTU is less than the existing PMTU estimate, the
+ tentative PMTU replaces the existing PMTU as the PMTU value for the
+ path.
+
+ 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 Packet Too Big message contains an Original
+ Packet Header that refers to a UDP packet, the TCP layer must be
+ notified if any of its connections use the given path.
+
+ Also, the instance that sent the packet that elicited the Packet Too
+ Big message should be notified that its packet has been dropped, even
+ if the PMTU estimate has not changed, so that it may retransmit the
+ dropped data.
+
+ Note: An implementation can avoid the use of an asynchronous
+ notification mechanism for PMTU decreases by postponing
+ notification until the next attempt to send a packet larger than
+ the PMTU estimate. In this approach, when an attempt is made to
+ SEND a packet that 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 ICMPv6 layer. In this case, the
+ normal timeout-based retransmission mechanisms would be used to
+ recover from the dropped packets.
+
+ 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.
+
+5.3. Purging Stale PMTU Information
+
+ Internetwork topology is dynamic; routes change over time. While the
+ local representation of a path may remain constant, the actual
+ path(s) in use may change. Thus, PMTU information cached by a node
+ can become stale.
+
+
+
+
+McCann, et al. Standards Track [Page 11]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+ If the stale PMTU value is too large, this will be discovered almost
+ immediately once a large enough packet is sent on the path. 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), it
+ should probe to find if a larger PMTU is supported.
+
+ Note: an implementation should provide a means for changing the
+ timeout duration, including setting it to "infinity". For
+ example, nodes attached to a link with a large MTU that is then
+ attached to the rest of the Internet via a link with a small MTU
+ are never going to discover a new non-local PMTU, so they should
+ not have to put up with dropped packets every 10 minutes.
+
+5.4. Packetization Layer Actions
+
+ A packetization layer (e.g., TCP) must use the PMTU for the path(s)
+ in use by a connection; it should not send segments that would result
+ in packets larger than the PMTU, except to probe during PMTU
+ Discovery (this probe packet must not be fragmented to the PMTU). A
+ simple implementation could ask the IP layer for this value each time
+ it created a new segment, but this could be inefficient. An
+ implementation typically caches other values derived from the PMTU.
+ It may be simpler to receive asynchronous notification when the PMTU
+ changes, so that these variables may be also updated.
+
+ A TCP implementation must also store the Maximum Segment Size (MSS)
+ value received from its peer, which represents the EMTU_R, the
+ largest packet that can be reassembled by the receiver, and must not
+ send any segment larger than this MSS, regardless of the PMTU.
+
+ The value sent in the TCP MSS option is independent of the PMTU; it
+ is determined by the receiver reassembly limit EMTU_R. This MSS
+ option value is used by the other end of the connection, which may be
+ using an unrelated PMTU value. See Section 5, "Packet Size Issues",
+ and Section 8.3, "Maximum Upper-Layer Payload Size", of [RFC8200] for
+ information on selecting a value for the TCP MSS option.
+
+ Reception of a Packet Too Big message implies that a packet was
+ dropped by the node that sent the ICMPv6 message. A reliable upper-
+ layer protocol will detect this loss by its own means, and recover it
+ by its normal retransmission methods. The retransmission could
+ result in delay, depending on the loss detection method used by the
+ upper-layer protocol. If the Path MTU Discovery process requires
+ several steps to find the PMTU of the full path, this could finally
+ delay the retransmission by many round-trip times.
+
+
+
+
+
+McCann, et al. Standards Track [Page 12]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+ Alternatively, the retransmission could be done in immediate response
+ to a notification that the Path MTU was decreased, but only for the
+ specific connection specified by the Packet Too Big message. The
+ packet size used in the retransmission should be no larger than the
+ new PMTU.
+
+ Note: A packetization layer that determines a probe packet is lost
+ needs to adapt the segment size of the retransmission. Using the
+ reported size in the last Packet Too Big message, however, can
+ lead to further losses as there might be smaller PMTU limits at
+ the routers further along the path. This would lead to loss of
+ all retransmitted segments and therefore cause unnecessary
+ congestion as well as additional packets to be sent each time a
+ new router announces a smaller MTU. Any packetization layer that
+ uses retransmission is therefore also responsible for congestion
+ control of its retransmissions [RFC8085].
+
+ A loss caused by a PMTU probe indicated by the reception of a Packet
+ Too Big message must not be considered as a congestion notification,
+ and hence the congestion window may not change.
+
+5.5. Issues for Other Transport Protocols
+
+ Some transport protocols are not allowed to repacketize when doing a
+ retransmission. That is, once an attempt is made to transmit a
+ segment of a certain size, the transport cannot split the contents of
+ the segment into smaller segments for retransmission. In such a
+ case, the original segment can be fragmented by the IP layer during
+ retransmission. Subsequent segments, when transmitted for the first
+ time, should be no larger than allowed by the Path MTU.
+
+ Path MTU Discovery for IPv4 [RFC1191] used NFS as an example of a
+ UDP-based application that benefits from PMTU Discovery. Since then,
+ [RFC7530] states that the supported transport layer between NFS and
+ IP must be an IETF standardized transport protocol that is specified
+ to avoid network congestion; such transports include TCP, Stream
+ Control Transmission Protocol (SCTP) [RFC4960], and the Datagram
+ Congestion Control Protocol (DCCP) [RFC4340]. In this case, the
+ transport is responsible for ensuring that transmitted segments
+ (except probes) conform to the Path MTU, including supporting PMTU
+ Discovery probe transmissions as needed.
+
+
+
+
+
+
+
+
+
+
+McCann, et al. Standards Track [Page 13]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+5.6. Management Interface
+
+ It is suggested that an implementation provides a way for a system
+ utility program to:
+
+ - Specify that Path MTU Discovery not be done on a given path.
+
+ - Change the PMTU value associated with a given path.
+
+ The former can be accomplished by associating a flag with the path;
+ when a packet is sent on a path with this flag set, the IP layer does
+ not send packets larger than the IPv6 minimum link MTU.
+
+ 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.
+
+6. Security Considerations
+
+ This Path MTU Discovery mechanism makes possible two DoS attacks,
+ both based on a malicious party sending false Packet Too Big messages
+ to a node.
+
+ In the first attack, the false message indicates a PMTU much
+ smaller than reality. In response, the victim node should never
+ set its PMTU estimate below the IPv6 minimum link MTU. A sender
+ that falsely reduces to this MTU would observe suboptimal
+ performance.
+
+ In the second attack, the false message indicates a PMTU larger
+ than reality. If believed, this could cause temporary blockage as
+ the victim sends packets that will be dropped by some router.
+ Within one round-trip time, the node would discover its mistake
+ (receiving Packet Too Big messages from that router), but frequent
+ repetition of this attack could cause lots of packets to be
+ dropped. A node, however, must not raise its estimate of the PMTU
+ based on a Packet Too Big message, so it should not be vulnerable
+ to this attack.
+
+ Both of these attacks can cause a black-hole connection, that is, the
+ TCP three-way handshake completes correctly but the connection hangs
+ when data is transferred.
+
+
+
+
+
+
+McCann, et al. Standards Track [Page 14]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+ A malicious party could also cause problems if it could stop a victim
+ from receiving legitimate Packet Too Big messages, but in this case
+ there are simpler DoS attacks available.
+
+ If ICMPv6 filtering prevents reception of ICMPv6 Packet Too Big
+ messages, the source will not learn the actual path MTU.
+ "Packetization Layer Path MTU Discovery" [RFC4821] does not rely upon
+ network support for ICMPv6 messages and is therefore considered more
+ robust than standard PMTUD. It is not susceptible to "black-holed"
+ connections caused by the filtering of ICMPv6 messages. See
+ [RFC4890] for recommendations regarding filtering ICMPv6 messages.
+
+7. IANA Considerations
+
+ This document does not require any IANA actions.
+
+8. References
+
+8.1. Normative References
+
+ [ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+ Control Message Protocol (ICMPv6) for the Internet
+ Protocol Version 6 (IPv6) Specification", STD 89,
+ RFC 4443, DOI 10.17487/RFC4443, March 2006,
+ <http://www.rfc-editor.org/info/rfc4443>.
+
+ [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", STD 86, RFC 8200,
+ DOI 10.17487/RFC8200, July 2017,
+ <http://www.rfc-editor.org/info/rfc8200>.
+
+8.2. Informative References
+
+ [FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful",
+ In Proc. SIGCOMM '87 Workshop on Frontiers in Computer
+ Communications Technology, DOI 10.1145/55483.55524, August
+ 1987.
+
+ [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+ "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+ DOI 10.17487/RFC4861, September 2007,
+ <http://www.rfc-editor.org/info/rfc4861>.
+
+ [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122,
+ DOI 10.17487/RFC1122, October 1989,
+ <http://www.rfc-editor.org/info/rfc1122>.
+
+
+
+
+McCann, et al. Standards Track [Page 15]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+ [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+ DOI 10.17487/RFC1191, November 1990,
+ <http://www.rfc-editor.org/info/rfc1191>.
+
+ [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
+ for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
+ 1996, <http://www.rfc-editor.org/info/rfc1981>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
+ RFC 2923, DOI 10.17487/RFC2923, September 2000,
+ <http://www.rfc-editor.org/info/rfc2923>.
+
+ [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
+ Congestion Control Protocol (DCCP)", RFC 4340,
+ DOI 10.17487/RFC4340, March 2006,
+ <http://www.rfc-editor.org/info/rfc4340>.
+
+ [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
+ Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
+ <http://www.rfc-editor.org/info/rfc4821>.
+
+ [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
+ ICMPv6 Messages in Firewalls", RFC 4890,
+ DOI 10.17487/RFC4890, May 2007,
+ <http://www.rfc-editor.org/info/rfc4890>.
+
+ [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
+ RFC 4960, DOI 10.17487/RFC4960, September 2007,
+ <http://www.rfc-editor.org/info/rfc4960>.
+
+ [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)",
+ RFC 6691, DOI 10.17487/RFC6691, July 2012,
+ <http://www.rfc-editor.org/info/rfc6691>.
+
+ [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
+ (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
+ March 2015, <http://www.rfc-editor.org/info/rfc7530>.
+
+ [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
+ Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
+ March 2017, <http://www.rfc-editor.org/info/rfc8085>.
+
+
+
+
+
+McCann, et al. Standards Track [Page 16]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+Appendix A. Comparison to RFC 1191
+
+ RFC 1981 (obsoleted by this document) was based in large part on RFC
+ 1191, which describes Path MTU Discovery for IPv4. Certain portions
+ of RFC 1191 were not needed in RFC 1981:
+
+ router specification Packet Too Big messages and corresponding
+ router behavior are defined in [ICMPv6]
+
+ Don't Fragment bit there is no DF bit in IPv6 packets
+
+ TCP MSS discussion selecting a value to send in the TCP MSS option
+ is discussed in [RFC8200]
+
+ old-style messages all Packet Too Big messages report the MTU of
+ the constricting link
+
+ MTU plateau tables not needed because there are no old-style
+ messages
+
+Appendix B. Changes Since RFC 1981
+
+ This document is based on RFC 1981 and has the following changes from
+ RFC 1981:
+
+ o Clarified in Section 1, "Introduction", that the purpose of PMTUD
+ is to reduce the need for IPv6 fragmentation.
+
+ o Added text to Section 1, "Introduction", about the effects on
+ PMTUD when ICMPv6 messages are blocked.
+
+ o Added a "Note" to the introduction to document that this
+ specification doesn't cite RFC 2119 and only uses lower case
+ "should/must" language. Changed all upper case "should/must" to
+ lower case.
+
+ o Added a short summary to Section 1, "Introduction", about PLPMTUD
+ and a reference to RFC 4821 that defines it.
+
+ o Aligned text in Section 2, "Terminology", to match current
+ packetization layer terminology.
+
+ o Added clarification in Section 4, "Protocol Requirements", that
+ nodes should validate the payload of ICMP PTB messages per RFC
+ 4443, and that nodes should detect decreases in PMTU as fast as
+ possible.
+
+
+
+
+
+McCann, et al. Standards Track [Page 17]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+ o Removed a "Note" from Section 4, "Protocol Requirements", about a
+ Packet Too Big message reporting a next-hop MTU that is less than
+ the IPv6 minimum link MTU because this was removed from [RFC8200].
+
+ o Added clarification in Section 5.2, "Storing PMTU Information", to
+ discard an ICMPv6 Packet Too Big message if it contains an MTU
+ less than the IPv6 minimum link MTU.
+
+ o Added clarification in Section 5.2, "Storing PMTU Information",
+ that for nodes with multiple interfaces, Path MTU information
+ should be stored for each link.
+
+ o Removed text in Section 5.2, "Storing PMTU Information", about
+ Routing Header type 0 (RH0) because it was deprecated by RFC 5095.
+
+ o Removed text about obsolete security classification from
+ Section 5.2, "Storing PMTU Information".
+
+ o Changed the title of Section 5.4 to "Packetization Layer Actions"
+ and changed the text in the first paragraph to generalize this
+ section to cover all packetization layers, not just TCP.
+
+ o Clarified text in Section 5.4, "Packetization Layer Actions", to
+ use normal packetization layer retransmission methods.
+
+ o Removed text in Section 5.4, "Packetization Layer Actions", that
+ described 4.2 BSD because it is obsolete, and removed reference to
+ TP4.
+
+ o Updated text in Section 5.5, "Issues for Other Transport
+ Protocols", about NFS, including adding a current reference to NFS
+ and removing obsolete text.
+
+ o Added a paragraph to Section 6, "Security Considerations", about
+ black-hole connections if PTB messages are not received and
+ comparison to PLPMTUD.
+
+ o Updated "Acknowledgements".
+
+ o Editorial Changes.
+
+
+
+
+
+
+
+
+
+
+
+McCann, et al. Standards Track [Page 18]
+
+RFC 8201 IPv6 Path MTU Discovery July 2017
+
+
+Acknowledgements
+
+ We would like to acknowledge the authors of and contributors to
+ [RFC1191], from which the majority of this document was derived. We
+ would also like to acknowledge the members of the IPng Working Group
+ for their careful review and constructive criticisms.
+
+ We would also like to acknowledge the contributors to this update of
+ "Path MTU Discovery for IP Version 6". This includes members of the
+ 6MAN Working Group, area directorate reviewers, the IESG, and
+ especially Joe Touch and Gorry Fairhurst.
+
+Authors' Addresses
+
+ Jack McCann
+ Digital Equipment Corporation
+
+
+ Stephen E. Deering
+ Retired
+ Vancouver, British Columbia
+ Canada
+
+
+ Jeffrey Mogul
+ Digital Equipment Corporation
+
+
+ Robert M. Hinden (editor)
+ Check Point Software
+ 959 Skyway Road
+ San Carlos, CA 94070
+ United States of America
+
+ Email: bob.hinden@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCann, et al. Standards Track [Page 19]
+