idnits 2.17.1 draft-ietf-6man-mtu-option-15.txt: -(1059): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 May 2022) is 716 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-taps-arch-12 -- Obsolete informational reference (is this intentional?): RFC 1063 (Obsoleted by RFC 1191) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Hinden 3 Internet-Draft Check Point Software 4 Intended status: Experimental G. Fairhurst 5 Expires: 11 November 2022 University of Aberdeen 6 10 May 2022 8 IPv6 Minimum Path MTU Hop-by-Hop Option 9 draft-ietf-6man-mtu-option-15 11 Abstract 13 This document specifies a new IPv6 Hop-by-Hop option that is used to 14 record the minimum Path MTU along the forward path between a source 15 host to a destination host. The recorded value can then be 16 communicated back to the source using the return Path MTU field in 17 the option. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 11 November 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Example Operation . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Use of the IPv6 Hop-by-Hop Options Header . . . . . . . . 4 55 2. Motivation and Problem Solved . . . . . . . . . . . . . . . . 5 56 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 57 4. Applicability Statements . . . . . . . . . . . . . . . . . . 6 58 5. IPv6 Minimum Path MTU Hop-by-Hop Option . . . . . . . . . . . 6 59 6. Router, Host, and Transport Layer Behaviors . . . . . . . . . 8 60 6.1. Router Behavior . . . . . . . . . . . . . . . . . . . . . 8 61 6.2. Host Operating System Behavior . . . . . . . . . . . . . 8 62 6.3. Transport Layer Behavior . . . . . . . . . . . . . . . . 9 63 6.3.1. Including the Option in an Outgoing Packet . . . . . 10 64 6.3.2. Validation of the Packet that includes the Option . . 12 65 6.3.3. Receiving the Option . . . . . . . . . . . . . . . . 12 66 6.3.4. Using the Rtn-PMTU Field . . . . . . . . . . . . . . 13 67 6.3.5. Detecting Path Changes . . . . . . . . . . . . . . . 14 68 6.3.6. Detection of Dropping Packets that include the 69 Option . . . . . . . . . . . . . . . . . . . . . . . 14 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 8.1. Router Option Processing . . . . . . . . . . . . . . . . 15 73 8.2. Network Layer Host Processing . . . . . . . . . . . . . . 15 74 8.3. Validating use of the Option Data . . . . . . . . . . . . 16 75 8.4. Direct use of the Rtn-PMTU Value . . . . . . . . . . . . 16 76 8.5. Using the Rtn-PMTU Value as a Hint for Probing . . . . . 17 77 8.6. Impact of Middleboxes . . . . . . . . . . . . . . . . . . 17 78 9. Experiment Goals . . . . . . . . . . . . . . . . . . . . . . 17 79 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 80 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 81 12. Change log [RFC Editor: Please remove] . . . . . . . . . . . 18 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 84 13.2. Informative References . . . . . . . . . . . . . . . . . 22 85 Appendix A. Examples of Usage . . . . . . . . . . . . . . . . . 24 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 88 1. Introduction 90 This document specifies a new IPv6 Hop-by-Hop (HBH) Option to record 91 the minimum Maximum Transmission Unit (MTU) along the forward path 92 between a source and a destination host. The source host creates a 93 packet with this option and initializes the Min-PMTU field with the 94 value of the MTU for the outbound link that will be used to forward 95 the packet towards the destination host. 97 At each subsequent hop where the option is processed, the router 98 compares the value of the Min-PMTU Field in the option and the MTU of 99 its outgoing link. If the MTU of the link is less than the Min-PMTU, 100 it rewrites the value in the option data with the smaller value. 101 When the packet arrives at the destination host, the host can send 102 the value of the minimum reported MTU for the path back to the source 103 host using the Rtn-PMTU field in the option. The source host can 104 then use this value as input to the method that sets the Path MTU 105 (PMTU) used by upper layer protocols. 107 The IPv6 Minimum Path MTU Hop-by-Hop (MinPMTU HBH) Option is designed 108 to work with packet sizes that can be specified in the IPv6 header. 109 The maximum packet size that can be specified in an IPv6 header is 110 65,535 octets (2^^16). 112 This method has the potential to complete Path MTU discovery in a 113 single round trip time, even over paths that have successive links 114 each with a lower MTU. 116 The mechanism defined in this document is focused on Unicast, it does 117 not describe Multicast. That is left for future work. 119 1.1. Example Operation 121 The figure below illustrates the operation of the method. In this 122 case, the path between the source host and the destination host 123 comprises three links, the source has a link MTU of size MTU-S, the 124 link between routers R1 and R2 has an MTU of size 9000 bytes, and the 125 final link to the destination has an MTU of size MTU-D. 127 +--------+ +----+ +----+ +-------+ 128 | | | | | | | | 129 | Sender +---------+ R1 +--------+ R2 +-------- + Dest. | 130 | | | | | | | | 131 +--------+ MTU-S +----+ 9000B +----+ MTU-D +-------+ 133 Figure 1 135 Three scenarios are described: 137 * Scenario 1, considers all links to have an 9000 byte MTU and the 138 method is supported by both routers. The initial Min-PMTU is not 139 modified along the path, and therefore the PMTU is 9000 bytes. 141 * Scenario 2, considers the link between R2 and destination host 142 (MTU-D) to have an MTU of 1500 bytes. This is the smallest MTU, 143 router R2 updates the Min-PMTU to 1500 bytes and the method 144 correctly updates the PMTU to 1500 bytes. Had there been another 145 smaller MTU at a link further along the path that also supports 146 the method, the lower MTU would also have been detected. 148 * Scenario 3, considers the case where the router preceding the 149 smallest link (R2) does not support the method, and the link to 150 the destination host (MTU-D) has an MTU of 1500 bytes. Therefore, 151 router R2 does not update the Min-PMTU to 1500 bytes. The method 152 then fails to detect the actual PMTU. 154 In Scenarios 2 and 3, a lower PMTU would also fail to be detected in 155 the case where PMTUD had been used and an ICMPv6 Packet Too Big (PTB) 156 message had not been delivered to the sender [RFC8201]. 158 These scenarios are summarized in the table below. "H" in R1 and/or 159 R2 columns means the router understands the MinPMTU HBH option. 161 +-+-----+-----+----+----+----------+-----------------------+ 162 | |MTU-S|MTU-D| R1 | R2 | Rec PMTU | Note | 163 +-+-----+-----+----+----+----------+-----------------------+ 164 |1|9000B|9000B| H | H | 9000 B | Endpoints attempt to | 165 | | | | | | use a 9000 B PMTU. | 166 +-+-----+-----+----+----+----------+-----------------------+ 167 |2|9000B|1500B| H | H | 1500 B | Endpoints attempt to | 168 | | | | | | | use a 1500 B PMTU. | 169 +-+-----+-----+----+----+----------+-----------------------+ 170 |3|9000B|1500B| H | - | 9000 B | Endpoints attempt to | 171 | | | | | | | use a 9000 B PMTU, | 172 | | | | | | | but need to implement | 173 | | | | | | | a method to fall back | 174 | | | | | | | to discover and use a | 175 | | | | | | | 1500 B PMTU. | 176 +-+-----+-----+----+----+----------+-----------------------+ 178 Figure 2 180 1.2. Use of the IPv6 Hop-by-Hop Options Header 182 IPv6 as specified in [RFC8200] allows nodes to optionally process the 183 Hop-by-Hop header. Specifically, from Section 4: 185 * The Hop-by-Hop Options header is not inserted or deleted, but may 186 be examined or processed by any node along a packet's delivery 187 path, until the packet reaches the node (or each of the set of 188 nodes, in the case of multicast) identified in the Destination 189 Address field of the IPv6 header. The Hop-by-Hop Options header, 190 when present, must immediately follow the IPv6 header. Its 191 presence is indicated by the value zero in the Next Header field 192 of the IPv6 header. 194 * NOTE: While [RFC2460] required that all nodes must examine and 195 process the Hop-by-Hop Options header, it is now expected that 196 nodes along a packet's delivery path only examine and process the 197 Hop-by-Hop Options header if explicitly configured to do so. 199 The Hop-by-Hop Option defined in this document is designed to take 200 advantage of this property of how Hop-by-Hop options are processed. 201 Nodes that do not support this Option SHOULD ignore them. This can 202 mean that the Min-PMTU value does not account for all links along a 203 path. 205 2. Motivation and Problem Solved 207 The current state of Path MTU Discovery on the Internet is 208 problematic. The mechanisms defined in [RFC8201] are known to not 209 work well in all environments. It fails to work in various cases, 210 including when nodes in the middle of the network do not send ICMPv6 211 PTB messages, or rate-limited ICMPv6 messages, or do not have a 212 return path to the source host. 214 This results in many transport layer connections being configured to 215 use smaller packets (e.g., 1280 bytes) by default and makes it 216 difficult to take advantage of paths with a larger PMTU where they do 217 exist. Applications that send large packets are forced to use IPv6 218 Fragmentation [RFC8200], which can reduce the reliability of Internet 219 communication [RFC8900]. 221 Encapsulations and network-layer tunnels further reduce the payload 222 size available for a transport protocol to use. Also, some use-cases 223 increase packet overhead, for example, Network Virtualization Using 224 Generic Routing Encapsulation (NVGRE) [RFC7637] encapsulates L2 225 packets in an outer IP header and does not allow IP Fragmentation. 227 Sending larger packets can improve host performance, e.g., avoiding 228 limits to packet processing by the packet rate. For example, the 229 packet per second rate required to reach wire speed on a 10G link 230 with 1280 byte packets is about 977K packets per second (pps), vs. 231 139K pps for 9000 byte packets. 233 The purpose of this document is to improve the situation by defining 234 a mechanism that does not rely on reception of ICMPv6 Packet Too Big 235 messages from nodes in the middle of the network. Instead, this 236 provides information to the destination host about the minimum Path 237 MTU, and sends this information back to the source host. This is 238 expected to work better than the current RFC8201-based mechanisms. 240 A similar mechanism was proposed in 1988 for IPv4 in [RFC1063] by 241 Jeff Mogul, C. Kent, Craig Partridge, and Keith McCloghire. It was 242 later obsoleted in 1990 by [RFC1191], the current deployed approach 243 to Path MTU Discovery. In contrast, the method described in this 244 document uses the Hop-by-Hop option of IPv6. It does not replace 245 PMTUD [RFC8201], PLPPMTUD [RFC4821] or Datagram PLPMTUD [RFC8899], 246 but rather is designed to compliment these methods. 248 3. Requirements Language 250 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 251 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 252 "OPTIONAL" in this document are to be interpreted as described in BCP 253 14 [RFC2119] [RFC8174] when, and only when, they appear in all 254 capitals, as shown here. 256 4. Applicability Statements 258 The Path MTU option is designed for environments where there is 259 control over the hosts and nodes that connect them, and where there 260 is more than one MTU size in use. For example, in Data Centers and 261 on paths between Data Centers, to allow hosts to better take 262 advantage of a path that is able to support a large PMTU. 264 The design of the option is sufficiently simple that it can be 265 executed on a router's fast path. A successful experiment depends on 266 both implementation by host and router vendors and deployment by 267 operators. The contained use-case of connections within and between 268 Data Centers could be a driver for deployment. 270 The method could also be useful in other environments, including the 271 general Internet, and offers advantage when this Hop-by-Hop Option is 272 supported on all paths. The method is more robust when used to probe 273 the path using packets that do not carry application data and when 274 also paired with a method such as Packetization Layer PMTUD [RFC4821] 275 or Datagram PLPMTUD [RFC8899]. 277 5. IPv6 Minimum Path MTU Hop-by-Hop Option 279 The Minimum Path MTU Hop-by-Hop Option has the following format: 281 Option Option Option 282 Type Data Len Data 283 +--------+--------+--------+--------+---------+-------+-+ 284 |BBCTTTTT|00000100| Min-PMTU | Rtn-PMTU |R| 285 +--------+--------+--------+--------+---------+-------+-+ 287 Option Type (see Section 4.2 of [RFC8200]): 289 BB 00 Skip over this option and continue processing. 291 C 1 Option data can change en route to the packet's final 292 destination. 294 TTTTT 10000 Option Type assigned from IANA [IANA-HBH]. 296 Length: 4 The size of the value field in Option Data 297 field supports PMTU values from 0 to 65,534 octets, the 298 maximum size represented by the Path MTU option. 300 Min-PMTU: n 16-bits. The minimum MTU recorded along the path 301 in octets, reflecting the smallest link MTU that 302 the packet experienced along the path. 303 A value less than the IPv6 minimum link 304 MTU [RFC8200] MUST be ignored. 306 Rtn-PMTU: n 15-bits. The returned Path MTU field, carrying the 15 307 most significant bits of the latest received Min-PMTU 308 field for the forward path. The value zero means that 309 no Reported MTU is being returned. 311 R n 1-bit. R-Flag. Set by the source to signal that 312 the destination host should include the received 313 Rtn-PMTU field updated by the reported Min-PMTU value 314 when the destination host is to send a PMTU Option back 315 to the source host. 317 Figure 3 319 NOTE: The encoding of the final two octets (Rtn-PMTU and R-Flag) 320 could be implemented by a mask of the latest received Min-PMTU value 321 with 0xFFFE, discarding the right-most bit and then performing a 322 logical 'OR' with the R-Flag value of the sender. This encoding fits 323 in the minimum-sized Hop-by-Hop Option header. 325 6. Router, Host, and Transport Layer Behaviors 327 6.1. Router Behavior 329 Routers that are not configured to support Hop-by-Hop Options are not 330 expected to examine or process the contents of this option [RFC8200]. 332 Routers that support Hop-by-Hop Options, but are not configured to 333 support this option SHOULD skip over this option and continue to 334 processing the header [RFC8200]. 336 Routers that support this option MUST compare the value of the Min- 337 PMTU field with the MTU configured for the outgoing link. If the MTU 338 of the outgoing link is less than the Min-PMTU, the router rewrites 339 the Min-PMTU in the Option to use the smaller value. (The router 340 processing is performed without checking the valid range of the Min- 341 PMTU or the Rtn-PMTU fields.) 343 A router MUST ignore and MUST NOT change the Rtn-PMTU field or the 344 R-Flag in the option. 346 6.2. Host Operating System Behavior 348 The PMTU entry associated with the destination in the host's 349 destination cache [RFC4861] SHOULD be updated after detecting a 350 change using the IPv6 Minimum Path MTU Hop-by-Hop Option. This 351 cached value can be used by other flows that share the host's 352 destination cache. 354 The value in the host destination cache SHOULD be used by PLPMTUD to 355 select an initial PMTU for a flow. The cached PMTU is only increased 356 by PLPMTUD when the Packetization Layer determines the path actually 357 supports a larger PMTU [RFC4821] [RFC8899]. 359 When requested to send an IPv6 packet with the MinPMTU HBH option, 360 the source host includes the option in an outgoing packet. The 361 source host MUST fill the Min-PMTU field with the MTU configured for 362 the link over which it will send the packet on the next hop towards 363 the destination host. 365 When a host includes the option in a packet it sends, the host SHOULD 366 set the Rtn-PMTU field to the previously cached value of the received 367 Minimum Path MTU for the flow in the Rtn-PMTU field (see 368 Section 6.3.3). If this value is not set (for example, because there 369 is no cached reported Min-PMTU value), the Rtn-PMTU field value MUST 370 be set to zero. 372 The source host MAY request the destination host to return the 373 reported Min-PMTU value by setting the R-Flag in the option of an 374 outgoing packet. The R-Flag SHOULD NOT be set when the MinPMTU HBH 375 Option was sent solely to provide requested feedback on the return 376 Path MTU to avoid each response generating another response. 378 The destination host controls when to send a packet with this option 379 in response to an R-flag, as well as which packets to include it in. 380 The destination host MAY limit the rate at which it sends these 381 packets. 383 A destination host only sets the R Flag if it wishes the source host 384 to also return the discovered PMTU value for the path from the 385 destination to the source. 387 The normal sequence of operation of the R-Flag using the terminology 388 from the diagram in Figure 1 is: 390 1. The source sends a probe to the destination. The sender sets the 391 R-Flag. 393 2. The destination responds by sending a probe including the 394 received Min-PMTU as the Rtn-PMTU. A destination that does not 395 wish to probe the return path sets the R-Flag to 0. 397 6.3. Transport Layer Behavior 399 This Hop-by-Hop option is intended to be used with a path MTU 400 discovery method. 402 PLPMTUD [RFC9000] uses probe packets for two distinct functions: 404 * Probe packets are used to confirm connectivity. Such probes can 405 be of any size up to the PLPMTU. These probe packets are sent to 406 solicit a response use the path to the remote node. These probe 407 packets can carry the Hop-by-Hop PMTU option, providing the final 408 size of the packet does not exceed the current PLPMTU. After 409 validating that the packet originates from the path (section 410 4.6.1), the PLPMTUD method can use the reported size from the Hop- 411 by-Hop option as the next search point when it resumes the search 412 algorithm. (This use resembles the use of the PTB_SIZE 413 information in section 4.6.2 of [RFC8899] 415 * A second use of probe packets is to explore if a path supports a 416 packet size greater than the current PLPMTU. If this probe packet 417 is successfully delivered (as determined by the source host), then 418 the PLPMTU is raised to the size of the successful probe. These 419 probe packets do not usually set the Path MTU Hop-by-Hop option. 421 See section 1.2 of [RFC8899]. Section 4.1 of [RFC8899] also 422 describes ways that a Probe Packet can be constructed, depending 423 on whether the probe packets carry application data. 425 * The PMTU Hop-by-Hop Option Probe can be sent on packets that 426 include application data, but needs to be robust to potential loss 427 of the packet (i.e., with the possibility that retransmission 428 might be needed if the packet is lost). 430 * Using a PMTU Probe on packets that do not carry application data 431 will avoid the need for loss recovery if a router on the path 432 drops packets that set this option. (This avoids the transport 433 needing to retransmit a lost packet that includes this option.) 434 This is the normal default format for both uses of probes. 436 6.3.1. Including the Option in an Outgoing Packet 438 The upper layer protocol can request the MinPMTU HBH option to be 439 included in an outgoing IPv6 packet. A transport protocol (or upper 440 layer protocol) can include this option only on specific packets used 441 to test the path. This option does not need to be included in all 442 packets belonging to a flow. 444 NOTE: Including this option in a large packet (e.g., one larger than 445 the present PMTU) is not likely to be useful, since the large packet 446 would itself be dropped by any link along the path with a smaller 447 MTU, preventing the Min-PMTU information from reaching the 448 destination host. 450 Discussion: 452 * In the case of TCP, the option could be included in a packet that 453 carries a TCP segment sent after the connection is established. A 454 segment without data could be used, to avoid the need to 455 retransmit this data if the probe packet is lost. The discovered 456 value can be used to inform PLPMTUD [RFC4821]. 458 NOTE: A TCP SYN can also negotiate the Maximum Segment Size (MSS), 459 which acts as an upper limit to the packet size that can be sent 460 by a TCP sender. If this option were to be included in a TCP SYN, 461 it could increase the probability that the SYN segment is lost 462 when routers on the path drop packets with this option (see 463 Section 6.3.6), which could have an unwanted impact on the result 464 of racing options [I-D.ietf-taps-arch] or feature negotiation. 466 * The use with datagram transport protocols (e.g., UDP) is harder to 467 characterize because applications using datagram transports range 468 from very short-lived (low data-volume applications) exchanges, to 469 longer (bulk) exchanges of packets between the source and 470 destination hosts [RFC8085]. 472 * Simple-exchange protocols (i.e., low data-volume applications 473 [RFC8085] that only send one or a few packets per transaction), 474 might assume that the PMTU is symmetrical. That is, the PMTU is 475 the same in both directions, or at least not smaller for the 476 return path. This optimization does not hold when the paths are 477 not symmetric. 479 * The MinPMTU HBH option can be used with ICMPv6 [RFC4443]. This 480 requires a response from the remote node and therefore is 481 restricted to use with ICMPv6 echo messages. The MinPMTU HBH 482 option could provide additional information about the PMTU that 483 might be supported by a path. This could be use as a diagnostic 484 tool to measure the PMTU of a path. As with other uses, the 485 actual supported PMTU is only confirmed after receiving a response 486 to a subsequent probe of the PMTU size. 488 * A datagram transport can utilise DPLPMTUD [RFC8899]. For example, 489 QUIC (see section 14.3 of [RFC9000]), can use DPLPMTUD to 490 determine whether the path to a destination will support a desired 491 maximum datagram size. When using the IPv6 MinPMTU HBH option, 492 the option could be added to an additional QUIC PMTU Probe that is 493 of minimal size (or one no larger than the currently supported 494 PMTU size). Once the return Path MTU value in the MinPMTU HBH 495 option has been learned, DPLPMTUD can be triggered to test for a 496 larger PLPMTU using an appropriately sized PLPMTU Probe Packet 497 (see section 5.3.1 of [RFC8899]). 499 * The use of this option with DNS and DNSSEC over UDP is expected to 500 work for paths where the PMTU is symmetric. The DNS server will 501 learn the PMTU from the DNS query messages. If the Rtn-PMTU value 502 is smaller, then a large DNSSEC response might be dropped and the 503 known problems with PMTUD will then occur. DNS and DNSSEC over 504 transport protocols that can carry the PMTU ought to work. 506 * This method also can be used with Anycast to discover the PMTU of 507 the path, but the use needs to be aware that the Anycast binding 508 might change. 510 6.3.2. Validation of the Packet that includes the Option 512 An upper layer protocol (e.g., transport endpoint) using this option 513 needs to provide protection from data injection attacks by off-path 514 devices [RFC8085]. This requires a method to assure that the 515 information in the Option Data is provided by a node on the path. 516 This validates that the packet forms a part of an existing flow, 517 using context available at the upper layer. For example, a TCP 518 connection or UDP application that maintains the related state and 519 uses a randomized ephemeral port would provide this basic validation 520 to protect from off-path data injection, see Section 5.1 of 521 [RFC8085]. IPsec [RFC4301] and TLS [RFC8446] provide greater 522 assurance. 524 The upper layer discards any received packet when the packet 525 validation fails. When packet validation fails, the upper layer MUST 526 also discard the associated Option Data from the MinPMTU HBH option 527 without further processing. 529 6.3.3. Receiving the Option 531 For a connection-oriented upper layer protocol, caching of the 532 received Min-PMTU could be implemented by saving the value in the 533 connection context at the transport layer. A connection-less upper 534 layer (e.g., one using UDP), requires the upper layer protocol to 535 cache the value for each flow it uses. 537 A destination host that receives a MinPMTU HBH Option with the R-Flag 538 SHOULD include the MinPMTU HBH option in the next outgoing IPv6 539 packet for the corresponding flow. 541 A simple mechanism could only include this option (with the Rtn-PMTU 542 field set) the first time this option is received or when it notifies 543 a change in the Minimum Path MTU. This limits the number of packets 544 including the option packets that are sent. However, this does not 545 provide robustness to packet loss or recovery after a sender loses 546 state. 548 Discussion: 550 * Some upper layer protocols send packets less frequently than the 551 rate at which the host receives packets. This provides less 552 frequent feedback of the received Rtn-PMTU value. However, a host 553 always sends the most recent Rtn-PMTU value. 555 6.3.4. Using the Rtn-PMTU Field 557 The Rtn-PMTU field provides an indication of the PMTU from on-path 558 routers. It does not necessarily reflect the actual PMTU between the 559 source and destination hosts. Care therefore needs to be exercised 560 in using the Rtn-PMTU value. Specifically: 562 * The actual PMTU can be lower than the Rtn-PMTU value because the 563 Min-PMTU field was not updated by a router on the path that did 564 not process the option. 566 * The actual PMTU may be lower than the Rtn-PMTU value because there 567 is a layer-2 device with a lower MTU. 569 * The actual PMTU may be larger than the Rtn-PMTU value because of a 570 corrupted, delayed or mis-ordered response. A source host MUST 571 ignore a Rtn-PMTU value larger than the MTU configured for the 572 outgoing link. 574 * The path might have changed between the time when the probe was 575 sent and when the Rtn-PMTU value received. 577 IPv6 requires that every link in the Internet have an MTU of 1280 578 octets or greater. A node MUST ignore a Rtn-PMTU value less than 579 1280 octets [RFC8200]. 581 To avoid unintentional dropping of packets that exceed the actual 582 PMTU (e.g., Scenario 3 in Section 1.1), the source host can delay 583 increasing the PMTU until a probe packet with the size of the Rtn- 584 PMTU value has been successfully acknowledged by the upper layer, 585 confirming that the path supports the larger PMTU. This probing 586 increases robustness, but adds one additional path round trip time 587 before the PMTU is updated. This use resembles that of PTB messages 588 in section 4.6 of DPLPMTUD [RFC8899] (with the important difference 589 that a PTB message can only seek to lower the PMTU, whereas this 590 option could trigger a probe packet to seek to increase the PMTU.) 592 Section 5.2 of [RFC8201] provides guidance on the caching of PMTU 593 information and also the relation to IPv6 flow labels. 594 Implementations should consider the impact of Equal Cost Multipath 595 (ECMP) [RFC6438]. Specifically, whether a PMTU ought to be 596 maintained for each transport endpoint, or for each network address. 598 6.3.5. Detecting Path Changes 600 Path characteristics can change and the actual PMTU could increase or 601 decrease over time. For instance, following a path change when 602 packets are forwarded over a link with a different MTU than that 603 previously used. To bound the delay in discovering an increase in 604 the actual PMTU, a host with a link MTU larger than the current PMTU 605 SHOULD periodically send the MinPMTU HBH Option with the R-bit set. 606 DPLPMTUD provides recommendations concerning how this could be 607 implemented (see Section 5.3 of [RFC8899]). Since the option 608 consumes less capacity than a full-sized probe packet, there can be 609 advantage in using this to detect a change in the path 610 characteristics. 612 6.3.6. Detection of Dropping Packets that include the Option 614 There is evidence that some middleboxes drop packets that include 615 Hop-by-Hop options. For example, a firewall might drop a packet that 616 carries an unknown extension header or option. This practice is 617 expected to decrease as an option becomes more widely used. It could 618 result in generation of an ICMPv6 message indicating the problem. 619 This could be used to (temporarily) suspend use of this option. 621 A middlebox that silently discards a packet with this option results 622 in dropping of any packet using the option. This dropping can be 623 avoided by appropriate configuration in a controlled environment, 624 such as within a data centre, but needs to be considered for Internet 625 usage. Section 6.2 recommends that this option is not used on 626 packets where loss might adversely impact performance. 628 7. IANA Considerations 630 IANA has assigned and registered an IPv6 Hop-by-Hop Option type with 631 Temporary status from the "Destination Options and Hop-by-Hop 632 Options" registry [IANA-HBH]. This assignment is shown in Section 5. 634 IANA is requested to update this registry to point to this document 635 and remove the Temporary status. 637 8. Security Considerations 639 This section discusses the security considerations. It first reviews 640 router option processing. It then reviews host processing when 641 receiving this option at the network layer. It then considers two 642 ways in which the Option Data can be processed, followed by two 643 approaches for using the Option Data. Finally, it discusses 644 middlebox implications related to use in the general Internet. 646 8.1. Router Option Processing 648 This option shares the characteristics of all other IPv6 Hop-by-Hop 649 Options, in that if not supported at line rate it could be used to 650 degrade the performance of a router. This option, while simple, is 651 no different to other uses of IPv6 Hop-by-Hop options. 653 It is common for routers to ignore the Hop-by-Hop Option header or 654 drop packets containing a Hop-by-Hop Option header. Routers 655 implementing IPv6 according to [RFC8200] only examine and process the 656 Hop-by-Hop Options header if explicitly configured to do so. 658 8.2. Network Layer Host Processing 660 A malicious attacker can forge a packet directed at a host that 661 carries the MinPMTU HBH option. By design, the fields of this IP 662 option can be modified by the network. 664 For comparison, the ICMPv6 Packet Too Big message used in [RFC8201] 665 Path MTU Discovery, the source host has an inherent trust 666 relationship with the destination host including this option. This 667 trust relationship can be used to help verify the option. ICMPv6 668 Packet Too Big messages are sent from any router on the path to the 669 destination host, the source host has no prior knowledge of these 670 routers (except for the first hop router). 672 Reception of this packet will require processing as the network stack 673 parses the packet before the packet is delivered to the upper layer 674 protocol. This network layer option processing is normally completed 675 before any upper layer protocol delivery checks are performed. 677 The network layer does not normally have sufficient information to 678 validate that the packet carrying an option originated from the 679 destination (or an on-path node). It also does not typically have 680 sufficient context to demultiplex the packet to identify the related 681 transport flow. This can mean that any changes resulting from 682 reception of the option applies to all flows between a pair of 683 endpoints. 685 These considerations are no different to other uses of Hop-by-Hop 686 options, and this is the use case for PMTUD. The following section 687 describes a mitigation for this attack. 689 8.3. Validating use of the Option Data 691 Transport protocols should be designed to provide protection from 692 data injection attacks by off-path devices and mechanisms should be 693 described in the Security Considerations for each transport 694 specification (see Section 5.1 of the UDP Guidelines [RFC8085]). For 695 example, a TCP or UDP application that maintains the related state 696 and uses a randomized ephemeral port would provide basic protection. 697 TLS [RFC8446] or IPsec [RFC4301] provide cryptographic 698 authentication. An upper layer protocol that validates each received 699 packet discards any packet when this validation fails. In this case, 700 the host MUST also discard the associated Option Data from the 701 MinPMTU HBH option without further processing (Section 6.3). 703 A network node on the path has visibility of all packets it forwards. 704 By observing the network packet payload, the node might be able to 705 construct a packet that might be validated by the destination host. 706 Such a node would also be able to drop or limit the flow in other 707 ways that could be potentially more disruptive. Authenticating the 708 packet, for example, using IPsec [RFC4301] or TLS [RFC8446] mitigates 709 this attack. Note that AH style authentication [RFC4302] while 710 authenticating the payload and outer IPv6 header, does not check Hop- 711 by-Hop options that change on route. 713 8.4. Direct use of the Rtn-PMTU Value 715 The simplest way to utilize the Rtn-PMTU value is to directly use 716 this to update the PMTU. This approach results in a set of security 717 issues when the option carries malicious data: 719 * A direct update of the PMTU using the Rtn-PMTU value could result 720 in an attacker inflating or reducing the size of the host PMTU for 721 the destination. Forcing a reduction in the PMTU can decrease the 722 efficiency of network use, might increase the number of packets/ 723 fragments required to send the same volume of payload data, and 724 prevents sending an unfragmented datagram larger than the PMTU. 725 Increasing the PMTU can result in black-holing (see Section 1.1 of 726 [RFC8899]) when the source host sends packets larger than the 727 actual PMTU. This persists until the PMTU is next updated. 729 * The method can be used to solicit a response from the destination 730 host. A malicious attacker could forge a packet that causes the 731 destination to add the option to a packet sent to the source host. 732 A forged value of Rtn-PMTU in the Option Data might also impact 733 the remote endpoint, as described in the previous bullet. This 734 persists until a valid MinPMTU HBH option is received. This 735 attack could be mitigated by limiting the sending of the MinPMTU 736 HBH option in reply to incoming packets that carry the option. 738 8.5. Using the Rtn-PMTU Value as a Hint for Probing 740 Another way to utilize the Rtn-PMTU value is to indirectly trigger a 741 probe to determine if the path supports a PMTU of size Rtn-PMTU. 742 This approach needs context for the flow, and hence assumes an upper 743 layer protocol that validates the packet that carries the option (see 744 Section 8.3). This is the case when used in combination with 745 DPLPMTUD [RFC8899]. A set of security considerations result when an 746 option carries malicious data: 748 * If the forged packet carries a validated option with a non-zero 749 Rtn-PMTU field, the upper layer protocol could utilize the 750 information in the Rtn-PMTU field. A Rtn-PMTU larger than the 751 current PMTU can trigger a probe for a new size. 753 * If the forged packet carries a non-zero Min-PMTU field, the upper 754 layer protocol would change the cached information about the path 755 from the source. The cached information at the destination host 756 will be overwritten when the host receives another packet that 757 includes a MinPMTU HBH option corresponding to the flow. 759 * Processing of the option could cause a destination host to add the 760 MinPMTU HBH option to a packet sent to the source host. This 761 option will carry a Rtn-PMTU value that could have been updated by 762 the forged packet. The impact of the source host receiving this 763 resembles that discussed previously. 765 8.6. Impact of Middleboxes 767 There is evidence that some middleboxes drop packets that include 768 Hop-by-Hop options. For example, a firewall might drop a packet that 769 carries an unknown extension header or option. This practice is 770 expected to decrease as the option becomes more widely used. Methods 771 to address this are discussed in Section 6.3.6. 773 When a forged packet causes a packet to be sent including the MinPMTU 774 HBH option, and the return path does not forward packets with this 775 option, the packet will be dropped Section 6.3.6. This attack is 776 mitigated by validating the option data before use and by limiting 777 the rate of responses generated. An upper layer could further 778 mitigate the impact by responding to an R-Flag by including the 779 option in a packet that does not carry application data. 781 9. Experiment Goals 783 This section describes the experimental goals of this specification. 785 A successful deployment of the method depends upon several components 786 being implemented and deployed: 788 * Support in the sending node (see Section 6.2). This also requires 789 corresponding support in upper layer protocols (see Section 6.3). 791 * Router support in nodes (see Section 6.1). The IETF continues to 792 provide recommendations on the use of IPv6 Hop-by-Hop options, for 793 example Section 2.2.2 of [RFC9099]. This document does not update 794 the way router implementations configure support for Hop-by-Hop 795 options. 797 * Support in the receiving node (see Section 6.3.3). 799 Experience from deployment is an expected input to any decision to 800 progress this specification from Experimental to IETF Standards 801 Track. Appropriate inputs might include: 803 * Reports of implementation experience; 805 * Measurements of the number paths where the method can be used; 807 * Measurements showing the benefit realized or the implications of 808 using specific methods over specific paths. 810 10. Implementation Status 812 At the time this document was published there are two known 813 implementations of the Path MTU Hop-by-Hop option. These are: 815 * Wireshark dissector. This is shipping in production in Wireshark 816 version 3.2 [WIRESHARK]. 818 * A prototype in the open source version of the FD.io Vector Packet 819 Processing (VPP) technology [VPP]. At the time this document was 820 published, the source code can be found [VPP_SRC]. 822 11. Acknowledgments 824 Helpful comments were received from Tom Herbert, Tom Jones, Fred 825 Templin, Ole Troan, Tianran Zhou, Jen Linkova, Brian Carpenter, Peng 826 Shuping, Mark Smith, Fernando Gont, Michael Dougherty, Erik Kline, 827 and other members of the 6MAN working group. 829 12. Change log [RFC Editor: Please remove] 831 draft-ietf-6man-mtu-option-15, 2022-May-10 832 * Correcting an editing mistake in Appendix A. 833 * Editorial Change. 835 draft-ietf-6man-mtu-option-14, 2022-April-15 837 * Area Director Reviews: 838 - Lars Eggert's Review: Fixed "nits". 839 - Eric Vyncke's Review: Added that this work is focused on 840 Unicast, removed Discussion from Section 6.1, revised text on 841 PLPMTUD probing, changed SHOULD to MUST in Section 6.3.4, and 842 fixed several NITs. 843 - Alvaro Retana's Review: Changed SHOULD language to more general 844 text in Section 6.1 845 - ARTART Review: Added new Appendix "Examples of Usage" with 846 diagrams showing examples of use. 847 - Zaheduzzaman Sarker's Review: Fixed some editorial issues, and 848 updated SHOULD language. 849 * Editorial Changes. 851 draft-ietf-6man-mtu-option-13, 2022-February-28 853 * Area Directorate Reviews: 854 - SECDIR Review: Fixed "nit". 855 - TSVART Review: Restructured Section 6 including making 856 Transport Behavior more prominent, added text about ICMPv6 to 857 Section 6.3.1, moved the text about prior work in RFC1063 to 858 Section 2. 859 - GENART Review: Added text to Section 1 that this option was 860 designed to work with packet sizes that can be specified in the 861 IPv6 Header. 862 * Editorial Changes. 864 draft-ietf-6man-mtu-option-12, 2022-January-26 866 * Clarified a few issues raised by AD review by Erik Kline AD 867 review. 869 draft-ietf-6man-mtu-option-11, 2021-September-30 871 * Clarifications and editorial changes to the Security 872 Considerations section based on early AD review by Erik Kline. 874 draft-ietf-6man-mtu-option-10, 2021-September-27 876 * Clarifications and editorial changes based on second chair review 877 by Ole Troan. 878 * Editorial changes. 880 draft-ietf-6man-mtu-option-09, 2021-September-23 882 * Clarifications and editorial changes based on review by Michael 883 Dougherty. 885 draft-ietf-6man-mtu-option-08, 2021-September-7 887 * Clarifications and editorial changes based on chair review by Ole 888 Troan. 889 * Correction and clarifications based on review by Fernando Gont. 891 draft-ietf-6man-mtu-option-07, 2021-August-31 893 * Added Experiment Goals section. 894 * Added Implementation Status section. 895 * Updated the IANA Considerations section to point to this document 896 and remove Temporary status. 897 * Clarifications and editorial changes based on review by Mark 898 Smith. 900 draft-ietf-6man-mtu-option-06, 2021-August-7 902 * Transport usage of the mechanism clarified in response to feedback 903 and suggestions from Jen Linkova. 904 * Restructured Section 6 to improve readability. 905 * Editorial changes. 907 draft-ietf-6man-mtu-option-05, 2021-April-28 909 * Editorial changes. 911 draft-ietf-6man-mtu-option-04, 2020-Oct-23 913 * Fixes for typos. 915 draft-ietf-6man-mtu-option-03, 2020-Sept-14 917 * Rewrite to make text and terminology more consistent. 918 * Added the notion of validating the packet before use of the HBH 919 option data. 920 * Method aligned with the way common APIs send/receive HBH option 921 data. 922 * Added reference to DPLPMTUD and clarified upper layer usage. 923 * Completed security considerations section. 925 draft-ietf-6man-mtu-option-02, 2020-March-9 927 * Editorial changes to make text and terminology more consistent. 929 * Added reference to DPLPMTUD. 931 draft-ietf-6man-mtu-option-01, 2019-September-13 933 * Changes to show IANA assigned code point. 934 * Editorial changes to make text and terminology more consistent. 935 * Added a reference to RFC8200 in Section 2 and a reference to 936 RFC6438 in Section 6.3. 938 draft-ietf-6man-mtu-option-00, 2019-August-9 940 * First 6man w.g. draft version. 941 * Changes to request IANA allocation of code point. 942 * Editorial changes. 944 draft-hinden-6man-mtu-option-02, 2019-July-5 946 * Changed option format to also include the Returned PMTU value and 947 Return flag and made related text changes in Section 6.2 to 948 describe this behavior. 949 * ICMPv6 Packet Too Big messages are no longer used for feedback to 950 the source host. 951 * Added to Acknowledgements Section that a similar mechanism was 952 proposed for IPv4 in 1988 in [RFC1063]. 953 * Editorial changes. 955 draft-hinden-6man-mtu-option-01, 2019-March-05 957 * Changed requested status from Standards Track to Experimental to 958 allow use of experimental option type (11110) to allow for 959 experimentation. Removed request for IANA Option assignment. 960 * Added Section 2 "Motivation and Problem Solved" section to better 961 describe what the purpose of this document is. 962 * Added appendix describing planned experiments and how the results 963 will be measured. 964 * Editorial changes. 966 draft-hinden-6man-mtu-option-00, 2018-Oct-16 968 * Initial draft. 970 13. References 972 13.1. Normative References 974 [IANA-HBH] "Destination Options and Hop-by-Hop Options", 975 . 978 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 979 Requirement Levels", BCP 14, RFC 2119, 980 DOI 10.17487/RFC2119, March 1997, 981 . 983 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 984 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 985 May 2017, . 987 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 988 (IPv6) Specification", STD 86, RFC 8200, 989 DOI 10.17487/RFC8200, July 2017, 990 . 992 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 993 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 994 DOI 10.17487/RFC8201, July 2017, 995 . 997 13.2. Informative References 999 [I-D.ietf-taps-arch] 1000 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and 1001 C. Perkins, "An Architecture for Transport Services", Work 1002 in Progress, Internet-Draft, draft-ietf-taps-arch-12, 3 1003 January 2022, . 1006 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 1007 MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, 1008 July 1988, . 1010 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1011 DOI 10.17487/RFC1191, November 1990, 1012 . 1014 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1015 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1016 December 1998, . 1018 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1019 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1020 December 2005, . 1022 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1023 DOI 10.17487/RFC4302, December 2005, 1024 . 1026 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1027 Control Message Protocol (ICMPv6) for the Internet 1028 Protocol Version 6 (IPv6) Specification", STD 89, 1029 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1030 . 1032 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1033 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1034 . 1036 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1037 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1038 DOI 10.17487/RFC4861, September 2007, 1039 . 1041 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1042 for Equal Cost Multipath Routing and Link Aggregation in 1043 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1044 . 1046 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 1047 Virtualization Using Generic Routing Encapsulation", 1048 RFC 7637, DOI 10.17487/RFC7637, September 2015, 1049 . 1051 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1052 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1053 March 2017, . 1055 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1056 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1057 . 1059 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 1060 Völker, "Packetization Layer Path MTU Discovery for 1061 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 1062 September 2020, . 1064 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 1065 and F. Gont, "IP Fragmentation Considered Fragile", 1066 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 1067 . 1069 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1070 Multiplexed and Secure Transport", RFC 9000, 1071 DOI 10.17487/RFC9000, May 2021, 1072 . 1074 [RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, 1075 "Operational Security Considerations for IPv6 Networks", 1076 RFC 9099, DOI 10.17487/RFC9099, August 2021, 1077 . 1079 [VPP] "VPP/What is VPP?", 1080 . 1082 [VPP_SRC] "VPP Source", . 1084 [WIRESHARK] 1085 "Wireshark Network Protocol Analyzer", 1086 . 1088 Appendix A. Examples of Usage 1090 This section provides examples that illustrate a use of the MinPMTU 1091 HBH option by a source using DPLPMTUD to discover the PLPMTU 1092 supported by a path. They consider a path where the on-path router 1093 has been configured with an outgoing MTU of d'. The source starts by 1094 transmission of packets of size a, and then uses DPLPMTUD to seek to 1095 increase the size in steps resulting in sizes of b,c,d,e, etc., 1096 (chosen by the search algorithm used by DPLPMTUD). The search 1097 algorithm terminates with a PLPMTU that is at least d and is less 1098 than or equal to d'. 1100 The first example considers DPLPMTUD without using the MinPMTU HBH 1101 option. In this case, DPLPMTUD searches using an increasing size of 1102 probe packet. Probe packets of size (e) are sent, which are larger 1103 than the actual PMTU. In this example, PTB messages are not received 1104 from the routers and repeated unsuccessful probes result in the 1105 search phase completing. Packets of data are never sent with a size 1106 larger than the size of the last confirmed probe packet. ACKs of 1107 data packets are not shown. 1109 ----Packets of data size (a) ----------------------------> 1110 ----Probe size (b) --------------------------------------> 1111 <---------------------------------- ACK of probe -------- 1112 ----Packets of data size (b) ----------------------------> 1113 ----Probe size (c) --------------------------------------> 1114 <---------------------------------- ACK of probe -------- 1115 ----Packets of data size (c) ----------------------------> 1116 ----Probe size (d) --------------------------------------> 1117 <---------------------------------- ACK of probe -------- 1118 ----Packets of data size (d) ----------------------------> 1119 <---------------------------------- ACK of probe -------- 1120 ... 1121 ----Probe size (e) ------------X 1122 X----ICMPv6 PTB (d') --| 1123 ----Packets of data size (d) ----------------------------> 1124 ----Probe size (e) ------------X (again) 1125 X----ICMPv6 PTB (d') --| 1126 ----Packets of data size (d) ----------------------------- 1127 ... 1128 etc, until MaxProbes are unsuccessful and search phase completes. 1129 ----Packets of data size (d) ----------------------------> 1131 Figure 4 1133 The second example considers DPLPMTUD with the MinPMTU HBH option set 1134 on a connectivity probe packet. 1136 The IPv6 option is sent end-to-end, and the Min-PMTU is updated by a 1137 router on the path to d', which is returned in a response that also 1138 sets the MinPMTU HBH option. Upon receiving Rtn-PMTU value is 1139 received, DPLPMTUD immediately sends a probe packet of the target 1140 size (d'). If the probe packet is confirmed for the path, the PLPMTU 1141 is updated, allowing the source to use data packets up to size d'. 1142 (The search algorithm is allowed to continue to probe to see if the 1143 path supports a larger size.) Packets of data are never sent with a 1144 size larger than the last confirmed probe size, d'. 1146 ----Packets of data size (a) ----------------------------> 1147 ----Connectivity probe with MinPMTU- 1148 +--updated to minPMTU=d'-----> 1149 <-----------------ACK with Rtn-PMTU=d'-------------------- 1150 ----Packets of data size (a) ----------------------------> 1151 ----Probe size (d') -------------------------------------> 1152 <---------------------------------- ACK of probe --------- 1153 -----Packets of data size (d') --------------------------> 1154 Search phase completes. 1155 -----Packets of data size (d') --------------------------> 1156 Figure 5 1158 The final example considers DPLPMTUD with the MinPMTU HBH option set 1159 on a connectivity probe packet, but shows the effect when this 1160 connectivity probe packet is dropped. 1162 In this case, the packet with the MinPMTU HBH option is not received. 1163 DPLPMTUD searches using probe packets of increasing size, increasing 1164 the PLPMTU when the probes are confirmed. An ICMPv6 PTB message is 1165 received when the probed size exceeds the actual PMTU, indicating a 1166 PTB_SIZE of d'. DPLPMTUD immediately sends a probe packet of the 1167 target size (d'). If the probe packet is confirmed for the path, the 1168 PLPMTU is updated, allowing the source to use data packets up to size 1169 d'. If the ICMPv6 PTB message is not received, the DPLPMTU will be 1170 the last confirmed probe size, d. 1172 ----Packets of data size (a) -----------------------------> 1173 ----Connectivity probe with MinPMTU --------X 1174 ----Packets of data size (a) -----------------------------> 1175 ----Probe size (b) ---------------------------------------> 1176 <---------------------------------- ACK of probe -------- 1177 ----Packets of data size (b) -----------------------------> 1178 ----Probe size (c) ---------------------------------------> 1179 <---------------------------------- ACK of probe -------- 1180 ----Packets of data size (c) -----------------------------> 1181 ----Probe size (d) ---------------------------------------> 1182 <---------------------------------- ACK of probe -------- 1183 ----Packets of data size (d) -----------------------------> 1184 ----Probe size (e) ----------X 1185 <--ICMPv6 PTB PTB_SIZE(d') -| 1186 ----Packets of data size (d) -----------------------------> 1187 ----Probe size (d') using target set by PTB_SIZE ---------> 1188 <---------------------------------- ACK of probe -------- 1189 Search phase completes. 1190 ----Packets of data size (d') ----------------------------> 1192 Figure 6 1194 The number of probe rounds depends on the number of steps needed by 1195 the search algorithm, and is typically larger for a larger PMTU. 1197 Authors' Addresses 1199 Robert M. Hinden 1200 Check Point Software 1201 959 Skyway Road 1202 San Carlos, CA 94070 1203 United States of America 1204 Email: bob.hinden@gmail.com 1206 Godred Fairhurst 1207 University of Aberdeen 1208 School of Engineering 1209 Fraser Noble Building 1210 Aberdeen 1211 AB24 3UE 1212 United Kingdom 1213 Email: gorry@erg.abdn.ac.uk