idnits 2.17.1 draft-fairhurst-tsvwg-udp-options-dplpmtud-01.txt: 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: ---------------------------------------------------------------------------- No issues found here. 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 (October 2, 2019) is 1668 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 (-22) exists of draft-ietf-tsvwg-datagram-plpmtud-07 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-07 -- 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: April 4, 2020 October 2, 2019 7 Datagram PLPMTUD for UDP Options 8 draft-fairhurst-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. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 4, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. DPLPMTUD for UDP Options . . . . . . . . . . . . . . . . . . 3 54 3.1. Confirmation of Connectivity across a Path . . . . . . . 3 55 3.2. Sending UDP-Options Probe Packets . . . . . . . . . . . . 3 56 3.2.1. Sending Packet Probes using the Echo Request Option 57 Request Option . . . . . . . . . . . . . . . . . . . 4 58 3.2.2. Sending Packet Probes that include Application Data . 5 59 3.3. Validating the Path with UDP Options . . . . . . . . . . 6 60 3.3.1. Sending Packet Probes using Timestamps . . . . . . . 6 61 3.4. PTB Message Handling for this Method . . . . . . . . . . 6 62 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 7.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 The User Datagram Protocol [RFC0768] offers a minimal transport 74 service on top of IP and is frequently used as a substrate for other 75 protocols. Applications using UDP frequently have to implement basic 76 transport services such as Path Maximum Transmission Unit Discovery 77 (PMTUD) themselves. Section 3.5 of UDP Guidelines [RFC8085] 78 recommends that applications implement some form of Path MTU 79 Discovery to avoid the generation of IP fragments: 81 "Consequently, an application SHOULD either use the path MTU 82 information provided by the IP layer or implement Path MTU Discovery 83 (PMTUD)". 85 The UDP API [RFC8304] offers calls for applications to receive ICMP 86 Packet Too Big (PTB) messages and to control the size of messages 87 that are sent, but does not offer any automatic mechanisms for an 88 application to discover the maximum packet size supported by a path. 89 Applications and upper layer protocols are left to implement robust 90 PMTUD mechanisms of their own. 92 Packetization Layer PMTUD (PLPMTUD) [RFC4821] describes a method for 93 a Packetization Layer (such as UDP with options) to search for the 94 largest MTU supported on a path in the absence of ICMP PTB messages. 95 Datagram PLPMTUD [I-D.ietf-tsvwg-datagram-plpmtud] describes PMTUD 96 probing and search algorithms for datagram transports that do not 97 solely rely on ICMP PTB messages. This allows the Packetization 98 Layer (PL) to offer a probing mechanism which works in the presence 99 of lost probes. However, UDP is unable itself to offer the required 100 probing mechanisms to implement DPLPMTUD without some additional 101 transport services. 103 This document specifies the additional functionality required to 104 perform DPLPMTUD with UDP Options [I-D.ietf-tsvwg-udp-options]as a 105 service to upper-layer protocols. UDP Options supplies additional 106 functionality that can be used to implement DPLPMTUD within the UDP 107 transport service. Implementing DPLPMTUD using UDP Options avoids 108 the need for each upper layer protocol or application to implement 109 the DPLPMTUD method. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in BCP 14 [RFC2119] 116 [RFC8174] when, and only when, they appear in all capitals, as shown 117 here. 119 The structure of the present document follows the structure used to 120 describe DPLPMTUD for other transports 121 [I-D.ietf-tsvwg-datagram-plpmtud]. 123 3. DPLPMTUD for UDP Options 125 The DPLPMTUD PL endpoint implements the method specified in 126 [I-D.ietf-tsvwg-datagram-plpmtud]. 128 3.1. Confirmation of Connectivity across a Path 130 The DPLPMTUD method requires that the PL is able to confirm 131 connectivity on the path (Section 5.2.1 of 132 [I-D.ietf-tsvwg-datagram-plpmtud]). 134 The UDP API does not offer a mechanism for a sender to confirm 135 connectivity, a UDP Options sender SHOULD use reception of an option 136 that elicits a positive confirmation (i.e. Timestamps, ECHO Request/ 137 Response) to confirm connectivity of the path. 139 3.2. Sending UDP-Options Probe Packets 141 This method relies upon the sender Packetization Layer to be able to 142 generate probe packets with a specific size. UDP Options enables 143 padding to be added to a UDP datagram that is used as these Probe 144 Packets. 146 A PL needs to determine that the current path continues to support 147 the size of datagram that the application is currently sending when 148 in the DPLPMTUD search_done state i.e., to detect black-holing of 149 data (Section 4.2 of [I-D.ietf-tsvwg-datagram-plpmtud]). UDP Options 150 can achieve this by sending probe packets padded to the size of the 151 PLPMTU. 153 A PL also needs, from time to time, to determine whether the current 154 path can support a larger size of datagram that the current PLPMTU. 155 UDP Options can achieve this by sending probe packets padded to the 156 size required for the Packet Probe. 158 A UDP options sender MUST be able to send probes up to the maximum 159 for the size the local interface supports, and not constrained by the 160 maximum PMTU set by network layer mechanisms (such as PMTUD 161 [RFC1063][RFC8201]). There are various options described in DPLPMTUD 162 to send a Packet Probe to test the size of packet supported by a path 163 (see Section 4.1 of [I-D.ietf-tsvwg-datagram-plpmtud]). This 164 secification recommends "Probing using padding data". 166 3.2.1. Sending Packet Probes using the Echo Request Option Request 167 Option 169 The RECOMMENDED method sends a Packet Probe with the Echo Request 170 Option (RES) together with any padding needed to be inflated to the 171 size required for the Packet Probe. The reception of this option 172 generates an Echo Response Option that confirms reception of each 173 received Packet Probe. 175 Implementations ought to only send a Packet Probe with a Request 176 Probe Option when required by their local DPLPMTUD state machine, 177 i.e., when probing to grow the PLPMTU or to confirm the current 178 PLPMTU. 180 Packet Probes consume network capacity and incur endpoint processing 181 (see Section 4.1 of [I-D.ietf-tsvwg-datagram-plpmtud]). 183 Implementations MAY track multiple requests and respond to them with 184 a single packet. 186 The UDP Options used in this method are described in section 6 of 187 [I-D.ietf-tsvwg-udp-options]: 189 o The Echo Request Option (RES) is set by a sending PL to solicit a 190 response from a remote endpoint. A four-byte token identifies 191 each request. 193 o The Echo Response Option (REQ) is generated by the UDP Options 194 receiver in response to reception of a previously received Echo 195 Request Option. Each Echo Response Option echoes a previously 196 received four-byte token. 198 The token value allows implementations to distinguish between 199 acknowledgements for initial Packet Probes and acknowledgements 200 confirming receipt of subsequent Packet Probes (e.g., travelling 201 along alternate paths with a larger round trip time). Each Packet 202 Probe needs to be uniquely identifiable by the UDP Options sender 203 within the Maximum Segment Lifetime (MSL). The UDP Options sender 204 therefore needs to not recycle token values until they have expired 205 or have been acknowledged. A four byte value for the token field 206 provides sufficient space for multiple unique probes to be made 207 within the MSL. 209 The initial value of the four byte token field SHOULD be assigned to 210 a randomised value to enhance protection from off-path attacks, as 211 described in section 5.1 of [RFC8085]). 213 The procedure to handle the loss of a datagram is the responsibility 214 of the sender of the request. Implementations MAY track multiple 215 requests and respond to them with a single packet carrying the Echo 216 Response Option (REQ). 218 3.2.2. Sending Packet Probes that include Application Data 220 The RECOMMENDED approach to generate Packet Probes is to send a probe 221 that contains only control information. 223 A sender could include application data in Packet Probes (Section 4.1 224 of [I-D.ietf-tsvwg-datagram-plpmtud] discusses the merits and 225 demerits of this approach). A Packet Probe then contains a data 226 block supplied by an application that is combined with padding to 227 inflate the length of the datagram to the size required for the probe 228 and additionally include an Echo Request Option or Timestamp Option 229 (Section 5.9 [I-D.ietf-tsvwg-udp-options]). 231 If the application/transport needs protection from the loss of data 232 in the Packet Probe payload, the application/ transport could perform 233 transport-layer retransmission/repair of the data block (e.g., by 234 retransmission after loss is detected or by duplicating the data 235 block in a datagram without the padding) [RFC8085]. 237 3.3. Validating the Path with UDP Options 239 A PL needs to validate that the path continues to support the PLPMTU 240 discovered in a previous search for a suitable PLPMTU value (see 241 Section 6.1.4 of [I-D.ietf-tsvwg-datagram-plpmtud]). This could be 242 provided by an upper layer protocol confirming correct reception of 243 data by the remote PL, but there is no generic mechanism to provide 244 this in UDP Options, and therefore requires generation of a Packet 245 Probe of size PLPMTU to confirm the path. This Packet Probe could 246 use either the ECHO Response Option or the TimeStamp option to elicit 247 a response from the remote PL. 249 3.3.1. Sending Packet Probes using Timestamps 251 Reception of a valid Timestamps Option echoed by the remote endpoint 252 can be used to infer connectivity and that packets of the current 253 size are being received by the remote PL. This can provide useful 254 feedback, even over paths with asymmetric capacity and/or that carry 255 UDP Option flows that have very asymmetric datagram rates, because an 256 echo of the most recent timestamp still indicates reception of at 257 least one packet of the transmitted size. This is sufficient to 258 confirm there is no black hole (see Section 2.1 of [RFC2923]). 260 When sending a probe to increase the PLPMTU, a Timestamp might be 261 unable to unambiguously identify that a specific Packet Probe has 262 been received [KP87]. Timestamp mechanisms therefore cannot be used 263 to confirm the reception of individual probe messages and cannot be 264 used to stimulate a response from the remote peer. Packet Probes 265 used to search for a larger PLPMTU MUST include the Echo Request 266 Option. 268 3.4. PTB Message Handling for this Method 270 A UDP Options sender MAY ignore received ICMP PTB messages. 272 A UDP Options sender that utilises ICMP PTB messages received to a 273 Packet Probe MUST use the quoted packet to validate the UDP port 274 information in combination with the token and/or timestamp value 275 contained in the UDP Option, before processing the packet using the 276 DPLPMTUD method (Section 4.4.1 of [I-D.ietf-tsvwg-datagram-plpmtud]). 277 An implementation unable to support this validation needs to ignore 278 received ICMP PTB messages. 280 As in other implementations of DPLPMTUD, a PL implementing this 281 specification MUST suspend processing of ICMP PTB by the network 282 layer (as specified in PMTUD [RFC1191] [RFC8201]) for each flow 283 utilising DPLPMTUD. 285 4. Acknowledgements 287 Gorry Fairhurst and Tom Jones are supported by funding provided by 288 the University of Aberdeen. 290 5. IANA Considerations 292 This memo includes no requests to IANA. 294 6. Security Considerations 296 The security considerations for using UDP Options are described in 297 [I-D.ietf-tsvwg-udp-options]. The proposed new method does not 298 change the integrity protection offered by the UDP options method. 300 The security considerations for using DPLPMTUD are described in 301 [I-D.ietf-tsvwg-datagram-plpmtud]. The proposed new method does not 302 change the ICMP PTB message validation method described DPLPMTUD. 304 7. References 306 7.1. Normative References 308 [I-D.ietf-tsvwg-datagram-plpmtud] 309 Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 310 T. Voelker, "Packetization Layer Path MTU Discovery for 311 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-07 312 (work in progress), February 2019. 314 [I-D.ietf-tsvwg-udp-options] 315 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 316 udp-options-07 (work in progress), March 2019. 318 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 319 DOI 10.17487/RFC0768, August 1980, 320 . 322 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 323 DOI 10.17487/RFC1191, November 1990, 324 . 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 332 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 333 May 2017, . 335 7.2. Informative References 337 [KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time 338 Estimates in Reliable Transport Protocols", 1987. 340 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 341 MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, 342 July 1988, . 344 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 345 RFC 2923, DOI 10.17487/RFC2923, September 2000, 346 . 348 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 349 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 350 . 352 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 353 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 354 March 2017, . 356 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 357 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 358 DOI 10.17487/RFC8201, July 2017, 359 . 361 [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the 362 User Datagram Protocol (UDP) and Lightweight UDP (UDP- 363 Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, 364 . 366 Appendix A. Revision Notes 368 XXX Note to RFC-Editor: please remove this entire section prior to 369 publication. XXX 371 Individual draft-00. 373 o This version contains a description for consideration and comment 374 by the TSVWG. 376 Individual draft-01. 378 o Address Nits 379 o Change Probe Request and Probe Reponse options to Echo to align 380 names with draft-ietf-tsvwg-udp-options 382 o Remove Appendix B, Informative Description of new UDP Options 384 o Add additional sections around Packet Probe generation 386 Authors' Addresses 388 Godred Fairhurst 389 University of Aberdeen 390 School of Engineering 391 Fraser Noble Building 392 Aberdeen AB24 3UE 393 UK 395 Email: gorry@erg.abdn.ac.uk 397 Tom Jones 398 University of Aberdeen 399 School of Engineering 400 Fraser Noble Building 401 Aberdeen AB24 3UE 402 UK 404 Email: tom@erg.abdn.ac.uk