IETF Mobile IP Working Group Y. Han Internet-Draft J. Choi Expires: December 4, 2003 H. Jang SAMSUNG AIT S. Park SAMSUNG Electronics July 2003 Advance Duplicate Address Detection draft-han-mobileip-adad-01.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 December 4, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document proposes to automatically allocate a care-of IPv6 addresses (CoA) for the use of mobile nodes that want to be fast handovered. Each access router maintains 'Passive Proxy Cache' 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 an address reserved in 'Passive Proxy Cache' in order not to affect the destination cache and neighbor cache of its neighbor nodes and not to disturb the normal CoA configuration procedure of the nodes which do not obey this draft. During L3 Han, et al. Expires December 4, 2003 [Page 1] Internet-Draft Advance DAD July 2003 handover, a mobile node, which obeys this draft, requests one of the duplication-free addresses reserved by its target access router. After successfully acquiring the address, the mobile node assigns it on its interface which attaches to the new link, without the RFC 2461 DAD. Consequently, the proposed scheme can completely take off the DAD procedure and hence the time involved in the exsting L3 handover schemes 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 Duplication-free NCoAs . . . . . . . . . . . 7 4.3 MN Operation for Duplication-free NCoA Configuration . . . . . 8 4.4 NAR Operation for Duplication-free NCoA Configuration . . . . 8 5. New ICMPv6 Options Formats . . . . . . . . . . . . . . . . . . 11 5.1 Duplication-free NCoA Request Option . . . . . . . . . . . . . 11 5.2 Duplication-free NCoA Reply option . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 Normative References . . . . . . . . . . . . . . . . . . . . . 14 Informative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 Han, et al. Expires December 4, 2003 [Page 2] Internet-Draft Advance DAD July 2003 1. Introduction To accommodate the increasing demand of mobility in the Internet, Mobile IPv6 (MIPv6) [2] has been proposed in the IETF. According to the proposal, 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], to verify the uniqueness of this CoA, it should run "duplicate address detection (DAD)" algorithm (in this draft, hereinafter, DAD refers to the normal DAD as described in [3]) before assigning the address to its 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 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 MN in need of seamless handover runs it. During DAD time, any active communications of MN are interrupted, and this is especially unsuitable for real-time communications. In this draft, we propose a scheme, named 'advance DAD', that completely takes off DAD procedure/time from L3 handover procedure/ latency. This is achieved by advance configuration of new CoA, which will be used without any concern about address collision after MN moves to new link. To put it precisely, an access router (AR) generates randomly many addresses in advance and tests their uniqueness through the existing DAD procedure (these are performed as background process). After successfully passing the DAD procedure, it puts the addresses into 'Passive Proxy Cache'. For each address stored in the cache, AR acts as 'Passive Proxy' in order not to affect the destination cache and neighbor cache of its neighbor nodes and not to disturb the RFC 2461 CoA configuration procedure of the nodes who do not obey this draft. Addresses stored in the cache are duplication-free. From MN's viewpoint, such duplication-free address configuration procedures can be divided into 'predictive' and 'non-predictive'. In the 'predictive' case, MN can get a duplication-free address from new target AR (via current AR) before it moves to the target AR's link. This can be achieved with the help of handover-related messages (exchanged between MN and current AR, and between current AR and target AR) defined in the existing handover schemes (e.g., FBU/FBACK, and HI/HACK in [5]). In the 'non-predictive' case, MN does not engage Han, et al. Expires December 4, 2003 [Page 3] Internet-Draft Advance DAD July 2003 in such message exchange before it moves to new AR's link. In this case, MN gets a duplication-free address from new target AR, immediately after getting connectivity with this AR. After successfully acquiring the address, MN immediately assigns it to its interface without DAD procedure. Our approach is to allow duplication-free addresses to be configured "in advance" at each AR as against [5] in which an address is configured during handover procedure. The benefits of this scheme are follows. - It completely eliminates CoA configuration procedure and hence the time involved in any seamless handover schemes. - Address collision is completely eliminated provided there is no packet loss. - If an anticipation is available (in 'predictive' case) and MN sends a prediction message with new CoA request to NAR via PAR, NAR can immediately reply to the message with new duplication-free CoA, without any confirmation procedure (e.g., DAD). - In the absence of anticipation (in 'non-predictive' case), MN can acquire new duplication-free CoA from new AR. - As the address received by MN from new AR is duplication-free, it can use this address as the source address of any messages without DAD procedure immediately after it gets connectivity with new AR. - If a handover protocol sets up a tunnel between the PAR and the NAR (in order to forward packets to MN connected to NAR), 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 December 4, 2003 [Page 4] Internet-Draft Advance DAD July 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. Duplication-free NCoA - NCoA of which uniqueness is already guaranteed. Duplication-free NCoA Request Option - ICMPv6 Option used by an MN to request a duplication-free NCoA from NAR. Duplication-free NCoA Reply Option - ICMPv6 Option used by an NAR to deliver a duplication-free NCoA to MN. Han, et al. Expires December 4, 2003 [Page 5] Internet-Draft Advance DAD July 2003 3. Advance DAD Requirements Following subsections list the minimum set of requirements for advance DAD protocol. 3.1 Basic Requirements - MN SHOULD be able to request and receive a duplication-free NCoA from new AR before it moves to the new AR's link in 'predictive' case, or as soon as it attaches to the new AR's link in 'non-predictive' case. - AR SHOULD act as Passive Proxy for each of the duplication-free addresses that it has reserved. 3.2 Passive Proxy Requirements - Passive Proxy MUST randomly create CoAs, run DAD on the addresses. - Passive Proxy MUST reserve the addresses after performing DAD on them. - Passive Proxy MUST NOT influence any change of destination cache and neighbor cache of its neighbor nodes. - If Passive Proxy perceives that a node is trying to create and configure one of addresses reserved by it, then it MUST abandon that address and configure another one. Han, et al. Expires December 4, 2003 [Page 6] Internet-Draft Advance DAD July 2003 4. Protocol Description This section describes our protocol in detail. 4.1 CoA Generation If AR has an interface connected to a link where an MN can move, it MUST manage a 'Passive Proxy Cache' associated with the interface. In addition to the original function of packet forwarding, AR generates globally routable addresses as background process. The number of address generated initially is at least CAPACITY_OF_POOL. By default, CAPACITY_OF_POOL is 100, but it SHOULD be configured based on router capacity and expected MNs' solicitation load. The default address generation procedure is similar with one described in RFC 3041 [4], except that the generated interface identifier is appended to the prefix 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 each generated address. If DAD indicates the address is already in use, the address MUST NOT be reserved into 'Passive Proxy Cache'. After successful DAD, AR reserves the address into its 'Passive Proxy Cache' and regards the reserved address as a duplication-free NCoA. AR SHOULD try to generate new CoA so that the number of addresses reserved in 'Passive Proxy Cache' is up to CAPACITY_OF_POOL. 4.2 Passive Proxy for Duplication-free NCoAs As soon as a duplication-free NCoA is stored, AR begins to proxy the address "passively". While AR is serving as Passive Proxy for an address, it MUST NOT multicast onto its link an unsolicited Neighbor Advertisement (NA) message with the address. This behavior is the opposite from Home Agentí¯s behavior. The reason is because AR does not have to intercept packets delivered to the address. Moreover, such packets may not be created or delivered from any node until an MN gets and uses it as its NCoA. Also, it MUST NOT reply to a Neighbor Solicitation (NS) message with the Target Address field set to an address stored at 'Passive Proxy Cache'. Particularly when AR receives an NS for the purpose of DAD executed from any node (note: in this case, the Source Address field is the unspecified address), it MUST check if the Target Address specified in the message matches an address stored at 'Passive Proxy Cache'. If such an address exists in the cache, it MUST delete the address from the cache. At any time of such deletion, AR SHOULD try to keep the total number of addresses in the cache being CAPACITY_OF_POOL. Han, et al. Expires December 4, 2003 [Page 7] Internet-Draft Advance DAD July 2003 4.3 MN Operation for Duplication-free NCoA Configuration This draft does not minutely specify MN operation for the acquisition and the configuration of a duplication-free NCoA. Instead of that, it introduces 'Duplication-free NCoA Request Option' and 'Duplication-free NCoA Reply Option' used for requesting a duplication-free NCoA from NAR, and delivering a duplication-free NCoA to MN, respectively. There are already some fast handover protocols using a set of handover-related messages. For example, [5] has defined RtSolPr/RtSolPr, FBU/FBACK, HI/HACK, FNA/NAACK messages for supporting its handover scheme. These messages can be utilized for including the options defined newly in this draft. From MN's viewpoint, a handover scheme can be divided into 'predictive' and 'non-predictive'. In the 'predictive' case, MN can send 'Duplication-free NCoA Request Option' to NAR (via PAR) before it moves to NAR's link. This option includes current CoA (PCoA in a viewpoint of NAR), MN's link-layer address, an identifier, and 'B' flag. 'B' flag is set when MN demands that NAR should buffer packets tunneled from PAR. If MN can judge that it quickly moves to NAR's link, it MAY not set 'B' flag. When MN receives 'Duplication-free NCoA Reply Option' as a reply, it can resides in PAR's link or NAR's link. If MN resides in NAR's link at that time, it configures the address stored in the reply option into its interface immediately after receiving the reply option. Otherwise, it keeps the address in advance. And, it configures the address into its interface immediately after it gets connectivity with NAR's link. If MN sets 'B' flag when it sends 'Duplication-free NCoA Request Option' to NAR, it MUST notify NAR of its presence with the duplication-free NCoA set to the notification message's source address as soon as it configures the address into its interface (e.g., FNA message used in [5]). If 'B' flag was not set, MN don't have to notify NAR of its presence. In the 'non-predictive' case, MN adds 'Duplication-free NCoA Request Option' to any handover-related message firstly delivered from MN to NAR after it gets connectivity with NAR's link. In that option sent in the 'non-predictive' case, 'B' flag MUST NOT be set. As soon as MN receives 'Duplication-free NCoA Reply Option' as a reply, it configures the address stored in the reply option into its interface. 4.4 NAR Operation for Duplication-free NCoA Configuration When NAR acting as Passive Proxy finds 'Duplication-free NCoA Request Option' in the handover-related message delivered from PAR (in 'predictive' case) or MN (in 'non-predictive' case), it selects an address from 'Passive Proxy Cache' and deletes it from the cache. NAR Han, et al. Expires December 4, 2003 [Page 8] Internet-Draft Advance DAD July 2003 can use a method to select an address from the cache (e.g., using FIFO). With the selected address, NAR generates 'Duplication-free NCoA Reply Option'. The reply option's 'Identifier' field MUST be set to the same value as the one in the request option. In case NAR receives the request option from PAR (this can be judged from the kind of message carrying the request option), it sends 'Duplication-free NCoA Reply Option' to PAR and MN at the same time. The reply option sent to PAR is delivered with one of the handover-related messages. In the other hand, the reply option sent to MN is delivered using the host route entry, which can be created with MN's PCoA and MN's link-layer address. These two addresses is included in the request option. After the host route entry is used to send the reply option to MN, it MUST be deleted immediately. When NAR receives the request option from MN, it also tries to send the reply option to MN with the help of one of the handover-related messages. If such a message is not available, NAR MUST create the host route entry and send the reply option to MN. After sending 'Duplication-free NCoA Reply Option' to PAR or MN, NAR checks if 'B' flag is set or not. If 'B' flag is set, NAR performs the following procedure: 1) create a 'proxy neighbor cache' entry with the selected duplication-free NCoA and NAR's link-layer address. 2) intercept and buffer the packets tunneled from PAR until receiving a message notifying MN's presence. 3) change the 'proxy neighbor cache' entry into 'neighbor cache' entry as soon as receiving the message. If the MN's link-layer address is not available from any handover-related messages (including the notification message), NAR gets it from the request option. 4) set the 'neighbor cache' state to REACHABLE. 5) forward any buffered packets to MN. If 'B' flag is not set, NAR performs the following procedure: 1) create a 'neighbor cache' entry with the selected duplication-free NCoA and MN's link-layer address. If the MN's link-layer address is not available from any handover-related messages, NAR gets it from the request option. Han, et al. Expires December 4, 2003 [Page 9] Internet-Draft Advance DAD July 2003 2) set the 'neighbor cache' state to REACHABLE. 3) forward any buffered packets to MN. After completely performing the above procedure, NAR SHOULD check if there are other 'Duplication-free NCoA Request Option's delivered from MNs. If such request options do not remain any more, NAR SHOULD try to promptly generate new addresses, run DAD on the addresses, and reserve them into 'Passive Proxy Cache' so that NAR keeps the total number of duplication-free NCoAs being CAPACITY_OF_POOL. Before receiving 'Duplication-free NCoA Reply Option', MN can receive a normal Router Advertisement (RA) from an AR which does not act as Passive Proxy. At this case, MN itself creates NCoA, and starts to run the DAD procedure. If it receives 'Duplication-free NCoA Reply Option' while the DAD procedure goes on, however, it ignores the DAD process afterward. Han, et al. Expires December 4, 2003 [Page 10] Internet-Draft Advance DAD July 2003 5. New ICMPv6 Options Formats 5.1 Duplication-free NCoA Request Option 'Duplication-free NCoA Request Option' is a new ICMPv6 option sent from MN to request a duplication-free NCoA from NAR. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B| 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 a 'Duplication-free NCoA Reply Option' to a 'Duplication-free NCoA Request Option'. 'B' flag This flag is set when MN demands that NAR should buffer packets tunneled from PAR. If MN sets the flag, it MUST notify NAR of its presence immediately after it gets connectivity with NAR's link 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 Han, et al. Expires December 4, 2003 [Page 11] Internet-Draft Advance DAD July 2003 while the MN is attached to NAR until it finishes NCoA setup. MN's Link-Layer Address 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 Duplication-free NCoA Reply option 'Duplication-free NCoA Reply Option' is a new ICMPv6 option sent from NAR to deliver a duplication-free NCoA to MN. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Duplication-free NCoA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA. Length size of this option units of 8 octets (i.e., 3). Identifier MUST be copied from 'Duplication-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. Duplication-free NCoA New Care of Address can be used by MN without the DAD procedure. Han, et al. Expires December 4, 2003 [Page 12] Internet-Draft Advance DAD July 2003 6. Security Considerations If someone wants to hijack correct 'Duplication-free NCoA Request/ Reply Options', they could send an handover-related message with incorrect 'Duplication-free NCoA Request Option' to NAR repeatedly, and NAR would reply to the request message, which is a unsafe processing. If there is any authentication schemes in the handover protocol which has defined the handover-related messages carrying the options, the schemes will correctly authenticates the options, too. There may be a security issue with the host route entry created by the NAR upon reception of 'Duplication-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 'Duplication-free NCoA Reply Option'. Therefore, AR MUST create the entry only when it processes the request option and use it for the reply packet, and then delete it immediately. Implementations SHOULD apply a rate-limiting method to send the reqeust/reply options to avoid being used in a Denial-of-Service attack. Han, et al. Expires December 4, 2003 [Page 13] Internet-Draft Advance DAD July 2003 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 2003. [3] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [4] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. Han, et al. Expires December 4, 2003 [Page 14] Internet-Draft Advance DAD July 2003 Informative References [5] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mobileip-fast-mipv6-06 (work in progress), March 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 Hee-Jin Jang 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 9615 EMail: heejin.jang@samsung.com Han, et al. Expires December 4, 2003 [Page 15] Internet-Draft Advance DAD July 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 Hee-Jin Jang, Doo-Jin Cha, and Sueng-Ho Lee. Other useful comments were received from Singh Shubhranshu, Xiaoming Wang and Byoung-Jun Lee. Han, et al. Expires December 4, 2003 [Page 16]