NETLMM Working Group Hong-Ke Zhang Internet Draft Zhi-Wei Yan Expires: September 2010 Hua-Chun Zhou Jian-Feng Guan Si-Dong Zhang Beijing Jiaotong University March 4, 2010 Consideration of Network Mobility in PMIPv6 draft-zhang-netlmm-nemo-01.txt Abstract The NetLMM WG is specifying Proxy Mobile IPv6 (PMIPv6) for network- based localized mobility management (NetLMM), taking basic support for registration, de-registration and handover of single Mobile Node (MN) into account in the RFC 5213 [1]. When a whole subnet moves into the PMIPv6 domain through the Mobile Router (MR), the scheme should be considered to provide and maintain the connectivity for the Mobile Network Node (MNN) in the mobile network (NEMO). This document discusses the deployment consideration of NEMO support in PMIPv6 network and proposes the possible solution accordingly. 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 September 4, 2010. Zhang et al. Expires September,2010 [Page 1] Internet-Draft Consideration of NEMO in PMIPv6 March 2010 Copyright Notice Copyright (c) 2010 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction...................................................2 2. Conventions....................................................3 3. Problem statement..............................................3 3.1. Mobility of NEMO..........................................3 3.2. Mobility of nested NEMO...................................4 4. PMIPv6-NEMO....................................................4 4.1. Extensions of LMA and MAG.................................4 4.2. NEMO state table..........................................4 4.2.1. LMA..................................................4 4.2.2. MAG..................................................5 4.2.3. MR...................................................5 4.3. Procedure of PMIPv6-NEMO..................................5 5. Packet transmission............................................6 5.1. Incoming packets..........................................6 5.2. Outgoing packets..........................................7 6. Security Considerations........................................7 7. IANA Considerations............................................7 8. Acknowledgements...............................................7 9. References.....................................................7 Authors' Addresses................................................8 1. Introduction As the extension of basic MIPv6 specification [2], NEMO [3] was proposed to support the network mobility in MIPv6 network. The protocol procedure of MIPv6-NEMO is compatible with basic MIPv6 protocol and the prefix of network is maintained by HA to support the redirection of packets to and from the mobile network. However, the mobility of MIPv6-NEMO is totally managed by the MR as the MN does in basic MIPv6. Be different with MIPv6, the PMIPv6 was proposed to Zhang et al. Expires September,2010 [Page 2] Internet-Draft Consideration of NEMO in PMIPv6 March 2010 support the network-based mobility management. The entities in the PMIPv6 have the responsibility to track the MN, update the location of the MN and redirect the packets to and from the MN. However, the basic PMIPv6 protocol only solves the mobility management for the single MN. In order to deploy the NEMO in the PMIPv6 network, CJ. Bernardos proposes the problems of NEMO support in the PMIPv6 network when using current protocols [4]. This document discusses the deployment consideration of NEMO in PMIPv6 network noted as PMIPv6-NEMO. As a default router of the whole mobile network, a PMIPv6-MR should not only send and receive the packets for MNN, but also manage the mobility of MNN. So we propose the extension of basic PMIPv6 and add the NEMO state table for the entities of the PMIPv6 domain. Then the Local Mobility Anchor (LMA), Mobile Access Gateway (MAG) and MR can maintain the location information of the MNNs in its lower subnet. Because the authentication scheme is used, the mobility of the NEMO is still managed in the network-based manner. 2. Conventions 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 [RFC-2119]. 3. Problem statement At least there are two problems should be considered when deploying NEMO in PMIPv6 network. The first one is the mobility management of the whole mobile subnet, including the MR, Local Fixed Node (LFN) and Visited Mobile Node (VMN). The second one is the nested NEMO supporting. 3.1. Mobility of NEMO In the NEMO, the mobility of three types of nodes MUST be considered: the MR itself, LFN and VMN. For the MR, it should be allocated a particular Home Network Prefix (HNP) as the single MN in the PMIPv6 network and the HNP MUST not changes when the MR moves. For the LFN, its address is configured using the Mobile Network Prefix (MNP) which belongs to a special NEMO. In this case, the LMA MUST not only intercept and redirect the packets for MR, but also intercept and redirect the packets for the LFN belonging to the MNP. For the VMN, it can roam between MR and MR, MR and MAG, MAG and MAG. And then the VMN MUST be assigned a particular HNP and its address is configured using the HNP and does not change during its movement. Zhang et al. Expires September,2010 [Page 3] Internet-Draft Consideration of NEMO in PMIPv6 March 2010 3.2. Mobility of nested NEMO In the nested NEMO scenario, we should consider who manages the mobility of NEMO. When the mobility of NEMO is managed by MR itself, it can follow the procedure in RFC 3963 or P-NEMO [5]. And then the advantages of network-based manner discounts. When the mobility of NEMO is managed by the network, the MR should not involve in any mobility related signaling with MAG or LMA. And then the NEMO support can be manageable, controllable and secure. 4. PMIPv6-NEMO 4.1. Extensions of LMA and MAG In order to manage the bindings of MR and MNN, the LMA and MAG MUST be extended to include the following information: o R flag: indicating whether or not this Binding Cache entry is created for a mobile router or a single node. This flag is set to value 1 for MRs and is set to value 0 for the single nodes. o A list of IPv6 prefixes in the mobile network: these prefixes include the MNP for the location update of LFNs and HNPs for the location update of VMNs. Besides, the MNP is also allocated and managed by the LMA. In thi sway, the MNP related packets can be routed to the LMA. 4.2. NEMO state table Besides, the packets to and from the MNN have to be transmitted through the most optimized route. Then the NEMO state table should be established and maintained by the entries. 4.2.1. LMA The NEMO state table of LMA MUST contain the following information: o MR's HNP: denotes the related MR. o A list of IPv6 prefixes in the mobile network: these prefixes include the MNP for the location update of LFNs and HNPs for the location update of VMNs. o Tunnel index: denotes the related tunnel to arrive at the MAG. And the MR's HNP related MR locates at the MAG subnet currently. Zhang et al. Expires September,2010 [Page 4] Internet-Draft Consideration of NEMO in PMIPv6 March 2010 4.2.2. MAG The NEMO state table of MAG MUST contain the following information: o MR's HNP: denotes the related MR. o A list of IPv6 prefixes in the mobile network: these prefixes include the MNP for the location update of LFNs and HNPs for the location update of VMNs. o Link local address: denotes the next hop to arrive at the MR's HNP related MR. o Tunnel index: denotes the related tunnel to arrive at LMA. 4.2.3. MR The NEMO state table of MR MUST contain the following information: o MR's HNP: denotes the related MR. o A list of IPv6 prefixes in the mobile network: these prefixes include the MNP for the location update of LFNs and HNPs for the location update of VMNs. o Link local address: denotes the next hop to arrive at the MR's HNP related MR. 4.3. Procedure of PMIPv6-NEMO When another MR2 attaches to the MR1 whose connection has been established, the attachment should be discovered by MR1 through the link layer information. When the link layer connection is successfully established, the MR2 sends the Authentication Request(AR) message to the MR1 for the authentication. The following information should be contained in the authentication messages: o R flag: its value is set to 1, indicating that it is a NEMO attachment. o A list of IPv6 prefixes in the mobile network: these prefixes include the MNP for the location update of LFNs and HNPs for the location update of VMNs. Zhang et al. Expires September,2010 [Page 5] Internet-Draft Consideration of NEMO in PMIPv6 March 2010 Then the MR1 redirects the Proxy Authentication Request (PAR) message to the MAG. According to the PMIPv6 protocol, the Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA) are exchanged between MAG and LMA. After this process, the LMA updates its NEMO state table and records the current MAG of MR2 and those VMNs' HNPs. +------+ +-----+ +-----+ +-----+ | MR2 | | MR1 | | MAG | | LMA | +------+ +-----+ +-----+ +-----+ |-- Attach ->| | | |-----AR---->| | | | |----PAR--->| | | | |------PBU--->| | | |<-----PBA----| | |<----PAA---| | |<----AA-----| | | |-----data-->| | | | |----data-->| | | | |====data====>| | | |<====data====| | |<----data--| | |<-----data--| | | Figure 1: Message flow of PMIPv6-NEMO When receiving the PBA message, the MAG also increases the entries of MR2's HNP, MR2's MNP and VMNs' HNPs in its NEMO state table. Then the MAG sends the Proxy Authentication Answer (PAA) message to the MR1 and MR1 records the related information as MAG does. Finally the MR2 receives the Authentication Answer (AA) message and sends the related prefix to the related nodes. Because these MNNs always receive the same related prefixes and their connectivity can be maintained. 5. Packet transmission In the previous example, we assume that an VMN and an LFN are located at the MR2 and communicate with the Corresponding Node(CN) during the movement of MR2. 5.1. Incoming packets For the incoming packets sent from CN to MNN, they are firstly transmitted to the LMA according to the routing protocol. Then the LMA checks the destination addresses and finds that the VMN's HNP and LFN's MNP are binding with the MR2's HNP. So the LMA can send the packets to the MAG through the correct tunnel. When the MAG receives Zhang et al. Expires September,2010 [Page 6] Internet-Draft Consideration of NEMO in PMIPv6 March 2010 the packets, it gets their next hop address and redirects them to the MR1. In the same manner, the MR1 sends the packets to the MR2 and MR2 sends them to the LFN and VMN finally. 5.2. Outgoing packets For the outgoing packets sent from MNN to CN, they are firstly transmitted to the MR2 according to the default router configuration. In the same manner, the MR2 sends them to the MR1 when the MR2 finds that there is no state of the destination related prefix. When the MR2 fins that the destination address is in accordance with a prefix in its NEMO state table. MR2 will think these packets are intra-NEMO communication and the packets can be redirected to the CN directly. Otherwise, the packets are transmitted to the MAG, and then MAG finds the correct tunnel and sends them to the LMA. Finally, the LMA deencapsulates the packets and sends them to the CN. 6. Security Considerations To eliminate the threats on the interface between the MAG and the MR, this specification requires an established trust between the mobile access gateway and the MR node and to authenticate and authorize the MR before it is allowed to access the network. 7. IANA Considerations This specification has no actions for IANA. 8. Acknowledgements The authors would like to acknowledge the prior discussions on this topic in netext and netlmm mailing lists. 9. References [1] Gundavelli, et al., "Proxy Mobile IPv6", RFC5213, August 2008. [2] David B. Johnson, Charles E. Perkins and Jari Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Vijay Devarapalli, Ryuji Wakikawa, Alexandru Petrescu, and Pascal Thubert, "NEMO Basic Support Protocol", RFC 3963, January 2005. [4] CJ. Bernardos, M. Calderon and I. Soto, "PMIPv6 and Network Mobility Problem Statement", draft-bernardos-netext-pmipv6- nemo-ps-01, October 2009. Zhang et al. Expires September,2010 [Page 7] Internet-Draft Consideration of NEMO in PMIPv6 March 2010 [5] I. Soto, CJ. Bernardos, M. Calderon, A. Banchs and A. Azcorra, "NEMO-Enabled Localized Mobility Support for Internet Access in Automotive Scenarios", IEEE Communications Magazine, vol. 47, no. 5, pp: 152-159, May 2009. Authors' Addresses Hong-Ke Zhang, Zhi-Wei Yan, Hua-Chun Zhou, Jian-Feng Guan, Si-Dong Zhang National Engineering Laboratory for NGIID Beijing Jiaotong University of China Phone: +861051685677 Email:hkzhang@bjtu.edu.cn 06120232@bjtu.edu.cn hchzhou@bjtu.edu.cn guanjian8632@163.com sdzhang@center.njtu.edu.cn Zhang et al. Expires September,2010 [Page 8]