Netlmm Working Group D. Oulai Internet-Draft S. Krishnan Intended status: Standards Track Ericsson Expires: July 16, 2009 January 12, 2009 Multiple Home Network Prefixes Considerations in Handover involving Network and Client Based IP Mobility Protocols draft-oulai-netlmm-mip-interaction-multiple-hnp-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 16, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Oulai & Krishnan Expires July 16, 2009 [Page 1] Internet-Draft Multiple HNPs considerations in handover January 2009 Abstract Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) are the base protocols defined by IETF for network based and client based mobility. This document analyzes PMIPv6 and two MIPv6 extensions, DSMIP and NEMO, with regard to multiple Home Network Prefixes handling during handover. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Interaction between PMIP and client based protocols . . . . . 6 4.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. PMIP-DSMIP . . . . . . . . . . . . . . . . . . . . . . 6 4.1.2. PMIP-NEMO . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. PMIP-DSMIP . . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. PMIP-NEMO . . . . . . . . . . . . . . . . . . . . . . 7 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Oulai & Krishnan Expires July 16, 2009 [Page 2] Internet-Draft Multiple HNPs considerations in handover January 2009 1. Introduction MIPv6 is the IETF standard for client-based mobility [RFC3775] and PMIPv6 is an extension of MIPv6 developed to offer network-based mobility [RFC5213]. Those two protocols will be deployed on a wide scale. On the other hand, DSMIP [I-D.ietf-mext-nemo-v4traversal] and NEMO [RFC3963] are two major variants of MIPv6 used to support IPv4 mobility and mobile routers (MR). Therefore, standardizing interactions between those protocols becomes mandatory. Three scenarios have been presented in [I-D.ietf-netlmm-mip-interactions]. * Scenario A: Two distinct PMIPv6 domains inside a single MIPv6 domain. * Scenario B: A single domain where PMIPv6 and MIPv6 are supported. * Scenario C: A collocated LMA/HA serving distinct PMIPv6 and MIPv6 domain. In this document, the ability to manage the mobility of a MN with more than one assigned HNPs for a mobility session is considered. This allows reducing the Binding Cache size, the signaling load and the security processing in some ways. PMIP allows multiple HNPs for a single mobility session while MIPv6 does not. MIPv6 [RFC3775] works with only one v6 HoA by MIPv6 session. Therefore, we will not consider MIPv6 as managing multiples HNPs results on multiple MIPv6 sessions. DSMIP [I-D.ietf-mext-nemo-v4traversal] has the same limitations as MIPv6 except that a MN can have several v4 HoAs from different prefixes. On the contrary, NEMO [RFC3963] supports multiple prefixes assignment. Having multiple HNPs is interesting for example in the case where, through a single LMA, a MN is connected to several service providers which assign prefixes to the MN. In this situation, the mobility is managed through a single mobility session. This features is also interesting for Mobile Routers (MR). Here we consider DSMIP and NEMO as they are MIPv6 extensions that support multiple HNPs assignment in different ways. Moreover, PMIP is the only network based IP mobility protocol. Therefore, in this document we describe handover between PMIP and client based IP Mobility protocols (DSMIP and NEMO). Oulai & Krishnan Expires July 16, 2009 [Page 3] Internet-Draft Multiple HNPs considerations in handover January 2009 2. Conventions used in this document 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 [RFC2119]. Oulai & Krishnan Expires July 16, 2009 [Page 4] Internet-Draft Multiple HNPs considerations in handover January 2009 3. Terminology All the general mobility-related terms used in this document are to be interpreted as defined in the Mobile IPv6 [RFC3775], Proxy Mobile IPv6 [RFC5213], NEMO [RFC3963] and DSMIP [I-D.ietf-mext-nemo-v4traversal] base specifications. Oulai & Krishnan Expires July 16, 2009 [Page 5] Internet-Draft Multiple HNPs considerations in handover January 2009 4. Interaction between PMIP and client based protocols We now describe the interaction between PMIP, DSMIP and NEMO protocols. First, note that we will not address scenario B mentioned in [I-D.ietf-netlmm-mip-interactions] as it does not involve any handover. Home Addresses in a PMIP domain are referred as P-HoA and Home Addresses in the other protocol are simply labeled HoA. 4.1. Scenario A In this scenario, PMIP is used for local mobility and the other protocols for global mobility. We consider the case where Multiple HNPs are assigned in the PMIP domain. 4.1.1. PMIP-DSMIP Here, the MN can locally obtain several HNPs and forms P-HoAs based on these HNPs. To register more than one P-HoA as CoAs with the DSMIP HA, the MN must use Multiple CoA [I-D.ietf-monami6-multiplecoa] specification (MCoA). After a handover in a new PMIP domain, the MN can configure different P-HoAs and register them with the DSMIPv6 HA. Note that some extensions to MCoA protocol are required to register v4 P-HoA as CoA. 4.1.2. PMIP-NEMO The same operations described in Section 4.1.1 apply here and the MCoA specification can be modify to handle the assignment of a Mobile Network Prefix (MNP) toward a specific CoA. 4.2. Scenario C In this scenario, the LMA and the HA are collocated. Let's also mentioned that there is no prefix sharing between MNs as stated in [I-D.ietf-netlmm-mip-interactions]. Moreover, when in the PMIP domain, it is recommended to create the SA for the DSMIP or NEMO session in order to reduce the handover delay. 4.2.1. PMIP-DSMIP 4.2.1.1. Handover PMIP-DSMIP We consider that the MN is assigned several HNPs in the PMIP domain. Based on [I-D.ietf-mext-nemo-v4traversal] and [RFC5213] specifications, the MN MUST choose one HNP and register it in the DSMIPv6 domain, loosing connectivity through the other HNPs. We suggest to label one HNP as the primary one in the PMIP domain. This primary HNP will likely be chosen in for registration in the DSMIP Oulai & Krishnan Expires July 16, 2009 [Page 6] Internet-Draft Multiple HNPs considerations in handover January 2009 domain. The MN can also create one DSMIPv6 session for each assigned HNP, which is not optimal. As the whole prefix is reserved for a MN, a simple extension to DSMIPv6 could be to allow several v6HoAs in the BCE but perform all the signaling and security operations based on a single HoA labeled as the primary HoA. Therefore, allowing multiple HoAs is equivalent to allowing multiple HNPs. The MN is then able to send a single BU and binds all the HNPs to a single CoAs. Modifying DSMIP in this way should be straightforward as DSMIP already allows v6 and v4 HoAs in a single binding and all the signaling and security operations are based on the v6HoA. 4.2.1.2. Handover DSMIP-PMIP Two sub-cases may happen here: 1. The MN runs one or more DSMIPv6 session with one HNP for each session After the handover, the PMIP domain assigns the HNPs used in the DSMIPv6 domain and additional ones if required for a single PMIP session. The HNP used in the MIPv6 domains are labeled as the primary HNPs. The MN MUST maintain the MIPv6 SAs. 2. The MN uses one DSMIPv6 session with several HNPs In this case, the prefix list used in the DSMIPv6 BCE is copied to the PMIP BCE and all the HNPs are assigned to the MNs. The primary HNP in the PMIP domain is also the primary one in the DSMIPv6 domain. The MN MUST maintain the DSMIPv6 SA using the primary v6HoA. 4.2.2. PMIP-NEMO As the LMA and NEMO HA are collocated, the same sets of prefixes advertised as HNPs in the PMIP domain can be used as MNPs in the NEMO domain as those prefixes are reserved. When the MN is in the PMIP domain, the SA with the NEMO HA should be created. 4.2.2.1. Handover PMIP-NEMO As the MN (which became a MR in the NEMO domain) knows which prefixes are advertised in the PMIP domain, after the handover, it inserts all the PMIP HNPs as MNPs in the BU sent to the NEMO HA. A binding is created towards the CoA for all those MNPs. The MR can also follow the implicit mode where the HA will be responsible of retrieving all the HNPs used int he PMIP domain and assigning them to the MN as MNPs. if other means are used to assign the MNPs in the NEMO domain, the MN or the HA should send the HNPs as hints during the signaling. Oulai & Krishnan Expires July 16, 2009 [Page 7] Internet-Draft Multiple HNPs considerations in handover January 2009 4.2.2.2. Handover NEMO-PMIP When the LMA/HA receives the PBU for the MN, it checks the NEMO BCE and assigns all the MNPs as HNPs to the MN. Therefore, the MR can continue serving its MNPs, believing it is on the home network. Oulai & Krishnan Expires July 16, 2009 [Page 8] Internet-Draft Multiple HNPs considerations in handover January 2009 5. Recommendations For scenario A, the best approach is to register all the P-HoAs formed in the PMIP domain as CoAs at the HA. This is performed using MCoA [I-D.ietf-monami6-multiplecoa] specification. For scenario C, the interaction between PMIP and NEMO is the most elegant way of providing multiple HNPs support. However, as NEMO is not expected to be supported by most of the HAs, a slight modification of DSMIPv6 where multiple HNPs (or at least multiple v6HoAs) are supported represents the best alternative. Oulai & Krishnan Expires July 16, 2009 [Page 9] Internet-Draft Multiple HNPs considerations in handover January 2009 6. Security Considerations The issue brought here resides in the SA for the signaling message as there are several HNPs and it is not scalable to have one SA for each HoA or HNP. The MN in scenario C MUST be able to create the SA based on one primary HoA. When receiving a signaling packet, the LMA/HA MUST be able to identify the primary HoA or HNP in order to locate the right SA for the host. Oulai & Krishnan Expires July 16, 2009 [Page 10] Internet-Draft Multiple HNPs considerations in handover January 2009 7. IANA Considerations TBD Oulai & Krishnan Expires July 16, 2009 [Page 11] Internet-Draft Multiple HNPs considerations in handover January 2009 8. Normative References [I-D.ietf-mext-nemo-v4traversal] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-07 (work in progress), December 2008. [I-D.ietf-monami6-multiplecoa] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-10 (work in progress), November 2008. [I-D.ietf-netlmm-mip-interactions] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-ietf-netlmm-mip-interactions-01 (work in progress), November 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Oulai & Krishnan Expires July 16, 2009 [Page 12] Internet-Draft Multiple HNPs considerations in handover January 2009 Authors' Addresses Desire Oulai Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Email: desire.oulai@ericsson.com Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Email: Suresh.Krishnan@ericsson.com Oulai & Krishnan Expires July 16, 2009 [Page 13]