IETF Mobile IP Working Group Y. Han Internet-Draft J. Choi Expires: November, 2003 SAMSUNG AIT S. Park SAMSUNG Electronics June 2003 Advance Duplicate Address Detection draft-han-mobileip-adad-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of 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. This Internet-Draft will expire on October 30, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document proposes to automatically allocate a globally unique care-of IPv6 addresses (CoA) for the use of mobile nodes that want to be fast handovered. Each access router maintains a 'CoA Pool' of which each address is in advance generated and tested for its uniqueness by the access router. Also, the access router acts as 'Passive Proxy' for the stored addresses in order not to affect the destination cache and neighbor cache of its neighbor and not to disturb the normal CoA configuration procedure of the nodes who do not obey this draft. As soon as a mobile node, which obeys this draft, gains connectivity on a new link, it inquires one of CoAs Han, et al. Expires October 30, 2003 [Page 1] Internet-Draft Advance DAD May 2003 stored by its access router. After successfully acquiring the one, the mobile node assigns it on the interface which attaches to the new link, without the normal DAD. Consequently, the proposed scheme can completely take off the DAD procedure/time from L3 handover procedure/latency Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Advance DAD Requirements . . . . . . . . . . . . . . . . . . . 6 3.1 Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Passive Proxy Requirements . . . . . . . . . . . . . . . . . . 6 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 4.1 CoA Generation . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 Passive Proxy for DAD-free NCoAs . . . . . . . . . . . . . . . 7 4.3 DAD-free NCoA Configuration Protocol . . . . . . . . . . . . . 8 5. New ICMPv6 Options Formats . . . . . . . . . . . . . . . . . . 10 5.1 DAD-free NCoA Request option . . . . . . . . . . . . . . . . . 10 5.2 DAD-free NCoA Reply option . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 Han, et al. Expires October 30, 2003 [Page 2] Internet-Draft Advance DAD May 2003 1. Introduction To accommodate a highly increasing demand of mobility in the Internet, Mobile IPv6 (MIPv6) [2] has been proposed in the IETF. In MIPv6, a mobile node (MN) should generate a new care-of address (CoA) using IPv6 stateless address auto-configuration whenever it moves to new link. As described in [3], for testing the new CoA's uniqueness within the new link, it should run "duplicate address detection (DAD)" algorithm before assigning the new CoA to the interface which attaches to the new link. After successful DAD, it registers the new CoA to its home agent (HA) and correspondent nodes (CNs) using binding update (BU) messages. In the current protocol, DAD takes at least 1000ms to detect there is no duplicate address in the link (DupAddrDetectTransmits=1 and RetransTimer=1000ms as default values in [3]). If an MN detects DAD is failed, it may generate a random interface identifier and repeatedly run DAD algorithm using the new link-local address. At most 5 consecutive attempts should be performed to generate such addresses and test them through DAD [2]. Obviously, DAD is a time consuming process, particularly when an MN in need of seamless handover runs it. During DAD time, any active communications of the MN are interrupted, and this is especially unsuitable for real-time communications. Not all IPv6 nodes' interfaces contain IEEE identifiers. In such cases, an interface identifier is generated through a random generation method such as [5], and the resultant interface identifier may be not globally unique. In [7], the author writes that the optimistic DAD is far more likely to succeed than fail for even randomly auto-configured addresses, by a factor of at least 10,000,000,000 to one. However, such optimistic thought becomes valid only when randomly auto-configured addresses are truly random and they are distributed uniformly and globally. In practice, however, generating truly random numbers can be tricky. We can think that two or more nodes use the same seed for random number generation. If the nodes meet in a link, the collision probability may be high. To think another example, let us assume that there is a series of links where a great quantity of IPv6 nodes exists and an optimistic node wanders about within the series of links. If the node generates its CoA randomly whenever moving to one of the series, the probability of address collision may be high, too. Therefore, the optimistic DAD cannot be the unique solution for DAD optimization when we take all situations into account, while we generally accept that it is the one of optimized solutions when an MN uses the IEEE 802 identifiers to generate its interface identifier, or when it assures that the probability of collision is exceedingly low. Han, et al. Expires October 30, 2003 [Page 3] Internet-Draft Advance DAD May 2003 In this draft, we propose a scheme, named 'advance DAD', that completely takes off DAD time from L3 handover latency regardless of the type of MN's Layer 2 identifier. This is achieved by advance configuration of new CoA that will be used without any DAD concerns after the MN moves to a link. To put it concretely, an access router (AR) generates in advance many CoAs at random and tests their uniqueness through the existing DAD procedure. After the DAD procedure succeeds, it put the globally unique CoAs into its CoA Pool. As soon as moving to a AR's link, MN inquires one of CoAs stored by the AR. After successfully acquiring the one, it immediately assigns it on the interface without the normal DAD. For each address in the CoA Pool, AR acts as 'Passive Proxy' in order not to affect the destination cache and neighbor cache of its neighbor and not to disturb the normal CoA configuration procedure of the nodes who do not obey this draft. Our approach is to allow new CoA to be configured "in advance" and to be stored at each AR. This is discriminated from configuring new CoA "expeditiously" in the existing fast handover scheme [6]. The benefits of using the advance CoA configuration and pooling are follows. - An MN can acquire a new CoA quickly without any anticipated scheme. - For the new CoA, an MN can skip a DAD and use it as the IPv6 source address of BU messages - We can completely take off CoA configuration procedure and time from any seamless handover process, thereby simplifying any seamless handover protocols. - If a seamless handover protocol sets up a bi-directional tunnel between the PAR and the NAR (in order to forward packets to and from MN's PCoA), an additional protocol for renewing the tunnel must be supported in preparation for late new CoA configuration. Such support is a bothersome task on designing overall handover protocol, but it is indispensable. If advance DAD is used, we do not have to support the tunnel renewing protocol any more. Han, et al. Expires October 30, 2003 [Page 4] Internet-Draft Advance DAD May 2003 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "silently ignore" in this document are to be interpreted as described in RFC 2119 [1]. The following terminology and abbreviations are used in this document. Previous Access Router (PAR) - The MN's default router prior to its handover. New Access Router (NAR) - The MN's anticipated default router subsequent to its handover. Previous CoA (PCoA) - The MN's Care of Address valid on PAR. New CoA (NCoA) - The MN's Care of Address valid on NAR. DAD-free NCoA - NCoA of which uniqueness is already guaranted. DAD-free NCoA Request Message - Message used by an MN to request an AR to deliver DAD-free NCoA. This message is a Router Solicitation with new DAD-free NCoA Request ICMPv6 option. DAD-free NCoA Reply Message - Message used by an AR to reply to DAD-free NCoA request delivered from an MN. This message is a Router Advertisement with new DAD-free NCoA Reply ICMPv6 option. Han, et al. Expires October 30, 2003 [Page 5] Internet-Draft Advance DAD May 2003 3. Advance DAD Requirements The followings are a minimal set of requirements that advance DAD protocol must meet. 3.1 Basic Requirements - The protocol is required that an MN should be able to receive a DAD-free NCoA from its current AR as soon as it attatchs a link where the AR resides. - The protocol is required to allow an AR to serve as Passive Proxy for the addresses in CoA poll. 3.2 Passive Proxy Requirements - Passive Proxy MUST create a CoA, run DAD on the address, and store the address on behalf of MNs - Passive Proxy MUST NOT make an influence on the change of destination cache and neighbor cache of its neighbors. - If Passive Proxy perceives that a node is tying to create and configure one of the stored DAD-free NCoAs, it MUST abandon the address and configure another one. Han, et al. Expires October 30, 2003 [Page 6] Internet-Draft Advance DAD May 2003 4. Protocol Description The goal of this protocol is to allow MN to obtain a DAD-free NCoA as soon as it establishes connectivity on a new link. This section describes our protocol in detail. 4.1 CoA Generation If an AR has an interface connected to a link where an MN can move to, it MUST manage a 'CoA Pool' assigned to the interface. AR can have several interfaces assigned to different prefixes. In this case, AR MUST manage one 'CoA Pool' for each interface. In addition to the original function of packet forwarding, each AR generates globally unique addresses as background process. The number of address generated initially is at least CAPACITY_OF_POOL per one 'CoA Pool'. By default, CAPACITY_OF_POOL is 100, but it SHOULD be configured based on router capacity and expected MNs' solicitation load. The default CoA generation procedure is similar with one described in RFC 3041 [5], except that the generated interface identifier is appended to the prefix(es) managed by AR itself. However, a procedure, if any, can be used for the address generation. As specified in RFC 3041, AR MUST perform DAD on the generated address. If DAD indicates the address is already in use, the address MUST NOT be stored into a 'CoA Pool'. If AR has several interfaces assigned to different prefixes, there is little benefit in running DAD on every address. This document recommends that DAD be run on the first address generated from a given randomized identifier, but that DAD be skipped on all subsequent addresses generated from the same randomized interface identifier. After successful DAD, AR stores the address into the managed 'CoA Pool' and regards the stored address as the 'DAD-free NCoA'. AR SHOULD try to generate new CoA so that the number of addresses stored in 'CoA Pool' is up to CAPACITY_OF_POOL. 4.2 Passive Proxy for DAD-free NCoAs As soon as a 'DAD-free NCoA' is stored, AR begins to proxy the address "passively". While an AR is serving as Passive Proxy for a 'DAD-free NCoA', it MUST NOT multicast onto its link an unsolicited Neighbor Advertisement (NA) message with the address. This behavior is the opposite to one of Home Agent. The reason is because AR does not have to intercept packets that are delivered to the address. Moreover, such packets may not be created or delivered from any host until an MN gets and uses it as its NCoA. Also, it MUST NOT reply to a Neighbor Solicitation (NS) message with Han, et al. Expires October 30, 2003 [Page 7] Internet-Draft Advance DAD May 2003 the Target Address field set to one address stored at 'CoA Pool'. Particularly when AR receives an NS for the purpose of DAD performed from any host (in this case, the Source Address field is the unspecified address), it MUST check if the Target Address specified in the message matches one address stored at 'CoA Pool'. If such an address exists in 'CoA Pool', it MUST delete the address from 'CoA Pool'. At any time of such deletion, AR SHOULD try to keep the total number of CoAs in a 'CoA Pool' being CAPACITY_OF_POOL. 4.3 DAD-free NCoA Configuration Protocol DAD-free NCoA Configuration protocol consists of the request protocol and the response protocol. Like some existing handover protocols, the acquisition operation takes advantage of "Layer 2 link up (L2-UP)" trigger. As soon as MN gains connectivity on a new link, it can send Router Solicitation (RS) to the all-Routers multicast address. MN requesting DAD-free NCoA sends RS with DAD-free NCoA Request option. This new option includes the MN's PCoA, the MN's link-layer address, and an identifier. When AR acting as Passive Proxy receives an RS, it validates the message according to rules described in [4]. And, it additionally checks whether there is a DAD-free NCoA Request option or not. If a DAD-free NCoA Request exists, AR regards the message as an RS requesting DAD-free NCoA. Otherwise, it processes it normally. When AR receives an RS requesting DAD-free NCoA, it handles it in the following way: 1) Select a DAD-free NCoA from 'CoA Pool' and delete the address from the pool. AR can use a method to select a DAD-free NCoA from 'CoA Pool' (e.g., using FIFO). 2) Create a neighbor cache entry using the selected DAD-free NCoA and the MN's link-layer address. The MN's link-layer address is retrieved from the DAD-free NCoA Request option. 3) Set state of the neighbor cache entry to STALE. 4) Create a host route entry using the MN's PCoA and the MN's link-layer address, which are retrieved from the DAD-free NCoA Request option. 5) Create a Router Advertisement (RA) with DAD-free NCoA Reply option. DAD-free NCoA Reply option includes the selected DAD-free NCoA. And, the value assigned to Identifier field of this option MUST be copied from DAD-free NCoA Request option. Han, et al. Expires October 30, 2003 [Page 8] Internet-Draft Advance DAD May 2003 6) Using the created host route entry, send the RA directly to the MN's PCoA. 7) Immediately delete the host route entry used to send the RA. After completely performing the above procedure, AR SHOULD check If there are other DAD-free NCoA requests delivered from MNs. If there is no DAD-free NCoA request, AR SHOULD try to promptly generate new addresses, run DAD on the addresses (in parallel), and store them into a 'CoA Pool' in order to keep the total number of CoAs in a 'CoA Pool' being CAPACITY_OF_POOL. As soon as the MN receives an RA with DAD-free NCoA Reply option, it configures the address specified in the option as its NCoA and SHOULD multicast a Neighbor Advertisement message onto its link. This message updates its neighbor's cache entries with the MN's link-layer address. It should be noted that MN does not have to multicast a Neighbor Solicitation for normal DAD. Also, MN can immediately send Binding Updates including the DAD-free NCoA to HA and CNs. Because MN sends RS to the all-Routers multicast address when it request a DAD-free NCoA from AR, it can receive normal RA from an AR which does not act as Passive Proxy. If MN receives normal RA before receiving RA including DAD-free NCoA Reply option, it itself configures NCoA, and starts to run the normal DAD. If it receives RA including DAD-free NCoA Reply option while the normal DAD goes on, however, it ignores the normal DAD process afterward. Han, et al. Expires October 30, 2003 [Page 9] Internet-Draft Advance DAD May 2003 5. New ICMPv6 Options Formats 5.1 DAD-free NCoA Request option DAD-free NCoA Request option is a new ICMPv6 option that MUST be included in RS messages, if the sending node wants to request DAD- free NCoA from an AR. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + PCoA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN's Link-Layer Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA. Length size of this option units of 8 octets. Identifier An identifier to aid in matching DAD-free NCoA Reply option to DAD-free NCoA Request option. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. PCoA The MN's Care of Address valid on PAR. PCoA is reused while the MN is attached to NAR until it finishes NCoA setup. MN's Link-Layer Address Han, et al. Expires October 30, 2003 [Page 10] Internet-Draft Advance DAD May 2003 The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. 5.2 DAD-free NCoA Reply option DAD-free NCoA Reply option is a new ICMPv6 option that MUST be included in RA messages, if the sending AR receives a valid RS with DAD-free NCoA Request option, and there is a corresponding Proxy Cache entry. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DAD-free NCoA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA. Length size of this option units of 8 octets (i.e., 3). Identifier MUST be copied from DAD-free NCoA Request option. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. DAD-free NCoA New Care of Address can be used by MN without normal DAD. Han, et al. Expires October 30, 2003 [Page 11] Internet-Draft Advance DAD May 2003 6. Security Considerations If someone wants to hijack correct DAD-free NCoA Request/Reply message, they could send an RS message with incorrect DAD-free Request option to the AR repeatedly and AR would send an RA message through above mechanism, which is a unsafe processing. As described in [4], a mobile node can check validity of ND messages. If the ND message includes an IP Authentication Header, the message authenticates correctly. There may be a security issue with the creation of the host route entry by the AR upon reception of the DAD-free NCoA Request option. It could be used to deny service to a legitimate host which is off-link (or be a man-in-the-middle), if the host route entry is valid for more than just sending RA with DAD-free NCoA Reply option. Therefore, AR MUST create the entry only when it processes the DAD-free NCoA Request option and use it for the reply packet, and then delete it immediately. Implementations SHOULD apply a rate-limiting method to send DAD-free NCoA Request/Reply message to avoid being used in a Denial-of-Service attack. Security issues regarding the Neighbor Discovery protocol are discussed in [4] and in IETF send (Securing Neighbor Discovery) working group. Han, et al. Expires October 30, 2003 [Page 12] Internet-Draft Advance DAD May 2003 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-22 (work in progress), May 2003. [3] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [5] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [6] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mobileip-fast-mipv6-06 (work in progress), March 2003. [7] Moore, N., "Optimistic Duplicate Address Detection", draft-moore-ipv6-optimistic-dad-02 (work in progress), February 2003. Authors' Addresses Youn-Hee Han SAMSUNG Advanced Institute of Technology i-Networking Laboratory San 14-1, Nongseo-ri, Giheung-eup Yongin-si, Gyeonggi-do 449-712 KOREA Phone: +82 31 280 9233 EMail: yh21.han@samsung.com URI: http://myhome.personaldb.net/bluebibi JinHyeock Choi SAMSUNG Advanced Institute of Technology i-Networking Laboratory San 14-1, Nongseo-ri, Giheung-eup Yongin-si, Gyeonggi-do 449-712 KOREA Phone: +82 31 280 9233 EMail: jinchoe@samsung.com Han, et al. Expires October 30, 2003 [Page 13] Internet-Draft Advance DAD May 2003 Soohong Daniel Park SAMSUNG Electronics Mobile Platform Laboratory 314, Maetan3-dong, Paltal-Ku Suwon-si, Gyeonggi-do 449-743 KOREA Phone: +82 31 200 3728 EMail: soohong.park@samsung.com Acknowledgement Greg Daley and Nick Moore provided valuable feedback and contributed to this draft. Implementation experience have been provided by HeeJin Jang. Other useful comments were received from Xiaoming Wang and Byoung-Jun Lee. Han, et al. Expires October 30, 2003 [Page 16]