Network Working Group K. Chowdhury Internet-Draft Starent Networks Expires: August 29, 2006 A. Patel Cisco Systems February 25, 2006 Home Info Discovery for Mobile IPv6 via ICMPv6 Router Advertisement draft-chowdhury-mip6-homeinfo-ra-00.txt Status of this Memo 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 August 29, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract For Mobile IPv6 service, the mobile node first connects to an Access Router and obtain an IPv6 address to use it as a Care-of-Address. In many networks, the Access Router sends Router Advertisement to the mobile node to convey various information. If the Access Router has the knowledge of the mobile nodes home info such as home agent address, the Access Router can convey that info to the mobile node along with the Router Advertisement. This document proposes a method Chowdhury & Patel Expires August 29, 2006 [Page 1] Internet-Draft February 2006 that will allow the Access Router to include home info of the mobile node in the Router Advertisement message. Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. The ICMPv6 Options for Home Info . . . . . . . . . . . . . . . 5 4.1 IPv6 Home Link Prefix Option . . . . . . . . . . . . . . . 5 4.2 Home Agent IPv6 Address Option . . . . . . . . . . . . . . 6 5. Node Requirements . . . . . . . . . . . . . . . . . . . . . . 7 5.1 Mobile Node Requirements . . . . . . . . . . . . . . . . . 7 5.2 Access Router/NAS Requirements . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Chowdhury & Patel Expires August 29, 2006 [Page 2] Internet-Draft February 2006 1. Introduction and Scope Mobile IPv6 service [RFC3775] requires the Mobile Node to acquire a Care-of Address (CoA) from the Access Router (AR) on the link where it is currently attached. Moreover, the MN needs to have knowledge of certain home network information such as address of the Home Agent and the related Home Link Prefix (for Home Address auto- configuration) prior to sending a Binding Update to register with the Home Agent. As part of the network attachment procedure in the current point of attachment, the AR sends Router Advertisement (RA) (solicited or un- solicited) to the MN to assist it in auto configuration of CoA an to convey information about other link specific parameters [RFC2461], [RFC2462]. It is possible that the AR has knowledge of the MN's home network info at the time of sending the RA to the MN. Consider the case when the NAS and the AR are collocated and the NAS received the home network info such as HL prefix and the Home Agent address for the MN from the Home AAA as part of the authentication and authorization phase during layer 2 establishment. There may also be cases, where the AR has the knowledge of the MN's home info via provisioning or via other out of band methods. Nevertheless, if the AR have the home network info for the MN it can pass it to the MN via the RA that it sends to the MN. This certainly speeds up the network connection setup process. This document defines the ICMPv6 options that will carry such info in the RA. The home info identified in the document are HL prefix and Home Agent address. The defined format of the option is generic enough to carry other information if needed in the future. 2. 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 [RFC2119]. 3. Solution Overview When the link between the MN and AR becomes enabled i.e. the bearer path is open, the AR sends a Router Advertisement (RA) message to the MN. The RA message is defined in [RFC2461]. If the AR already has the MN's HL prefix and/or Home Agent address (either via pre- configuration or retrieved earlier during AAA exchange for the link establishment), it MUST include the same in corresponding options (described in section 4) in the Router Advertisement message. Chowdhury & Patel Expires August 29, 2006 [Page 3] Internet-Draft February 2006 MN AR/NAS HAAA | | | (1) |-----Initiate layer 2----->| | | connection | | | | | | (2)|---Layer 2 Auth Request--->| | | | | (3)|<----Layer 2 Auth Reply----| | | (Send HL prefix | | | and/or HA address) | | | | (4) |<-----Complete layer 2-----| | | connection | | | | | (5) |----Router Solicitation--->| | | (Optional) | | | | | (6) |<------Unicast Router------| | | Advertisement | | | (With the new | | | HL prefix and/or | | | HA address option) | | | | | Figure 1. Message flow for the proposed method with HAAA assist Description of the steps: 1. The MN and the NAS begins L2 setup. As part of the L2 authentication and authorization process, either PPP LCP or EAP over foo (where foo is specific link technology or PANA) is initiated. 2. The NAS exchanges AAA messages with the Home AAA (HAAA) to authenticate and authorize the MN. 3. The NAS receives successful authentication indication from the HAAA. As part of the authorization data, the HAAA sends HL prefix and/or Home Agent information to the NAS. 4. The NAS and the MN completes L2 establishment. 5. At this step, the MN MAY send a Router Solicitation message to begin L3 configuration process. However, this step is entirely optional as the AR is not always waiting for the MN to send this trigger to send an RA. Chowdhury & Patel Expires August 29, 2006 [Page 4] Internet-Draft February 2006 6. The AR sends a Router Advertisement to the MN. In this RA, the AR includes the HL prefix info and/or the Home Agent address info in the newly defined ICMPv6 options in this document. The AR and the NAS are collocated in this solution. The AR identifies the proper context in the NAS to extract home info by using the user ID that is associated with the corresponding L2 connection over which the RA is sent. 4. The ICMPv6 Options for Home Info The following ICMPv6 options are proposed to carry the home info. At this time two home info options are defined to carry HL prefix info and Home Agent info respectively. 4.1 IPv6 Home Link Prefix Option The IPv6 HL prefix info is sent via this option in the RA. The format of the option is as follows: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + . . . IPv6 Address prefix of the Home-Link . . . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type A 8-bit field indicating the type of the option. To be assigned by IANA. Code 0 (Zero). Chowdhury & Patel Expires August 29, 2006 [Page 5] Internet-Draft February 2006 Checksum The ICMPv6 checksum. IPv6 Address prefix of the Home-Link The IPv6 prefix of the Home-Link assigned to the MN. The MN MAY auto-configure and Home Address (HoA) using this prefix. 4.2 Home Agent IPv6 Address Option The Home Agent IPv6 Address info is sent via this option in the RA. The format of the option is as follows: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + . . . IPv6 Home Agent Address (128-bits) . . . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type A 8-bit field indicating the type of the option. To be assigned by IANA. Code 0 (Zero). Checksum The ICMPv6 checksum. IPv6 Address prefix of the Home-Link The IPv6 Address of the Home Agent that is assigned to the MN. Chowdhury & Patel Expires August 29, 2006 [Page 6] Internet-Draft February 2006 5. Node Requirements TBD. 5.1 Mobile Node Requirements TBD. 5.2 Access Router/NAS Requirements TBD. 6. Security Considerations The MN MUST be able to trust the received RA from the Access Router. This is a basic requirement for establishing connectivity in an IPv6 network. There are no additional security concerns applicable to the solution proposed here. 7. IANA Considerations The following Extension Types MUST be assigned by IANA: IPv6 Home Link Prefix Option Type: TBD-1. Home Agent IPv6 Address Option Type: TBD-2. 8. Acknowledgements TBD. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Chowdhury & Patel Expires August 29, 2006 [Page 7] Internet-Draft February 2006 Authors' Addresses Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US Phone: +1 214-550-1416 Email: kchowdhury@starentnetworks.com Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-853-9580 Email: alpesh@cisco.com Chowdhury & Patel Expires August 29, 2006 [Page 8] Internet-Draft February 2006 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 (2006). 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. Chowdhury & Patel Expires August 29, 2006 [Page 9]