Mobile IPv6 Working Group Kuntal Chowdhury INTERNET DRAFT Mohamed Khalil April 2004 Haseeb Akhtar Nortel Networks Home Subnet Prefix or the Home Agent discovery for Mobile IPv6 draft-chowdhury-mipv6-home-prefix-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. Abstract This document proposes a method that would allow the dynamic discovery of the HAs (Home Agents)in the Mobile IPv6 while eliminating the need for the static provisioning of the MN (Mobile Node) with its home link prefixes of the home subnet. Chowdhury et. al Expires August, 2004 [Page 1] Internet-Draft Home Link Prefix, HA discovery for MIPv6 April 2004 Table of Contents 1.0 Introduction....................................................2 2.0 Terminology.....................................................2 3.0 Basic Operarion ................................................3 4.0 New Router Advertisement Options ...............................5 4.1 Home Link Prefix Option.........................................5 4.2 Home Agent Address Option.......................................5 5.0 MN Considerations...............................................6 6.0 Security Considerations.........................................6 7.0 IANA Considerations.............................................7 8.0 Intellectual Property Rights....................................7 9.0 Acknowledgements................................................7 10.0 References......................................................7 11.0 Contact Information.............................................8 Full Copyright Statement............................................9 1.0 Introduction The base specification of Mobile IPv6 [1] allows the MN to dynamically discover the HAs in the MN's Home link. This, however, requires static provisioning of the prefix of the home subnet in the MN. This approach has two drawbacks. a. It creates administrative burden for the network operator. This also requires out-of-band ways to update the MN with the updated home-link prefix information in case of network re-configuration. b. This prevents the opportunistic and local assignment of HAs otherwise available in the network, especially in the case of roaming. Even though the HA services are available in the local (foreign) network or in the immediate vicinity of the local access network, the MN has to register with the statically provisioned home link that may be thousands of miles away. This draft proposes a method that would allow the dynamic dicovery of the HAs that eases the burden of statically provisioning the MS with its home prefix of the home subnet. 2.0 Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Chowdhury et. al Expires August, 2004 [Page 2] Internet-Draft Home Link Prefix, HA discovery for MIPv6 April 2004 3.0 Basic Operation The dynamic HA address discovery mechanism may be initiated by exchanging the ICMP Home Agent Address Discovery Request and ICMP Home Agent Address Discovery Reply messages between the MN and the HA's anycast address as described in [1] and [2]. However, an AR (Access Router) as defined in [3] may not always be in the home network. The AR, however, can retieve the MN's home link prefixes and/or the HA addresses ahead of time. The AR may be provisioned to store the home link prefixes and/or the HA addresses in its own database. The AR may also query the HAAA (Home Autnetication, Authorization and Accounting) server to receive the list of home link prefixes and/or the list of HA addresses. When the interface between the MN and AR becomes enabled, the MN may decide to send a Router Solicitation message as detailed in [4]. The MN must include the the NAI option as described in [5] with the Router Solicitation message. When the interface between the MN and AR becomes enabled, the the AR may send the Router Advertisement message to the MN as detailed in [4]. If the AR already has the MN's home link prefixes and/or HA addresses (either pre-configured or retrieved earlier during the layer 2 establishment), it must include the Home Link Prefix and/or Home Agent Address options (as described in section 4.0) to the Router Advertisement message. The AR must send any Router Advertisement that has the MN's home link prefixes and/or HA addresses options as an unicast message. Chowdhury et. al Expires August, 2004 [Page 3] Internet-Draft Home Link Prefix, HA discovery for MIPv6 April 2004 Figure 1 below illustrates an example of this process. MN AR HAAA | | | (1) |-----Initiate layer 2----->| | | connection | | | | | | (2)|---Layer 2 Auth Request--->| | | | | (3)|<----Layer 2 Auth Reply----| | | (Send home link | | | prefixes and/or HA | | | addresses) | | | | (4) |<-----Complete layer 2-----| | | connection | | | | | (5) |----Router Solicitation--->| | | (With the NAI option) | | | | | (6) |<------Unicast Router------| | | Advsertisement | | | (With the new home | | | link prefixes | | | and/or HA address | | | options) | | | | | Figure 1: Message Flow for Home Link and/or HA Address Discovery (1) The MN initiates a layer 2 communication with the AR. The details of this interface is beyond the scope of this draft. (2) The AR may send an authentication request to the HAAA server to authenticate the MN. The details of this interface is beyond the scope of this draft. (3) The HAAA server authenticates the MN and returns a successful reply to the AR. The HAAA may send the MN's home link prefixes and/or HA addresses in the same message. The details of this interface is beyond the scope of this draft. (4) The AR completes the layer 2 connection. The interface between the MN and the AR is now enabled. The details of this interface is beyond the scope of this draft. (5) The MN sends a Router Solicitation message to the AR as detailed in [4]. The MN includes the NAI option [5] with the Router Solicitation message. Sending Router Solicitation message, however, is optional. Chowdhury et. al Expires August, 2004 [Page 4] Internet-Draft Home Link Prefix, HA discovery for MIPv6 April 2004 (6) The AR sends an unicast Router Advertisement with the Home Link Prfix and/or HA address options to the MN. 4.0 New Options for ICMPv6 Router Advertisement Message The following new options are required to be included in the ICMP Router Advertisement Message so that the AR can convey the home link prefixes and/or HA addresses to the MN. 4.1 Home Link Prefix Option Home Link prefix Option contains the assigned IPv6 prefixes of the home link of the MN. When advertising more than one home link prefixes, they are attached in the order of preference. 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + . . . List of IPv6 Address prefix of the Home-Links . . . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8-bit identifier of the option type to be defined by IANA. Code 0 (Zero) Checksum The ICMP checksum List of IPv6 Address prefix of the Home Links The IPv6 prefixes of the Home-Link listed in the order of preference 4.2 Home Agent Addess Option Home Agent Address Option contains the assigned Home Agents for the MN. When advertising more than one HAs, they are listed in the order of preference. Chowdhury et. al Expires August, 2004 [Page 5] Internet-Draft Home Link Prefix, HA discovery for MIPv6 April 2004 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + . . . List of IPv6 Addresses of the Home Agents . . . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8-bit identifier of the option type to be defined by IANA. Code 0 (Zero) Checksum The ICMP checksum List of IPv6 Addresses of the Home Agents The IPv6 addresses of the Home Agents listed in the order of preference 5.0 MN Considerations The MN should be configured to send the Router Solitication message with the NAI option (as described in [5]) for either of the following cases. (a) If the AR did not perform any authentication while establishing the layer 2 connection (i.e., while enabling the MN to AR interface). (b) If the MN is not configured with the home link prefix of the home network. 6.0 Security Considerations There must be a security association between the MN and the HAAA server so that the HAAA can authenticate the MN as it attempts to establish a layer 2 connection with the AR. Chowdhury et. al Expires August, 2004 [Page 6] Internet-Draft Home Link Prefix, HA discovery for MIPv6 April 2004 7.0 IANA Considerations The option types defined are new options. IANA should record a value for these new options. 8.0 Intellectual Property Rights 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 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. 9.0 Acknowledgements 10.0 References [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), June 2003. [2] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999. [3] Koodli, Rajeev, "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-01.txt (work in progress), January 2004. [4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Chowdhury et. al Expires August, 2004 [Page 7] Internet-Draft Home Link Prefix, HA discovery for MIPv6 April 2004 [5] Patel, et al., "Network Access Identifier Option for Mobile IPv6", draft-patel-mipv6-nai-option-01.txt, (work in progress), February 2004. 11.0 Contact Information Questions and comments about this draft should be directed at the Mobile IPv6 working group: mip6@ietf.org Questions and comments about this draft may also be directed to the authors: Kuntal Chowdury Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: chowdury@nortelnetworks.com Phone: +1 972-685-7788 Mohamed Khalil Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: mkhalil@nortelnetworks.com Phone: +1 972-685-0574 Haseeb Akhtar Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: haseebak@nortelnetworks.com Phone: +1 972-684-4732 Chowdhury et. al Expires August, 2004 [Page 8] Internet-Draft Home Link Prefix, HA discovery for MIPv6 April 2004 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 assigns. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Chowdhury et. al Expires August, 2004 [Page 9]