Mobile IPv6 Extensions Group F. Zhao Internet-Draft S. Faccin Expires: January 7, 2009 A. Damle Marvell July 6, 2008 IKEv2 based Mobile Network Prefix Assignment draft-zhao-mext-mnp-ikev2-00 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 January 7, 2009. Zhao, et al. Expires January 7, 2009 [Page 1] Internet-Draft MNP Assigment July 2008 Abstract This document proposes a mechanism for the Mobile Router to dynamically obtain the Mobile Network Prefix through IKEv2. The mechanisms to renew, release and update the allocated Mobile Network Prefixes are also described. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. New Attribute Format . . . . . . . . . . . . . . . . . . . . . 4 4. Mobile Network Prefix Assignment . . . . . . . . . . . . . . . 6 5. Mobile Network Prefix Management . . . . . . . . . . . . . . . 8 5.1. Renewing the Mobile Network Prefix . . . . . . . . . . . . 8 5.2. Releasing the Mobile Network Prefix . . . . . . . . . . . 8 5.3. Updating the Mobile Network Prefix . . . . . . . . . . . . 9 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 10 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Zhao, et al. Expires January 7, 2009 [Page 2] Internet-Draft MNP Assigment July 2008 1. Introduction With the specification of the Network Mobility (NEMO) Basic Support Protocol defined in RFC 3963 [1], a Mobile Router needs to advertise an IPv6 prefix, called the Mobile Network Prefix, on the link associated with the Mobile Network in order for the Mobile Network Nodes to perform IP address configuration and thus obtain IP connectivity. Static configuration of the Mobile Network Prefix on the Mobile Router is inefficient, especially when the Mobile Networks are to be deployed at a large scale. However, the NEMO Basic Support protocol [1] does not specify a dynamic Mobile Network Prefix assignment mechanism for the Mobile Router. Besides the Mobile Network Prefix, the Mobile Router needs its Home Agent address, its Home Address, and the necessary information (such as IPsec security associations) shared with the Home Agent to protect signaling and/or data traffic, when it powers up and uses the NEMO/ DSMIPv6 protocol to obtain network connectivity. The procedure for the Mobile Node to obtain such information is called bootstrapping [2] in the context of Mobile IPv6. Bootstrapping solutions [3] [4] are proposed for both split and integrated scenarios, such as Home Agent discovery via DHCP or DNS and Home Address assignment via IKEv2. In order to reduce complexity and costs of implementation, it is desired that the components of the Mobile IPv6 bootstrapping mechanism are re-used as much as possible for NEMO Mobile Router bootstrapping. In this document, we propose that the Mobile Router obtains the Mobile Network Prefix through IKEv2, i.e. using the same message exchange for the Home Address assignment. In addition, we describe mechanisms to renew, release and update the allocated Mobile Network Prefix. 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 RFC 2119 [5]. Mobility terminology used throughout this document is defined in [6], [7] and [8]. Zhao, et al. Expires January 7, 2009 [Page 3] Internet-Draft MNP Assigment July 2008 3. New Attribute Format We propose a new IKEv2 Configuration Attribute, called MOBILE_NETWORK_PREFIX6. This attribute is carried in the IKEv2 Configuration Payload and is used to convey an IPv6 Mobile Network Prefix between the Mobile Router and the Home Agent. Figure 1 shows the format of the MOBILE_NETWORK_PREFIX6 Configuration Attribute. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Mobile Network Prefix | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | +-+-+-+-+-+-+-+-+ Figure 1: The format of the MOBILE_NETWORK_PREFIX6 attribute Reserved (1 bit) This bit MUST be set to zero and MUST be ignored on receipt. Attribute Type (15 bits) A unique identifier for the MOBILE_NETWORK_PREFIX6 attribute (to be determined by IANA). Length (2 octets) Length in octets of fields, including IPv6 Mobile Network Prefix, Prefix Lifetime and Prefix Length. This can be 0 or 21. Prefix Lifetime (4 octets) The length of time period during which the Mobile Network Prefix remains valid. This should not be longer than the lifetime of the IKE security association used when the Mobile Network Prefix is assigned to the Mobile Router. Zhao, et al. Expires January 7, 2009 [Page 4] Internet-Draft MNP Assigment July 2008 IPv6 Mobile Network Prefix (16 octets) The IPv6 Mobile Network Prefix to be advertised to the Mobile Network. Prefix Length (1 octet) The length in bits of the Mobile Network Prefix specified in the IPv6 Mobile Network Prefix field. When the Mobile Router requests a new Mobile Network Prefix, the Mobile Router includes the MOBILE_NETWORK_PREFIX6 attribute in the CFG_REQUEST payload and the value of the Length field is zero or the IPv6 Mobile Network Prefix field is set as zero. The Mobile Router may indicate the preferred Mobile Network Prefix in this attribute and the Home Agent should return the indicated Mobile Network Prefix, if available. The Mobile Router may explicitly request a lifetime by specifying a value in the Prefix Lifetime field. Such value must not be zero if the Mobile Router specifies a preferred Mobile Network Prefix and is set as 2^32-1 if the Mobile Router wants the assigned Mobile Network Prefix remains valid for the lifetime of the IKEv2 security association. The Mobile Router may request multiple Mobile Network Prefixes by using multiple MOBILE_NETWORK_PREFIX6 attributes in one IKEv2 request message. If such request from the Mobile Router is valid, the Home Agent includes the MOBILE_NETWORK_PREFIX6 attribute in the CFG_REPLY payload and sends it back to the Mobile Router in one IKEv2 response message. The attribute contains the allocated Mobile Network Prefix and the lifetime authorized by the Home Agent. If the Mobile Router requests multiple Mobile Network Prefixes in one IKEv2 request message, the Home Agent should return multiple Mobile Network Prefixes by using multiple MOBILE_NETWORK_PREFIX6 attributes in one IKEv2 response message. There are different mechanisms for the Home Agent to allocate the Mobile Network Prefix. For example, the Home Agent may manage a pool of network prefixes by itself or communicate with a DHCP server located in the home domain for this task. The details of such mechanisms are out of scope of this document. Zhao, et al. Expires January 7, 2009 [Page 5] Internet-Draft MNP Assigment July 2008 4. Mobile Network Prefix Assignment When the Mobile Router powers up, based on its configuration or some mechanisms that are out of scope of this document, the Mobile Router may choose hosted based mobility protocols, such as DSMIPv6/NEMO, to set up network connectivity. Figure 2 shows the steps performed by the Mobile Router during bootstrapping. MR Access network HA | | | | IP address configuration | | |<-------------------------->| | | | | | Home Agent discovery | | |<--------------------> | | | | | | IKE_SA_INIT{...} | |<------------------------------------------------------->| | | | IKE_AUTH{CFG_REQUEST(HoA/HNP, MNP)} | |-------------------------------------------------------->| | | | IKE_AUTH{CFG_REPLY(HoA/HNP, MNP)} | |<--------------------------------------------------------| | | | BU/BA | |<------------------------------------------------------->| | | Figure 2: The procedure of the Mobile Network Prefix assignment via IKEv2 o When attaching to a new link, the Mobile Router configures an IP address on its interface that attaches to this link, for example, by performing IP address stateless configuration using Router Solicitation and Router Advertisement messages. o The Mobile Router discovers the IP address of the Home Agent, for example, by using mechanisms defined in [6] [3] and [4]. o The Mobile Router starts to establish a security association and firstly completes the IKE_SA_INIT exchange with the discovered Home Agent. o During the IKE_AUTH exchange, in addition to a Home Address or Home Network Prefix, the Mobile Router also requests a Mobile Network Prefix from the Home Agent by including the MOBILE_NETWORK_PREFIX6 attribute in the CFG_REQUEST payload. Zhao, et al. Expires January 7, 2009 [Page 6] Internet-Draft MNP Assigment July 2008 o The Home Agent verifies this request based on its policy and configuration. If this request is valid, the Home Agent allocates a Mobile Network Prefix in addition to a Home Address or Home Network Prefix. The information regarding the allocated Mobile Network Prefix, including the lifetime, is carried in the MOBILE_NETWORK_PREFIX6 attribute and sent back to the Mobile Router. The Mobile Router configures the Home Address and the Mobile Network Prefix based on the received CFG_REPLY payload. o If the Mobile Router attaches to its home link (the details of the home link detection mechanism is out of scope of this document), the Mobile Router does not perform binding registration with the Home Agent. Otherwise, the Mobile Router follows the procedure specified in the NEMO Basic Support Protocol [1] to register the binding between its Care-of address and its Home Address and the Mobile Network Prefix with the Home Agent. In addition to an IPSec security association to protect mobility signaling messages, the Mobile Router may negotiate an IPSec child security association with the Home Agent to protect the data traffic from/to itself and the Mobile Network Nodes. Zhao, et al. Expires January 7, 2009 [Page 7] Internet-Draft MNP Assigment July 2008 5. Mobile Network Prefix Management After the Mobile Router obtains the Mobile Network Prefix, in the most common case, the Mobile Network Prefix is used until the current IKEv2 security association expires or is explicitly deleted or re- authenticated, i.e. the Mobile Network Prefix is valid through the lifetime of the IKEv2 security association. In this case, either the Mobile Router or the Home Agent can initiate the procedure to renew, release and update the allocated Mobile Network Prefix by performing operations, such as rekeying or re-establishing the IKEv2 security association as specified in the IKEv2 protocol [9]. On the other hand, with the Informational Exchange already defined in the IKEv2 protocol [9], an allocated Mobile Network Prefix can also be renewed, released and updated while the IKEv2 security association is still valid. Such Informational Exchange is protected by the IKEv2 security association. In the following, we focus on mechanisms for renewing, releasing and updating the Mobile Network Prefix in the second case. 5.1. Renewing the Mobile Network Prefix When the lifetime of the allocated Mobile Network Prefix is about to expire, the Mobile Router needs to extend the lifetime of the Mobile Network Prefix, if it still wants to use the same Mobile Network Prefix. Otherwise, if the Home Agent does not receive any renewal request before expiration, the Home Agent will recycle the expired Mobile Network Prefix for re-allocation later. The renewal procedure is usually initiated by the Mobile Router. To renew a Mobile Network Prefix, the Mobile Router initiates the IKEv2 Informational Exchange with the Home Agent and includes the Mobile Network Prefix to be renewed and a new lifetime in the CFG_REQUEST payload. If such request is valid, the Home Agent sends back the same Mobile Network Prefix with the authorized lifetime in the CFG- REPLY payload to the UE. 5.2. Releasing the Mobile Network Prefix The Mobile Network Prefix release procedure can be initiated by either the Mobile Router or the Home Agent. To release an allocated Mobile Network Prefix, the Mobile Router initiates the IKEv2 Informational Exchange with the Home Agent. In the CFG_REQUEST payload carried in the IKEv2 request message, the Mobile Router includes the Mobile Network Prefix to be released and the lifetime set as zero in the MOBILE_NETWORK_PREFIX6 attribute. As Zhao, et al. Expires January 7, 2009 [Page 8] Internet-Draft MNP Assigment July 2008 a reply, the Home Agent returns a CFG_REPLY payload indicating the released Mobile Network Prefix and the lifetime set as zero. To release an allocated Mobile Network Prefix, the Home Agent can also initiate the IKEv2 Informational Exchange with the Mobile Router. In the IKEv2 Informational Exchange message sent to the Mobile Router, the Home Agent uses the CFG_REQUEST payload to carry the MOBILE_NETWORK_PREFIX6 attribute that indicates the Mobile Network Prefix to be released and the lifetime set as zero. When the Mobile Router receives such IKEv2 request message, it removes the corresponding configuration and replies with a CFG_REPLY payload to carry the MOBILE_NETWORK_PREFIX6 attribute that indicates the released Mobile Network Prefix and the lifetime set as zero. When the Home Agent receives this responses, it recycles the released Mobile Network Prefix. 5.3. Updating the Mobile Network Prefix The Mobile Network Prefix update procedure can be initiated by either the Mobile Router or the Home Agent. One way to perform the Mobile Router initiated Mobile Network Prefix update procedure is that the Home Agent returns a different Mobile Network Prefix when the Mobile Router requests to renew a Mobile Network Prefix. Another way is that the Mobile Router indicates the release of the old Mobile Network Prefix and the request of a new Mobile Network Prefix by using two separate MOBILE_NETWORK_PREFIX6 attributes in one CFG_REQUEST payload. The Home Agent should return a new Mobile Network Prefix and confirm the release of the old Mobile Network Prefix by using two separate MOBILE_NETWORK_PREFIX6 attributes in one CFG_REPLY payload. To perform the Home Agent initiated Prefix update procedure, the Home Agent indicates the release of the old Mobile Network Prefix and the assignment of a new Mobile Network Prefix by using two separate MOBILE_NETWORK_PREFIX6 attributes in one CFG_REQUEST payload. In this case, the Mobile Node should confirm the assignment of the new Mobile Network Prefix and the release of the old Mobile Network Prefix by using two separate MOBILE_NETWORK_PREFIX6 attributes in one CFG_REPLY payload. Zhao, et al. Expires January 7, 2009 [Page 9] Internet-Draft MNP Assigment July 2008 6. Security Consideration This document describes the use of a new IKEv2 Configuration Attribute to assign the Mobile Network Prefix to the Mobile Router. The security issues related to the IKEv2 protocol are discussed in the "Security Considerations" section of the Internet Key Exchange (IKEv2) Protocol [9]. This document does not introduce any additional security considerations related to such IKEv2 message exchange. When the Mobile Router requests a Mobile Network Prefix from the Home Agent during the IKEv2 message exchange, in addition to verifying the identity of the Mobile Router, the Home Agent must also verify whether the Mobile Router is eligible to request a Mobile Network Prefix, based on the Mobile Router's profile and network policies. This is because the policy of the home network operator may not allow the Mobile Router to request the Mobile Network Prefix from a Home Agent located in the certain roaming domain. Such verification can be performed as a part of IKEv2 authentication process, for example, by checking the Mobile Router's profile after authenticating the identity of the Mobile Router and associated credentials using certain authentication protocols (e.g. EAP). The NEMO Basic Support protocol [1] requires that the Home Agent check if a Mobile Network Prefix received in a Binding Update message is authorized to be used. To do so, the Home Agent can associate the mobile node identity used in the IKEv2 authentication process with the Home Network Prefix allocated. In some deployment, the Home Agent itself manages the allocation of Mobile Network Prefixes, for example, from a locally managed prefix pool. It is also possible that additional back-end servers are used for Mobile Network Prefix assignment. For example, the Home Agent can act as a DHCP Requesting Router and interact with a DHCP Delegating Router. The security mechanism protecting the interaction between the Home Agent and such back-end servers could be generic security mechanisms, such as IPSec, or specific to the protocols used in between, such as DHCP authentication option. Once allocated, the Mobile Network Prefix must not be assigned to a different Mobile Router until such Mobile Network Prefix is returned to the Home Agent. 7. IANA Consideration This document defines one new IKEv2 Configuration Attribute Type, MOBILE_NETWORK_PREFIX6. The value of such type is expected to be assigned from the "IKEv2 Configuration Payload Attribute Types" Zhao, et al. Expires January 7, 2009 [Page 10] Internet-Draft MNP Assigment July 2008 namespace [9] by IANA. 8. References [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [2] Patel, A. and G. Giaretta, "Problem Statement for Bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006. [3] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. [4] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft draft-ietf-mip6-bootstrapping-integrated-06, April 2008. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [7] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [8] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. [9] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [10] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. [11] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [12] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007. [13] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. Zhao, et al. Expires January 7, 2009 [Page 11] Internet-Draft MNP Assigment July 2008 [14] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. Authors' Addresses Fan Zhao Marvell Semiconductor, Inc. 5488 Marvell Lane Santa Clara, CA 95054 US Email: fanzhao@marvell.com Stefano Faccin Marvell Semiconductor, Inc. 5488 Marvell Lane Santa Clara, CA 95054 US Email: smfaccin@marvell.com Ameya Damle Marvell Semiconductor, Inc. 5488 Marvell Lane Santa Clara, CA 95054 US Email: adamle@marvell.com Zhao, et al. Expires January 7, 2009 [Page 12] Internet-Draft MNP Assigment July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Zhao, et al. Expires January 7, 2009 [Page 13]