--- 1/draft-ietf-tsvwg-datagram-plpmtud-21.txt 2020-06-10 05:13:17.425377570 -0700 +++ 2/draft-ietf-tsvwg-datagram-plpmtud-22.txt 2020-06-10 05:13:17.525380116 -0700 @@ -1,22 +1,22 @@ Internet Engineering Task Force G. Fairhurst Internet-Draft T. Jones Updates: 4821, 4960, 6951, 8085, 8261 (if University of Aberdeen approved) M. Tuexen Intended status: Standards Track I. Ruengeler -Expires: 13 November 2020 T. Voelker +Expires: 12 December 2020 T. Voelker Muenster University of Applied Sciences - 12 May 2020 + 10 June 2020 Packetization Layer Path MTU Discovery for Datagram Transports - draft-ietf-tsvwg-datagram-plpmtud-21 + draft-ietf-tsvwg-datagram-plpmtud-22 Abstract This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It describes an extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path MTU Discovery for IPv4 and IPv6. The method allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet @@ -51,21 +51,21 @@ 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 https://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 13 November 2020. + This Internet-Draft will expire on 12 December 2020. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -78,21 +78,21 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Classical Path MTU Discovery . . . . . . . . . . . . . . 4 1.2. Packetization Layer Path MTU Discovery . . . . . . . . . 6 1.3. Path MTU Discovery for Datagram Services . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 11 4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 14 4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 14 4.2. Confirmation of Probed Packet Size . . . . . . . . . . . 15 - 4.3. Black Hole Detection and Reducing the PLPMTU . . . . . . 16 + 4.3. Black Hole Detection and Reducing the PLPMTU . . . . . . 15 4.4. The Maximum Packet Size (MPS) . . . . . . . . . . . . . . 17 4.5. Disabling the Effect of PMTUD . . . . . . . . . . . . . . 18 4.6. Response to PTB Messages . . . . . . . . . . . . . . . . 18 4.6.1. Validation of PTB Messages . . . . . . . . . . . . . 18 4.6.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 19 5. Datagram Packetization Layer PMTUD . . . . . . . . . . . . . 20 5.1. DPLPMTUD Components . . . . . . . . . . . . . . . . . . . 21 5.1.1. Timers . . . . . . . . . . . . . . . . . . . . . . . 21 5.1.2. Constants . . . . . . . . . . . . . . . . . . . . . . 22 @@ -122,32 +122,28 @@ 6.2.2.1. Initial Connectivity . . . . . . . . . . . . . . 35 6.2.2.2. Sending SCTP/UDP Probe Packets . . . . . . . . . 35 6.2.2.3. Validating the Path with SCTP/UDP . . . . . . . . 35 6.2.2.4. Handling of PTB Messages by SCTP/UDP . . . . . . 35 6.2.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 35 6.2.3.1. Initial Connectivity . . . . . . . . . . . . . . 35 6.2.3.2. Sending SCTP/DTLS Probe Packets . . . . . . . . . 36 6.2.3.3. Validating the Path with SCTP/DTLS . . . . . . . 36 6.2.3.4. Handling of PTB Messages by SCTP/DTLS . . . . . . 36 6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 36 - 6.3.1. Initial Connectivity . . . . . . . . . . . . . . . . 36 - 6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 37 - 6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 37 - 6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 37 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 39 - 10.2. Informative References . . . . . . . . . . . . . . . . . 41 - Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 42 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 + 10.2. Informative References . . . . . . . . . . . . . . . . . 39 + Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 41 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 1. Introduction The IETF has specified datagram transport using UDP, SCTP, and DCCP, as well as protocols layered on top of these transports (e.g., SCTP/ UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP network layer. This document describes a robust method for Path MTU Discovery (PMTUD) that can be used with these transport protocols (or the applications that use their transport service) to discover an appropriate size of packet to use across an Internet path. @@ -429,21 +425,21 @@ MAX_PLPMTU: The MAX_PLPMTU is the largest size of PLPMTU that DPLPMTUD will attempt to use (see the constants defined in Section 5.1.2). MIN_PLPMTU: The MIN_PLPMTU is the smallest size of PLPMTU that DPLPMTUD will attempt to use (see the constants defined in Section 5.1.2). MPS: The Maximum Packet Size (MPS) is the largest size of application data block that can be sent across a network path by a - PL using a single Datagram. + PL using a single Datagram (see Section 4.4). MSL: Maximum Segment Lifetime (MSL) The maximum delay a packet is expected to experience across a path, taken as 2 minutes [BCP145]. Packet: A Packet is the IP header(s) and any extension headers/ options plus the IP payload. Packetization Layer (PL): The PL is a layer of the network stack that places data into packets and performs transport protocol functions. Examples of a PL include: TCP, SCTP, SCTP over UDP, @@ -1033,25 +1029,28 @@ The following constants are defined: MAX_PROBES: The MAX_PROBES is the maximum value of the PROBE_COUNT counter (see Section 5.1.3). MAX_PROBES represents the limit for the number of consecutive probe attempts of any size. Search algorithms benefit from a MAX_PROBES value greater than 1 because this can provide robustness to isolated packet loss. The default value of MAX_PROBES is 3. MIN_PLPMTU: The MIN_PLPMTU is the smallest size of PLPMTU that - DPLPMTUD will attempt to use. For IPv6, this size is greater than - or equal to the size at the PL that results in an 1280 byte IPv6 - packet, as specified in [RFC8200]. For IPv4, this size is greater - than or equal to the size at the PL that results in an 68 byte - IPv4 packet. Note: An IPv4 router is required to be able to + DPLPMTUD will attempt to use. An endpoint could need to be + configure the MIN_PLPMTU to provide space for extension headers + and other encapsulations at layers below the PL. This value can + be interface and path dependent. For IPv6, this size is greater + than or equal to the size at the PL that results in an 1280 byte + IPv6 packet, as specified in [RFC8200]. For IPv4, this size is + greater than or equal to the size at the PL that results in an 68 + byte IPv4 packet. Note: An IPv4 router is required to be able to forward a datagram of 68 bytes without further fragmentation. This is the combined size of an IPv4 header and the minimum fragment size of 8 bytes. In addition, receivers are required to be able to reassemble fragmented datagrams at least up to 576 bytes, as stated in section 3.3.3 of [RFC1122]. MAX_PLPMTU: The MAX_PLPMTU is the largest size of PLPMTU. This has to be less than or equal to the maximum size of the PL packet that can be sent on the outgoing interface (constrained by the local interface MTU). When known, this also ought to be less than the @@ -1645,80 +1644,27 @@ the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. 6.2.3.4. Handling of PTB Messages by SCTP/DTLS [RFC4960] does not specify a way to validate SCTP/DTLS ICMP message payload and neither does this document. This can prevent processing of PTB messages at the PL. 6.3. DPLPMTUD for QUIC - QUIC [I-D.ietf-quic-transport] is a UDP-based transport that provides - reception feedback. The UDP payload includes the QUIC packet header, - protected payload, and any authentication fields. QUIC depends on a - PMTU of at least 1280 bytes. - - Section 14 of [I-D.ietf-quic-transport] describes the path - considerations when sending QUIC packets. It recommends the use of - PADDING frames to build the probe packet. Pure probe-only packets - are constructed with PADDING frames and PING frames to create a - padding only packet that will elicit an acknowledgment. Such padding - only packets enable probing without affecting the transfer of other - QUIC frames. - - The recommendation for QUIC endpoints implementing DPLPMTUD is that a - MPS is maintained for each combination of local and remote IP - addresses [I-D.ietf-quic-transport]. If a QUIC endpoint determines - that the PMTU between any pair of local and remote IP addresses has - fallen below the size required for an acceptable MPS, it immediately - ceases to send QUIC packets on the affected path. This could result - in termination of the connection if an alternative path cannot be - found [I-D.ietf-quic-transport]. - -6.3.1. Initial Connectivity - - The base protocol is specified in [I-D.ietf-quic-transport]. This - provides an acknowledged PL. A sender can therefore enter the BASE - state as soon as connectivity has been confirmed. - - QUIC provides an acknowledged PL, a sender can therefore enter the - BASE state as soon as the connection handshake has been completed and - the endpoint has an 1-RTT key established. - -6.3.2. Sending QUIC Probe Packets - - Probe packets consist of a QUIC Header and a payload containing a - PING Frame and multiple PADDING Frames. A PADDING Frame is - represented by a single octet (0x00). Several PADDING Frames are - used together to control the length of the probe packet. The PING - Frame is used to trigger generation of an acknowledgement. - - The current specification of QUIC sets the following: - - * BASE_PLPMTU: A QUIC sender pads initial packets to confirm the - path can support packets of the required size, which sets the - BASE_PLPMTU and MIN_PLPMTU. - - * MIN_PLPMTU: A QUIC sender that determines the MIN_PLPMTU has - fallen MUST immediately stop sending on the affected path. - -6.3.3. Validating the Path with QUIC - - QUIC provides an acknowledged PL, therefore a sender does not - implement the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. - -6.3.4. Handling of PTB Messages by QUIC - - QUIC validates ICMP PTB messages. In addition to UDP Port - validation, QUIC can validate an ICMP message by using other PL - information (e.g., validation of connection identifiers (CIDs) in the - quoted packet of any received ICMP message). + QUIC [I-D.ietf-quic-transport] is a UDP-based PL that provides + reception feedback. The UDP payload includes a QUIC packet header, a + protected payload, and any authentication fields. It supports + padding and packet coalescence that can be used to construct probe + packets. From the perspective of DPLPMTUD, QUIC can function as an + acknowledged PL. [I-D.ietf-quic-transport] describes the method for + using DPLPMTUD with QUIC packets. 7. Acknowledgments 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). Thanks to all that have commented or contributed, the TSVWG and QUIC working groups, and Mathew Calder and Julius Flohr for providing early implementations. @@ -1806,27 +1752,20 @@ 10. References 10.1. Normative References [BCP145] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, March 2017. - [I-D.ietf-quic-transport] - Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed - and Secure Transport", Work in Progress, Internet-Draft, - draft-ietf-quic-transport-27, 21 February 2020, - . - [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, @@ -1885,20 +1824,27 @@ fragile-17, 30 September 2019, . [I-D.ietf-intarea-tunnels] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", Work in Progress, Internet-Draft, draft- ietf-intarea-tunnels-10, 12 September 2019, . + [I-D.ietf-quic-transport] + Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed + and Secure Transport", Work in Progress, Internet-Draft, + draft-ietf-quic-transport-27, 21 February 2020, + . + [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", @@ -2154,20 +2100,30 @@ * Address nits and comments from IESG * Refer to BCP 145 rather than RFC 8085 in most places. * Update probing method text for SCTP and QUIC. Working group draft -21: * Update QUIC text for skipping into BASE state. + Working group draft -22: + + * Add a section reference to MPS + + * Clarify MIN_PLPMTU text + + * Remove most QUIC text + + * Make QUIC reference informative. + Authors' Addresses Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom