idnits 2.17.1 draft-ietf-tsvwg-udp-options-dplpmtud-01.txt: -(349): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (18 November 2021) is 888 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-13 -- Obsolete informational reference (is this intentional?): RFC 1063 (Obsoleted by RFC 1191) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Fairhurst 3 Internet-Draft T. Jones 4 Intended status: Standards Track University of Aberdeen 5 Expires: 22 May 2022 18 November 2021 7 Datagram PLPMTUD for UDP Options 8 draft-ietf-tsvwg-udp-options-dplpmtud-01 10 Abstract 12 This document specifies how a UDP Options sender implements Datagram 13 Packetization Layer Path Maximum Transmission Unit Discovery 14 (DPLPMTUD) as a robust method for Path Maximum Transmission Unit 15 discovery. This method uses the UDP Options packetization layer. It 16 allows a datagram application to discover the largest size of 17 datagram that can be sent across a network path. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 22 May 2022. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. DPLPMTUD for UDP Options . . . . . . . . . . . . . . . . . . 3 55 4. Sending UDP-Options Probe Packets . . . . . . . . . . . . . . 4 56 4.1. Packet Probes using the Echo Request Option Request 57 Option . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. DPLPMTUD Procedures for UDP Options . . . . . . . . . . . 5 59 4.2.1. Confirmation of Connectivity across a Path . . . . . 5 60 4.2.2. Sending Probe Packets to Increase the PLPMTU . . . . 5 61 4.2.3. Validating the Path with UDP Options . . . . . . . . 6 62 4.2.4. Sending Packet Probes that include Application 63 Data . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.3. PTB Message Handling for this Method . . . . . . . . . . 7 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 The User Datagram Protocol [RFC0768] offers a minimal transport 77 service on top of IP and is frequently used as a substrate for other 78 protocols. Section 3.5 of UDP Guidelines [RFC8085] recommends that 79 applications implement some form of Path MTU discovery to avoid the 80 generation of IP fragments: 82 "Consequently, an application SHOULD either use the path MTU 83 information provided by the IP layer or implement Path MTU Discovery 84 (PMTUD)". 86 The UDP API [RFC8304] offers calls for applications to receive ICMP 87 Packet Too Big (PTB) messages and to control the maximum size of 88 datagrams that are sent, but does not offer any automated mechanisms 89 for an application to discover the maximum packet size supported by a 90 path. Applications and upper layer protocols implement mechanisms 91 for Path MTU discovery above the UDP API. 93 Packetization Layer PMTUD (PLPMTUD) [RFC4821] describes a method for 94 a Packetization Layer (PL) (such as UDP Options) to search for the 95 largest Packetization Layer PMTU (PLPMTU) supported on a path. 96 Datagram PLPMTUD (DPLPMTUD) [RFC8899] specifies this support for 97 datagram transports. PLPMTUD and DPLPMTUD gain robustness by using a 98 probing mechanism that does not solely rely on ICMP PTB messages and 99 works on paths that drop ICMP PTB messages. 101 In summary, UDP Options [I-D.ietf-tsvwg-udp-options] supplies 102 functionality that can be used to implement DPLPMTUD within the UDP 103 transport service. This document specifies how an implementation can 104 use this additional functionality to support DPLPMTUD. Implementing 105 DPLPMTUD using UDP Options avoids the need for each upper layer 106 protocol or application to implement the DPLPMTUD method. This 107 provides a standard method for applications to discover the current 108 maximum packet size for a path and to detect when this changes. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in BCP 14 [RFC2119] 115 [RFC8174] when, and only when, they appear in all capitals, as shown 116 here. 118 3. DPLPMTUD for UDP Options 120 There are two ways an upper PL can perform DPLPMTUD: 122 * The UDP Options sender implementing DPLPMTUD uses the method 123 specified in [RFC8899] and the upper PL or application does not 124 perform PMTU discovery. In this case, UDP Options processing is 125 responsible for sending probes to determine a PLPMTU, as described 126 in this document. This discovered PLPMTU can be used by UDP 127 Options to either: 129 - set the maximum datagram size for the current path (based on 130 the discovered largest IP packet that can be received across 131 the path). 133 - set the maximum fragment size when a sender uses the UDP 134 Fragmentation Option to divide a datagram into multiple UDP 135 fragments for transmission. Each UDP fragment is then less 136 than the discovered largest IP packet that can be received 137 across the path. 139 * An upper PL or application performs DPLPMTUD (e.g., QUIC 140 [RFC9000]). This upper PL then uses probes to determine a safe 141 PLPMTU for the datagrams that it sends. The contents of any probe 142 is determined by the upper PL. Such a design needs to avoid 143 performing discovery at multiple levels, so, when when 144 configurable, this upper PL SHOULD disable DPLPMTUD by UDP Options 145 [RFC8899]). 147 This section describe packet formats and procedures for DPLPMTUD 148 using UDP Options. 150 4. Sending UDP-Options Probe Packets 152 DPLPMTUD relies upon the ability of a UDP Options sender to generate 153 a probe with a specific size, up to the maximum for the size 154 supported by the local interface. The size of a DPLPMTUD probe 155 packet MUST NOT be constrained by the maximum PMTU set by network 156 layer mechanisms (such as PMTUD [RFC1063][RFC8201] or the IP Cache). 158 Probe packets consume network capacity and incur endpoint processing 159 (see Section 4.1 of [RFC8899]). Implementations ought to send a 160 probe with a Request Probe Option only when required by their local 161 DPLPMTUD state machine, i.e., when confirming the base PMTU for the 162 path, probing to increase the PLPMTU or to confirm the current 163 PLPMTU. 165 4.1. Packet Probes using the Echo Request Option Request Option 167 This section describes a format of probe consisting of an empty UDP 168 datagram, UDP Options area and Padding. The UDP Options area 169 contains the Echo Request Option (RES), any other required options 170 concluded with an EOL Option followed by any padding needed to 171 inflate to the required probe size. The reception of this option 172 generates an Echo Response Option that confirms reception of a 173 specific received probe. 175 The UDP Options used in this method are described in section 6 of 176 [I-D.ietf-tsvwg-udp-options]: 178 * The Echo Request Option (RES) is set by a sending PL to solicit a 179 response from a remote UDP Options receiver. A four-byte token 180 identifies each request. 182 * The Echo Response Option (REQ) is generated by the UDP Options 183 receiver in response to reception of a previously received Echo 184 Request Option. Each Echo Response Option echoes a previously 185 received four-byte token. 187 The token value allows a sender to distinguish between 188 acknowledgements for initial probes and acknowledgements confirming 189 receipt of subsequent probes (e.g., travelling along alternate paths 190 with a larger round trip time). This needs each probe to be uniquely 191 identifiable by the UDP Options sender within the Maximum Segment 192 Lifetime (MSL). The UDP Options sender therefore MUST NOT recycle 193 token values until they have expired or have been acknowledged. A 194 four byte value for the token field provides sufficient space for 195 multiple unique probes to be made within the MSL. 197 The initial value of the four byte token field SHOULD be assigned to 198 a randomised value to enhance protection from off-path attacks, as 199 described in section 5.1 of [RFC8085]). 201 4.2. DPLPMTUD Procedures for UDP Options 203 DPLPMTUD utilizes three types of probes. These are described in the 204 following sections: 206 * A probe to confirm the path can support the base PLPMTU. 208 * A probe to detect whether the path can support a larger PLPMTU. 210 * A probe to validate the path supports the current PLPMTU. 212 4.2.1. Confirmation of Connectivity across a Path 214 The DPLPMTUD method requires a PL to confirm connectivity over the 215 path using the base PLPMTU (see Section 5.1.4 of [RFC8899]), but UDP 216 does not offer a mechanism for this. 218 UDP Options can provide this required functionality. A UDP Options 219 sender implementing this specification MUST elicit a positive 220 confirmation of connectivity for the path, by sending a probe, padded 221 to size BASE_PLPMTU. This confirmation probe MUST include a UDP 222 Option that elicits a response from the remote endpoint (e.g., by 223 including the ECHO Request/Response Option) to confirm that a packet 224 of the size traversed the path. 226 4.2.2. Sending Probe Packets to Increase the PLPMTU 228 From time to time, DPLPMTUD searches to detect whether the current 229 path can support a larger PLPMTU. When the remote endpoint 230 advertises a UDP Maximum Segment Size (MSS) option, this value can be 231 used as a hint to initialise this search to increase the PLPMTU. 233 Probe packets seeking to increase the PLPMTU SHOULD NOT carry 234 application data (see "Probing using padding data" in Section 4.1 of 235 [RFC8899]), since they will be lost whenever their size exceeds the 236 actual PMTU. 238 A probe seeking to increase the PLPMTU MUST elicit a positive 239 confirmation that the path has delivered a Datagram of the specific 240 probed size and therefore SHOULD include the Echo Request Option 241 Request Option. 243 Received probes that do not carry application data do not form a part 244 of the end-to-end transport data and are not delivered to the upper 245 layer protocol. 247 4.2.3. Validating the Path with UDP Options 249 A PL using DPLPMTUD needs to validate that a path continues to 250 support the PLPMTU discovered in a previous search for a suitable 251 PLPMTU value (see Section 6.1.4 of [RFC8899]). This validation sends 252 probes in the DPLPMTUD SEARCH_COMPLETE state i.e., to detect black- 253 holing of data (see Section 4.2 of [RFC8899]). 255 This function can be implemented within UDP Options, by generating a 256 probe of size PLPMTU which MUST include a UDP Option to elicit a 257 positive confirmation that the path has delivered the probe. This 258 confirmation probe MAY use "Probing using padding data" or "Probing 259 using application data and padding data" (see Section 4.1 of 260 [RFC8899]) or can construct a probe packet that does not carry any 261 application data, as described in a previous section. 263 4.2.4. Sending Packet Probes that include Application Data 265 The method can be designed to only use probes that are formed of a 266 UDP Options datagram containing control information, padded to the 267 required size. This implements "Probing using padding data", and 268 avoids having to retransmit application data when a probe fails. 269 This type of probe must be used when searching to increase the 270 PLPMTU. These probes do not form a part of the end-to-end transport 271 data and a receiver does not deliver these to the upper layer 272 protocol. A simple implementation of the method might be designed to 273 only use this format for all probes. 275 Probe used to confirm the connectivity or to validate support for the 276 current PLPMTU are also permitted to carry application data, since 277 this type of probe is expected to be successful. Section 4.1 of 278 [RFC8899] provides a discussion of the merits and demerits of 279 including application data. For example, this reduces the need to 280 send an additional datagram when confirming that the current path 281 supports datagrams of size PLPMTU and could be designed to utilise a 282 control message format defined by the PL that does not need to be 283 delivered reliably. 285 4.3. PTB Message Handling for this Method 287 Support for receiving ICMP PTB messages is OPTIONAL for use with 288 DPLPMTUD. A UDP Options sender can therefore ignore received ICMP 289 PTB messages. 291 A UDP Options sender that utilises ICMP PTB messages received in 292 response to a probe packet MUST use the quoted packet to validate the 293 UDP port information in combination with the token and/or timestamp 294 value contained in the UDP Option, before processing the packet using 295 the DPLPMTUD method (see Section 4.4.1 of [RFC8899]). An 296 implementation unable to support this validation needs to ignore 297 received ICMP PTB messages. 299 5. Acknowledgements 301 Gorry Fairhurst and Tom Jones are supported by funding provided by 302 the University of Aberdeen. 304 6. IANA Considerations 306 This memo includes no requests to IANA. 308 7. Security Considerations 310 The security considerations for using UDP Options are described in 311 [I-D.ietf-tsvwg-udp-options]. The proposed new method does not 312 change the integrity protection offered by the UDP options method. 314 The specification recommends that the token in the REQ/RES message is 315 initialised to a randomised value to enhance protection from off-path 316 attacks. 318 The security considerations for using DPLPMTUD are described in 319 [RFC8899]. The proposed new method does not change the ICMP PTB 320 message validation method described DPLPMTUD: A UDP Options sender 321 that utilises ICMP PTB messages received to a probe packet MUST use 322 the quoted packet to validate the UDP port information in combination 323 with the token and/or timestamp value contained in the UDP Option, 324 before processing the packet using the DPLPMTUD method. 326 8. References 328 8.1. Normative References 330 [I-D.ietf-tsvwg-udp-options] 331 Touch, J. D., "Transport Options for UDP", Work in 332 Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-13, 333 19 June 2021, . 336 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 337 DOI 10.17487/RFC0768, August 1980, 338 . 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, 342 DOI 10.17487/RFC2119, March 1997, 343 . 345 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 346 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 347 May 2017, . 349 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 350 Völker, "Packetization Layer Path MTU Discovery for 351 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 352 September 2020, . 354 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 355 Multiplexed and Secure Transport", RFC 9000, 356 DOI 10.17487/RFC9000, May 2021, 357 . 359 8.2. Informative References 361 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 362 MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, 363 July 1988, . 365 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 366 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 367 . 369 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 370 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 371 March 2017, . 373 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 374 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 375 DOI 10.17487/RFC8201, July 2017, 376 . 378 [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the 379 User Datagram Protocol (UDP) and Lightweight UDP (UDP- 380 Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, 381 . 383 Appendix A. Revision Notes 385 XXX Note to RFC-Editor: please remove this entire section prior to 386 publication. XXX 388 Individual draft-00. 390 * This version contains a description for consideration and comment 391 by the TSVWG. 393 Individual draft-01. 395 * Address Nits 397 * Change Probe Request and Probe Reponse options to Echo to align 398 names with draft-ietf-tsvwg-udp-options 400 * Remove Appendix B, Informative Description of new UDP Options 402 * Add additional sections around Probe Packet generation 404 Individual draft-02. 406 * Address Nits 408 Individual draft-03. 410 * Referenced DPLPMTUD RFC. 412 * Tidied language to clarify the method. 414 Individual draft-04 416 * Reworded text on probing with data a little 418 * Removed paragraph on suspending ICMP PTB suspension. 420 Working group draft-00 422 * -00 First Working Group Version 424 * RFC8899 call search_done SEARCH_COMPLETE, fix 425 Working group draft -01 427 * Update to reflect new fragmentation design in UDP Options. 429 * Add a description of uses of DPLPMTUD with UDP Options. 431 * Add a description on how to form probe packets with padding. 433 * Say that MSS options can be used to initialise the search 434 algorithm. 436 * Say that the recommended approach is to not use user data for 437 probes. 439 * Attempts to clarify and improve wording throughout. 441 * Remove text saying you can respond to multiple probes in a single 442 packet. 444 * Simplified text by removing options that don't yield benefit. 446 Authors' Addresses 448 Godred Fairhurst 449 University of Aberdeen 450 School of Engineering 451 Fraser Noble Building 452 Aberdeen 453 AB24 3UE 454 United Kingdom 456 Email: gorry@erg.abdn.ac.uk 458 Tom Jones 459 University of Aberdeen 460 School of Engineering 461 Fraser Noble Building 462 Aberdeen 463 AB24 3UE 464 United Kingdom 466 Email: tom@erg.abdn.ac.uk