idnits 2.17.1 draft-ietf-6man-rfc1981bis-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 99: '... IPv6 nodes SHOULD implement Path MT...' RFC 2119 keyword, line 228: '...et Too Big message, it MUST reduce its...' RFC 2119 keyword, line 235: '...oo Big message, a node MUST attempt to...' RFC 2119 keyword, line 236: '...ges in the near future. The node MUST...' RFC 2119 keyword, line 241: '... node MUST force the Path MTU Discov...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 167 has weird spacing: '...scovery proce...' == Line 687 has weird spacing: '...ent bit the...' == Line 689 has weird spacing: '...cussion sel...' == Line 692 has weird spacing: '...essages all...' == Line 695 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 (April 27, 2016) is 2920 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-04 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-6man-rfc2460bis' Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 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: October 29, 2016 J. Mogul 7 Digital Equipment Corporation 8 R. Hinden, Ed. 9 Check Point Software 10 April 27, 2016 12 Path MTU Discovery for IP version 6 13 draft-ietf-6man-rfc1981bis-02 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 October 29, 2016. 38 Copyright Notice 40 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5 71 5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 6 72 5.1. Layering . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5.2. Storing PMTU information . . . . . . . . . . . . . . . . 7 74 5.3. Purging stale PMTU information . . . . . . . . . . . . . 10 75 5.4. TCP layer actions . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . 15 85 Appendix B. Changes Since RFC 1981 . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 When one IPv6 node has a large amount of data to send to another 91 node, the data is transmitted in a series of IPv6 packets. It is 92 usually preferable that these packets be of the largest size that can 93 successfully traverse the path from the source node to the 94 destination node. This packet size is referred to as the Path MTU 95 (PMTU), and it is equal to the minimum link MTU of all the links in a 96 path. IPv6 defines a standard mechanism for a node to discover the 97 PMTU of an arbitrary path. 99 IPv6 nodes SHOULD implement Path MTU Discovery in order to discover 100 and take advantage of paths with PMTU greater than the IPv6 minimum 101 link MTU [I-D.ietf-6man-rfc2460bis]. A minimal IPv6 implementation 102 (e.g., in a boot ROM) may choose to omit implementation of Path MTU 103 Discovery. 105 Nodes not implementing Path MTU Discovery use the IPv6 minimum link 106 MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet size. 107 In most cases, this will result in the use of smaller packets than 108 necessary, because most paths have a PMTU greater than the IPv6 109 minimum link MTU. A node sending packets much smaller than the Path 110 MTU allows is wasting network resources and probably getting 111 suboptimal throughput. 113 An extension to Path MTU Discovery defined in this document can be 114 found in [RFC4821]. It defines a method for Packetization Layer Path 115 MTU Discovery (PLPMTUD) designed for use over paths where delivery of 116 ICMP messages to a host is not assured. In this algorithm, the 117 proper MTU is determined by starting with small packets and probing 118 with successively larger packets. The bulk of the algorithm is 119 implemented above IP, in the transport layer (e.g., TCP) or other 120 "Packetization Protocol" that is responsible for determining packet 121 boundaries. 123 2. Terminology 125 node a device that implements IPv6. 127 router a node that forwards IPv6 packets not explicitly 128 addressed to itself. 130 host any node that is not a router. 132 upper layer a protocol layer immediately above IPv6. 133 Examples are transport protocols such as TCP and 134 UDP, control protocols such as ICMP, routing 135 protocols such as OSPF, and internet or lower- 136 layer protocols being "tunneled" over (i.e., 137 encapsulated in) IPv6 such as IPX, AppleTalk, or 138 IPv6 itself. 140 link a communication facility or medium over which 141 nodes can communicate at the link layer, i.e., 142 the layer immediately below IPv6. Examples are 143 Ethernets (simple or bridged); PPP links; X.25, 144 Frame Relay, or ATM networks; and internet (or 145 higher) layer "tunnels", such as tunnels over 146 IPv4 or IPv6 itself. 148 interface a node's attachment to a link. 150 address an IPv6-layer identifier for an interface or a 151 set of interfaces. 153 packet an IPv6 header plus payload. 155 link MTU the maximum transmission unit, i.e., maximum 156 packet size in octets, that can be conveyed in 157 one piece over a link. 159 path the set of links traversed by a packet between a 160 source node and a destination node. 162 path MTU the minimum link MTU of all the links in a path 163 between a source node and a destination node. 165 PMTU path MTU 167 Path MTU Discovery process by which a node learns the PMTU of a path 169 flow a sequence of packets sent from a particular 170 source to a particular (unicast or multicast) 171 destination for which the source desires special 172 handling by the intervening routers. 174 flow id a combination of a source address and a non-zero 175 flow label. 177 3. Protocol Overview 179 This memo describes a technique to dynamically discover the PMTU of a 180 path. The basic idea is that a source node initially assumes that 181 the PMTU of a path is the (known) MTU of the first hop in the path. 182 If any of the packets sent on that path are too large to be forwarded 183 by some node (regardless of whether it decrements the Hop Limit) 184 along the path, that node will discard them and return ICMPv6 Packet 185 Too Big messages [ICMPv6]. Upon receipt of such a message, the 186 source node reduces its assumed PMTU for the path based on the MTU of 187 the constricting hop as reported in the Packet Too Big message. 189 The Path MTU Discovery process ends when the node's estimate of the 190 PMTU is less than or equal to the actual PMTU. Note that several 191 iterations of the packet-sent/Packet-Too-Big-message-received cycle 192 may occur before the Path MTU Discovery process ends, as there may be 193 links with smaller MTUs further along the path. 195 Alternatively, the node may elect to end the discovery process by 196 ceasing to send packets larger than the IPv6 minimum link MTU. 198 The PMTU of a path may change over time, due to changes in the 199 routing topology. Reductions of the PMTU are detected by Packet Too 200 Big messages. To detect increases in a path's PMTU, a node 201 periodically increases its assumed PMTU. This will almost always 202 result in packets being discarded and Packet Too Big messages being 203 generated, because in most cases the PMTU of the path will not have 204 changed. Therefore, attempts to detect increases in a path's PMTU 205 should be done infrequently. 207 Path MTU Discovery supports multicast as well as unicast 208 destinations. In the case of a multicast destination, copies of a 209 packet may traverse many different paths to many different nodes. 210 Each path may have a different PMTU, and a single multicast packet 211 may result in multiple Packet Too Big messages, each reporting a 212 different next-hop MTU. The minimum PMTU value across the set of 213 paths in use determines the size of subsequent packets sent to the 214 multicast destination. 216 Note that Path MTU Discovery must be performed even in cases where a 217 node "thinks" a destination is attached to the same link as itself. 218 In a situation such as when a neighboring router acts as proxy [ND] 219 for some destination, the destination can to appear to be directly 220 connected but is in fact more than one hop away. 222 4. Protocol Requirements 224 As discussed in section 1, IPv6 nodes are not required to implement 225 Path MTU Discovery. The requirements in this section apply only to 226 those implementations that include Path MTU Discovery. 228 When a node receives a Packet Too Big message, it MUST reduce its 229 estimate of the PMTU for the relevant path, based on the value of the 230 MTU field in the message. The precise behavior of a node in this 231 circumstance is not specified, since different applications may have 232 different requirements, and since different implementation 233 architectures may favor different strategies. 235 After receiving a Packet Too Big message, a node MUST attempt to 236 avoid eliciting more such messages in the near future. The node MUST 237 reduce the size of the packets it is sending along the path. Using a 238 PMTU estimate larger than the IPv6 minimum link MTU may continue to 239 elicit Packet Too Big messages. Since each of these messages (and 240 the dropped packets they respond to) consume network resources, the 241 node MUST force the Path MTU Discovery process to end. 243 Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast 244 as possible. Nodes MAY detect increases in PMTU, but because doing 245 so requires sending packets larger than the current estimated PMTU, 246 and because the likelihood is that the PMTU will not have increased, 247 this MUST be done at infrequent intervals. An attempt to detect an 248 increase (by sending a packet larger than the current estimate) MUST 249 NOT be done less than 5 minutes after a Packet Too Big message has 250 been received for the given path. The recommended setting for this 251 timer is twice its minimum value (10 minutes). 253 A node MUST NOT reduce its estimate of the Path MTU below the IPv6 254 minimum link MTU. 256 If a node receives a Packet Too Big message reporting a next-hop MTU 257 that is less than the IPv6 minimum link MTU, it should discard it. 259 A node MUST NOT increase its estimate of the Path MTU in response to 260 the contents of a Packet Too Big message. A message purporting to 261 announce an increase in the Path MTU might be a stale packet that has 262 been floating around in the network, a false packet injected as part 263 of a denial-of-service attack, or the result of having multiple paths 264 to the destination, each with a different PMTU. 266 5. Implementation Issues 268 This section discusses a number of issues related to the 269 implementation of Path MTU Discovery. This is not a specification, 270 but rather a set of notes provided as an aid for implementors. 272 The issues include: 274 - What layer or layers implement Path MTU Discovery? 276 - How is the PMTU information cached? 278 - How is stale PMTU information removed? 280 - What must transport and higher layers do? 282 5.1. Layering 284 In the IP architecture, the choice of what size packet to send is 285 made by a protocol at a layer above IP. This memo refers to such a 286 protocol as a "packetization protocol". Packetization protocols are 287 usually transport protocols (for example, TCP) but can also be 288 higher-layer protocols (for example, protocols built on top of UDP). 290 Implementing Path MTU Discovery in the packetization layers 291 simplifies some of the inter-layer issues, but has several drawbacks: 292 the implementation may have to be redone for each packetization 293 protocol, it becomes hard to share PMTU information between different 294 packetization layers, and the connection-oriented state maintained by 295 some packetization layers may not easily extend to save PMTU 296 information for long periods. 298 It is therefore suggested that the IP layer store PMTU information 299 and that the ICMP layer process received Packet Too Big messages. 300 The packetization layers may respond to changes in the PMTU, by 301 changing the size of the messages they send. To support this 302 layering, packetization layers require a way to learn of changes in 303 the value of MMS_S, the "maximum send transport-message size". The 304 MMS_S is derived from the Path MTU by subtracting the size of the 305 IPv6 header plus space reserved by the IP layer for additional 306 headers (if any). 308 It is possible that a packetization layer, perhaps a UDP application 309 outside the kernel, is unable to change the size of messages it 310 sends. This may result in a packet size that exceeds the Path MTU. 311 To accommodate such situations, IPv6 defines a mechanism that allows 312 large payloads to be divided into fragments, with each fragment sent 313 in a separate packet (see [I-D.ietf-6man-rfc2460bis] section 314 "Fragment Header"). However, packetization layers are encouraged to 315 avoid sending messages that will require fragmentation (for the case 316 against fragmentation, see [FRAG]). 318 5.2. Storing PMTU information 320 Ideally, a PMTU value should be associated with a specific path 321 traversed by packets exchanged between the source and destination 322 nodes. However, in most cases a node will not have enough 323 information to completely and accurately identify such a path. 324 Rather, a node must associate a PMTU value with some local 325 representation of a path. It is left to the implementation to select 326 the local representation of a path. 328 In the case of a multicast destination address, copies of a packet 329 may traverse many different paths to reach many different nodes. The 330 local representation of the "path" to a multicast destination must in 331 fact represent a potentially large set of paths. 333 Minimally, an implementation could maintain a single PMTU value to be 334 used for all packets originated from the node. This PMTU value would 335 be the minimum PMTU learned across the set of all paths in use by the 336 node. This approach is likely to result in the use of smaller 337 packets than is necessary for many paths. 339 An implementation could use the destination address as the local 340 representation of a path. The PMTU value associated with a 341 destination would be the minimum PMTU learned across the set of all 342 paths in use to that destination. The set of paths in use to a 343 particular destination is expected to be small, in many cases 344 consisting of a single path. This approach will result in the use of 345 optimally sized packets on a per-destination basis. This approach 346 integrates nicely with the conceptual model of a host as described in 347 [ND]: a PMTU value could be stored with the corresponding entry in 348 the destination cache. 350 If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation 351 could use the flow id as the local representation of a path. Packets 352 sent to a particular destination but belonging to different flows may 353 use different paths, with the choice of path depending on the flow 354 id. This approach will result in the use of optimally sized packets 355 on a per-flow basis, providing finer granularity than PMTU values 356 maintained on a per-destination basis. 358 For source routed packets (i.e. packets containing an IPv6 Routing 359 header [I-D.ietf-6man-rfc2460bis]), the source route may further 360 qualify the local representation of a path. In particular, a packet 361 containing a type 0 Routing header in which all bits in the Strict/ 362 Loose Bit Map are equal to 1 contains a complete path specification. 363 An implementation could use source route information in the local 364 representation of a path. 366 Note: Some paths may be further distinguished by different 367 security classifications. The details of such classifications are 368 beyond the scope of this memo. 370 Initially, the PMTU value for a path is assumed to be the (known) MTU 371 of the first-hop link. 373 When a Packet Too Big message is received, the node determines which 374 path the message applies to based on the contents of the Packet Too 375 Big message. For example, if the destination address is used as the 376 local representation of a path, the destination address from the 377 original packet would be used to determine which path the message 378 applies to. 380 Note: if the original packet contained a Routing header, the 381 Routing header should be used to determine the location of the 382 destination address within the original packet. If Segments Left 383 is equal to zero, the destination address is in the Destination 384 Address field in the IPv6 header. If Segments Left is greater 385 than zero, the destination address is the last address 386 (Address[n]) in the Routing header. 388 The node then uses the value in the MTU field in the Packet Too Big 389 message as a tentative PMTU value, and compares the tentative PMTU to 390 the existing PMTU. If the tentative PMTU is less than the existing 391 PMTU estimate, the tentative PMTU replaces the existing PMTU as the 392 PMTU value for the path. 394 The packetization layers must be notified about decreases in the 395 PMTU. Any packetization layer instance (for example, a TCP 396 connection) that is actively using the path must be notified if the 397 PMTU estimate is decreased. 399 Note: even if the Packet Too Big message contains an Original 400 Packet Header that refers to a UDP packet, the TCP layer must be 401 notified if any of its connections use the given path. 403 Also, the instance that sent the packet that elicited the Packet Too 404 Big message should be notified that its packet has been dropped, even 405 if the PMTU estimate has not changed, so that it may retransmit the 406 dropped data. 408 Note: An implementation can avoid the use of an asynchronous 409 notification mechanism for PMTU decreases by postponing 410 notification until the next attempt to send a packet larger than 411 the PMTU estimate. In this approach, when an attempt is made to 412 SEND a packet that is larger than the PMTU estimate, the SEND 413 function should fail and return a suitable error indication. This 414 approach may be more suitable to a connectionless packetization 415 layer (such as one using UDP), which (in some implementations) may 416 be hard to "notify" from the ICMP layer. In this case, the normal 417 timeout-based retransmission mechanisms would be used to recover 418 from the dropped packets. 420 It is important to understand that the notification of the 421 packetization layer instances using the path about the change in the 422 PMTU is distinct from the notification of a specific instance that a 423 packet has been dropped. The latter should be done as soon as 424 practical (i.e., asynchronously from the point of view of the 425 packetization layer instance), while the former may be delayed until 426 a packetization layer instance wants to create a packet. 427 Retransmission should be done for only for those packets that are 428 known to be dropped, as indicated by a Packet Too Big message. 430 5.3. Purging stale PMTU information 432 Internetwork topology is dynamic; routes change over time. While the 433 local representation of a path may remain constant, the actual 434 path(s) in use may change. Thus, PMTU information cached by a node 435 can become stale. 437 If the stale PMTU value is too large, this will be discovered almost 438 immediately once a large enough packet is sent on the path. No such 439 mechanism exists for realizing that a stale PMTU value is too small, 440 so an implementation should "age" cached values. When a PMTU value 441 has not been decreased for a while (on the order of 10 minutes), the 442 PMTU estimate should be set to the MTU of the first-hop link, and the 443 packetization layers should be notified of the change. This will 444 cause the complete Path MTU Discovery process to take place again. 446 Note: an implementation should provide a means for changing the 447 timeout duration, including setting it to "infinity". For 448 example, nodes attached to an FDDI link which is then attached to 449 the rest of the Internet via a small MTU serial line are never 450 going to discover a new non-local PMTU, so they should not have to 451 put up with dropped packets every 10 minutes. 453 An upper layer must not retransmit data in response to an increase in 454 the PMTU estimate, since this increase never comes in response to an 455 indication of a dropped packet. 457 One approach to implementing PMTU aging is to associate a timestamp 458 field with a PMTU value. This field is initialized to a "reserved" 459 value, indicating that the PMTU is equal to the MTU of the first hop 460 link. Whenever the PMTU is decreased in response to a Packet Too Big 461 message, the timestamp is set to the current time. 463 Once a minute, a timer-driven procedure runs through all cached PMTU 464 values, and for each PMTU whose timestamp is not "reserved" and is 465 older than the timeout interval: 467 - The PMTU estimate is set to the MTU of the first hop link. 469 - The timestamp is set to the "reserved" value. 471 - Packetization layers using this path are notified of the increase. 473 5.4. TCP layer actions 475 The TCP layer must track the PMTU for the path(s) in use by a 476 connection; it should not send segments that would result in packets 477 larger than the PMTU. A simple implementation could ask the IP layer 478 for this value each time it created a new segment, but this could be 479 inefficient. Moreover, TCP implementations that follow the "slow- 480 start" congestion-avoidance algorithm [CONG] typically calculate and 481 cache several other values derived from the PMTU. It may be simpler 482 to receive asynchronous notification when the PMTU changes, so that 483 these variables may be updated. 485 A TCP implementation must also store the MSS value received from its 486 peer, and must not send any segment larger than this MSS, regardless 487 of the PMTU. In 4.xBSD-derived implementations, this may require 488 adding an additional field to the TCP state record. 490 The value sent in the TCP MSS option is independent of the PMTU. 491 This MSS option value is used by the other end of the connection, 492 which may be using an unrelated PMTU value. See 493 [I-D.ietf-6man-rfc2460bis] sections "Packet Size Issues" and "Maximum 494 Upper-Layer Payload Size" for information on selecting a value for 495 the TCP MSS option. 497 When a Packet Too Big message is received, it implies that a packet 498 was dropped by the node that sent the ICMP message. It is sufficient 499 to treat this as any other dropped segment, and wait until the 500 retransmission timer expires to cause retransmission of the segment. 501 If the Path MTU Discovery process requires several steps to find the 502 PMTU of the full path, this could delay the connection by many round- 503 trip times. 505 Alternatively, the retransmission could be done in immediate response 506 to a notification that the Path MTU has changed, but only for the 507 specific connection specified by the Packet Too Big message. The 508 packet size used in the retransmission should be no larger than the 509 new PMTU. 511 Note: A packetization layer must not retransmit in response to 512 every Packet Too Big message, since a burst of several oversized 513 segments will give rise to several such messages and hence several 514 retransmissions of the same data. If the new estimated PMTU is 515 still wrong, the process repeats, and there is an exponential 516 growth in the number of superfluous segments sent. 518 This means that the TCP layer must be able to recognize when a 519 Packet Too Big notification actually decreases the PMTU that it 520 has already used to send a packet on the given connection, and 521 should ignore any other notifications. 523 Many TCP implementations incorporate "congestion avoidance" and 524 "slow-start" algorithms to improve performance [CONG]. Unlike a 525 retransmission caused by a TCP retransmission timeout, a 526 retransmission caused by a Packet Too Big message should not change 527 the congestion window. It should, however, trigger the slow-start 528 mechanism (i.e., only one segment should be retransmitted until 529 acknowledgements begin to arrive again). 531 TCP performance can be reduced if the sender's maximum window size is 532 not an exact multiple of the segment size in use (this is not the 533 congestion window size, which is always a multiple of the segment 534 size). In many systems (such as those derived from 4.2BSD), the 535 segment size is often set to 1024 octets, and the maximum window size 536 (the "send space") is usually a multiple of 1024 octets, so the 537 proper relationship holds by default. If Path MTU Discovery is used, 538 however, the segment size may not be a submultiple of the send space, 539 and it may change during a connection; this means that the TCP layer 540 may need to change the transmission window size when Path MTU 541 Discovery changes the PMTU value. The maximum window size should be 542 set to the greatest multiple of the segment size that is less than or 543 equal to the sender's buffer space size. 545 5.5. Issues for other transport protocols 547 Some transport protocols (such as ISO TP4 [ISOTP]) are not allowed to 548 repacketize when doing a retransmission. That is, once an attempt is 549 made to transmit a segment of a certain size, the transport cannot 550 split the contents of the segment into smaller segments for 551 retransmission. In such a case, the original segment can be 552 fragmented by the IP layer during retransmission. Subsequent 553 segments, when transmitted for the first time, should be no larger 554 than allowed by the Path MTU. 556 The Sun Network File System (NFS) uses a Remote Procedure Call (RPC) 557 protocol [RPC] that, when used over UDP, in many cases will generate 558 payloads that must be fragmented even for the first-hop link. This 559 might improve performance in certain cases, but it is known to cause 560 reliability and performance problems, especially when the client and 561 server are separated by routers. 563 It is recommended that NFS implementations use Path MTU Discovery 564 whenever routers are involved. Most NFS implementations allow the 565 RPC datagram size to be changed at mount-time (indirectly, by 566 changing the effective file system block size), but might require 567 some modification to support changes later on. 569 Also, since a single NFS operation cannot be split across several UDP 570 datagrams, certain operations (primarily, those operating on file 571 names and directories) require a minimum payload size that if sent in 572 a single packet would exceed the PMTU. NFS implementations should 573 not reduce the payload size below this threshold, even if Path MTU 574 Discovery suggests a lower value. In this case the payload will be 575 fragmented by the IP layer. 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 smaller 604 than reality. This should not entirely stop data flow, since the 605 victim node should never set its PMTU estimate below the IPv6 minimum 606 link MTU. It will, however, result in suboptimal performance. 608 In the second attack, the false message indicates a PMTU larger than 609 reality. If believed, this could cause temporary blockage as the 610 victim sends packets that will be dropped by some router. Within one 611 round-trip time, the node would discover its mistake (receiving 612 Packet Too Big messages from that router), but frequent repetition of 613 this attack could cause lots of packets to be dropped. A node, 614 however, should never raise its estimate of the PMTU based on a 615 Packet Too Big message, so should not be vulnerable to this attack. 617 A malicious party could also cause problems if it could stop a victim 618 from receiving legitimate Packet Too Big messages, but in this case 619 there are simpler denial-of-service attacks available. 621 7. Acknowledgements 623 We would like to acknowledge the authors of and contributors to 624 [RFC1191], from which the majority of this document was derived. We 625 would also like to acknowledge the members of the IPng working group 626 for their careful review and constructive criticisms. 628 8. IANA Considerations 630 This document does not have any IANA actions 632 9. References 634 9.1. Normative References 636 [I-D.ietf-6man-rfc2460bis] 637 Deering, S. and R. Hinden, "Internet Protocol, Version 6 638 (IPv6) Specification", draft-ietf-6man-rfc2460bis-04 (work 639 in progress), March 2016. 641 [ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 642 Control Message Protocol (ICMPv6) for the Internet 643 Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 644 10.17487/RFC4443, March 2006, 645 . 647 9.2. Informative References 649 [CONG] Jacobson, V., "Congestion Avoidance and Control", Proc. 650 SIGCOMM '88 Symposium on Communications Architectures and 651 Protocols , August 1988. 653 [FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", 654 In Proc. SIGCOMM '87 Workshop on Frontiers in Computer 655 Communications Technology , August 1987. 657 [ISOTP] "ISO Transport Protocol specification ISO DP 8073", RFC 658 905, DOI 10.17487/RFC0905, April 1984, 659 . 661 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 662 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 663 DOI 10.17487/RFC4861, September 2007, 664 . 666 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 667 DOI 10.17487/RFC1191, November 1990, 668 . 670 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 671 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 672 . 674 [RPC] Sun Microsystems, "RPC: Remote Procedure Call Protocol 675 specification: Version 2", RFC 1057, DOI 10.17487/RFC1057, 676 June 1988, . 678 Appendix A. Comparison to RFC 1191 680 This document is based in large part on RFC 1191, which describes 681 Path MTU Discovery for IPv4. Certain portions of RFC 1191 were not 682 needed in this document: 684 router specification Packet Too Big messages and corresponding 685 router behavior are defined in [ICMPv6] 687 Don't Fragment bit there is no DF bit in IPv6 packets 689 TCP MSS discussion selecting a value to send in the TCP MSS option 690 is discussed in [I-D.ietf-6man-rfc2460bis] 692 old-style messages all Packet Too Big messages report the MTU of 693 the constricting link 695 MTU plateau tables not needed because there are no old-style 696 messages 698 Appendix B. Changes Since RFC 1981 700 This document has the following changes from RFC1981. Numbers 701 identify the Internet-Draft version that the change was made.: 703 Working Group Internet Drafts 705 02) Clarified in Section 3. that ICMP Packet Too Big should be 706 sent even if the node doesn't decrement the hop limit 708 01) Revised the text about PLPMTUD to use the word "path". 710 01) Editorial changes. 712 00) Added text to discard an ICMP Packet Too Big message 713 containing an MTU less than the IPv6 minimum link MTU. 715 00) Revision of text regarding RFC4821. 717 00) Added R. Hinden as Editor to facilitate ID submission. 719 00) Editorial changes. 721 Individual Internet Drafts 723 01) Remove Note about a Packet Too Big message reporting a next- 724 hop MTU that is less than the IPv6 minimum link MTU. This 725 was removed from [I-D.ietf-6man-rfc2460bis]. 727 01) Include a link to RFC4821 along with a short summary of what 728 it does. 730 01) Assigned references to informative and normative. 732 01) Editorial changes. 734 00) Establish a baseline from RFC1981. The only intended changes 735 are formatting (XML is slightly different from .nroff), 736 differences between an RFC and Internet Draft, fixing a few 737 ID Nits, updating references, and updates to the authors 738 information. There should not be any content changes to the 739 specification. 741 Authors' Addresses 743 Jack McCann 744 Digital Equipment Corporation 746 Stephen E. Deering 747 Retired 748 Vancouver, British Columbia 749 Canada 751 Jeffrey Mogul 752 Digital Equipment Corporation 753 Robert M. Hinden (editor) 754 Check Point Software 755 959 Skyway Road 756 San Carlos, CA 94070 757 USA 759 Email: bob.hinden@gmail.com