idnits 2.17.1 draft-ietf-tsvwg-datagram-plpmtud-08.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. -- The abstract seems to indicate that this document updates RFC8201, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC4821, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (5 June 2019) is 1780 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 (-34) exists of draft-ietf-quic-transport-20 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-09 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-07 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 Updates4821 (if approved) University of Aberdeen 5 Intended status: Standards Track M. Tuexen 6 Expires: 7 December 2019 I. Ruengeler 7 T. Voelker 8 Muenster University of Applied Sciences 9 5 June 2019 11 Packetization Layer Path MTU Discovery for Datagram Transports 12 draft-ietf-tsvwg-datagram-plpmtud-08 14 Abstract 16 This document describes a robust method for Path MTU Discovery 17 (PMTUD) for datagram Packetization Layers (PLs). It describes an 18 extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path 19 MTU Discovery for IPv4 and IPv6. The method allows a PL, or a 20 datagram application that uses a PL, to discover whether a network 21 path can support the current size of datagram. This can be used to 22 detect and reduce the message size when a sender encounters a network 23 black hole (where packets are discarded). The method can probe a 24 network path with progressively larger packets to discover whether 25 the maximum packet size can be increased. This allows a sender to 26 determine an appropriate packet size, providing functionally for 27 datagram transports that is equivalent to the Packetization Layer 28 PMTUD specification for TCP, specified in RFC 4821. 30 The document also provides implementation notes for incorporating 31 Datagram PMTUD into IETF datagram transports or applications that use 32 datagram transports. 34 When published, this specification updates RFC 4821. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 7 December 2019. 53 Copyright Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Simplified BSD License text 64 as described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Classical Path MTU Discovery . . . . . . . . . . . . . . 4 71 1.2. Packetization Layer Path MTU Discovery . . . . . . . . . 6 72 1.3. Path MTU Discovery for Datagram Services . . . . . . . . 7 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 10 75 4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 12 76 4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 12 77 4.2. Confirmation of Probed Packet Size . . . . . . . . . . . 14 78 4.3. Detection of Unsupported PLPMTU Size, aka Black Hole 79 Detection . . . . . . . . . . . . . . . . . . . . . . . . 14 80 4.4. Response to PTB Messages . . . . . . . . . . . . . . . . 15 81 4.4.1. Validation of PTB Messages . . . . . . . . . . . . . 15 82 4.4.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 16 83 5. Datagram Packetization Layer PMTUD . . . . . . . . . . . . . 17 84 5.1. DPLPMTUD Components . . . . . . . . . . . . . . . . . . . 18 85 5.1.1. Timers . . . . . . . . . . . . . . . . . . . . . . . 18 86 5.1.2. Constants . . . . . . . . . . . . . . . . . . . . . . 19 87 5.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 20 88 5.1.4. Overview of DPLPMTUD Phases . . . . . . . . . . . . . 21 89 5.2. State Machine . . . . . . . . . . . . . . . . . . . . . . 23 90 5.3. Search to Increase the PLPMTU . . . . . . . . . . . . . . 26 91 5.3.1. Probing for a larger PLPMTU . . . . . . . . . . . . . 26 92 5.3.2. Selection of Probe Sizes . . . . . . . . . . . . . . 27 93 5.3.3. Resilience to Inconsistent Path Information . . . . . 27 94 5.4. Robustness to Inconsistent Paths . . . . . . . . . . . . 28 95 6. Specification of Protocol-Specific Methods . . . . . . . . . 28 96 6.1. Application support for DPLPMTUD with UDP or 97 UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . 28 98 6.1.1. Application Request . . . . . . . . . . . . . . . . . 29 99 6.1.2. Application Response . . . . . . . . . . . . . . . . 29 100 6.1.3. Sending Application Probe Packets . . . . . . . . . . 29 101 6.1.4. Validating the Path . . . . . . . . . . . . . . . . . 29 102 6.1.5. Handling of PTB Messages . . . . . . . . . . . . . . 29 103 6.2. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 30 104 6.2.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 30 105 6.2.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 31 106 6.2.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 31 107 6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 32 108 6.3.1. Sending QUIC Probe Packets . . . . . . . . . . . . . 32 109 6.3.2. Validating the Path with QUIC . . . . . . . . . . . . 33 110 6.3.3. Handling of PTB Messages by QUIC . . . . . . . . . . 33 111 6.4. DPLPMTUD for UDP-Options . . . . . . . . . . . . . . . . 33 112 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 113 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 114 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 115 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 116 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 117 10.2. Informative References . . . . . . . . . . . . . . . . . 36 118 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 37 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 121 1. Introduction 123 The IETF has specified datagram transport using UDP, SCTP, and DCCP, 124 as well as protocols layered on top of these transports (e.g., SCTP/ 125 UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP 126 network layer. This document describes a robust method for Path MTU 127 Discovery (PMTUD) that may be used with these transport protocols (or 128 the applications that use their transport service) to discover an 129 appropriate size of packet to use across an Internet path. 131 1.1. Classical Path MTU Discovery 133 Classical Path Maximum Transmission Unit Discovery (PMTUD) can be 134 used with any transport that is able to process ICMP Packet Too Big 135 (PTB) messages (e.g., [RFC1191] and [RFC8201]). In this document, 136 the term PTB message is applied to both IPv4 ICMP Unreachable 137 messages (type 3) that carry the error Fragmentation Needed (Type 3, 138 Code 4) [RFC0792] and ICMPv6 packet too big messages (Type 2) 139 [RFC4443]. When a sender receives a PTB message, it reduces the 140 effective MTU to the value reported as the Link MTU in the PTB 141 message, and a method that from time-to-time increases the packet 142 size in attempt to discover an increase in the supported PMTU. The 143 packets sent with a size larger than the current effective PMTU are 144 known as probe packets. 146 Packets not intended as probe packets are either fragmented to the 147 current effective PMTU, or the attempt to send fails with an error 148 code. Applications are sometimes provided with a primitive to let 149 them read the Maximum Packet Size (MPS), derived from the current 150 effective PMTU. 152 Classical PMTUD is subject to protocol failures. One failure arises 153 when traffic using a packet size larger than the actual PMTU is 154 black-holed (all datagrams sent with this size, or larger, are 155 discarded). This could arise when the PTB messages are not delivered 156 back to the sender for some reason (see for example [RFC2923]). 158 Examples where PTB messages are not delivered include: 160 * The generation of ICMP messages is usually rate limited. This 161 could result in no PTB messages being generated to the sender (see 162 section 2.4 of [RFC4443]) 164 * ICMP messages can be filtered by middleboxes (including firewalls) 165 [RFC4890]. A stateful firewall could be configured with a policy 166 to block incoming ICMP messages, which would prevent reception of 167 PTB messages to a sending endpoint behind this firewall. 169 * When the router issuing the ICMP message drops a tunneled packet, 170 the resulting ICMP message will be directed to the tunnel ingress. 171 This tunnel endpoint is responsible for forwarding the ICMP 172 message and also processing the quoted packet within the payload 173 field to remove the effect of the tunnel, and return a correctly 174 formatted ICMP message to the sender [I-D.ietf-intarea-tunnels]. 175 Failure to do this prevents the PTB message reaching the original 176 sender. 178 * Asymmetry in forwarding can result in there being no return route 179 to the original sender, which would prevent an ICMP message being 180 delivered to the sender. This issue can also arise when policy- 181 based routing is used, Equal Cost Multipath (ECMP) routing is 182 used, or a middlebox acts as an application load balancer. An 183 example is where the path towards the server is chosen by ECMP 184 routing depending on bytes in the IP payload. In this case, when 185 a packet sent by the server encounters a problem after the ECMP 186 router, then any resulting ICMP message needs to also be directed 187 by the ECMP router towards the original sender. 189 * There are additional cases where the next hop destination fails to 190 receive a packet because of its size. This could be due to 191 misconfiguration of the layer 2 path between nodes, for instance 192 the MTU configured in a layer 2 switch, or misconfiguration of the 193 Maximum Receive Unit (MRU). If the packet is dropped by the link, 194 this will not cause a PTB message to be sent to the original 195 sender. 197 Another failure could result if a node that is not on the network 198 path sends a PTB message that attempts to force a sender to change 199 the effective PMTU [RFC8201]. A sender can protect itself from 200 reacting to such messages by utilising the quoted packet within a PTB 201 message payload to validate that the received PTB message was 202 generated in response to a packet that had actually originated from 203 the sender. However, there are situations where a sender would be 204 unable to provide this validation. Examples where validation of the 205 PTB message is not possible include: 207 * When a router issuing the ICMP message implements RFC792 208 [RFC0792], it is only required to include the first 64 bits of the 209 IP payload of the packet within the quoted payload. There could 210 be insufficient bytes remaining for the sender to interpret the 211 quoted transport information. 213 Note: The recommendation in RFC1812 [RFC1812] is that IPv4 routers 214 return a quoted packet with as much of the original datagram as 215 possible without the length of the ICMP datagram exceeding 576 216 bytes. IPv6 routers include as much of the invoking packet as 217 possible without the ICMPv6 packet exceeding 1280 bytes [RFC4443]. 219 * The use of tunnels/encryption can reduce the size of the quoted 220 packet returned to the original source address, increasing the 221 risk that there could be insufficient bytes remaining for the 222 sender to interpret the quoted transport information. 224 * Even when the PTB message includes sufficient bytes of the quoted 225 packet, the network layer could lack sufficient context to 226 validate the message, because validation depends on information 227 about the active transport flows at an endpoint node (e.g., the 228 socket/address pairs being used, and other protocol header 229 information). 231 * When a packet is encapsulated/tunneled over an encrypted 232 transport, the tunnel/encapsulation ingress might have 233 insufficient context, or computational power, to reconstruct the 234 transport header that would be needed to perform validation. 236 1.2. Packetization Layer Path MTU Discovery 238 The term Packetization Layer (PL) has been introduced to describe the 239 layer that is responsible for placing data blocks into the payload of 240 IP packets and selecting an appropriate MPS. This function is often 241 performed by a transport protocol, but can also be performed by other 242 encapsulation methods working above the transport layer. 244 In contrast to PMTUD, Packetization Layer Path MTU Discovery 245 (PLPMTUD) [RFC4821] does not rely upon reception and validation of 246 PTB messages. It is therefore more robust than Classical PMTUD. 247 This has become the recommended approach for implementing PMTU 248 discovery with TCP. 250 It uses a general strategy where the PL sends probe packets to search 251 for the largest size of unfragmented datagram that can be sent over a 252 network path. Probe packets are sent with a progressively larger 253 packet size. If a probe packet is successfully delivered (as 254 determined by the PL), then the PLPMTU is raised to the size of the 255 successful probe. If no response is received to a probe packet, the 256 method reduces the probe size. The result of probing with the PLPMTU 257 is used to set the application MPS. 259 PLPMTUD introduces flexibility in the implementation of PMTU 260 discovery. At one extreme, it can be configured to only perform ICMP 261 black Hole Detection and recovery to increase the robustness of 262 Classical PMTUD, or at the other extreme, all PTB processing can be 263 disabled and PLPMTUD can completely replace Classical PMTUD. 265 PLPMTUD can also include additional consistency checks without 266 increasing the risk that data is lost when probing to discover the 267 path MTU. For example, information available at the PL, or higher 268 layers, enables received PTB messages to be validated before being 269 utilized. 271 1.3. Path MTU Discovery for Datagram Services 273 Section 5 of this document presents a set of algorithms for datagram 274 protocols to discover the largest size of unfragmented datagram that 275 can be sent over a network path. The method described relies on 276 features of the PL described in Section 3 and applies to transport 277 protocols operating over IPv4 and IPv6. It does not require 278 cooperation from the lower layers, although it can utilize PTB 279 messages when these received messages are made available to the PL. 281 The UDP Usage Guidelines [RFC8085] state "an application SHOULD 282 either use the Path MTU information provided by the IP layer or 283 implement Path MTU Discovery (PMTUD)", but does not provide a 284 mechanism for discovering the largest size of unfragmented datagram 285 that can be used on a network path. Prior to this document, PLPMTUD 286 had not been specified for UDP. 288 Section 10.2 of [RFC4821] recommends a PLPMTUD probing method for the 289 Stream Control Transport Protocol (SCTP). SCTP utilizes probe 290 packets consisting of a minimal sized HEARTBEAT chunk bundled with a 291 PAD chunk as defined in [RFC4820], but RFC4821 does not provide a 292 complete specification. The present document provides the details to 293 complete that specification. 295 The Datagram Congestion Control Protocol (DCCP) [RFC4340] requires 296 implementations to support Classical PMTUD and states that a DCCP 297 sender "MUST maintain the MPS allowed for each active DCCP session". 298 It also defines the current congestion control MPS (CCMPS) supported 299 by a network path. This recommends use of PMTUD, and suggests use of 300 control packets (DCCP-Sync) as path probe packets, because they do 301 not risk application data loss. The method defined in this 302 specification could be used with DCCP. 304 Section 6 specifies the method for a set of transports, and provides 305 information to enable the implementation of PLPMTUD with other 306 datagram transports and applications that use datagram transports. 308 2. Terminology 310 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 311 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 312 "OPTIONAL" in this document are to be interpreted as described in BCP 313 14 [RFC2119] [RFC8174] when, and only when, they appear in all 314 capitals, as shown here. 316 Other terminology is directly copied from [RFC4821], and the 317 definitions in [RFC1122]. 319 Actual PMTU: The Actual PMTU is the PMTU of a network path between a 320 sender PL and a destination PL, which the DPLPMTUD algorithm seeks 321 to determine. 323 Black Hole: A Black Hole is encountered when a sender is unaware 324 that packets are not being delivered to the destination end point. 325 Two types of Black Hole are relevant to DPLPMTUD: 327 Packet Black Hole: Packets encounter a Packet Black Hole when 328 packets are not delivered to the destination 329 endpoint (e.g., when the sender transmits 330 packets of a particular size with a previously 331 known effective PMTU and they are discarded by 332 the network). 334 ICMP Black Hole An ICMP Black Hole is encountered when the 335 sender is unaware that packets are not 336 delivered to the destination endpoint because 337 PTB messages are not received by the 338 originating PL sender. 340 Black holed : Traffic is black-holed when the sender is unaware that 341 packets are not being delivered. This could be due to a Packet 342 Black Hole or an ICMP Black Hole. 344 Classical Path MTU Discovery: Classical PMTUD is a process described 345 in [RFC1191] and [RFC8201], in which nodes rely on PTB messages to 346 learn the largest size of unfragmented datagram that can be used 347 across a network path. 349 Datagram: A datagram is a transport-layer protocol data unit, 350 transmitted in the payload of an IP packet. 352 Effective PMTU: The Effective PMTU is the current estimated value 353 for PMTU that is used by a PMTUD. This is equivalent to the 354 PLPMTU derived by PLPMTUD. 356 EMTU_S: The Effective MTU for sending (EMTU_S) is defined in 357 [RFC1122] as "the maximum IP datagram size that may be sent, for a 358 particular combination of IP source and destination addresses...". 360 EMTU_R: The Effective MTU for receiving (EMTU_R) is designated in 361 [RFC1122] as the largest datagram size that can be reassembled by 362 EMTU_R (Effective MTU to receive). 364 Link: A Link is a communication facility or medium over which nodes 365 can communicate at the link layer, i.e., a layer below the IP 366 layer. Examples are Ethernet LANs and Internet (or higher) layer 367 and tunnels. 369 Link MTU: The Link Maximum Transmission Unit (MTU) is the size in 370 bytes of the largest IP packet, including the IP header and 371 payload, that can be transmitted over a link. Note that this 372 could more properly be called the IP MTU, to be consistent with 373 how other standards organizations use the acronym. This includes 374 the IP header, but excludes link layer headers and other framing 375 that is not part of IP or the IP payload. Other standards 376 organizations generally define the link MTU to include the link 377 layer headers. 379 MAX_PMTU: The MAX_PMTU is the largest size of PLPMTU that DPLPMTUD 380 will attempt to use. 382 MPS: The Maximum Packet Size (MPS) is the largest size of 383 application data block that can be sent across a network path by a 384 PL. In DPLPMTUD this quantity is derived from the PLPMTU by 385 taking into consideration the size of the lower protocol layer 386 headers. Probe packets generated by DPLPMTUD can have a size 387 larger than the MPS. 389 MIN_PMTU: The MIN_PMTU is the smallest size of PLPMTU that DPLPMTUD 390 will attempt to use. 392 Packet: A Packet is the IP header plus the IP payload. 394 Packetization Layer (PL): The Packetization Layer (PL) is the layer 395 of the network stack that places data into packets and performs 396 transport protocol functions. 398 Path: The Path is the set of links and routers traversed by a packet 399 between a source node and a destination node by a particular flow. 401 Path MTU (PMTU): The Path MTU (PMTU) is the minimum of the Link MTU 402 of all the links forming a network path between a source node and 403 a destination node. 405 PTB_SIZE: The PTB_SIZE is a value reported in a validated PTB 406 message that indicates next hop link MTU of a router along the 407 path. 409 PLPMTU: The Packetization Layer PMTU is an estimate of the actual 410 PMTU provided by the DPLPMTUD algorithm. 412 PLPMTUD: Packetization Layer Path MTU Discovery (PLPMTUD), the 413 method described in this document for datagram PLs, which is an 414 extension to Classical PMTU Discovery. 416 Probe packet: A probe packet is a datagram sent with a purposely 417 chosen size (typically the current PLPMTU or larger) to detect if 418 packets of this size can be successfully sent end-to-end across 419 the network path. 421 3. Features Required to Provide Datagram PLPMTUD 423 TCP PLPMTUD has been defined using standard TCP protocol mechanisms. 424 All of the requirements in [RFC4821] also apply to the use of the 425 technique with a datagram PL. Unlike TCP, some datagram PLs require 426 additional mechanisms to implement PLPMTUD. 428 There are eight requirements for performing the datagram PLPMTUD 429 method described in this specification: 431 1. PMTU parameters: A DPLPMTUD sender is RECOMMENDED to provide 432 information about the maximum size of packet that can be 433 transmitted by the sender on the local link (the local Link MTU). 434 It MAY utilize similar information about the receiver when this 435 is supplied (note this could be less than EMTU_R). This avoids 436 implementations trying to send probe packets that can not be 437 transmitted by the local link. Too high of a value could reduce 438 the efficiency of the search algorithm. Some applications also 439 have a maximum transport protocol data unit (PDU) size, in which 440 case there is no benefit from probing for a size larger than this 441 (unless a transport allows multiplexing multiple applications 442 PDUs into the same datagram). 444 2. PLPMTU: A datagram application using a PL not supporting 445 fragmentation is REQUIRED to be able to choose the size of 446 datagrams sent to the network, up to the PLPMTU, or a smaller 447 value (such as the MPS) derived from this. This value is managed 448 by the DPLPMTUD method. The PLPMTU (specified as the effective 449 PMTU in Section 1 of [RFC1191]) is equivalent to the EMTU_S 450 (specified in [RFC1122]). 452 3. Probe packets: On request, a DPLPMTUD sender is REQUIRED to be 453 able to transmit a packet larger than the PLMPMTU. This is used 454 to send a probe packet. In IPv4, a probe packet MUST be sent 455 with the Don't Fragment (DF) bit set in the IP header, and 456 without network layer endpoint fragmentation. In IPv6, a probe 457 packet is always sent without source fragmentation (as specified 458 in section 5.4 of [RFC8201]). 460 4. Processing PTB messages: A DPLPMTUD sender MAY optionally utilize 461 PTB messages received from the network layer to help identify 462 when a network path does not support the current size of probe 463 packet. Any received PTB message MUST be validated before it is 464 used to update the PLPMTU discovery information [RFC8201]. This 465 validation confirms that the PTB message was sent in response to 466 a packet originating by the sender, and needs to be performed 467 before the PLPMTU discovery method reacts to the PTB message. A 468 PTB message MUST NOT be used to increase the PLPMTU [RFC8201]. 470 5. Reception feedback: The destination PL endpoint is REQUIRED to 471 provide a feedback method that indicates to the DPLPMTUD sender 472 when a probe packet has been received by the destination PL 473 endpoint. The mechanism needs to be robust to the possibility 474 that packets could be significantly delayed along a network path. 475 The local PL endpoint at the sending node is REQUIRED to pass 476 this feedback to the sender DPLPMTUD method. 478 6. Probe loss recovery: It is RECOMMENDED to use probe packets that 479 do not carry any user data. Most datagram transports permit 480 this. If a probe packet contains user data requiring 481 retransmission in case of loss, the PL (or layers above) are 482 REQUIRED to arrange any retransmission/repair of any resulting 483 loss. DPLPMTUD is REQUIRED to be robust in the case where probe 484 packets are lost due to other reasons (including link 485 transmission error, congestion). 487 7. Probing and congestion control: The DPLPMTUD sender treats 488 isolated loss of a probe packet (with or without a corresponding 489 PTB message) as a potential indication of a PMTU limit for the 490 path. Loss of a probe packet SHOULD NOT be treated as an 491 indication of congestion and the loss SHOULD NOT directly trigger 492 a congestion control reaction [RFC4821]. 494 8. Shared PLPMTU state: The PLPMTU value could also be stored with 495 the corresponding entry in the destination cache and used by 496 other PL instances. The specification of PLPMTUD [RFC4821] 497 states: "If PLPMTUD updates the MTU for a particular path, all 498 Packetization Layer sessions that share the path representation 499 (as described in Section 5.2 of [RFC4821]) SHOULD be notified to 500 make use of the new MTU". Such methods MUST be robust to the 501 wide variety of underlying network forwarding behaviors, PLPMTU 502 adjustments based on shared PLPMTU values should be incorporated 503 in the search algorithms. Section 5.2 of [RFC8201] provides 504 guidance on the caching of PMTU information and also the relation 505 to IPv6 flow labels. 507 In addition, the following principles are stated for design of a 508 DPLPMTUD method: 510 * MPS: A method is REQUIRED to signal an appropriate MPS to the 511 higher layer using the PL. The value of the MPS can change 512 following a change to the path. It is RECOMMENDED that methods 513 avoid forcing an application to use an arbitrary small MPS 514 (PLPMTU) for transmission while the method is searching for the 515 currently supported PLPMTU. Datagram PLs do not necessarily 516 support fragmentation of PDUs larger than the PLPMTU. A reduced 517 MPS can adversely impact the performance of a datagram 518 application. 520 * Path validation: It is RECOMMENDED that methods are robust to path 521 changes that could have occurred since the path characteristics 522 were last confirmed, and to the possibility of inconsistent path 523 information being received. 525 * Datagram reordering: A method is REQUIRED to be robust to the 526 possibility that a flow encounters reordering, or the traffic 527 (including probe packets) is divided over more than one network 528 path. 530 * When to probe: It is RECOMMENDED that methods determine whether 531 the path has changed since it last measured the path. This can 532 help determine when to probe the path again. 534 4. DPLPMTUD Mechanisms 536 This section lists the protocol mechanisms used in this 537 specification. 539 4.1. PLPMTU Probe Packets 541 The DPLPMTUD method relies upon the PL sender being able to generate 542 probe packets with a specific size. TCP is able to generate these 543 probe packets by choosing to appropriately segment data being sent 544 [RFC4821]. In contrast, a datagram PL that needs to construct a 545 probe packet has to either request an application to send a data 546 block that is larger than that generated by an application, or to 547 utilize padding functions to extend a datagram beyond the size of the 548 application data block. Protocols that permit exchange of control 549 messages (without an application data block) could alternatively 550 prefer to generate a probe packet by extending a control message with 551 padding data. 553 A receiver needs to be able to distinguish an in-band data block from 554 any added padding. This is needed to ensure that any added padding 555 is not passed on to an application at the receiver. 557 This results in three possible ways that a sender can create a probe 558 packet listed in order of preference: 560 Probing using padding data: A probe packet that contains only 561 control information together with any padding, which is needed to 562 be inflated to the size required for the probe packet. Since 563 these probe packets do not carry an application-supplied data 564 block, they do not typically require retransmission, although they 565 do still consume network capacity and incur endpoint processing. 567 Probing using application data and padding 568 data: A probe packet that 569 contains a data block supplied by an application that is combined 570 with padding to inflate the length of the datagram to the size 571 required for the probe packet. If the application/transport needs 572 protection from the loss of this probe packet, the application/ 573 transport could perform transport-layer retransmission/repair of 574 the data block (e.g., by retransmission after loss is detected or 575 by duplicating the data block in a datagram without the padding 576 data). 578 Probing using application data: A probe packet that contains a data 579 block supplied by an application that matches the size required 580 for the probe packet. This method requests the application to 581 issue a data block of the desired probe size. If the application/ 582 transport needs protection from the loss of an unsuccessful probe 583 packet, the application/transport needs then to perform transport- 584 layer retransmission/repair of the data block (e.g., by 585 retransmission after loss is detected). 587 A PL that uses a probe packet carrying an application data block, 588 could need to retransmit this application data block if the probe 589 fails. This could need the PL to re-fragment the data block to a 590 smaller packet size that is expected to traverse the end-to-end path 591 (which could utilize endpoint network-layer or PL fragmentation when 592 these are available). 594 DPLPMTUD MAY choose to use only one of these methods to simplify the 595 implementation. 597 Probe messages sent by a PL MUST contain enough information to 598 uniquely identify the probe within Maximum Segment Lifetime, while 599 being robust to reordering and replay of probe response and PTB 600 messages. 602 4.2. Confirmation of Probed Packet Size 604 The PL needs a method to determine (confirm) when probe packets have 605 been successfully received end-to-end across a network path. 607 Transport protocols can include end-to-end methods that detect and 608 report reception of specific datagrams that they send (e.g., DCCP and 609 SCTP provide keep-alive/heartbeat features). When supported, this 610 mechanism SHOULD also be used by DPLPMTUD to acknowledge reception of 611 a probe packet. 613 A PL that does not acknowledge data reception (e.g., UDP and UDP- 614 Lite) is unable itself to detect when the packets that it sends are 615 discarded because their size is greater than the actual PMTU. These 616 PLs need to either rely on an application protocol to detect this 617 loss, or make use of an additional transport method such as UDP- 618 Options [I-D.ietf-tsvwg-udp-options]. 620 Section 6 specifies this function for a set of IETF-specified 621 protocols. 623 4.3. Detection of Unsupported PLPMTU Size, aka Black Hole Detection 625 A PL sender needs to reduce the PLPMTU when it discovers the actual 626 PMTU supported by a network path is less than the PLPMTU. This can 627 be triggered when a validated PTB message is received, or by another 628 event that indicates the network path no longer sustains the current 629 packet size, such as a loss report from the PL, or repeated lack of 630 response to probe packets sent to confirm the PLPMTU. Detection is 631 followed by a reduction of the PLPMTU. 633 This is performed by sending packet probes of size PLPMTU to verify 634 that a network path still supports the last acknowledged PLPMTU size. 635 There are two alternative mechanism: 637 * A PL can rely upon a mechanism implemented within the PL to detect 638 excessive loss of data sent with a specific packet size and then 639 conclude that this excessive loss could be a result of an invalid 640 PMTU (as in PLPMTUD for TCP [RFC4821]). 642 * A PL can use the DPLPMTUD probing mechanism to periodically 643 generate probe packets of the size of the current PLPMTU (e.g., 644 using the confirmation timer Section 5.1.1). A timer tracks 645 whether acknowledgments are received. Successive loss of probes 646 is an indication that the current path no longer supports the 647 PLPMTU (e.g., when the number of probe packets sent without 648 receiving an acknowledgement, PROBE_COUNT, becomes greater than 649 MAX_PROBES). 651 A PL MAY inhibit sending probe packets when no application data has 652 been sent since the previous probe packet. A PL preferring to use an 653 up-to-data PLPMTU once user data is sent again, MAY choose to 654 continue PLPMTU discovery for each path. However, this may result in 655 additional packets being sent. 657 When the method detects the current PLPMTU is not supported, DPLPMTUD 658 sets a lower MPS. The PL then confirms that the updated PLPMTU can 659 be successfully used across the path. The PL could need to send a 660 probe packet with a size less than the size of the data block 661 generated by an application. In this case, the PL could provide a 662 way to fragment a datagram at the PL, or use a control packet as the 663 packet probe. 665 4.4. Response to PTB Messages 667 This method requires the DPLPMTUD sender to validate any received PTB 668 message before using the PTB information. The response to a PTB 669 message depends on the PTB_SIZE indicated in the PTB message, the 670 state of the PLPMTUD state machine, and the IP protocol being used. 672 Section 4.4.1 first describes validation for both IPv4 ICMP 673 Unreachable messages (type 3) and ICMPv6 packet too big messages, 674 both of which are referred to as PTB messages in this document. 676 4.4.1. Validation of PTB Messages 678 This section specifies utilization of PTB messages. 680 * A simple implementation MAY ignore received PTB messages and in 681 this case the PLPMTU is not updated when a PTB message is 682 received. 684 * An implementation that supports PTB messages MUST validate 685 messages before they are further processed. 687 A PL that receives a PTB message from a router or middlebox, performs 688 ICMP validation as specified in Section 5.2 of [RFC8085][RFC8201]. 689 Because DPLPMTUD operates at the PL, the PL needs to check that each 690 received PTB message is received in response to a packet transmitted 691 by the endpoint PL performing DPLPMTUD. 693 The PL MUST check the protocol information in the quoted packet 694 carried in an ICMP PTB message payload to validate the message 695 originated from the sending node. This validation includes 696 determining that the combination of the IP addresses, the protocol, 697 the source port and destination port match those returned in the 698 quoted packet - this is also necessary for the PTB message to be 699 passed to the corresponding PL. 701 The validation SHOULD utilize information that it is not simple for 702 an off-path attacker to determine [RFC8085]. For example, by 703 checking the value of a protocol header field known only to the two 704 PL endpoints. A datagram application that uses well-known source and 705 destination ports ought to also rely on other information to complete 706 this validation. 708 These checks are intended to provide protection from packets that 709 originate from a node that is not on the network path. A PTB message 710 that does not complete the validation MUST NOT be further utilized by 711 the DPLPMTUD method. 713 PTB messages that have been validated MAY be utilized by the DPLPMTUD 714 algorithm, but MUST NOT be used directly to set the PLPMTU. A method 715 that utilizes these PTB messages can improve the speed at the which 716 the algorithm detects an appropriate PLPMTU, compared to one that 717 relies solely on probing. Section 4.4.2 describes this processing. 719 4.4.2. Use of PTB Messages 721 A set of checks are intended to provide protection from a router that 722 reports an unexpected PTB_SIZE. The PL also needs to check that the 723 indicated PTB_SIZE is less than the size used by probe packets and 724 larger than minimum size accepted. 726 This section provides a summary of how PTB messages can be utilized. 727 This processing depends on the PTB_SIZE and the current value of a 728 set of variables: 730 MIN_PMTU < PTB_SIZE < BASE_PMTU 731 * A robust PL MAY enter an error state (see Section 5.2) for an 732 IPv4 path when the PTB_SIZE reported in the PTB message is 733 larger than or equal to 68 bytes and when this is less than the 734 BASE_PMTU. 736 * A robust PL MAY enter an error state (see Section 5.2) for an 737 IPv6 path when the PTB_SIZE reported in the PTB message is 738 larger than or equal to 1280 bytes and when this is less than 739 the BASE_PMTU. 741 PTB_SIZE = PLPMTU 742 * Completes the search for a larger PLPMTU. 744 PTB_SIZE > PROBED_SIZE 745 * Inconsistent network signal. 747 * PTB message ought to be discarded without further processing 748 (e. g. PLPMTU not modified). 750 * The information could be utilized as an input to trigger 751 enabling a resilience mode. 753 BASE_PMTU <= PTB_SIZE < PLPMTU 754 * Black Hole Detection is triggered and the PLPMTU ought to be 755 set to BASE_PMTU. 757 * The PL could use the PTB_SIZE reported in the PTB message to 758 initialize a search algorithm. 760 PLPMTU < PTB_SIZE < PROBED_SIZE 761 * The PLPMTU continues to be valid, but the last PROBED_SIZE 762 searched was larger than the actual PMTU. 764 * The PLPMTU is not updated. 766 * The PL can use the reported PTB_SIZE from the PTB message as 767 the next search point when it resumes the search algorithm. 769 xxx Author Note: Do we want to specify how to handle PTB Message with 770 PTB_SIZE = 0? xxx 772 5. Datagram Packetization Layer PMTUD 774 This section specifies Datagram PLPMTUD (DPLPMTUD). The method can 775 be introduced at various points (as indicated with * in the figure 776 below) in the IP protocol stack to discover the PLPMTU so that an 777 application can utilize an appropriate MPS for the current network 778 path. DPLPMTUD SHOULD NOT be used by an application if it is already 779 used in a lower layer. 781 +----------------------+ 782 | Application* | 783 +-+-------+----+----+--+ 784 | | | | 785 +---+--+ +--+--+ | +-+---+ 786 | QUIC*| |UDPO*| | |SCTP*| 787 +---+--+ +--+--+ | +--+--+ 788 | | | | | 789 +-------+--+ | | | 790 | | | | 791 +-+-+--+ | 792 | UDP | | 793 +---+--+ | 794 | | 795 +--------------+-----+-+ 796 | Network Interface | 797 +----------------------+ 799 Figure 1: Examples where DPLPMTUD can be implemented 801 The central idea of DPLPMTUD is probing by a sender. Probe packets 802 are sent to find the maximum size of a user message that can be 803 completely transferred across the network path from the sender to the 804 destination. 806 The folloowing sections identify the components needed for 807 implementation, provides an overvoew of the phases of operation, and 808 specifies the state machine and search algorithm. 810 5.1. DPLPMTUD Components 812 This section describes the timers, constants, and variables of 813 DPLPMTUD. 815 5.1.1. Timers 817 The method utilizes up to three timers: 819 PROBE_TIMER: The PROBE_TIMER is configured to expire after a 820 period longer than the maximum time to receive 821 an acknowledgment to a probe packet. This value 822 MUST NOT be smaller than 1 second, and SHOULD be 823 larger than 15 seconds. Guidance on selection 824 of the timer value are provided in section 3.1.1 825 of the UDP Usage Guidelines [RFC8085]. 827 If the PL has a path Round Trip Time (RTT) 828 estimate and timely acknowledgements the 829 PROBE_TIMER can be derived from the PL RTT 830 estimate. 832 PMTU_RAISE_TIMER: The PMTU_RAISE_TIMER is configured to the period 833 a sender will continue to use the current 834 PLPMTU, after which it re-enters the Search 835 phase. This timer has a period of 600 secs, as 836 recommended by PLPMTUD [RFC4821]. 838 DPLPMTUD MAY inhibit sending probe packets when 839 no application data has been sent since the 840 previous probe packet. A PL preferring to use 841 an up-to-data PMTU once user data is sent again, 842 can choose to continue PMTU discovery for each 843 path. However, this may result in sending 844 additional packets. 846 CONFIRMATION_TIMER: When an acknowledged PL is used, this timer MUST 847 NOT be used. For other PLs, the 848 CONFIRMATION_TIMER is configured to the period a 849 PL sender waits before confirming the current 850 PLPMTU is still supported. This is less than 851 the PMTU_RAISE_TIMER and used to decrease the 852 PLPMTU (e.g., when a black hole is encountered). 853 Confirmation needs to be frequent enough when 854 data is flowing that the sending PL does not 855 black hole extensive amounts of traffic. 856 Guidance on selection of the timer value are 857 provided in section 3.1.1 of the UDP Usage 858 Guidelines [RFC8085]. 860 DPLPMTUD MAY inhibit sending probe packets when 861 no application data has been sent since the 862 previous probe packet. A PL preferring to use 863 an up-to-data PMTU once user data is sent again, 864 can choose to continue PMTU discovery for each 865 path. However, this may result in sending 866 additional packets. 868 An implementation could implement the various timers using a single 869 timer. 871 5.1.2. Constants 873 The following constants are defined: 875 MAX_PROBES: The MAX_PROBES is the maximum value of the PROBE_COUNT 876 counter (see Section 5.1.3). The default value of 877 MAX_PROBES is 10. 879 MIN_PMTU: The MIN_PMTU is the smallest allowed probe packet size. 880 For IPv6, this value is 1280 bytes, as specified in 881 [RFC2460]. For IPv4, the minimum value is 68 bytes. 883 Note: An IPv4 router is required to be able to forward a 884 datagram of 68 bytes without further fragmentation. 885 This is the combined size of an IPv4 header and the 886 minimum fragment size of 8 bytes. In addition, 887 receivers are required to be able to reassemble 888 fragmented datagrams at least up to 576 bytes, as stated 889 in section 3.3.3 of [RFC1122]. 891 MAX_PMTU: The MAX_PMTU is the largest size of PLPMTU. This has to 892 be less than or equal to the minimum of the local MTU of 893 the outgoing interface and the destination PMTU for 894 receiving. An application, or PL, MAY reduce the 895 MAX_PMTU when there is no need to send packets larger 896 than a specific size. 898 BASE_PMTU: The BASE_PMTU is a configured size expected to work for 899 most paths. The size is equal to or larger than the 900 MIN_PMTU and smaller than the MAX_PMTU. In the case of 901 IPv6, this value is 1280 bytes [RFC2460]. When using 902 IPv4, a size of 1200 bytes is RECOMMENDED. 904 5.1.3. Variables 906 This method utilizes a set of variables: 908 PROBED_SIZE: The PROBED_SIZE is the size of the current probe 909 packet. This is a tentative value for the PLPMTU, 910 which is awaiting confirmation by an acknowledgment. 912 PROBE_COUNT: The PROBE_COUNT is a count of the number of 913 unsuccessful probe packets that have been sent with a 914 size of PROBED_SIZE. The value is initialized to zero 915 when a particular size of PROBED_SIZE is first 916 attempted. 918 The figure below illustrates the relationship between the packet size 919 constants and variables at a point of time when the DPLPMTUD 920 algorithm performs path probing to increase the size of the PLPMTU. 921 A probe packet has been sent of size PROBED_SIZE. Once this is 922 acknowledged, the PLPMTU will raise to PROBED_SIZE allowing the 923 DPLPMTUD algorithm to further increase PROBED_SIZE towards the actual 924 PMTU. 926 MIN_PMTU MAX_PMTU 927 <--------------------------------------------------> 928 | | | | 929 v | | v 930 BASE_PMTU | v Actual PMTU 931 | PROBED_SIZE 932 v 933 PLPMTU 935 Figure 2: Relationships between packet size constants and variables 937 5.1.4. Overview of DPLPMTUD Phases 939 This section provides a high-level informative view of the DPLPMTUD 940 method, by describing the movement of the method through several 941 phases of operation. More detail is available in the state machine 942 Section 5.2. 944 +------+ 945 +------->| Base |----------------+ Connectivity 946 | +------+ | or BASE_PMTU 947 | | | confirmation failed 948 | | v 949 | | Connectivity +-------+ 950 | | and BASE_PMTU | Error | 951 | | confirmed +-------+ 952 | | | 953 | v | Consistent connectivity 954 PLPMTU | +--------+ | and BASE_PMTU 955 confirmation | | Search |<--------------+ confirmed 956 failed | +--------+ 957 | ^ | 958 | | | 959 | Raise | | Search 960 | timer | | algorithm 961 | expired | | completed 962 | | | 963 | | v 964 | +-----------------+ 965 +---| Search Complete | 966 +-----------------+ 968 Figure 3: DPLPMTUD Phases 970 BASE_PMTU Confirmation Phase 971 * The BASE_PMTU Confirmation Phase confirms connectivity to the 972 remote peer. This phase is implicit for a connection-oriented 973 PL (where it can be performed in a PL connection handshake). A 974 connectionless PL needs to send an acknowledged probe packet to 975 confirm that the remote peer is reachable. 977 * The sender also confirms that BASE_PMTU is supported across the 978 network path. 980 * A PL that does not wish to support a path with a PLPMTU less 981 than BASE_PMTU can simplify the phase into a single step by 982 performing the connectivity checks with a probe of the 983 BASE_PMTU size. 985 * Once confirmed, DPLPMTUD enters the Search Phase. If this 986 phase fails to confirm, DPLPMTUD enters the Error Phase. 988 Search Phase 989 * The Search Phase utilizes a search algorithm to send probe 990 packets to seek to increase the PLPMTU. 992 * The algorithm concludes when it has found a suitable PLPMTU, by 993 entering the Search Complete Phase. 995 * A PL could respond to PTB messages using the PTB to advance or 996 terminate the search, see Section 4.4. 998 * Black Hole Detection can also terminate the search by entering 999 the BASE_PMTU Confirmation phase. 1001 Search Complete Phase 1002 * The Search Complete Phase is entered when the PLPMTU is 1003 supported across the network path. 1005 * A PL can use a CONFIRMATION_TIMER to periodically repeat a 1006 probe packet for the current PLPMTU size. If the sender is 1007 unable to confirm reachability (e.g., if the CONFIRMATION_TIMER 1008 expires) or the PL signals a lack of reachability, DPLPMTUD 1009 enters the BASE_PMTU Confirmation phase. 1011 * The PMTU_RAISE_TIMER is used to periodically resume the search 1012 phase to discover if the PLPMTU can be raised. 1014 * Black Hole Detection or receipt of a validated PTB message 1015 Section 4.4.1) can cause the sender to enter the BASE_PMTU 1016 Confirmation Phase. 1018 Error Phase 1019 * The Error Phase is entered when there is conflicting or invalid 1020 PLPMTU information for the path (e.g. a failure to support the 1021 BASE_PMTU) that cause DPLPMTUD to be unable to progress and the 1022 PLPMTU is lowered 1024 * DPLPMTUD remains in the Error Phase until a consistent view of 1025 the path can be discovered and it has also been confirmed that 1026 the path supports the BASE_PMTU (or DPLPMTUD is suspended). 1028 * Note: MIN_PMTU may be identical to BASE_PMTU, simplifying the 1029 actions in this phase. 1031 An implementation that only reduces the PLPMTU to a suitable size 1032 would be sufficient to ensure reliable operation, but can be very 1033 inefficient when the actual PMTU changes or when the method (for 1034 whatever reason) makes a suboptimal choice for the PLPMTU. 1036 A full implementation of DPLPMTUD provides an algorithm enabling the 1037 DPLPMTUD sender to increase the PLPMTU following a change in the 1038 characteristics of the path, such as when a link is reconfigured with 1039 a larger MTU, or when there is a change in the set of links traversed 1040 by an end-to-end flow (e.g., after a routing or path fail-over 1041 decision). 1043 5.2. State Machine 1045 A state machine for DPLPMTUD is depicted in Figure 4. If multipath 1046 or multihoming is supported, a state machine is needed for each path. 1048 Note: Some state changes are not shown to simplify the diagram. 1050 | | 1051 | Start | PL indicates loss 1052 | | of connectivity 1053 v v 1054 +---------------+ +---------------+ 1055 | DISABLED | | ERROR | 1056 +---------------+ PROBE_TIMER expiry: +---------------+ 1057 | PL indicates PROBE_COUNT = MAX_PROBES or ^ | 1058 | connectivity PTB: PTB_SIZE < BASE_PMTU | | 1059 +--------------------+ +---------------+ | 1060 | | | 1061 v | BASE_PMTU Probe | 1062 +---------------+ acked | 1063 | BASE |----------------------+ 1064 +---------------+ | 1065 Black hole detected or ^ | ^ ^ Black hole detected or | 1066 PTB: PTB_SIZE < PLPMTU | | | | PTB: PTB_SIZE < PLPMTU | 1067 +--------------------+ | | +--------------------+ | 1068 | +----+ | | 1069 | PROBE_TIMER expiry: | | 1070 | PROBE_COUNT < MAX_PROBES | | 1071 | | | 1072 | PMTU_RAISE_TIMER expiry | | 1073 | +-----------------------------------------+ | | 1074 | | | | | 1075 | | v | v 1076 +---------------+ +---------------+ 1077 |SEARCH_COMPLETE| | SEARCHING | 1078 +---------------+ +---------------+ 1079 | ^ ^ | | ^ 1080 | | | | | | 1081 | | +-----------------------------------------+ | | 1082 | | MAX_PMTU Probe acked or PROBE_TIMER | | 1083 | | expiry: PROBE_COUNT = MAX_PROBES or | | 1084 +----+ PTB: PTB_SIZE = PLPMTU +----+ 1085 CONFIRMATION_TIMER expiry: PROBE_TIMER expiry: 1086 PROBE_COUNT < MAX_PROBES or PROBE_COUNT < MAX_PROBES or 1087 PLPMTU Probe acked Probe acked or PTB: 1088 PLPMTU < PTB_SIZE < PROBED_SIZE 1090 Figure 4: State machine for Datagram PLPMTUD 1092 The following states are defined: 1094 DISABLED: The DISABLED state is the initial state before 1095 probing has started. It is also entered from any 1096 other state, when the PL indicates loss of 1097 connectivity. This state is left, once the PL 1098 indicates connectivity to the remote PL. 1100 BASE: The BASE state is used to confirm that the 1101 BASE_PMTU size is supported by the network path and 1102 is designed to allow an application to continue 1103 working when there are transient reductions in the 1104 actual PMTU. It also seeks to avoid long periods 1105 where traffic is black holed while searching for a 1106 larger PLPMTU. 1108 On entry, the PROBED_SIZE is set to the BASE_PMTU 1109 size and the PROBE_COUNT is set to zero. 1111 Each time a probe packet is sent, the PROBE_TIMER 1112 is started. The state is exited when the probe 1113 packet is acknowledged, and the PL sender enters 1114 the SEARCHING state. 1116 The state is also left when the PROBE_COUNT reaches 1117 MAX_PROBES or a received PTB message is validated. 1118 This causes the PL sender to enter the ERROR state. 1120 SEARCHING: The SEARCHING state is the main probing state. 1121 This state is entered when probing for the 1122 BASE_PMTU was successful. 1124 The PROBE_COUNT is set to zero when the first probe 1125 packet is sent for each probe size. Each time a 1126 probe packet is acknowledged, the PLPMTU is set to 1127 the PROBED_SIZE, and then the PROBED_SIZE is 1128 increased using the search algorithm. 1130 When a probe packet is sent and not acknowledged 1131 within the period of the PROBE_TIMER, the 1132 PROBE_COUNT is incremented and the probe packet is 1133 retransmitted. The state is exited when the 1134 PROBE_COUNT reaches MAX_PROBES, a received PTB 1135 message is validated, a probe of size MAX_PMTU is 1136 acknowledged, or a black hole is detected. 1138 SEARCH_COMPLETE: The SEARCH_COMPLETE state indicates a successful 1139 end to the SEARCHING state. DPLPMTUD remains in 1140 this state until either the PMTU_RAISE_TIMER 1141 expires, a received PTB message is validated, or a 1142 black hole is detected. 1144 When DPLPMTUD uses an unacknowledged PL and is in 1145 the SEARCH_COMPLETE state, a CONFIRMATION_TIMER 1146 periodically resets the PROBE_COUNT and schedules a 1147 probe packet with the size of the PLPMTU. If the 1148 probe packet fails to be acknowledged after 1149 MAX_PROBES attempts, the method enters the BASE 1150 state. When used with an acknowledged PL (e.g., 1151 SCTP), DPLPMTUD SHOULD NOT continue to generate 1152 PLPMTU probes in this state. 1154 ERROR: The ERROR state represents the case where either 1155 the network path is not known to support a PLPMTU 1156 of at least the BASE_PMTU size or when there is 1157 contradictory information about the network path 1158 that would otherwise result in excessive variation 1159 in the MPS signalled to the higher layer. The 1160 state implements a method to mitigate oscillation 1161 in the state-event engine. It signals a 1162 conservative value of the MPS to the higher layer 1163 by the PL. The state is exited when packet probes 1164 no longer detect the error or when the PL indicates 1165 that connectivity has been lost. 1167 Implementations are permitted to enable endpoint 1168 fragmentation if the DPLPMTUD is unable to validate 1169 MIN_PMTU within PROBE_COUNT probes. If DPLPMTUD is 1170 unable to validate MIN_PMTU the implementation 1171 should transition to the DISABLED state. 1173 5.3. Search to Increase the PLPMTU 1175 This section describes the algorithms used by DPLPMTUD to search for 1176 a larger PLPMTU. 1178 5.3.1. Probing for a larger PLPMTU 1180 Implementations use a search algorithm across the search range to 1181 determine whether a larger PLPMTU can be supported across a network 1182 path. 1184 The method discovers the search range by confirming the minimum 1185 PLPMTU and then using the probe method to select a PROBED_SIZE less 1186 than or equal to MAX_PMTU. MAX_PMTU is the minimum of the local MTU 1187 and EMTU_R (learned from the remote endpoint). The MAX_PMTU MAY be 1188 reduced by an application that sets a maximum to the size of 1189 datagrams it will send. 1191 The PROBE_COUNT is initialized to zero when a probe packet is first 1192 sent with a particular size. A timer is used by the search algorithm 1193 to trigger the sending of probe packets of size PROBED_SIZE, larger 1194 than the PLPMTU. Each probe packet successfully sent to the remote 1195 peer is confirmed by acknowledgement at the PL, see Section 4.1. 1197 Each time a probe packet is sent to the destination, the PROBE_TIMER 1198 is started. The timer is canceled when the PL receives 1199 acknowledgment that the probe packet has been successfully sent 1200 across the path Section 4.1. This confirms that the PROBED_SIZE is 1201 supported, and the PROBED_SIZE value is then assigned to the PLPMTU. 1202 The search algorithm can continue to send subsequent probe packets of 1203 an increasing size. 1205 If the timer expires before a probe packet is acknowledged, the probe 1206 has failed to confirm the PROBED_SIZE. Each time the PROBE_TIMER 1207 expires, the PROBE_COUNT is incremented, the PROBE_TIMER is 1208 reinitialized, and a probe packet of the same size is retransmitted 1209 (the replicated probe improve the resilience to loss). The maximum 1210 number of retransmissions for a particular size is configured 1211 (MAX_PROBES). If the value of the PROBE_COUNT reaches MAX_PROBES, 1212 probing will stop, and the PL sender enters the SEARCH_COMPLETE 1213 state. 1215 5.3.2. Selection of Probe Sizes 1217 The search algorithm needs to determine a minimum useful gain in 1218 PLPMTU. It would not be constructive for a PL sender to attempt to 1219 probe for all sizes. This would incur unnecessary load on the path 1220 and has the undesirable effect of slowing the time to reach a more 1221 optimal MPS. Implementations SHOULD select the set of probe packet 1222 sizes to maximize the gain in PLPMTU from each search step. 1224 Implementations could optimize the search procedure by selecting step 1225 sizes from a table of common PMTU sizes. When selecting the 1226 appropriate next size to search, an implementor ought to also 1227 consider that there can be common sizes of MPS that applications seek 1228 to use, and their could be common sizes of MTU used within the 1229 network. 1231 5.3.3. Resilience to Inconsistent Path Information 1233 A decision to increase the PLPMTU needs to be resilient to the 1234 possibility that information learned about the network path is 1235 inconsistent. A path is inconsistent, when, for example, probe 1236 packets are lost due to other reasons (i. e. not packet size) or due 1237 to frequent path changes. Frequent path changes could occur by 1238 unexpected "flapping" - where some packets from a flow pass along one 1239 path, but other packets follow a different path with different 1240 properties. 1242 A PL sender is able to detect inconsistency from the sequence of 1243 PLPMTU probes that it sends or the sequence of PTB messages that it 1244 receives. When inconsistent path information is detected, a PL 1245 sender could use an alternate search mode that clamps the offered MPS 1246 to a smaller value for a period of time. This avoids unnecessary 1247 loss of packets due to MTU limitation. 1249 5.4. Robustness to Inconsistent Paths 1251 Some paths could be unable to sustain packets of the BASE_PMTU size. 1252 To be robust to these paths an implementation could implement the 1253 Error State. This allows fallback to a smaller than desired PLPMTU, 1254 rather than suffer connectivity failure. This could utilize methods 1255 such as endpoint IP fragmentation to enable the PL sender to 1256 communicate using packets smaller than the BASE_PMTU. 1258 6. Specification of Protocol-Specific Methods 1260 This section specifies protocol-specific details for datagram PLPMTUD 1261 for IETF-specified transports. 1263 The first subsection provides guidance on how to implement the 1264 DPLPMTUD method as a part of an application using UDP or UDP-Lite. 1265 The guidance also applies to other datagram services that do not 1266 include a specific transport protocol (such as a tunnel 1267 encapsulation). The following subsections describe how DPLPMTUD can 1268 be implemented as a part of the transport service, allowing 1269 applications using the service to benefit from discovery of the 1270 PLPMTU without themselves needing to implement this method. 1272 6.1. Application support for DPLPMTUD with UDP or UDP-Lite 1274 The current specifications of UDP [RFC0768] and UDP-Lite [RFC3828] do 1275 not define a method in the RFC-series that supports PLPMTUD. In 1276 particular, the UDP transport does not provide the transport layer 1277 features needed to implement datagram PLPMTUD. 1279 The DPLPMTUD method can be implemented as a part of an application 1280 built directly or indirectly on UDP or UDP-Lite, but relies on 1281 higher-layer protocol features to implement the method [RFC8085]. 1283 Some primitives used by DPLPMTUD might not be available via the 1284 Datagram API (e.g., the ability to access the PLPMTU cache, or 1285 interpret received PTB messages). 1287 In addition, it is desirable that PMTU discovery is not performed by 1288 multiple protocol layers. An application SHOULD avoid using DPLPMTUD 1289 when the underlying transport system provides this capability. To 1290 use common method for managing the PLPMTU has benefits, both in the 1291 ability to share state between different processes and opportunities 1292 to coordinate probing. 1294 6.1.1. Application Request 1296 An application needs an application-layer protocol mechanism (such as 1297 a message acknowledgement method) that solicits a response from a 1298 destination endpoint. The method SHOULD allow the sender to check 1299 the value returned in the response to provide additional protection 1300 from off-path insertion of data [RFC8085], suitable methods include a 1301 parameter known only to the two endpoints, such as a session ID or 1302 initialized sequence number. 1304 6.1.2. Application Response 1306 An application needs an application-layer protocol mechanism to 1307 communicate the response from the destination endpoint. This 1308 response may indicate successful reception of the probe across the 1309 path, but could also indicate that some (or all packets) have failed 1310 to reach the destination. 1312 6.1.3. Sending Application Probe Packets 1314 A probe packet that may carry an application data block, but the 1315 successful transmission of this data is at risk when used for 1316 probing. Some applications may prefer to use a probe packet that 1317 does not carry an application data block to avoid disruption to data 1318 transfer. 1320 6.1.4. Validating the Path 1322 An application that does not have other higher-layer information 1323 confirming correct delivery of datagrams SHOULD implement the 1324 CONFIRMATION_TIMER to periodically send probe packets while in the 1325 SEARCH_COMPLETE state. 1327 6.1.5. Handling of PTB Messages 1329 An application that is able and wishes to receive PTB messages MUST 1330 perform ICMP validation as specified in Section 5.2 of [RFC8085]. 1331 This requires that the application to check each received PTB 1332 messages to validate it is received in response to transmitted 1333 traffic and that the reported PTB_SIZE is less than the current 1334 probed size (see Section 4.4.2). A validated PTB message MAY be used 1335 as input to the DPLPMTUD algorithm, but MUST NOT be used directly to 1336 set the PLPMTU. 1338 6.2. DPLPMTUD for SCTP 1340 Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing 1341 method for SCTP. It recommends the use of the PAD chunk, defined in 1342 [RFC4820] to be attached to a minimum length HEARTBEAT chunk to build 1343 a probe packet. This enables probing without affecting the transfer 1344 of user messages and without interfering with congestion control. 1345 This is preferred to using DATA chunks (with padding as required) as 1346 path probes. 1348 XXX Author Note: Future versions of this document might define a 1349 parameter contained in the INIT and INIT ACK chunk to indicate the 1350 remote peer MTU to the local peer. However, multihoming makes this a 1351 bit complex, so it might not be worth doing. XXX 1353 6.2.1. SCTP/IPv4 and SCTP/IPv6 1355 The base protocol is specified in [RFC4960]. This provides an 1356 acknowledged PL. A sender can therefore enter the BASE state as soon 1357 as connectivity has been confirmed. 1359 6.2.1.1. Sending SCTP Probe Packets 1361 Probe packets consist of an SCTP common header followed by a 1362 HEARTBEAT chunk and a PAD chunk. The PAD chunk is used to control 1363 the length of the probe packet. The HEARTBEAT chunk is used to 1364 trigger the sending of a HEARTBEAT ACK chunk. The reception of the 1365 HEARTBEAT ACK chunk acknowledges reception of a successful probe. 1367 The HEARTBEAT chunk carries a Heartbeat Information parameter which 1368 should include, besides the information suggested in [RFC4960], the 1369 probe size, which is the size of the complete datagram. The size of 1370 the PAD chunk is therefore computed by reducing the probing size by 1371 the IPv4 or IPv6 header size, the SCTP common header, the HEARTBEAT 1372 request and the PAD chunk header. The payload of the PAD chunk 1373 contains arbitrary data. 1375 To avoid fragmentation of retransmitted data, probing starts right 1376 after the PL handshake, before data is sent. Assuming this behavior 1377 (i.e., the PMTU is smaller than or equal to the interface MTU), this 1378 process will take a few round trip time periods depending on the 1379 number of PMTU sizes probed. The Heartbeat timer can be used to 1380 implement the PROBE_TIMER. 1382 6.2.1.2. Validating the Path with SCTP 1384 Since SCTP provides an acknowledged PL, a sender MUST NOT implement 1385 the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. 1387 6.2.1.3. PTB Message Handling by SCTP 1389 Normal ICMP validation MUST be performed as specified in Appendix C 1390 of [RFC4960]. This requires that the first 8 bytes of the SCTP 1391 common header are quoted in the payload of the PTB message, which can 1392 be the case for ICMPv4 and is normally the case for ICMPv6. 1394 When a PTB message has been validated, the PTB_SIZE reported in the 1395 PTB message SHOULD be used with the DPLPMTUD algorithm, providing 1396 that the reported PTB_SIZE is less than the current probe size (see 1397 Section 4.4). 1399 6.2.2. DPLPMTUD for SCTP/UDP 1401 The UDP encapsulation of SCTP is specified in [RFC6951]. 1403 6.2.2.1. Sending SCTP/UDP Probe Packets 1405 Packet probing can be performed as specified in Section 6.2.1.1. The 1406 maximum payload is reduced by 8 bytes, which has to be considered 1407 when filling the PAD chunk. 1409 6.2.2.2. Validating the Path with SCTP/UDP 1411 Since SCTP provides an acknowledged PL, a sender MUST NOT implement 1412 the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. 1414 6.2.2.3. Handling of PTB Messages by SCTP/UDP 1416 ICMP validation MUST be performed for PTB messages as specified in 1417 Appendix C of [RFC4960]. This requires that the first 8 bytes of the 1418 SCTP common header are contained in the PTB message, which can be the 1419 case for ICMPv4 (but note the UDP header also consumes a part of the 1420 quoted packet header) and is normally the case for ICMPv6. When the 1421 validation is completed, the PTB_SIZE indicated in the PTB message 1422 SHOULD be used with the DPLPMTUD providing that the reported PTB_SIZE 1423 is less than the current probe size. 1425 6.2.3. DPLPMTUD for SCTP/DTLS 1427 The Datagram Transport Layer Security (DTLS) encapsulation of SCTP is 1428 specified in [RFC8261]. It is used for data channels in WebRTC 1429 implementations. 1431 6.2.3.1. Sending SCTP/DTLS Probe Packets 1433 Packet probing can be done as specified in Section 6.2.1.1. 1435 6.2.3.2. Validating the Path with SCTP/DTLS 1437 Since SCTP provides an acknowledged PL, a sender MUST NOT implement 1438 the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. 1440 6.2.3.3. Handling of PTB Messages by SCTP/DTLS 1442 It is not possible to perform ICMP validation as specified in 1443 [RFC4960], since even if the ICMP message payload contains sufficient 1444 information, the reflected SCTP common header would be encrypted. 1445 Therefore it is not possible to process PTB messages at the PL. 1447 6.3. DPLPMTUD for QUIC 1449 Quick UDP Internet Connection (QUIC) [I-D.ietf-quic-transport] is a 1450 UDP-based transport that provides reception feedback. The UDP 1451 payload includes the QUIC packet header, protected payload, and any 1452 authentication fields. QUIC depends on a PMTU of at least 1280 1453 bytes. 1455 Section 14.1 of [I-D.ietf-quic-transport] describes the path 1456 considerations when sending QUIC packets. It recommends the use of 1457 PADDING frames to build the probe packet. Pure probe-only packets 1458 are constructed with PADDING frames and PING frames to create a 1459 padding only packet that will elicit an acknowledgement. Such 1460 padding only packets enable probing without affecting the transfer of 1461 other QUIC frames. 1463 The recommendation for QUIC endpoints implementing DPLPMTUD is that a 1464 MPS is maintained for each combination of local and remote IP 1465 addresses [I-D.ietf-quic-transport]. If a QUIC endpoint determines 1466 that the PMTU between any pair of local and remote IP addresses has 1467 fallen below an acceptable MPS, it needs to immediately cease sending 1468 QUIC packets on the affected path. This could result in termination 1469 of the connection if an alternative path cannot be found 1470 [I-D.ietf-quic-transport]. 1472 6.3.1. Sending QUIC Probe Packets 1474 A probe packet consists of a QUIC Header and a payload containing 1475 PADDING Frames and a PING Frame. PADDING Frames are a single octet 1476 (0x00) and several of these can be used to create a probe packet of 1477 size PROBED_SIZE. QUIC provides an acknowledged PL, a sender can 1478 therefore enter the BASE state as soon as connectivity has been 1479 confirmed. 1481 The current specification of QUIC sets the following: 1483 * BASE_PMTU: 1200. A QUIC sender needs to pad initial packets to 1484 1200 bytes to confirm the path can support packets of a useful 1485 size. 1487 * MIN_PMTU: 1200 bytes. A QUIC sender that determines the PMTU has 1488 fallen below 1200 bytes MUST immediately stop sending on the 1489 affected path. 1491 6.3.2. Validating the Path with QUIC 1493 QUIC provides an acknowledged PL. A sender therefore MUST NOT 1494 implement the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. 1496 6.3.3. Handling of PTB Messages by QUIC 1498 QUIC operates over the UDP transport, and the guidelines on ICMP 1499 validation as specified in Section 5.2 of [RFC8085] therefore apply. 1500 In addition to UDP Port validation QUIC can validate an ICMP message 1501 by looking for valid Connection IDs in the quoted packet. 1503 6.4. DPLPMTUD for UDP-Options 1505 UDP Options [I-D.ietf-tsvwg-udp-options] provides a way to extend UDP 1506 to provide new transport mechanisms. 1508 Support for using DPLPMTUD with UDP-Options is defined in the UDP- 1509 Options specification [I-D.ietf-tsvwg-udp-options]. 1511 7. Acknowledgements 1513 This work was partially funded by the European Union's Horizon 2020 1514 research and innovation programme under grant agreement No. 644334 1515 (NEAT). The views expressed are solely those of the author(s). 1517 8. IANA Considerations 1519 This memo includes no request to IANA. 1521 If there are no requirements for IANA, the section will be removed 1522 during conversion into an RFC by the RFC Editor. 1524 9. Security Considerations 1526 The security considerations for the use of UDP and SCTP are provided 1527 in the references RFCs. Security guidance for applications using UDP 1528 is provided in the UDP Usage Guidelines [RFC8085], specifically the 1529 generation of probe packets is regarded as a "Low Data-Volume 1530 Application", described in section 3.1.3 of this document. This 1531 recommends that sender limits generation of probe packets to an 1532 average rate lower than one probe per 3 seconds. 1534 A PL sender needs to ensure that the method used to confirm reception 1535 of probe packets offers protection from off-path attackers injecting 1536 packets into the path. This protection if provided in IETF-defined 1537 protocols (e.g., TCP, SCTP) using a randomly-initialized sequence 1538 number. A description of one way to do this when using UDP is 1539 provided in section 5.1 of [RFC8085]). 1541 There are cases where ICMP Packet Too Big (PTB) messages are not 1542 delivered due to policy, configuration or equipment design (see 1543 Section 1.1), this method therefore does not rely upon PTB messages 1544 being received, but is able to utilize these when they are received 1545 by the sender. PTB messages could potentially be used to cause a 1546 node to inappropriately reduce the PLPMTU. A node supporting 1547 DPLPMTUD MUST therefore appropriately validate the payload of PTB 1548 messages to ensure these are received in response to transmitted 1549 traffic (i.e., a reported error condition that corresponds to a 1550 datagram actually sent by the path layer, see Section 4.4.1). 1552 An on-path attacker, able to create a PTB message could forge PTB 1553 messages that include a valid quoted IP packet. Such an attack could 1554 be used to drive down the PLPMTU. There are two ways this method can 1555 be mitigated against such attacks: First, by ensuring that a PL 1556 sender never reduces the PLPMTU below the base size, solely in 1557 response to receiving a PTB message. This is achieved by first 1558 entering the BASE state when such a message is received. Second, the 1559 design does not require processing of PTB messages, a PL sender could 1560 therefore suspend processing of PTB messages (e.g., in a robustness 1561 mode after detecting that subsequent probes actually confirm that a 1562 size larger than the PTB_SIZE is supported by a path). 1564 Parallel forwarding paths SHOULD be considered. Section 5.4 1565 identifies the need for robustness in the method when the path 1566 information may be inconsistent. 1568 A node performing DPLPMTUD could experience conflicting information 1569 about the size of supported probe packets. This could occur when 1570 there are multiple paths are concurrently in use and these exhibit a 1571 different PMTU. If not considered, this could result in data being 1572 black holed when the PLPMTU is larger than the smallest PMTU across 1573 the current paths. 1575 10. References 1577 10.1. Normative References 1579 [I-D.ietf-quic-transport] 1580 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1581 and Secure Transport", draft-ietf-quic-transport-20 (work 1582 in progress), 23 April 2019, 1583 . 1586 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1587 DOI 10.17487/RFC0768, August 1980, 1588 . 1590 [RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", 1591 RFC 1191, DOI 10.17487/RFC1191, November 1990, 1592 . 1594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1595 Requirement Levels", BCP 14, RFC 2119, 1596 DOI 10.17487/RFC2119, March 1997, 1597 . 1599 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1600 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1601 December 1998, . 1603 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., 1604 and G. Fairhurst, Ed., "The Lightweight User Datagram 1605 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 1606 2004, . 1608 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 1609 Parameter for the Stream Control Transmission Protocol 1610 (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, 1611 . 1613 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1614 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1615 . 1617 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1618 Control Transmission Protocol (SCTP) Packets for End-Host 1619 to End-Host Communication", RFC 6951, 1620 DOI 10.17487/RFC6951, May 2013, 1621 . 1623 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1624 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1625 March 2017, . 1627 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1628 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1629 May 2017, . 1631 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 1632 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 1633 DOI 10.17487/RFC8201, July 2017, 1634 . 1636 [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, 1637 "Datagram Transport Layer Security (DTLS) Encapsulation of 1638 SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 1639 2017, . 1641 10.2. Informative References 1643 [I-D.ietf-intarea-tunnels] 1644 Touch, J. and M. Townsley, "IP Tunnels in the Internet 1645 Architecture", draft-ietf-intarea-tunnels-09 (work in 1646 progress), 19 July 2018, 1647 . 1650 [I-D.ietf-tsvwg-udp-options] 1651 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 1652 udp-options-07 (work in progress), 8 March 2019, 1653 . 1656 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1657 RFC 792, DOI 10.17487/RFC0792, September 1981, 1658 . 1660 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1661 Communication Layers", STD 3, RFC 1122, 1662 DOI 10.17487/RFC1122, October 1989, 1663 . 1665 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 1666 RFC 1812, DOI 10.17487/RFC1812, June 1995, 1667 . 1669 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 1670 RFC 2923, DOI 10.17487/RFC2923, September 2000, 1671 . 1673 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1674 Congestion Control Protocol (DCCP)", RFC 4340, 1675 DOI 10.17487/RFC4340, March 2006, 1676 . 1678 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1679 Control Message Protocol (ICMPv6) for the Internet 1680 Protocol Version 6 (IPv6) Specification", STD 89, 1681 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1682 . 1684 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1685 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1686 . 1688 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1689 ICMPv6 Messages in Firewalls", RFC 4890, 1690 DOI 10.17487/RFC4890, May 2007, 1691 . 1693 Appendix A. Revision Notes 1695 Note to RFC-Editor: please remove this entire section prior to 1696 publication. 1698 Individual draft -00: 1700 * Comments and corrections are welcome directly to the authors or 1701 via the IETF TSVWG working group mailing list. 1703 * This update is proposed for WG comments. 1705 Individual draft -01: 1707 * Contains the first representation of the algorithm, showing the 1708 states and timers 1710 * This update is proposed for WG comments. 1712 Individual draft -02: 1714 * Contains updated representation of the algorithm, and textual 1715 corrections. 1717 * The text describing when to set the effective PMTU has not yet 1718 been validated by the authors 1720 * To determine security to off-path-attacks: We need to decide 1721 whether a received PTB message SHOULD/MUST be validated? The text 1722 on how to handle a PTB message indicating a link MTU larger than 1723 the probe has yet not been validated by the authors 1725 * No text currently describes how to handle inconsistent results 1726 from arbitrary re-routing along different parallel paths 1728 * This update is proposed for WG comments. 1730 Working Group draft -00: 1732 * This draft follows a successful adoption call for TSVWG 1734 * There is still work to complete, please comment on this draft. 1736 Working Group draft -01: 1738 * This draft includes improved introduction. 1740 * The draft is updated to require ICMP validation prior to accepting 1741 PTB messages - this to be confirmed by WG 1743 * Section added to discuss Selection of Probe Size - methods to be 1744 evlauated and recommendations to be considered 1746 * Section added to align with work proposed in the QUIC WG. 1748 Working Group draft -02: 1750 * The draft was updated based on feedback from the WG, and a 1751 detailed review by Magnus Westerlund. 1753 * The document updates RFC 4821. 1755 * Requirements list updated. 1757 * Added more explicit discussion of a simpler black-hole detection 1758 mode. 1760 * This draft includes reorganisation of the section on IETF 1761 protocols. 1763 * Added more discussion of implementation within an application. 1765 * Added text on flapping paths. 1767 * Replaced 'effective MTU' with new term PLPMTU. 1769 Working Group draft -03: 1771 * Updated figures 1773 * Added more discussion on blackhole detection 1775 * Added figure describing just blackhole detection 1777 * Added figure relating MPS sizes 1779 Working Group draft -04: 1781 * Described phases and named these consistently. 1783 * Corrected transition from confirmation directly to the search 1784 phase (Base has been checked). 1786 * Redrawn state diagrams. 1788 * Renamed BASE_MTU to BASE_PMTU (because it is a base for the PMTU). 1790 * Clarified Error state. 1792 * Clarified supsending DPLPMTUD. 1794 * Verified normative text in requirements section. 1796 * Removed duplicate text. 1798 * Changed all text to refer to /packet probe/probe packet/ 1799 /validation/verification/ added term /Probe Confirmation/ and 1800 clarified BlackHole detection. 1802 Working Group draft -05: 1804 * Updated security considerations. 1806 * Feedback after speaking with Joe Touch helped improve UDP-Options 1807 description. 1809 Working Group draft -06: 1811 * Updated description of ICMP issues in section 1.1 1813 * Update to description of QUIC. 1815 Working group draft -07: 1817 * Moved description of the PTB processing method from the PTB 1818 requirements section. 1820 * Clarified what is performed in the PTB validation check. 1822 * Updated security consideration to explain PTB security without 1823 needing to read the rest of the document. 1825 * Reformatted state machine diagram 1827 Working group draft -08: 1829 * Moved to rfcxml v3+ 1831 * Rendered diagrams to svg in html version. 1833 * Removed Appendix A. Event-driven state changes. 1835 * Removed section on DPLPMTUD with UDP Options. 1837 * Shortened the dsecription of phases. 1839 Authors' Addresses 1841 Godred Fairhurst 1842 University of Aberdeen 1843 School of Engineering, Fraser Noble Building 1844 Aberdeen 1845 AB24 3UE 1846 United Kingdom 1848 Email: gorry@erg.abdn.ac.uk 1850 Tom Jones 1851 University of Aberdeen 1852 School of Engineering, Fraser Noble Building 1853 Aberdeen 1854 AB24 3UE 1855 United Kingdom 1857 Email: tom@erg.abdn.ac.uk 1859 Michael Tuexen 1860 Muenster University of Applied Sciences 1861 Stegerwaldstrasse 39 1862 48565 Steinfurt 1863 Germany 1865 Email: tuexen@fh-muenster.de 1866 Irene Ruengeler 1867 Muenster University of Applied Sciences 1868 Stegerwaldstrasse 39 1869 48565 Steinfurt 1870 Germany 1872 Email: i.ruengeler@fh-muenster.de 1874 Timo Voelker 1875 Muenster University of Applied Sciences 1876 Stegerwaldstrasse 39 1877 48565 Steinfurt 1878 Germany 1880 Email: timo.voelker@fh-muenster.de