idnits 2.17.1 draft-ietf-pmtud-method-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 553 has weird spacing: '...retried after...' == Line 880 has weird spacing: '...irement has p...' == Line 1009 has weird spacing: '...tion it is...' == Line 1010 has weird spacing: '...portant that ...' == Line 1140 has weird spacing: '...imed to per-...' == (1 more instance...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Links MUST not deliver packets that are larger than their MTU. Links that have parametric limitations (e.g. MTU bounds due to limited clock stability) MUST include explicit mechanisms to consistently reject packets that might otherwise be nondeterministically delivered. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 122, but not defined == Missing Reference: 'IPv4-SPEC' is mentioned on line 125, but not defined == Missing Reference: 'IPv6-SPEC' is mentioned on line 826, but not defined == Missing Reference: 'Congestion' is mentioned on line 319, but not defined == Missing Reference: 'DOS' is mentioned on line 476, but not defined == Missing Reference: 'ND' is mentioned on line 822, but not defined == Missing Reference: 'FRAG' is mentioned on line 847, but not defined == Missing Reference: 'ISOTP' is mentioned on line 1030, but not defined == Unused Reference: 'RFC2119' is defined on line 1082, but no explicit reference was found in the text == Unused Reference: 'RFC1063' is defined on line 1087, but no explicit reference was found in the text == Unused Reference: 'RFC1435' is defined on line 1090, but no explicit reference was found in the text == Unused Reference: 'RFC1626' is defined on line 1094, but no explicit reference was found in the text == Unused Reference: 'RFC1791' is defined on line 1097, but no explicit reference was found in the text == Unused Reference: 'RFC2923' is defined on line 1100, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1063 (ref. 'RFC1191') (Obsoleted by RFC 1191) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 1626 (Obsoleted by RFC 2225) Summary: 5 errors (**), 0 flaws (~~), 24 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Matt Mathis 3 John Heffner 4 PSC 5 Kevin Lahey 6 Freelance 7 14 Feb, 2004 9 Path MTU Discovery 10 draft-ietf-pmtud-method-01.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes a robust new method for Path MTU Discovery 35 that relies on TCP or other Packetization Layer to probe an Internet 36 path with progressively larger packets. This method is described as 37 an extension to RFC 1191 and RFC 1981, which specify ICMP based Path 38 MTU Discovery for IP versions 4 and 6. This document does not define 39 a protocol, but rather a method to use features of existing protocols 40 to discover the path MTU. 42 The general strategy of the new algorithm is to start with a small 43 MTU and probe upward, testing successively larger MTUs by probing 44 with single packets. If the probe is successfully delivered, then 45 the MTU is raised. If the probe is lost, it is treated as an MTU 46 limitation and not as a congestion signal. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3.1. General Method . . . . . . . . . . . . . . . . . . . . . 8 54 3.2. Generating Probes . . . . . . . . . . . . . . . . . . . . 9 55 3.3. Normal sequence of events to raise the MTU . . . . . . . 10 56 3.4. Processing MTU Indications . . . . . . . . . . . . . . . 11 57 3.4.1. Processing Packet Too Big Messages . . . . . . . . . . 11 58 3.4.2. Packetization Layer retransmits lost packets . . . . . 11 59 3.4.3. Packetization Layer Retransmission Timeout . . . . . . 13 60 3.5. Probing Intervals . . . . . . . . . . . . . . . . . . . . 14 61 3.6. Interoperation with prior algorithms . . . . . . . . . . 15 62 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 15 63 5. Implementation Issues . . . . . . . . . . . . . . . . . . . 16 64 5.1. Layering and Accounting for Header Sizes. . . . . . . . . 17 65 5.2. Storing PMTU information . . . . . . . . . . . . . . . . 18 66 5.3. Host fragmentation . . . . . . . . . . . . . . . . . . . 19 67 5.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 19 68 5.5. Path MTU Search Strategy . . . . . . . . . . . . . . . . 20 69 5.5.1. Search . . . . . . . . . . . . . . . . . . . . . . . . 20 70 5.5.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . 21 71 5.5.3. Suspend . . . . . . . . . . . . . . . . . . . . . . . . 21 72 5.6. Implementation issues for specific Packetization Layers . 21 73 5.6.1. Probing method using TCP . . . . . . . . . . . . . . . 21 74 5.6.2. Probing method using SCTP . . . . . . . . . . . . . . . 22 75 5.6.3. Issues for tunnels . . . . . . . . . . . . . . . . . . 23 76 5.6.4. Issues for other transport protocols . . . . . . . . . 23 77 5.7. Diagnostic tools . . . . . . . . . . . . . . . . . . . . 23 78 5.8. Management interface . . . . . . . . . . . . . . . . . . 23 79 6. Normative references . . . . . . . . . . . . . . . . . . . 24 80 7. Informative references . . . . . . . . . . . . . . . . . . 24 81 8. Security considerations . . . . . . . . . . . . . . . . . . 24 82 9. IANA considerations . . . . . . . . . . . . . . . . . . . . 25 83 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . 25 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 25 85 12. Authors' addresses . . . . . . . . . . . . . . . . . . . . 25 86 13. Intellectual Property . . . . . . . . . . . . . . . . . . 25 87 14. Full copyright statement . . . . . . . . . . . . . . . . . 26 89 1. Introduction 91 This document describes a method for Packetization Layer Path MTU 92 Discovery (PLPMTUD) which is an extension to existing Path MTU 93 discovery methods. The proper MTU is determined by starting with 94 small packets and probing with successively larger packets. The 95 bulk of the algorithm is implemented above IP, in the transport layer 96 (e.g. TCP) or other "Packetization Protocol" that is responsible for 97 determining packet boundaries. 99 This document draws heavily RFC1191 and RFC1981 for terminology, 100 ideas and some of the text. 102 The methods described in this document apply both IPv4 and IPv6, and 103 to many transport protocols such as TCP. This document does not 104 define a protocol, but rather a method to use features of existing 105 protocols to discover the path MTU. It does not require cooperation 106 from the lower layers (except that they are consistent about what 107 packet sizes are acceptable) or the far node. Variants in 108 implementations will not cause interoperability problems. 110 The methods described in this document are carefully designed to 111 maximize robustness in the presence of less than ideal 112 implementations of other protocols or Internet components. 114 For sake of clarity we uniformly prefer TCP and IPv6 terminology. In 115 the terminology section we also present the analogous IPv4 terms and 116 concepts for the IPv6 terminology. In a few situations we describe 117 specific details that are different between IPv4 and IPv6. 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC 2119]. 123 2. Terminology 125 IP - Either IPv4 [IPv4-SPEC] or IPv6 [IPv6-SPEC]. 127 node - A device that implements IP. 129 router - A node that forwards IP packets not explicitly 130 addressed to itself. 132 host - Any node that is not a router. 134 upper layer - A protocol layer immediately above IP. Examples are 135 transport protocols such as TCP and UDP, control 136 protocols such as ICMP, routing protocols such as OSPF, 137 and Internet or lower-layer protocols being "tunneled" 138 over (i.e., encapsulated in) IP such as IPX, 139 AppleTalk, IP itself. 141 link - A communication facility or medium over which nodes can 142 communicate at the link layer, i.e., the layer 143 immediately below IP. Examples are Ethernets (simple 144 or bridged); PPP links; X.25, Frame Relay, or ATM 145 networks; and Internet (or higher) layer "tunnels", 146 such as tunnels over IPv4 or IPv6. In some earlier 147 documents the term "lower layer" was used for this 148 concept. 150 interface - A node's attachment to a link. 152 address - An IP-layer identifier for an interface or a set of 153 interfaces. 155 packet - An IP header plus payload. 157 MTU - Maximum Transmission Unit, the size in bytes of the 158 largest IP packet, including the IP header and payload, 159 that can be transmitted on a link or path. Note that 160 this could more properly be called the IP MTU, to be 161 consistent with how other standards organizations use 162 the acronym MTU. 164 link MTU - The Maximum Transmission Unit, i.e., maximum IP packet 165 size in octets, that can be conveyed in one piece over 166 a link. Beware that this definition differers from 167 the definition used by other standards organizations. 169 For IETF documents, link MTU is uniformly defined as 170 the IP MTU over the link. This includes the IP header, 171 but excludes link layer headers and other framing which 172 is not part of IP or the IP payload. 174 Other standards organizations generally define link MTU 175 to include the link layer headers. 177 path - The set of links traversed by a packet between a source 178 node and a destination node 180 path MTU - The minimum link MTU of all the links in a path between 181 a source node and a destination node. 183 PMTU - Path MTU 185 classical PMTU discovery, 186 - Process described in RFC 1191 and RFC 1981, in which 187 nodes rely on ICMP messages to learn the MTU of a path. 189 PL, packetization layer 190 - The layer of the network stack which segments data into 191 packets. 193 PLPMTUD - Packetization Layer Path MTU Discovers, the method 194 described in this document, which is an extension to 195 classical PMTU discovery. 197 Packet Too Big message 198 - An ICMP message reporting that an IP packet is too 199 large to forward. This is the IPv6 term that 200 corresponds to the IPv4 "ICMP Can't fragment" message. 202 flow - A context in which MTU discovery is applied. This is 203 naturally an instance of the packetization protocol, e.g. 204 one side of a TCP connection. 206 MPS - The maximum IP payload size available over a specific 207 path. This is typically the path MTU minus the IP header 208 As an example, this is the maximum TCP packet size, 209 including TCP payload and headers but not including 210 IP headers. This has also been called the "L3 MTU". 212 MSS - The TCP Maximum Segment Size, the maximum payload 213 size available to the TCP layer. This is typically the 214 path MPS minus the size of the TCP headers. 216 probe packet- A packet which is being used to test for a larger MTU. 218 probe size - The size of a packet being used to probe for a larger MTU. 220 successful probe 221 - The probe packet was delivered through the network. 223 inconclusive probe 224 - The probe packet was not delivered, but there were other lost 225 packets close enough to the probe where can not presume that 226 the probe was lost due to MTU. By implication the probe 227 might have been lost due to something other than MTU (such 228 congestion), so the results are inconclusive. Inconclusive 229 probes are generally repeated at the same probe size, after 230 a suitable delay. 232 failed probe 233 - The probe packet was not delivered and there were no other 234 lost packets close to the probe. This is taken as an 235 indication that the probe was larger than the path MTU, 236 and future probes should generally be for at smaller sizes. 238 errored probe 239 - There were losses or timeouts during the verification 240 phase which suggest a potentially disruptive failure 241 or network condition. These are generally retried 242 only after substantially longer intervals. 243 @@@ not used 245 probe gap - The expected missing payload data that will need to be 246 retransmitted if the probe is not delivered. 248 probe phase - The interval (time or protocol events) 249 between when a probe is sent, and when 250 it is determined that the the probe succeeded, failed or was 251 inconclusive 253 verification phase - An additional interval during which the new path MTU 254 is considered provisional. Packet losses or timeouts are 255 treated as an indication that there may be a problem with 256 the provisional MTU. 258 Transition phase - The interval between the probe phase and the 259 verification phase, during which packets using the new MTU 260 propagate to the far node and the acknowledgment propagates 261 back. 263 full stop timeout - a timeout where the none of the packets transmitted 264 after some specific event at the sender (e.g. entering the 265 probe or verification phase) is acknowledged by the receiver. 266 This is taken as an indication that the MTU change caused 267 some failure in the network. 269 search strategy - the heuristics used to choose successive probe sizes 270 to converge to the proper path MTU, as described in 271 section 5.5. 273 3. Overview 275 This document describes a method for TCP or other packetization 276 protocols to dynamically discover the MTU of a path without relying 277 on explicit signals from the network. These procedures are 278 applicable to TCP and other transport- or application-level 279 packetization protocols in which the receiver always reports to the 280 sender complete information about which packets were lost in the 281 network. 283 The general strategy of the new procedure is for the packetization 284 layer to find the proper MTU by probing with progressively larger 285 packets, without disrupting its normal protocol operation. If a 286 probe packet is successfully delivered, then the path MTU is 287 provisionally raised. If there are no additional losses during the 288 subsequent verification phase, then the path MTU is confirmed 289 (verified) to be at least as large as the provisional MTU. PLPMTUD 290 can then probe again with an even larger MTU, according to MTU search 291 strategy described in section 5.5. 293 The verification phase is used to detect situations where raising the 294 MTU greatly raises the packet loss rate. For example this might 295 happen if some link is striped across multiple physical channels and 296 the stripes have inconsistent MTUs. 298 A conservative implementation of PLPMTUD would use a full round trip 299 time for the verification phase. In this case each time PLPMTUD 300 raises the MTU it takes three full round trip times to do so. It 301 takes one round trip for the probe phase, during which the probe 302 propagates to the far node and an acknowledgment is returned. The 303 second round trip is the transitional phase, during which data 304 packets using the provisional MTU propagate to the far node and are 305 acknowledged. During he third and final round trip time, it is 306 verified that raising the MTU does not cause excessive loss. 308 The isolated loss of a probe packet (with or without a Packet Too Big 309 message) is treated as an indication of an MTU limit, and not as a 310 congestion indicator. In this case alone, the packetization protocol 311 is permitted to retransmit the probe gap without adjusting the 312 congestion window. 314 If there is a timeout or additional lost packets during any of the 315 three phases, the loss is treated as a congestion indication as well 316 as a indication of some sort of failure of the PLPMTUD process. The 317 congestion indication is treated like any other congestion 318 indication: window or rate adjustments are mandatory per the relevant 319 congestions control standards [Congestion]. Probing can resume with 320 some new probe size after a delay which is determined by the nature 321 of the indicated failure. 323 The most likely (and least serious) PLPMTUD failure is the link 324 experiencing legitimate congestion related losses at about the same 325 time as the probe. In this case, it is appropriate to retry the 326 probe (with the same probe size) as soon as the packetization layer 327 has fully adapted to the congestion and recovered from the losses. 329 In other cases, additional losses or timeouts indicate problems with 330 the link or packetization layer, and that probes may be disruptive. 331 In these situations it is desirable to use progressively longer 332 delays depending on the severity of the failure and if it is 333 repeated. 335 PLPMTUD can optionally process Packet Too Big messages to select the 336 provisional MTU for faster convergence in exchange for a slight 337 decrease in robustness. Processing malicious or erroneous Packet Too 338 Big messages can cause PLPMTUD to arrive at the incorrect MTU for a 339 path, which is likely to reduce protocol performance. The document 340 describes three options for processing Packet Too Big messages: 341 completely ignore them, only accept them in response to probes or 342 accept all Packet Too Big messages (fully implementing classic PMTUD 343 within PLPMTUD). Theses are further described in section 3.8. 345 Relatively few details of this procedure affect interoperability with 346 other standards or Internet protocols. These details are specified 347 in RFC2119 standards language in the requirements section. The vast 348 majority of the implementation details are recommendations based on 349 experiences with earlier versions of path MTU discovery. These are 350 motivated by a desire to maximize robustness of PLPMTUD in the 351 presence of less than ideal implementations as they exist in the 352 field. 354 3.1. General Method 356 Most of the difficulty in implementing PLPMTUD arises because it 357 needs to be implemented in several different places within a single 358 node. In general each packetization protocol needs to have it's own 359 implementation of PLPMTUD. Furthermore, the natural mechanism to 360 share path MTU information between concurrent or subsequent 361 connections over the same path is a path information cache in the IP 362 layer. The various packetization protocols need to have the means to 363 access and update the shared cache in the IP layer. 365 Rather than prescribing implementation details this memo describes 366 PLPMTUD in terms of its primary subsystems, without fully describing 367 how they are integrated into a complete implementation. The 368 subsystems are: generating probes, processing probe responses, the 369 search strategy and, the supporting infrastructure (including the 370 path cache). The first two are introduced in this section and are 371 subject to the requirements specified in the following section. The 372 probe strategy and issues related to the support infrastructure and 373 cache are covered in the implementation section. 375 3.2. Generating Probes 377 A new candidate MTU is tested by sending one "probe packet", which is 378 larger than the current MTU. In this section we present a couple of 379 possible ways to alter packetization layers to generate probe 380 packets. The different techniques incur different overheads in 381 three areas: difficulty in generating the probe packet (in terms of 382 packetization layer implementation complexity and computational 383 overhead) possible additional network capacity consumed by the probes 384 and the overhead of recovering from failed probes (both network and 385 protocol overhead). 387 For example a protocol such as SCTP might be extended to allow 388 padding with dummy data inside the SCTP packets. This greatly 389 simplify the implementation because the probing can be performed 390 without participation from the application and if the probe fails, 391 the missing data (the "probe gap") is assured to fit within the 392 current MTU when it is retransmitted. However, the padding does 393 consume network capacity without carrying any useful payload. 395 This technique does not work for TCP, because there is not a separate 396 length field or other mechanism to differentiate between padding and 397 real payload data. With TCP the natural approach is to send 398 additional payload data in an over-sized segment. There are several 399 variants which have different tradeoffs. 401 In one method, after a TCP probe segment has been sent the subsequent 402 segment(s) may be sent as though the probe segment was not over- 403 sized. Thus if the probe segment is lost, it will leave a gap in the 404 sequence space that is exactly the correct size to be filled by one 405 segment at the current MTU. Since this method generates overlapping 406 data, it will cause duplicate acknowledgments if the probe is 407 successfully delivered. The sender must be capable of ignoring these 408 expected duplicate acknowledgments in a manner which will not cause 409 unnecessary retransmission or congestion window reduction. 411 In the second method, after a TCP probe segment has been sent, 412 subsequent TCP segments are sent in a non-overlapping manner. If the 413 probe segment is lost, it will leave a gap which will require 414 retransmission of multiple segments to fill. This method has lower 415 overhead for successful probes, but it requires more complexity in 416 the retransmit logic to correctly retransmit the missing data with 417 multiple segments that fit into the old MTU, while properly 418 suppressing the congestion adjustments for this one situation and no 419 others. 421 Under all conditions it is important that the packetization layer 422 sends additional data (packets) after the probe, such that Fast 423 Retransmit or equivalent algorithms in the packetization layer will 424 trigger the retransmission of the probe if it is lost in the network. 426 3.3. Normal sequence of events to raise the MTU 428 If the probe size is smaller than the path MTU and there are no other 429 losses, the normal sequence of events will be: 431 Step 1) The probe is sent, followed by more packets at the current MTU. 432 By definition PLPMTUD enters the probe phase. The probe propagates 433 through the network and the far node acknowledges it (or possibly 434 latter data, if ACKs are cumulative and delayed ACK is in effect). 436 Step 2) The ACK for the probe reaches the data sender. By definition, 437 this ends the probe phase. 439 Step 3) The packetization layer provisionally raises the MTU to the 440 probe size. PLPMTUD enters the transitional phase when it starts 441 sending data using the provisional MTU. 443 Note that implementations that use packet counts for congestion 444 accounting (e.g. keep cwnd in units of packets) must rescale their 445 congestion accounting such that raising the MTU does not raise the 446 total congestion window or data rate. 448 If the implementation packetizes the data at the application API, it 449 may transmit already queued data at the current MTU before raising 450 the MTU. In this case this data is not part of either the probing or 451 transition phases, because all of the packets in flight fit within 452 the current MTU. 454 Step 4) Once the first packet of the transitional phase is 455 acknowledged, PLPMTUD enters the verification phase to determine if 456 raising the MTU causes packet loss. In principle the verification 457 phase can be of arbitrary duration, however at this time we are 458 recommending one full window of data (i.e one full round trip time). 460 Step 5) Once there has been sufficient data delivered and acknowledged 461 in the provisional MTU is considered verified and the path MTU is 462 updated. PLPMTUD can then probe for an even larger MTU, as 463 described in the searching strategy in section 5.5. 465 3.4. Processing MTU Indications 467 Other events described below are treated as exceptions and alter or 468 cancel some of the steps above. 470 3.4.1. Processing Packet Too Big Messages 472 Classical PMTU discovery specifies the generation of Packet Too Big 473 Messages if an over-sized packet (e.g. a probe) encounters a link 474 that has a smaller MTU. Since these messages can not be 475 authenticated they introduce a number of well documented denial of 476 service attacks against classical PMTUD [DOS]. 478 In PLPMTUD these messages are not required for correct operation, so 479 in principle they can be summarily ignored at the expense of slower 480 convergence to the proper MTU. However we believe that a slightly 481 better compromise is to process Packet too big messages in two 482 specific contexts: in conjunction with a PLPMTUD probe or a 483 retransmission timeout in the packetization layer (indication a re- 484 route to a link with a smaller MTU). 486 Every Packet Too Big Message should be subjected to the following 487 checks: 489 o If globally forbidden then discard the message. 491 o If forbidden by the application then discard the message. 493 o If this path has been tagged "bogus ICMP messages" then discard the 494 message. 496 o If the reported MTU fails consistency checks then set "bogus ICMP 497 messages" flag for this path and discards the message. These 498 consistency checks include: unrecognized or unparseable enclosed 499 header, reported MTU is larger than the size indicated by the 500 enclosed header or larger than the current MTU, provisional MTU or 501 probe size as appropriate. 503 o If the Packet Too Big Message is acceptable under all of these 504 checks, save the "ICMP MTU", pending another packetization layer 505 protocol event. 507 3.4.2. Packetization Layer retransmits lost packets 508 Each packetization protocol has it's own mechanism to detect lost 509 packets and request the retransmission of missing data. The primary 510 signals used by the packetization layer are these protocol specific 511 loss indications. In all cases the packetization layer is 512 responsible for retransmitting the lost data and notifying PLPMTUD 513 that there was a loss. 515 o If the probe itself was lost, and there were no other losses during 516 the probe phase (The RTT between when the probe was sent and the loss 517 detected) than it is taken as an indication that the path MTU is 518 smaller than the probe size. In this situation alone the 519 Packetization Layer is permitted to retransmit the missing data (the 520 "probe gap") without adjusting its congestion window or data 521 transmission rate. 523 If an accepted Packet Too Big Message was received after the probe 524 was sent, and it passes the additional checks that the ICMP MTU is 525 greater than the current MTU, then set the provisional MTU to the 526 ICMP MTU and proceed from step 3 in section 3.3 above. 528 If there was not a accepted Packet Too Big Message, then the 529 indicated event is a "probe failure", which can be retried with a 530 smaller probe size after a suitable delay for a probe_failure_event. 531 See section 3.7 for more complete descriptions of failure events. 533 o If there are losses during the probe phase and the probe was not 534 lost, then the probe was successful. However, since additional loses 535 have the potential to spoil the verification phase, it is important 536 that PLPMTUD not progress into the transition phase (step 3 above) 537 until after the Packetization Layer has fully recovered from the 538 losses and completed the congestion window (or rate) adjustment. 540 o If there are losses during the probe phase and the probe was also 541 lost the outcome depends on the presence an ICMP MTU set by an 542 acceptable Packet Too Big Message. 544 If there was an accepted Packet Too Big Message received since the 545 probe was sent, and it passes the additional checks that the ICMP MTU 546 is greater than the current MTU, then set the provisional MTU to the 547 ICMP MTU, and once the Packetization Layer has fully recovered from 548 the losses and completed the congestion window (or rate) adjustment 549 then proceed to step 3 in section 3.3 above. 551 If there was not an accepted Packet Too big Message, then the probe 552 is inconclusive because the lost probe might have been caused by 553 congestion. The probe can be retried after a suitable delay for a 554 inconclusive_probe_event. 556 o Losses during the transition phase do not receive special treatment. 558 o Losses during the verification phase are taken as a indication that 559 the path may have a non-uniform MTU or some other problems such that 560 raising the MTU substantially raises the loss rate. If so, this is 561 potentially a very serious problem, so the provisional MTU is 562 considered to have failed the verification phase and the path MTU is 563 set back to the previously verified MTU (the previously the current 564 MTU). 566 Packet loss during the verification phase might also be due to 567 coincidental congestion on the path, unrelated to the probe, so it 568 would seem to be desirable that PLPMTUD re-probes the path. The risk 569 is that this effectively raises the tolerated loss threshold because 570 even though raising the MTU causes additional loss, there is a 571 statistical chance that repeated attempts to verify a the new MTU may 572 yield as false pass. The compromise is to re-probe once with the 573 same probe size (after delay inconclusive_probe_event), and if this 574 also fails, then the probe may not be retried until after a suitable 575 delay for a verification_fail_event, which exponentially increases on 576 each successive failure. 578 Losses during the verification phase may indicate that a Packet Too 579 Big Message reported the incorrect ICMP MTU, so if the provisional 580 MTU was updated from the ICMP MTU (which was from an earlier Packet 581 Too Big Message), set the "bogus ICMP message" flag for this path. 582 This will prevent PLPMTUD from processing further "Packet Too Big 583 Messages" for this path. If the provisional MTU was correct, the 584 re-probe above will correctly use it. If it was not correct, then 585 by definition the path reported at least one incorrect "Packet Too 586 Big Message", and should not process any additional messages. 588 3.4.3. Packetization Layer Retransmission Timeout 590 If there is a retransmission timeout during the probe or verification 591 phase it may be an indication of a serious problem with the path or 592 the Packetization Layer. We first define the notion of a "full stop 593 timeout" to be a timeout where the none of the packets transmitted 594 after some specific event at the sender (e.g. entering the probe or 595 verification phase) is acknowledged by the receiver. If a 596 retransmission timeout is not full stop it is processed above as 597 loss, except using longer delays before re-probing. 598 (probe_timeout_event, verification_timeout_event) 600 If there is a full stop timeout following a probe then it is taken as 601 an indication that probing may be disruptive to either the network or 602 the far node (e.g. it triggered a bug halt due to a buffer overrun, 603 etc). The probe should not be retried until after a long delay, for 604 probe_stop_event. Not that this makes it particularly important that 605 probes are only sent when the sender can send sufficient additional 606 data to assure the correct operation of Fast Retransmit and similar 607 algorithms in the Packetization Layer. 609 If there is a full stop timeout when the path MTU is raised to the 610 provisional MTU and the provisional MTU was updated from the ICMP 611 MTU, then it is assumed that the MTU reported in the Packet Too Big 612 Message was incorrect. Set the "bogus ICMP message" flag for this 613 path and re-probe with a smaller probe size after a suitable delay 614 for an ICMP_fail_event. 616 If there is a full stop timeout when the path MTU is raised to the 617 provisional MTU and the provisional MTU is the same as the probe size 618 (because the probe packet was not lost), then something truly 619 unexpected happened. It is possible that the timeout is unrelated 620 to the probe, so in this situation re-probe with a smaller probe size 621 after a suitable delay for an verification_stop_event. 623 3.5. Probing Intervals 625 Section 3.4 above describes a number of probe failure events. In 626 all cases the basic response is the same: to wait some time interval 627 (dependent on the specific event and possibly the history) and then 628 to probe again. For events that are "inconclusive", is is generally 629 appropriate to re-probe with the same probe size. For events that 630 are identified as "failed probes" is is generally appropriate to re- 631 probe with a smaller probe size. The search strategy described in 632 section 5.5 is used to select probe sizes. 634 Many of the intervals below are specified in terms of elapsed round 635 trips relative to the current congestion window. This is because 636 TCP and other Packetization Layer protocols tend to exhibit periodic 637 loses which cause periodic variations of the congestion window and 638 possibly the data rate. It is preferable that the PLPMTUD probes are 639 scheduled near the low point of these cycles. 641 In order from least to most serious: 643 inconclusive_probe_event - Packet loss near the lost probe marked the 644 result ambiguous. Since the loss of non-probe causes a window (or 645 data rate) reduction, it is desirable to schedule the re-probe (of 646 the same probe size) a few round trips after the end of the recovery. 648 ICMP_fail_event - Since this is detected by a timeout, it is first 649 desirable for the packetization protocol to come back into 650 equilibrium with the network (for TCP, this generally means recover 651 it's self clock by completing slowstart up to one half of the old 652 congestion window) before probing again with a smaller probe segment. 654 @@@ TODO finish 656 probe_failure_event - 658 verification_fail_event - 660 verification_timeout_event - 662 probe_timeout_event - 664 verification_stop_event - 666 3.6. Interoperation with prior algorithms 668 To cache or not. To ICMP or not - 670 Three choices for processing packet too big: ignore all, accept all 671 or only on probes. 673 Three choices for starting size: cached, small, or interface 675 4. Requirements 677 All Internet nodes SHOULD implement PLPMTUD in order to discover and 678 take advantage of the largest MTU supported along the Internet path. 680 Links MUST not deliver packets that are larger than their MTU. Links 681 that have parametric limitations (e.g. MTU bounds due to limited 682 clock stability) MUST include explicit mechanisms to consistently 683 reject packets that might otherwise be nondeterministically 684 delivered. 686 The requirements below only apply to those implementations that 687 include PLPMTUD. 689 If the IP protocol is IPv4 the DF bit must be set. 691 A packetization protocol MUST use a loss reporting mechanism 692 mechanism (e.g. SACK) which avoids spurious retransmission of any 693 other data when a probe packet is lost. 695 A Packetization Layer SHOULD NOT send a probe packet unless the flow 696 is expected to have at least the 3 round trips worth of data needed 697 to successfully complete the probing and verification process. 699 A Packetization Layer MUST NOT send a probe unless it has sufficient 700 data available to send such that a lost packet will trigger Fast 701 Retransmit or similar algorithm. 703 Failed and inconclusive probes MUST NOT be sent more frequently than 704 the normal congestion interval for the current average window size. 705 @@@@ too TCP specific 707 During the probe, the normal congestion control machinery MUST remain 708 in effect except when only the probe gap is detected as lost. In 709 this case the normal multiplicative congestion window reduction is 710 suppressed. If any other lost data is detected, all normal 711 congestion control MUST take place. 713 If the probe is successful, the current MPS is updated to the 714 candidate MPS. If window and other congestion state variables are 715 kept in units of packets, they MUST be rescaled to preserve the 716 current window size in bytes. @@ move 718 5. Implementation Issues 720 This section discusses a number of issues related to the 721 implementation of Path MTU Discovery. This is not a specification, 722 but rather a set of notes provided as an aid for implementers. 724 The issues include: 726 - What layer or layers implement Path MTU Discovery? 728 - Accounting for headers 730 - How is the PMTU information cached? 732 - How are ICMP messages processed 734 - How to implement PMTUD with TCP? 736 - What should other transport and higher layers do? 737 - What should tunnels above IP do? 739 5.1. Layering and Accounting for Header Sizes. 741 Packetization Layer Path MTU Discovery is most easily implemented by 742 splitting its functions between layers. The IP layer is in the best 743 place to keep shared state, collect the ICMP messages, track IP 744 headers sizes and manage MTU information from the link layer 745 interfaces. However the procedures that PLPMTUD uses for probing, 746 verifications and scanning for the path MTU are very tightly coupled 747 to the data recovery and congestion control state machines in the 748 Packetization Layer. The most difficult part of implementing 749 PLPMTUD is properly splitting the implementation between the layers. 751 Note that this layering is constant with the advice in the current 752 PMTUD specifications [RFC1191, RFC1981]. Today, many implementations 753 of classical PMTU Discovery are already split along these same 754 layers. 756 Early implementation of PLPMTUD revealed that it is critically 757 important to have a good clean mechanism for accounting header sizes 758 at all layers. This is because the Packetization Layer does its 759 calculations in its own natural data unit, which are almost always a 760 reflection of the service that the Packetization Layer provides to 761 the application or other upper layers. For example, TCP naturally 762 performs all of its calculations in terms of sequence numbers and 763 segment sizes, and the probe gap is the segment that was carried by 764 the probe packet. However, the probe size, ICMP MTU, etc are 765 measures of full packets, which not only include the TCP data and 766 fixed IP and TCP headers, but may also include IP extension headers 767 or options, TCP options and even IPsec AH or ESP headers. 769 PLPMTUD requires frequent bidirectional translation between these two 770 domains: the Packetization Layer's natural data unit and full IP 771 packet sizes. While there are a number of possible ways to 772 accurately implement this duality of size measures, our experience 773 has been that it is best if the boundary between the IP layer and the 774 Packetization layer communicate in terms of the IP Maximum Payload 775 Size or MPS. The MPS is the only size measure that is common to both 776 the IP and Packetization Layers, because it exactly matches the 777 boundary between the layers. The IP Layer is responsible for adding 778 or deducting it's own headers when translating between MTU and MPS. 779 Likewise the Packetization Layer is responsible for adding or 780 deducting its own headers when calculations in it's own natural data 781 units. 783 This document does not take a stance on the placement of IPsec, which 784 logically sits between IP and the Packetization Layer. IPsec can be 785 treated either as part of IP or as part of the Packetization Layer, 786 as long as the accounting is consistent within any given 787 implementation. If IPsec is treated as part of the IP layer, then 788 each security association to a remote node may need to be treated as 789 a separate flow if they have different length security headers. If 790 IPsec is treated as part of the packetization layer, the IPsec header 791 size has to be included in the Packetization Layer's header size 792 calculations. 794 5.2. Storing PMTU information 796 This memo uses the concept of a "flow" to define the scope in which 797 path MTU information is used. Each flow locally stores its maximum 798 payload size (MPS), which is used for packetizing data. Flows may 799 communicate with the IP layer to store or access cached PMTU values, 800 providing a means by which similar flows may share information. To 801 do so, the flow must convert between these two values by adding or 802 subtracting the size of the IP header plus any additional 803 intermediate headers. The IP layer also stores PMTU information from 804 the ICMP layer when it receives Packet Too Big messages. 806 Ideally, a PMTU value should be associated with a specific path 807 traversed by packets exchanged between the source and destination 808 nodes. However, in most cases a node will not have enough 809 information to completely and accurately identify such a path. 810 Rather, a node must associate a PMTU value with some local 811 representation of a path. It is left to the implementation to select 812 the local representation of a path. 814 An implementation could use the destination address as the local 815 representation of a path. The PMTU value associated with a 816 destination would be the minimum PMTU learned across the set of all 817 paths in use to that destination. The set of paths in use to a 818 particular destination is expected to be small, in many cases 819 consisting of a single path. This approach will result in the use of 820 optimally sized packets on a per-destination basis. This approach 821 integrates nicely with the conceptual model of a host as described in 822 [ND]: a PMTU value could be stored with the corresponding entry in 823 the destination cache. However, NAT and other forms of middle boxes 824 may exhibit differing MTUs at as single IP address. 826 If IPv6 flows [IPv6-SPEC] are in use, an implementation could use the 827 IPv6 flow id as the local representation of a path. Packets sent to 828 a particular destination but belonging to different flows may use 829 different paths, with the choice of path depending on the flow id. 830 This approach will result in the use of optimally sized packets on a 831 per-flow basis, providing finer granularity than PMTU values 832 maintained on a per-destination basis. 834 For source routed packets (i.e. packets containing an IPv6 Routing 835 header, or IPv4 LSRR or SSRR options), the source route may further 836 qualify the local representation of a path. An implementation 837 could use source route information in the local representation of a 838 path. 840 If IPsec is in use, the security association can also be used to 841 represent paths. 843 5.3. Host fragmentation 845 Packetization layers are encouraged to avoid sending messages that 846 will require fragmentation (for the case against fragmentation, see 847 [FRAG]). However this is not always possible. Some packetization 848 layers, such as a UDP application outside the kernel, may be unable 849 to change the size of messages it sends. This may result in packet 850 sizes that exceeds the Path MTU. 852 IPv4 permitted such applications to send packets without DF set. 853 These packets would be fragmented in the IP layer in the host or 854 fragmented by the network. This approach is no longer recommended. 856 We recommend that IPv4 implementation use a new strategy to mimic 857 IPv6 functionality. When the application sends packets that are too 858 large for the path they should be fragmented in the host IP layer. 859 However, the DF bit should be set on the fragments, so they will not 860 be fragmented again in the network. Note that in principle the IP 861 fragmentation layer is an example of a Packetization Layers, it could 862 implement full PLPMTUD in the fragmentation process. 864 At lease one major operating system already uses this strategy. 866 5.4. Multicast 868 In the case of a multicast destination address, copies of a packet 869 may traverse many different paths to reach many different nodes. The 870 local representation of the "path" to a multicast destination must in 871 fact represent a potentially large set of paths. 873 Minimally, an implementation could maintain a single MPS value to be 874 used for all packets originated from the node. This MPS value would 875 be the minimum MPS learned across the set of all paths in use by the 876 node. This approach is likely to result in the use of smaller 877 packets than is necessary for many paths. 879 Alternatively, if the application using multicast gets complete 880 delivery reports (unlikely because this requirement has poor scaling 881 properties), PLPMTUD could be implemented in multicast protocols. 883 5.5. Path MTU Search Strategy 885 The probe strategy described here is a recommended baseline 886 algorithm. It is not presented in formal standards language because 887 the probe strategy can include heuristics to help select an optimal 888 MSS for a given path. As a consequence there is opportunity for 889 future improvements to this algorithms. 891 The probing strategy has three major states: Search, Monitor and 892 Suspend. In the Search state, it sequentially searches for the 893 largest MSS that the path can support. Once the appropriate MPS has 894 been discovered, the probing algorithm enters the Monitor state where 895 it probes infrequently to detect if the path MPS has become larger. 897 If the MPS probing persistently fails it may be desirable to suspend 898 MPS probing and heuristically select one of the common default MSSs: 899 576, 1240, or 1460 Bytes. 901 5.5.1. Search 903 @@@ this entire section still needs to be rewritten @@@ 905 The recommended search strategy is a multi-phase scan: First, a 906 coarse scan for the approximate MTU using factor of 2 steps starting 907 at 1024 Bytes until a probe fails, followed by successively finer 908 scans between the largest previously successful and unsuccessful 909 probes. The TCP should use its best knowledge of the lower@@ layer 910 header sizes to appropriately determine the MPS from the MTUs listed 911 in the table below. 913 Table 1: Recommended MTU scanning sequence 914 (Coarse scan down column 1, fine scan across each row) 915 512, [Use only after repeated timeouts] 916 1024, 1492, 1500, 2002 917 2048 918 4096, 4352 919 8192, 9000 920 16384, 17914 921 32768 922 64512 923 ((Additional values needed)) 925 During the scan it is recommended that the MPS not be raised if cwnd 926 is too small as determined by a heuristic. The recommended heuristic 927 is that the MPS is only raised when the cwnd is larger than 20 928 segments. @@@ This may be too high. 930 5.5.2. Monitor 932 Once the scan has found an appropriate MPS, the probe strategy enters 933 the Monitor state, where it re-probes the most recent failed MTU, 934 once every MONITOR_INTERVAL seconds. If the probe fails, it remains 935 in the Monitor state. If it succeeds, it enters the scanning state. 937 If the network becomes too congested during either the Search or the 938 Monitor states, it is recommended that the MPS be reduced to a 939 smaller size as determined by a heuristic. The recommended heuristic 940 is to reduce the MSS if ssthresh is reduced to 5 segments or smaller. 941 The recommended reduction is to the next smaller coarse step in Table 942 1. 944 When there are repeated timeouts (MAX_TIMO or more retransmissions, 945 without any received ACKs), it is presumed that the connection was 946 re-routed onto a link with a smaller MSS, and that ICMP messages are 947 not being delivered. The MSS probing algorithms is reset by pulling 948 back the MSS to 1024 Bytes, rescaling the congestion control 949 variables and reentering the Search state. 951 5.5.3. Suspend 953 If there is a timeout, and cwnd prior to the timeout was smaller than 954 6 packets, then the probe strategy can enter the Suspend state and 955 set the MSS to 512 or 1240 Bytes. This has the effect of reducing 956 the minimum data rate that TCP can stably manage. 958 5.6. Implementation issues for specific Packetization Layers 960 Different protocols introduce specific problems. 962 5.6.1. Probing method using TCP 964 TCP has no mechanism that could be used to distinguish between real 965 application data and some other form of padding that might be used to 966 fill out probe packets. Therefor, TCP must generate probes by 967 sending oversized segments that are carrying real application date. 968 As previously mentioned there are two approaches that TCP might use 969 to minimize the overheads associated with the probing process. 971 A TCP implementation of PLPMTUD can elect to send subsequent segments 972 as though the probe segment was not oversized. This has the 973 advantage that TCP only need to retransmit a segment at the current 974 MTU to recover from failed probes. However the duplicate data in the 975 probe does consume network resources and will cause duplicate 976 acknowledgments. It is important that these extra duplicate 977 acknowledgments not trigger Fast Retransmit. This can be guaranteed 978 by limiting the largest probe segment size to twice the current 979 segment size (causing at most 1 duplicate acknowledgment) three times 980 the current segment size (causing at most 2 duplicate 981 acknowledgments. 983 The other approach is to send non-overlapping segments following the 984 probe. Although this is cleaner from a protocol architecture 985 standpoint it clashes with many of the optimizations used improve the 986 efficiency of data motion withing many operating systems. In 987 particular many implementations divide the data into segments and 988 precompute checksums as the data is copied out of user space. In 989 these implementation it can be very expensive to adjust segment 990 boundaries after the data is already queued. 992 If TCP is using SACK or any other variable length headers, the 993 headers on the probe and verification packets should be padded to the 994 maximum possible length. Otherwise, large headers may cause delivery 995 problems for future segments. 997 Note that the header size and overhead calculations described in 998 section @@@ apply here. TCP's natural data accounting units are 999 sequence space and Maximum Segment Size. However the the PLPMTUD 1000 process is described in terms of total packet size, which is larger 1001 than the MSS by all fixed and optional headers. 1003 At the point when TCP is ready to start verification, it is permitted 1004 to not re-packetize already queued data. This postpones the 1005 verification process by the time required to send the queued data. 1007 If the verification phase experiences any segment losses, TCP is 1008 required to pull back to the prior MSS. Since failing the 1009 verification phase should be an infrequent error condition it is 1010 less important that this be as efficient as probing. 1012 5.6.2. Probing method using SCTP 1014 In the SCTP protocol packetization is the responsibility of the 1015 application or protocol above SCTP. By implication SCTP can not 1016 easily generate probes sending additional application data. 1018 For SCTP the recommended method for generating probes is to pad 1019 messages by @@@@@@ or by sending a message that consists entirely of 1020 padding and no application data. 1022 The verification phase ...... 1024 5.6.3. Issues for tunnels 1026 @@@ to be written 1028 5.6.4. Issues for other transport protocols 1030 Some transport protocols (such as ISO TP4 [ISOTP]) are not allowed to 1031 repacketize when doing a retransmission. That is, once an attempt is 1032 made to transmit a segment of a certain size, the transport cannot 1033 split the contents of the segment into smaller segments for 1034 retransmission. In such a case, the original segment can be 1035 fragmented by the IP layer during retransmission. Subsequent 1036 segments, when transmitted for the first time, should be no larger 1037 than allowed by the Path MTU. 1039 5.7. Diagnostic tools 1041 All implementations MUST include a mechanism to implement diagnostic 1042 tools that do not rely on the operating systems implementation of 1043 path MTU discovery. This requires an mechanism where an application 1044 can send oversized packets that are not subjected to the operating 1045 systems notion of the current path MTU, up to the physical MTU limit 1046 as supported by the network interface, as well as a mechanism to 1047 collect any Packet Too Big Messages. 1049 5.8. Management interface 1051 It is suggested that an implementation provide a way for a system 1052 utility program to: 1054 - Specify that Path MTU Discovery not be done on a given path. 1056 - Change the PMTU value associated with a given path. 1058 - Global controls on ICMP processing 1060 - Per connection or per application controls on ICMP processing 1062 The former can be accomplished by associating a flag with the path; 1063 when a packet is sent on a path with this flag set, the IP layer does 1064 not send packets larger than the IPv6 minimum link MTU. 1066 These features might be used to work around an anomalous situation, 1067 or by a routing protocol implementation that is able to obtain Path 1068 MTU values. 1070 The implementation should also provide a way to change the timeout 1071 period for aging stale PMTU information. 1073 6. Normative references 1075 [RFC1191] Path MTU discovery. J.C. Mogul, S.E. Deering. Nov-01-1990. 1076 (Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT 1077 STANDARD) 1079 [RFC1981] Path MTU Discovery for IP version 6. J. McCann, S. Deering, 1080 J. Mogul. August 1996. (Status: PROPOSED STANDARD) 1082 [RFC2119] Key words for use in RFCs to Indicate Requirement Levels. S. 1083 Bradner. March 1997. (Status: BEST CURRENT PRACTICE) 1085 7. Informative references 1087 [RFC1063] IP MTU discovery options. J.C. Mogul, C.A. Kent, C. Par- 1088 tridge, K. McCloghrie. Jul-01-1988. (Obsoleted by RFC1191) 1090 [RFC1435] IESG Advice from Experience with Path MTU Discovery. S. 1091 Knowles. March 1993. (Format: TXT=2708 bytes) (Status: 1092 INFORMATIONAL) 1094 [RFC1626] Default IP MTU for use over ATM AAL5. R. Atkinson. May 1994. 1095 (Status: PROPOSED STANDARD) 1097 [RFC1791] TCP And UDP Over IPX Networks With Fixed Path MTU. T. Sung. 1098 April 1995. (Status: EXPERIMENTAL) 1100 [RFC2923] TCP Problems with Path MTU Discovery. K. Lahey. September 1101 2000. (Status: INFORMATIONAL) 1103 8. Security considerations 1105 Since the MTU reported in the ICMP messages is constrained to be 1106 between the old MTU and the candidate MTU, this algorithm is more 1107 difficult to attack through fraudulent ICMP messages. 1109 Furthermore, since this algorithm can function properly without ICMP 1110 messages that part of the algorithm can be disabled for additional 1111 robustness in hostile environments. 1113 9. IANA considerations 1115 10. Contributors 1117 11. Acknowledgements 1119 Matt Mathis and John Heffner are supported by a grant from Cisco Sys- 1120 tems, Inc. 1122 12. Authors' addresses 1124 Please send comments and suggestions to pmtud@ietf.org. 1126 Matt Mathis and John Heffner 1127 Pittsburgh Supercomputing Center 1128 4400 Fifth Ave. 1129 Pittsburgh, PA 15213 1130 mathis@psc.edu 1131 jheffner@psc.edu 1133 Kevin Lahey 1134 Freelance 1135 kml@patheticgeek.net 1137 13. Intellectual Property 1139 The IETF takes no position regarding the validity or scope of any 1140 intellectual property or other rights that might be claimed to per- 1141 tain to the implementation or use of the technology described in this 1142 document or the extent to which any license under such rights might 1143 or might not be available; neither does it represent that it has made 1144 any effort to identify any such rights. Information on the IETF's 1145 procedures with respect to rights in standards-track and standards- 1146 related documentation can be found in BCP-11. Copies of claims of 1147 rights made available for publication and any assurances of licenses 1148 to be made available, or the result of an attempt made to obtain a 1149 general license or permission for the use of such proprietary rights 1150 by implementers or users of this specification can be obtained from 1151 the IETF Secretariat. 1153 The IETF invites any interested party to bring to its attention any 1154 copyrights, patents or patent applications, or other proprietary 1155 rights which may cover technology that may be required to practice 1156 this standard. Please address the information to the IETF Executive 1157 Director. 1159 14. Full copyright statement 1161 Copyright (C) The Internet Society 14 Feb, 2004. All Rights Reserved. 1163 This document and translations of it may be copied and furnished to 1164 others, and derivative works that comment on or otherwise explain it 1165 or assist in its implementation may be prepared, copied, published 1166 and distributed, in whole or in part, without restriction of any 1167 kind, provided that the above copyright notice and this paragraph are 1168 included on all such copies and derivative works. However, this doc- 1169 ument itself may not be modified in any way, such as by removing the 1170 copyright notice or references to the Internet Society or other 1171 Internet organizations, except as needed for the purpose of develop- 1172 ing Internet standards in which case the procedures for copyrights 1173 defined in the Internet Standards process must be followed, or as 1174 required to translate it into languages other than English. 1176 The limited permissions granted above are perpetual and will not be 1177 revoked by the Internet Society or its successors or assigns.