INTERNET-DRAFT Soohong Daniel Park Expires: September 2003 Hakgoo Lee SAMSUNG Electronics March 2003 The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document presents a new method for the PMTU discovery for IPv6. To discover the PMTU of a path, a source node measures its actual PMTU using the newly defined Hop-by-Hop Option header, whereas a source node initially assumes that the PMTU of a path is the known MTU of the first hop in the path in the previous one [1981]. In order to measure the actual PMTU, the source node sends the IP packet with the newly defined Hop-by-Hop Option header to the destination node with the first data packet when node is beginning. This can eliminate the chance of occurrence of several iterations of the somewhat complex discovery cycle (sending a packet, receiving a Packet Too Big message, reducing a packet size). Most of all, since existing PMTU has a weak point for security and denial-of-service attacks, this document suggests a security function when PMTU is going on. All IPv6 nodes, including both hosts and routers, must implement newly Options as defined in this specification. Park,Lee Expires September 2003 [Page 1] INTERNET-DRAFT March 2003 Table of Contents Abstract 1. Introduction 2. Terminology 3. Proposed Method : Overview 3.1 Request MAP Option Format 3.2 Response MAP Option Format 4. Node Requirements for Discoverying PMTU 4.1 Source Node and Destination Node 4.2 Nodes on Routing Path 4.3 Operation Procedure 5. Mode Requirements for Detecting PMTU 5.1 Source Node and Destination Node 5.2 Nodes on Routing Path 5.3 Operation Procedure 6. Comparison with [1981] 7. Security Considerations 8. Normative Reference 9. Informative References 10. Acknowledgements 11. Authors' Addresses 12. Intellectual Property 13. Copyright 1. Introduction The discovery of the Path MTU (PMTU) is described in [1981]. The basic idea of [1981] is that a source node initially assumes that the a path's PMTU is the known MTU of the first hop in the path. If any of the packets sent on that path are too large to be forwarded by some node along the path, that node will discard them and return ICMPv6 Packet Too Big messages [2463]. Upon receipt of such a message, the source node reduces its assumed PMTU for the path based on the MTU of the constricting hop as reported in the Packet Too Big message. The PMTU Discovery process ends when packets arrive at the destination node. However, in [1981], there may be several iterations of the somewhat complex discovery cycle (sending a packet, receiving a Packet Too Big message, reducing a packet size), before the actual PMTU is obtained. In the worst case, the number of interactions becomes the number of hops in the path. This method might be somewhat inefficient. Therefore, a new method for the PMTU discovery is suggested in this document. In this new method, to discover the PMTU of a path, the source node measures its actual PMTU using the newly defined Hop-by-Hop Option header. To measure the actual PMTU, the source node sends the IP packet with the newly defined Hop-by-Hop Option header to the destination node with the first data packet which should be the its link MTU when node is beginning. After then, the measured PMTU is used to send the subsequent packets. Park,Lee Expires September 2003 [Page 2] INTERNET-DRAFT March 2003 Now, another problem can be considered in PMTU Discovery [1981]. Due to changes in the routing topology, the PMTU of a path may change over time. In [1981], to detect increases of the PMTU of a path, the source node periodically increases its assumed PMTU although this is done infrequently (10 minutes in general). However, in this method, the assumed PMTU is increased by the source node's link MTU unconditionally. This may also result in several iterations of the discovery cycle. This problem can be also resolved by the proposed method. Therefore, in both discovering PMTU and detecting PMTU's increases, the proposed method can eliminate the chance of occurrence of several iterations of the somewhat complex discovery cycle. Thus, the proposed method in this document can be helpful for the best-conditioned network environment because the actual PMTU is measured dynamically for changes in the routing topology. Finally, existing PMTU [1981] mechanism makes possible some denial-of- service attacks, most of all, both are based on a malicious party sending false Packet Too Big messages to a victim. Accordingly both weak points, it will result in suboptimal performance and availability of denial-of-service attacks. This document suggests the secure PMTU method. It is described in section 7. 2. Terminology o PMTU is the minimum link MTU of all the links in a path between a source node and a destination node. o MTU is stands for Maximum Transmission Unit. i.e., maximum packet size in octets, that can be conveyed in one piece over a link. o Detection Timer Nodes may send PMTU packet at infrequent intervals in order to detect an increase. The recommended setting for this timer is same value as [1981]. (10 minutes) o Response Timer If the source node does not receive the packet with Response MAP Option until the Response Timer expires, the source node initially assumes that the PMTU of a path is the MTU of the first hop in the path as [1981]. o MAP is stands for Measuring Actual PMTU. In order to perform MAP, newly MAP Option must be done. o Discoverying PMTU When node is beginning, node should perform PMTU to discovery its own value. Park,Lee Expires September 2003 [Page 3] INTERNET-DRAFT March 2003 o Detecting PMTU's Increase Nodes may detect increases in PMTU. o Request MAP Option is used to request MAP information to destination. See section 3.1 o Response MAP Option is used to response MAP information to source. See section 3.2 3. Proposed Method : Overview This section gives a brief overview of the new method for the discoverying and detecting PMTU mechanisms. A router on routing path examines only IP header, Hop-by-Hop Option header and routing header in extension header. Other extension headers and data are examined only by a source node and destination node. In the new method, Hop-by-Hop Option header is used to measure increases in a path's PMTU The Hop-by-Hop Option header and Option is defined as below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Currently, Hop-by-Hop Option headers are Pad1, PadN, Jumbo Payload, and Router Alert Options. This document defines a new Option. It is called 'Measuring Actual PMTU (MAP Option)'. Then, the IP packet including Hop-by-Hop Option header with MAP Option has the following format. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + Park,Lee Expires September 2003 [Page 4] INTERNET-DRAFT March 2003 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | 0 | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Data(PMTU) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 8-bit identifier of the type of Option. Opt Data Len 8-bit unsigned integer. Length of the Option Data field of this Option, in octets. Option Data(PMTU) Measured PMTU value with 4 bytes
The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken when the router does not recognize the Option Type. The third highest order bit of the Option Type specifies whether or not the Option Data (PMTU) of that Option can change en-route to the packet's final destination. The other five bits are defined arbitrarily. The MAP Option has two Option Types. The one is Request MAP Option and the other is Response MAP Option, which will be shown in following subsections. If any of the routers en-route cannot recognize the Option Types, it skips over or discards the packet silently. It depends on operator policy. o The highest-order two bits of the Option type is 00 If routers are not understand MAP Options, this packet must be skipped over this Option and continue processing the header. When this Option meets with possible router, this PMTU must be modified. When source node receives this response, it is not actual PMTU because all routers are not understand. If received MTU is larger than its own value, this MTU should be ignored. Note : In initiation case, node must use "00" value because of response error message (Packet Too Big message). o The highest-order two bits of the Option type is 01 If routers are not understand MAP Options, this packet must be discarded, at this case, source node has its waiting time. When this time is expired without any response, this node should perform original PMTU as [1981]. Park,Lee Expires September 2003 [Page 5] INTERNET-DRAFT March 2003 This document suggests that if specific link should be performed with small PMTU value, at this point, MAP Options should be applied. 3.1 Request MAP Option Format The Request MAP Option format is defined to measure real PMTU as shown in Figure 3. The source node sends the IP packet with this Request MAP Option format to the destination node. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 x 1|1 0 0 0 0|0 0 0 0 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P M T U | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Highest-order two bits 00 - Skip over this Option and continue processing the header 01 - discard the packet The third-highest-order bit 1 - Option Data may change en-route Option Type - 112 (temporary value) Option Length - 4 PMTU - 4 Octets
3.2 Response MAP Option Format The Response MAP Option format is defined to response measured real PMTU as shown in Figure 3. The destination node sends the IP packet with this Response MAP Option format to the source node. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 x 0|1 1 0 0 0|0 0 0 0 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P M T U | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Highest-order two bits 00 - Skip over this Option and continue processing the header 01 - discard the packet The third-highest-order bit 0 - Option Data does not change en-route Park,Lee Expires September 2003 [Page 6] INTERNET-DRAFT March 2003 Option Type - 88 (temporary value) Option Length - 4 PMTU - 4 Octets
3.3 Discoverying PMTU with MAP Options The source node sends IP packet with Request MAP Option to the destination node when node is beginning to communicate. Initial MTU value should be its link MTU of the source node. After node receives Response MAP Option with PMTU, the subsequent packets will be sent of course using obtained PMTU. If the first packet with the IPv6 minimum link MTU don't go through the next-hop, its node must not reduce its estimate of the PMTU below the IPv6 minimum link MTU. At this case, node may receive a Packet Too Big message reporting a next-hop MTU that is less than IPv6 minimum link MTU. Then, node must include a Fragment header in those packets. This packet should be composed of the following headers: IPv6 Header Hop-by-Hop Options with Request/Response MAP Option Fragment ... While the packet is passing through nodes en-route, the following action occurs. - Compare PMTU in Request MAP Option and Link MTU of next hop. - Store the smaller value between them on PMTU field of the packet. By doing the same action on routers en-route, PMTU field of the IP packet with Request MAP Option is updated to have minimum PMTU. This is the actual PMTU value. The destination node that receives the IP packet returns back this value to the source node using Response MAP Option. The source node that receives the actual PMTU value determines the transmission length of a packet. However, if all routers don't recognize MAP Options, responsed MTU is not actual PMTU. 3.4 Detecting PMTU with MAP Options As described on Path MTU Discovery [1981], a source node sends IP packet with Request MAP Option to a destination node before the Detection Timer expires so that it wants to increase PMTU value. Default MTU value is link MTU of the source node. This packet should be composed of the following headers: IPv6 Header Hop-by-Hop Options with Request/Response MAP Option Park,Lee Expires September 2003 [Page 7] INTERNET-DRAFT March 2003 While the packet is passing through nodes en-route, the actions are the same as section 3.3 By doing the same action on routers en-route, PMTU field of the IP packet with Response MAP Option is updated to have minimum PMTU. This is the optimal PMTU value. The destination node that receives the IP packet returns back this value to the source node using Response MAP Option. The source node that receives the optimal PMTU value determines the transmission length of a packet. This method can reduce the number of ICMP-Packet Too Big Error message, otherwise happens more frequently. This also reduce waste of network resource. 4. Node Requirements for Discoverying PMTU 4.1 Source Node and Destination Node When the IPv6 source node has a large amount of packets to send to the destination node, the source node sends the IP packet with Request MAP Option to the destination when node is beginning. The PMTU field of Request MAP Option of the packet initialized by the value of its link MTU of the source node. If router does not understand the MAP Options, the packet is skipped over this Option and continue processing the header (See section 3.). When node receives the Packet Too Big message this node should be performed existing PMTU as [1981]. Whenever the destination node receives the IP packet with Request MAP Option, it must response the IP packet with Response MAP Option immediately. By the Option Type, this packet cannot be modified by routers on routing path. 4.2 Nodes on Routing Path Nodes on a routing path are routers. When the IP packet with Request MAP Option arrives on these routers, they compare the PMTU in Request MAP Option and link MTU of the next hop. They select a smaller value between them and forward the packet with a PMTU value. After doing the same procedure, the final destination node comes to know minimum PMTU. If the IP packet with Response MAP Option arrives on theses routers, they forward the packet without any modification. If routers can not recognize two MAP Options, it skips over this Option and continue processing the header since the first two bits of the MAP Option is 00. (See section 3.). 4.3 Operation Procedure When the IPv6 source node sends to the destination node, the source node sends the IP packet with Request MAP Option and its link MTU of the source node to a destination. In this case, the Option Type in Request MAP Option is 112 (temporary value). While the packet is Park,Lee Expires September 2003 [Page 8] INTERNET-DRAFT March 2003 en-route, intermediate routers compare the PMTU in Request MAP Option and link MTU of the next hop. They select a smaller value between them, store the value to PMTU field of Request MAP Option and forward the packet with the updated PMTU. PMTU of the packet arrived at the destination node becomes minimum PMTU. The destination node sends the IP packet Response MAP Option to inform the source node. In this case, the Option Type in Request MAP Option is 88 (temporary value). After then, the source node sends packets using new PMTU. If routers implements only previous PMTU Discovery [1981] on routing path, in this case the router can skip over this Option and continue processing the header. If node receives the Packet Too Big message, the source node should be performed existing PMTU as [1981]. If node receives Response MAP Option, the source node must compare with its own MTU value. The source node selects a smaller value between them and store. Therefore, in discovering PMTU, the proposed method can eliminate the chance of occurrence of several iterations of the discovery cycle. 5. Node Requirements for Detecting PMTU 5.1 Source Node and Destination Node A source node does not change the PMTU value for some amount of time after it comes to know PMTU based on PMTU Discovery [1981]. When the source node wants to increase PMTU by the Detection Timer, it sends the IP packet with MAP Options to a destination. The PMTU field of MAP Options of the packet contains the value of link MTU of the source node and the data. Whenever a destination node receives the IP packet with Request MAP Option, it must response the IP packet with Response MAP Option immediately. By the Option Type, this packet cannot be modified by routers on routing path. Also, it can use both type "00" and "01". It depends on operator policy. In order to use type "01", source node must have its timer, Response Timer. 5.2 Nodes on Routing Path This processing is same as section 4.2 5.3 Operation Procedure When the source node wants to increase PMTU by the Detection Timer, it sends the IP packet with Request MAP Option to a destination. In this case, the Option Type in Request MAP Option is 112 (temporary value). While the packet is en-route, intermediate routers compare the PMTU in MAP Option and link MTU of the next hop. They select a smaller value between them, store the value to PMTU field of MAP Option and forward the packet with the updated PMTU. PMTU of the packet arrived at the destination node becomes minimum PMTU. The destination node sends the IP packet Response MAP Option to inform the source node. In Park,Lee Expires September 2003 [Page 9] INTERNET-DRAFT March 2003 this case, the Option Type in Response MAP Option is 88 (temporary value). After then, the source node sends packets using new PMTU.if routers implements only previous PMTU Discovery [1981] on routing path, in this case the router can silently discard the packet without response error message by the highest-order two bits, 01, in Option Type field or skip over this Option and continue processing the header with MAP Options by the highest-order two bits, 00, in Option Type field. If the source node does not receive the IP packet with Response MAP Option until the Response Timer expires, the source node initially assumes that the PMTU of a path is the MTU of the first hop in the path as [1981]. 6. Comparison with [1981] This section should be discussed more detail. o In order to perform PMTU, [1981] uses ICMPv6, but MAP uses only basic IPv6 protocol and extension header with newly Option. We assure that it should be implemented very easy in host and router as well. o In the aspect of implementation, all IPv6 nodes, including both hosts and routers, must implement newly Options as defined in this specification. o As described in [1981], MAP should consider all implementation issues. 7. Security Considerations As we knew, existing PMTU [1981] mechanism makes possible two denial -of-service attacks, most of all, both are based on a malicious party sending false Packet Too Big messages to a victim. Accordingly both weak points, it will result in suboptimal performance and availability of denial-of-service attacks. MAP mechanism is not likely to do denial-of-service attacks. However when malicious node sends false MAP response with its correct type, there are still simpler denial-of-service attacks available. This document considers the protection method from various attacks. In order to avoid spoofing or attacking with incorrect response, MAP mechanisms can use the 64-bit Nonce field. Its value in a MAP Option is always copied from the corresponding Request MAP by the responder. This method is an Optional, therefore the usage of this method depends on operator. However this document recommends this method is implemented with MAP Options for the secure PMTU. Park,Lee Expires September 2003 [Page 10] INTERNET-DRAFT March 2003 +... + | Original IPv6 Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | 1 |MAP Option Typ |0 0 0 0 1 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Nonce | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Data(PMTU) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Nonce should be a random or good pseudo-random value to foil spoofed replied. An implementation which allows multiple independent processes to send MAP Option may use the Nonce value to deliver MAP Option to the correct process. Nonetheless, such processes must check the received Nonce and ignore extraneous response. 8. Normative Reference [1981] J. McCann, S. Deering, J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. 9. Informative References [2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)", RFC 2460, December 1998. [2463] A. conta, S. Deering, "Internet Control message Protocol (ICMP) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. 9. Acknowledgements The authors would like to thank Robert Hinden for his careful reviews of this draft. 10. Authors' Addresses Soohong Daniel Park SAMSUNG Electronics Digital Media R&D Center Tel : +82-31-200-3728 Fax : +82-31-200-3147 E-mail : soohong.park@samsung.com Park,Lee Expires September 2003 [Page 11] INTERNET-DRAFT March 2003 Hakgoo Lee SAMSUNG Electronics Digital Media R&D Center Tel : +82-31-200-9309 Fax : +82-31-200-3147 E-mail : solited@samsung.co.kr 11. Intellectual Property The following notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 12. Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the applicable copyright for this document. Copyright (C) The Internet Society July 12, 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Park,Lee Expires September 2003 [Page 12] INTERNET-DRAFT March 2003 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Park,Lee Expires September 2003 [Page 13]