idnits 2.17.1 draft-park-pmtu-ipv6-option-header-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 98 instances of lines with control characters in the document. ** The abstract seems to contain references ([1981]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 412 has weird spacing: '...mporary value...' == Line 461 has weird spacing: '...becomes minim...' -- 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.) -- The document date (March 2003) is 7711 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) -- Looks like a reference, but probably isn't: 'RFC2026' on line 14 -- Looks like a reference, but probably isn't: 'Bradner' on line 567 == Missing Reference: '1996' is mentioned on line 567, but not defined == Unused Reference: '2460' is defined on line 538, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2463 (Obsoleted by RFC 4443) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Soohong Daniel Park 3 Expires: September 2003 Hakgoo Lee 4 SAMSUNG Electronics 5 March 2003 7 The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header 8 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [RFC2026]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document presents a new method for the PMTU discovery for IPv6. 34 To discover the PMTU of a path, a source node measures its actual PMTU 35 using the newly defined Hop-by-Hop Option header, whereas a source 36 node initially assumes that the PMTU of a path is the known MTU of 37 the first hop in the path in the previous one [1981]. In order to 38 measure the actual PMTU, the source node sends the IP packet with the 39 newly defined Hop-by-Hop Option header to the destination node with 40 the first data packet when node is beginning. This can eliminate the 41 chance of occurrence of several iterations of the somewhat complex 42 discovery cycle (sending a packet, receiving a Packet Too Big message, 43 reducing a packet size). Most of all, since existing PMTU has a weak 44 point for security and denial-of-service attacks, this document 45 suggests a security function when PMTU is going on. 47 All IPv6 nodes, including both hosts and routers, must implement newly 48 Options as defined in this specification. 50 Table of Contents 52 Abstract 53 1. Introduction 54 2. Terminology 55 3. Proposed Method : Overview 56 3.1 Request MAP Option Format 57 3.2 Response MAP Option Format 58 4. Node Requirements for Discoverying PMTU 59 4.1 Source Node and Destination Node 60 4.2 Nodes on Routing Path 61 4.3 Operation Procedure 62 5. Mode Requirements for Detecting PMTU 63 5.1 Source Node and Destination Node 64 5.2 Nodes on Routing Path 65 5.3 Operation Procedure 66 6. Comparison with [1981] 67 7. Security Considerations 68 8. Normative Reference 69 9. Informative References 70 10. Acknowledgements 71 11. Authors' Addresses 72 12. Intellectual Property 73 13. Copyright 75 1. Introduction 77 The discovery of the Path MTU (PMTU) is described in [1981]. The basic 78 idea of [1981] is that a source node initially assumes that the a 79 path's PMTU is the known MTU of the first hop in the path. If any of 80 the packets sent on that path are too large to be forwarded by some 81 node along the path, that node will discard them and return ICMPv6 82 Packet Too Big messages [2463]. Upon receipt of such a message, the 83 source node reduces its assumed PMTU for the path based on the MTU of 84 the constricting hop as reported in the Packet Too Big message. The 85 PMTU Discovery process ends when packets arrive at the destination 86 node. 88 However, in [1981], there may be several iterations of the somewhat 89 complex discovery cycle (sending a packet, receiving a Packet Too Big 90 message, reducing a packet size), before the actual PMTU is obtained. 91 In the worst case, the number of interactions becomes the number of 92 hops in the path. This method might be somewhat inefficient. 94 Therefore, a new method for the PMTU discovery is suggested in this 95 document. In this new method, to discover the PMTU of a path, the 96 source node measures its actual PMTU using the newly defined 97 Hop-by-Hop Option header. To measure the actual PMTU, the source node 98 sends the IP packet with the newly defined Hop-by-Hop Option header 99 to the destination node with the first data packet which should be the 100 its link MTU when node is beginning. After then, the measured PMTU is 101 used to send the subsequent packets. 103 Now, another problem can be considered in PMTU Discovery [1981]. Due 104 to changes in the routing topology, the PMTU of a path may change over 105 time. In [1981], to detect increases of the PMTU of a path, the source 106 node periodically increases its assumed PMTU although this is done 107 infrequently (10 minutes in general). However, in this method, the 108 assumed PMTU is increased by the source node's link MTU 109 unconditionally. This may also result in several iterations of the 110 discovery cycle. This problem can be also resolved by the proposed 111 method. 113 Therefore, in both discovering PMTU and detecting PMTU's increases, 114 the proposed method can eliminate the chance of occurrence of several 115 iterations of the somewhat complex discovery cycle. Thus, the proposed 116 method in this document can be helpful for the best-conditioned 117 network environment because the actual PMTU is measured dynamically 118 for changes in the routing topology. 120 Finally, existing PMTU [1981] mechanism makes possible some denial-of- 121 service attacks, most of all, both are based on a malicious party 122 sending false Packet Too Big messages to a victim. Accordingly both 123 weak points, it will result in suboptimal performance and availability 124 of denial-of-service attacks. This document suggests the secure PMTU 125 method. It is described in section 7. 127 2. Terminology 129 o PMTU is the minimum link MTU of all the links 130 in a path between a source node and a 131 destination node. 133 o MTU is stands for Maximum Transmission Unit. 134 i.e., maximum packet size in octets, 135 that can be conveyed in one piece over 136 a link. 138 o Detection Timer Nodes may send PMTU packet at infrequent 139 intervals in order to detect an increase. 140 The recommended setting for this timer 141 is same value as [1981]. (10 minutes) 143 o Response Timer If the source node does not receive the 144 packet with Response MAP Option until 145 the Response Timer expires, the source 146 node initially assumes that the PMTU 147 of a path is the MTU of the first hop 148 in the path as [1981]. 150 o MAP is stands for Measuring Actual PMTU. In 151 order to perform MAP, newly MAP Option 152 must be done. 154 o Discoverying PMTU When node is beginning, node should 155 perform PMTU to discovery its own value. 157 o Detecting PMTU's Increase 158 Nodes may detect increases in PMTU. 160 o Request MAP Option is used to request MAP information to 161 destination. See section 3.1 163 o Response MAP Option is used to response MAP information to 164 source. See section 3.2 166 3. Proposed Method : Overview 168 This section gives a brief overview of the new method for the 169 discoverying and detecting PMTU mechanisms. 171 A router on routing path examines only IP header, Hop-by-Hop Option 172 header and routing header in extension header. Other extension headers 173 and data are examined only by a source node and destination node. 174 In the new method, Hop-by-Hop Option header is used to measure 175 increases in a path's PMTU 177 The Hop-by-Hop Option header and Option is defined as below. 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Next Header | Hdr Ext Len | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 182 | | 183 . . 184 . Options . 185 . . 186 | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189
191 Currently, Hop-by-Hop Option headers are Pad1, PadN, Jumbo Payload, 192 and Router Alert Options. This document defines a new Option. It is 193 called 'Measuring Actual PMTU (MAP Option)'. Then, the IP packet 194 including Hop-by-Hop Option header with MAP Option has the following 195 format. 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |Version| Traffic Class | Flow Label | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Payload Length | Next Header | Hop Limit | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | 203 + + 204 | | 205 + Source Address + 206 | | 207 + + 208 | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | | 211 + + 212 | | 213 + Destination Address + 214 | | 215 + + 216 | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Next Header | 0 | Option Type | Opt Data Len | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Option Data(PMTU) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Option Type 8-bit identifier of the type of Option. 225 Opt Data Len 8-bit unsigned integer. Length of the Option 226 Data field of this Option, in octets. 228 Option Data(PMTU) Measured PMTU value with 4 bytes 230
232 The Option Type identifiers are internally encoded such that their 233 highest-order two bits specify the action that must be taken when 234 the router does not recognize the Option Type. The third highest 235 order bit of the Option Type specifies whether or not the Option 236 Data (PMTU) of that Option can change en-route to the packet's 237 final destination. The other five bits are defined arbitrarily. 238 The MAP Option has two Option Types. The one is Request MAP Option 239 and the other is Response MAP Option, which will be shown in 240 following subsections. If any of the routers en-route cannot 241 recognize the Option Types, it skips over or discards the packet 242 silently. It depends on operator policy. 244 o The highest-order two bits of the Option type is 00 245 If routers are not understand MAP Options, this packet 246 must be skipped over this Option and continue processing 247 the header. When this Option meets with possible router, 248 this PMTU must be modified. When source node receives 249 this response, it is not actual PMTU because all routers 250 are not understand. If received MTU is larger than its 251 own value, this MTU should be ignored. 252 Note : In initiation case, node must use "00" value 253 because of response error message 254 (Packet Too Big message). 256 o The highest-order two bits of the Option type is 01 257 If routers are not understand MAP Options, this packet 258 must be discarded, at this case, source node has its 259 waiting time. When this time is expired without any 260 response, this node should perform original PMTU as 261 [1981]. 263 This document suggests that if specific link should be performed with 264 small PMTU value, at this point, MAP Options should be applied. 266 3.1 Request MAP Option Format 268 The Request MAP Option format is defined to measure real PMTU as 269 shown in Figure 3. The source node sends the IP packet with this 270 Request MAP Option format to the destination node. 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 |0 x 1|1 0 0 0 0|0 0 0 0 0 1 0 0| 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | P M T U | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Highest-order two bits 279 00 - Skip over this Option and continue processing the header 280 01 - discard the packet 282 The third-highest-order bit 283 1 - Option Data may change en-route 285 Option Type - 112 (temporary value) 287 Option Length - 4 289 PMTU - 4 Octets 291
293 3.2 Response MAP Option Format 295 The Response MAP Option format is defined to response measured 296 real PMTU as shown in Figure 3. The destination node sends the IP 297 packet with this Response MAP Option format to the source node. 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 |0 x 0|1 1 0 0 0|0 0 0 0 0 1 0 0| 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | P M T U | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Highest-order two bits 306 00 - Skip over this Option and continue processing the header 307 01 - discard the packet 309 The third-highest-order bit 310 0 - Option Data does not change en-route 312 Option Type - 88 (temporary value) 314 Option Length - 4 316 PMTU - 4 Octets 318
320 3.3 Discoverying PMTU with MAP Options 322 The source node sends IP packet with Request MAP Option to the 323 destination node when node is beginning to communicate. Initial MTU 324 value should be its link MTU of the source node. After node receives 325 Response MAP Option with PMTU, the subsequent packets will be sent of 326 course using obtained PMTU. If the first packet with the IPv6 minimum 327 link MTU don't go through the next-hop, its node must not reduce its 328 estimate of the PMTU below the IPv6 minimum link MTU. At this case, 329 node may receive a Packet Too Big message reporting a next-hop MTU 330 that is less than IPv6 minimum link MTU. Then, node must include a 331 Fragment header in those packets. This packet should be composed of 332 the following headers: 334 IPv6 Header 335 Hop-by-Hop Options with Request/Response MAP Option 336 Fragment 337 ... 339 While the packet is passing through nodes en-route, the following 340 action occurs. 342 - Compare PMTU in Request MAP Option and Link MTU of next hop. 343 - Store the smaller value between them on PMTU field of the packet. 345 By doing the same action on routers en-route, PMTU field of the IP 346 packet with Request MAP Option is updated to have minimum PMTU. 347 This is the actual PMTU value. The destination node that receives 348 the IP packet returns back this value to the source node using 349 Response MAP Option. The source node that receives the actual PMTU 350 value determines the transmission length of a packet. However, if 351 all routers don't recognize MAP Options, responsed MTU is not actual 352 PMTU. 354 3.4 Detecting PMTU with MAP Options 356 As described on Path MTU Discovery [1981], a source node sends IP 357 packet with Request MAP Option to a destination node before the 358 Detection Timer expires so that it wants to increase PMTU value. 359 Default MTU value is link MTU of the source node. This packet 360 should be composed of the following headers: 362 IPv6 Header 363 Hop-by-Hop Options with Request/Response MAP Option 364 While the packet is passing through nodes en-route, the actions are 365 the same as section 3.3 367 By doing the same action on routers en-route, PMTU field of the IP 368 packet with Response MAP Option is updated to have minimum PMTU. 369 This is the optimal PMTU value. The destination node that receives 370 the IP packet returns back this value to the source node using 371 Response MAP Option. The source node that receives the optimal PMTU 372 value determines the transmission length of a packet. This method can 373 reduce the number of ICMP-Packet Too Big Error message, otherwise 374 happens more frequently. This also reduce waste of network resource. 376 4. Node Requirements for Discoverying PMTU 378 4.1 Source Node and Destination Node 380 When the IPv6 source node has a large amount of packets to send to the 381 destination node, the source node sends the IP packet with Request MAP 382 Option to the destination when node is beginning. The PMTU field of 383 Request MAP Option of the packet initialized by the value of its link 384 MTU of the source node. If router does not understand the MAP Options, 385 the packet is skipped over this Option and continue processing the 386 header (See section 3.). When node receives the Packet Too Big message 387 this node should be performed existing PMTU as [1981]. 389 Whenever the destination node receives the IP packet with Request MAP 390 Option, it must response the IP packet with Response MAP Option 391 immediately. By the Option Type, this packet cannot be modified by 392 routers on routing path. 394 4.2 Nodes on Routing Path 396 Nodes on a routing path are routers. When the IP packet with Request 397 MAP Option arrives on these routers, they compare the PMTU in Request 398 MAP Option and link MTU of the next hop. They select a smaller value 399 between them and forward the packet with a PMTU value. After doing 400 the same procedure, the final destination node comes to know minimum 401 PMTU. If the IP packet with Response MAP Option arrives on theses 402 routers, they forward the packet without any modification. If routers 403 can not recognize two MAP Options, it skips over this Option and 404 continue processing the header since the first two bits of the MAP 405 Option is 00. (See section 3.). 407 4.3 Operation Procedure 409 When the IPv6 source node sends to the destination node, the source 410 node sends the IP packet with Request MAP Option and its link MTU of 411 the source node to a destination. In this case, the Option Type in 412 Request MAP Option is 112 (temporary value). While the packet is 413 en-route, intermediate routers compare the PMTU in Request MAP Option 414 and link MTU of the next hop. They select a smaller value between 415 them, store the value to PMTU field of Request MAP Option and forward 416 the packet with the updated PMTU. PMTU of the packet arrived at the 417 destination node becomes minimum PMTU. The destination node sends the 418 IP packet Response MAP Option to inform the source node. In this case, 419 the Option Type in Request MAP Option is 88 (temporary value). After 420 then, the source node sends packets using new PMTU. If routers 421 implements only previous PMTU Discovery [1981] on routing path, in 422 this case the router can skip over this Option and continue processing 423 the header. If node receives the Packet Too Big message, the source 424 node should be performed existing PMTU as [1981]. If node receives 425 Response MAP Option, the source node must compare with its own MTU 426 value. The source node selects a smaller value between them and store. 428 Therefore, in discovering PMTU, the proposed method can eliminate 429 the chance of occurrence of several iterations of the discovery 430 cycle. 432 5. Node Requirements for Detecting PMTU 434 5.1 Source Node and Destination Node 436 A source node does not change the PMTU value for some amount of time 437 after it comes to know PMTU based on PMTU Discovery [1981]. When the 438 source node wants to increase PMTU by the Detection Timer, it sends 439 the IP packet with MAP Options to a destination. The PMTU field of 440 MAP Options of the packet contains the value of link MTU of the 441 source node and the data. Whenever a destination node receives the 442 IP packet with Request MAP Option, it must response the IP packet 443 with Response MAP Option immediately. By the Option Type, this packet 444 cannot be modified by routers on routing path. Also, it can use both 445 type "00" and "01". It depends on operator policy. In order to use 446 type "01", source node must have its timer, Response Timer. 448 5.2 Nodes on Routing Path 450 This processing is same as section 4.2 452 5.3 Operation Procedure 454 When the source node wants to increase PMTU by the Detection Timer, 455 it sends the IP packet with Request MAP Option to a destination. 456 In this case, the Option Type in Request MAP Option is 112 (temporary 457 value). While the packet is en-route, intermediate routers compare the 458 PMTU in MAP Option and link MTU of the next hop. They select a smaller 459 value between them, store the value to PMTU field of MAP Option and 460 forward the packet with the updated PMTU. PMTU of the packet arrived 461 at the destination node becomes minimum PMTU. The destination node 462 sends the IP packet Response MAP Option to inform the source node. In 463 this case, the Option Type in Response MAP Option is 88 (temporary 464 value). After then, the source node sends packets using new PMTU.if 465 routers implements only previous PMTU Discovery [1981] on routing 466 path, in this case the router can silently discard the packet 467 without response error message by the highest-order two bits, 01, 468 in Option Type field or skip over this Option and continue processing 469 the header with MAP Options by the highest-order two bits, 00, in 470 Option Type field. If the source node does not receive the IP packet 471 with Response MAP Option until the Response Timer expires, the source 472 node initially assumes that the PMTU of a path is the MTU of the first 473 hop in the path as [1981]. 475 6. Comparison with [1981] 477 This section should be discussed more detail. 479 o In order to perform PMTU, [1981] uses ICMPv6, but MAP uses 480 only basic IPv6 protocol and extension header with newly 481 Option. We assure that it should be implemented very easy in 482 host and router as well. 484 o In the aspect of implementation, all IPv6 nodes, including 485 both hosts and routers, must implement newly Options as 486 defined in this specification. 488 o As described in [1981], MAP should consider all 489 implementation issues. 491 7. Security Considerations 493 As we knew, existing PMTU [1981] mechanism makes possible two denial 494 -of-service attacks, most of all, both are based on a malicious 495 party sending false Packet Too Big messages to a victim. 496 Accordingly both weak points, it will result in suboptimal 497 performance and availability of denial-of-service attacks. 499 MAP mechanism is not likely to do denial-of-service attacks. However 500 when malicious node sends false MAP response with its correct type, 501 there are still simpler denial-of-service attacks available. 503 This document considers the protection method from various attacks. 504 In order to avoid spoofing or attacking with incorrect response, 505 MAP mechanisms can use the 64-bit Nonce field. Its value in a MAP 506 Option is always copied from the corresponding Request MAP by the 507 responder. This method is an Optional, therefore the usage of this 508 method depends on operator. However this document recommends this 509 method is implemented with MAP Options for the secure PMTU. 511 +... + 512 | Original IPv6 Header | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Next Header | 1 |MAP Option Typ |0 0 0 0 1 1 0 0| 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | | 517 + Nonce | 518 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Option Data(PMTU) | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523
525 The Nonce should be a random or good pseudo-random value to foil 526 spoofed replied. An implementation which allows multiple independent 527 processes to send MAP Option may use the Nonce value to deliver MAP 528 Option to the correct process. Nonetheless, such processes must 529 check the received Nonce and ignore extraneous response. 531 8. Normative Reference 533 [1981] J. McCann, S. Deering, J. Mogul, "Path MTU Discovery for 534 IP version 6", RFC 1981, August 1996. 536 9. Informative References 538 [2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 539 (IPv6)", RFC 2460, December 1998. 541 [2463] A. conta, S. Deering, "Internet Control message Protocol 542 (ICMP) for the Internet Protocol Version 6 (IPv6) 543 Specification", RFC 2463, December 1998. 545 9. Acknowledgements 547 The authors would like to thank Robert Hinden for his careful reviews 548 of this draft. 550 10. Authors' Addresses 552 Soohong Daniel Park 553 SAMSUNG Electronics 554 Digital Media R&D Center 555 Tel : +82-31-200-3728 556 Fax : +82-31-200-3147 557 E-mail : soohong.park@samsung.com 558 Hakgoo Lee 559 SAMSUNG Electronics 560 Digital Media R&D Center 561 Tel : +82-31-200-9309 562 Fax : +82-31-200-3147 563 E-mail : solited@samsung.co.kr 565 11. Intellectual Property 567 The following notice is copied from RFC 2026 [Bradner, 1996], 568 Section 10.4, and describes the position of the IETF concerning 569 intellectual property claims made against this document. 571 The IETF takes no position regarding the validity or scope of any 572 intellectual property or other rights that might be claimed to 573 pertain to the implementation or use other technology described in 574 this document or the extent to which any license under such rights 575 might or might not be available; neither does it represent that it 576 has made any effort to identify any such rights. Information on the 577 IETF's procedures with respect to rights in standards-track and 578 standards-related documentation can be found in BCP-11. Copies of 579 claims of rights made available for publication and any assurances 580 of licenses to be made available, or the result of an attempt made 581 to obtain a general license or permission for the use of such 582 proprietary rights by implementers or users of this specification 583 can be obtained from the IETF Secretariat. 585 The IETF invites any interested party to bring to its attention any 586 copyrights, patents or patent applications, or other proprietary 587 rights which may cover technology that may be required to practice 588 this standard. Please address the information to the IETF Executive 589 Director. 591 12. Copyright 593 The following copyright notice is copied from RFC 2026 [Bradner, 594 1996], Section 10.4, and describes the applicable copyright for this 595 document. 597 Copyright (C) The Internet Society July 12, 2001. All Rights Reserved. 599 This document and translations of it may be copied and furnished to 600 others, and derivative works that comment on or otherwise explain it 601 or assist in its implementation may be prepared, copied, published 602 and distributed, in whole or in part, without restriction of any 603 kind, provided that the above copyright notice and this paragraph 604 are included on all such copies and derivative works. However, this 605 document itself may not be modified in any way, such as by removing 606 the copyright notice or references to the Internet Society or other 607 Internet organizations, except as needed for the purpose of 608 developing Internet standards in which case the procedures for 609 copyrights defined in the Internet Standards process must be 610 followed, or as required to translate it into languages other than 611 English. 613 The limited permissions granted above are perpetual and will not be 614 revoked by the Internet Society or its successors or assignees. 616 This document and the information contained herein is provided on an 617 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 618 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 619 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 620 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 621 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.