draft-ietf-6man-rfc1981bis-03.txt   draft-ietf-6man-rfc1981bis-04.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: April 7, 2017 J. Mogul Expires: August 4, 2017 J. Mogul
Digital Equipment Corporation Digital Equipment Corporation
R. Hinden, Ed. R. Hinden, Ed.
Check Point Software Check Point Software
October 4, 2016 January 31, 2017
Path MTU Discovery for IP version 6 Path MTU Discovery for IP version 6
draft-ietf-6man-rfc1981bis-03 draft-ietf-6man-rfc1981bis-04
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 April 7, 2017. This Internet-Draft will expire on August 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5
5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 6 5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 6
5.1. Layering . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Layering . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Storing PMTU information . . . . . . . . . . . . . . . . 7 5.2. Storing PMTU information . . . . . . . . . . . . . . . . 7
5.3. Purging stale PMTU information . . . . . . . . . . . . . 9 5.3. Purging stale PMTU information . . . . . . . . . . . . . 9
5.4. TCP layer actions . . . . . . . . . . . . . . . . . . . . 10 5.4. TCP layer actions . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . 15 Appendix A. Comparison to RFC 1191 . . . . . . . . . . . . . . . 15
Appendix B. Changes Since RFC 1981 . . . . . . . . . . . . . . . 15 Appendix B. Changes Since RFC 1981 . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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
skipping to change at page 3, line 24 skipping to change at page 3, line 24
MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet size. MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet size.
In most cases, this will result in the use of smaller packets than In most cases, this will result in the use of smaller packets than
necessary, because most paths have a PMTU greater than the IPv6 necessary, because most paths have a PMTU greater than the IPv6
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.
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]. It defines a method for Packetization Layer Path found in [RFC4821]. It defines a method for Packetization Layer Path
MTU Discovery (PLPMTUD) designed for use over paths where delivery of MTU Discovery (PLPMTUD) designed for use over paths where delivery of
ICMP messages to a host is not assured. In this algorithm, the ICMP messages to a host is not assured.
proper MTU is determined by starting with small packets and probing
with successively larger packets. The bulk of the algorithm is
implemented above IP, in the transport layer (e.g., TCP) or other
"Packetization Protocol" that is responsible for determining packet
boundaries.
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.
host any node that is not a router. host any node that is not a router.
skipping to change at page 4, line 43 skipping to change at page 4, line 38
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 (regardless of whether it decrements the Hop Limit) by some node along the path, that node will discard them and return
along the path, that node will discard them and return ICMPv6 Packet ICMPv6 Packet Too Big messages [ICMPv6]. Upon receipt of such a
Too Big messages [ICMPv6]. 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. message.
The Path MTU Discovery process ends when the node's estimate of the 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 PMTU is less than or equal to the actual PMTU. Note that several
iterations of the packet-sent/Packet-Too-Big-message-received cycle iterations of the packet-sent/Packet-Too-Big-message-received cycle
may occur before the Path MTU Discovery process ends, as there may be may occur before the Path MTU Discovery process ends, as there may be
links with smaller MTUs further along the path. 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 5, line 36 skipping to change at page 5, line 31
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] In a situation such as when a neighboring router acts as proxy [ND]
for some destination, the destination can to appear to be directly for some destination, the destination can to appear to be directly
connected but is in fact more than one hop away. connected but 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.
When a node receives a Packet Too Big message, it MUST reduce its 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 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 MTU field in the message. The precise behavior of a node in this
circumstance is not specified, since different applications may have circumstance is not specified, since different applications may have
different requirements, and since different implementation different requirements, and since different implementation
architectures may favor different strategies. architectures may favor different strategies.
skipping to change at page 7, line 17 skipping to change at page 7, line 10
Implementing Path MTU Discovery in the packetization layers Implementing Path MTU Discovery in the packetization layers
simplifies some of the inter-layer issues, but has several drawbacks: simplifies some of the inter-layer issues, but has several drawbacks:
the implementation may have to be redone for each packetization the implementation may have to be redone for each packetization
protocol, it becomes hard to share PMTU information between different protocol, it becomes hard to share PMTU information between different
packetization layers, and the connection-oriented state maintained by packetization layers, and the connection-oriented state maintained by
some packetization layers may not easily extend to save PMTU some packetization layers may not easily extend to save PMTU
information for long periods. information for long periods.
It is therefore suggested that the IP layer store PMTU information It is therefore suggested that the IP layer store PMTU information
and that the ICMP layer process received Packet Too Big messages. and that the ICMP layer process received Packet Too Big messages.
The packetization layers may respond to changes in the PMTU, by The packetization layers may respond to changes in the PMTU by
changing the size of the messages they send. To support this changing the size of the messages they send. To support this
layering, packetization layers require a way to learn of changes in layering, packetization layers require a way to learn of changes in
the value of MMS_S, the "maximum send transport-message size". The the value of MMS_S, the "maximum send transport-message size". The
MMS_S is derived from the Path MTU by subtracting the size of the MMS_S is derived from the Path MTU by subtracting the size of the
IPv6 header plus space reserved by the IP layer for additional IPv6 header plus space reserved by the IP layer for additional
headers (if any). headers (if any).
It is possible that a packetization layer, perhaps a UDP application It is possible that a packetization layer, perhaps a UDP application
outside the kernel, is unable to change the size of messages it outside the kernel, is unable to change the size of messages it
sends. This may result in a packet size that exceeds the Path MTU. sends. This may result in a packet size that exceeds the Path MTU.
skipping to change at page 7, line 47 skipping to change at page 7, line 40
Ideally, a PMTU value should be associated with a specific path Ideally, a PMTU value should be associated with a specific path
traversed by packets exchanged between the source and destination traversed by packets exchanged between the source and destination
nodes. However, in most cases a node will not have enough nodes. However, in most cases a node will not have enough
information to completely and accurately identify such a path. information to completely and accurately identify such a path.
Rather, a node must associate a PMTU value with some local Rather, a node must associate a PMTU value with some local
representation of a path. It is left to the implementation to select representation of a path. It is left to the implementation to select
the local representation of a path. the local representation of a path.
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 in local representation of the "path" to a multicast destination must
fact 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. packets than is necessary for many paths.
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
skipping to change at page 8, line 31 skipping to change at page 8, line 24
sent to a particular destination but belonging to different flows may sent to a particular destination but belonging to different flows may
use different paths, with the choice of path depending on the flow use different paths, with the choice of path depending on the flow
id. This approach will result in the use of optimally sized packets id. This approach will result in the use of optimally sized packets
on a per-flow basis, providing finer granularity than PMTU values on a per-flow basis, providing finer granularity than PMTU values
maintained on a per-destination basis. maintained on a per-destination basis.
For source routed packets (i.e. packets containing an IPv6 Routing For source routed packets (i.e. packets containing an IPv6 Routing
header [I-D.ietf-6man-rfc2460bis]), the source route may further header [I-D.ietf-6man-rfc2460bis]), the source route may further
qualify the local representation of a path. qualify the local representation of a path.
Note: Some paths may be further distinguished by different
security classifications. The details of such classifications are
beyond the scope of this memo.
Initially, the PMTU value for a path is assumed to be the (known) MTU Initially, the PMTU value for a path is assumed to be the (known) MTU
of the first-hop link. of the first-hop link.
When a Packet Too Big message is received, the node determines which 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 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 Big message. For example, if the destination address is used as the
local representation of a path, the destination address from the local representation of a path, the destination address from the
original packet would be used to determine which path the message original packet would be used to determine which path the message
applies to. applies to.
Note: if the original packet contained a Routing header, the Note: if the original packet contained a Routing header, the
Routing header should be used to determine the location of the Routing header should be used to determine the location of the
destination address within the original packet. If Segments Left destination address within the original packet. If Segments Left
is equal to zero, the destination address is in the Destination is equal to zero, the destination address is in the Destination
Address field in the IPv6 header. If Segments Left is greater Address field in the IPv6 header. If Segments Left is greater
than zero, the destination address is the last address than zero, the destination address is the last address
(Address[n]) in the Routing header. (Address[n]) in the Routing header.
The node then uses the value in the MTU field in the Packet Too Big The node then uses the value in the MTU field in the Packet Too Big
message as a tentative PMTU value, and compares the tentative PMTU to message as a tentative PMTU value or the minimum IPv6 next hope MTU
the existing PMTU. If the tentative PMTU is less than the existing if that is larger, and compares the tentative PMTU to the existing
PMTU estimate, the tentative PMTU replaces the existing PMTU as the PMTU. If the tentative PMTU is less than the existing PMTU estimate,
PMTU value for the path. the tentative PMTU replaces the existing PMTU as the PMTU value for
the path.
The packetization layers must be notified about decreases in the The packetization layers must be notified about decreases in the
PMTU. Any packetization layer instance (for example, a TCP PMTU. Any packetization layer instance (for example, a TCP
connection) that is actively using the path must be notified if the connection) that is actively using the path must be notified if the
PMTU estimate is decreased. PMTU estimate is decreased.
Note: even if the Packet Too Big message contains an Original Note: even if the Packet Too Big message contains an Original
Packet Header that refers to a UDP packet, the TCP layer must be Packet Header that refers to a UDP packet, the TCP layer must be
notified if any of its connections use the given path. notified if any of its connections use the given path.
skipping to change at page 11, line 5 skipping to change at page 10, line 46
The TCP layer must track the PMTU for the path(s) in use by a The TCP layer must track the PMTU for the path(s) in use by a
connection; it should not send segments that would result in packets connection; it should not send segments that would result in packets
larger than the PMTU. A simple implementation could ask the IP layer larger than the PMTU. A simple implementation could ask the IP layer
for this value each time it created a new segment, but this could be for this value each time it created a new segment, but this could be
inefficient. Moreover, TCP implementations that follow the "slow- inefficient. Moreover, TCP implementations that follow the "slow-
start" congestion-avoidance algorithm [CONG] typically calculate and start" congestion-avoidance algorithm [CONG] typically calculate and
cache several other values derived from the PMTU. It may be simpler cache several other values derived from the PMTU. It may be simpler
to receive asynchronous notification when the PMTU changes, so that to receive asynchronous notification when the PMTU changes, so that
these variables may be updated. these variables may be updated.
A TCP implementation must also store the MSS value received from its A TCP implementation must also store the Maximum Segment Size (MSS)
peer, and must not send any segment larger than this MSS, regardless value received from its peer, and must not send any segment larger
of the PMTU. In 4.xBSD-derived implementations, this may require than this MSS, regardless of the PMTU. In 4.xBSD-derived
adding an additional field to the TCP state record. implementations, this may require adding an additional field to the
TCP state record.
The value sent in the TCP MSS option is independent of the PMTU. The value sent in the TCP MSS option is independent of the PMTU.
This MSS option value is used by the other end of the connection, This MSS option value is used by the other end of the connection,
which may be using an unrelated PMTU value. See which may be using an unrelated PMTU value. See
[I-D.ietf-6man-rfc2460bis] sections "Packet Size Issues" and "Maximum [I-D.ietf-6man-rfc2460bis] sections "Packet Size Issues" and "Maximum
Upper-Layer Payload Size" for information on selecting a value for Upper-Layer Payload Size" for information on selecting a value for
the TCP MSS option. the TCP MSS option.
When a Packet Too Big message is received, it implies that a packet When a Packet Too Big message is received, it implies that a packet
was dropped by the node that sent the ICMP message. It is sufficient was dropped by the node that sent the ICMP message. It is sufficient
skipping to change at page 14, line 22 skipping to change at page 14, line 11
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]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", draft-ietf-6man-rfc2460bis-07 (work (IPv6) Specification", draft-ietf-6man-rfc2460bis-08 (work
in progress), October 2016. in progress), November 2016.
[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
[CONG] Jacobson, V., "Congestion Avoidance and Control", Proc. [CONG] Jacobson, V., "Congestion Avoidance and Control", Proc.
skipping to change at page 15, line 40 skipping to change at page 15, line 32
MTU plateau tables not needed because there are no old-style MTU plateau tables not needed because there are no old-style
messages messages
Appendix B. Changes Since RFC 1981 Appendix B. Changes Since RFC 1981
This document has the following changes from RFC1981. Numbers This document has the following changes from RFC1981. Numbers
identify the Internet-Draft version that the change was made.: identify the Internet-Draft version that the change was made.:
Working Group Internet Drafts Working Group Internet Drafts
04) Changes based on AD Evaluation including removing details
about RFC4821 algorithm in Section 1, remove text about
decrementing hop limit from Section 3, and removed text about
obsolete security classifications from Section 5.2.
04) Editorial changes and clarification in Section 5.2 based on
IP Directorate review by Donald Eastlake
03) Remove text in Section 5.3 regarding RH0 since it was 03) Remove text in Section 5.3 regarding RH0 since it was
deprecated by RFC5095 deprecated by RFC5095
02) Clarified in Section 3 that ICMP Packet Too Big should be 02) Clarified in Section 3 that ICMP Packet Too Big should be
sent even if the node doesn't decrement the hop limit sent even if the node doesn't decrement the hop limit
01) Revised the text about PLPMTUD to use the word "path". 01) Revised the text about PLPMTUD to use the word "path".
01) Editorial changes. 01) Editorial changes.
 End of changes. 17 change blocks. 
37 lines changed or deleted 38 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/