INTERNET DRAFT Mohamed M. Khalil Category: Standards Track Nortel Networks Title: draft-mkhalil-mipv6-nai-00.txt Haseeb Akhtar Date: October 2003 inCode Telecom Expires: April 2004 Mobile IP Network Access Identifier Extension for IPv6 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 29, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines a way for the mobile node to identify itself, by including the NAI with the MIPv6 Binding Update messages. 1. Introduction This document defines a way for the mobile users to identify themselves, by including the NAI with the MIPv6 Binding Update messages. The proposed mechanism will allow a mobile node to obtain a new Home IP address. This mechanism is useful when the MN (Mobile Node) has established a PPP session while it doesnÆt yet have a home IP Address. It may also be used when the MN is changing its home address, either because of renumbering in its home network or because the MN periodically changes addresses. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWDS]. 2. New Mobility Options The following section defines the following new options. 2.1 MN-NAI Option The MN-NAI Option, contains the user name following the format defined in [1]. When it is present in the Binding Update message the Home Address field of the Home Address Option MAY be set to zero (0). 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 | MN-NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The Mobile-Node NAI Option Type TBD Length The length in bytes of the MN-NAI field MN-NAI A string in the NAI format defined in [1]. 3. Mobile Node Obtaining a Home IP address There are two mechanisms for the MN to obtain a Home IP Address. They are as follows: 3.1 Stateless Address Configuration The MN needs to gather prefix information about its home network to construct a home IP address based on the stateless address configuration as defined in [SLADDR]. The MN can use the Prefix Configuration messages provided by [MIPV6]. Once the MN has obtained the set of home prefix information, it will contruct a stateless address as stated in [SLADDR]. If the MN is away from home, it will not be able to Verify the uniqueness of its home IP address using DAD (Duplicate Address Detection) on the foreign sub-network. In that case, the MN should send a Binding Update and include the Home IP address in the Home IP field of the Home Address Option. The MN-NAI MUST be included in the Binding Update. The Binding Update MUST be authenticated by including the MN-HA authentication option as the last option of Binding Update message. When the HA (Home Agent) receives the Binding Update it will verify the authenticity of the message, and perform DAD on the Home Sub-Network for the home IP address. If the home IP address is unique, a successful Binding Acknowledgment message must be sent to the MN. The HA will then follow the registration steps stated in [MIPv6] to register the MN. Upon receiving a successful Binding Acknowledgment, the MN SHOULD start IKE/IPSec negotiation to establish a IPSec Security Association to be used in the future as stated in [MIPV6]. 3.2 Stateful Address Configuration This process is performed by the MN issuing a request to the HA for a home IP address. The MN will first send a Binding Update with the MN-NAI option. The Binding Update MUST also include the MN-HA Authentication option so that the Binding Update message can be authenticated by the HA. The MN MUST include 0 (zero) in the home IP address field of the home destination option. Upon receiving the Binding Update, the HA will first verify the authenticity of the Binding Update. It will then attempt to allocate a unique IP address to the MN. If the allocation process is successful, the HA will follow the registration steps stated in [MIPv6] to register the MN. Upon receiving a successful Binding Acknowledgment, the MN SHOULD start IKE/IPSec negotiation to establish a IPSec Security Association to be used in the future as stated in [MIPV6]. 4.0 MN Operation The MN can obtain a home IP address with one of the methods described in section 3.0. If the MN acquired a home IP address using the method described in section 3.1, it will construct a Binding Update message with the NAI option. The Home IP field of the Home Address option MUST be set to the newly acquired IP address. If, on the other hand, the MN wants to acquire the home IP address using the method described in section 3.2, it MUST set the home IP address field to 0 (zero). 5.0 HA Operation Upon receiving a Binding Update, the HA MUST verify the authenticity of the Binding Update message. The authentication process is out side the scope of this draft. If and when the HA receives a valid Binding Update with the Home IP address field set to zero and the NAI option included, it will attemnpt to allocate a unique IP address and proceed with registration procedure as stated in [MIPV6]. If the HA receives a Binding Update with the home IP address field set to a nonzero value with the NAI option included, it will verify the uniqueness of the home IP address. If the home IP address is unique, the HA will proceed with the registration procedure as stated in[MIPV6]. If the home IP address is not unique it will return a Binding Acknowledgment with an error status ZZZZ (home IP address not unique). References [KEYWDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MIPV6] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), Dec. 2003. [SLADDR] S. Thomson, T. Narten,ö IPv6 Stateless Address Autoconfigurationö, RFC 2462, December 1998. Acknowledgements The authors would like to thank Jayshree Bharatia and William Gage of Nortel Networks for providing their valuable inputs to this work. Addresses The working group can be contacted via the current chairs: Basavaraj Patil Nokia Corporation 6000 Connection Drive M/S M8-540 Irving, TX 75039 USA Phone: +1 972-894-6709 Fax : +1 972-894-5349 Email: Basavaraj.Patil@nokia.com Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone:+1 408 525 1404 E-Mail: gdommety@cisco.com Questions about this draft can be directed to the authors: Mohamed M Khalil Nortel Networks USA email: mkhalil@nortelnetworks.com Haseeb Akhtar inCode Telecom Group 9645 Scranton Road, Suite 110 San Diego, CA 92121 email:hakhtar@incodewireless.com