idnits 2.17.1 draft-ietf-6man-mtu-option-08.txt: -(936): 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 (7 September 2021) is 962 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-11 -- 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 March 2022 University of Aberdeen 6 7 September 2021 8 IPv6 Minimum Path MTU Hop-by-Hop Option 9 draft-ietf-6man-mtu-option-08 11 Abstract 13 This document specifies a new Hop-by-Hop IPv6 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 value can then be communicated back 16 to the source using the return Path MTU field in the option. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 11 March 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Example Operation . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Use of the IPv6 Hop-by-Hop Options Header . . . . . . . . 4 54 2. Motivation and Problem Solved . . . . . . . . . . . . . . . . 5 55 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 56 4. Applicability Statements . . . . . . . . . . . . . . . . . . 6 57 5. IPv6 Minimum Path MTU Hop-by-Hop Option . . . . . . . . . . . 6 58 6. Router, Host, and Transport Behaviors . . . . . . . . . . . . 8 59 6.1. Router Behavior . . . . . . . . . . . . . . . . . . . . . 8 60 6.2. Host OS and Transport Behavior . . . . . . . . . . . . . 8 61 6.2.1. Host Operating System Behavior . . . . . . . . . . . 8 62 6.2.2. Transport Behavior . . . . . . . . . . . . . . . . . 9 63 6.2.2.1. Including the Option in an Outgoing Packet . . . 10 64 6.2.2.2. Validation of the Packet that includes the 65 Option . . . . . . . . . . . . . . . . . . . . . . 11 66 6.2.2.3. Receiving the Option . . . . . . . . . . . . . . 11 67 6.2.2.4. Using the Rtn-PMTU Field . . . . . . . . . . . . 12 68 6.2.2.5. Detecting Path Changes . . . . . . . . . . . . . 13 69 6.2.2.6. Detection of Dropping Packets that include the 70 Option . . . . . . . . . . . . . . . . . . . . . . 13 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 8.1. Router Option Processing . . . . . . . . . . . . . . . . 14 74 8.2. Network Layer Host Processing . . . . . . . . . . . . . . 14 75 8.3. Validating use of the Option Data . . . . . . . . . . . . 14 76 8.4. Direct use of the Rtn-PMTU Value . . . . . . . . . . . . 15 77 8.5. Using the Rtn-PMTU Value as a Hint for Probing . . . . . 15 78 8.6. Impact of Middleboxes . . . . . . . . . . . . . . . . . . 16 79 9. Experiment Goals . . . . . . . . . . . . . . . . . . . . . . 16 80 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 81 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 82 12. Change log [RFC Editor: Please remove] . . . . . . . . . . . 17 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 85 13.2. Informative References . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 88 1. Introduction 90 This draft proposes a new IPv6 Hop-by-Hop Option to record the 91 minimum of the Maximum Transmission Unit (MTU) along the forward path 92 between a source and destination host. The source host creates a 93 packet with this option and fills the Min-PMTU field with the value 94 of the MTU for the outbound link that will be used to forward the 95 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 This method has the potential to complete discovery of the correct 108 value in a single round trip time, even over paths that have 109 successive links each configured with a lower MTU. 111 1.1. Example Operation 113 The figure below illustrates the operation of the method. In this 114 case, the path between the source host and the destination host 115 comprises three links, the sender has a link MTU of size MTU-S, the 116 link between routers R1 and R2 has an MTU of size 9000 bytes, and the 117 final link to the destination has an MTU of size MTU-D. 119 +--------+ +----+ +----+ +-------+ 120 | | | | | | | | 121 | Sender +---------+ R1 +--------+ R2 +-------- + Dest. | 122 | | | | | | | | 123 +--------+ MTU-S +----+ 9000B +----+ MTU-D +-------+ 125 Figure 1 127 Three scenarios are described: 129 * Scenario 1, considers all links to have an 9000 byte MTU and the 130 method is supported by both routers. The initial Min-PMTU is not 131 modified along the path, and therefore the PMTU is 9000 bytes. 133 * Scenario 2, considers the link to the destination host (MTU-D) to 134 have an MTU of 1500 bytes. This is the smallest MTU, router R2 135 updates the Min-PMTU to 1500 bytes and the method correctly 136 updates the PMTU to 1500 bytes. Had there been another smaller 137 MTU at a link further along the path that also supports the 138 method, the lower MTU would also have been detected. 140 * Scenario 3, considers the case where the router preceding the 141 smallest link (R2) does not support the method, and the link to 142 the destination host (MTU-D) has an MTU of 1500 bytes. Therefore, 143 router R2 does not update the Min-PMTU to 1500 bytes. The method 144 then fails to detect the actual PMTU. 146 In Scenarios 2 and 3, a lower PMTU would also fail to be detected in 147 the case where PMTUD had been used and an ICMPv6 Packet Too Big (PTB) 148 message had not been delivered to the sender [RFC8201]. 150 These scenarios are summarized in the table below. "H" in R1 and/or 151 R2 columns means the router understands the Minimum Path MTU Hop-by- 152 Hop option. 154 +-+-----+-----+----+----+----------+-----------------------+ 155 | |MTU-S|MTU-D| R1 | R2 | Rec PMTU | Note | 156 +-+-----+-----+----+----+----------+-----------------------+ 157 |1|9000B|9000B| H | H | 9000 B | Endpoints attempt to | 158 | | | | | | use a 9000 B PMTU. | 159 +-+-----+-----+----+----+----------+-----------------------+ 160 |2|9000B|1500B| H | H | 1500 B | Endpoints attempt to | 161 | | | | | | | use a 1500 B PMTU. | 162 +-+-----+-----+----+----+----------+-----------------------+ 163 |3|9000B|1500B| H | - | 9000 B | Endpoints attempt to | 164 | | | | | | | use a 9000 B PMTU, | 165 | | | | | | | but need to implement | 166 | | | | | | | a method to fall back | 167 | | | | | | | to discover and use a | 168 | | | | | | | 1500 B PMTU. | 169 +-+-----+-----+----+----+----------+-----------------------+ 171 Figure 2 173 1.2. Use of the IPv6 Hop-by-Hop Options Header 175 IPv6 as specified in [RFC8200] allows nodes to optionally process 176 Hop-by-Hop headers. Specifically from Section 4: 178 * The Hop-by-Hop Options header is not inserted or deleted, but may 179 be examined or processed by any node along a packet's delivery 180 path, until the packet reaches the node (or each of the set of 181 nodes, in the case of multicast) identified in the Destination 182 Address field of the IPv6 header. The Hop-by-Hop Options header, 183 when present, must immediately follow the IPv6 header. Its 184 presence is indicated by the value zero in the Next Header field 185 of the IPv6 header. 187 * NOTE: While [RFC2460] required that all nodes must examine and 188 process the Hop-by-Hop Options header, it is now expected that 189 nodes along a packet's delivery path only examine and process the 190 Hop-by-Hop Options header if explicitly configured to do so. 192 The Hop-by-Hop Option defined in this document is designed to take 193 advantage of this property of how Hop-by-Hop options are processed. 194 Nodes that do not support this Option SHOULD ignore them. This can 195 mean that the Min-PMTU value does not account for all links along a 196 path. 198 2. Motivation and Problem Solved 200 The current state of Path MTU Discovery on the Internet is 201 problematic. The mechanisms defined in [RFC8201] are known to not 202 work well in all environments. This fails to work in various cases, 203 including when nodes in the middle of the network do not send ICMP 204 PTB messages, or rate-limited ICMP messages, or do not have a return 205 path to the source host. 207 This results in many transport connections being configured to use 208 smaller packets (e.g., 1280 bytes) by default and makes it difficult 209 to take advantage of paths with a larger PMTU where they do exist. 210 Applications that send large packets are forced to use IPv6 211 Fragmentation [RFC8200], which can reduce the reliability of Internet 212 communication [RFC8900]. 214 Encapsulations and network-layer tunnels further reduce the payload 215 size available for a transport to use. Also, some use-cases increase 216 packet overhead, for example, Network Virtualization Using Generic 217 Routing Encapsulation (NVGRE) [RFC7637] encapsulates L2 packets in an 218 outer IP header and does not allow IP Fragmentation. 220 Sending larger packets can improve host performance, e.g., avoiding 221 limits to packet processing by the packet rate. The potential of 222 multi-gigabit Ethernet will only be realized if the packet size is 223 increased above 1280 bytes, to avoid exceeding a packet per second 224 sending rate that most hosts can process. For example, the packet 225 per second rate required to reach wire speed on a 10G Ethernet link 226 with 1280 byte packets is about 977K packets per second (pps), vs. 227 139K pps for 9000 byte packets. A significant difference. 229 The purpose of the this draft is to improve the situation by defining 230 a mechanism that does not rely on reception of ICMPv6 Packet Too Big 231 messages from nodes in the middle of the network. Instead, this 232 provides information to the destination host about the minimum Path 233 MTU, and sends this information back to the source host. This is 234 expected to work better than the current RFC8201-based mechanisms. 236 3. Requirements Language 238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 239 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 240 "OPTIONAL" in this document are to be interpreted as described in BCP 241 14 [RFC2119] [RFC8174] when, and only when, they appear in all 242 capitals, as shown here. 244 4. Applicability Statements 246 The Path MTU option is designed for environments where there is 247 control over the hosts and nodes that connect them, and where there 248 is more than one MTU size in use. For example in Data Centers and on 249 paths between Data Centers, to allow a hosts to better take advantage 250 of a path that is able to support a large PMTU. 252 The design of the option is sufficiently simple that it can be 253 executed on a router's fast path. A strong pull from router vendors 254 customers will be required to create critical mass for this to 255 happen. This could initially be the case for connections within and 256 between Data Centers. 258 The method could also be useful in other environments, including the 259 general Internet, and offers advantage when this Hop-by-Hop Option is 260 supported on these paths. The method is more robust when used to 261 probe the path using packets that do not carry application data and 262 when also paired with a method such as Packetization Layer PMTUD 263 [RFC4821] or Datagram PLPMTUD [RFC8899]. 265 5. IPv6 Minimum Path MTU Hop-by-Hop Option 267 The Minimum Path MTU Hop-by-Hop Option has the following format: 269 Option Option Option 270 Type Data Len Data 271 +--------+--------+--------+--------+---------+-------+-+ 272 |BBCTTTTT|00000100| Min-PMTU | Rtn-PMTU |R| 273 +--------+--------+--------+--------+---------+-------+-+ 275 Option Type (see Section 4.2 of [RFC8200]): 277 BB 00 Skip over this option and continue processing. 279 C 1 Option data can change en route to the packet's final 280 destination. 282 TTTTT 10000 Option Type assigned from IANA [IANA-HBH]. 284 Length: 4 The size of the each value field in Option Data 285 field supports PMTU values from 0 to 65,534 octets, the 286 maximum size represented by the Path MTU option. 288 Min-PMTU: n 16-bits. The minimum MTU recorded along the path 289 in octets, reflecting the smallest link MTU that 290 the packet experienced along the path. 291 A value less than the IPv6 minimum link 292 MTU [RFC8200] MUST be ignored. 294 Rtn-PMTU: n 15-bits. The returned Path MTU field, carrying the 15 295 most significant bits of the latest received Min-PMTU 296 field for the forward path. The value zero means that 297 no Reported MTU is being returned. 299 R n 1-bit. R-Flag. Set by the source to signal that 300 the destination host should include the received 301 Rtn-PMTU field updated by the reported Min-PMTU value 302 when the destination host is to send a PMTU Option back 303 to the source host. 305 Figure 3 307 NOTE: The encoding of the final two octets (Rtn-PMTU and R-Flag) 308 could be implemented by a mask of the latest received Min-PMTU value 309 with 0xFFFE, discarding the right-most bit and then performing a 310 logical 'OR' with the R-Flag value of the sender. This encoding fits 311 in the minimum-sized HBH Option header. 313 6. Router, Host, and Transport Behaviors 315 6.1. Router Behavior 317 Routers that are not configured to support Hop-by-Hop Options SHOULD 318 ignore this option and SHOULD forward the packet [RFC8200]. 320 Routers that support Hop-by-Hop Options, but that are not configured 321 to support this option SHOULD ignore the option and SHOULD forward 322 the packet. 324 Routers that support this option SHOULD compare the value of the Min- 325 PMTU field with the MTU configured for the outgoing link. If the MTU 326 of the outgoing link is less than the Min-PMTU, the router rewrites 327 the Min-PMTU in the Option to use the smaller value. (The router 328 processing is performed without checking the valid range of the Min- 329 PMTU or the Rtn-PMTU fields.) 331 A router MUST ignore and MUST NOT change the Rtn-PMTU field or the 332 R-Flag in the option. 334 Discussion: 336 * The design of this option makes it feasible to be implemented 337 within the fast path of a router, because the processing 338 requirements are minimal. 340 6.2. Host OS and Transport Behavior 342 6.2.1. Host Operating System Behavior 344 The PMTU entry associated with the destination in the IP layer cache 345 can be updated using PMTUD after detecting a change using the IPv6 346 Minimum Path MTU Hop-by-Hop Option. This cached value can be used by 347 other flows that share the IP cache. 349 The value in the host IP layer cache could, for instance, be used by 350 PLPMTUD to select an initial PMTU for each flow before a flow 351 determines a PMTU for the specific path it is using (e.g., using the 352 IPv6 Minimum Path MTU Hop-by-Hop Option and DPLPMTUD). The cached 353 PMTU is only increased by PLPMTUD when the PL determines the path 354 actually supports a larger PMTU [RFC4821] [RFC8899]. 356 When requested to send an IPv6 packet with the Minimum Path MTU 357 option, the source host includes the option in an outgoing packet. 358 The source host MUST fill the Min-PMTU field with the MTU configured 359 for the link over which it will send the packet on the next hop 360 towards the destination host. 362 It sets the R Flag if it wishes the remote host to return the 363 discovered PMTU value. 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.2.2.3). If this value is not set (for example, because 369 there is no cached reported Min-PMTU value), the Rtn-PMTU field value 370 MUST 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 Minimum Path 375 MTU Option was sent solely to provide requested feedback on the 376 return Path MTU to avoid each response generating another response. 378 The normal sequence of operation of the R-Flag using the terminology 379 from the diagram in Figure 1 is: 381 1. Sender sends probe to Dest. Sender MUST set the R-Flag 383 2. Dest responds by sending a probe including the received Min-PMTU 384 as the Rtn-PMTU. Dest sets R-Flag only if response is desired 386 3. Sender sends response probe back to Dest, MUST NOT set R-Flag. 388 6.2.2. Transport Behavior 390 This Hop-by-Hop option is intended to be used with a path MTU 391 discovery method. 393 Section 4.1 of [RFC9000] describes different types of PMTU Probe, 394 depending on whether the probe packets carry application data. When 395 the path is expected to support use of the option, the PMTU Probe can 396 be sent on packets that include application data, but needs to be 397 robust to potential loss of the packet with the possibility that 398 retransmission might be needed. Using a PMTU Probe on packets that 399 do not carry application data will avoid the need for loss recovery 400 if a router on the path later drops packets that set this option. 401 This avoids the transport needing to retransmit a lost packet that 402 includes this option. 404 6.2.2.1. Including the Option in an Outgoing Packet 406 The upper layer protocol can request the Minimum Path MTU option to 407 be included in an outgoing IPv6 packet. A transport protocol (or 408 upper layer protocol) can include this option only on specific 409 packets used to test the path. This option does not need to be 410 included in all packets belonging to a flow. 412 NOTE: Including this option in a large packet (e.g., one larger than 413 the present PMTU) is not likely to be useful, since the large packet 414 would itself be dropped by any link along the path with a smaller 415 MTU, preventing the Min-PMTU information from reaching the 416 destination host. 418 Discussion: 420 * In the case of TCP, the option could be included in a packet that 421 carries a TCP segment sent after the connection is established. A 422 segment without data could be used, to avoid the need to 423 retransmit this data if the probe packet is lost. The discovered 424 value can be used to inform PLPMTUD [RFC4821]. 426 NOTE: A TCP SYN can also negotiate the Maximum Segment Size (MSS), 427 which acts as an upper limit to the packet size that can be sent 428 by a TCP sender. If this option were to be included in a TCP SYN, 429 it could increase the probability that the SYN segment is lost 430 when routers on the path drop packets with this option (see 431 Section 6.2.2.6), which could have an unwanted impact on the 432 result of racing options [I-D.ietf-taps-arch] or feature 433 negotiation. 435 * The use with datagram transport protocols (e.g., UDP) is harder to 436 characterize because applications using datagram transports range 437 from very short-lived (low data-volume applications) exchanges, to 438 longer (bulk) exchanges of packets between the source and 439 destination hosts [RFC8085]. 441 * Simple-exchange protocols (i.e., low data-volume applications 442 [RFC8085] that only send one or a few packets per transaction), 443 might assume that the PMTU is symmetrical. That is, the PMTU is 444 the same in both directions, or at least not smaller for the 445 return path. This optimization does not hold when the paths are 446 not symmetric. 448 * A datagram transport can utilise DPLPMTUD [RFC8899]. For example, 449 QUIC (see section 14.3 of [RFC9000]), can use DPLPMTUD to 450 determine whether the path to a destination will support a desired 451 maximum datagram size. When using the IPv6 MinPMTU HBH option, 452 the option could be added to an additional QUIC PMTU Probe that is 453 of minimal size (or one no larger than the currently supported 454 PMTU size). Once the return Path MTU value in the Min PMTU HBH 455 option has been learned, DPLPMTUD can be triggered to test for a 456 larger PLPMTU using an appropriately sized PLPMTU Probe Packet 457 (see section 5.3.1 of [RFC8899]). 459 * The use of this option with DNS and DNSSEC over UDP ought to work 460 for paths where the PMTU is symmetric. The DNS server will learn 461 the PMTU from the DNS query messages. If the Rtn-PMTU value is 462 smaller, then a large DNSSEC response might be dropped and the 463 known problems with PMTUD will then occur. DNS and DNSSEC over 464 transport protocols that can carry the PMTU ought to work. 466 * This method also can be used with Anycast to discover the PMTU of 467 the path, but the use needs to be aware that the Anycast binding 468 might change. 470 6.2.2.2. Validation of the Packet that includes the Option 472 An upper layer protocol (e.g., transport endpoint) using this option 473 needs to provide protection from data injection attacks by off-path 474 devices [RFC8085]. This requires a method to assure that the 475 information in the Option Data is provided by a node on the path. 476 This validates that the packet forms a part of an existing flow, 477 using context available at the upper layer. For example, a TCP 478 connection or UDP application that maintains the related state and 479 uses a randomized ephemeral port would provide this basic validation 480 to protect from off-path data injection, see Section 5.1 of 481 [RFC8085]. IPsec [RFC4301] and TLS [RFC8446] provide greater 482 assurance. 484 The upper layer discards any received packet when the packet 485 validation fails. When packet validation fails, the upper layer MUST 486 also discard the associated Option Data from the minimum Path MTU 487 option without further processing. 489 6.2.2.3. Receiving the Option 491 For a connection-oriented upper layer protocol, caching of the 492 received Min-PMTU could be implemented by saving the value in the 493 connection context at the transport layer. A connection-less upper 494 layer (e.g., one using UDP), requires the upper layer protocol to 495 cache the value for each flow it uses. 497 A destination host that receives a Minimum Path MTU Option with the 498 R-Flag SHOULD include the Minimum Path MTU option in the next 499 outgoing IPv6 packet for the corresponding flow. 501 A simple mechanism could only include this option (with the Rtn-PMTU 502 field set) the first time this option is received or when it notifies 503 a change in the Minimum Path MTU. This limits the number of packets 504 including the option packets that are sent. However, this does not 505 provide robustness to packet loss or recovery after a sender loses 506 state. 508 Discussion: 510 * Some upper layer protocols send packets less frequently than the 511 rate at which the host receives packets. This provides less 512 frequent feedback of the received Rtn-PMTU value. However, a host 513 always sends the most recent Rtn-PMTU value. 515 6.2.2.4. Using the Rtn-PMTU Field 517 The Rtn-PMTU field provides an indication of the PMTU from on-path 518 routers. It does not necessarily reflect the actual PMTU between the 519 sender and destination. Care therefore needs to be exercised in 520 using the Rtn-PMTU value. Specifically: 522 * The actual PMTU can be lower than the Rtn-PMTU value because Min- 523 PMTU field was not updated by a router on the path that did not 524 process the option. 526 * The actual PMTU may be lower than the Rtn-PMTU value because the 527 there is a layer 2 device with a lower MTU. 529 * The actual PMTU may be larger than the Rtn-PMTU value because of a 530 corrupted, delayed or mis-ordered response. A source host SHOULD 531 ignore a Rtn-PMTU value larger than the MTU configured for the 532 outgoing link. 534 IPv6 requires that every link in the Internet have an MTU of 1280 535 octets or greater. A node MUST ignore a Rtn-PMTU value less than 536 1280 octets [RFC8200]. 538 To avoid unintentional dropping of packets that exceed the actual 539 PMTU (e.g., Scenario 3 in Section 1.1), the source host can delay 540 increasing the PMTU until a probe packet with the size of the Rtn- 541 PMTU value has been successfully acknowledged by the upper layer, 542 confirming that the path supports the larger PMTU. This probing 543 increases robustness, but adds one additional path round trip time 544 before the PMTU is updated. This use resembles that of PTB messages 545 in section 4.6 of DPLPMTUD [RFC8899] (with the important difference 546 that a PTB message can only seek to lower the PMTU, whereas this 547 option could trigger a probe packet to seek to increase the PMTU.) 548 Section 5.2 of [RFC8201] provides guidance on the caching of PMTU 549 information and also the relation to IPv6 flow labels. 550 Implementations should consider the impact of Equal Cost Multipath 551 (ECMP) [RFC6438]. Specifically, whether a PMTU ought be maintained 552 for each transport endpoint, or for each network address. 554 6.2.2.5. Detecting Path Changes 556 Path characteristics can change and the actual PMTU could increase or 557 decrease over time. For instance, following a path change when 558 packets are forwarded over a link with a different MTU than that 559 previously used. To bound the delay in discovering an increase in 560 the actual PMTU, a host with a link MTU larger than the current PMTU 561 SHOULD periodically send the Minimum Path MTU Option with the R-bit 562 set. DPLPMTUD provides recommendations concerning how this could be 563 implemented (see Section 5.3 of [RFC8899]). Since the option 564 consumes less capacity than a full-sized probe packet, there can be 565 advantage in using this to detect a change in the path 566 characteristics. 568 6.2.2.6. Detection of Dropping Packets that include the Option 570 There is evidence that some middleboxes drop packets that include 571 Hop-by-Hop options. For example, a firewall might drop a packet that 572 carries an unknown extension header or option. This practice is 573 expected to decrease as an option becomes more widely used. It could 574 result in generation of an ICMPv6 message indicating the problem. 575 This could be used to (temporarily) suspend use of this option. 577 A middlebox that silently discards a packet with this option results 578 in dropping of any packet using the option. This dropping can be 579 avoided by appropriate configuration in a controlled environment, 580 such as within a data centre, but needs to be considered for Internet 581 usage. Section 6.2 recommends that this option is not used on 582 packets where loss might adversely impact performance. 584 7. IANA Considerations 586 IANA has assigned and registered an IPv6 Hop-by-Hop Option type with 587 Temporary status from the "Destination Options and Hop-by-Hop 588 Options" registry [IANA-HBH]. This assignment is shown in Section 5. 590 IANA is requested to update this registry to point to this document 591 and remove the Temporary status. 593 8. Security Considerations 595 This section discusses the security considerations. It first reviews 596 router option processing. It then reviews host processing when 597 receiving this option at the network layer. It then considers two 598 ways in which the Option Data can be processed, followed by two 599 approaches for using the Option Data. Finally, it discusses 600 middlebox implications related to use in the general Internet. 602 8.1. Router Option Processing 604 This option shares the characteristics of all other IPv6 Hop by Hop 605 Options, in that if not supported at line rate it could be used to 606 degrade the performance of a router. This option, while simple, is 607 no different to other uses of IPv6 Hop-by-Hop options. 609 8.2. Network Layer Host Processing 611 A malicious attacker can forge a packet directed at a host that 612 carries the minimum Path MTU option. By design, the fields of this 613 IP option can be modified by the network. 615 Reception of this packet will require processing as the network stack 616 parses the packet before the packet is delivered to the upper layer 617 protocol. This network layer option processing is normally completed 618 before any upper layer protocol delivery checks are performed. 620 The network layer does not normally have sufficient information to 621 validate that the packet carrying an option originated from the 622 destination (or an on-path node). It also does not typically have 623 sufficient context to demultiplex the packet to identify the related 624 transport flow. This can mean that any changes resulting from 625 reception of the option apply to all flows between a pair of 626 endpoints. 628 These considerations are no different to other uses of Hop-by-Hop 629 options, and this is the use case for PMTUD. The following section 630 describes a mitigation for this attack. 632 8.3. Validating use of the Option Data 634 Transport protocols should be designed to provide protection from 635 data injection attacks by off-path devices and mechanisms should be 636 described in the Security Considerations for each transport 637 specification (see Section 5.1 of the UDP Guidelines [RFC8085]). For 638 example, a TCP or UDP application that maintains the related state 639 and uses a randomized ephemeral port would provide basic protection. 640 TLS [RFC8446] or IPsec [RFC4301] provide cryptographic 641 authentication. An upper layer protocol that validates each received 642 packet discards any packet when this validation fails. In this case, 643 the host MUST also discard the associated Option Data from the 644 minimum Path MTU option without further processing (Section 6.2.2). 646 A network node on the path has visibility of all packets it forwards. 647 By observing the network packet payload, the node might be able to 648 construct a packet that might be validated by the destination host. 649 Such a node would also be able to drop or limit the flow in other 650 ways that could be potentially more disruptive. Authenticating the 651 packet, for example, using IPsec [RFC4301] or TLS [RFC8446] mitigates 652 this attack. 654 8.4. Direct use of the Rtn-PMTU Value 656 The simplest way to utilize the Rtn-PMTU value is to directly use 657 this to update the PMTU. This approach results in a set of security 658 issues when the option carries malicious data: 660 * A direct update of the PMTU using the Rtn-PMTU value could result 661 in an attacker inflating or reducing the size of the host PMTU for 662 the destination. Forcing a reduction in the PMTU can decrease the 663 efficiency of network use, might increase the number of packets/ 664 fragments required to send the same volume of payload data, and 665 prevents sending an unfragmented datagram larger than the PMTU. 666 Increasing the PMTU can result in black-holing (see Section 1.1 of 667 [RFC8899]) when the source sends packets larger than the actual 668 PMTU. This persists until the PMTU is next updated. 670 * The method can be used to solicit a response from the destination 671 host. A malicious attacker could forge a packet that cause the 672 sender to add the option to a packet sent to the source. A forged 673 value of Rtn-PMTU in the Option Data might also impact the remote 674 endpoint, as described in the previous bullet. This persists 675 until a valid minimum Path MTU option is received. This attack 676 could be mitigated by limiting the sending of the minimum Path MTU 677 option in reply to incoming packets that carry the option. 679 8.5. Using the Rtn-PMTU Value as a Hint for Probing 681 Another way to utilize the Rtn-PMTU value is to indirectly trigger a 682 probe to determine if the path supports a PMTU of size Rtn-PMTU. 683 This approach needs context for the flow, and hence assumes an upper 684 layer protocol that validates the packet that carries the option (see 685 Section 8.3). This is the case when used in combination with 686 DPLPMTUD [RFC8899]. A set of security considerations result when an 687 option carries malicious data: 689 * If the forged packet carries a validated option with a non-zero 690 Rtn-PMTU field, the upper layer protocol could utilize the 691 information in the Rtn-PMTU field. A Rtn-PMTU larger than the 692 current PMTU can trigger a probe for a new size. 694 * If the forged packet carries a non-zero Min-PMTU field, the upper 695 layer protocol would change the cached information about the path 696 from the source. The cached information at the destination host 697 will be overwritten when the host receives another packet that 698 includes a minimum Path MTU option corresponding to the flow. 700 * Processing of the option could cause a destination host to add the 701 minimum Path MTU option to a packet sent to the source host. This 702 option will carry a Rtn-PMTU value that could have been updated by 703 the forged packet. The impact of the source host receiving this 704 resembles that discussed previously. 706 8.6. Impact of Middleboxes 708 There is evidence that some middleboxes drop packets that include 709 Hop-by-Hop options. For example, a firewall might drop a packet that 710 carries an unknown extension header or option. This practice is 711 expected to decrease as the option becomes more widely used. Methods 712 to address this are discussed in Section 6.2.2.6. 714 When a forged packet cause a packet to be sent including the minimum 715 Path MTU option, and the return path does not forward packets with 716 this option, the packet will be dropped Section 6.2.2.6. This attack 717 is mitigated by validating the option data before use and by limiting 718 the rate of responses generated. An upper layer could further 719 mitigate the impact by responding to a R-Flag by including the option 720 in a packet that does not carry application data. 722 9. Experiment Goals 724 This section describes the experimental goals of this specification. 726 A successful deployment of the method depends upon several components 727 being implemented and deployed: 729 * Support in the sending node (see Section 6.2.1). This also 730 requires corresponding support in upper layer protocols (see 731 Section 6.2.2). 733 * Router support in nodes (see Section 6.1). The IETF continues to 734 provide recommendations on the use of IPv6 Hop-by-Hop options, for 735 example Section 2.2.2 of [RFC9099]. This document does not update 736 the way router implementations configure support for HBH options. 738 * Support in the receiving node (see Section 6.2.2.3). 740 Experience from deployment is an expected input to any decision to 741 progress this specification from Experimental to IETF Standards 742 Track. Appropriate inputs might include: 744 * Reports of implementation experience; 746 * Measurements of the number paths where the method can be used; 748 * Measurements showing the benefit realized or the implications of 749 using specific methods over specific paths. 751 10. Implementation Status 753 At the time this document was published there are two known 754 implementations of the Path MTU Hop-by-Hop option. These are: 756 * Wireshark dissector. This is shipping in production in Wireshark 757 version 3.2 [WIRESHARK]. 759 * A prototype in the open source version of the FD.io Vector Packet 760 Processing (VPP) technology [VPP]. The the time this document was 761 published, the source code can be found [VPP_SRC]. 763 11. Acknowledgments 765 A similar mechanism was proposed for IPv4 in 1988 in [RFC1063] by 766 Jeff Mogul, C. Kent, Craig Partridge, and Keith McCloghire. It was 767 later obsoleted in 1990 by [RFC1191] the current deployed approach to 768 Path MTU Discovery. 770 Helpful comments were received from Tom Herbert, Tom Jones, Fred 771 Templin, Ole Troan, Tianran Zhou, Jen Linkova, Brian Carpenter, Peng 772 Shuping, Mark Smith, Fernando Gont, and other members of the 6MAN 773 working group. 775 12. Change log [RFC Editor: Please remove] 777 draft-ietf-6man-mtu-option-08, 2021-September-7 779 * Clarifications and editorial changes based on chair review by Ole 780 Troan. 781 * Correction and clarifications based on review by Fernando Gont. 783 draft-ietf-6man-mtu-option-07, 2021-August-31 785 * Added Experiment Goals section. 787 * Added Implementation Status section. 788 * Updated the IANA Considerations section to point to this document 789 and remove Temporary status. 790 * Clarifications and editorial changes based on review by Mark 791 Smith. 793 draft-ietf-6man-mtu-option-06, 2021-August-7 795 * Transport usage of the mechanism clarified in response to feedback 796 and suggestions from Jen Linkova. 797 * Restructured Section 6 to improve readability. 798 * Editorial changes. 800 draft-ietf-6man-mtu-option-05, 2021-April-28 802 * Editorial changes. 804 draft-ietf-6man-mtu-option-04, 2020-Oct-23 806 * Fixes for typos. 808 draft-ietf-6man-mtu-option-03, 2020-Sept-14 810 * Rewrite to make text and terminology more consistent. 811 * Added the notion of validating the packet before use of the HBH 812 option data. 813 * Method aligned with the way common APIs send/receive HBH option 814 data. 815 * Added reference to DPLPMTUD and clarified upper layer usage. 816 * Completed security considerations section. 818 draft-ietf-6man-mtu-option-02, 2020-March-9 820 * Editorial changes to make text and terminology more consistent. 821 * Added reference to DPLPMTUD. 823 draft-ietf-6man-mtu-option-01, 2019-September-13 825 * Changes to show IANA assigned code point. 826 * Editorial changes to make text and terminology more consistent. 827 * Added a reference to RFC8200 in Section 2 and a reference to 828 RFC6438 in Section 6.2.2. 830 draft-ietf-6man-mtu-option-00, 2019-August-9 832 * First 6man w.g. draft version. 833 * Changes to request IANA allocation of code point. 834 * Editorial changes. 836 draft-hinden-6man-mtu-option-02, 2019-July-5 838 * Changed option format to also include the Returned PMTU value and 839 Return flag and made related text changes in Section 6.2 to 840 describe this behavior. 841 * ICMP Packet Too Big messages are no longer used for feedback to 842 the source host. 843 * Added to Acknowledgements Section that a similar mechanism was 844 proposed for IPv4 in 1988 in [RFC1063]. 845 * Editorial changes. 847 draft-hinden-6man-mtu-option-01, 2019-March-05 849 * Changed requested status from Standards Track to Experimental to 850 allow use of experimental option type (11110) to allow for 851 experimentation. Removed request for IANA Option assignment. 852 * Added Section 2 "Motivation and Problem Solved" section to better 853 describe what the purpose of this document is. 854 * Added appendix describing planned experiments and how the results 855 will be measured. 856 * Editorial changes. 858 draft-hinden-6man-mtu-option-00, 2018-Oct-16 860 * Initial draft. 862 13. References 864 13.1. Normative References 866 [IANA-HBH] "Destination Options and Hop-by-Hop Options", 867 . 870 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 871 Requirement Levels", BCP 14, RFC 2119, 872 DOI 10.17487/RFC2119, March 1997, 873 . 875 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 876 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 877 May 2017, . 879 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 880 (IPv6) Specification", STD 86, RFC 8200, 881 DOI 10.17487/RFC8200, July 2017, 882 . 884 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 885 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 886 DOI 10.17487/RFC8201, July 2017, 887 . 889 13.2. Informative References 891 [I-D.ietf-taps-arch] 892 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 893 Perkins, C., Tiesel, P. S., and C. A. Wood, "An 894 Architecture for Transport Services", Work in Progress, 895 Internet-Draft, draft-ietf-taps-arch-11, 12 July 2021, 896 . 898 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 899 MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, 900 July 1988, . 902 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 903 DOI 10.17487/RFC1191, November 1990, 904 . 906 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 907 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 908 December 1998, . 910 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 911 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 912 December 2005, . 914 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 915 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 916 . 918 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 919 for Equal Cost Multipath Routing and Link Aggregation in 920 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 921 . 923 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 924 Virtualization Using Generic Routing Encapsulation", 925 RFC 7637, DOI 10.17487/RFC7637, September 2015, 926 . 928 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 929 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 930 March 2017, . 932 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 933 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 934 . 936 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 937 Völker, "Packetization Layer Path MTU Discovery for 938 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 939 September 2020, . 941 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 942 and F. Gont, "IP Fragmentation Considered Fragile", 943 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 944 . 946 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 947 Multiplexed and Secure Transport", RFC 9000, 948 DOI 10.17487/RFC9000, May 2021, 949 . 951 [RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, 952 "Operational Security Considerations for IPv6 Networks", 953 RFC 9099, DOI 10.17487/RFC9099, August 2021, 954 . 956 [VPP] "VPP/What is VPP?", 957 . 959 [VPP_SRC] "VPP Source", . 961 [WIRESHARK] 962 "Wireshark Network Protocol Analyzer", 963 . 965 Authors' Addresses 967 Robert M. Hinden 968 Check Point Software 969 959 Skyway Road 970 San Carlos, CA 94070 971 United States of America 973 Email: bob.hinden@gmail.com 975 Godred Fairhurst 976 University of Aberdeen 977 School of Engineering, Fraser Noble Building 978 Aberdeen 979 AB24 3UE 980 United Kingdom 982 Email: gorry@erg.abdn.ac.uk