NETLMM Working Group Y. Cui Internet Draft Y. Liu Intended status: Standards Track Y. Sun Expires: DEC 2010 Tsinghua University D. Liu H. Deng China Mobile November 23, 2009 Interactions between PMIPv6 and DSMIPv6: a scenario while HA and LMA are separate deployment draft-cui-netlmm-mip-interactions-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 May 23, 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Cui, et al. Expires May 23, 2010 [Page 1] Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009 Abstract Home Agent and Local Mobility Anchor are separately deployed is one scene of the interactions between Proxy Mobile IPv6 (PMIPv6) and Dual stack Mobile IPv6 (DSMIPv6). In view of this scenario this document proposes two detailed solutions for a mobile node which is roaming between PMIPv6 and DSMIPv6. Table of Contents 1. Introduction.....................................................3 2. Requirements Terminology.........................................3 3. Scenario Description.............................................4 4. Solution One - simple interaction................................5 5. Solution Two - complex interaction...............................6 5.1. Extension of Proxy Binding Update...........................6 5.2. Messaging Mechanism for PMIPv6-DSMIPv6 Interactions.........7 5.2.1. Roaming from DSIMPv6 to PMIPv6.........................7 5.2.2. Roaming from PMIPv6 to DSIMPv6.........................9 5.3. Mobility Agent Considerations...............................9 5.3.1. Mobile Node Considerations.............................9 5.3.2. Mobility Access Gateway Considerations.................9 5.3.3. Local Mobile Anchor Considerations.....................9 6. Security Considerations..........................................9 7. IANA Considerations..............................................9 8. References......................................................10 8.1. Normative References.......................................10 8.2. Informative References.....................................10 9. Acknowledgments.................................................10 Author's Addresses.................................................10 Cui, et al. Expires May 23, 2010 [Page 2] Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009 1. Introduction This document proposes two detailed solutions for a mobile node which is roaming between PMIPv6 and DSMIPv6. In this scenario the HA and LMA are separately deployed in different networks. When a mobile node is roaming from DSMIPv6 domain to PMIPv6 domain, in order to ensure the connectivity of MN's communications, the mobile node must re-register to the HA with a new care-of-address. There are two ways to resolve the problem. One way is that when the MN gets the PMIPv6-HoA from the MAG, it re-registers to the HA with the PMIPv6-HoA as a CoA. The other way is that the LMA will register to the HA with one of its own addresses instead of the attached mobile node. This document also defines some option and mechanisms for use in the solutions. These extensions are optional extensions, but they can help to implement the interaction system. 2. Requirements Terminology 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 RFC 2119. The Mobile-IP-related and Proxy-Mobile-IP-related terminology used in this document are described in RFC 3344 [3] and RFC 5213 [2]. The dynamics home agent assignment related terminology used in this document are described in RFC 4433[4]. In addition, the following terms are used: DSMIPV6: dual stack mobile IPv6 DSMIPv6-HoA: the Home Address the MN includes in DSMIPv6 binding update messages PMIPv6-HoA: the Home Address assigned by the LMA, in our scenario PMIPv6-HoA is equal to DSMIPv6-HoA LMAA: the address of LMA Cui, et al. Expires May 23, 2010 [Page 3] Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009 3. Scenario Description There are three scenarios described in [6]. Scenario A is that the Mobile IPv6 Home Agent (HA) and Proxy Mobile IPv6 (LMA) are separate and the whole network is made up of PMIPv6 domains. Scenario B and C is that the HA and LMA are merged as a common mobility anchor, and the difference between the two scenarios is scenario B including only PMIPv6 domain but scenario C with Non-PMIPv6 domain. However, in our opinion, there should be four scenarios base on whether the HA and LMA are separate or merged and whether the Non-PMIPv6 domain is included. So besides the above-mentioned three scenarios, there must be another scenario D which is the HA and LMA is separate and the network is made up of PMIPv6 domain and Non-PMIPv6 domain. We believe scenario D is more reasonable and practical. The MIPv6 should be deployed in the whole network and the PMIPv6 locally deployed. This scenario is easy to deploy and convenient to manage. Because the MAG can't be deployed everywhere, the request in scenario A which the whole network is only made up of PMIPv6 domain is not practical. It requires the whole network should consist of PMIPv6 domain and Non-PMIPv6 domain. So scenario D is reasonable and used as our scenario. The figure 1 illustrates our scenario. In this scenario the HA and LMA are separately deployed, in other words HA and LMA are belongs to different networks. The interaction is similar to HIMIPv6; DSMIPv6 is used as a global mobility management whereas PMIPv6 is used as local mobility management. The Non-PMIPv6 domain is also included in our scenario. When a mobile node is roaming in DSMIPv6 domain, it uses the protocol of the DSMIPv6. The same mechanism is used when the mobile node is roaming only in the PMIPv6 domain. But when the mobile node is roaming from DSMIPv6 domain to PMIPv6 domain, the two solutions described in this document can be used to re-register to the HA. Cui, et al. Expires May 23, 2010 [Page 4] Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009 +----+ | HA | DSMIPv6-HoA -> LMAA +----+ /\ / \ / \ / \ / \ / \ / \ / \ PMIPv6-HoA -> MAG +-----+ +---------+ | LMA | ( ) DSMIPv6 Network +-----+ ( ) || +---------+ +----||-----+ | PMIPv6 Domain ( || ) | ( || ) | +----||-----+ | +-----+ +----+ | MAG | | AR | +-----+ +----+ | | [MN] Figure 1 - Scenario 4. Solution One - simple interaction This solution is much like the one proposed in [6] related to scenario A. The difference between the two solutions is that the Non- PMIPv6 domain is introduce into our scenario. In this simple interaction solution, the mobile node is managed by DSMIPv6 protocol when it is roaming only in the Non-PMIPv6 domain (DSMIPv6 domain) and the same to the PMIPv6 domain. However, when the mobile node is roaming from Non-PMIPv6 domain to PMIPv6 domain or from one PMIPv6 domain to another, the mobile node should re-register to the HA. The re-register process should be performed as the figure for global mobility message flow which is defined in [6]. When the mobile node is roaming from PMIPv6 domain to Non-PMIPv6 domain, the message flow is shown as figure 2. Cui, et al. Expires May 23, 2010 [Page 5] Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009 MN RA HA(DSIMPv6) MAG LMA(PMIPv6) | | | |------1-----> | | | | |<-----2------ | |----3---> | | | | |<---4---- | | | | | | | | | |-----------5----------> | | | |<----------6----------- | | | |<---------------------> | | | Figure 2: Message Flow for MN's roaming from PMIPv6 to Non-PMIPv6 Firstly, as the step 1 and 2 shown, the MAG will discover that the MN has been gone, and it will send a PBU to revoke the binding for MN at the LMA. The LMA will send a PBA to confirm the revocation. The step from 3 to 6 describe the process of the re-register to HA as the MIPv6[5] defines. 5. Solution Two - complex interaction In this complex interaction solution, when a mobile node is roaming from DSMIPv6 domain to PMIPv6 domain using DSMIPv6-HoA, LMA should receive all the packets sent to MN and then forward them to MN via MAG. When the MN attach to the MAG, the registration to HA will be accomplished by the LMA instead of MN, and the care-of-address option includes in the Binding Update will be filled with the LMAA. Then a tunnel between the LMA and HA will be established. All the packets sent to MN will be forwarded through the tunnel. 5.1. Extension of Proxy Binding Update The HA Address Option, shown in Figure 2, contains the address of the HA. This extension is used in PBU to tell LMA who is the MN's HA. It MAY be an optional extension. Cui, et al. Expires May 23, 2010 [Page 6] Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009 0 1 2 30 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The HA Address Option Type specifies the HA address option Length Indicates the length of the extension not including the type, reserved and length fields. HA-Address Address of the HA. 5.2. Messaging Mechanism for PMIPv6-DSMIPv6 Interactions This specification presents the messaging mechanism for MN's roaming from DSMIPv6 domain to the PMIPv6 domain and the opposite direction. 5.2.1. Roaming from DSIMPv6 to PMIPv6 Detailed explanation of the process is best described with the help of a message flow diagram and description. Figure 3 shows the process of a MN roams from DSMIPv6 to PMIPv6. Cui, et al. Expires May 23, 2010 [Page 7] Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009 MN HA(DSIMPv6) MAG LMA(PMIPv6) |------1----->| | | |<-----2------| | | |---------------3------------->| | | | |-------4----->| | | |<------5------| | | |<------------>| | |<---------------6--------------| | |----------------7------------->| | |<----------------------------->| Figure 4: Message Flow for MN's roaming from DSMIPv6 to PMIPv6 1. Firstly the MN sends BU and revokes the binding by setting the lifetime field to 0 and by setting the care-of address equal to the home address 2. The HA receives the binding revocation and knows that the MN has left then HA will delete all the resources related to the MN. 3. The MN entered the PMIPv6 domain and MAY send a Router Solicitation to the MAG if it does not receive any Router Advertisements for certain time. 4. The MAG will send PBU to the LMA for MN while it detects the MN's enter. 5. The LMA will send back a PBA once the PBU is accepted and a bi- directional tunnel between MAG and LMA is also established. 6. At the same time the LMA will send a BU to the HA for MN and register the LMAA as MN's new CoA. 7. The HA will send back BA if the BU is accepted and a bi- directional tunnel will be established between LMA and HA. Cui, et al. Expires May 23, 2010 [Page 8] Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009 5.2.2. Roaming from PMIPv6 to DSIMPv6 The process of a MN roams from PMIPv6 to DSMIPv6 is the same as the figure 2 shown in 3.2. 5.3. Mobility Agent Considerations The following sections describe the behavior of each mobility agent in detail. 5.3.1. Mobile Node Considerations The mobile node does not have any special behavior beyond a dual stack mobile node. 5.3.2. Mobility Access Gateway Considerations The MAG MAY get the HA address of attached MN, the method may be a static way such as reading from a Strategy Document and this is out the scope of this document. The MAG can send the HA address to the LMA used HA Address Option while registering to LMA and LMA can also reject this option. 5.3.3. Local Mobile Anchor Considerations The LMA MUST be able to send binding update to the HA for MN. The MAG may include the HA address option in the proxy binding update while it Registers to the LMA for MN. A valid unicast IPv6 address MUST be used as LMA address in this extension. The LMA will registers to the HA for MN while it accepts the PBU from MAG, so the LMA must be able to generate and send the binding update packet to the HA specified by MAG. 6. Security Considerations This specification assumes that a security configuration has been preconfigured between the LMA and the MAG. The Assigned LMA authenticates each Proxy Binding Update from the MAG. The MAG also authenticates the Proxy Binding Apply from the Assigned LMA. 7. IANA Considerations The HA Address Option is a new defined extension. Cui, et al. Expires May 23, 2010 [Page 9] Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009 8. References 8.1. Normative References [1] H. Soliman, Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009 [2] K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [3] C. Perkins, Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002. [4] M. Kulkarni, A. Patel, K. Leung, "Mobile IPv4 Dynamic Home Agent (HA) Assignment", RFC 4433, March 2006. [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [6] G. Giaretta, Ed., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", Internet Draft, June, 2009. 9. Acknowledgments The authors would like to thank Tianze Ma for discussions on the topic. This document was prepared using 2-Word-v2.0.template.dot. Author's Addresses Yong Cui Tsinghua University Tsinghua University FIT Building 4-104 Beijing 100084 P.R.China Email: cuiyong@tsinghua.edu.cn Cui, et al. Expires May 23, 2010 [Page 10] Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009 Yin Liu Tsinghua University Tsinghua University FIT Building 4-104 Beijing 100084 P.R.China Email: liuyin08@gmail.com Yonghao Sun Tsinghua University Tsinghua University FIT Building 4-103 Beijing 100084 P.R.China Email: yonghaosun@gmail.com Dapeng Liu China Mobile research institute Unit2, 28 Xuanwumenxi Ave,Xuanwu District, Beijing 100053, China Email: liudapeng@chinamobile.com Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui02@gmail.com Cui, et al. Expires May 23, 2010 [Page 11]