NetLMM Working Group J.-H. Lee Internet-Draft B.-J. Han Intended status: Informational T.-M. Chung Expires: March 24, 2009 Sungkyunkwan University H.-J. Lim Korea Financial Security Agency September 20, 2008 Network Mobility Basic Support within Proxy Mobile IPv6: scenarios and analysis draft-jhlee-netlmm-nemo-scenarios-01.txt 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 March 24, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract As Proxy Mobile IPv6 is deployed, a Mobile Network will be initialized in or move to a Proxy Mobile IPv6 domain. In this document, the scenarios of Network Mobility Basic Support within Proxy Mobile IPv6 that ensure session continuance for all nodes in Lee, et al. Expires March 24, 2009 [Page 1] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 the Mobile Network are presented. In addition, an analysis of all scenarios that comprise the interactions between Network Mobility Basic Support and Proxy Mobile IPv6 is provided as a guideline to PMIPv6 deployments. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 2.1. Conventions used in this document . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of scenarios . . . . . . . . . . . . . . . . . . . . 5 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Scenario A.1 . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Scenario A.2 . . . . . . . . . . . . . . . . . . . . . 7 3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Scenario B.1 . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Scenario B.2 . . . . . . . . . . . . . . . . . . . . . 9 3.2.3. Scenario B.3 . . . . . . . . . . . . . . . . . . . . . 9 3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. Scenario C.1 . . . . . . . . . . . . . . . . . . . . . 10 3.3.2. Scenario C.2 . . . . . . . . . . . . . . . . . . . . . 11 3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4.1. Scenario D.1 . . . . . . . . . . . . . . . . . . . . . 12 3.4.2. Scenario D.2 . . . . . . . . . . . . . . . . . . . . . 13 4. Chaining scenarios . . . . . . . . . . . . . . . . . . . . . . 13 5. Analysis of scenarios . . . . . . . . . . . . . . . . . . . . 13 5.1. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . 13 5.1.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . 16 5.1.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . 21 5.1.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . 24 5.2. Tunneling Management . . . . . . . . . . . . . . . . . . . 25 6. Returning Home . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Multihoming Considerations . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Lee, et al. Expires March 24, 2009 [Page 2] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 1. Introduction Network Mobility Basic Support (NBS) described in [1] provides that a Mobile Network (NEMO) moves from its home link to a new link based on Mobile IPv6 (MIPv6) [2]. The base protocol for NBS is MIPv6 and derived scenarios therefore focused on the interactions between NBS and MIPv6. As Proxy Mobile IPv6 (PMIPv6) is deployed [3], a NEMO will be initialized in or move to a PMIPv6 domain. Thus, the scenarios where NBS operates within PMIPv6 need to be analyzed as a guideline to PMIPv6 deployments. Note that the interaction scenarios between PMIPv6 and MIPv6 are presented in [4]. This document specifies the scenarios where NBS operates within PMIPv6 and related issues. In addition, an analysis for each scenario is presented. The NEMO Route Optimization is not considered in the scenarios because this document focuses on the interactions between NBS and PMIPv6. 2. Conventions & Terminology 2.1. 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 [5]. 2.2. Terminology Terminologies related to mobility support are defined in [3] and [6]. The following terminologies are frequently used in this document. o Proxy Mobile IPv6 domain (PMIPv6 domain), As defined in [3], it refers to the network where the mobility management is handled by PMIPv6. o Non-Proxy Mobile IPv6 domain (Non-PMIPv6 domain), It refers to the network in where PMIPv6 is not supported. o Mobile Network (NEMO): As defined in [6], it is an entire network that consists of one or more subnets and involves any node (host or router). A NEMO can be initialized at an Non-PMIPv6 domain or at a PMIPv6 domain and move from and to different mobility management domains. In this document, a NEMO is classified into two types: Mobile Network-MIPv6 and Mobile Network-PMIPv6. o Mobile Network-MIPv6 (NEMO-MIPv6): It is a NEMO that has been initialized at an Non-PMIPv6 domain. The Home Address (HoA) of Lee, et al. Expires March 24, 2009 [Page 3] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 NEMO-MIPv6 is configured from a prefix advertised in the home link. o Mobile Network-PMIPv6 (NEMO-PMIPv6): It is a NEMO that has been initialized at a PMIPv6 domain. The HoA of NEMO-PMIPv6 is taken from the Home Network Prefix (HNP) that is topologically anchored at the Local Mobility Anchor (LMA) defined in [3]. From a perspective of NEMO-PMIPv6, the LMA acts as the Home Agent (HA). o Mobile Router (MR): As defined in [6], it is a router that acts as a gateway in a NEMO. In this document, an MR MUST take cognizance of that the current domain provides a PMIPv6 service or not. o Mobile Router of Mobile Network-MIPv6 (MR-NEMO-MIPv6): It is an MR that acts as a gateway in the current NEMO-MIPv6. o Mobile Router of Mobile Network-PMIPv6 (MR-NEMO-PMIPv6): It is an MR that acts as a gateway in the current NEMO-PMIPv6. o Bi-directional Tunnel between a Mobile Router and its Home Agent (MRHA tunnel): As defined in [6], it is a bi-directional tunnel between an MR and its HA. In NBS, this tunnel is used to preserve session continuance between the MR and the HA. o Mobile Router Identifier (MR-Identifier): It is an identity for an MR used in a PMIPv6 domain. Similar to Mobile Node Identifier (MN-Identifier) defined in [3], mobility entities in a PMIPv6 domain MUST acquire and use it for identifying an MR. NAI or MAC address of MR can be used as an identifier. o Care-of Address of Mobile Router in Mobile Network-MIPv6 (CoA- NEMO-MIPv6): It is a Care-of Address (CoA) of MR-NEMO-MIPv6 obtained in the new link. When a NEMO-MIPv6 enters to a PMIPv6 domain, the CoA is configured based on the HNP and is used as long as the NEMO-MIPv6 is attached to the PMIPv6 domain. o Care-of Address of Mobile Router in Mobile Network-PMIPv6 (CoA- NEMO-PMIPv6): It is a CoA of MR-NEMO-PMIPv6 obtained in another PMIPv6. This address is configured based on the HNP and is used as long as the NEMO-PMIPv6 is attached to the PMIPv6 domain. o Home Address of Mobile Router in Mobile Network-MIPv6 (HoA-NEMO- MIPv6): It is a HoA of MR-NEMO-MIPv6 obtained in the home link. o Home Address of Mobile Router in Mobile Network-PMIPv6 (HoA-NEMO- PMIPv6): It is a HoA of MR-NEMO-PMIPv6 obtained in the home PMIPv6 domain. This address is configured based on the HNP defined in [3]. Lee, et al. Expires March 24, 2009 [Page 4] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 o Mobile Network Prefix (MNP): As defined in [6], it is a network prefix delegated to an MR that is used to advertise in the NEMO. o Mobile Network Node (MNN): As defined in [6], it represents any node that exists and has an address containing the MNP in a NEMO. A MNN is classified into three types: Local Fixed Node, Visiting Mobile Node, and Local Mobile Node. o Local Fixed Node (LFN): As defined in [6], it represents any normal node that has no mobility support stack. An LFN cannot change its point of attachment while communicating with other nodes and its address is taken from the MNP in a NEMO. o Visiting Mobile Node (VMN): As defined in [6], it represents any node that has a mobility support stack. A VMN is a temporarily attached node in a NEMO. From a perspective of VMN, the NEMO is a foreign link in where the VMN obtains its CoA from the MNP. o Local Mobile Node (LMN): As defined in [6], it represents any node that has a mobility support stack. From a perspective of LMN, the NEMO is a home link in where the LMN obtains its HoA from the MNP. o Local Mobility Anchor existing in the home PMIPv6 doamin (LMAh): It is a Local Mobility Anchor for NEMO-PMIPv6 in the home PMIPv6 doamin. o Local Mobility Anchor existing in the visit PMIPv6 doamin (LMAv): It is a Local Mobility Anchor for NEMO-PMIPv6 in the visit PMIPv6 doamin. o AAA server existing in the home domain (AAAh): It is a AAA server for a NEMO in the home domain. The AAAh is responsible for authenticating and authorizing the NEMO. o AAA server existing in the visit domain (AAAv): It is a AAA server for a NEMO in the visit domain. The AAAv is responsible for authenticating and authorizing the NEMO. The AAAv and the AAAh have a security association to support security credential exchanges. 3. Overview of scenarios Several interaction scenarios between NBS and PMIPv6 exist. In the following scenarios, a NEMO ensure that all MNNs keep their session continuance while the NEMO moves around. The main goal of describing scenarios is to show how to establish the MRHA tunnel between a NEMO and its HA when the NEMO moves within PMIPv6 domains. Lee, et al. Expires March 24, 2009 [Page 5] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 In the all scenarios, the mobility service selection option defined in [7] SHOULD be used to select the PMIPv6 service by a NEMO. AAA servers are used to provide secure access service and service parameters when the NEMO is attached in the access link. Note that the MR-Identifier is used as like as the use of the MN-Identifier. 3.1. Scenario A As shown in Figure 1, Scenario A describes that a NEMO moves from an Non-PMIPv6 domain to a PMIPv6 domain. There are two identified sub- scenarios depending on the NEMO type. __ +-----------+ __ __ _/ \__ +----+ ( Home Link ) _/ \_/ \_/ \------| CN | ( ) / / +----+ ( +----+ ) / Internet \__ ( |HA/ |---+---\ _ _ / \ ( |LMAh| | ) \__ __/ \__/ \__/ +--\------------------------+ ( +----+ | ) \__/ ( +----+ +----+ ) ( | ) / ( |LMAv| |AAAv| ) ( +----+ | ) / _______( +----+ +----+ ) ( |AAAh|---+ ) / ( //\\ <-- LMAA ) ( +----+ ) / ( +-----//--\\-----+ ) +-----------+ / ( ( // \\ )<-- IPv4/IPv6) | ( +---//------\\---+ Network ) +-------------|---------+ ( // \\ ) ( Non-PMIPv6 | ) ( //<-- pCoA1 \\<-- PCoA2 ) ( Domain +----+ ) ( +----+ +----+ ) ( | AR | ) ( |MAG1| |MAG2| ) ( +----+ ) ( +----+ +----+ ) ( : ) ( : ) ( : ) ( : <-- CoA-NEMO-MIPv6 ) ( +------+ ==============> +------+ /CoA-NEMO-PMIPv6 ) ( +------| MR |-----+ ) ( +----| MR |-----+ ) ( ( +------+ ) ) ( ( +------+ ) ) ( ( / : : : ) ) ( ( / : : : ) ) ( ( / : : +--+ ) ) ( ( / : : +--+) ) ( ( [LFN][VMN][LMN]|MR| ) ) ( ([LFN][VMN][LMN]|MR|) ) ( ( +--+ ) ) ( ( +--+) ) ( ( MNP = A::/64 ) ) ( ( MNP = A::/64 ) PMIPv6 ) ( +-------------------+ ) ( +-----------------+ Domain ) +-----------------------+ +------------------------------------+ Figure 1. Scenario A: a NEMO moves from an Non-PMIPv6 domain to a PMIPv6 domain Lee, et al. Expires March 24, 2009 [Page 6] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 3.1.1. Scenario A.1 In this scenario, a NEMO-MIPv6 that has been initialized at an Non- PMIPv6 domain moves from another Non-PMIPv6 domain to a PMIPv6 domain. As the NEMO-MIPv6 moves from the Non-PMIPv6 domain to the PMIPv6 domain, it attaches to one of MAGs. Similar to the MN attachment defined in [3], the NEMO-MIPv6 MUST be authenticated and authorized by the deployed security service mechanism. For instance, the AAA server can be used for authenticating and authorizing the MR-NEMO- MIPv6 based on the MR-Identifier. The serving MAG, MAG1, sends a Proxy Binding Update (PBU) message to the LMAv. Upon accepting the PBU message, the LMAv sends a Proxy Binding Acknowledgement (PBA) message to the MAG1. As a result of registration, a bi-directional tunnel between the MAG1 and the LMAv for the NEMO-MIPv6 is established. As the MAG1 adverties a Router Advertisement (RA) message cotaining the HNP, the MR-NEMO-MIPv6 obtains its CoA based on the HNP. In other words, the MR in NEMO-MIPv6 configues its CoA- NEMO-MIPv6 from the HNP in the PMIPv6 domain. The configured CoA- NEMO-MIPv6 is registered to the HA by sending Binding Update (BU) message as defined in [1]. The HA on receiving the BU message establishes a binding between the HoA-NEMO-MIPv6 and CoA-NEMO-MIPv6 of MR. As a result of establishing the binding, the HA can forward the packets for NEMO-MIPv6 to the current attachement point of MR- NEMO-MIPv6. 3.1.2. Scenario A.2 In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6 domain moves from an Non-PMIPv6 domain to another PMIPv6 domain. As the NEMO-PMIPv6 moves from the Non-PMIPv6 domain to the PMIPv6 domain, it attaches to one of MAGs. Similar to Scenario A.1, after successful authentication and authorization for PMIPv6 service, the registration procedure between the MAG1 and the LMAv is performed. A point of difference between Scenario A.1 and Scenario A.2 is that the MR-NEMO-PMIPv6 registers its CoA, CoA-NEMO-PMIPv6, to the LMAh by sending BU message. The LMAh on receiving the BU message sent from the MR establishes a binding between the HoA-NEMO-PMIPv6 and CoA- NEMO-PMIPv6 of MR. 3.2. Scenario B This scenario describes that a NEMO moves between links in a PMIPv6 domain as shown in Figure 2. There are three identified sub- scenarios depending on the NEMO type. Lee, et al. Expires March 24, 2009 [Page 7] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 +-----------+ +----+ ( Home Link ) | CN | ( ) +----+ ( +----+ ) __ / ( |HA/ |---+ ) __ __ _/ \/_ ( |LMAh| | ) _/ \_/ \_/ \ ( +----+ +------/ / ( | ) / Internet \ ( +----+ | ) \ _ _ / ( |AAAh|---+ ) \__ __/ \__/ \__/ ( +----+ ) \__/ | +-----------+ | | +------------------------------|---------------------------------+ ( PMIPv6 +---------+ +-------+ ) ( Domain |LMAv/LMAh| | AAAv/ | ) ( +---------+ | AAAh | ) ( // \\ <-- LMAA +-------+ ) ( +-----//----\\-----+ ) ( ( // \\ )<- IPv4/IPv6 ) ( +---//--------\\---+ Network ) ( // \\ ) ( //<--pCoA1 \\<--pCoA2 ) ( +----+ +----+ ) ( |MAG1| |MAG2| ) ( +----+ +----+ ) ( CoA-NEMO-MIPv6 : : ) ( /CoA-NEMO-PMIPv6 : : ) ( /HoA-NEMO-PMIPv6--> : : ) ( +------+ ==========> +------+ ) ( +----| MR |-----+ +----| MR |-----+ ) ( ( +------+ ) ( +------+ ) ) ( ( / : : : ) ( / : : : ) ) ( ( / : : +--+) ( / : : +--+) ) ( ([LFN][VMN][LMN]|MR|) ([LFN][VMN][LMN]|MR|) ) ( ( +--+) ( +--+) ) ( ( MNP = A::/64 ) ( MNP = A::/64 ) ) ( +-----------------+ +-----------------+ ) +----------------------------------------------------------------+ Figure 2. Scenario B: a NEMO moves between links in a PMIPv6 domain 3.2.1. Scenario B.1 In this scenario, a NEMO-MIPv6 that has been initialized at an Non- PMIPv6 domain moves between links in a PMIPv6 domain. This scenario is an extension of Scenario A.1. As described in Lee, et al. Expires March 24, 2009 [Page 8] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 Scenario A.1, the NEMO-MIPv6 has been registered at both the LMAv and the HA. According to [3], there is no additionally registration messages by sending the MR-NEMO-MIPv6 whenever the NEMO-MIPv6 moves between links in the PMIPv6 domain. The serving MAG, MAG2, sends a PBU message to the LMAv to inform that the NEMO-MIPv6 has been moved from the MAG1 to the MAG2. 3.2.2. Scenario B.2 In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6 domain moves between links in another PMIPv6 domain. This scenario is an extension of Scenario A.2. As described in Scenario A.2, the NEMO-PMIPv6 has been registered at both the LMAv and the LMAh. When the NEMO-PMIPv6 attaches to the MAG2, the MAG2 sends a PBU message to the LMAv. 3.2.3. Scenario B.3 In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6 domain moves between links in the PMIPv6 domain. When the NEMO-PMIPv6 boots up in the PMIPv6 domain, it is registered to the LMAh as a result of PBU message sent from the MAG1. The MR- NEMO-PMIPv6 also creates its HoA based on the RA message including the HNP. The created HoA, pHoA-NEMO-PMIPv6, is used to send a BU message to the LMAh. In this scenario, the LMAh acts as the HA of NEMO-PMIPv6. Similar to Scenario B.2, the MAG2 sends a PBU message to the LMAh when the NEMO-PMIPv6 attaches to the MAG2. 3.3. Scenario C This scenario describes that a NEMO moves between different PMIPv6 domains as shown in Figure 3. There are two identified sub-scenarios depending on the NEMO type. Lee, et al. Expires March 24, 2009 [Page 9] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 +-----------+ +----+ ( Home Link ) | CN | ( ) +----+ ( +----+ ) __ / ( |HA/ |---+ ) __ __ _/ \/_ ( |LMAh| | ) _/ \_/ \_/ \ ( +----+ +---------/ / ( | ) / Internet \ ( +----+ | ) \ _ _ / ( |AAAh|---+ ) \__ __/ \__/ \__/\ ( +----+ ) / \__/ \____ +-----------+ / \ / \ +-----------------/------------+ +------------\--------------+ ( PMIPv6-v1 +-----+ +-----+ ) ( PMIPv6-v2 +-----+ +-----+ ) ( Domain |LMAv1| |AAAv1| ) ( Domain |LMAv2| |AAAv2| ) ( +-----+ +-----+ ) ( +-----+ +-----+ ) ( LMAA1 --> || ) ( LMAA2 --> || ) ( +-------||-------+ ) ( +-------||-------+ ) ( ( IPv4 || IPv6 ) ) ( ( IPv4 || IPv6 ) ) ( +-------||-------+ ) ( +-------||-------+ ) ( || ) ( || ) ( || <--pCoA1 ) ( || <--pCoA2 ) ( +----+ ) ( +----+ ) ( |MAG1| ) ( |MAG2| ) ( +----+ ) ( +----+ ) ( : ) ( : ) ( CoA-NEMO-MIPv6 : ) ( : ) ( CoA-NEMO-PMIPv6 : ) ( : ) ( +-------+ ==================> +-------+ ) ( +----| MR |----+ ) ( +----| MR |----+ ) ( ( +-------+ ) ) ( ( +-------+ ) ) ( ( / : : : ) ) ( ( / : : : ) ) ( ( / : : +--+) ) ( ( / : : +--+) ) ( ([LFN][VMN][LMN]|MR|) ) ( ([LFN][VMN][LMN]|MR|) ) ( ( +--+) ) ( ( +--+) ) ( ( MNP = A::/64 ) ) ( ( MNP = A::/64 ) ) ( +-----------------+ ) ( +-----------------+ ) +------------------------------+ +---------------------------+ Figure 3. Scenario C: a NEMO moves between different PMIPv6 domains 3.3.1. Scenario C.1 In this scenario, a NEMO-MIPv6 that has been initialized at an Non- PMIPv6 domain moves between different PMIPv6 domains. As the NEMO-MIPv6 moves from a PMIPv6 domain (PMIPv6-v1 domain) to Lee, et al. Expires March 24, 2009 [Page 10] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 another PMIPv6 domain (PMIPv6-v2 domain), the CoA-NEMO-MIPv6 is changed because the serving MAG, MAG2, advertises a RA message including the different HNP that is previously assigned in the PMIPv6-v1 domain. Similar to Scenario A.1, there are two types of registration; registering to the LMAv2 and registering to the HA. For registering to the LMAv2, the MAG2 sends a PBU message to the LMAv2 when the MR-NEMO-MIPv6 is attached to the MAG2. As the MR- NEMO-MIPv6 receives the RA message from the MAG2, the MR sends a BU message to register its new CoA-NEMO-MIPv6 to the HA. 3.3.2. Scenario C.2 In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6 domain moves between different PMIPv6 domains. Similar to Scenario C.1, the MAG2 registers the NEMO-PMIPv6 to the LMAv2 by sending PBU message. The MR-NEMO-PMIPv6 on receiving the RA message sent from the MAG2 configures its new CoA-NEMO-PMIPv6 because the contained HNP in the RA message is a different HNP compared to the previous HNP. After the address configuration, the MR-NEMO- PMIPv6 informs its new CoA-NEMO-PMIPv6 to the LMAh located in the home domain. 3.4. Scenario D This scenario describes that a NEMO moves from a PMIPv6 domain to an Non-PMIPv6 domain as shown in Figure 4. There are two identified sub-scenarios depending on the NEMO type. Lee, et al. Expires March 24, 2009 [Page 11] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 +-----------+ +----+ ( Home Link ) | CN | ( ) +----+ ( +----+ ) __ / ( |HA/ |---+ ) __ __ _/ \/_ ( |LMAh| | ) _/ \_/ \_/ \ ( +----+ +------/ / ( | ) / Internet \ ( +----+ | ) \ _ _ /\ ( |AAAh|---+ ) \__ __/ \__/ \__/ \ ( +----+ ) /\__/ \ +-----------+ / \_______ / \ +----------------/-----------------+ | ( PMIPv6 +----+ ) | ( Domain |LMAv| ) | ( +----+ ) | ( // \\ <-- LMAA ) | ( +------//----\\------+ ) | ( ( IPv4 // \\ IPv6 ) ) | ( +----//--------\\----+ ) +----------|----------+ ( // \\ ) ( Non-PMIPv6 ) ( //<--pCoA1 \\<--pCoA2 ) ( Domain +----+ ) ( +----+ +----+ ) ( | AR | ) ( |MAG1| |MAG2| ) ( +----+ ) ( +----+ +----+ ) ( : ) ( : ) ( : ) ( CoA-NEMO-MIPv6 : ) ( : ) ( CoA-NEMO-PMIPv6 +------+ ==============> +------+ ) ( +----| MR |-----+ ) ( +----| MR |-----+ ) ( ( +------+ ) ) ( ( +------+ ) ) ( ( / : : : ) ) ( ( / : : : ) ) ( ( / : : +--+) ) ( ( / : : +--+) ) ( ([LFN][VMN][LMN]|MR|) ) ( ([LFN][VMN][LMN]|MR|) ) ( ( +--+) ) ( ( +--+) ) ( ( MNP = A::/64 ) ) ( ( MNP = A::/64 ) ) ( +-----------------+ ) ( +-----------------+ ) +----------------------------------+ +---------------------+ Figure 4. Scenario D: a NEMO moves from a PMIPv6 domain to an Non- PMIPv6 domain 3.4.1. Scenario D.1 In this scenario, a NEMO-MIPv6 that has been initialized at an Non- PMIPv6 domain moves from a PMIPv6 domain to another MIPv6 domain. As the NEMO-MIPv6 attaches to a new link in the Non-PMIPv6 domain, Lee, et al. Expires March 24, 2009 [Page 12] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 the MR-NEMO-MIPv6 receives a RA message sent from the access router (AR). The MR-NEMO-MIPv6 takes cognizance of that it has been moved to a new link based on the RA message. As described in [1], the MR- NEMO-MIPv6 sends a BU message to its HA after the adress configuration on the new link. 3.4.2. Scenario D.2 In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6 domain moves from another PMIPv6 domain to an Non-PMIPv6 domain. As the NEMO-PMIPv6 attaches to a new link in the Non-PMIPv6 domain, the NEMO-PMIPv6 receives a RA message sent from the AR. Similar to Scenario D.1, the MR-NEMO-PMIPv6 sends a BU message to its LMAh after the adress configuration on the new link. 4. Chaining scenarios Scenarios described in Section 3 SHOULD be chained according to the movement patterns of NEMO. The chaining scenarios is defined in the next version of this document. 5. Analysis of scenarios This section presents the message flows for each scenario described in Section 3. Based on the message flow, the tunneling management issues are presented. 5.1. Message Flow 5.1.1. Scenario A As mentioned in Section 3.1, Scenario A considers the case in where a NEMO moves from an Non-PMIPv6 domain to a PMIPv6 domain. 5.1.1.1. Scenario A.1 Figure 5 shows the message flow when the NEMO-MIPv6 that has been initialized at an Non-PMIPv6 domain enters from another Non-PMIPv6 domain to a PMIPv6 domain. o The NEMO-MIPv6 enters from the Non-PMIPv6 domain to a PMIPv6 domain. o The NEMO-MIPv6 is attached to the MAG1. Lee, et al. Expires March 24, 2009 [Page 13] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 +-----+ +----+ +------+ +------+ +------+ +----+ +----+ | MNN | | MR | | MAG1 | | LMAv | | AAAv | | HA | | CN | +-----+ +----+ +------+ +------+ +------+ +----+ +----+ | | | | | | | | Movement from | | | | | | Non-PMIPv6 domain | | | | | | | | | | | | | L2 Attachment | | | | | | | L2 Attached Event | | | | | | | | | | | | | Authentication | | | | |<------------------------------>| | | | | | Parameters | | | | | |<--------------------| | | | | | PBU | | | | | | |--------->| | | | | | | PBA | | | | | | RA(HNP) |<---------| | | | | |<---------| | | | | | | | | | | | | Address | | | | | | Configuration | | | | | | | | BU | | | | | |------------------------------------------>| | | |<------------------------------------------| | | | | BA | | | | | | | | | | | | | MR=HA | MAG1=LMAv| MR=HA | | |<-------->0<========>0<########>0<===================>0<-------->| | [CN|MNN] | | | | | [HA|MR][CN|MNN] | [CN|MNN] | | | v | | | | | | | [HA|MR][CN|MNN] v | | | | | | [LMAv|MAG1][HA|MR][CN|MNN] | | | | | | | | | | Figure 5. Message Flow for Scenario A.1 o The authentication procedure for PMIPv6 service is done between the MR-NEMO-MIPv6 and AAAv. o The AAAv provides PMIPv6 service parameters including the MR- Identifier and the corresponding Local Mobility Anchor Address (LMAA) after successfully completing the authentication procedure. o The MAG1 sends a PBU message to the LMAv. o The LMAv sends a PBA message to the MAG1 after successfully completing the binding registration procedure. As a result, the Lee, et al. Expires March 24, 2009 [Page 14] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 bi-directional tunnel between the MAG1 and the LMAv is established for the MR-NEMO-MIPv6. o The MAG1 sends a RA message to the MR-NEMO-MIPv6. The RA message includes the HNP that is the IPv6 prefix and is topologically anchored at the LMAv. o Based on the HNP, the MR-NEMO-MIPv6 creates its new CoA-NEMO- MIPv6. o The MR-NEMO-MIPv6 sends a BU message to its HA located in the home domain. o The HA establishes a binding between the HoA-NEMO-MIPv6 and CoA- NEMO-MIPv6 of MR. o Any packet destinated to the MNNs in the MR-NEMO-MIPv6 is forwarded to the current attachement point of MR-NEMO-MIPv6 through the HA and the LMAv. 5.1.1.2. Scenario A.2 Figure 6 shows the message flow when the NEMO-PMIPv6 that has been initialized at a PMIPv6 domain moves from an Non-MIPv6 domain to another PMIPv6 domain. The message flow is similar to Scenario A.1. Distinguishing differences are as follows. o As the NEMO-PMIPv6 is attached to the MAG1, the AAAv requests the authentication decision to the AAAh. o As the MR-NEMO-PMIPv6 configures its new CoA-NEMO-PMIPv6 based on the HNP contained in the RA message sent from the MAG1, it sends a BU message to its LMAh located in the home domain. o The LMAh on receiving the BU message sent from MR-NEMO-PMIPv6 establishes a binding between the HoA-NEMO-PMIPv6 and CoA-NEMO- PMIPv6. Lee, et al. Expires March 24, 2009 [Page 15] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 +-----+ +----+ +------+ +------+ +------+ +------+ +----+ +----+ | MNN | | MR | | MAG1 | | LMAv | | AAAv | | AAAh | |LMAh| | CN | +-----+ +----+ +------+ +------+ +------+ +------+ +----+ +----+ | | | | | | | | | Movement from | | | | | | | Non-PMIPv6 domain| | | | | | | | | | | | | | | L2 Attachment | | | | | | | | L2 Attached Event | | | | | | | | | | | | | | | Authentication Authentication | | | |<--------------------------->|<------->| | | | | | Parameters | Parameters | | | | |<------------------|<--------| | | | | | PBU | | | | | | | |-------->| | | | | | | | PBA | | | | | | | RA(HNP) |<--------| | | | | | |<--------| | | | | | | | | | | | | | | Address | | | | | | | Configuration | | | | | | | | | BU | | | | | | |----------------------------------------------->| | | |<-----------------------------------------------| | | | | BA | | | | | | | | | | | | | | | MR=LMAh |MAG1=LMAv| MR=LMAh | | | |<------>0<=======>0<#######>0<==========================>0<------>| |[CN|MNN]| | | | | [LMAh|MR][CN|MNN] | |[CN|MNN]| | | v | | | | | | | | [LMAh|MR][CN|MNN] v | | | | | | | [LMAv|MAG1][LMAh|MR][CN|MNN]| | | | | | | | | | | | Figure 6. Message Flow for Scenario A.2 5.1.2. Scenario B As mentioned in Section 3.2, Scenario B considers the case in where a NEMO moves between links in a PMIPv6 domain. 5.1.2.1. Scenario B.1 Figure 7 shows the message flow when the NEMO-MIPv6 that has been initialized at an Non-PMIPv6 domain moves between links in a PMIPv6 domain. This scenario is an extension of Scenario A.1 or Scenario C.1. Lee, et al. Expires March 24, 2009 [Page 16] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 o From a perspective of the PMIPv6 domain, the MR-NEMO-MIPv6 is treated as a node. As the MR-NEMO-MIPv6 is attached to the MAG2, the MAG2 sends a PBU message to the LMAv on behalf of the MR-NEMO- MIPv6. o The MR-NEMO-MIPv6 on receiving the RA message sent from the MAG2 can continue to use the same address, CoA-NEMO-MIPv6, configured in the previous MAG. o Since the CoA-NEMO-MIPv6 is not changed, the MR-NEMO-MIPv6 does not need to register its movement to the HA. According to [3], the MR-NEMO-MIPv6 will always detect the same link as long as its attached network is in the scope of PMIPv6 domain. +-----+ +----+ +------+ +------+ +------+ +----+ +----+ | MNN | | MR | | MAG2 | | LMAv | | AAAv | | HA | | CN | +-----+ +----+ +------+ +------+ +------+ +----+ +----+ | | | | | | | | Movement from | | | | | | a pervious MAG | | | | | | | | | | | | | L2 Attachment | | | | | | | L2 Attached Event | | | | | | | | | | | | | Authentication | | | | |<------------------------------>| | | | | | Parameters | | | | | |<--------------------| | | | | | PBU | | | | | | |--------->| | | | | | | PBA | | | | | | RA(HNP) |<---------| | | | | |<---------| | | | | | | | | | | | | | MR=HA | MAG2=LMAv| MR=HA | | |<-------->0<========>0<########>0<===================>0<-------->| | [CN|MNN] | | | | | [HA|MR][CN|MNN] | [CN|MNN] | | | v | | | | | | | [HA|MR][CN|MNN] v | | | | | | [LMAv|MAG2][HA|MR][CN|MNN] | | | | | | | | | | Figure 7. Message Flow for Scenario B.1 Lee, et al. Expires March 24, 2009 [Page 17] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 5.1.2.2. Scenario B.2 Figure 8 shows the message flow when the NEMO-PMIPv6 that has been initialized at a PMIPv6 domain moves between links in another PMIPv6 domain. This scenario is an extension of Scenario A.2 or Scenario C.2. o Similar to the message flow of Scenario B.1, the MR-NEMO-MIPv6 is treated as a node. The movement of NEMO-PMIPv6 is detected by the MAG2 and the MAG2 sends a PBU message on behalf of the MR-NEMO- PMIPv6. +-----+ +----+ +------+ +------+ +------+ +------+ +----+ +----+ | MNN | | MR | | MAG2 | | LMAv | | AAAv | | AAAh | |LMAh| | CN | +-----+ +----+ +------+ +------+ +------+ +------+ +----+ +----+ | | | | | | | | | Movement from | | | | | | | a pervious MAG | | | | | | | | | | | | | | | L2 Attachment | | | | | | | | L2 Attached Event | | | | | | | | | | | | | | | Authentication Authentication | | | |<--------------------------->|<------->| | | | | | Parameters | Parameters | | | | |<------------------|<--------| | | | | | PBU | | | | | | | |-------->| | | | | | | | PBA | | | | | | | RA(HNP) |<--------| | | | | | |<--------| | | | | | | | | | | | | | | | MR=LMAh |MAG2=LMAv| MR=LMAh | | | |<------>0<=======>0<#######>0<==========================>0<------>| |[CN|MNN]| | | | | [LMAh|MR][CN|MNN] | |[CN|MNN]| | | v | | | | | | | | [LMAh|MR][CN|MNN] v | | | | | | | [LMAv|MAG2][LMAh|MR][CN|MNN]| | | | | | | | | | | | Figure 8. Message Flow for Scenario B.2 5.1.2.3. Scenario B.3 Figure 9 shows the message flow for Scenario B.3 in where the MR- NEMO-PMIPv6 boots up under an MAG of the PMIPv6 domain and then moves to another MAG in the same PMIPv6 domain, e.g., inter MAG handoff. Lee, et al. Expires March 24, 2009 [Page 18] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 Since the MR-NEMO-PMIPv6 is registered by sending PBU message sent from MAG1 to the LMAh, the MR-NEMO-PMIPv6 configures its HoA-NEMO- PMIPv6 from the RA message sent from the MAG1. The MR-NEMO-PMIPv6 is treated as a node as long as it moves in the PMIPv6 domain. o As the MR-NEMO-PMIPv6 boots up in the PMIPv6 domain, it is attached to the MAG1. o The authentication procedure between the MR-NEMO-PMIPv6 and the AAAh is done, then the MAG1 obtains PMIPv6 service parameters for the MR-NEMO-PMIPv6 through the AAAh. o The binding registration procedure between the MAG1 and the LMAh is done. o After the address configuration based on the RA message sent from the MAG1, the MR-NEMO-PMIPv6 sends a BU message to the LMAh. o As the MR-NEMO-PMIPv6 moves from the MAG1 to the MAG2, the MAG2 detects its movement. Then the further message flow is the same to the case of Scenario B.2 Lee, et al. Expires March 24, 2009 [Page 19] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 +-----+ +----+ +------+ +------+ +------+ +------+ +----+ | MNN | | MR | | MAG1 | | MAG2 | | LMAh | | AAAh | | CN | +-----+ +----+ +------+ +------+ +------+ +------+ +----+ | | | | | | | | Boot up | | | | | | | | | | | | | L2 Attachment | | | | | | | L2 Attached Event | | | | | | | | | | | | | | Authentication | | | | |<----------------------------------------->| | | | | Parameters | | | | | |<-------------------------------| | | | | PBU | | | | | | |-------------------->| | | | | | PBA | | | | | | RA(HNP) |<--------------------| | | | |<---------| | | | | | Address | | | | | | Configuration | | | | | | | | BU | | | | | |------------------------------->| | | | |<-------------------------------| | | | Movement from | BA | | | | | MAG1 to MAG2 | | | | | | | | | | | | | L2 Attachment | | | | | | | | L2 Attached Event | | | | | | | | | | | | | Authentication | | | | |<----------------------------------------->| | | | | | Parameters | | | | | |<--------------------| | | | | | PBU | | | | | | |--------->| | | | | | | PBA | | | | | RA(HNP) | |----------| | | | |<--------------------| | | | | | | | | | | | | | | MAG2=LMAh| | | |<------------------------------>0<========>0<------------------->| | [CN|MNN] | | [LMAh|MAG2][CN|MNN] | [CN|MNN] | | | | | | | | Figure 9. Message Flow for Scenario B.3 Lee, et al. Expires March 24, 2009 [Page 20] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 5.1.3. Scenario C As mentioned in Section 3.3, Scenario C considers the case in where a NEMO moves between different PMIPv6 domains, e.g., inter domain handoff. 5.1.3.1. Scenario C.1 Figure 10 shows the message flow when the NEMO-MIPv6 that has been initialized at an Non-PMIPv6 moves between different PMIPv6 domains. Becuase this scenario represents the inter domain handoff, two types of registration MUST be performed; registering to the current visiting LMA (LMAv2) and registering to the HA located in the home domain. This scenario is an extension of Scenarios A.1 or B.1. o As the MR-NEMO-MIPv6 moves to the new PMIPv6 domain in where the LMAv2 is the topological anchor point for all nodes' HNP, the MR- NEMO-MIPv6 performs the authentication procedure with the AAAv2. o After successfully completing the authentication procedure, the serving MAG, MAG2, obtains PMIPv6 service parameters for the MR- NEMO-MIPv6 via the AAAv2. o The binding registration procedure between the MAG2 and the LMAv2 is done. o The MAG2 sends a RA message to the MR-NEMO-MIPv6. o The MR-NEMO-MIPv6 on receiving the RA message performs the address configuration procedure and then sends a BU message to its HA. o The HA establishes a binding between the HoA-NEMO-MIPv6 and CoA- NEMO-MIPv6 of MR. Lee, et al. Expires March 24, 2009 [Page 21] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 +-----+ +----+ +------+ +-------+ +-------+ +----+ +----+ | MNN | | MR | | MAG2 | | LMAv2 | | AAAv2 | | HA | | CN | +-----+ +----+ +------+ +-------+ +-------+ +----+ +----+ | | | | | | | | Movement from | | | | | | a PMIPv6 domain | | | | | | | | | | | | | L2 Attachment | | | | | | | L2 Attached Event | | | | | | | | | | | | | Authentication | | | | |<------------------------------>| | | | | | Parameters | | | | | |<--------------------| | | | | | PBU | | | | | | |--------->| | | | | | | PBA | | | | | | RA(HNP) |<---------| | | | | |<---------| | | | | | | | | | | | | Address | | | | | | Configuration | | | | | | | | BU | | | | | |------------------------------------------>| | | |<------------------------------------------| | | | | BA | | | | | | | | | | | | | MR=HA |MAG2=LMAv2| MR=HA | | |<-------->0<========>0<########>0<===================>0<-------->| | [CN|MNN] | | | | | [HA|MR][CN|MNN] | [CN|MNN] | | | v | | | | | | | [HA|MR][CN|MNN] v | | | | | | [LMAv2|MAG1][HA|MR][CN|MNN] | | | | | | | | | | Figure 10. Message Flow for Scenario C.1 5.1.3.2. Scenario C.2 Figure 11 shows the message flow when the NEMO-PMIPv6 that has been initialized at an Non-PMIPv6 moves between different PMIPv6 domains. Similar to Scenario C.1, it represents the inter domain handoff so that two types of registration MUST be performed; registering to the current visiting LMA (LMAv2) and registering to the LMAh located in the home domain. This scenario is an extension of Scenarios A.2 or B.2. The message flow is similar to Scenario C.1. Distinguishing differences are as follows. Lee, et al. Expires March 24, 2009 [Page 22] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 o As the MR-NEMO-PMIPv6 receives the RA message from the MAG2, the MR-NEMO-PMIPv6 configures its new CoA-NEMO-PMIPv6 and then sends a BU message to its LMAh. o The HA on receiving the BU message establishes a binding between the HoA-NEMO-PMIPv6 and CoA-NEMO-PMIPv6 of MR. +-----+ +----+ +------+ +-------+ +-------+ +------+ +----+ +----+ | MNN | | MR | | MAG2 | | LMAv2 | | AAAv2 | | AAAh | |LMAh| | CN | +-----+ +----+ +------+ +-------+ +-------+ +------+ +----+ +----+ | | | | | | | | | Movement from | | | | | | | a PMIPv6 domain | | | | | | | | | | | | | | | L2 Attachment | | | | | | | | L2 Attached Event | | | | | | | | | | | | | | | Authentication Authentication | | | |<--------------------------->|<------->| | | | | | Parameters | Parameters | | | | |<------------------|<--------| | | | | | PBU | | | | | | | |-------->| | | | | | | | PBA | | | | | | | RA(HNP) |<--------| | | | | | |<--------| | | | | | | | | | | | | | | Address | | | | | | | Configuration | | | | | | | | | BU | | | | | | |----------------------------------------------->| | | |<-----------------------------------------------| | | | | BA | | | | | | | | | | | | | | | MR=LMAh |MAG2=LMAv2 MR=LMAh | | | |<------>0<=======>0<#######>0<==========================>0<------>| |[CN|MNN]| | | | | [LMAh|MR][CN|MNN] | |[CN|MNN]| | | v | | | | | | | | [LMAh|MR][CN|MNN] v | | | | | | |[LMAv2|MAG2][LMAh|MR][CN|MNN]| | | | | | | | | | | | Figure 11. Message Flow for Scenario C.2 Lee, et al. Expires March 24, 2009 [Page 23] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 5.1.4. Scenario D As mentioned in Section 3.4, Scenario D considers the case in where a NEMO moves from a PMIPv6 to an Non-PMIPv6 domain. 5.1.4.1. Scenario D.1 Figure 12 shows the message flow when the NEMO-MIPv6 that has been initialized at an Non-PMIPv6 domain moves from a PMIPv6 domain to another Non-PMIPv6 domain. This scenario is an extension of Scenarios A.1 or B.1 or C.1. o As the MR-NEMO-MIPv6 moves out from a PMIPv6, the MR-NEMO-MIPv6 receives the RA message sent from AR in the new link. o The MR-NEMO-MIPv6 creates its new CoA-NEMO-MIPv6 because the IPv6 prefix is different from its previous prefix. In other words, the MR-NEMO-MIPv6 takes cognizance of that it has been moved to a new link based on the prefix information sent from the AR. o The MR-NEMO-MIPv6 sends a BU message to its LMAh to inform its movement. +-----+ +----+ +----+ +----+ +----+ | MNN | | MR | | AR | | HA | | CN | +-----+ +----+ +----+ +----+ +----+ | | | | | | Movement from | | | | a PMIPv6 domain | | | | | RA | | | | |<--------------| | | | | | | | | Address | | | | Configuration | | | | | | BU | | | |------------------------------>| | | |<------------------------------| | | | | BA | | | | | | | | | MR=HA | | |<------------->0<=============================>0<------------->| | [CN|MNN] | [HA|MR][CN|MNN] | [CN|MNN] | | | | | | Figure 12. Message Flow for Scenario D.1 Lee, et al. Expires March 24, 2009 [Page 24] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 5.1.4.2. Scenario D.2 Figure 13 shows the message flow when the NEMO-PMIPv6 that has been initialized at a PMIPv6 domain moves from another PMIPv6 domain to an Non-PMIPv6 domain. This scenario is an extension of Scenarios A.2 or B.2 or C.2. The message flow is similar to Scenario D.1. Distinguishing differences are as follows. o As the MR-NEMO-PMIPv6 receives the RA message from the AR, the MR- NEMO-PMIPv6 configures its new CoA-NEMO-PMIPv6 and then sends a BU message to its LMAh. +-----+ +----+ +----+ +----+ +----+ | MNN | | MR | | AR | |LMAh| | CN | +-----+ +----+ +----+ +----+ +----+ | | | | | | Movement from | | | | a PMIPv6 domain | | | | | RA | | | | |<--------------| | | | | | | | | Address | | | | Configuration | | | | | | BU | | | |------------------------------>| | | |<------------------------------| | | | | BA | | | | | | | | | MR=LMAh | | |<------------->0<=============================>0<------------->| | [CN|MNN] | [LMAh|MR][CN|MNN] | [CN|MNN] | | | | | | Figure 13. Message Flow for Scenario D.2 5.2. Tunneling Management In the next version of this document, the tunneling management is presented. 6. Returning Home In the next version of this document, the returning home case is presented. Lee, et al. Expires March 24, 2009 [Page 25] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 7. Multihoming Considerations The NEMO can connect to a PMIPv6 domain through multiple interfaces. In the next version of this document, the multihoming considerations are presented. 8. Security Considerations TBA 9. IANA Considerations TBA 10. Acknowledgment Comments are solicited and should be addressed to NetLMM working group's mailing list at netlmm@ietf.org and/or the authors. This study was supported by a grant of the Korea Health 21 R&D Project, Ministry of Health & Welfare, Republic of Korea (02-PJ3-PG6- EV08-0001). 11. References [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [4] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-giaretta-netlmm-mip-interactions-02 (work in progress), November 2007. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. Lee, et al. Expires March 24, 2009 [Page 26] Internet-Draft NEMO Basic Support within PMIPv6 September 2008 [7] Damic, D., Premec, D., Patil, B., Sahasrabudhe, M., and S. Krishnan, "Proxy Mobile IPv6 indication and discovery", draft-damic-netlmm-pmip6-ind-discover-03 (work in progress), February 2008. Authors' Addresses Jong-Hyouk Lee Sungkyunkwan University 26316, Engineering Building 2, Internet Management Technology Lab. Suwon-si, Gyeonggi-do, 440-746 Korea Phone: +82 031 290 7222 Email: jhlee@imtl.skku.ac.kr; jonghyouk@gmail.com Byung-Jin Han Sungkyunkwan University 26316, Engineering Building 2, Internet Management Technology Lab. Suwon-si, Gyeonggi-do, 440-746 Korea Phone: +82 031 290 7222 Email: bjhan@imtl.skku.ac.kr Tai-Myoung Chung Sungkyunkwan University 27328, Engineering Building 2, Internet Management Technology Lab. Suwon-si, Gyeonggi-do, 440-746 Korea Phone: +82 031 290 7131 Email: tmchung@ece.skku.ac.kr Hyung-Jin Lim Korea Financial Security Agency 15F, 36-1, Yoido-dong, Youngdeungpo-gu Seoul, 150-886 Korea Phone: +82 02 6919 9156 Email: hjlim@fsa.or.kr Lee, et al. Expires March 24, 2009 [Page 27] Internet-Draft NEMO Basic Support within PMIPv6 September 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lee, et al. Expires March 24, 2009 [Page 28]