idnits 2.17.1 draft-hinden-6man-rfc1981bis-01.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 97: '... IPv6 nodes SHOULD implement Path MT...' RFC 2119 keyword, line 225: '...et Too Big message, it MUST reduce its...' RFC 2119 keyword, line 232: '...oo Big message, a node MUST attempt to...' RFC 2119 keyword, line 233: '...ges in the near future. The node MUST...' RFC 2119 keyword, line 238: '... 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 164 has weird spacing: '...scovery proce...' == Line 681 has weird spacing: '...ent bit the...' == Line 683 has weird spacing: '...cussion sel...' == Line 686 has weird spacing: '...essages all...' == Line 689 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 (December 1, 2015) is 3062 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-01 -- 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: June 3, 2016 J. Mogul 7 Digital Equipment Corporation 8 December 1, 2015 10 Path MTU Discovery for IP version 6 11 draft-hinden-6man-rfc1981bis-01 13 Abstract 15 This document describes Path MTU Discovery for IP version 6. It is 16 largely derived from RFC 1191, which describes Path MTU Discovery for 17 IP version 4. It obsoletes RFC1981. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 3, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5 69 5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Layering . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5.2. Storing PMTU information . . . . . . . . . . . . . . . . 7 72 5.3. Purging stale PMTU information . . . . . . . . . . . . . 9 73 5.4. TCP layer actions . . . . . . . . . . . . . . . . . . . . 10 74 5.5. Issues for other transport protocols . . . . . . . . . . 12 75 5.6. Management interface . . . . . . . . . . . . . . . . . . 13 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 9.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Appendix A. Comparison to RFC 1191 . . . . . . . . . . . . . . . 15 83 Appendix B. Changes Since RFC 1981 . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Introduction 88 When one IPv6 node has a large amount of data to send to another 89 node, the data is transmitted in a series of IPv6 packets. It is 90 usually preferable that these packets be of the largest size that can 91 successfully traverse the path from the source node to the 92 destination node. This packet size is referred to as the Path MTU 93 (PMTU), and it is equal to the minimum link MTU of all the links in a 94 path. IPv6 defines a standard mechanism for a node to discover the 95 PMTU of an arbitrary path. 97 IPv6 nodes SHOULD implement Path MTU Discovery in order to discover 98 and take advantage of paths with PMTU greater than the IPv6 minimum 99 link MTU [I-D.ietf-6man-rfc2460bis]. A minimal IPv6 implementation 100 (e.g., in a boot ROM) may choose to omit implementation of Path MTU 101 Discovery. 103 Nodes not implementing Path MTU Discovery use the IPv6 minimum link 104 MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet size. 105 In most cases, this will result in the use of smaller packets than 106 necessary, because most paths have a PMTU greater than the IPv6 107 minimum link MTU. A node sending packets much smaller than the Path 108 MTU allows is wasting network resources and probably getting 109 suboptimal throughput. 111 An extension to Path MTU Discovery defined in this document can be 112 found in [RFC4821]. It defines a method for Packetization Layer Path 113 MTU Discovery (PLPMTUD). In the absence of ICMP messages, the proper 114 MTU is determined by starting with small packets and probing with 115 successively larger packets. The bulk of the algorithm is 116 implemented above IP, in the transport layer (e.g., TCP) or other 117 "Packetization Protocol" that is responsible for determining packet 118 boundaries. 120 2. Terminology 122 node a device that implements IPv6. 124 router a node that forwards IPv6 packets not explicitly 125 addressed to itself. 127 host any node that is not a router. 129 upper layer a protocol layer immediately above IPv6. 130 Examples are transport protocols such as TCP and 131 UDP, control protocols such as ICMP, routing 132 protocols such as OSPF, and internet or lower- 133 layer protocols being "tunneled" over (i.e., 134 encapsulated in) IPv6 such as IPX, AppleTalk, or 135 IPv6 itself. 137 link a communication facility or medium over which 138 nodes can communicate at the link layer, i.e., 139 the layer immediately below IPv6. Examples are 140 Ethernets (simple or bridged); PPP links; X.25, 141 Frame Relay, or ATM networks; and internet (or 142 higher) layer "tunnels", such as tunnels over 143 IPv4 or IPv6 itself. 145 interface a node's attachment to a link. 147 address an IPv6-layer identifier for an interface or a 148 set of interfaces. 150 packet an IPv6 header plus payload. 152 link MTU the maximum transmission unit, i.e., maximum 153 packet size in octets, that can be conveyed in 154 one piece over a link. 156 path the set of links traversed by a packet between a 157 source node and a destination node. 159 path MTU the minimum link MTU of all the links in a path 160 between a source node and a destination node. 162 PMTU path MTU 164 Path MTU Discovery process by which a node learns the PMTU of a path 166 flow a sequence of packets sent from a particular 167 source to a particular (unicast or multicast) 168 destination for which the source desires special 169 handling by the intervening routers. 171 flow id a combination of a source address and a non-zero 172 flow label. 174 3. Protocol Overview 176 This memo describes a technique to dynamically discover the PMTU of a 177 path. The basic idea is that a source node initially assumes that 178 the PMTU of a path is the (known) MTU of the first hop in the path. 179 If any of the packets sent on that path are too large to be forwarded 180 by some node along the path, that node will discard them and return 181 ICMPv6 Packet Too Big messages [ICMPv6]. Upon receipt of such a 182 message, the source node reduces its assumed PMTU for the path based 183 on the MTU of the constricting hop as reported in the Packet Too Big 184 message. 186 The Path MTU Discovery process ends when the node's estimate of the 187 PMTU is less than or equal to the actual PMTU. Note that several 188 iterations of the packet-sent/Packet-Too-Big-message-received cycle 189 may occur before the Path MTU Discovery process ends, as there may be 190 links with smaller MTUs further along the path. 192 Alternatively, the node may elect to end the discovery process by 193 ceasing to send packets larger than the IPv6 minimum link MTU. 195 The PMTU of a path may change over time, due to changes in the 196 routing topology. Reductions of the PMTU are detected by Packet Too 197 Big messages. To detect increases in a path's PMTU, a node 198 periodically increases its assumed PMTU. This will almost always 199 result in packets being discarded and Packet Too Big messages being 200 generated, because in most cases the PMTU of the path will not have 201 changed. Therefore, attempts to detect increases in a path's PMTU 202 should be done infrequently. 204 Path MTU Discovery supports multicast as well as unicast 205 destinations. In the case of a multicast destination, copies of a 206 packet may traverse many different paths to many different nodes. 207 Each path may have a different PMTU, and a single multicast packet 208 may result in multiple Packet Too Big messages, each reporting a 209 different next-hop MTU. The minimum PMTU value across the set of 210 paths in use determines the size of subsequent packets sent to the 211 multicast destination. 213 Note that Path MTU Discovery must be performed even in cases where a 214 node "thinks" a destination is attached to the same link as itself. 215 In a situation such as when a neighboring router acts as proxy [ND] 216 for some destination, the destination can to appear to be directly 217 connected but is in fact more than one hop away. 219 4. Protocol Requirements 221 As discussed in section 1, IPv6 nodes are not required to implement 222 Path MTU Discovery. The requirements in this section apply only to 223 those implementations that include Path MTU Discovery. 225 When a node receives a Packet Too Big message, it MUST reduce its 226 estimate of the PMTU for the relevant path, based on the value of the 227 MTU field in the message. The precise behavior of a node in this 228 circumstance is not specified, since different applications may have 229 different requirements, and since different implementation 230 architectures may favor different strategies. 232 After receiving a Packet Too Big message, a node MUST attempt to 233 avoid eliciting more such messages in the near future. The node MUST 234 reduce the size of the packets it is sending along the path. Using a 235 PMTU estimate larger than the IPv6 minimum link MTU may continue to 236 elicit Packet Too Big messages. Since each of these messages (and 237 the dropped packets they respond to) consume network resources, the 238 node MUST force the Path MTU Discovery process to end. 240 Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast 241 as possible. Nodes MAY detect increases in PMTU, but because doing 242 so requires sending packets larger than the current estimated PMTU, 243 and because the likelihood is that the PMTU will not have increased, 244 this MUST be done at infrequent intervals. An attempt to detect an 245 increase (by sending a packet larger than the current estimate) MUST 246 NOT be done less than 5 minutes after a Packet Too Big message has 247 been received for the given path. The recommended setting for this 248 timer is twice its minimum value (10 minutes). 250 A node MUST NOT reduce its estimate of the Path MTU below the IPv6 251 minimum link MTU. 253 A node MUST NOT increase its estimate of the Path MTU in response to 254 the contents of a Packet Too Big message. A message purporting to 255 announce an increase in the Path MTU might be a stale packet that has 256 been floating around in the network, a false packet injected as part 257 of a denial-of-service attack, or the result of having multiple paths 258 to the destination, each with a different PMTU. 260 5. Implementation Issues 262 This section discusses a number of issues related to the 263 implementation of Path MTU Discovery. This is not a specification, 264 but rather a set of notes provided as an aid for implementors. 266 The issues include: 268 - What layer or layers implement Path MTU Discovery? 270 - How is the PMTU information cached? 272 - How is stale PMTU information removed? 274 - What must transport and higher layers do? 276 5.1. Layering 278 In the IP architecture, the choice of what size packet to send is 279 made by a protocol at a layer above IP. This memo refers to such a 280 protocol as a "packetization protocol". Packetization protocols are 281 usually transport protocols (for example, TCP) but can also be 282 higher-layer protocols (for example, protocols built on top of UDP). 284 Implementing Path MTU Discovery in the packetization layers 285 simplifies some of the inter-layer issues, but has several drawbacks: 286 the implementation may have to be redone for each packetization 287 protocol, it becomes hard to share PMTU information between different 288 packetization layers, and the connection-oriented state maintained by 289 some packetization layers may not easily extend to save PMTU 290 information for long periods. 292 It is therefore suggested that the IP layer store PMTU information 293 and that the ICMP layer process received Packet Too Big messages. 294 The packetization layers may respond to changes in the PMTU, by 295 changing the size of the messages they send. To support this 296 layering, packetization layers require a way to learn of changes in 297 the value of MMS_S, the "maximum send transport-message size". The 298 MMS_S is derived from the Path MTU by subtracting the size of the 299 IPv6 header plus space reserved by the IP layer for additional 300 headers (if any). 302 It is possible that a packetization layer, perhaps a UDP application 303 outside the kernel, is unable to change the size of messages it 304 sends. This may result in a packet size that exceeds the Path MTU. 305 To accommodate such situations, IPv6 defines a mechanism that allows 306 large payloads to be divided into fragments, with each fragment sent 307 in a separate packet (see [I-D.ietf-6man-rfc2460bis] section 308 "Fragment Header"). However, packetization layers are encouraged to 309 avoid sending messages that will require fragmentation (for the case 310 against fragmentation, see [FRAG]). 312 5.2. Storing PMTU information 314 Ideally, a PMTU value should be associated with a specific path 315 traversed by packets exchanged between the source and destination 316 nodes. However, in most cases a node will not have enough 317 information to completely and accurately identify such a path. 318 Rather, a node must associate a PMTU value with some local 319 representation of a path. It is left to the implementation to select 320 the local representation of a path. 322 In the case of a multicast destination address, copies of a packet 323 may traverse many different paths to reach many different nodes. The 324 local representation of the "path" to a multicast destination must in 325 fact represent a potentially large set of paths. 327 Minimally, an implementation could maintain a single PMTU value to be 328 used for all packets originated from the node. This PMTU value would 329 be the minimum PMTU learned across the set of all paths in use by the 330 node. This approach is likely to result in the use of smaller 331 packets than is necessary for many paths. 333 An implementation could use the destination address as the local 334 representation of a path. The PMTU value associated with a 335 destination would be the minimum PMTU learned across the set of all 336 paths in use to that destination. The set of paths in use to a 337 particular destination is expected to be small, in many cases 338 consisting of a single path. This approach will result in the use of 339 optimally sized packets on a per-destination basis. This approach 340 integrates nicely with the conceptual model of a host as described in 341 [ND]: a PMTU value could be stored with the corresponding entry in 342 the destination cache. 344 If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation 345 could use the flow id as the local representation of a path. Packets 346 sent to a particular destination but belonging to different flows may 347 use different paths, with the choice of path depending on the flow 348 id. This approach will result in the use of optimally sized packets 349 on a per-flow basis, providing finer granularity than PMTU values 350 maintained on a per-destination basis. 352 For source routed packets (i.e. packets containing an IPv6 Routing 353 header [I-D.ietf-6man-rfc2460bis]), the source route may further 354 qualify the local representation of a path. In particular, a packet 355 containing a type 0 Routing header in which all bits in the Strict/ 356 Loose Bit Map are equal to 1 contains a complete path specification. 357 An implementation could use source route information in the local 358 representation of a path. 360 Note: Some paths may be further distinguished by different 361 security classifications. The details of such classifications are 362 beyond the scope of this memo. 364 Initially, the PMTU value for a path is assumed to be the (known) MTU 365 of the first-hop link. 367 When a Packet Too Big message is received, the node determines which 368 path the message applies to based on the contents of the Packet Too 369 Big message. For example, if the destination address is used as the 370 local representation of a path, the destination address from the 371 original packet would be used to determine which path the message 372 applies to. 374 Note: if the original packet contained a Routing header, the 375 Routing header should be used to determine the location of the 376 destination address within the original packet. If Segments Left 377 is equal to zero, the destination address is in the Destination 378 Address field in the IPv6 header. If Segments Left is greater 379 than zero, the destination address is the last address 380 (Address[n]) in the Routing header. 382 The node then uses the value in the MTU field in the Packet Too Big 383 message as a tentative PMTU value, and compares the tentative PMTU to 384 the existing PMTU. If the tentative PMTU is less than the existing 385 PMTU estimate, the tentative PMTU replaces the existing PMTU as the 386 PMTU value for the path. 388 The packetization layers must be notified about decreases in the 389 PMTU. Any packetization layer instance (for example, a TCP 390 connection) that is actively using the path must be notified if the 391 PMTU estimate is decreased. 393 Note: even if the Packet Too Big message contains an Original 394 Packet Header that refers to a UDP packet, the TCP layer must be 395 notified if any of its connections use the given path. 397 Also, the instance that sent the packet that elicited the Packet Too 398 Big message should be notified that its packet has been dropped, even 399 if the PMTU estimate has not changed, so that it may retransmit the 400 dropped data. 402 Note: An implementation can avoid the use of an asynchronous 403 notification mechanism for PMTU decreases by postponing 404 notification until the next attempt to send a packet larger than 405 the PMTU estimate. In this approach, when an attempt is made to 406 SEND a packet that is larger than the PMTU estimate, the SEND 407 function should fail and return a suitable error indication. This 408 approach may be more suitable to a connectionless packetization 409 layer (such as one using UDP), which (in some implementations) may 410 be hard to "notify" from the ICMP layer. In this case, the normal 411 timeout-based retransmission mechanisms would be used to recover 412 from the dropped packets. 414 It is important to understand that the notification of the 415 packetization layer instances using the path about the change in the 416 PMTU is distinct from the notification of a specific instance that a 417 packet has been dropped. The latter should be done as soon as 418 practical (i.e., asynchronously from the point of view of the 419 packetization layer instance), while the former may be delayed until 420 a packetization layer instance wants to create a packet. 421 Retransmission should be done for only for those packets that are 422 known to be dropped, as indicated by a Packet Too Big message. 424 5.3. Purging stale PMTU information 426 Internetwork topology is dynamic; routes change over time. While the 427 local representation of a path may remain constant, the actual 428 path(s) in use may change. Thus, PMTU information cached by a node 429 can become stale. 431 If the stale PMTU value is too large, this will be discovered almost 432 immediately once a large enough packet is sent on the path. No such 433 mechanism exists for realizing that a stale PMTU value is too small, 434 so an implementation should "age" cached values. When a PMTU value 435 has not been decreased for a while (on the order of 10 minutes), the 436 PMTU estimate should be set to the MTU of the first-hop link, and the 437 packetization layers should be notified of the change. This will 438 cause the complete Path MTU Discovery process to take place again. 440 Note: an implementation should provide a means for changing the 441 timeout duration, including setting it to "infinity". For 442 example, nodes attached to an FDDI link which is then attached to 443 the rest of the Internet via a small MTU serial line are never 444 going to discover a new non-local PMTU, so they should not have to 445 put up with dropped packets every 10 minutes. 447 An upper layer must not retransmit data in response to an increase in 448 the PMTU estimate, since this increase never comes in response to an 449 indication of a dropped packet. 451 One approach to implementing PMTU aging is to associate a timestamp 452 field with a PMTU value. This field is initialized to a "reserved" 453 value, indicating that the PMTU is equal to the MTU of the first hop 454 link. Whenever the PMTU is decreased in response to a Packet Too Big 455 message, the timestamp is set to the current time. 457 Once a minute, a timer-driven procedure runs through all cached PMTU 458 values, and for each PMTU whose timestamp is not "reserved" and is 459 older than the timeout interval: 461 - The PMTU estimate is set to the MTU of the first hop link. 463 - The timestamp is set to the "reserved" value. 465 - Packetization layers using this path are notified of the increase. 467 5.4. TCP layer actions 469 The TCP layer must track the PMTU for the path(s) in use by a 470 connection; it should not send segments that would result in packets 471 larger than the PMTU. A simple implementation could ask the IP layer 472 for this value each time it created a new segment, but this could be 473 inefficient. Moreover, TCP implementations that follow the "slow- 474 start" congestion-avoidance algorithm [CONG] typically calculate and 475 cache several other values derived from the PMTU. It may be simpler 476 to receive asynchronous notification when the PMTU changes, so that 477 these variables may be updated. 479 A TCP implementation must also store the MSS value received from its 480 peer, and must not send any segment larger than this MSS, regardless 481 of the PMTU. In 4.xBSD-derived implementations, this may require 482 adding an additional field to the TCP state record. 484 The value sent in the TCP MSS option is independent of the PMTU. 485 This MSS option value is used by the other end of the connection, 486 which may be using an unrelated PMTU value. See 487 [I-D.ietf-6man-rfc2460bis] sections "Packet Size Issues" and "Maximum 488 Upper-Layer Payload Size" for information on selecting a value for 489 the TCP MSS option. 491 When a Packet Too Big message is received, it implies that a packet 492 was dropped by the node that sent the ICMP message. It is sufficient 493 to treat this as any other dropped segment, and wait until the 494 retransmission timer expires to cause retransmission of the segment. 495 If the Path MTU Discovery process requires several steps to find the 496 PMTU of the full path, this could delay the connection by many round- 497 trip times. 499 Alternatively, the retransmission could be done in immediate response 500 to a notification that the Path MTU has changed, but only for the 501 specific connection specified by the Packet Too Big message. The 502 packet size used in the retransmission should be no larger than the 503 new PMTU. 505 Note: A packetization layer must not retransmit in response to 506 every Packet Too Big message, since a burst of several oversized 507 segments will give rise to several such messages and hence several 508 retransmissions of the same data. If the new estimated PMTU is 509 still wrong, the process repeats, and there is an exponential 510 growth in the number of superfluous segments sent. 512 This means that the TCP layer must be able to recognize when a 513 Packet Too Big notification actually decreases the PMTU that it 514 has already used to send a packet on the given connection, and 515 should ignore any other notifications. 517 Many TCP implementations incorporate "congestion avoidance" and 518 "slow-start" algorithms to improve performance [CONG]. Unlike a 519 retransmission caused by a TCP retransmission timeout, a 520 retransmission caused by a Packet Too Big message should not change 521 the congestion window. It should, however, trigger the slow-start 522 mechanism (i.e., only one segment should be retransmitted until 523 acknowledgements begin to arrive again). 525 TCP performance can be reduced if the sender's maximum window size is 526 not an exact multiple of the segment size in use (this is not the 527 congestion window size, which is always a multiple of the segment 528 size). In many systems (such as those derived from 4.2BSD), the 529 segment size is often set to 1024 octets, and the maximum window size 530 (the "send space") is usually a multiple of 1024 octets, so the 531 proper relationship holds by default. If Path MTU Discovery is used, 532 however, the segment size may not be a submultiple of the send space, 533 and it may change during a connection; this means that the TCP layer 534 may need to change the transmission window size when Path MTU 535 Discovery changes the PMTU value. The maximum window size should be 536 set to the greatest multiple of the segment size that is less than or 537 equal to the sender's buffer space size. 539 5.5. Issues for other transport protocols 541 Some transport protocols (such as ISO TP4 [ISOTP]) are not allowed to 542 repacketize when doing a retransmission. That is, once an attempt is 543 made to transmit a segment of a certain size, the transport cannot 544 split the contents of the segment into smaller segments for 545 retransmission. In such a case, the original segment can be 546 fragmented by the IP layer during retransmission. Subsequent 547 segments, when transmitted for the first time, should be no larger 548 than allowed by the Path MTU. 550 The Sun Network File System (NFS) uses a Remote Procedure Call (RPC) 551 protocol [RPC] that, when used over UDP, in many cases will generate 552 payloads that must be fragmented even for the first-hop link. This 553 might improve performance in certain cases, but it is known to cause 554 reliability and performance problems, especially when the client and 555 server are separated by routers. 557 It is recommended that NFS implementations use Path MTU Discovery 558 whenever routers are involved. Most NFS implementations allow the 559 RPC datagram size to be changed at mount-time (indirectly, by 560 changing the effective file system block size), but might require 561 some modification to support changes later on. 563 Also, since a single NFS operation cannot be split across several UDP 564 datagrams, certain operations (primarily, those operating on file 565 names and directories) require a minimum payload size that if sent in 566 a single packet would exceed the PMTU. NFS implementations should 567 not reduce the payload size below this threshold, even if Path MTU 568 Discovery suggests a lower value. In this case the payload will be 569 fragmented by the IP layer. 571 5.6. Management interface 573 It is suggested that an implementation provide a way for a system 574 utility program to: 576 - Specify that Path MTU Discovery not be done on a given path. 578 - Change the PMTU value associated with a given path. 580 The former can be accomplished by associating a flag with the path; 581 when a packet is sent on a path with this flag set, the IP layer does 582 not send packets larger than the IPv6 minimum link MTU. 584 These features might be used to work around an anomalous situation, 585 or by a routing protocol implementation that is able to obtain Path 586 MTU values. 588 The implementation should also provide a way to change the timeout 589 period for aging stale PMTU information. 591 6. Security Considerations 593 This Path MTU Discovery mechanism makes possible two denial-of- 594 service attacks, both based on a malicious party sending false Packet 595 Too Big messages to a node. 597 In the first attack, the false message indicates a PMTU much smaller 598 than reality. This should not entirely stop data flow, since the 599 victim node should never set its PMTU estimate below the IPv6 minimum 600 link MTU. It will, however, result in suboptimal performance. 602 In the second attack, the false message indicates a PMTU larger than 603 reality. If believed, this could cause temporary blockage as the 604 victim sends packets that will be dropped by some router. Within one 605 round-trip time, the node would discover its mistake (receiving 606 Packet Too Big messages from that router), but frequent repetition of 607 this attack could cause lots of packets to be dropped. A node, 608 however, should never raise its estimate of the PMTU based on a 609 Packet Too Big message, so should not be vulnerable to this attack. 611 A malicious party could also cause problems if it could stop a victim 612 from receiving legitimate Packet Too Big messages, but in this case 613 there are simpler denial-of-service attacks available. 615 7. Acknowledgements 617 We would like to acknowledge the authors of and contributors to 618 [RFC1191], from which the majority of this document was derived. We 619 would also like to acknowledge the members of the IPng working group 620 for their careful review and constructive criticisms. 622 8. IANA Considerations 624 This document does not have any IANA actions 626 9. References 628 9.1. Normative References 630 [I-D.ietf-6man-rfc2460bis] 631 Deering, S. and B. Hinden, "Internet Protocol, Version 6 632 (IPv6) Specification", draft-ietf-6man-rfc2460bis-01 (work 633 in progress), November 2015. 635 [ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 636 Control Message Protocol (ICMPv6) for the Internet 637 Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 638 10.17487/RFC4443, March 2006, 639 . 641 9.2. Informative References 643 [CONG] Jacobson, V., "Congestion Avoidance and Control", Proc. 644 SIGCOMM '88 Symposium on Communications Architectures and 645 Protocols , August 1988. 647 [FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", 648 In Proc. SIGCOMM '87 Workshop on Frontiers in Computer 649 Communications Technology , August 1987. 651 [ISOTP] "ISO Transport Protocol specification ISO DP 8073", RFC 652 905, DOI 10.17487/RFC0905, April 1984, 653 . 655 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 656 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 657 DOI 10.17487/RFC4861, September 2007, 658 . 660 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 661 DOI 10.17487/RFC1191, November 1990, 662 . 664 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 665 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 666 . 668 [RPC] Sun Microsystems, "RPC: Remote Procedure Call Protocol 669 specification: Version 2", RFC 1057, DOI 10.17487/RFC1057, 670 June 1988, . 672 Appendix A. Comparison to RFC 1191 674 This document is based in large part on RFC 1191, which describes 675 Path MTU Discovery for IPv4. Certain portions of RFC 1191 were not 676 needed in this document: 678 router specification Packet Too Big messages and corresponding 679 router behavior are defined in [ICMPv6] 681 Don't Fragment bit there is no DF bit in IPv6 packets 683 TCP MSS discussion selecting a value to send in the TCP MSS option 684 is discussed in [I-D.ietf-6man-rfc2460bis] 686 old-style messages all Packet Too Big messages report the MTU of 687 the constricting link 689 MTU plateau tables not needed because there are no old-style 690 messages 692 Appendix B. Changes Since RFC 1981 694 This document has the following changes from RFC1981. Numbers 695 identify the Internet-Draft version that the change was made.: 697 01) Remove Note about a Packet Too Big message reporting a next- 698 hop MTU that is less than the IPv6 minimum link MTU. This 699 was removed from [I-D.ietf-6man-rfc2460bis]. 701 01) Include a link to RFC4821 along with a short summary of what 702 it does. 704 01) Assigned references to informative and normative. 706 01) Editorial changes. 708 00) Establish a baseline from RFC1981. The only intended changes 709 are formatting (XML is slightly different from .nroff), 710 differences between an RFC and Internet Draft, fixing a few 711 ID Nits, updating references, and updates to the authors 712 information. There should not be any content changes to the 713 specification. 715 Authors' Addresses 717 Jack McCann 718 Digital Equipment Corporation 720 Stephen E. Deering 721 Retired 722 Vancouver, British Columbia 723 Canada 725 Jeffrey Mogul 726 Digital Equipment Corporation