draft-ietf-6man-rfc1981bis-05.txt   draft-ietf-6man-rfc1981bis-06.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: October 2, 2017 J. Mogul Expires: October 9, 2017 J. Mogul
Digital Equipment Corporation Digital Equipment Corporation
R. Hinden, Ed. R. Hinden, Ed.
Check Point Software Check Point Software
March 31, 2017 April 7, 2017
Path MTU Discovery for IP version 6 Path MTU Discovery for IP version 6
draft-ietf-6man-rfc1981bis-05 draft-ietf-6man-rfc1981bis-06
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 October 2, 2017. This Internet-Draft will expire on October 9, 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 41 skipping to change at page 2, line 41
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 . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . 15 Appendix A. Comparison to RFC 1191 . . . . . . . . . . . . . . . 15
Appendix B. Changes Since RFC 1981 . . . . . . . . . . . . . . . 16 Appendix B. Changes Since RFC 1981 . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 B.1. Change History Since RFC1981 . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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
series of fragments each with a size less than or equal to the PMTU. 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 It is usually preferable that these packets be of the largest size
skipping to change at page 3, line 28 skipping to change at page 3, line 28
Nodes not implementing Path MTU Discovery MUST use the IPv6 minimum Nodes not implementing Path MTU Discovery MUST use the IPv6 minimum
link MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet link 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 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 than 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.
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 loss if ICMPv6 [ICMPv6] the IPv6 minimum link MTU are susceptible to problematic connectivity
messages are blocked or not transmitted. For example, this will if ICMPv6 [ICMPv6] messages are blocked or not transmitted. For
result in connections that complete the TCP three-way handshake example, this will result in connections that complete the TCP three-
correctly but then hang when data is transferred. This state is way handshake correctly but then hang when data is transferred. This
referred to as a black hole connection. Path MTU Discovery relies on state is referred to as a black hole connection. Path MTU Discovery
such messages to determine the MTU of the path. relies on such messages 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.
2. Terminology 2. Terminology
node a device that implements IPv6. node a device that implements IPv6.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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 value of MMS_S, the "maximum send transport-message size".
MMS_S is a transport message size calculated by subtracting the size MMS_S is a transport message size calculated by subtracting the size
of the IPv6 header (including IPv6 extension headers) from the 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 largest IP packet that can be sent, EMTU_S. MMS_S is limited by a
combination of factors, including the PMTU, support for packet combination of factors, including the PMTU, support for packet
fragmentation and reassembly, and the packet reassembly limit (see fragmentation and reassembly, and the packet reassembly limit (see
[I-D.ietf-6man-rfc2460bis] section "Fragment Header"). When source [I-D.ietf-6man-rfc2460bis] section "Fragment Header"). When source
fragmentation is available, EMTU_S is set to EMTU_R, as indicated by fragmentation is available, EMTU_S is set to EMTU_R, as indicated by
the receiver at using an upper layer protocol or based on protocol the receiver using an upper layer protocol or based on protocol
requirements (1500 octets for IPv6). When a message larger than PMTU requirements (1500 octets for IPv6). When a message larger than PMTU
is to be transmitted, the source creates fragments, each limited by is to be transmitted, the source creates fragments, each limited by
PMTU. When source fragmentation is not desired, EMTU_S is set to PMTU. When source fragmentation is not desired, EMTU_S is set to
PMTU, and the upper layer protocol is expected to either perform its PMTU, and the upper layer protocol is expected to either perform its
own fragmentation and reassembly or otherwise limit the size of its own fragmentation and reassembly or otherwise limit the size of its
messages accordingly. messages accordingly.
However, packetization layers are encouraged to avoid sending However, packetization layers are encouraged to avoid sending
messages that will require source fragmentation (for the case against messages that will require source fragmentation (for the case against
fragmentation, see [FRAG]). fragmentation, see [FRAG]).
skipping to change at page 9, line 32 skipping to change at page 9, line 32
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 or the minimum IPv6 next hope MTU message as a tentative PMTU value or the IPv6 minimum link MTU if
if that is larger, and compares the tentative PMTU to the existing that is larger, and compares the tentative PMTU to the existing PMTU.
PMTU. If the tentative PMTU is less than the existing PMTU estimate, If the tentative PMTU is less than the existing PMTU estimate, the
the tentative PMTU replaces the existing PMTU as the PMTU value for tentative PMTU replaces the existing PMTU as the PMTU value for the
the path. 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 14, line 14 skipping to change at page 14, line 14
A malicious party could also cause problems if it could stop a victim A malicious party could also cause problems if it could stop a victim
from receiving legitimate Packet Too Big messages, but in this case from receiving legitimate Packet Too Big messages, but in this case
there are simpler denial-of-service attacks available. there are simpler denial-of-service attacks available.
If ICMPv6 filtering prevents reception of ICMPv6 Packet Too Big If ICMPv6 filtering prevents reception of ICMPv6 Packet Too Big
messages, the source will not learn the actual path MTU. messages, the source will not learn the actual path MTU.
Packetization Layer Path MTU Discovery [RFC4821] does not rely upon Packetization Layer Path MTU Discovery [RFC4821] does not rely upon
network support for ICMPv6 messages and is therefore considered more network support for ICMPv6 messages and is therefore considered more
robust than standard PMTUD. It is not susceptible to "black holing" robust than standard PMTUD. It is not susceptible to "black holing"
of ICMPv6 message. of ICMPv6 message. See [RFC4890] for 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.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 15, line 18 skipping to change at page 15, line 18
<http://www.rfc-editor.org/info/rfc4861>. <http://www.rfc-editor.org/info/rfc4861>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>. <http://www.rfc-editor.org/info/rfc1191>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>. <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>.
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)",
RFC 6691, DOI 10.17487/RFC6691, July 2012, RFC 6691, DOI 10.17487/RFC6691, July 2012,
<http://www.rfc-editor.org/info/rfc6691>. <http://www.rfc-editor.org/info/rfc6691>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <http://www.rfc-editor.org/info/rfc7530>. March 2015, <http://www.rfc-editor.org/info/rfc7530>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
skipping to change at page 16, line 7 skipping to change at page 16, line 10
is discussed in [I-D.ietf-6man-rfc2460bis] is discussed in [I-D.ietf-6man-rfc2460bis]
old-style messages all Packet Too Big messages report the MTU of old-style messages all Packet Too Big messages report the MTU of
the constricting link the constricting link
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 is based on RFC1981 has the following changes from
identify the Internet-Draft version where the change was made: RFC1981:
o Clarified Section 1 "Introduction" that the purpose of PMTUD is to
reduce the need for IPv6 fragmentation.
o Added text to Section 1 "Introduction" and Section 6 "Security
Considerations" about the effects on PMTUD when ICMPv6 messages
are blocked.
o Added a short summary to the Section 1 "Introduction" of
Packetization Layer Path MTU Discovery ((PLPMTUD) and a reference
to RFC4821 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 message per RFC4443.
o Remove 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
[I-D.ietf-6man-rfc2460bis].
o Added clarification in Section 5.2 "Storing PMTU information" to
discard an ICMPv6 Packet Too Big message if it contains a MTU less
than the IPv6 minimum link MTU.
o Removed text in Section 5.2 "Storing PMTU information" about the
RH0 routing header because it was deprecated by RFC5095.
o Removed text about obsolete security classification from
Section 5.2 "Storing PMTU information".
o Changed title of Section 5.4 to "Packetization Layer actions" and
changed to text in the first paragraph to 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 Editorial Changes.
B.1. Change History Since RFC1981
NOTE TO RFC EDITOR: Please remove this subsection prior to RFC
Publication
This section describes change history made in each Internet Draft
that went into producing this version. The numbers identify the
Internet-Draft version in which the change was made.
Working Group Internet Drafts Working Group Internet Drafts
06) Revised Appendix B "Changes since RFC1981" to have a summary
of changes since RFC1981 and a separate subsection with a
change history of each Internet Draft. This subsection will
be removed when the RFC is published.
06) Editorial changes based on comments received after publishing
the -05 draft.
05) Changes based on IETF last call reviews by Gorry Fairhurst, 05) Changes based on IETF last call reviews by Gorry Fairhurst,
Joe Touch, Susan Hares, Stewart Bryant, Rifaat Shekh-Yusef, Joe Touch, Susan Hares, Stewart Bryant, Rifaat Shekh-Yusef,
and Donald Eastlake. This includes includes: and Donald Eastlake. This includes includes:
o Clarify that the purpose of PMTUD is to reduce the need o Clarify that the purpose of PMTUD is to reduce the need
for IPv6 Fragmentation. for IPv6 Fragmentation.
o Added text to Introduction about effects on PMTUD when o Added text to Introduction about effects on PMTUD when
ICMPv6 messages are blocked. ICMPv6 messages are blocked.
 End of changes. 12 change blocks. 
20 lines changed or deleted 93 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/