idnits 2.17.1 draft-hinden-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 (July 5, 2019) is 1756 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- 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 (~~), 1 warning (==), 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: January 6, 2020 University of Aberdeen 6 July 5, 2019 8 IPv6 Minimum Path MTU Hop-by-Hop Option 9 draft-hinden-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 to a destination host. This collects a minimum recorded MTU along 16 the path to the destination. The value can then be communicated back 17 to the source using the return Path MTU field in the option. 19 This Hop-by-Hop option is intended to be used in environments like 20 Data Centers and on paths between Data Centers, to allow them to 21 better take advantage of paths able to support a large Path MTU. 23 Status of This Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 6, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Motivation and Problem Solved . . . . . . . . . . . . . . . . 4 56 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 57 4. Applicability Statements . . . . . . . . . . . . . . . . . . 5 58 5. IPv6 Minimum Path MTU Hop-by-Hop Option . . . . . . . . . . . 5 59 6. Router, Host, and Transport Behaviors . . . . . . . . . . . . 6 60 6.1. Router Behaviour . . . . . . . . . . . . . . . . . . . . 6 61 6.2. Host Behavior . . . . . . . . . . . . . . . . . . . . . . 7 62 6.3. Transport Behavior . . . . . . . . . . . . . . . . . . . 9 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 66 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 11 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 11.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Appendix A. Planned Experiments . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 This draft proposes a new Hop-by-Hop Option to be used to record the 76 minimum MTU along the forward path between the source and destination 77 nodes. The source node creates a packet with this Hop-by-Hop Option 78 and fills the Reported PMTU Field in the option with the value of the 79 MTU for the outbound link that will be used to forward the packet 80 towards the destination. 82 At each subsequent hop where the option is processed, the router 83 compares the value of the Reported PMTU in the option and the MTU of 84 its outgoing link. If the MTU of the outgoing link is less than the 85 Reported PMTU specified in the option, it rewrites the value in the 86 Option Data with the smaller value. When the packet arrives at the 87 Destination node, the Destination node can send the minimum reported 88 PMTU value back to the Source Node using the Return PMTU field in the 89 option. 91 The figure below can be used to illustrate the operation of the 92 method. In this case, the path between the Sender and Destination 93 nodes comprises three links, the sender has a link MTU of size MTU-S, 94 the link between routers R1 and R2 has an MTU of size 8 KBytes, and 95 the final link to the destination has an MTU of size MTU-D. 97 +--------+ +----+ +----+ +-------+ 98 | | | | | | | | 99 | Sender +---------+ R1 +--------+ R2 +-------- + Dest. | 100 | | | | | | | | 101 +--------+ MTU-S +----+ 9000B +----+ MTU-D +-------+ 103 The scenarios are described: 105 Scenario 1, considers all links to have an 9000 Byte MTU and the 106 method is supported by both routers. 108 Scenario 2, considers the destination link to have an MTU of 1500 109 Byte. This is the smallest MTU, router R2 resets the reported PMTU 110 to 1500 Byte and this is detected by the method. Had there been 111 another smaller MTU at a link further along the path that supports 112 the method, the lower PMTU would also have been detected. 114 Scenario 3, considers the case where the router preceding the 115 smallest link does not support the method, and the method then fails 116 to detect the actual PMTU. These scenarios are summarized in the 117 table below. This scenario would also arise if the PTB message was 118 not delivered to the sender. 120 +-+-----+-----+----+----+----------+-----------------------+ 121 | |MTU-S|MTU-D| R1 | R2 | Rec PMTU | Note | 122 +-+-----+-----+----+----+----------+-----------------------+ 123 |1|9000B|9000B| H | H | 9000 B | Endpoints attempt to | 124 | | | | | | use an 9000 B PMTU. | 125 +-+-----+-----+----+----+----------+-----------------------+ 126 |2|9000B|1500B| H | H | 1500 B | Endpoints attempt to | 127 | | | | | | | use a 1500 B PMTU. | 128 +-+-----+-----+----+----+----------+-----------------------+ 129 |3|9000B|1500B| H | - | 9000 B | Endpoints attempt to | 130 | | | | | | | use an 9000 B PMTU, | 131 | | | | | | | but need to implement | 132 | | | | | | | a method to fall back | 133 | | | | | | | use a 1500 B PMTU. | 134 +-+-----+-----+----+----+----------+-----------------------+ 136 IPv6 as specified in [RFC8200] allows nodes to optionally process 137 Hop-by-Hop headers. Specifically from Section 4: 139 o The Hop-by-Hop Options header is not inserted or deleted, but may 140 be examined or processed by any node along a packet's delivery 141 path, until the packet reaches the node (or each of the set of 142 nodes, in the case of multicast) identified in the Destination 143 Address field of the IPv6 header. The Hop-by-Hop Options header, 144 when present, must immediately follow the IPv6 header. Its 145 presence is indicated by the value zero in the Next Header field 146 of the IPv6 header. 148 o NOTE: While [RFC2460] required that all nodes must examine and 149 process the Hop-by-Hop Options header, it is now expected that 150 nodes along a packet's delivery path only examine and process the 151 Hop-by-Hop Options header if explicitly configured to do so. 153 The Hop-by-Hop Option defined in this document is designed to take 154 advantage of this property of how Hop-by-Hop options are processed. 155 Nodes that do not support this Option SHOULD ignore them. This can 156 mean that the value returned in the response message does not account 157 for all links along a path. 159 2. Motivation and Problem Solved 161 The current state of Path MTU Discovery on the Internet is 162 problematic. The problems with the mechanisms defined in [RFC8201] 163 are known to not work well in all environments. Nodes in the middle 164 of the network may not send ICMP Packet Too Big messages or they are 165 rate limited to the point of not making them a useful mechanism. 167 This results in many connection defaulting to 1280 octets and makes 168 it very difficult to take advantage of links with larger MTU where 169 they exist. Applications that need to send large packets over UDP 170 are forced to use IPv6 Fragmentation. 172 Transport encapsulations and network-layer tunnels reduce the PMTU 173 available for a transport to use. For example, Network 174 Virtualization Using Generic Routing Encapsulation (NVGRE) [RFC7637] 175 encapsulates L2 packets in an outer IP header and does not allow IP 176 Fragmentation. 178 The use of 10G Ethernet will not achieve it's potential because the 179 packet per second rate will exceed what most nodes can send to 180 achieve multi-gigabit rates if the packet size limited to 1280 181 octets. For example, the packet per second rate required to reach 182 wire speed on a 10G Ethernet link with 1280 octet packets is about 183 977K packets per second (pps), vs. 139K pps for 9,000 octet packets. 184 A significant difference. 186 The purpose of the this draft is to improve the situation by defining 187 a mechanism that does not rely on nodes in the middle of the network 188 to send ICMPv6 Packet Too Big messages, instead it provides the 189 destination host information on the minimum Path MTU and it can send 190 this information back to the source host. This is expected to work 191 better than the current RFC8201 based mechanisms. 193 3. Requirements Language 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 197 "OPTIONAL" in this document are to be interpreted as described in BCP 198 14 [RFC2119] [RFC8174] when, and only when, they appear in all 199 capitals, as shown here. 201 4. Applicability Statements 203 This Hop-by-Hop Option header is intended to be used in environments 204 such as Data Centers and on paths between Data Centers, to allow them 205 to better take advantage of a path that is able to support a large 206 PMTU. For example, it helps inform a sender that the path includes 207 links that have a MTU of 9,000 Bytes. This has many performance 208 advantages compared to the current practice of limiting packets to 209 1280 Bytes. 211 The design of the option is sufficiently simple that it could be 212 executed on a router's fast path. To create critical mass for this 213 to happen will have to be a strong pull from router vendors 214 customers. This could be the case for connections within and between 215 Data Centers. 217 The method could also be useful in other environments, including the 218 general Internet. 220 5. IPv6 Minimum Path MTU Hop-by-Hop Option 222 The Minimum Path MTU Hop-by-Hop Option has the following format: 224 Option Option Option 225 Type Data Len Data 226 +--------+--------+--------+--------+---------+-------+-+ 227 |BBCTTTTT|00000100| Min-PMTU | Rtn-PMTU |R| 228 +--------+--------+--------+--------+---------+-------+-+ 230 Option Type: 232 BB 00 Skip over this option and continue processing. 234 C 1 Option data can change en route to the packet's final 235 destination. 237 TTTT 11110 Experimental Option Type from [IANA-HBH]. 239 Length: 4 The size of the each value field in Option Data 240 field supports Path MTU values from 0 to 65,535 octets. 242 Min-PMTU: n 16-bits. The minimum PMTU in octets, reflecting the 243 smallest link MTU that the packet experienced across 244 the path. This is called the Reported PMTU. A value 245 less than the IPv6 minimum link MTU [RFC8200] 246 should be ignored. 248 Rtn-PMTU: n 15-bits. The returned mimimum PMTU, carrying the 15 249 most significant bits of the latest received Min-PMTU 250 field. The value zero means that no Reported MTU is 251 being returned. 253 R n 1-bit. R-Flag. Set by the source to signal that 254 the destination should include the received 255 Reported PMTU in Rtn-PMTU field. 257 NOTE: The encoding of the final two octets (Rtn-PMTU and R-Flag) 258 could be implemented by a mask of the latest received Min-MTU value 259 with 0xFFFE, discarding the right-most bit and then performing a 260 logical 'OR' with the R-Flag value of the sender. 262 6. Router, Host, and Transport Behaviors 264 6.1. Router Behaviour 266 Routers that do not support Hop-by-Hop options SHOULD ignore this 267 option and SHOULD forward the packet. 269 Routers that support Hop-by-Hop Options, but do not recognize this 270 option SHOULD ignore the option and SHOULD forward the packet. 272 Routers that recognize this option SHOULD compare the Reported PMTU 273 in the Min-PMTU field and the MTU configured for the outgoing link. 274 If the MTU of the outgoing link is less than the Reported PMTU, the 275 router rewrites the Reported PMTU in the Option to use the smaller 276 value. 278 The router MUST ignore and not change the Rtn-PMTU field and R-Flag 279 in the option. 281 Discussion: 283 o The design of this Hop-by-Hop Option makes it feasible to be 284 implemented within the fast path of a router, because the required 285 processing is simple. 287 6.2. Host Behavior 289 The source host that supports this option SHOULD create a packet with 290 this Hop-by-Hop Option and fill the Min-PMTU field of the option with 291 the MTU of configured for the link over which it will send the packet 292 on the next hop towards the destination. 294 The source host may request that the destination host return the 295 received minimum MTU value by setting the R-Flag in the option. This 296 will cause the destination host to include a PMTU option in an 297 outgoing packet. 299 Discussion: 301 o This option does not need to be sent in all packets belonging to a 302 flow. A transport protocol (or packetization layer) can set this 303 option only on specific packets used to test the path. 305 o In the case of TCP, the option could be included in packets 306 carrying a SYN segment as part of the connection set up, or can 307 periodically be sent in packets carrying other segments. 308 Including this packet in a SYN could increase the probability that 309 SYN segment is lost, when routers on the path drop packets with 310 this option. Including this option in a large packet is not 311 likely to be useful, since the large packet might itself also be 312 dropped by a link along the path with a smaller MTU, preventing 313 the Reported PMTU information from reaching the Destination node. 315 o The use with datagram transport protocols (e.g. UDP) is harder to 316 characterize because applications using datagram transports range 317 from very short-lived (low data-volume applications) exchanges, to 318 longer (bulk) exchanges of packets between the Source and 319 Destination nodes [RFC8085]. 321 o For applications that use Anycast, this option should be included 322 in all packets as the actual destination will vary due to the 323 nature of Anycast. 325 o Simple-exchange protocols (i.e low data-volume applications 326 [RFC8085] that only send one or a few packets per transaction, 327 could be optimized by assuming that the Path MTU is symmetrical, 328 that is where the Path MTU is the same in both directions, or at 329 least not smaller in the return path. This optimisation does not 330 hold when the paths are not symmetric. 332 o The use of this option with DNS and DNSSEC over UDP ought to work 333 as long as the paths are symmetric. The DNS server will learn the 334 Path MTU from the DNS query messages. If the return Path MTU is 335 smaller, then the large DNSSEC response may be dropped and the 336 known problems with PMTUD will occur. DNS and DNSSEC over 337 transport protocols that can carry the Path MTU should work. 339 The Source Host can request the destination host to send a packet 340 carrying the PMTU Option using the R-Flag. 342 A Destination Host SHOULD respond to each packet received with the 343 R-Flag set, by setting the PMTU Option in the next packet that it 344 sends to the Source Host by the same upper layer protocol instance. 346 The upper layer protocol MAY generate a packet when any of these 347 conditions is met when the R Flag is set in the PMTU Option and 348 either: 350 o It is the first Reported PMTU value it has received from the 351 Source. 353 o The Reported PMTU value is lower than previously received. 355 The R-Flag SHOULD NOT be set when the PMTU Option was sent solely to 356 carry the feedback of a Reported PMTU. 358 The PMTU Option sent back to the source SHOULD contain the outgoing 359 link MTU in Min-PMTU field and SHOULD set the last Received PMTU in 360 the Rtn-PMTU field. If these values are not present the field MUST 361 be set to zero. 363 For a connection-oriented upper layer protocol, this could be 364 implemented by saving the value of the last received option within 365 the connection context. This last received value is then used to set 366 the return Path MTU field for all packets belonging to this flow that 367 carry the IPv6 Minimum Path MTU Hop-by-Hop Option. 369 A connection-less protocol, e.g., based on UDP, requires the 370 application to be updated to cache the Received PMTU value, and to 371 ensure that this corresponding value is used to set the last Received 372 PMTU in the Rtn-PMTU field of any PMTU Option that it sends. 374 NOTE: The Rtn-PMTU value is specific to the instance of the upper 375 layer protocol (i.e. matching the IPv6 flow ID, port-fields in UDP or 376 the SPI in IPsec, etc), not the protocol itself, because network 377 devices can make forwarding decisions that impact the PMTU based on 378 the presence and values of these upper layer fields, and therefore 379 these fields need to correspond to those of the packets for the flow 380 received by the Destination Host set to ensure feedback is provided 381 to the corresponding Source Host. 383 NOTE: An upper layer protocol that send packets from the Destination 384 Host towards the Source Host less frequently than the Destination 385 Host receives packets from the Source Host, provides less frequent 386 feedback of the received Min-PMTU value. However, it will always 387 needs to send the most recent value. 389 Discussion: 391 o A simple mechanism could only send an MTU Option with the Rtn-PMTU 392 field filled in the first time this option is received or when the 393 Received PMTU is reduced. This is good because it limits the 394 number sent, but there is no provision for retransmission of the 395 PMTU Option fails to reach the sender, or the sender looses state. 397 o The Reported PMTU value could increase or decrease over time. For 398 instance, it would increase when the path changes and the packets 399 become then forwarded over a link with a MTU larger than the link 400 previously used. 402 6.3. Transport Behavior 404 A transport endpoint using this option needs to use a method to 405 verify the information provided by this option. 407 The Received PMTU does not necessarily reflect the actual PMTU 408 between the sender and destination. Care therefore needs to be 409 exercised in using this value at the sender. Specifically: 411 o If the Received PMTU value returned by the Destination is the same 412 as the initial Reported PMTU value, there could still be a router 413 or layer 2 device on the path that does not support this PMTU. 414 The usable PMTU therefore needs to be confirmed. 416 o If the Received PMTU value returned by the Destination is smaller 417 than the initial Reported PMTU value, this is an indication that 418 there is at least one router in the path with a smaller MTU. 419 There could still be another router or layer 2 device on the path 420 that does not support this MTU. 422 o If the Received PMTU value returned by the Destination is larger 423 than the initial Reported PMTU value, this may be a corrupted, 424 delayed or mis-ordered response, and SHOULD be ignored. 426 A sender needs to discriminate between the Received PMTU value in a 427 PTB message generated in response to a Hop-by-Hop option requesting 428 this, and a PTB message received from a router on the path. 430 A PMTUD or PLPMTUD method could use the Received PMTU value as an 431 initial target size to probe the path. This can significantly 432 decrease the number of probe attempts (and hence time taken) to 433 arrive at a workable PMTU. It has the potential to complete 434 discovery of the correct value in a single Round Trip Time (RTT), 435 even over paths that may have successive links configured with lower 436 MTUs. 438 Since the method can delay notification of an increase in the actual 439 PMTU, a sender with a link MTU larger than the current PMTU SHOULD 440 periodically probe for a PMTU value that is larger than the Received 441 PMTU value. This specification does not define an interval for the 442 time between probes. 444 Since the option consumes less capacity than an a full probe packet, 445 there may be advantage in using this to detect a change in the path 446 characteristics. 448 NOTE: Further details to be included in next version. 450 NOTE: A future version of the document will consider more the impact 451 of Equal Cost Multipath (ECMP). Specifically, whether a Received 452 PMTU value should be maintained by the method for each transport 453 endpoint, or for each network address, and how these are best used by 454 methods such as PLPMTUD or DPLPMTUD. 456 7. IANA Considerations 458 No IANA assignments are requested. Document uses experimental option 459 from [IANA-HBH]. 461 8. Security Considerations 463 The method has no way to protect the destination from off-path attack 464 using this option in packets that do not originate from the source. 465 This attack could be used to inflate or reduce the size of the 466 reported PMTU. Mechanisms to provide this protection can be provided 467 at a higher layer (e.g., the transport packetization layer using 468 PLPMTUD or DPLPMTUD), where more information is available about the 469 size of packet that has successfully traversed a path. 471 The method solicits a response from the destination, which should be 472 used to generate a response to the IPv6 node originating the option 473 packet. A malicious attacker could generate a packet to the 474 destination for a previously inactive flow or one that advertises a 475 change in the size of the MTU for an active flow. This would create 476 additional work at the destination, and could induce creation of 477 state when a new flow is created. It could potentially result in 478 additional traffic on the return path to the sender, which could be 479 mitigated by limiting the rate at which responses are generated. 481 A sender MUST check the quoted packet within the PTB message to 482 validate that the message is in response to a packet that was 483 originated by the sender. This is intended to provide protection 484 against off-path insertion of ICMP PTB messages by an attacker trying 485 to disrupt the service. Messages that fail this check MAY be logged, 486 but the information they contain MUST be discarded. 488 TBD 490 9. Acknowledgments 492 A somewhat similar mechanism was proposed for IPv4 in 1988 in 493 [RFC1063] by Jeff Mogul, C. Kent, Craig Partridge, and Keith 494 McCloghire. It was later obsoleted in 1990 by [RFC1191] the current 495 deployed approach to Path MTU Discovery. 497 Helpful comments were received from Tom Herbert, Tom Jones, Fred 498 Templin, Ole Troan, [Your name here], and other members of the 6MAN 499 working group. 501 10. Change log [RFC Editor: Please remove] 503 draft-hinden-6man-mtu-option-02, 2019-July-5 505 o Changed option format to also include the Returned MTU value and 506 Return flag and made related text changes in Section 6.2 to 507 describe this behaviour. 509 o ICMP Packet Too Big messages are no longer used for feedback to 510 the Source host. 511 o Added to Acknowledgements Section that a similar mechanism was 512 proposed for IPv4 in 1988 in [RFC1063]. 513 o Editorial changes. 515 draft-hinden-6man-mtu-option-01, 2019-March-05 517 o Changed requested status from Standards Track to Experimental to 518 allow use of experimental option type (11110) to allow for 519 experimentation. Removed request for IANA Option assignment. 520 o Added Section 2 "Motivation and Problem Solved" section to better 521 describe what the purpose of this document is. 522 o Added Appendix A describing planned experiments and how the 523 results will be measured. 524 o Editorial changes. 526 draft-hinden-6man-mtu-option-00, 2018-Oct-16 528 o Initial draft. 530 11. References 532 11.1. Normative References 534 [IANA-HBH] 535 "Destination Options and Hop-by-Hop Options", 536 . 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 541 RFC2119, March 1997, . 544 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 545 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 546 May 2017, . 548 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 549 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/ 550 RFC8200, July 2017, . 553 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 554 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 555 DOI 10.17487/RFC8201, July 2017, . 558 11.2. Informative References 560 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 561 MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, 562 July 1988, . 564 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 565 DOI 10.17487/RFC1191, November 1990, . 568 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 569 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 570 December 1998, . 572 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 573 Virtualization Using Generic Routing Encapsulation", RFC 574 7637, DOI 10.17487/RFC7637, September 2015, 575 . 577 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 578 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 579 March 2017, . 581 Appendix A. Planned Experiments 583 TBD 585 This section will describe a set of experiments planned for the use 586 of the option defined in this document. There are many aspects of 587 the design that require experimental data or experience to evaluate 588 this experimental specification. 590 This includes experiments to understand the pathology of packets sent 591 with the specified option to determine the likelihood that they are 592 lost within specific types of network segment. 594 This includes consideration of the cost and alternatives for 595 providing the feedback required by the mechanism and how to 596 effectively limit the rate of transmission. 598 This includes consideration of the potential for integration in 599 frameworks such as that offered by DPLPMTUD. 601 There are also security-related topics to be understood as described 602 in the Security Considerations (Section 8). 604 Authors' Addresses 606 Robert M. Hinden 607 Check Point Software 608 959 Skyway Road 609 San Carlos, CA 94070 610 USA 612 Email: bob.hinden@gmail.com 614 Godred Fairhurst 615 University of Aberdeen 616 School of Engineering 617 Fraser Noble Building 618 Aberdeen AB24 3UE 619 UK 621 Email: gorry@erg.abdn.ac.uk