idnits 2.17.1 draft-ietf-tsvwg-udp-options-dplpmtud-02.txt: -(386): 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 (25 November 2021) is 875 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 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: 29 May 2022 25 November 2021 7 Datagram PLPMTUD for UDP Options 8 draft-ietf-tsvwg-udp-options-dplpmtud-02 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 specific 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 29 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 Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised 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 and Response 57 Options . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . 6 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.2.5. Changes in the Path . . . . . . . . . . . . . . . . . 7 65 4.3. PTB Message Handling for this Method . . . . . . . . . . 7 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 8.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 The User Datagram Protocol [RFC0768] offers a minimal transport 78 service on top of IP and is frequently used as a substrate for other 79 protocols. Section 3.5 of UDP Guidelines [RFC8085] recommends that 80 applications implement some form of Path MTU discovery to avoid the 81 generation of IP fragments: 83 "Consequently, an application SHOULD either use the path MTU 84 information provided by the IP layer or implement Path MTU Discovery 85 (PMTUD)". 87 The UDP API [RFC8304] offers calls for applications to receive ICMP 88 Packet Too Big (PTB) messages and to control the maximum size of 89 datagrams that are sent, but does not offer any automated mechanisms 90 for an application to discover the maximum packet size supported by a 91 path. Upper layer protocols (which can include applications) 92 implement mechanisms for Path MTU discovery above the UDP API. 94 Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] describes 95 a method for a Packetization Layer (PL) (such as UDP Options) to 96 search for the largest Packetization Layer PMTU (PLPMTU) supported on 97 a path. Datagram PLPMTUD (DPLPMTUD) [RFC8899] specifies this support 98 for datagram transports. PLPMTUD and DPLPMTUD gain robustness by 99 using a probing mechanism that does not solely rely on ICMP PTB 100 messages and works on paths that drop ICMP PTB messages. 102 This document specifies how UDP Options [I-D.ietf-tsvwg-udp-options] 103 can be used as a PL to implement DPLPMTUD (see Section 6.1 of 104 [RFC8899]). In summary, UDP Options [I-D.ietf-tsvwg-udp-options] 105 supplies functionality that can be used to implement DPLPMTUD within 106 the UDP transport service. Implementing DPLPMTUD using UDP Options 107 avoids the need for each upper layer protocol or application to 108 implement the DPLPMTUD method. This provides a standard method for 109 applications to discover the current maximum packet size for a path 110 and to detect when this changes. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14 [RFC2119] 117 [RFC8174] when, and only when, they appear in all capitals, as shown 118 here. 120 3. DPLPMTUD for UDP Options 122 There are two ways an upper PL can perform DPLPMTUD: 124 * The UDP Options sender implementing DPLPMTUD uses the method 125 specified in [RFC8899] and the upper PL (or application) does not 126 perform PMTU discovery. In this case, UDP Options processing is 127 responsible for sending probes to determine a PLPMTU, as described 128 in this document. "An application SHOULD avoid using DPLPMTUD 129 when the underlying transport system provides this capability" 130 (Section 6.1 of [RFC8899]). This discovered PLPMTU can be used by 131 UDP Options to either: 133 - set the maximum datagram size for the current path (based on 134 the discovered largest IP packet that can be received across 135 the current path). 137 - set the maximum fragment size when a sender uses the UDP 138 Fragmentation Option to divide a datagram into multiple UDP 139 fragments for transmission. Each UDP fragment is then less 140 than the discovered largest IP packet that can be received 141 across the current path. 143 * An upper PL (or application performs DPLPMTUD (e.g., QUIC 144 [RFC9000]). This upper PL then uses probes to determine a safe 145 PLPMTU for the datagrams that it sends. The format and content of 146 any probe is determined by the upper PL. Such a design should 147 avoid performing discovery at multiple levels, so, when when 148 configurable, this upper PL SHOULD disable DPLPMTUD by UDP 149 Options. 151 This section describes packet formats and procedures for DPLPMTUD 152 using UDP Options. 154 4. Sending UDP-Options Probe Packets 156 DPLPMTUD relies upon the ability of a UDP Options sender to generate 157 a probe with a specific size, up to the maximum for the size 158 supported by a local interface. This MUST NOT be constrained by the 159 maximum PMTU set by network layer mechanisms (such as PMTUD 160 [RFC1191][RFC8201] or the PMTU size held in the IP- layer cache), as 161 noted in bullet 2 of Section 2 in [RFC8899]). 163 Probe packets consume network capacity and incur endpoint processing 164 (see Section 4.1 of [RFC8899]). Implementations ought to send a 165 probe with an REQ Option only when required by their local DPLPMTUD 166 state machine, i.e., when confirming the base PMTU for the path, 167 probing to increase the PLPMTU or to confirm the current PLPMTU. 169 4.1. Packet Probes using the Echo Request and Response Options 171 A UDP Options node that supports DPLPMTUD MUST support sending and 172 receiving of the REQ Option and the RES Option. When not supported, 173 DPLPMTUD will be unable to confirm the Path or to discover the PMTU. 175 This section describes a format of probe consisting of an empty UDP 176 datagram, UDP Options area and Padding. 178 A Probe Packet includes the UDP Options area containing a RES Option 179 and any other required options concluded with an EOL Option followed 180 by any padding needed to inflate to the required probe size. 182 The UDP Options used in this document are described in Section 6 of 183 [I-D.ietf-tsvwg-udp-options]: 185 * The REQ Option is set by a sending PL to solicit a response from a 186 remote UDP Options receiver. A four-byte token identifies each 187 request. 189 * The RES Option is generated by the UDP Options receiver in 190 response to reception of a previously received REQ Option. Each 191 RES Option echoes a previously received four-byte token. 193 * Reception of a RES Option confirms reception of a specific 194 received probe by the remote UDP Options receiver. 196 The token value allows a sender to distinguish between 197 acknowledgements for initial probes and acknowledgements confirming 198 receipt of subsequent probes (e.g., travelling along alternate paths 199 with a larger round trip time). This needs each probe to be uniquely 200 identifiable by the UDP Options sender within the Maximum Segment 201 Lifetime (MSL). The UDP Options sender therefore MUST NOT recycle 202 token values until they have expired or have been acknowledged. A 203 four byte value for the token field provides sufficient space for 204 multiple unique probes to be made within the MSL. Since UDP Options 205 operates over UDP, the token values only need to be unique for the 206 specific 5-tuple over which DPLPMTUD is operating. 208 The initial value of the four byte token field SHOULD be assigned to 209 a randomised value to enhance protection from off-path attacks, as 210 described in Section 5.1 of [RFC8085]). 212 4.2. DPLPMTUD Procedures for UDP Options 214 DPLPMTUD utilises three types of probes. These are described in the 215 following sections: 217 * A probe to confirm the path can support the BASE_PLPMTU see 218 Section 5.1.4 of [RFC8899]). 220 * A probe to detect whether the path can support a larger PLPMTU. 222 * A probe to validate the path supports the current PLPMTU. 224 4.2.1. Confirmation of Connectivity across a Path 226 The DPLPMTUD method requires a PL to confirm connectivity over the 227 path using the BASE_PLPMTU (see Section 5.1.4 of [RFC8899]), but UDP 228 does not offer a mechanism for this. 230 UDP Options can provide this required functionality. A UDP Options 231 sender implementing this specification MUST elicit a positive 232 confirmation of connectivity for the path, by sending a probe, padded 233 to size BASE_PLPMTU. This confirmation probe MUST include a UDP 234 Option that elicits a response from the remote endpoint (e.g., by 235 including the RES and REQ Options) to confirm that a packet of the 236 size traversed the path. This also confirms that the remote receiver 237 supports use of the RES and REQ Options. 239 4.2.2. Sending Probe Packets to Increase the PLPMTU 241 From time to time, DPLPMTUD enters the SEARCHING state [RFC8899] 242 (e.g., after expiry of the PMTU_RAISE_TIMER) to detect whether the 243 current path can support a larger PLPMTU. When the remote endpoint 244 advertises a UDP Maximum Segment Size (MSS) option, this value can be 245 used as a hint to initialise this search to increase the PLPMTU. 247 Probe packets seeking to increase the PLPMTU SHOULD NOT carry 248 application data (see "Probing using padding data" in Section 4.1 of 249 [RFC8899]), since they will be lost whenever their size exceeds the 250 actual PMTU. 252 A probe seeking to increase the PLPMTU needs to elicit a positive 253 acknowledgment that the path has delivered a datagram of the specific 254 probed size and, therefore, MUST include the REQ Option. 256 Received probes that do not carry application data do not form a part 257 of the end-to-end transport data and are not delivered to the upper 258 layer protocol. 260 4.2.3. Validating the Path with UDP Options 262 A PL using DPLPMTUD needs to validate that a path continues to 263 support the PLPMTU discovered in a previous search for a suitable 264 PLPMTU value (see Section 6.1.4 of [RFC8899]). This validation sends 265 probes in the DPLPMTUD SEARCH_COMPLETE state to detect black-holing 266 of data (see Section 4.2 of [RFC8899]). 268 This function can be implemented within UDP Options, by generating a 269 probe of size PLPMTU, which MUST include a RES Option to elicit a 270 positive confirmation whether the path has delivered the probe. This 271 confirmation probe MAY use "Probing using padding data" or "Probing 272 using application data and padding data" (see Section 4.1 of 273 [RFC8899]) or can construct a probe packet that does not carry any 274 application data, as described in a previous section. 276 4.2.4. Sending Packet Probes that include Application Data 278 The method can be designed to only use probes that are formed of a 279 UDP datagram that includes application data (which could be 280 applications control information), padded to the required size and 281 include a RES Option. This implements "Probing using padding data", 282 and avoids having to retransmit application data when a probe fails. 283 This type of probe must be used when searching to increase the 284 PLPMTU. In this use, the RES and REQ Options do not form a part of 285 the end-to-end transport data and a receiver does not deliver them to 286 the upper layer protocol. A simple implementation of the method 287 might be designed to only use this format for all probes. 289 The probe used to confirm the connectivity or to validate support for 290 the current PLPMTU are also permitted to carry application data, 291 since this type of probe is expected to be successful. Section 4.1 292 of [RFC8899] provides a discussion of the merits and demerits of 293 including application data. For example, this reduces the need to 294 send an additional datagram when confirming that the current path 295 supports datagrams of size PLPMTU and could be designed to utilise a 296 control message format defined by the PL that does not need to be 297 delivered reliably. In this use, the RES and REQ Options need to be 298 included by the sending upper layer and the values of tokens need to 299 be coordinated with values used for other DPLPMTUD probe packets. 300 These probes do form a part of the end-to-end transport data and a 301 receiver does deliver the RES and REQ Options to the upper layer 302 protocol. 304 4.2.5. Changes in the Path 306 A change in the path or the loss of probe packets can result in a 307 change of the PLPMTU. DPLPMTUD [RFC8899] recommends that methods are 308 robust to path changes that could have occurred since the path 309 characteristics were last confirmed and to the possibility of 310 inconsistent path information being received. For example, a 311 notification that a path could have changed could trigger path 312 validation to provide black hole protection Section 4.3 of 313 [RFC8899]). 315 Section 3 of [RFC8899] requires any methods designed to share the 316 PLPMTU between PLs (such as updating the IP cache PMTU for an 317 interface/destination) to be robust to the wide variety of underlying 318 network forwarding behaviors. For example, an implementation could 319 avoid sharing PMTU information that could potentially relate to 320 packets sent with the same address over a different interface. 322 4.3. PTB Message Handling for this Method 324 Support for receiving ICMP PTB messages is OPTIONAL for use with 325 DPLPMTUD. A UDP Options sender can therefore ignore received ICMP 326 PTB messages. 328 A UDP Options sender that utilises ICMP PTB messages received in 329 response to a probe packet MUST use the quoted packet to validate the 330 UDP port information in combination with the token value contained in 331 the UDP Option, before processing the packet using the DPLPMTUD 332 method. Section 4.6.1 of [RFC8899] specifies this validation 333 procedure. An implementation unable to support this validation needs 334 to ignore received ICMP PTB messages. 336 5. Acknowledgements 338 Gorry Fairhurst and Tom Jones are supported by funding provided by 339 the University of Aberdeen. 341 6. IANA Considerations 343 This memo includes no requests to IANA. 345 7. Security Considerations 347 The security considerations for using UDP Options are described in 348 [I-D.ietf-tsvwg-udp-options]. The proposed new method does not 349 change the integrity protection offered by the UDP options method. 351 The specification recommends that the token in the REQ Option is 352 initialised to a randomised value to enhance protection from off-path 353 attacks. 355 The security considerations for using DPLPMTUD are described in 356 [RFC8899]. The proposed new method does not change the ICMP PTB 357 message validation method described DPLPMTUD: A UDP Options sender 358 that utilies ICMP PTB messages received to a probe packet MUST use 359 the quoted packet to validate the UDP port information in combination 360 with the token and/or timestamp value contained in the UDP Option, 361 before processing the packet using the DPLPMTUD method. 363 8. References 365 8.1. Normative References 367 [I-D.ietf-tsvwg-udp-options] 368 Touch, J. D., "Transport Options for UDP", Work in 369 Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-13, 370 19 June 2021, . 373 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 374 DOI 10.17487/RFC0768, August 1980, 375 . 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, 379 DOI 10.17487/RFC2119, March 1997, 380 . 382 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 383 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 384 May 2017, . 386 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 387 Völker, "Packetization Layer Path MTU Discovery for 388 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 389 September 2020, . 391 8.2. Informative References 393 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 394 DOI 10.17487/RFC1191, November 1990, 395 . 397 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 398 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 399 . 401 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 402 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 403 March 2017, . 405 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 406 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 407 DOI 10.17487/RFC8201, July 2017, 408 . 410 [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the 411 User Datagram Protocol (UDP) and Lightweight UDP (UDP- 412 Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, 413 . 415 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 416 Multiplexed and Secure Transport", RFC 9000, 417 DOI 10.17487/RFC9000, May 2021, 418 . 420 Appendix A. Revision Notes 422 XXX Note to RFC-Editor: please remove this entire section prior to 423 publication. XXX 425 Individual draft-00. 427 * This version contains a description for consideration and comment 428 by the TSVWG. 430 Individual draft-01. 432 * Address Nits 434 * Change Probe Request and Probe Reponse options to Echo to align 435 names with draft-ietf-tsvwg-udp-options 437 * Remove Appendix B, Informative Description of new UDP Options 439 * Add additional sections around Probe Packet generation 441 Individual draft-02. 443 * Address Nits 445 Individual draft-03. 447 * Referenced DPLPMTUD RFC. 449 * Tidied language to clarify the method. 451 Individual draft-04 453 * Reworded text on probing with data a little 455 * Removed paragraph on suspending ICMP PTB suspension. 457 Working group draft-00 459 * -00 First Working Group Version 461 * RFC8899 call search_done SEARCH_COMPLETE, fix 463 Working group draft -01 465 * Update to reflect new fragmentation design in UDP Options. 467 * Add a description of uses of DPLPMTUD with UDP Options. 469 * Add a description on how to form probe packets with padding. 471 * Say that MSS options can be used to initialise the search 472 algorithm. 474 * Say that the recommended approach is to not use user data for 475 probes. 477 * Attempts to clarify and improve wording throughout. 479 * Remove text saying you can respond to multiple probes in a single 480 packet. 482 * Simplified text by removing options that don't yield benefit. 484 Working group draft -02 486 * Update to reflect comments from MED. 488 * More consistent description of DPLPMTUD with UDP Options. 490 * Clarify token is intended per 5-tuple, not interface. 492 * BASE_PLPMTU related to RFC8899. 494 * Probes with user data can carry application control data. 496 * Added that application data uses RES and REQ tokens from the app. 498 * QUIC was intended as an informational reference to an example of 499 RFC8899. 501 Authors' Addresses 503 Godred Fairhurst 504 University of Aberdeen 505 School of Engineering 506 Fraser Noble Building 507 Aberdeen 508 AB24 3UE 509 United Kingdom 511 Email: gorry@erg.abdn.ac.uk 513 Tom Jones 514 University of Aberdeen 515 School of Engineering 516 Fraser Noble Building 517 Aberdeen 518 AB24 3UE 519 United Kingdom 521 Email: tom@erg.abdn.ac.uk