draft-ietf-6man-rfc1981bis-07.txt   draft-ietf-6man-rfc1981bis-08.txt 
Network Working Group J. McCann Network Working Group J. McCann
Internet-Draft Digital Equipment Corporation Internet-Draft Digital Equipment Corporation
Obsoletes: 1981 (if approved) S. Deering Obsoletes: 1981 (if approved) S. Deering
Intended status: Standards Track Retired Intended status: Standards Track Retired
Expires: November 17, 2017 J. Mogul Expires: November 28, 2017 J. Mogul
Digital Equipment Corporation Digital Equipment Corporation
R. Hinden, Ed. R. Hinden, Ed.
Check Point Software Check Point Software
May 16, 2017 May 27, 2017
Path MTU Discovery for IP version 6 Path MTU Discovery for IP version 6
draft-ietf-6man-rfc1981bis-07 draft-ietf-6man-rfc1981bis-08
Abstract Abstract
This document describes Path MTU Discovery for IP version 6. It is This document describes Path MTU Discovery for IP version 6. It is
largely derived from RFC 1191, which describes Path MTU Discovery for largely derived from RFC 1191, which describes Path MTU Discovery for
IP version 4. It obsoletes RFC1981. IP version 4. It obsoletes RFC1981.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 17, 2017. This Internet-Draft will expire on November 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 6
5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 7 5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 7
5.1. Layering . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Layering . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Storing PMTU information . . . . . . . . . . . . . . . . 8 5.2. Storing PMTU information . . . . . . . . . . . . . . . . 8
5.3. Purging stale PMTU information . . . . . . . . . . . . . 10 5.3. Purging stale PMTU information . . . . . . . . . . . . . 10
5.4. Packetization layer actions . . . . . . . . . . . . . . . 11 5.4. Packetization layer actions . . . . . . . . . . . . . . . 11
5.5. Issues for other transport protocols . . . . . . . . . . 12 5.5. Issues for other transport protocols . . . . . . . . . . 12
5.6. Management interface . . . . . . . . . . . . . . . . . . 13 5.6. Management interface . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Comparison to RFC 1191 . . . . . . . . . . . . . . . 16 Appendix A. Comparison to RFC 1191 . . . . . . . . . . . . . . . 15
Appendix B. Changes Since RFC 1981 . . . . . . . . . . . . . . . 16 Appendix B. Changes Since RFC 1981 . . . . . . . . . . . . . . . 16
B.1. Change History Since RFC1981 . . . . . . . . . . . . . . 17 B.1. Change History Since RFC1981 . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
When one IPv6 node has a large amount of data to send to another 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 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). 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 Alternatively, they can be larger packets that are fragmented into a
skipping to change at page 3, line 33 skipping to change at page 3, line 33
minimum link MTU. A node sending packets much smaller than the Path minimum link MTU. A node sending packets much smaller than the Path
MTU allows is wasting network resources and probably getting MTU allows is wasting network resources and probably getting
suboptimal throughput. suboptimal throughput.
Nodes implementing Path MTU Discovery and sending packets larger than Nodes implementing Path MTU Discovery and sending packets larger than
the IPv6 minimum link MTU are susceptible to problematic connectivity the IPv6 minimum link MTU are susceptible to problematic connectivity
if ICMPv6 [ICMPv6] messages are blocked or not transmitted. For if ICMPv6 [ICMPv6] messages are blocked or not transmitted. For
example, this will result in connections that complete the TCP three- example, this will result in connections that complete the TCP three-
way handshake correctly but then hang when data is transferred. This way handshake correctly but then hang when data is transferred. This
state is referred to as a black hole connection [RFC2923]. Path MTU state is referred to as a black hole connection [RFC2923]. Path MTU
Discovery relies on such messages to determine the MTU of the path. 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 An extension to Path MTU Discovery defined in this document can be
found in [RFC4821]. RFC4821 defines a method for Packetization Layer found in [RFC4821]. RFC4821 defines a method for Packetization Layer
Path MTU Discovery (PLPMTUD) designed for use over paths where Path MTU Discovery (PLPMTUD) designed for use over paths where
delivery of ICMPv6 messages to a host is not assured. delivery of ICMPv6 messages to a host is not assured.
Note: This document is an update to [RFC1981] that was published Note: This document is an update to [RFC1981] that was published
prior to [RFC2119] being published. Consequently although RFC1981 prior to [RFC2119] being published. Consequently although RFC1981
used the "should/must" style language in upper and lower case, the used the "should/must" style language in upper and lower case, this
document does not cite the RFC2119 definitions and only uses lower document does not cite the RFC2119 definitions and only uses lower
case for these words. case for these words.
2. Terminology 2. Terminology
node a device that implements IPv6. node a device that implements IPv6.
router a node that forwards IPv6 packets not explicitly router a node that forwards IPv6 packets not explicitly
addressed to itself. addressed to itself.
skipping to change at page 5, line 24 skipping to change at page 5, line 24
flow id a combination of a source address and a non-zero flow id a combination of a source address and a non-zero
flow label. flow label.
3. Protocol Overview 3. Protocol Overview
This memo describes a technique to dynamically discover the PMTU of a This memo describes a technique to dynamically discover the PMTU of a
path. The basic idea is that a source node initially assumes that 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. 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 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 by some node along the path, that node will discard them and return
ICMPv6 Packet Too Big (PTB) messages. Upon receipt of such a ICMPv6 Packet Too Big messages. Upon receipt of such a message, the
message, the source node reduces its assumed PMTU for the path based source node reduces its assumed PMTU for the path based on the MTU of
on the MTU of the constricting hop as reported in the Packet Too Big the constricting hop as reported in the Packet Too Big message. The
message. The decreased PMTU causes the source to send smaller decreased PMTU causes the source to send smaller packets or change
packets or change EMTU_S to cause upper layer to reduce the size of EMTU_S to cause upper layer to reduce the size of IP packets it
IP packets it sends. sends.
The Path MTU Discovery process ends when the source node's estimate 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 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 several iterations of the packet-sent/Packet-Too-Big-message-received
cycle may occur before the Path MTU Discovery process ends, as there cycle may occur before the Path MTU Discovery process ends, as there
may be links with smaller MTUs further along the path. may be links with smaller MTUs further along the path.
Alternatively, the node may elect to end the discovery process by Alternatively, the node may elect to end the discovery process by
ceasing to send packets larger than the IPv6 minimum link MTU. ceasing to send packets larger than the IPv6 minimum link MTU.
skipping to change at page 6, line 10 skipping to change at page 6, line 10
Path MTU Discovery supports multicast as well as unicast Path MTU Discovery supports multicast as well as unicast
destinations. In the case of a multicast destination, copies of a destinations. In the case of a multicast destination, copies of a
packet may traverse many different paths to many different nodes. packet may traverse many different paths to many different nodes.
Each path may have a different PMTU, and a single multicast packet Each path may have a different PMTU, and a single multicast packet
may result in multiple Packet Too Big messages, each reporting a may result in multiple Packet Too Big messages, each reporting a
different next-hop MTU. The minimum PMTU value across the set of different next-hop MTU. The minimum PMTU value across the set of
paths in use determines the size of subsequent packets sent to the paths in use determines the size of subsequent packets sent to the
multicast destination. multicast destination.
Note that Path MTU Discovery must be performed even in cases where a 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. 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] it might have a PMTU lower than the link MTU. In a situation such as
for some destination, the destination can appear to be directly when a neighboring router acts as proxy [ND] for some destination,
connected but it is in fact more than one hop away. the destination can appear to be directly connected but it is in fact
more than one hop away.
4. Protocol Requirements 4. Protocol Requirements
As discussed in Section 1, IPv6 nodes are not required to implement As discussed in Section 1, IPv6 nodes are not required to implement
Path MTU Discovery. The requirements in this section apply only to Path MTU Discovery. The requirements in this section apply only to
those implementations that include Path MTU Discovery. those implementations that include Path MTU Discovery.
Nodes should appropriately validate the payload of ICMPv6 PTB Nodes should appropriately validate the payload of ICMPv6 PTB
messages to ensure these are received in response to transmitted messages to ensure these are received in response to transmitted
traffic (i.e., a reported error condition that corresponds to an IPv6 traffic (i.e., a reported error condition that corresponds to an IPv6
skipping to change at page 8, line 48 skipping to change at page 8, line 49
In the case of a multicast destination address, copies of a packet In the case of a multicast destination address, copies of a packet
may traverse many different paths to reach many different nodes. The may traverse many different paths to reach many different nodes. The
local representation of the "path" to a multicast destination must local representation of the "path" to a multicast destination must
represent a potentially large set of paths. represent a potentially large set of paths.
Minimally, an implementation could maintain a single PMTU value to be Minimally, an implementation could maintain a single PMTU value to be
used for all packets originated from the node. This PMTU value would 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 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 node. This approach is likely to result in the use of smaller
packets than is necessary for many paths. In the case of multipath packets than is necessary for many paths. In the case of multipath
routing (e.g., Equal Cost Multipath Routing, ECMP), a set of paths routing (e.g., Equal Cost Multipath Routing (ECMP) ), a set of paths
can exist even for a single source and destination pair. can exist even for a single source and destination pair.
An implementation could use the destination address as the local An implementation could use the destination address as the local
representation of a path. The PMTU value associated with a representation of a path. The PMTU value associated with a
destination would be the minimum PMTU learned across the set of all destination would be the minimum PMTU learned across the set of all
paths in use to that destination. This approach will result in the paths in use to that destination. This approach will result in the
use of optimally sized packets on a per-destination basis. This use of optimally sized packets on a per-destination basis. This
approach integrates nicely with the conceptual model of a host as approach integrates nicely with the conceptual model of a host as
described in [ND]: a PMTU value could be stored with the described in [ND]: a PMTU value could be stored with the
corresponding entry in the destination cache. corresponding entry in the destination cache.
skipping to change at page 10, line 47 skipping to change at page 10, line 47
Internetwork topology is dynamic; routes change over time. While the Internetwork topology is dynamic; routes change over time. While the
local representation of a path may remain constant, the actual local representation of a path may remain constant, the actual
path(s) in use may change. Thus, PMTU information cached by a node path(s) in use may change. Thus, PMTU information cached by a node
can become stale. can become stale.
If the stale PMTU value is too large, this will be discovered almost 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 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, mechanism exists for realizing that a stale PMTU value is too small,
so an implementation should "age" cached values. When a PMTU value 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 has not been decreased for a while (on the order of 10 minutes), it
PMTU estimate should be set to the MTU of the first-hop link, and the should probe to find if a larger PMTU is supported.
packetization layers should be notified of the change. This will
cause the complete Path MTU Discovery process to take place again.
Note: an implementation should provide a means for changing the Note: an implementation should provide a means for changing the
timeout duration, including setting it to "infinity". For timeout duration, including setting it to "infinity". For
example, nodes attached to an FDDI link which is then attached to example, nodes attached to a link with a large MTU which is then
the rest of the Internet via a small MTU serial line are never attached to the rest of the Internet via a link with a small MTU
going to discover a new non-local PMTU, so they should not have to are never going to discover a new non-local PMTU, so they should
put up with dropped packets every 10 minutes. not have to put up with dropped packets every 10 minutes.
One approach to implementing PMTU aging is to associate a timestamp
field with a PMTU value. This field is initialized to a "reserved"
value, indicating that the PMTU is equal to the MTU of the first hop
link. Whenever the PMTU is decreased in response to a Packet Too Big
message, the timestamp is set to the current time.
Once a minute, a timer-driven procedure runs through all cached PMTU
values, and for each PMTU whose timestamp is not "reserved" and is
older than the timeout interval:
- The PMTU estimate is set to the MTU of the first hop link.
- The timestamp is set to the "reserved" value.
- Packetization layers using this path are notified of the increase.
5.4. Packetization layer actions 5.4. Packetization layer actions
A packetization layer (e.g., TCP) must use the PMTU for the path(s) 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 use by a connection; it should not send segments that would result
in packets larger than the PMTU, except to probe during PMTU in packets larger than the PMTU, except to probe during PMTU
discovery (this probe packet must not be fragmented to the PMTU). A discovery (this probe packet must not be fragmented to the PMTU). A
simple implementation could ask the IP layer for this value each time simple implementation could ask the IP layer for this value each time
it created a new segment, but this could be inefficient. An it created a new segment, but this could be inefficient. An
implementation typically caches other values derived from the PMTU. implementation typically caches other values derived from the PMTU.
skipping to change at page 12, line 20 skipping to change at page 11, line 48
upper layer protocol. If the Path MTU Discovery process requires upper layer protocol. If the Path MTU Discovery process requires
several steps to find the PMTU of the full path, this could finally several steps to find the PMTU of the full path, this could finally
delay the retransmission by many round-trip times. delay the retransmission by many round-trip times.
Alternatively, the retransmission could be done in immediate response Alternatively, the retransmission could be done in immediate response
to a notification that the Path MTU was decreased, but only for the to a notification that the Path MTU was decreased, but only for the
specific connection specified by the Packet Too Big message, but only specific connection specified by the Packet Too Big message, but only
based on the message and connection. The packet size used in the based on the message and connection. The packet size used in the
retransmission should be no larger than the new PMTU. retransmission should be no larger than the new PMTU.
Note: A packetization layer must not retransmit in response to Note: A packetization layer that determines a probe packet is
every Packet Too Big message, since a burst of several oversized lost, needs to adapt the segment size of the retransmission.
segments will give rise to several such messages and hence several Using the reported size in the last Packet Too Big message,
retransmissions of the same data. If the new estimated PMTU is however, can lead to further losses as there might be smaller PMTU
still wrong, the process repeats, and there is an exponential limits at the routers further along the path. This would lead to
growth in the number of superfluous segments sent. loss of all retransmitted segments and therefore cause unnecessary
Retransmissions can increase network load in response to congestion as well as additional packets to be sent each time a
congestion, worsening that congestion. Any packetization layer new router announces a smaller MTU. Any packetization layer that
that uses retransmission is responsible for congestion control of uses retransmission is therefore also responsible for congestion
its retransmissions. See [RFC8085] for more information. control of its retransmissions [RFC8085].
A loss caused by a PMTU probe indicated by the reception of a Packet 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 Too Big message must not be considered as a congestion notification
and hence the congestion window may not change. and hence the congestion window may not change.
5.5. Issues for other transport protocols 5.5. Issues for other transport protocols
Some transport protocols are not allowed to repacketize when doing a Some transport protocols are not allowed to repacketize when doing a
retransmission. That is, once an attempt is made to transmit a retransmission. That is, once an attempt is made to transmit a
segment of a certain size, the transport cannot split the contents of segment of a certain size, the transport cannot split the contents of
skipping to change at page 14, line 24 skipping to change at page 14, line 5
connections caused by filtering of ICMPv6 message. See [RFC4890] for connections caused by filtering of ICMPv6 message. See [RFC4890] for
recommendations regarding filtering ICMPv6 messages. recommendations regarding filtering ICMPv6 messages.
7. Acknowledgements 7. Acknowledgements
We would like to acknowledge the authors of and contributors to We would like to acknowledge the authors of and contributors to
[RFC1191], from which the majority of this document was derived. We [RFC1191], from which the majority of this document was derived. We
would also like to acknowledge the members of the IPng working group would also like to acknowledge the members of the IPng working group
for their careful review and constructive criticisms. 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 w.g., area directorate reviewers, the IESG, and especially to
Joe Touch and Gorry Fairhurst.
8. IANA Considerations 8. IANA Considerations
This document does not have any IANA actions This document does not have any IANA actions
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-6man-rfc2460bis] [I-D.ietf-6man-rfc2460bis]
<>, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Deering, S. and R. Hinden, "Internet Protocol, Version 6
Specification", draft-ietf-6man-rfc2460bis-11 (work in (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work
progress), April 2017. in progress), May 2017.
[ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443, DOI Protocol Version 6 (IPv6) Specification", RFC 4443, DOI
10.17487/RFC4443, March 2006, 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>. <http://www.rfc-editor.org/info/rfc4443>.
9.2. Informative References 9.2. Informative References
[FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", [FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful",
skipping to change at page 17, line 45 skipping to change at page 17, line 34
TP4. TP4.
o Updated text in Section 5.5 "Issues for other transport protocols" o Updated text in Section 5.5 "Issues for other transport protocols"
about NFS including adding a current reference to NFS and removing about NFS including adding a current reference to NFS and removing
obsolete text. obsolete text.
o Added paragraph to Section 6 "Security Considerations" about black o Added paragraph to Section 6 "Security Considerations" about black
hole connections if PTB messages are not received, and comparison hole connections if PTB messages are not received, and comparison
to PLPMTD. to PLPMTD.
o Updated Section 7 "Acknowledgements".
o Editorial Changes. o Editorial Changes.
B.1. Change History Since RFC1981 B.1. Change History Since RFC1981
NOTE TO RFC EDITOR: Please remove this subsection prior to RFC NOTE TO RFC EDITOR: Please remove this subsection prior to RFC
Publication Publication
This section describes change history made in each Internet Draft This section describes change history made in each Internet Draft
that went into producing this version. The numbers identify the that went into producing this version. The numbers identify the
Internet-Draft version in which the change was made. Internet-Draft version in which the change was made.
Working Group Internet Drafts Working Group Internet Drafts
08) Based on IESG comments, cleaned up text in Section 5.3
regarding suggested action when PMTU value has not been
decreased recently.
08) Revision of Note in Section 5.4 to make text clearer.
08) Updated Section 7 "Acknowledgements".
08) Editorial Changes.
07) Changes from the IESG Discuss comments from IESG reviews. 07) Changes from the IESG Discuss comments from IESG reviews.
The changes include: The changes include:
o Added Note to Introduction that document that this o Added Note to Introduction that document that this
document doesn't cite RFC2119 and only uses lower case document doesn't cite RFC2119 and only uses lower case
"should/must" language. Changed all upper case "should/ "should/must" language. Changed all upper case "should/
must" to lower case. must" to lower case.
o Added references for EMTU_S and EMTU_R. o Added references for EMTU_S and EMTU_R.
 End of changes. 20 change blocks. 
57 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/