idnits 2.17.1 draft-ietf-6man-rfc1981bis-07.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 == Line 186 has weird spacing: '...scovery proce...' == Line 733 has weird spacing: '...ent bit the...' == Line 735 has weird spacing: '...cussion sel...' == Line 738 has weird spacing: '...essages all...' == Line 741 has weird spacing: '... tables not...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 16, 2017) is 2537 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-6man-rfc2460bis-11 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-6man-rfc2460bis' -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. McCann 3 Internet-Draft Digital Equipment Corporation 4 Obsoletes: 1981 (if approved) S. Deering 5 Intended status: Standards Track Retired 6 Expires: November 17, 2017 J. Mogul 7 Digital Equipment Corporation 8 R. Hinden, Ed. 9 Check Point Software 10 May 16, 2017 12 Path MTU Discovery for IP version 6 13 draft-ietf-6man-rfc1981bis-07 15 Abstract 17 This document describes Path MTU Discovery for IP version 6. It is 18 largely derived from RFC 1191, which describes Path MTU Discovery for 19 IP version 4. It obsoletes RFC1981. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 17, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 6 71 5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 7 72 5.1. Layering . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.2. Storing PMTU information . . . . . . . . . . . . . . . . 8 74 5.3. Purging stale PMTU information . . . . . . . . . . . . . 10 75 5.4. Packetization layer actions . . . . . . . . . . . . . . . 11 76 5.5. Issues for other transport protocols . . . . . . . . . . 12 77 5.6. Management interface . . . . . . . . . . . . . . . . . . 13 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 9.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Appendix A. Comparison to RFC 1191 . . . . . . . . . . . . . . . 16 85 Appendix B. Changes Since RFC 1981 . . . . . . . . . . . . . . . 16 86 B.1. Change History Since RFC1981 . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 When one IPv6 node has a large amount of data to send to another 92 node, the data is transmitted in a series of IPv6 packets. These 93 packets can have a size less than or equal to the Path MTU (PMTU). 94 Alternatively, they can be larger packets that are fragmented into a 95 series of fragments each with a size less than or equal to the PMTU. 97 It is usually preferable that these packets be of the largest size 98 that can successfully traverse the path from the source node to the 99 destination node without the need for IPv6 fragmentation. This 100 packet size is referred to as the Path MTU, and it is equal to the 101 minimum link MTU of all the links in a path. This document defines a 102 standard mechanism for a node to discover the PMTU of an arbitrary 103 path. 105 IPv6 nodes should implement Path MTU Discovery in order to discover 106 and take advantage of paths with PMTU greater than the IPv6 minimum 107 link MTU [I-D.ietf-6man-rfc2460bis]. A minimal IPv6 implementation 108 (e.g., in a boot ROM) may choose to omit implementation of Path MTU 109 Discovery. 111 Nodes not implementing Path MTU Discovery must use the IPv6 minimum 112 link MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet 113 size. In most cases, this will result in the use of smaller packets 114 than necessary, because most paths have a PMTU greater than the IPv6 115 minimum link MTU. A node sending packets much smaller than the Path 116 MTU allows is wasting network resources and probably getting 117 suboptimal throughput. 119 Nodes implementing Path MTU Discovery and sending packets larger than 120 the IPv6 minimum link MTU are susceptible to problematic connectivity 121 if ICMPv6 [ICMPv6] messages are blocked or not transmitted. For 122 example, this will result in connections that complete the TCP three- 123 way handshake correctly but then hang when data is transferred. This 124 state is referred to as a black hole connection [RFC2923]. Path MTU 125 Discovery relies on such messages to determine the MTU of the path. 127 An extension to Path MTU Discovery defined in this document can be 128 found in [RFC4821]. RFC4821 defines a method for Packetization Layer 129 Path MTU Discovery (PLPMTUD) designed for use over paths where 130 delivery of ICMPv6 messages to a host is not assured. 132 Note: This document is an update to [RFC1981] that was published 133 prior to [RFC2119] being published. Consequently although RFC1981 134 used the "should/must" style language in upper and lower case, the 135 document does not cite the RFC2119 definitions and only uses lower 136 case for these words. 138 2. Terminology 140 node a device that implements IPv6. 142 router a node that forwards IPv6 packets not explicitly 143 addressed to itself. 145 host any node that is not a router. 147 upper layer a protocol layer immediately above IPv6. 148 Examples are transport protocols such as TCP and 149 UDP, control protocols such as ICMPv6, routing 150 protocols such as OSPF, and internet or lower- 151 layer protocols being "tunneled" over (i.e., 152 encapsulated in) IPv6 such as IPX, AppleTalk, or 153 IPv6 itself. 155 link a communication facility or medium over which 156 nodes can communicate at the link layer, i.e., 157 the layer immediately below IPv6. Examples are 158 Ethernets (simple or bridged); PPP links; X.25, 159 Frame Relay, or ATM networks; and internet (or 160 higher) layer "tunnels", such as tunnels over 161 IPv4 or IPv6 itself. 163 interface a node's attachment to a link. 165 address an IPv6-layer identifier for an interface or a 166 set of interfaces. 168 packet an IPv6 header plus payload. The packet can have 169 a size less than or equal to the PMTU. 170 Alternatively, this can be a larger packet that 171 is fragmented into a series of fragments each 172 with a size less than or equal to the PMTU. 174 link MTU the maximum transmission unit, i.e., maximum 175 packet size in octets, that can be conveyed in 176 one piece over a link. 178 path the set of links traversed by a packet between a 179 source node and a destination node. 181 path MTU the minimum link MTU of all the links in a path 182 between a source node and a destination node. 184 PMTU path MTU 186 Path MTU Discovery process by which a node learns the PMTU of a path 188 EMTU_S Effective MTU for sending, used by upper layer 189 protocols to limit the size of IP packets they 190 queue for sending [RFC6691] [RFC1122]. 192 EMTU_R Effective MTU for receiving, the largest packet 193 that can be reassembled at the receiver 194 [RFC1122]. 196 flow a sequence of packets sent from a particular 197 source to a particular (unicast or multicast) 198 destination for which the source desires special 199 handling by the intervening routers. 201 flow id a combination of a source address and a non-zero 202 flow label. 204 3. Protocol Overview 206 This memo describes a technique to dynamically discover the PMTU of a 207 path. The basic idea is that a source node initially assumes that 208 the PMTU of a path is the (known) MTU of the first hop in the path. 209 If any of the packets sent on that path are too large to be forwarded 210 by some node along the path, that node will discard them and return 211 ICMPv6 Packet Too Big (PTB) messages. Upon receipt of such a 212 message, the source node reduces its assumed PMTU for the path based 213 on the MTU of the constricting hop as reported in the Packet Too Big 214 message. The decreased PMTU causes the source to send smaller 215 packets or change EMTU_S to cause upper layer to reduce the size of 216 IP packets it sends. 218 The Path MTU Discovery process ends when the source node's estimate 219 of the PMTU is less than or equal to the actual PMTU. Note that 220 several iterations of the packet-sent/Packet-Too-Big-message-received 221 cycle may occur before the Path MTU Discovery process ends, as there 222 may be links with smaller MTUs further along the path. 224 Alternatively, the node may elect to end the discovery process by 225 ceasing to send packets larger than the IPv6 minimum link MTU. 227 The PMTU of a path may change over time, due to changes in the 228 routing topology. Reductions of the PMTU are detected by Packet Too 229 Big messages. To detect increases in a path's PMTU, a node 230 periodically increases its assumed PMTU. This will almost always 231 result in packets being discarded and Packet Too Big messages being 232 generated, because in most cases the PMTU of the path will not have 233 changed. Therefore, attempts to detect increases in a path's PMTU 234 should be done infrequently. 236 Path MTU Discovery supports multicast as well as unicast 237 destinations. In the case of a multicast destination, copies of a 238 packet may traverse many different paths to many different nodes. 239 Each path may have a different PMTU, and a single multicast packet 240 may result in multiple Packet Too Big messages, each reporting a 241 different next-hop MTU. The minimum PMTU value across the set of 242 paths in use determines the size of subsequent packets sent to the 243 multicast destination. 245 Note that Path MTU Discovery must be performed even in cases where a 246 node "thinks" a destination is attached to the same link as itself. 247 In a situation such as when a neighboring router acts as proxy [ND] 248 for some destination, the destination can appear to be directly 249 connected but it is in fact more than one hop away. 251 4. Protocol Requirements 253 As discussed in Section 1, IPv6 nodes are not required to implement 254 Path MTU Discovery. The requirements in this section apply only to 255 those implementations that include Path MTU Discovery. 257 Nodes should appropriately validate the payload of ICMPv6 PTB 258 messages to ensure these are received in response to transmitted 259 traffic (i.e., a reported error condition that corresponds to an IPv6 260 packet actually sent by the application) per [ICMPv6]. 262 If a node receives a Packet Too Big message reporting a next-hop MTU 263 that is less than the IPv6 minimum link MTU, it must discard it. A 264 node must not reduce its estimate of the Path MTU below the IPv6 265 minimum link MTU on receipt of an Packet Too Big message. 267 When a node receives a Packet Too Big message, it must reduce its 268 estimate of the PMTU for the relevant path, based on the value of the 269 MTU field in the message. The precise behavior of a node in this 270 circumstance is not specified, since different applications may have 271 different requirements, and since different implementation 272 architectures may favor different strategies. 274 After receiving a Packet Too Big message, a node must attempt to 275 avoid eliciting more such messages in the near future. The node must 276 reduce the size of the packets it is sending along the path. Using a 277 PMTU estimate larger than the IPv6 minimum link MTU may continue to 278 elicit Packet Too Big messages. Because each of these messages (and 279 the dropped packets they respond to) consume network resources, Nodes 280 using Path MTU Discovery must detect decreases in PMTU as fast as 281 possible. 283 Nodes may detect increases in PMTU, but because doing so requires 284 sending packets larger than the current estimated PMTU, and because 285 the likelihood is that the PMTU will not have increased, this must be 286 done at infrequent intervals. An attempt to detect an increase (by 287 sending a packet larger than the current estimate) must not be done 288 less than 5 minutes after a Packet Too Big message has been received 289 for the given path. The recommended setting for this timer is twice 290 its minimum value (10 minutes). 292 A node must not increase its estimate of the Path MTU in response to 293 the contents of a Packet Too Big message. A message purporting to 294 announce an increase in the Path MTU might be a stale packet that has 295 been floating around in the network, a false packet injected as part 296 of a denial-of-service attack, or the result of having multiple paths 297 to the destination, each with a different PMTU. 299 5. Implementation Issues 301 This section discusses a number of issues related to the 302 implementation of Path MTU Discovery. This is not a specification, 303 but rather a set of notes provided as an aid for implementers. 305 The issues include: 307 - What layer or layers implement Path MTU Discovery? 309 - How is the PMTU information cached? 311 - How is stale PMTU information removed? 313 - What must transport and higher layers do? 315 5.1. Layering 317 In the IP architecture, the choice of what size packet to send is 318 made by a protocol at a layer above IP. This memo refers to such a 319 protocol as a "packetization protocol". Packetization protocols are 320 usually transport protocols (for example, TCP) but can also be 321 higher-layer protocols (for example, protocols built on top of UDP). 323 Implementing Path MTU Discovery in the packetization layers 324 simplifies some of the inter-layer issues, but has several drawbacks: 325 the implementation may have to be redone for each packetization 326 protocol, it becomes hard to share PMTU information between different 327 packetization layers, and the connection-oriented state maintained by 328 some packetization layers may not easily extend to save PMTU 329 information for long periods. 331 It is therefore suggested that the IP layer store PMTU information 332 and that the ICMPv6 layer process received Packet Too Big messages. 333 The packetization layers may respond to changes in the PMTU by 334 changing the size of the messages they send. To support this 335 layering, packetization layers require a way to learn of changes in 336 the value of MMS_S, the "maximum send transport-message size" 337 [RFC1122]. 339 MMS_S is a transport message size calculated by subtracting the size 340 of the IPv6 header (including IPv6 extension headers) from the 341 largest IP packet that can be sent, EMTU_S. MMS_S is limited by a 342 combination of factors, including the PMTU, support for packet 343 fragmentation and reassembly, and the packet reassembly limit (see 344 [I-D.ietf-6man-rfc2460bis] section "Fragment Header"). When source 345 fragmentation is available, EMTU_S is set to EMTU_R, as indicated by 346 the receiver using an upper layer protocol or based on protocol 347 requirements (1500 octets for IPv6). When a message larger than PMTU 348 is to be transmitted, the source creates fragments, each limited by 349 PMTU. When source fragmentation is not desired, EMTU_S is set to 350 PMTU, and the upper layer protocol is expected to either perform its 351 own fragmentation and reassembly or otherwise limit the size of its 352 messages accordingly. 354 However, packetization layers are encouraged to avoid sending 355 messages that will require source fragmentation (for the case against 356 fragmentation, see [FRAG]). 358 5.2. Storing PMTU information 360 Ideally, a PMTU value should be associated with a specific path 361 traversed by packets exchanged between the source and destination 362 nodes. However, in most cases a node will not have enough 363 information to completely and accurately identify such a path. 364 Rather, a node must associate a PMTU value with some local 365 representation of a path. It is left to the implementation to select 366 the local representation of a path. For nodes with multiple 367 interfaces, Path MTU information should be maintained for each IPv6 368 link. 370 In the case of a multicast destination address, copies of a packet 371 may traverse many different paths to reach many different nodes. The 372 local representation of the "path" to a multicast destination must 373 represent a potentially large set of paths. 375 Minimally, an implementation could maintain a single PMTU value to be 376 used for all packets originated from the node. This PMTU value would 377 be the minimum PMTU learned across the set of all paths in use by the 378 node. This approach is likely to result in the use of smaller 379 packets than is necessary for many paths. In the case of multipath 380 routing (e.g., Equal Cost Multipath Routing, ECMP), a set of paths 381 can exist even for a single source and destination pair. 383 An implementation could use the destination address as the local 384 representation of a path. The PMTU value associated with a 385 destination would be the minimum PMTU learned across the set of all 386 paths in use to that destination. This approach will result in the 387 use of optimally sized packets on a per-destination basis. This 388 approach integrates nicely with the conceptual model of a host as 389 described in [ND]: a PMTU value could be stored with the 390 corresponding entry in the destination cache. 392 If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation 393 could use the flow id as the local representation of a path. Packets 394 sent to a particular destination but belonging to different flows may 395 use different paths, as with ECMP, in which the choice of path might 396 depending on the flow id. This approach might result in the use of 397 optimally sized packets on a per-flow basis, providing finer 398 granularity than PMTU values maintained on a per-destination basis. 400 For source routed packets (i.e. packets containing an IPv6 Routing 401 header [I-D.ietf-6man-rfc2460bis]), the source route may further 402 qualify the local representation of a path. 404 Initially, the PMTU value for a path is assumed to be the (known) MTU 405 of the first-hop link. 407 When a Packet Too Big message is received, the node determines which 408 path the message applies to based on the contents of the Packet Too 409 Big message. For example, if the destination address is used as the 410 local representation of a path, the destination address from the 411 original packet would be used to determine which path the message 412 applies to. 414 Note: if the original packet contained a Routing header, the 415 Routing header should be used to determine the location of the 416 destination address within the original packet. If Segments Left 417 is equal to zero, the destination address is in the Destination 418 Address field in the IPv6 header. If Segments Left is greater 419 than zero, the destination address is the last address 420 (Address[n]) in the Routing header. 422 The node then uses the value in the MTU field in the Packet Too Big 423 message as a tentative PMTU value or the IPv6 minimum link MTU if 424 that is larger, and compares the tentative PMTU to the existing PMTU. 425 If the tentative PMTU is less than the existing PMTU estimate, the 426 tentative PMTU replaces the existing PMTU as the PMTU value for the 427 path. 429 The packetization layers must be notified about decreases in the 430 PMTU. Any packetization layer instance (for example, a TCP 431 connection) that is actively using the path must be notified if the 432 PMTU estimate is decreased. 434 Note: even if the Packet Too Big message contains an Original 435 Packet Header that refers to a UDP packet, the TCP layer must be 436 notified if any of its connections use the given path. 438 Also, the instance that sent the packet that elicited the Packet Too 439 Big message should be notified that its packet has been dropped, even 440 if the PMTU estimate has not changed, so that it may retransmit the 441 dropped data. 443 Note: An implementation can avoid the use of an asynchronous 444 notification mechanism for PMTU decreases by postponing 445 notification until the next attempt to send a packet larger than 446 the PMTU estimate. In this approach, when an attempt is made to 447 SEND a packet that is larger than the PMTU estimate, the SEND 448 function should fail and return a suitable error indication. This 449 approach may be more suitable to a connectionless packetization 450 layer (such as one using UDP), which (in some implementations) may 451 be hard to "notify" from the ICMPv6 layer. In this case, the 452 normal timeout-based retransmission mechanisms would be used to 453 recover from the dropped packets. 455 It is important to understand that the notification of the 456 packetization layer instances using the path about the change in the 457 PMTU is distinct from the notification of a specific instance that a 458 packet has been dropped. The latter should be done as soon as 459 practical (i.e., asynchronously from the point of view of the 460 packetization layer instance), while the former may be delayed until 461 a packetization layer instance wants to create a packet. 463 5.3. Purging stale PMTU information 465 Internetwork topology is dynamic; routes change over time. While the 466 local representation of a path may remain constant, the actual 467 path(s) in use may change. Thus, PMTU information cached by a node 468 can become stale. 470 If the stale PMTU value is too large, this will be discovered almost 471 immediately once a large enough packet is sent on the path. No such 472 mechanism exists for realizing that a stale PMTU value is too small, 473 so an implementation should "age" cached values. When a PMTU value 474 has not been decreased for a while (on the order of 10 minutes), the 475 PMTU estimate should be set to the MTU of the first-hop link, and the 476 packetization layers should be notified of the change. This will 477 cause the complete Path MTU Discovery process to take place again. 479 Note: an implementation should provide a means for changing the 480 timeout duration, including setting it to "infinity". For 481 example, nodes attached to an FDDI link which is then attached to 482 the rest of the Internet via a small MTU serial line are never 483 going to discover a new non-local PMTU, so they should not have to 484 put up with dropped packets every 10 minutes. 486 One approach to implementing PMTU aging is to associate a timestamp 487 field with a PMTU value. This field is initialized to a "reserved" 488 value, indicating that the PMTU is equal to the MTU of the first hop 489 link. Whenever the PMTU is decreased in response to a Packet Too Big 490 message, the timestamp is set to the current time. 492 Once a minute, a timer-driven procedure runs through all cached PMTU 493 values, and for each PMTU whose timestamp is not "reserved" and is 494 older than the timeout interval: 496 - The PMTU estimate is set to the MTU of the first hop link. 498 - The timestamp is set to the "reserved" value. 500 - Packetization layers using this path are notified of the increase. 502 5.4. Packetization layer actions 504 A packetization layer (e.g., TCP) must use the PMTU for the path(s) 505 in use by a connection; it should not send segments that would result 506 in packets larger than the PMTU, except to probe during PMTU 507 discovery (this probe packet must not be fragmented to the PMTU). A 508 simple implementation could ask the IP layer for this value each time 509 it created a new segment, but this could be inefficient. An 510 implementation typically caches other values derived from the PMTU. 511 It may be simpler to receive asynchronous notification when the PMTU 512 changes, so that these variables may be also updated. 514 A TCP implementation must also store the Maximum Segment Size (MSS) 515 value received from its peer, which represents the EMTU_R, the 516 largest packet that can be reassembled by the receiver, and must not 517 send any segment larger than this MSS, regardless of the PMTU. 519 The value sent in the TCP MSS option is independent of the PMTU; it 520 is determined by the receiver reassembly limit EMTU_R. This MSS 521 option value is used by the other end of the connection, which may be 522 using an unrelated PMTU value. See [I-D.ietf-6man-rfc2460bis] 523 sections "Packet Size Issues" and "Maximum Upper-Layer Payload Size" 524 for information on selecting a value for the TCP MSS option. 526 Reception of a Packet Too Big message implies that a packet was 527 dropped by the node that sent the ICMPv6 message. A reliable upper 528 layer protocol will detect this loss by its own means, and recover it 529 by its normal retransmission methods. The retransmission could 530 result in delay, depending on the loss detection method used by the 531 upper layer protocol. If the Path MTU Discovery process requires 532 several steps to find the PMTU of the full path, this could finally 533 delay the retransmission by many round-trip times. 535 Alternatively, the retransmission could be done in immediate response 536 to a notification that the Path MTU was decreased, but only for the 537 specific connection specified by the Packet Too Big message, but only 538 based on the message and connection. The packet size used in the 539 retransmission should be no larger than the new PMTU. 541 Note: A packetization layer must not retransmit in response to 542 every Packet Too Big message, since a burst of several oversized 543 segments will give rise to several such messages and hence several 544 retransmissions of the same data. If the new estimated PMTU is 545 still wrong, the process repeats, and there is an exponential 546 growth in the number of superfluous segments sent. 547 Retransmissions can increase network load in response to 548 congestion, worsening that congestion. Any packetization layer 549 that uses retransmission is responsible for congestion control of 550 its retransmissions. See [RFC8085] for more information. 552 A loss caused by a PMTU probe indicated by the reception of a Packet 553 Too Big message must not be considered as a congestion notification 554 and hence the congestion window may not change. 556 5.5. Issues for other transport protocols 558 Some transport protocols are not allowed to repacketize when doing a 559 retransmission. That is, once an attempt is made to transmit a 560 segment of a certain size, the transport cannot split the contents of 561 the segment into smaller segments for retransmission. In such a 562 case, the original segment can be fragmented by the IP layer during 563 retransmission. Subsequent segments, when transmitted for the first 564 time, should be no larger than allowed by the Path MTU. 566 Path MTU Discovery for IPv4 [RFC1191] used NFS as an example of a 567 UDP-based application that benefits from PMTU discovery. Since then 568 [RFC7530], states the supported transport layer between NFS and IP 569 must be an IETF standardized transport protocol that is specified to 570 avoid network congestion; such transports include TCP, Stream Control 571 Transmission Protocol (SCTP) [RFC4960], and the Datagram Congestion 572 Control Protocol (DCCP) [RFC4340]. In this case, the transport is 573 responsible for ensuring that transmitted segments (except probes) 574 conform to the the Path MTU, including supporting PMTU discovery 575 probe transmissions as needed. 577 5.6. Management interface 579 It is suggested that an implementation provide a way for a system 580 utility program to: 582 - Specify that Path MTU Discovery not be done on a given path. 584 - Change the PMTU value associated with a given path. 586 The former can be accomplished by associating a flag with the path; 587 when a packet is sent on a path with this flag set, the IP layer does 588 not send packets larger than the IPv6 minimum link MTU. 590 These features might be used to work around an anomalous situation, 591 or by a routing protocol implementation that is able to obtain Path 592 MTU values. 594 The implementation should also provide a way to change the timeout 595 period for aging stale PMTU information. 597 6. Security Considerations 599 This Path MTU Discovery mechanism makes possible two denial-of- 600 service attacks, both based on a malicious party sending false Packet 601 Too Big messages to a node. 603 In the first attack, the false message indicates a PMTU much 604 smaller than reality. In response, the victim node should never 605 set its PMTU estimate below the IPv6 minimum link MTU. A sender 606 that falsely reduces to this MTU would observe suboptimal 607 performance. 609 In the second attack, the false message indicates a PMTU larger 610 than reality. If believed, this could cause temporary blockage as 611 the victim sends packets that will be dropped by some router. 612 Within one round-trip time, the node would discover its mistake 613 (receiving Packet Too Big messages from that router), but frequent 614 repetition of this attack could cause lots of packets to be 615 dropped. A node, however, must not raise its estimate of the PMTU 616 based on a Packet Too Big message, so should not be vulnerable to 617 this attack. 619 Both of these attacks can cause a black hole connection, that is, the 620 TCP three-way handshake completes correctly but the connection hangs 621 when data is transfered. 623 A malicious party could also cause problems if it could stop a victim 624 from receiving legitimate Packet Too Big messages, but in this case 625 there are simpler denial-of-service attacks available. 627 If ICMPv6 filtering prevents reception of ICMPv6 Packet Too Big 628 messages, the source will not learn the actual path MTU. 629 Packetization Layer Path MTU Discovery [RFC4821] does not rely upon 630 network support for ICMPv6 messages and is therefore considered more 631 robust than standard PMTUD. It is not susceptible to "black holed" 632 connections caused by filtering of ICMPv6 message. See [RFC4890] for 633 recommendations regarding filtering ICMPv6 messages. 635 7. Acknowledgements 637 We would like to acknowledge the authors of and contributors to 638 [RFC1191], from which the majority of this document was derived. We 639 would also like to acknowledge the members of the IPng working group 640 for their careful review and constructive criticisms. 642 8. IANA Considerations 644 This document does not have any IANA actions 646 9. References 648 9.1. Normative References 650 [I-D.ietf-6man-rfc2460bis] 651 <>, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 652 Specification", draft-ietf-6man-rfc2460bis-11 (work in 653 progress), April 2017. 655 [ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 656 Control Message Protocol (ICMPv6) for the Internet 657 Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 658 10.17487/RFC4443, March 2006, 659 . 661 9.2. Informative References 663 [FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", 664 In Proc. SIGCOMM '87 Workshop on Frontiers in Computer 665 Communications Technology , August 1987. 667 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 668 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 669 DOI 10.17487/RFC4861, September 2007, 670 . 672 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 673 Communication Layers", STD 3, RFC 1122, DOI 10.17487/ 674 RFC1122, October 1989, 675 . 677 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 678 DOI 10.17487/RFC1191, November 1990, 679 . 681 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 682 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 683 1996, . 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 687 RFC2119, March 1997, 688 . 690 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 691 2923, DOI 10.17487/RFC2923, September 2000, 692 . 694 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 695 Congestion Control Protocol (DCCP)", RFC 4340, DOI 696 10.17487/RFC4340, March 2006, 697 . 699 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 700 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 701 . 703 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 704 ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/ 705 RFC4890, May 2007, 706 . 708 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 709 RFC 4960, DOI 10.17487/RFC4960, September 2007, 710 . 712 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 713 RFC 6691, DOI 10.17487/RFC6691, July 2012, 714 . 716 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 717 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 718 March 2015, . 720 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 721 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 722 March 2017, . 724 Appendix A. Comparison to RFC 1191 726 This document is based in large part on RFC 1191, which describes 727 Path MTU Discovery for IPv4. Certain portions of RFC 1191 were not 728 needed in this document: 730 router specification Packet Too Big messages and corresponding 731 router behavior are defined in [ICMPv6] 733 Don't Fragment bit there is no DF bit in IPv6 packets 735 TCP MSS discussion selecting a value to send in the TCP MSS option 736 is discussed in [I-D.ietf-6man-rfc2460bis] 738 old-style messages all Packet Too Big messages report the MTU of 739 the constricting link 741 MTU plateau tables not needed because there are no old-style 742 messages 744 Appendix B. Changes Since RFC 1981 746 This document is based on RFC1981 has the following changes from 747 RFC1981: 749 o Clarified Section 1 "Introduction" that the purpose of PMTUD is to 750 reduce the need for IPv6 fragmentation. 752 o Added text to Section 1 "Introduction" about the effects on PMTUD 753 when ICMPv6 messages are blocked. 755 o Added Note to Introduction that document that this document 756 doesn't cite RFC2119 and only uses lower case "should/must" 757 language. Changed all upper case "should/must" to lower case. 759 o Added a short summary to the Section 1 "Introduction" of 760 Packetization Layer Path MTU Discovery ((PLPMTUD) and a reference 761 to RFC4821 that defines it. 763 o Aligned text in Section 2 "Terminology" to match current 764 packetization layer terminology. 766 o Added clarification in Section 4 "Protocol Requirements" that 767 nodes should validate the payload of ICMP PTB message per RFC4443, 768 and that nodes should detect decreases in PMTU as fast as 769 possible. 771 o Remove Note from Section 4 "Protocol Requirements" about a Packet 772 Too Big message reporting a next-hop MTU that is less than the 773 IPv6 minimum link MTU because this was removed from 774 [I-D.ietf-6man-rfc2460bis]. 776 o Added clarification in Section 5.2 "Storing PMTU information" to 777 discard an ICMPv6 Packet Too Big message if it contains a MTU less 778 than the IPv6 minimum link MTU. 780 o Added clarification Section 5.2 "Storing PMTU information" that 781 nodes with multiple interface, Path MTU information should be 782 stored for each link. 784 o Removed text in Section 5.2 "Storing PMTU information" about the 785 RH0 routing header because it was deprecated by RFC5095. 787 o Removed text about obsolete security classification from 788 Section 5.2 "Storing PMTU information". 790 o Changed title of Section 5.4 to "Packetization Layer actions" and 791 changed to text in the first paragraph to to generalize this 792 section to cover all packetization layers, not just TCP. 794 o Clarified text in Section 5.4 "Packetization Layer actions" to use 795 normal packetization layer retransmission methods. 797 o Removed text in Section 5.4 "Packetization Layer actions" that 798 described 4.2 BSD because it is obsolete, and removed reference to 799 TP4. 801 o Updated text in Section 5.5 "Issues for other transport protocols" 802 about NFS including adding a current reference to NFS and removing 803 obsolete text. 805 o Added paragraph to Section 6 "Security Considerations" about black 806 hole connections if PTB messages are not received, and comparison 807 to PLPMTD. 809 o Editorial Changes. 811 B.1. Change History Since RFC1981 813 NOTE TO RFC EDITOR: Please remove this subsection prior to RFC 814 Publication 815 This section describes change history made in each Internet Draft 816 that went into producing this version. The numbers identify the 817 Internet-Draft version in which the change was made. 819 Working Group Internet Drafts 821 07) Changes from the IESG Discuss comments from IESG reviews. 822 The changes include: 824 o Added Note to Introduction that document that this 825 document doesn't cite RFC2119 and only uses lower case 826 "should/must" language. Changed all upper case "should/ 827 must" to lower case. 829 o Added references for EMTU_S and EMTU_R. 831 o Added clarification to Section 4 "Protocol Requirements" 832 that nodes should detect decreases in PMTU as fast as 833 possible. 835 o Added clarification Section 5.2 "Storing PMTU information" 836 that nodes with multiple interface, Path MTU information 837 should be stored for each link. 839 o Removed text in Section 5.2 about Retransmission because 840 it was unneeded. 842 o Removed text in Section 5.3 about Retransmission because 843 it was unneeded. 845 o Rewrote text in Section 5.4 "Packetization Layer actions" 846 regarding reception to make it clearer. 848 o Rewrote the text at the end of Section 5.4 to remove 849 unnecessary details and clarify not change congestion 850 window. 852 o Added references in Section 5.5 for SCTP and added DCCP 853 (and reference) the list of examples. 855 o Added paragraph to Section 5.5 "Security Considerations" 856 about black hole connections if PTB messages are not 857 received, and comparison to PLPMTD. 859 07) Editorial changes. 861 06) Revised Appendix B "Changes since RFC1981" to have a summary 862 of changes since RFC1981 and a separate subsection with a 863 change history of each Internet Draft. This subsection will 864 be removed when the RFC is published. 866 06) Editorial changes based on comments received after publishing 867 the -05 draft. 869 05) Changes based on IETF last call reviews by Gorry Fairhurst, 870 Joe Touch, Susan Hares, Stewart Bryant, Rifaat Shekh-Yusef, 871 and Donald Eastlake. This includes includes: 873 o Clarify that the purpose of PMTUD is to reduce the need 874 for IPv6 Fragmentation. 876 o Added text to Introduction about effects on PMTUD when 877 ICMPv6 messages are blocked. 879 o Clarified in Section 4. that nodes should validate the 880 payload of ICMPv6 PTB messages per RFC4443. 882 o Removed text in Section 5.2 about the number of paths to a 883 destination. 885 o Changed title of Section 5.4 to "Packetization layer 886 actions". 888 o Clarified first paragraph in Section 5.4 to to cover all 889 packetization layers, not just TCP. 891 o Clarified text in Section 5.4 to use normal retransmission 892 methods. 894 o Add clarification to Note in Section 5.4 about 895 retransmissions. 897 o Removed text in Section 5.4 that described 4.2BSD as it is 898 now obsolete. 900 o Removed reference to TP4 in Section 5.5. 902 o Updated text in Section 5.5 about NFS including adding a 903 current reference to NFS and removing obsolete text. 905 o Revised text in Section 6 to clarify first attack 906 response. 908 o Added new text in Section 6 to clarify the effect of 909 ICMPv6 filtering on PMTUD. 911 o Aligned terminology for the packetization layer 912 terminology. 914 o Editorial changes. 916 04) Changes based on AD Evaluation including removing details 917 about RFC4821 algorithm in Section 1, remove text about 918 decrementing hop limit from Section 3, and removed text about 919 obsolete security classifications from Section 5.2. 921 04) Editorial changes and clarification in Section 5.2 based on 922 IP Directorate review by Donald Eastlake 924 03) Remove text in Section 5.3 regarding RH0 since it was 925 deprecated by RFC5095 927 02) Clarified in Section 3 that ICMPv6 Packet Too Big should be 928 sent even if the node doesn't decrement the hop limit 930 01) Revised the text about PLPMTUD to use the word "path". 932 01) Editorial changes. 934 00) Added text to discard an ICMPv6 Packet Too Big message 935 containing an MTU less than the IPv6 minimum link MTU. 937 00) Revision of text regarding RFC4821. 939 00) Added R. Hinden as Editor to facilitate ID submission. 941 00) Editorial changes. 943 Individual Internet Drafts 945 01) Remove Note about a Packet Too Big message reporting a next- 946 hop MTU that is less than the IPv6 minimum link MTU. This 947 was removed from [I-D.ietf-6man-rfc2460bis]. 949 01) Include a link to RFC4821 along with a short summary of what 950 it does. 952 01) Assigned references to informative and normative. 954 01) Editorial changes. 956 00) Establish a baseline from RFC1981. The only intended changes 957 are formatting (XML is slightly different from .nroff), 958 differences between an RFC and Internet Draft, fixing a few 959 ID Nits, updating references, and updates to the authors 960 information. There should not be any content changes to the 961 specification. 963 Authors' Addresses 965 Jack McCann 966 Digital Equipment Corporation 968 Stephen E. Deering 969 Retired 970 Vancouver, British Columbia 971 Canada 973 Jeffrey Mogul 974 Digital Equipment Corporation 976 Robert M. Hinden (editor) 977 Check Point Software 978 959 Skyway Road 979 San Carlos, CA 94070 980 USA 982 Email: bob.hinden@gmail.com