--- 1/draft-ietf-tsvwg-datagram-plpmtud-09.txt 2019-11-18 03:13:41.172649950 -0800 +++ 2/draft-ietf-tsvwg-datagram-plpmtud-10.txt 2019-11-18 03:13:41.264652303 -0800 @@ -1,22 +1,22 @@ Internet Engineering Task Force G. Fairhurst Internet-Draft T. Jones Updates4821 (if approved) University of Aberdeen Intended status: Standards Track M. Tuexen -Expires: 7 May 2020 I. Ruengeler +Expires: 21 May 2020 I. Ruengeler T. Voelker Muenster University of Applied Sciences - 4 November 2019 + 18 November 2019 Packetization Layer Path MTU Discovery for Datagram Transports - draft-ietf-tsvwg-datagram-plpmtud-09 + draft-ietf-tsvwg-datagram-plpmtud-10 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 network @@ -41,123 +41,92 @@ 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 7 May 2020. + This Internet-Draft will expire on 21 May 2020. Copyright Notice Copyright (c) 2019 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 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 (name-introduction) . . . . . . . . . . . . . . 4 - 1.1. Classical Path MTU Discovery - (name-classical-path-mtu-discover) . . . . . . . . . . . 4 - 1.2. Packetization Layer Path MTU Discovery - (name-packetization-layer-path-mt) . . . . . . . . . . . 6 - 1.3. Path MTU Discovery for Datagram Services - (name-path-mtu-discovery-for-data) . . . . . . . . . . . 7 - 2. Terminology (name-terminology) . . . . . . . . . . . . . . . 8 - 3. Features Required to Provide Datagram PLPMTUD - (name-features-required-to-provid) . . . . . . . . . . . . . . 10 - 4. DPLPMTUD Mechanisms (name-dplpmtud-mechanisms) . . . . . . . 12 - 4.1. PLPMTU Probe Packets (name-plpmtu-probe-packets) . . . . 13 - 4.2. Confirmation of Probed Packet Size - (name-confirmation-of-probed-pack) . . . . . . . . . . . 14 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Classical Path MTU Discovery . . . . . . . . . . . . . . 3 + 1.2. Packetization Layer Path MTU Discovery . . . . . . . . . 6 + 1.3. Path MTU Discovery for Datagram Services . . . . . . . . 6 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 9 + 4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 12 + 4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 12 + 4.2. Confirmation of Probed Packet Size . . . . . . . . . . . 13 4.3. Detection of Unsupported PLPMTU Size, aka Black Hole - Detection (name-detection-of-unsupported-pl) . . . . . . 14 - 4.4. Disabling the Effect of PMTUD - (name-disabling-the-effect-of-pmt) . . . . . . . . . . . 15 - 4.5. Response to PTB Messages - (name-response-to-ptb-messages) . . . . . . . . . . . . . 15 - 4.5.1. Validation of PTB Messages - (name-validation-of-ptb-messages) . . . . . . . . . . 16 - 4.5.2. Use of PTB Messages - (name-use-of-ptb-messages) . . . . . . . . . . . . . 17 - 5. Datagram Packetization Layer PMTUD - (name-datagram-packetization-laye) . . . . . . . . . . . . . . 18 - 5.1. DPLPMTUD Components (name-dplpmtud-components) . . . . . 18 - 5.1.1. Timers (name-timers) . . . . . . . . . . . . . . . . 19 - 5.1.2. Constants (name-constants) . . . . . . . . . . . . . 20 - 5.1.3. Variables (name-variables) . . . . . . . . . . . . . 20 - 5.1.4. Overview of DPLPMTUD Phases - (name-overview-of-dplpmtud-phases) . . . . . . . . . 21 - 5.2. State Machine (name-state-machine) . . . . . . . . . . . 23 - 5.3. Search to Increase the PLPMTU - (name-search-to-increase-the-plpm) . . . . . . . . . . . 26 - 5.3.1. Probing for a larger PLPMTU - (name-probing-for-a-larger-plpmtu) . . . . . . . . . 26 - 5.3.2. Selection of Probe Sizes - (name-selection-of-probe-sizes) . . . . . . . . . . . 27 - 5.3.3. Resilience to Inconsistent Path Information - (name-resilience-to-inconsistent-) . . . . . . . . . 28 - 5.4. Robustness to Inconsistent Paths - (name-robustness-to-inconsistent-) . . . . . . . . . . . 28 - 6. Specification of Protocol-Specific Methods - (name-specification-of-protocol-s) . . . . . . . . . . . . . . 28 - 6.1. Application support for DPLPMTUD with UDP or UDP-Lite - (name-application-support-for-dpl) . . . . . . . . . . . 28 - 6.1.1. Application Request - (name-application-request) . . . . . . . . . . . . . 29 - 6.1.2. Application Response - (name-application-response) . . . . . . . . . . . . . 29 - 6.1.3. Sending Application Probe Packets - (name-sending-application-probe-p) . . . . . . . . . 29 - 6.1.4. Initial Connectivity - (name-initial-connectivity) . . . . . . . . . . . . . 29 - 6.1.5. Validating the Path - (name-validating-the-path) . . . . . . . . . . . . . 30 - 6.1.6. Handling of PTB Messages - (name-handling-of-ptb-messages) . . . . . . . . . . . 30 - 6.2. DPLPMTUD for SCTP (name-dplpmtud-for-sctp) . . . . . . . 30 - 6.2.1. SCTP/IPv4 and SCTP/IPv6 - (name-sctp-ipv4-and-sctp-ipv6) . . . . . . . . . . . 30 - 6.2.2. DPLPMTUD for SCTP/UDP - (name-dplpmtud-for-sctp-udp) . . . . . . . . . . . . 31 - 6.2.3. DPLPMTUD for SCTP/DTLS - (name-dplpmtud-for-sctp-dtls) . . . . . . . . . . . . 32 - 6.3. DPLPMTUD for QUIC (name-dplpmtud-for-quic) . . . . . . . 32 - 6.3.1. Initial Connectivity - (name-initial-connectivity-5) . . . . . . . . . . . . 33 - 6.3.2. Sending QUIC Probe Packets - (name-sending-quic-probe-packets) . . . . . . . . . . 33 - 6.3.3. Validating the Path with QUIC - (name-validating-the-path-with-qu) . . . . . . . . . 33 - 6.3.4. Handling of PTB Messages by QUIC - (name-handling-of-ptb-messages-by-q) . . . . . . . . 34 + Detection . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.4. Disabling the Effect of PMTUD . . . . . . . . . . . . . . 15 + 4.5. Response to PTB Messages . . . . . . . . . . . . . . . . 15 + 4.5.1. Validation of PTB Messages . . . . . . . . . . . . . 15 + 4.5.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 16 + 5. Datagram Packetization Layer PMTUD . . . . . . . . . . . . . 17 + 5.1. DPLPMTUD Components . . . . . . . . . . . . . . . . . . . 18 + 5.1.1. Timers . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.1.2. Constants . . . . . . . . . . . . . . . . . . . . . . 19 + 5.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 20 + 5.1.4. Overview of DPLPMTUD Phases . . . . . . . . . . . . . 21 + 5.2. State Machine . . . . . . . . . . . . . . . . . . . . . . 23 + 5.3. Search to Increase the PLPMTU . . . . . . . . . . . . . . 26 + 5.3.1. Probing for a larger PLPMTU . . . . . . . . . . . . . 26 + 5.3.2. Selection of Probe Sizes . . . . . . . . . . . . . . 27 + 5.3.3. Resilience to Inconsistent Path Information . . . . . 27 + 5.4. Robustness to Inconsistent Paths . . . . . . . . . . . . 28 - 7. Acknowledgements (name-acknowledgements) . . . . . . . . . . 34 - 8. IANA Considerations (name-iana-considerations) . . . . . . . 34 - 9. Security Considerations (name-security-considerations) . . . 34 - 10. References (name-references) . . . . . . . . . . . . . . . . 35 - 10.1. Normative References (name-normative-references) . . . . 35 - 10.2. Informative References - (name-informative-references) . . . . . . . . . . . . . 36 - A. Revision Notes (name-revision-notes) . . . . . . . . . . . . 37 - B Authors' Addresses (name-authors-addresses) . . . . . . . . . 41 + 6. Specification of Protocol-Specific Methods . . . . . . . . . 28 + 6.1. Application support for DPLPMTUD with UDP or + UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . 28 + 6.1.1. Application Request . . . . . . . . . . . . . . . . . 29 + 6.1.2. Application Response . . . . . . . . . . . . . . . . 29 + 6.1.3. Sending Application Probe Packets . . . . . . . . . . 29 + 6.1.4. Initial Connectivity . . . . . . . . . . . . . . . . 29 + 6.1.5. Validating the Path . . . . . . . . . . . . . . . . . 29 + 6.1.6. Handling of PTB Messages . . . . . . . . . . . . . . 30 + 6.2. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 30 + 6.2.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 30 + 6.2.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 31 + 6.2.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 32 + 6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 32 + 6.3.1. Initial Connectivity . . . . . . . . . . . . . . . . 33 + 6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 33 + 6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 33 + 6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 33 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 + 10.2. Informative References . . . . . . . . . . . . . . . . . 36 + Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 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 may 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. @@ -272,21 +241,21 @@ The term Packetization Layer (PL) has been introduced to describe the layer that is responsible for placing data blocks into the payload of IP packets and selecting an appropriate MPS. This function is often performed by a transport protocol, but can also be performed by other encapsulation methods working above the transport layer. In contrast to PMTUD, Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not rely upon reception and validation of PTB messages. It is therefore more robust than Classical PMTUD. This has become the recommended approach for implementing PMTU - discovery with TCP. + discovery. It uses a general strategy where the PL sends probe packets to search for the largest size of unfragmented datagram that can be sent over a network path. Probe packets are sent with a progressively larger packet size. If a probe packet is successfully delivered (as determined by the PL), then the PLPMTU is raised to the size of the successful probe. If no response is received to a probe packet, the method reduces the probe size. The result of probing with the PLPMTU is used to set the application MPS. @@ -500,51 +469,49 @@ validation confirms that the PTB message was sent in response to a packet originating by the sender, and needs to be performed before the PLPMTU discovery method reacts to the PTB message. A PTB message MUST NOT be used to increase the PLPMTU [RFC8201]. 5. Reception feedback: The destination PL endpoint is REQUIRED to provide a feedback method that indicates to the DPLPMTUD sender when a probe packet has been received by the destination PL endpoint. The mechanism needs to be robust to the possibility that packets could be significantly delayed along a network path. + The local PL endpoint at the sending node is REQUIRED to pass this feedback to the sender DPLPMTUD method. 6. Probe loss recovery: It is RECOMMENDED to use probe packets that - do not carry any user data. Most datagram transports permit - this. If a probe packet contains user data requiring - retransmission in case of loss, the PL (or layers above) are - REQUIRED to arrange any retransmission/repair of any resulting - loss. DPLPMTUD is REQUIRED to be robust in the case where probe - packets are lost due to other reasons (including link - transmission error, congestion). + do not carry any user data that would require retransmission if + lost. Most datagram transports permit this. If a probe packet + contains user data requiring retransmission in case of loss, the + PL (or layers above) are REQUIRED to arrange any retransmission/ + repair of any resulting loss. DPLPMTUD is REQUIRED to be robust + in the case where probe packets are lost due to other reasons + (including link transmission error, congestion). - 7. Probing and congestion control: The DPLPMTUD sender treats - isolated loss of a probe packet (with or without a corresponding - PTB message) as a potential indication of a PMTU limit for the - path. Loss of a probe packet SHOULD NOT be treated as an - indication of congestion and the loss SHOULD NOT directly trigger - a congestion control reaction [RFC4821]. + 7. Loss of a probe packet SHOULD NOT be treated as an indication of + congestion. The loss of a probe packet SHOULD NOT directly + trigger a congestion control reaction [RFC4821] because this + could result in unecessary reduction of the sending rate. The + interval between probe packets MUST be at least one RTT. - 8. Shared PLPMTU state: The PLPMTU value could also be stored with - the corresponding entry in the destination cache and used by - other PL instances. 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 [RFC4821]) SHOULD be notified to - make use of the new MTU". Such methods MUST be robust to the - wide variety of underlying network forwarding behaviors, PLPMTU - adjustments based on shared PLPMTU values should be incorporated - in the search algorithms. Section 5.2 of [RFC8201] provides - guidance on the caching of PMTU information and also the relation - to IPv6 flow labels. + 8. Shared PLPMTU state: The PLPMTU value MAY also be stored with the + corresponding entry in the destination cache and used by other PL + instances. 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 [RFC4821]) SHOULD be notified to make use of + the new MTU". Such methods MUST be robust to the wide variety of + underlying network forwarding behaviors. Section 5.2 of + [RFC8201] provides guidance on the caching of PMTU information + and also the relation to IPv6 flow labels. In addition, the following principles are stated for design of a DPLPMTUD method: * MPS: A method is REQUIRED to signal an appropriate MPS to the higher layer using the PL. The value of the MPS can change following a change to the path. It is RECOMMENDED that methods avoid forcing an application to use an arbitrary small MPS (PLPMTU) for transmission while the method is searching for the currently supported PLPMTU. Datagram PLs do not necessarily @@ -574,30 +541,29 @@ 4.1. PLPMTU Probe Packets The DPLPMTUD method relies upon the PL sender being able to generate probe packets with a specific size. TCP is able to generate these probe packets by choosing to appropriately segment data being sent [RFC4821]. In contrast, a datagram PL that needs to construct a probe packet has to either request an application to send a data block that is larger than that generated by an application, or to utilize padding functions to extend a datagram beyond the size of the application data block. Protocols that permit exchange of control - messages (without an application data block) could alternatively - prefer to generate a probe packet by extending a control message with - padding data. + messages (without an application data block) MAY prefer to generate a + probe packet by extending a control message with padding data. - A receiver needs to be able to distinguish an in-band data block from - any added padding. This is needed to ensure that any added padding - is not passed on to an application at the receiver. + A receiver is REQUIRED to be able to distinguish an in-band data + block from any added padding. This is needed to ensure that any + added padding is not passed on to an application at the receiver. This results in three possible ways that a sender can create a probe - packet listed in order of preference: + packet: Probing using padding data: A probe packet that contains only control information together with any padding, which is needed to be inflated to the size required for the probe packet. Since these probe packets do not carry an application-supplied data block, they do not typically require retransmission, although they do still consume network capacity and incur endpoint processing. Probing using application data and padding data: A probe packet that @@ -763,20 +729,29 @@ A set of checks are intended to provide protection from a router that reports an unexpected PTB_SIZE. The PL also needs to check that the indicated PTB_SIZE is less than the size used by probe packets and larger than minimum size accepted. This section provides a summary of how PTB messages can be utilized. This processing depends on the PTB_SIZE and the current value of a set of variables: + PTB_SIZE < MIN_MTU OR PTB_SIZE == 0 + * Invalid PTB_SIZE. + + * PTB message ought to be discarded without further processing + (e. g. PLPMTU not modified). + + * The information could be utilized as an input to trigger + enabling a resilience mode. + MIN_PMTU < PTB_SIZE < BASE_PMTU * A robust PL MAY enter an error state (see Section 5.2) for an IPv4 path when the PTB_SIZE reported in the PTB message is larger than or equal to 68 bytes and when this is less than the BASE_PMTU. * A robust PL MAY enter an error state (see Section 5.2) for an IPv6 path when the PTB_SIZE reported in the PTB message is larger than or equal to 1280 bytes and when this is less than the BASE_PMTU. @@ -837,21 +812,21 @@ +----------------------+ Figure 1: Examples where DPLPMTUD can be implemented The central idea of DPLPMTUD is probing by a sender. Probe packets are sent to find the maximum size of a user message that can be completely transferred across the network path from the sender to the destination. The following sections identify the components needed for - implementation, provides an overvoew of the phases of operation, and + implementation, provides an overview of the phases of operation, and specifies the state machine and search algorithm. 5.1. DPLPMTUD Components This section describes the timers, constants, and variables of DPLPMTUD. 5.1.1. Timers The method utilizes up to three timers: @@ -908,60 +883,59 @@ An implementation could implement the various timers using a single timer. 5.1.2. Constants 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. The default value of MAX_PROBES is 10. + any size. The default value of MAX_PROBES is 3. This + value is greater than 1 to provide robustness to + isolated packet loss. MIN_PMTU: The MIN_PMTU is the smallest allowed probe packet size. For IPv6, this value is 1280 bytes, as specified in [RFC2460]. For IPv4, the minimum value is 68 bytes. 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_PMTU: The MAX_PMTU is the largest size of PLPMTU. This has to be less than or equal to the minimum of the local MTU of the outgoing interface and the destination PMTU for - receiving. An application, or PL, MAY reduce the + receiving. An application, or PL, MAY choose a smaller MAX_PMTU when there is no need to send packets larger than a specific size. BASE_PMTU: The BASE_PMTU is a configured size expected to work for most paths. The size is equal to or larger than the MIN_PMTU and smaller than the MAX_PMTU. In the case of IPv6, this value is 1280 bytes [RFC2460]. When using IPv4, a size of 1200 bytes is RECOMMENDED. 5.1.3. Variables This method utilizes a set of variables: PROBED_SIZE: The PROBED_SIZE is the size of the current probe packet. This is a tentative value for the PLPMTU, which is awaiting confirmation by an acknowledgment. - PROBE_COUNT: The PROBE_COUNT is a count of the number of - unsuccessful probe packets that have been sent with a - size of PROBED_SIZE. The value is initialized to zero - when a particular size of PROBED_SIZE is first - attempted. + PROBE_COUNT: The PROBE_COUNT is a count of the number of successive + unsuccessful probe packets that have been sent. The figure below illustrates the relationship between the packet size constants and variables at a point of time when the DPLPMTUD algorithm performs path probing to increase the size of the PLPMTU. A probe packet has been sent of size PROBED_SIZE. Once this is acknowledged, the PLPMTU will raise to PROBED_SIZE allowing the DPLPMTUD algorithm to further increase PROBED_SIZE towards the actual PMTU. MIN_PMTU MAX_PMTU @@ -1071,21 +1045,21 @@ characteristics of the path, such as when a link is reconfigured with a larger MTU, or when there is a change in the set of links traversed by an end-to-end flow (e.g., after a routing or path fail-over decision). 5.2. State Machine A state machine for DPLPMTUD is depicted in Figure 4. If multipath or multihoming is supported, a state machine is needed for each path. - Note: Some state changes are not shown to simplify the diagram. + Note: Not all changes are not shown to simplify the diagram. | | | Start | PL indicates loss | | of connectivity v v +---------------+ +---------------+ | DISABLED | | ERROR | +---------------+ PROBE_TIMER expiry: +---------------+ | PL indicates PROBE_COUNT = MAX_PROBES or ^ | | connectivity PTB: PTB_SIZE < BASE_PMTU | | @@ -1147,49 +1121,48 @@ the SEARCHING state. The state is also left when the PROBE_COUNT reaches MAX_PROBES or a received PTB message is validated. This causes the PL sender to enter the ERROR state. SEARCHING: The SEARCHING state is the main probing state. This state is entered when probing for the BASE_PMTU was successful. - The PROBE_COUNT is set to zero when the first probe - packet is sent for each probe size. Each time a - probe packet is acknowledged, the PLPMTU is set to - the PROBED_SIZE, and then the PROBED_SIZE is + Each time a probe packet is acknowledged, the + PROBE_COUNT is set to zero, the PLPMTU is set to + the PROBED_SIZE and then the PROBED_SIZE is increased using the search algorithm. When a probe packet is sent and not acknowledged within the period of the PROBE_TIMER, the - PROBE_COUNT is incremented and the probe packet is - retransmitted. The state is exited when the + PROBE_COUNT is incremented and a new probe packet + is transmitted. The state is exited when the PROBE_COUNT reaches MAX_PROBES, a received PTB message is validated, a probe of size MAX_PMTU is acknowledged, or a black hole is detected. SEARCH_COMPLETE: The SEARCH_COMPLETE state indicates a successful end to the SEARCHING state. DPLPMTUD remains in this state until either the PMTU_RAISE_TIMER expires, a received PTB message is validated, or a black hole is detected. When DPLPMTUD uses an unacknowledged PL and is in the SEARCH_COMPLETE state, a CONFIRMATION_TIMER periodically resets the PROBE_COUNT and schedules a - probe packet with the size of the PLPMTU. If the - probe packet fails to be acknowledged after - MAX_PROBES attempts, the method enters the BASE - state. When used with an acknowledged PL (e.g., - SCTP), DPLPMTUD SHOULD NOT continue to generate - PLPMTU probes in this state. + probe packet with the size of the PLPMTU. If + MAX_PROBES successive PLPMTUD sized probes fail to + be acknowledged the method enters the BASE state. + When used with an acknowledged PL (e.g., SCTP), + DPLPMTUD SHOULD NOT continue to generate PLPMTU + probes in this state. ERROR: The ERROR state represents the case where either the network path is not known to support a PLPMTU of at least the BASE_PMTU size or when there is contradictory information about the network path that would otherwise result in excessive variation in the MPS signalled to the higher layer. The state implements a method to mitigate oscillation in the state-event engine. It signals a conservative value of the MPS to the higher layer @@ -1217,43 +1190,43 @@ determine whether a larger PLPMTU can be supported across a network path. The method discovers the search range by confirming the minimum PLPMTU and then using the probe method to select a PROBED_SIZE less than or equal to MAX_PMTU. MAX_PMTU is the minimum of the local MTU and EMTU_R (learned from the remote endpoint). The MAX_PMTU MAY be reduced by an application that sets a maximum to the size of datagrams it will send. - The PROBE_COUNT is initialized to zero when a probe packet is first - sent with a particular size. A timer is used by the search algorithm - to trigger the sending of probe packets of size PROBED_SIZE, larger - than the PLPMTU. Each probe packet successfully sent to the remote - peer is confirmed by acknowledgement at the PL, see Section 4.1. + The PROBE_COUNT is initialized to zero when the first probe with a + size greater than or equal to PLPMTUD is sent. A timer is used by + the search algorithm to trigger the sending of probe packets of size + PROBED_SIZE, larger than the PLPMTU. Each probe packet successfully + sent to the remote peer is confirmed by acknowledgement at the PL, + see Section 4.1. Each time a probe packet is sent to the destination, the PROBE_TIMER is started. The timer is canceled when the PL receives acknowledgment that the probe packet has been successfully sent across the path Section 4.1. This confirms that the PROBED_SIZE is supported, and the PROBED_SIZE value is then assigned to the PLPMTU. The search algorithm can continue to send subsequent probe packets of an increasing size. If the timer expires before a probe packet is acknowledged, the probe has failed to confirm the PROBED_SIZE. Each time the PROBE_TIMER expires, the PROBE_COUNT is incremented, the PROBE_TIMER is - reinitialized, and a probe packet of the same size is retransmitted - (the replicated probe improve the resilience to loss). The maximum - number of retransmissions for a particular size is configured - (MAX_PROBES). If the value of the PROBE_COUNT reaches MAX_PROBES, - probing will stop, and the PL sender enters the SEARCH_COMPLETE - state. + reinitialized, and a new probe of the same size or any other sized + (determined by the search algorithm) can be sent. The maximum number + of consecutive failed probes is configured (MAX_PROBES). If the + value of the PROBE_COUNT reaches MAX_PROBES, probing will stop, and + the PL sender enters the SEARCH_COMPLETE state. 5.3.2. Selection of Probe Sizes The search algorithm needs to determine a minimum useful gain in PLPMTU. It would not be constructive for a PL sender to attempt to probe for all sizes. This would incur unnecessary load on the path and has the undesirable effect of slowing the time to reach a more optimal MPS. Implementations SHOULD select the set of probe packet sizes to maximize the gain in PLPMTU from each search step. @@ -1286,22 +1259,22 @@ Some paths could be unable to sustain packets of the BASE_PMTU size. To be robust to these paths an implementation could implement the Error State. This allows fallback to a smaller than desired PLPMTU, rather than suffer connectivity failure. This could utilize methods such as endpoint IP fragmentation to enable the PL sender to communicate using packets smaller than the BASE_PMTU. 6. Specification of Protocol-Specific Methods - This section specifies protocol-specific details for datagram PLPMTUD - for IETF-specified transports. + DPLPMTUD requires protocol-specific details to be specified for each + PL that is used. The first subsection provides guidance on how to implement the DPLPMTUD method as a part of an application using UDP or UDP-Lite. The guidance also applies to other datagram services that do not include a specific transport protocol (such as a tunnel encapsulation). The following subsections describe how DPLPMTUD can be implemented as a part of the transport service, allowing applications using the service to benefit from discovery of the PLPMTU without themselves needing to implement this method. @@ -1565,26 +1538,23 @@ 8. 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. 9. 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 Usage Guidelines [RFC8085], specifically the - generation of probe packets is regarded as a "Low Data-Volume - Application", described in section 3.1.3 of this document. This - recommends that sender limits generation of probe packets to an - average rate lower than one probe per 3 seconds. + in the references RFCs. The interval between individual probe + packets MUST be at least one RTT, and the interval between rounds of + probing is determined by the PMTU_RAISE_TIMER. A PL sender needs to ensure that the method used to confirm reception of probe packets offers protection from off-path attackers injecting packets into the path. This protection if provided in IETF-defined protocols (e.g., TCP, SCTP) using a randomly-initialized sequence number. A description of one way to do this when using UDP is provided in section 5.1 of [RFC8085]). There are cases where ICMP Packet Too Big (PTB) messages are not delivered due to policy, configuration or equipment design (see @@ -1683,24 +1653,24 @@ [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 2017, . 10.2. Informative References [I-D.ietf-intarea-tunnels] Touch, J. and M. Townsley, "IP Tunnels in the Internet - Architecture", draft-ietf-intarea-tunnels-09 (work in - progress), 19 July 2018, + Architecture", draft-ietf-intarea-tunnels-10 (work in + progress), 12 September 2019, . + tunnels-10.txt>. [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, . @@ -1876,22 +1846,34 @@ * Removed section on DPLPMTUD with UDP Options. * Shortened the description of phases. Working group draft -09: * Remove final mention of UDP Options * Add Initial Connectivity sections to each PL + * Add to disable outgoing pmtu enforcement of packets + Working group draft -10: + + * Address comments from Lars Eggert + + * Reinforce that PROBE_COUNT is successive attempts to probe for any + size + + * Redefine MAx_PROBES to 3 + + * Address PTB_SIZE of 0 or less that MIN_PMTU + Authors' Addresses Godred Fairhurst University of Aberdeen School of Engineering, Fraser Noble Building Aberdeen AB24 3UE United Kingdom Email: gorry@erg.abdn.ac.uk