idnits 2.17.1 draft-ietf-6man-mtu-option-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 March 2020) is 1508 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-datagram-plpmtud-16 -- 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 (~~), 2 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: 10 September 2020 University of Aberdeen 6 9 March 2020 8 IPv6 Minimum Path MTU Hop-by-Hop Option 9 draft-ietf-6man-mtu-option-02 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. This collects a minimum recorded MTU 16 along the path to the destination. The value can then be 17 communicated back to the source using the return Path MTU field in 18 the option. 20 This Hop-by-Hop option is intended to be used in environments like 21 Data Centers and on paths between Data Centers, to allow them to 22 better take advantage of paths able to support a large Path MTU. The 23 method could also be useful in other environments, including the 24 general Internet. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 10 September 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Motivation and Problem Solved . . . . . . . . . . . . . . . . 4 61 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 62 4. Applicability Statements . . . . . . . . . . . . . . . . . . 5 63 5. IPv6 Minimum Path MTU Hop-by-Hop Option . . . . . . . . . . . 6 64 6. Router, Host, and Transport Behaviors . . . . . . . . . . . . 7 65 6.1. Router Behaviour . . . . . . . . . . . . . . . . . . . . 7 66 6.2. Host Behavior . . . . . . . . . . . . . . . . . . . . . . 7 67 6.3. Transport Behavior . . . . . . . . . . . . . . . . . . . 10 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 71 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 12 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 11.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Appendix A. Planned Experiments . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 This draft proposes a new Hop-by-Hop Option to be used to record the 81 minimum MTU along the forward path between the source and destination 82 hosts. The source host creates a packet with this Hop-by-Hop Option 83 and fills the Reported PMTU Field in the option with the value of the 84 MTU for the outbound link that will be used to forward the packet 85 towards the destination. 87 At each subsequent hop where the option is processed, the router 88 compares the value of the Reported PMTU in the option and the MTU of 89 its outgoing link. If the MTU of the outgoing link is less than the 90 Reported PMTU specified in the option, it rewrites the value in the 91 Option Data with the smaller value. When the packet arrives at the 92 destination host, the destination host can send the minimum reported 93 PMTU value back to the source host using the Return PMTU field in the 94 option. 96 The figure below can be used to illustrate the operation of the 97 method. In this case, the path between the source and destination 98 hosts comprises three links, the sender has a link MTU of size MTU-S, 99 the link between routers R1 and R2 has an MTU of size 9000 bytes, and 100 the final link to the destination has an MTU of size MTU-D. 102 +--------+ +----+ +----+ +-------+ 103 | | | | | | | | 104 | Sender +---------+ R1 +--------+ R2 +-------- + Dest. | 105 | | | | | | | | 106 +--------+ MTU-S +----+ 9000B +----+ MTU-D +-------+ 108 The scenarios are described: 110 Scenario 1, considers all links to have an 9000 byte MTU and the 111 method is supported by both routers. 113 Scenario 2, considers the link to the destination host (MTU-D) to 114 have an MTU of 1500 bytes. This is the smallest MTU, router R2 115 resets the reported PMTU to 1500 bytes and this is detected by the 116 method. Had there been another smaller MTU at a link further along 117 the path that supports the method, the lower PMTU would also have 118 been detected. 120 Scenario 3, considers the case where the router preceding the 121 smallest link does not support the method, and the method then fails 122 to detect the actual PMTU. These scenarios are summarized in the 123 table below. In this scenario, the lower PMTU would also fail to be 124 detected had PMTUD been used and an ICMPv6 PTB message had not been 125 delivered to the sender. 127 +-+-----+-----+----+----+----------+-----------------------+ 128 | |MTU-S|MTU-D| R1 | R2 | Rec PMTU | Note | 129 +-+-----+-----+----+----+----------+-----------------------+ 130 |1|9000B|9000B| H | H | 9000 B | Endpoints attempt to | 131 | | | | | | use an 9000 B PMTU. | 132 +-+-----+-----+----+----+----------+-----------------------+ 133 |2|9000B|1500B| H | H | 1500 B | Endpoints attempt to | 134 | | | | | | | use a 1500 B PMTU. | 135 +-+-----+-----+----+----+----------+-----------------------+ 136 |3|9000B|1500B| H | - | 9000 B | Endpoints attempt to | 137 | | | | | | | use an 9000 B PMTU, | 138 | | | | | | | but need to implement | 139 | | | | | | | a method to fall back | 140 | | | | | | | use a 1500 B PMTU. | 141 +-+-----+-----+----+----+----------+-----------------------+ 143 IPv6 as specified in [RFC8200] allows nodes to optionally process 144 Hop-by-Hop headers. Specifically from Section 4: 146 * The Hop-by-Hop Options header is not inserted or deleted, but may 147 be examined or processed by any node along a packet's delivery 148 path, until the packet reaches the node (or each of the set of 149 nodes, in the case of multicast) identified in the Destination 150 Address field of the IPv6 header. The Hop-by-Hop Options header, 151 when present, must immediately follow the IPv6 header. Its 152 presence is indicated by the value zero in the Next Header field 153 of the IPv6 header. 155 * NOTE: While [RFC2460] required that all nodes must examine and 156 process the Hop-by-Hop Options header, it is now expected that 157 nodes along a packet's delivery path only examine and process the 158 Hop-by-Hop Options header if explicitly configured to do so. 160 The Hop-by-Hop Option defined in this document is designed to take 161 advantage of this property of how Hop-by-Hop options are processed. 162 Nodes that do not support this Option SHOULD ignore them. This can 163 mean that the value returned in the response message does not account 164 for all links along a path. 166 2. Motivation and Problem Solved 168 The current state of Path MTU Discovery on the Internet is 169 problematic. The problems with the mechanisms defined in [RFC8201] 170 are known to not work well in all environments. Nodes in the middle 171 of the network may not send ICMP Packet Too Big messages or they are 172 rate limited to the point of not making them a useful mechanism. 174 This results in many transport connections defaulting to 1280 bytes 175 and makes it very difficult to take advantage of links with a larger 176 MTU where they exist. Applications that need to send large packets 177 (e.g., using UDP) are forced to use IPv6 Fragmentation [RFC8200]. 179 Transport encapsulations and network-layer tunnels reduce the PMTU 180 available for a transport to use. For example, Network 181 Virtualization Using Generic Routing Encapsulation (NVGRE) [RFC7637] 182 encapsulates L2 packets in an outer IP header and does not allow IP 183 Fragmentation. 185 The potential of multi-gigabit Ethernet will not be realized if the 186 packet size is limited to 1280 bytes, because this exceeds the packet 187 per second rate that most nodes can send. For example, the packet 188 per second rate required to reach wire speed on a 10G Ethernet link 189 with 1280 byte packets is about 977K packets per second (pps), vs. 190 139K pps for 9000 byte packets. A significant difference. 192 The purpose of the this draft is to improve the situation by defining 193 a mechanism that does not rely on nodes in the middle of the network 194 to send ICMPv6 Packet Too Big messages, instead it provides the 195 destination host information on the minimum Path MTU and it can send 196 this information back to the source host. This is expected to work 197 better than the current RFC8201 based mechanisms. 199 3. Requirements Language 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 203 "OPTIONAL" in this document are to be interpreted as described in BCP 204 14 [RFC2119] [RFC8174] when, and only when, they appear in all 205 capitals, as shown here. 207 4. Applicability Statements 209 This Hop-by-Hop Option header is intended to be used in environments 210 such as Data Centers and on paths between Data Centers, to allow them 211 to better take advantage of a path that is able to support a large 212 PMTU. For example, it helps inform a sender that the path includes 213 links that have a MTU of 9000 bytes. This has many performance 214 advantages compared to the current practice of limiting packets to 215 1280 bytes. 217 The design of the option is sufficiently simple that it could be 218 executed on a router's fast path. To create critical mass for this 219 to happen will have to be a strong pull from router vendors 220 customers. This could be the case for connections within and between 221 Data Centers. 223 The method could also be useful in other environments, including the 224 general Internet. 226 5. IPv6 Minimum Path MTU Hop-by-Hop Option 228 The Minimum Path MTU Hop-by-Hop Option has the following format: 230 Option Option Option 231 Type Data Len Data 232 +--------+--------+--------+--------+---------+-------+-+ 233 |BBCTTTTT|00000100| Min-PMTU | Rtn-PMTU |R| 234 +--------+--------+--------+--------+---------+-------+-+ 236 Option Type: 238 BB 00 Skip over this option and continue processing. 240 C 1 Option data can change en route to the packet's final 241 destination. 243 TTTTT 10000 Option Type assigned from IANA [IANA-HBH]. 245 Length: 4 The size of the each value field in Option Data 246 field supports Path MTU values from 0 to 65,535 octets. 248 Min-PMTU: n 16-bits. The minimum PMTU in octets, reflecting the 249 smallest link MTU that the packet experienced across 250 the path. This is called the Reported PMTU. A value 251 less than the IPv6 minimum link MTU [RFC8200] 252 should be ignored. 254 Rtn-PMTU: n 15-bits. The returned mimimum PMTU, carrying the 15 255 most significant bits of the latest received Min-PMTU 256 field. The value zero means that no Reported MTU is 257 being returned. 259 R n 1-bit. R-Flag. Set by the source to signal that 260 the destination should include the received 261 Reported PMTU in Rtn-PMTU field. 263 NOTE: The encoding of the final two octets (Rtn-PMTU and R-Flag) 264 could be implemented by a mask of the latest received Min-MTU value 265 with 0xFFFE, discarding the right-most bit and then performing a 266 logical 'OR' with the R-Flag value of the sender. 268 6. Router, Host, and Transport Behaviors 270 6.1. Router Behaviour 272 Routers that do not support Hop-by-Hop options SHOULD ignore this 273 option and SHOULD forward the packet. 275 Routers that support Hop-by-Hop Options, but do not recognize this 276 option SHOULD ignore the option and SHOULD forward the packet. 278 Routers that recognize this option SHOULD compare the Reported PMTU 279 in the Min-PMTU field and the MTU configured for the outgoing link. 280 If the MTU of the outgoing link is less than the Reported PMTU, the 281 router rewrites the Reported PMTU in the Option to use the smaller 282 value. 284 The router MUST ignore and not change the Rtn-PMTU field and R-Flag 285 in the option. 287 Discussion: 289 * The design of this Hop-by-Hop Option makes it feasible to be 290 implemented within the fast path of a router, because the required 291 processing is simple. 293 6.2. Host Behavior 295 The source host that supports this option SHOULD create a packet with 296 this Hop-by-Hop Option and fill the Min-PMTU field of the option with 297 the MTU of configured for the link over which it will send the packet 298 on the next hop towards the destination. 300 The source host may request that the destination host return the 301 received minimum MTU value by setting the R-Flag in the option. This 302 will cause the destination host to include a PMTU option in an 303 outgoing packet. 305 Discussion: 307 * This option does not need to be sent in all packets belonging to a 308 flow. A transport protocol (or packetization layer 309 [I-D.ietf-tsvwg-datagram-plpmtud]) can set this option only on 310 specific packets used to test the path. 312 * In the case of TCP, the option could be included in packets 313 carrying a SYN segment as part of the connection set up, or can 314 periodically be sent in packets carrying other segments. 315 Including this packet in a SYN could increase the probability that 316 SYN segment is lost, when routers on the path drop packets with 317 this option. 319 * Including this option in a large packet (e.g., greater than the 320 present PMTU) is not likely to be useful, since the large packet 321 might itself also be dropped by a link along the path with a 322 smaller MTU, preventing the Reported PMTU information from 323 reaching the destination host. 325 * The use with datagram transport protocols (e.g., UDP) is harder to 326 characterize because applications using datagram transports range 327 from very short-lived (low data-volume applications) exchanges, to 328 longer (bulk) exchanges of packets between the source and 329 destination hosts [RFC8085]. 331 * For applications that use Anycast, this option should be included 332 in all packets as the actual destination will vary due to the 333 nature of Anycast. 335 * Simple-exchange protocols (i.e low data-volume applications 336 [RFC8085] that only send one or a few packets per transaction, 337 could be optimized by assuming that the Path MTU is symmetrical, 338 that is where the Path MTU is the same in both directions, or at 339 least not smaller in the return path. This optimisation does not 340 hold when the paths are not symmetric. 342 * The use of this option with DNS and DNSSEC over UDP ought to work 343 as long as the paths are symmetric. The DNS server will learn the 344 Path MTU from the DNS query messages. If the return Path MTU is 345 smaller, then the large DNSSEC response may be dropped and the 346 known problems with PMTUD will occur. DNS and DNSSEC over 347 transport protocols that can carry the Path MTU should work. 349 The source host can request the destination host to send a packet 350 carrying the PMTU Option using the R-Flag. 352 A destination host SHOULD respond to each packet received with the 353 R-Flag set, by setting the PMTU Option in the next packet that it 354 sends to the source host by the same upper layer protocol instance. 356 The upper layer protocol MAY generate a packet when any of these 357 conditions are met when the R Flag is set in the PMTU Option and 358 either: 360 * It is the first Reported PMTU value it has received from the 361 source. 363 * The Reported PMTU value is lower than previously received. 365 The R-Flag SHOULD NOT be set when the PMTU Option was sent solely to 366 carry the feedback of a Reported PMTU. 368 The PMTU Option sent back to the source SHOULD contain the outgoing 369 link MTU in Min-PMTU field and SHOULD set the last Received PMTU in 370 the Rtn-PMTU field. If these values are not present the field MUST 371 be set to zero. 373 For a connection-oriented upper layer protocol, this could be 374 implemented by saving the value of the last received option within 375 the connection context. This last received value is then used to set 376 the return Path MTU field for all packets belonging to this flow that 377 carry the IPv6 Minimum Path MTU Hop-by-Hop Option. 379 A connection-less protocol (e.g., based on UDP), requires the 380 application to be updated to cache the Received PMTU value, and to 381 ensure that this corresponding value is used to set the last Received 382 PMTU in the Rtn-PMTU field of any PMTU Option that it sends. 384 NOTE: The Rtn-PMTU value is specific to the instance of the upper 385 layer protocol (i.e., matching the IPv6 flow ID, port-fields in UDP 386 or the SPI in IPsec, etc), not the protocol itself, because network 387 devices can make forwarding decisions that impact the PMTU based on 388 the presence and values of these upper layer fields, and therefore 389 these fields need to correspond to those of the packets for the flow 390 received by the destination host set to ensure feedback is provided 391 to the corresponding source host. 393 NOTE: An upper layer protocol that sends packets from the destination 394 host towards the source host less frequently than the destination 395 host receives packets from the source host, provides less frequent 396 feedback of the received Min-PMTU value. However, it will always 397 needs to send the most recent value. 399 Discussion: 401 * A simple mechanism could only send an MTU Option with the Rtn-PMTU 402 field filled in the first time this option is received or when the 403 Received PMTU is reduced. This is good because it limits the 404 number sent, but there is no provision for retransmission of the 405 PMTU Option fails to reach the sender, or the sender looses state. 407 * The Reported PMTU value could increase or decrease over time. For 408 instance, it would increase when the path changes and the packets 409 become then forwarded over a link with a MTU larger than the link 410 previously used. 412 6.3. Transport Behavior 414 An upper layer protocol (e.g., transport endpoint) using this option 415 needs to use a method to verify the information provided by this 416 option. 418 The Received PMTU does not necessarily reflect the actual PMTU 419 between the sender and destination. Care therefore needs to be 420 exercised in using this value at the sender. Specifically: 422 * If the Received PMTU value returned by the destination is the same 423 as the initial Reported PMTU value, there could still be a router 424 or layer 2 device on the path that does not support this PMTU. 425 The usable PMTU therefore needs to be confirmed. 427 * If the Received PMTU value returned by the destination is smaller 428 than the initial Reported PMTU value, this is an indication that 429 there is at least one router in the path with a smaller MTU. 430 There could still be another router or layer 2 device on the path 431 that does not support this MTU. 433 * If the Received PMTU value returned by the destination is larger 434 than the initial Reported PMTU value, this may be a corrupted, 435 delayed or mis-ordered response, and SHOULD be ignored. 437 A sender needs to discriminate between the Received PMTU value in a 438 PTB message generated in response to a Hop-by-Hop option requesting 439 this, and a PTB message received from a router on the path. 441 A PMTUD or PLPMTUD method could use the Received PMTU value as an 442 initial target size to probe the path. This can significantly 443 decrease the number of probe attempts (and hence time taken) to 444 arrive at a workable PMTU. It has the potential to complete 445 discovery of the correct value in a single Round Trip Time (RTT), 446 even over paths that may have successive links configured with lower 447 MTUs. 449 Since the method can delay notification of an increase in the actual 450 PMTU, a sender with a link MTU larger than the current PMTU SHOULD 451 periodically probe for a PMTU value that is larger than the Received 452 PMTU value. This specification does not define an interval for the 453 time between probes. 455 Since the option consumes less capacity than an a full probe packet, 456 there may be advantage in using this to detect a change in the path 457 characteristics. 459 NOTE: Further details to be included in next version. 461 NOTE: A future version of the document will consider more the impact 462 of Equal Cost Multipath (ECMP) [RFC6438]. Specifically, whether a 463 Received PMTU value should be maintained by the method for each 464 transport endpoint, or for each network address, and how these are 465 best used by methods such as PLPMTUD or DPLPMTUD. 467 7. IANA Considerations 469 No IANA actions are requested in this document. 471 Earlier IANA assigned and registered a new IPv6 Hop-by-Hop Option 472 type from the "Destination Options and Hop-by-Hop Options" registry 473 [IANA-HBH]. This assignment is shown in Section 5. 475 8. Security Considerations 477 The method has no way to protect the destination from off-path attack 478 using this option in packets that do not originate from the source. 479 If the Rtn-PMTU value is used directly to update the PMTU, this 480 attack could cause the receiver to inflate or reduce the size of the 481 reported PMTU. The attack can be mitigated in DPLPMTUD 482 [I-D.ietf-tsvwg-datagram-plpmtud] when the Rtn-PMTU value is used to 483 trigger a rate-limited probe first confirms that a packet with the 484 size Rtn-PMTU value can use the current path, before the PMTU is 485 updated. 487 The method solicits a response from the destination, which should be 488 used to generate a response to the IPv6 host originating the option 489 packet. A malicious attacker could generate a packet to the 490 destination for a previously inactive flow or one that advertises a 491 change in the size of the MTU for an active flow. This would create 492 additional work at the destination, and could induce creation of 493 state when a new flow is created. It could potentially result in 494 additional traffic on the return path to the sender, which could be 495 mitigated by limiting the rate at which responses are generated. 497 TBD 499 9. Acknowledgments 501 A somewhat similar mechanism was proposed for IPv4 in 1988 in 502 [RFC1063] by Jeff Mogul, C. Kent, Craig Partridge, and Keith 503 McCloghire. It was later obsoleted in 1990 by [RFC1191] the current 504 deployed approach to Path MTU Discovery. 506 Helpful comments were received from Tom Herbert, Tom Jones, Fred 507 Templin, Ole Troan, [Your name here], and other members of the 6MAN 508 working group. 510 10. Change log [RFC Editor: Please remove] 512 draft-ietf-6man-mtu-option-02, 2020-March-9 514 * Editorial changes to make text and terminology more consistent. 515 * Added reference to [I-D.ietf-tsvwg-datagram-plpmtud]. 517 draft-ietf-6man-mtu-option-01, 2019-September-13 519 * Changes to show IANA assigned code point. 520 * Editorial changes to make text and terminology more consistent. 521 * Added a reference to RFC8200 in Section 2 and a reference to 522 RFC6438 in Section 6.3. 524 draft-ietf-6man-mtu-option-00, 2019-August-9 526 * First 6man w.g. draft version. 527 * Changes to request IANA allocation of code point. 528 * Editorial changes. 530 draft-hinden-6man-mtu-option-02, 2019-July-5 532 * Changed option format to also include the Returned MTU value and 533 Return flag and made related text changes in Section 6.2 to 534 describe this behaviour. 535 * ICMP Packet Too Big messages are no longer used for feedback to 536 the source host. 537 * Added to Acknowledgements Section that a similar mechanism was 538 proposed for IPv4 in 1988 in [RFC1063]. 539 * Editorial changes. 541 draft-hinden-6man-mtu-option-01, 2019-March-05 543 * Changed requested status from Standards Track to Experimental to 544 allow use of experimental option type (11110) to allow for 545 experimentation. Removed request for IANA Option assignment. 546 * Added Section 2 "Motivation and Problem Solved" section to better 547 describe what the purpose of this document is. 548 * Added Appendix A describing planned experiments and how the 549 results will be measured. 550 * Editorial changes. 552 draft-hinden-6man-mtu-option-00, 2018-Oct-16 554 * Initial draft. 556 11. References 557 11.1. Normative References 559 [IANA-HBH] "Destination Options and Hop-by-Hop Options", 560 . 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, 565 DOI 10.17487/RFC2119, March 1997, 566 . 568 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 569 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 570 May 2017, . 572 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 573 (IPv6) Specification", STD 86, RFC 8200, 574 DOI 10.17487/RFC8200, July 2017, 575 . 577 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 578 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 579 DOI 10.17487/RFC8201, July 2017, 580 . 582 11.2. Informative References 584 [I-D.ietf-tsvwg-datagram-plpmtud] 585 Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 586 T. Voelker, "Packetization Layer Path MTU Discovery for 587 Datagram Transports", Work in Progress, Internet-Draft, 588 draft-ietf-tsvwg-datagram-plpmtud-16, 9 March 2020, 589 . 592 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 593 MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, 594 July 1988, . 596 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 597 DOI 10.17487/RFC1191, November 1990, 598 . 600 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 601 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 602 December 1998, . 604 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 605 for Equal Cost Multipath Routing and Link Aggregation in 606 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 607 . 609 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 610 Virtualization Using Generic Routing Encapsulation", 611 RFC 7637, DOI 10.17487/RFC7637, September 2015, 612 . 614 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 615 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 616 March 2017, . 618 Appendix A. Planned Experiments 620 TBD 622 This section will describe a set of experiments planned for the use 623 of the option defined in this document. There are many aspects of 624 the design that require experimental data or experience to evaluate 625 this experimental specification. 627 This includes experiments to understand the pathology of packets sent 628 with the specified option to determine the likelihood that they are 629 lost within specific types of network segment. 631 This includes consideration of the cost and alternatives for 632 providing the feedback required by the mechanism and how to 633 effectively limit the rate of transmission. 635 This includes consideration of the potential for integration in 636 frameworks such as that offered by DPLPMTUD. 638 There are also security-related topics to be understood as described 639 in the Security Considerations (Section 8). 641 Authors' Addresses 643 Robert M. Hinden 644 Check Point Software 645 959 Skyway Road 646 San Carlos, CA 94070 647 United States of America 649 Email: bob.hinden@gmail.com 650 Godred Fairhurst 651 University of Aberdeen 652 School of Engineering, Fraser Noble Building 653 Aberdeen 654 AB24 3UE 655 United Kingdom 657 Email: gorry@erg.abdn.ac.uk