Internet Engineering Task Force G. Fairhurst
Internet-Draft T. Jones
Intended status: Standards Track University of Aberdeen
Expires: January 4, 2018 M. Tuexen
I. Ruengeler
Muenster University of Applied Sciences
July 03, 2017
Packetization Layer Path MTU Discovery for Datagram Transports
draft-fairhurst-tsvwg-datagram-plpmtud-00.txt
Abstract
This document describes a robust method for Path MTU Discovery
(PMTUD) for datagram packetization layers. It allows these layers to
probe an Internet path with progressively larger packets to determine
a maximum packet size This method is described as an extension to RFC
1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP
versions 4 and 6. The document provides functionally for datagram
transports that is equivalent to the packetization layer PMTUD
specification for TCP, specified in RFC4821.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018.
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
Fairhurst, et al. Expires January 4, 2018 [Page 1]
Internet-Draft Datagram PLPMTUD July 2017
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. PMTU Probing Methods . . . . . . . . . . . . . . . . . . 7
4. Specification of PMTUD for Packetization Layers . . . . . . . 7
5. Specification or Protocol Specific Methods . . . . . . . . . 7
5.1. UDP and UDP-Lite . . . . . . . . . . . . . . . . . . . . 8
5.1.1. UDP Options . . . . . . . . . . . . . . . . . . . . . 8
5.2. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2.1. SCTP/IP4 and SCTP/IPv6 . . . . . . . . . . . . . . . 8
5.2.1.1. Probing . . . . . . . . . . . . . . . . . . . . . 8
5.2.1.2. PTB Message Handling . . . . . . . . . . . . . . 9
5.2.2. SCTP/UDP . . . . . . . . . . . . . . . . . . . . . . 9
5.2.2.1. Probing . . . . . . . . . . . . . . . . . . . . . 9
5.2.2.2. PTB Message Handling . . . . . . . . . . . . . . 9
5.2.3. SCTP/DTLS . . . . . . . . . . . . . . . . . . . . . . 9
5.2.3.1. Probing . . . . . . . . . . . . . . . . . . . . . 9
5.2.3.2. PTB Message Handling . . . . . . . . . . . . . . 9
5.3. DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. DCCP/UDP . . . . . . . . . . . . . . . . . . . . . . 10
5.4. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The IETF has specified datagram transport using UDP, SCTP, SCTP/UDP,
DCCP, and DCCP/UDP as well as upper layer protocols layered on top of
these transports.
Classical Path MTU Discovery (PMTUD) can be used with any transport
that is able to process ICMP Packet Too Big (PTB) messages (e.g.,
[RFC1191][I-D.ietf-6man-rfc1981bis]). It adjusts the Effective Path
Fairhurst, et al. Expires January 4, 2018 [Page 2]
Internet-Draft Datagram PLPMTUD July 2017
MTU (PMTU), based on reception of ICMP PTB messages to decrease the
PMTU when this is larger than the value supported along a path, and a
method that increases the packet size in attempt to discover an
increase in the supported PMTU. However, ICMP messages are being
increasingly filtered by middleboxes (including Firewalls) [RFC4890].
Classical PMTUD is therefore subject to protocol failures (e.g.,
traffic using a packet size larger than the actual supported PMTU is
blackholed when ICMP PTB messages are not delivered for some reason
[RFC2923]).
Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not
rely upon network or transport support for ICMP messages and is
therefore considered more robust than Classical PMTUD. This has
become the preferred approach for TCP traffic. The general strategy
is for the Packetization Layer to find an appropriate PMTU by sending
probe packets along the path with a progressively larger packet size.
If a probe packet is successfully delivered (as determined by the
PL), then the effective Path MTU is raised to the probe size.
PLPMTUD introduces flexibility in the implementation of classical
PMTUD. It can be configured to only perform ICMP black hole recovery
to increase the robustness of classical PMTUD, or at the other
extreme, all ICMP processing can be disabled and PLPMTUD can
completely replace classical Path MTU Discovery. Using PLPMTUD,
classical Path MTU Discovery can also be modified to include
additional consistency checks without increasing the risk of
connection hangs due to spurious failures of the additional checks.
The UDP-Guidelines [RFC8085] state "an application SHOULD either use
the path MTU information provided by the IP layer or implement Path
MTU Discovery (PMTUD)", but does not provide a mechanism for
discovering the largest size of unfragmented datagram than can be
used on a path. This specification describes how these datagram
transports perform PLPMTUD. This mechanism has not currently been
specified for UDP, while Section 10.2 of [RFC4821] specifies a
recommended PLPMTUD probing method for SCTP.
Section Section 4 of this document presents a set of algorithms for
datagram protocols to discover the maximum transmission unit possible
on a path at the packetization layer. The methods described rely on
features of transport protocols and apply to transport protocols over
IPv4 and IPv6. They do not require cooperation from the lower layers
(except that they are consistent about which packet sizes are
acceptable) or from peers.
Fairhurst, et al. Expires January 4, 2018 [Page 3]
Internet-Draft Datagram PLPMTUD July 2017
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Other terminology is directly copied from [RFC4821], the EMTU
definitions are from [RFC1122].
Address: An IP Layer identifier for an interface or a set of
interfaces.
Classical Path MTU Discovery: The process described in [RFC1191] and
[I-D.ietf-6man-rfc1981bis], in which nodes rely on ICMP PTB
messages to learn the MTU of a path.
Datagram: A transport-layer protocol data unit, transmitted in the
payload of an IP packet.
Effective PMTU: The current estimated value for PMTU used by a
Packetization Layer.
EMTU_S: The Effective MTU for sending (EMTU_S) is designated in
[RFC1122] as " the maximum IP datagram size that may be sent, for
a particular combination of IP source and destination
addresses..."
EMTU_R: The Effective MTU for receiving (EMTU_R) is designated in
[RFC1122] as "the largest datagram size that can be reassembled by
EMTU_R ("Effective MTU to receive")"
Interface: A node's attachment to a link.
Link: A communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately below
IP. Examples are Ethernet LANs and Internet (or higher) layer and
tunnels.
Link MTU: Maximum Transmission Unit, the size in bytes of the
largest IP packet, including the IP header and payload, that can
be transmitted on a link or path. Note that this could more
properly be called the IP MTU, to be consistent with how other
standards organizations use the acronym MTU. This includes the IP
header, but excludes link layer headers and other framing that is
not part of IP or the IP payload. Be aware that other standards
organizations generally define link MTU to include the link layer
headers.
Fairhurst, et al. Expires January 4, 2018 [Page 4]
Internet-Draft Datagram PLPMTUD July 2017
Packet: An IP header plus the IP payload.
Packetization Layer: The layer of the network stack that places data
into packets and performs transport protocol functions.
Path: The set of links traversed by a packet between a source node
and a destination node.
Path MTU, or PMTU: The minimum link MTU of all the links in a path
between a source node and a destination node.
PLPMTUD: Packetization Layer Path MTU Discovery, the method
described in this document, which is an extension to classical
PMTU Discovery.
3. Requirements
All of the requirements in [RFC4821] apply. There are also a number
of design constraints imposed by datagram transports. TCP PLPMTUD
has been defined using standard TCP protocol mechanism. Unlike TCP,
some datagram transports require additional or optional mechanisms to
implement PLPMTUD. This can place constraints on deployment when
only one end supports the new method.
There are eight functions that any Datagram PLPMTUD mechanisms needs
to perform:
1. PMTU parameters: A method MUST utilize information about the
maximum size of packet that can be transmitted by the sender on
the local link (Link MTU) and MAY utilize similar information
about the receiver link, when this is supplied (note this may be
less than EMTU_R). Some applications also have a maximum
transport protocol data unit (PDU) size, in which case there may
be no benefit from probing for a size larger than this (unless a
transport offers benefit from multiplexing multiple applications
PDUs into the same datagram.)
2. Effective PMTU: A datagram applications MUST be able to choose
the size of datagrams sent to the network, based on the effective
MTU. This value is managed by the PMTUD method, and sets the
maximum size of datagram that an application can send. The
effective PMTU (specified in Section 1 of [RFC1191]) is
equivalent to the EMTU_S (specified in [RFC1122]).
3. Processing ICMP PTB messages: A method MAY optionally utilize
ICMP PTB information from the network layer to help identify when
a path does not support a message size (i.e. reduce the effective
PMTU). The validity of PTB messages SHOULD to be verified before
Fairhurst, et al. Expires January 4, 2018 [Page 5]
Internet-Draft Datagram PLPMTUD July 2017
they are used to update the path MTU discovery information
[I-D.ietf-6man-rfc1981bis].
4. Path validation: An endpoint needs to confirm the current path
support the current effective datagram size, without relying
solely on ICMP PTB messages. In this respect, the mechanism MUST
be robust to path changes that could have occurred since the path
characteristics were last confirmed. A method MUST also be
robust to the possibility that a flow encounters reordering, or
has the traffic divided over more than one network path.
5. When to probe: An endpoint method SHOULD determine whether the
path capacity has increased since it last measured the path
characteristics. The endpoint needs a method to determine when a
probe datagram is transmitted, and it MUST cache the values
between probes. This method needs to consider the disruption
that may be incurred by an unsuccessful probe - both upon the
flow that incurs a probe loss, and other flows that experience
the effect of additional probe traffic.
6. Reception feedback: An endpoint MUST provide a feedback method to
indicate when a probe message has been received by the remote
endpoint. If the data in the probe message needs to be sent
reliably, the transport needs to arrange retransmission/repair of
any resulting loss. The method also needs to be robust in the
case where probe messages are lost due to other reasons than a
PMTU exceeded (e.g., link transmission error, congestion). The
isolated loss of a probe packet (with or without an ICMP Packet
Too Big message) is treated as an indication of an MTU limit, and
not as a congestion indicator. In this case alone, the
Packetization Protocol is permitted to retransmit any missing
data without adjusting the congestion window.
7. Shared state: The specification of PLPMTUD [RFC4821] states: "If
PLPMTUD updates the MTU for a particular path, all Packetization
Layer sessions that share the path representation (as described
in Section 5.2 of RFC821) SHOULD be notified to make use of the
new MTU and make the required congestion control adjustments".
Such methods need to robust to the wide variety of underlying
network forwarding behaviours. Considerations about caching have
been noted [I-D.ietf-6man-rfc1981bis].
8. Not interfere with congestion control: If the transport protocol
implements a congestion control, the loss of a probe packet
SHOULD NOT affect the congestion control if the probe packets are
not contain user data.
Fairhurst, et al. Expires January 4, 2018 [Page 6]
Internet-Draft Datagram PLPMTUD July 2017
3.1. PMTU Probing Methods
Many datagram protocols provide mechanisms to distinguish in-band
data from padding. In contrast, TCP to generate probes by
appropriately segmenting data. There are three ways of creating
probes, using application data, using application data and padding
and padding only:
o A probe datagram can contain only padding (these probes consume
capacity, but do not require retransmission of user data) and
control data.
o A probe datagram can contain user data that is combined with
control data and padding to inflate the length of the datagram to
the size required for the probe. A loss of this probe could
require retransmission/repair of the data if required by the
application/transport.
o A probe datagram can contain data supplied by an application that
matches the size required for the probe. This requires a method
to request the application to issue a packet of the desired probe
size. A loss of this probe could require retransmission/repair of
the data if required by the application/transport.
Three approaches are possible for providing datagram reliability:
1. A transport/application does not require a probe datagram to be
retransmitted in the event of the loss of a probe.
2. A transport/application requires retransmission of the data part
of a probe in the event of a loss.
3. A transport/application is allowed to replicate the data sent in
a probe in a packet (or packets) less than the size current
effective PMTU to reduce the need for retransmission.
4. Specification of PMTUD for Packetization Layers
<< Fill in a generic algorithm based on sending probe packets,
receiving success indications and possibly handling PTB messages.
These three operations are protocol specific and are described in
Section 5 for various protocols. >>
5. Specification or Protocol Specific Methods
<< In future revisions of this document, this section may be divided
into PMTUD and PLPMTUD methods >>
Fairhurst, et al. Expires January 4, 2018 [Page 7]
Internet-Draft Datagram PLPMTUD July 2017
5.1. UDP and UDP-Lite
UDP and UDP-LIte [RFC3828] do not provide a method that allows
padding to be added to a datagram.
<< This section will be completed in a future revision of this ID >>
5.1.1. UDP Options
UDP places additional design requirements on an application that
wishes to use PLPMTUD. UDP Options permits padding to be added to
UDP datagrams [I-D.ietf-tsvwg-udp-options], and can be used to
provide reception feedback. Therefore, UDP-Options can be used to
assist UDP applications by supplying the additional functionality and
using this to provide a Datagram PMTUD service similar to that
offered by other transports.
<< This section will be completed in a future revision of this ID >>
5.2. SCTP
Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing
method for SCTP. It recommends use of the PAD chunk, defined in
[RFC4820] to be attached to a minimum length HEARTBEAT chunk to build
a probe packet. This allows to perform probing without affecting the
transfer of user messages and without interfering with congestion
control. Therefore it is preferred to the use of DATA chunks (with
padding as required) to serve as path probes.
<< We might define a parameter contained in the INIT and INIT ACK
chunk to indicated the MTU to the peer. However, multihoming makes
this a bit complex, so it might not be worth doing. >>
5.2.1. SCTP/IP4 and SCTP/IPv6
The base protocol is specified in [RFC4960].
5.2.1.1. Probing
Probe packets consist of an SCTP common header followed by a
HEARTBEAT chunk and a PAD chunk. The PAD chunk is used to control
the length of the probe packet. The HEARTBEAT chunk is used to
trigger the sending of a HEARTBEAT ACK chunk. The reception of the
HEARTBEAT ACK chunk signals the successful probing.
Fairhurst, et al. Expires January 4, 2018 [Page 8]
Internet-Draft Datagram PLPMTUD July 2017
5.2.1.2. PTB Message Handling
Normal ICMP verification MUST be performed as specified in Appendix C
of [RFC4960]. This requires that the first 8 bytes of the SCTP
common header are contained in the ICMP packet, which is normally
fulfilled by ICMPv4 and ICMPv6.
5.2.2. SCTP/UDP
The UDP encapsulation of SCTP is specified in [RFC6951].
5.2.2.1. Probing
The probing can be performed as specified in Section 5.2.1.1.
5.2.2.2. PTB Message Handling
Normal ICMP verification has to be performed as specified in
[RFC4960]. However, this might not be possible for ICMPv4, since it
is not guaranteed that the ICMP packet contains the first 8 bytes of
the SCTP common header. ICMPv6 packets should contain enough
information to perform the required verification.
5.2.3. SCTP/DTLS
The DTLS encapsulation of SCTP is specified in
[I-D.ietf-tsvwg-sctp-dtls-encaps]. It is used for data channels in
WebRTC implementations.
5.2.3.1. Probing
The probing can be done as specified in Section 5.2.1.1.
5.2.3.2. PTB Message Handling
Normal ICMP verification can not be performed as specified in
[RFC4960], since even if the ICMP contains enough information, the
reflected SCTP common header would be encrypted. Therefore it is not
possible to process ICMP PTB messages.
5.3. DCCP
DCCP [RFC4340] implementations are required to support classical
PMTUD and states that a DCCP sender "MUST maintain the maximum packet
size (MPS) allowed for each active DCCP session" and also defines
"current congestion control mechanism (CCMPS), the maximum packet
size supported by the path's links". It recommends use of PMTUD, and
suggests use of DCCP-Sync packets as path probes, because they do not
Fairhurst, et al. Expires January 4, 2018 [Page 9]
Internet-Draft Datagram PLPMTUD July 2017
risk application data loss. It does not currently specify the use of
PLPMTUD methods that could work independently of the ability to
utilise ICMP PTB messages.
<< This section will be completed in a future revision of this ID >>
5.3.1. DCCP/UDP
DCCP/UDP is a UDP-based transport that permits padding to be added to
datagrams, and can provide reception feedback.
<< This section will be completed in a future revision of this ID >>
5.4. QUIC
QUIC is a UDP-based transport that provides reception feedback
[draft-ietf-quic-transport].
<< This section will be completed in a future revision of this ID >>
6. Acknowledgements
This work was partially funded by the European Union's Horizon 2020
research and innovation programme under grant agreement No. 644334
(NEAT). The views expressed are solely those of the author(s).
7. IANA Considerations
This memo includes no request to IANA.
If there are no requirements for IANA, the section will be removed
during conversion into an RFC by the RFC Editor.
8. Security Considerations
The security considerations for the use of UDP and SCTP are provided
in the references RFCs. Security guidance for applications using UDP
is provided in the UDP-Guidelines [RFC8085].
ICMP PTB messages could potentially be used to cause a node to
inappropriately reduce the PMTU. A node supporting PLPMTUD SHOULD
appropriately validate the payload of ICMP PTB messages to ensure
these are received in response to transmitted traffic (i.e., a
reported error condition that corresponds to a datagram actually sent
by the path layer.
Fairhurst, et al. Expires January 4, 2018 [Page 10]
Internet-Draft Datagram PLPMTUD July 2017
9. References
9.1. Normative References
[I-D.ietf-6man-rfc1981bis]
<>, J., <>, S., <>, J., and R. Hinden, "Path MTU Discovery
for IP version 6", draft-ietf-6man-rfc1981bis-08 (work in
progress), May 2017.
[I-D.ietf-tsvwg-sctp-dtls-encaps]
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
dtls-encaps-09 (work in progress), January 2015.
[I-D.ietf-tsvwg-udp-options]
Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
udp-options-01 (work in progress), June 2017.
[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>.
[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>.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
and G. Fairhurst, Ed., "The Lightweight User Datagram
Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July
2004, <http://www.rfc-editor.org/info/rfc3828>.
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
Parameter for the Stream Control Transmission Protocol
(SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,
<http://www.rfc-editor.org/info/rfc4820>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>.
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
Control Transmission Protocol (SCTP) Packets for End-Host
to End-Host Communication", RFC 6951,
DOI 10.17487/RFC6951, May 2013,
<http://www.rfc-editor.org/info/rfc6951>.
Fairhurst, et al. Expires January 4, 2018 [Page 11]
Internet-Draft Datagram PLPMTUD July 2017
[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>.
9.2. Informative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>.
[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>.
Appendix A. Revision Notes
Note to RFC-Editor: please remove this entire section prior to
publication.
Individual draft -00:
o This is the first version. Comments and corrections are welcome
directly to the authors or via the IETF TSVWG working group
mailing list.
Authors' Addresses
Fairhurst, et al. Expires January 4, 2018 [Page 12]
Internet-Draft Datagram PLPMTUD July 2017
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Fraser Noble Building Aberdeen AB24 3UE
UK
Email: gorry@erg.abdn.ac.uk
Tom Jones
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
UK
Email: tom@erg.abdn.ac.uk
Michael Tuexen
Muenster University of Applied Sciences
Stegerwaldstrasse 39
Steinfurt 48565
DE
Email: tuexen@fh-muenster.de
Irene Ruengeler
Muenster University of Applied Sciences
Stegerwaldstrasse 39
Steinfurt 48565
DE
Email: i.ruengeler@fh-muenster.de
Fairhurst, et al. Expires January 4, 2018 [Page 13]