IETF MIPSHOP Working Group Y. Han Internet-Draft SAMSUNG AIT Expires: July 15, 2004 January 15, 2004 A Supplementary Scheme for New Care-of Address Configuration and Confirmation in FMIPv6 draft-han-mipshop-ncoaconf-fmipv6-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 July 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document proposes a new care-of address (NCoA) configuration and confirmation scheme for the Mobile IPv6 fast handover protocol (FMIPv6). The goal of this proposal makes FMIPv6 address configuration and confirmation 'very fast' and its confirmation result 'always successful'. The proposed scheme can become a supplementary function implemented in only nodes which play a role of new access router in FMIPv6. Han Expires July 15, 2004 [Page 1] Internet-Draft A Supplementary Scheme for FMIPv6 January 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5 2.1 Duplication-free Address Generation . . . . . . . . . . . . . 5 2.2 Passive-Proxy for Duplication-free Addresses . . . . . . . . . 5 2.3 NAR operation . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 Normative References . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Han Expires July 15, 2004 [Page 2] Internet-Draft A Supplementary Scheme for FMIPv6 January 2004 1. Introduction FMIPv6 (Fast Handover for Mobile IPv6) [1] describes a protocol to replace MIPv6 (Mobile IPv6) [2] movement detection algorithm and NCoA (New Care-of Address) configuration procedure. Conceptually, the protocol consists of three phases: - FMIPv6 enables an MN (Mobile Node) to detect that it is now moving to a new subnet by providing the new access point identifier and receiving the associated subnet prefix information, if at all possible, when the MN is still connected to its current subnet. The MN may do this after establishing connectivity with PAR, and also do this at any time during its sojourn on its current point of attachment. - The MN also formulates a prospective NCoA, again if at all possible, when still present on current subnet. Furthermore, in order to make the MN allocate the NCoA to its interface immediately after attaching to new subnet, FMIPv6 provides the NCoA confirmation procedure, which is executed before or during MN switches its subnet. - FMIPv6 specifies a tunnel establishment typically between PCoA (Previous CoA) and NCoA so that the MN can continue to receive or send packets while it completes the binding update to HA and CNs on the new subnet. When feasible, this tunnel establishment is done before MN attaches to new subnet. Otherwise, it should be established immediately after MN attaches to new subnet. The scenario in which an MN receives the positive result about the confirmation of its prospective NCoA on the current subnet is called 'predictive' mode of operation. The scenario in which an MN checks the uniqueness of NCoA after MN attaches to new subnet is called 'reactive' mode of operation. Although MN initiates the NCoA confirmation and tunnel establishment at early time on the current subnet, FMIPv6 would fall into the reactive mode if MN could not receive the confirmation result on the current subnet. At this case, MN should (re)send FBU, which is encapsulated in FNA, as soon as it attaches to NAR. This procedure will cause wireless resources to be more used and an additional processing at NAR is required to check whether or not the NCoA is already confirmed (or whether or not the NCoA is already used by other node). In addition to that, if the proposed NCoA is rejected during the NCoA confirmation procedure, MN may configure NCoA by itself (using RFC 2462 DAD algorithm [3]) so that handover latency becomes long. In Han Expires July 15, 2004 [Page 3] Internet-Draft A Supplementary Scheme for FMIPv6 January 2004 order to achieve more reduction of handover latency, it is required that 'predictive' mode occurs more frequently than 'reactive' mode. So, it is so demanded that the NCoA confirmation should be done 'promptly' and its result should be always 'positive'. In this draft, we propose an NCoA configuration and confirmation scheme for FMIPv6. This scheme is an 'add-on' function implemented in NAR (New Access Router). It is not a new IPv6 address configuration scheme, but a supplementary one incorporated with the existing stateless and stateful address configurations. Han Expires July 15, 2004 [Page 4] Internet-Draft A Supplementary Scheme for FMIPv6 January 2004 2. Protocol Description The goal of this proposal makes FMIPv6 address configuration and confirmation 'very fast' and its confirmation result 'always successful'. In this section, we will describe this proposal in detail. The proposal consists of the following three steps: 2.1 Duplication-free Address Generation If AR (Access Router) has an interface connected to a subnet where an MN can move, it must create and manage a 'Duplication-free Address Pool' associated with the interface. AR can randomly generate globally routable addresses as background process. The default random address generation procedure is similar with one described in RFC 3041 [5]. However, a procedure, if any, can be used for the address generation. If stateful address configuration is available in the network, AR can request an address from DHCPv6 server. On generating or obtaining an address, AR must perform RFC 2462 DAD on the address. Only after successful DAD, AR reserves the address into its 'Duplication-free Address Pool'. The number of address generated or obtained initially is at least 'CAPACITY_OF_POOL'. By default, 'CAPACITY_OF_POOL' is 10, but it should be able to be configured. 2.2 Passive-Proxy for Duplication-free Addresses As soon as an address is stored in the pool, AR MUST begin to act as a proxy for the address 'passively'. While AR is serving as Passive-Proxy for an address, it MUST NOT use Proxy Neighbor Discovery (Section 7.2.8 in [4]). So, AR MUST NOT multicast onto its link an unsolicited NA (Neighbor Advertisement) message, to advertise the AR's own link-layer address for the address. This behavior's 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 an NS (Neighbor Solicitation) message with the Target Address field set to one of addresses stored at the pool. Particularly when AR receives such an NS with the purpose of DAD executed from any other node (in this case, the Source Address field in the NS message is set to the unspecified address), it MUST silently delete (thereby, relinquish) the address specified in the Target Address field from its 'Duplication-free Address Pool'. At any time of such deletion, AR SHOULD generate a new address (or obtaining it from DHCPv6 Server) and keep the total number of addresses in the pool being 'CAPACITY_OF_POOL'. By obeying these rules, AR can keep Han Expires July 15, 2004 [Page 5] Internet-Draft A Supplementary Scheme for FMIPv6 January 2004 the reserved addresses unique lastingly until they are allocated into an MN. 2.3 NAR operation Sometime after exchanging RtSolPr (Router Solicitation for Proxy) and PrRtAdv (Proxy Router Advertisement), MN sends FBU (Fast Binding Update) from PAR (Previous Acess Router)'s link. On receiving FBU, PAR sends HI (Handover Initiation) to NAR. PAR may set 'S' bit in HI and thereby request NCoA. Whether or not PAR sets 'S' bit in HI, NAR will assign a duplication-free address. In response to processing the HI message, the NAR 1) select a duplication-free address from its pool and delete it from the pool. 2) create HAck (Handover Acknowledgement) sent to PAR as a reply to HI. At this time, 'Code' field in HAck is set as follows: If 'S' bit in the received HI is unset, 'Code' field is set to '2', which indicates 'Handover Accepted, NCoA in use'. If 'S' bit in the received HI is set, 'Code' field is set to '3', which indicates 'Handover Accepted and NCoA is assigned'. Also, HAck always contains 'New Care-of Address' Option carrying the selected duplication-free address. 3) start 'normal' proxying the address and create a proxy neighbor cache entry defending the address. After completely performing the above procedure, NAR checks if there are other jobs. If such jobs do not remain any more, NAR SHOULD try to generate a new address (or obtain it from DHCPv6 server), run DAD on the address, and reserve it into its pool so that NAR keeps the total number of duplication-free addresses being CAPACITY_OF_POOL. By setting '2' or '3' in the 'Code' field and including a duplication-free address in HAck, this add-on scheme forces MN to always use the address assigned from NAR's 'Duplication-free Address Pool'. Han Expires July 15, 2004 [Page 6] Internet-Draft A Supplementary Scheme for FMIPv6 January 2004 3. Security Considerations The delivery of a duplication-free address are achieved with the exchange of pre-defined handover-related messages of FMIPv6. So, FMIPv6 itself will correctly authenticate the delivery of the address. References [1] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-00 (work in progress), October 2003. [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July 2002. [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. [5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Author's Address 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 9585 EMail: yh21.han@samsung.com Intellectual Property Statement 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 of the 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 Han Expires July 15, 2004 [Page 7] Internet-Draft A Supplementary Scheme for FMIPv6 January 2004 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 implementors 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. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. 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. Han Expires July 15, 2004 [Page 8]