DNA Working Group R. Koodli Internet-Draft Nokia Research Center Expires: January 9, 2006 S. Madanapalli Samsung ISO July 8, 2005 FMIPv6 Usage with DNA Protocol draft-koodli-dna-fmip-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 9, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In this document, we describe how the Fast Mobile IPv6 Handovers (FMIPv6) protocol can work where DNA protocol support is available, but the neighborhood information, which is part of the FMIPv6 operation, is not available. Koodli & Madanapalli Expires January 9, 2006 [Page 1] Internet-Draft FMIPv6 Usage with DNA Protocol July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. FMIPv6 Operating Modes . . . . . . . . . . . . . . . . . . . . 3 3. FMIPv6 with DNA . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 7 Koodli & Madanapalli Expires January 9, 2006 [Page 2] Internet-Draft FMIPv6 Usage with DNA Protocol July 2005 1. Introduction The Fast Handovers for Mobile IPv6 [1] defines a protocol to reduce delay and packet loss from IP protocol operations during a handover between cells or points of attachment. These protocol operations include movement detection, IP configuration and location update with a distant mobility agent such as a Home Agent. The FMIPv6 protocol is designed to effectively eliminate the delays due to movement detection and IP configuration latencies, while disengaging the location update latency from the time-critical path so that applications such as Voice over IP are provided real-time mobility support. The Detecting Network Attachment (DNA) WG is designing protocols to quickly detect link changes and enable establishment of IP connectivity as soon as a mobile node is attached to a new subnet. Compared to existing IPv6 router discovery mechanisms, DNA protocols provide faster and reliable mechanisms for determining the link identity and router discovery on the new subnet. DNA routers send augmented Router Advertisement information which uniquely identifies a link. These RAs are sent without delay providing rapid notification of link change. A host implementing DNA mechanisms determines the subnet change and configures new care of address significantly faster than non-DNA (unmodified) hosts on networks with DNA support, if post arrival link change detection is required. The purpose of this document is to illustrate how the FMIPv6 protocol could make use of the DNA protocol to retain the desired handover performance in certain circumstances. In order to do that, some background on the two operating modes of the FMIPv6 protocol is necessary. 2. FMIPv6 Operating Modes The FMIPv6 protocol can effectively eliminate the movement detection and IP configuration latencies when knowledge of the neighborhood access points and their subnet affiliation is available. For instance, a Mobile Node can query its access router to provide the subnet prefix, IP address and MAC address of a target router attached to a neighboring access point. With this information, it builds a neighborhood map of Access Point Identifier to Access Router Information. So, a conceptual neighborhood data structure consists of [AP-ID, AR-Info] tuples, with each AR-Info structure consisting of a router's IP address, MAC address and subnet prefix corresponding to the interface to which the Access Point is attached to. Such a neighborhood data structure serves two purposes: First, it allows a MN to map an association to a new radio connection to subnet information immediately, which allows it to bypass router discovery. Koodli & Madanapalli Expires January 9, 2006 [Page 3] Internet-Draft FMIPv6 Usage with DNA Protocol July 2005 Second, it allows a MN to use a new IP address on the new subnet link immediately, which allows it to send data packets immediately. There are two modes of operation assuming neighborhood information. In the "predictive mode", a MN is able to effect a local route update before departing from its current link. That is, a MN updates its access router's route table to forward packets to the new IP address before the MN departs the current link. In the "reactive" mode, the MN effects such a route update after it regains radio connectivity on the new link. In both the cases, the latencies due to movement detection and IP configuration are eliminated. In some cases however, neighborhood information may not be available. We discuss this in the following section. 3. FMIPv6 with DNA There are scenarios where DNA protocol operation could be beneficial for FMIPv6. For instance, an access network may not be able to provide neighborhood information for whatever reasons, or a MN may end up on an unanticipated Access Point for which it has no neighborhood information available. In another scenario, the neighborhood information maintained could be marked as stale using some measure. Under these scenarios, if DNA protocol is available, it can expedite FMIPv6 handover. When a MN with no neighborhood information regains link connectivity, it performs DNA movement detection to check if it has changed IP subnet. DNA performs router discovery, and in the process learns new subnet prefixes and router addresses. Subsequently, it runs address configuration, and uses Optimistic DAD [2], and sends the FMIPv6 Fast Binding Update (FBU) message to its previous access router (PAR). This special-case of reactive handover is expected to be faster than having to perform these operations in the absence of DNA protocol enhancements. 4. Protocol Operation The following are the steps that take place when an MN with no neighborhood information attaches to an AP. 1. MN (re)associates with an Access Point (AP) and gets the AP-ID (BSSID) 2. The MN searches for the [AP-ID, AR info] Tuple in its neighborhood data structure corresponding to the AP-ID of the Access Point it just (re)associated. If [AP-ID AR info] is available, MN proceeds with the rest of the FMIPv6 protocol. If the tuple info is not available, it invokes the DNA protocol (see below). Koodli & Madanapalli Expires January 9, 2006 [Page 4] Internet-Draft FMIPv6 Usage with DNA Protocol July 2005 3. The MN sends a Router Solicitation with DNA options (if any) to determine if there is a subnet change and to acquire new prefixes on the subnet. 4. The MN receives a DNA Router Advertisement, determines change in subnet, configures new care of address and makes the address optimistic [2]. 5. The MN sends a Fast Binding Update (FBU) to the Previous Access Router (PAR) directly without being encapsulated in FNA. 6. The PAR should send a Handover Initiate (HI) message to the New Access Router (NAR). 7. The NAR should send a Handover Acknowledge (HAck) message to the PAR. 8. The PAR sends a Fast Binding Acknowledgement (FBack) message to the MN on the new link. 9. The PAR starts tunneling the packets to the MN's new CoA. 5. IANA Considerations There are no IANA considerations introduced by this draft. 6. Security Considerations This draft is informational. Nevertheless, the security considerations of the FMIPv6 protocol and the DNA protocol must be taken into account. For instance, the FBU message mentioned above needs to be protected using a security association between the MN and the PAR. Similar considerations apply for the DNA protocols which may be able to take advantage of SEND for Router Discovery, if available [3]. 7. Acknowledgements The authors would like to thank Greg Daley for his initiative, and suggestions to improve this draft. 8. References [1] Koodli, R., "Fast Handovers for Mobile IPv6, draft-ietf-mipshop-fast-mipv6-03.txt (work in progress)", October 2004. [2] Moore, N., "Optimistic Duplicate Address Detection for IPv6, draft-ietf-ipv6-optimistic-dad-05.txt (work in progress)", February 2005. [3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. Koodli & Madanapalli Expires January 9, 2006 [Page 5] Internet-Draft FMIPv6 Usage with DNA Protocol July 2005 Authors' Addresses Rajeev Koodli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Phone: +1 650 625 2359 Email: Rajeev.Koodli@nokia.com Syam Madanapalli Samsung ISO No. 3/1 Millers Road Bangalore-560 052, India Phone: +91 80 51197777 Email: syam@samsung.com Koodli & Madanapalli Expires January 9, 2006 [Page 6] Internet-Draft FMIPv6 Usage with DNA Protocol July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Koodli & Madanapalli Expires January 9, 2006 [Page 7]