NETLMM Working Group G. Velev Internet-Draft K. Weniger Intended status: Informational Panasonic Expires: August 28, 2008 February 25, 2008 Interactions between PMIPv6 and MIPv6: Route Optimization Issues draft-velev-netlmm-mip-pmip-ro-01 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 August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The interactions scenarios between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) protocols are described in [ID-MIP-PMIP]. This document analyzes these scenarios when route optimization is used. The analysis results in the identification of possible issues that should be considered in the design of extensions for Route Optimization in PMIPv6. Velev & Weniger Expires August 28, 2008 [Page 1] Internet-Draft PMIPv6-MIPv6 RO Issues February 2008 Requirements Language 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 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of route optimization . . . . . . . . . . . . . . . . 3 3.1. Route optimization in MIPv6 . . . . . . . . . . . . . . . 3 3.2. Route optimization in PMIPv6 . . . . . . . . . . . . . . . 4 4. Analysis of the scenarios and possible issues . . . . . . . . 5 4.1. Proxy RO in scenario A . . . . . . . . . . . . . . . . . . 5 4.2. Proxy RO in scenario B . . . . . . . . . . . . . . . . . . 7 4.3. Proxy RO in scenario C . . . . . . . . . . . . . . . . . . 10 4.3.1. MN2 performs MN role . . . . . . . . . . . . . . . . . 10 4.3.2. MN2 performs CN role . . . . . . . . . . . . . . . . . 11 5. Summary of the issues . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Velev & Weniger Expires August 28, 2008 [Page 2] Internet-Draft PMIPv6-MIPv6 RO Issues February 2008 1. Introduction The NETLMM WG is standardizing Proxy Mobile IPv6 (PMIPv6) as the protocol for network-based localized mobility management. The MIPv6- PMIPv6 interactions document [ID-MIP-PMIP] captures the issues with the inter-working between host-based (MIPv6) and network-based (PMIPv6) mobility and identifies three main scenarios. However, the document does not consider the cases when a route optimized path is set up. In PMIPv6 the mobile access gateway (MAG) manages the mobility- related registrations with the local mobility agent (LMA) on behalf of the mobile nodes (MNs) attached to it. According to the base PMIPv6 specification [ID-PMIPv6] all data packets are bi- directionally tunneled between MAG and LMA. In some scenarios, e.g. if the communicating end nodes are located in the same PMIPv6 domain, it is advantageous to route the packets directly between the MAGs to which the nodes are attached. The PMIPv6 base spec does not support route optimization (RO) between different MAGs, however, there are individual proposals (see Section 3.2) for establishing such a route optimized path. In these proposals the MNs are unaware about the proxy RO set up in PMIPv6 domain between the MAGs. On the other hand, in MIPv6 the MN itself performs the route optimization with a CN. This document provides an analysis of the scenarios and possible issues when the PMIPv6 and MIPv6 route optimization procedures interact. 2. Terminology General mobility terminology can be found in [RFC3753]. Further, PMIPv6-related terminology used in this document is defined in [ID-PMIPv6] 3. Overview of route optimization This section provides an overview of the route optimization procedures specified for MIPv6 and the general characteristics of a potential to-be-standardized route optimization procedure for PMIPv6. 3.1. Route optimization in MIPv6 MIPv6 protocol comes with a route optimization scheme that enables a direct communication between MN and CN, i.e. the data packets are bypassing the Home Agent. Route optimization requires the mobile Velev & Weniger Expires August 28, 2008 [Page 3] Internet-Draft PMIPv6-MIPv6 RO Issues February 2008 node to register its current binding of home address (HoA) to care- of-address (CoA) at the correspondent node. The CN establishes a binding cache entry and packets from the CN can be routed directly to the CoA of the MN. MPv6 specification [RFC3775] defines the return routability (RR) procedure that authorizes the BU sent by the MN by the use of a cryptographic token exchange (keygen tokens). The binding update is signed by binding management key (Kbm) that is generated based on the keygen tokens obtained from CN separately for the home address and care-of-address. The detailed RR and RO procedures are described in sections 5.2, 6.1, 9.4 and 9.5 in [RFC3775]. 3.2. Route optimization in PMIPv6 Route optimization in PMIPv6 (proxy RO) is not in the charter of the NetLMM working group and is not specified in the PMIPv6 base specification [ID-PMIPv6]. However, [ID-PMIPv6] describes one case where the local routing at the MAG is possible. The local routing is applied when the two communicating mobile nodes are attached to the same MAG and the MAG's policy in coordination with LMA allows such routing. In all other attachment constellations the PMIPv6 protocol mandates reverse tunneling of data packets to the LMA. However, interest in the area of PMIPv6 RO (henceforth called proxy RO) exists from various working group members and individual solutions are already available. In the following, the general characteristics of possible PMIPv6 RO mechanisms are analyzed. Subsequently, some individual submissions are briefly presented as example solutions. In general, the proxy RO can be categorized in the following cases: 1. Between the MN and the CN's MAG. In this case the RO is initiated by the MN and the MAG is the endpoint of the route optimized path. For instance, if MIPv6 RO is used, CN's MAG performs the role of MIPv6 CN with respect to RO. 2. Between the MN's MAG and the CN. In this case the MN's MAG initiates the RO with CN on behalf of the MN and the endpoint of the route optimized path is MN's MAG instead of MN. For instance, if MIPv6 RO is used the MAG performs the role of MIPv6 MN with respect to RO. 3. Between MAGs. In this case the MAG, to which the MN is attached, initiates RO with the CN's MAG and a route optimized path between both MAGs is established. For instance, if MIPv6 RO is used, the MN's MAG performs the role of MIPv6 MN with respect to RO and the Velev & Weniger Expires August 28, 2008 [Page 4] Internet-Draft PMIPv6-MIPv6 RO Issues February 2008 MAG, to which the CN is attached, performs the role of MIPv6 CN. Each of the above cases is analyzed in different MIPv6-PMIPv6 interaction scenarios in Section 4. The document [PMIPv6-RO-RR] describes the applicability of Enhanced Route Optimization for Mobile IPv6 specified in [RFC4866] for PMIPv6, i.e. how cryptographically generated addresses (CGA) and the corresponding optimized RO signalling (compared to [RFC3775]) are used. The authors describe a proxy Return Routability (RR) procedure performed by the MAG on behalf of the MN. The document addresses cases 2 and 3 from above. Another individual approach for RO in PMIPv6 is described in [PMIPv6-RO-ROA]. In this approach, the exchange of RO setup messages (similar to binding updates messages) between the MAGs is performed either a) via the LMAs, to which the MAGs are attached, or b) directly between the MAGs. In the latter case, a route optimization association (ROA) between the MAGs is needed. The document addresses the case 3 (i.e. MAG-MAG RO) from above. A further individual solution is described in [PMIPv6-RO-IPv4] that presents a more general approach and considers a combination of both individual solutions presented in the previous paragraphs: either performing a proxy RR between MAGs or having a Security Association between MAGs for direct exchange of binding updates. In general, if a mobile node attached to a MAG in PMIPv6 domain moves to a new MAG, the old MAG, the new MAG and the LMA should manage the transition of the RO-related state from the old to the new MAG. Further the new MAG shall update the BCE in the correspondent node. These procedures are outside of the scope of this document because it is not specific to MIPv6-PMIPv6 interactions and should be defined in a potential to-be-standardized PMIPv6 RO procedure. 4. Analysis of the scenarios and possible issues The categorization of the MIPv6-PMIPv6 interactions with respect to RO is based on scenarios A, B and C described in [ID-MIP-PMIP] in order to achieve compliance between both documents. For each of the scenarios the cases from Section 3.2 are applied and the resulting issues are identified. 4.1. Proxy RO in scenario A In scenario A, PMIPv6 is used as a network-based local mobility management protocol within one access network, whereas MIPv6 is used Velev & Weniger Expires August 28, 2008 [Page 5] Internet-Draft PMIPv6-MIPv6 RO Issues February 2008 as a global mobility management protocol. Furthermore, HA and LMA are not co-located. In this scenario the MN uses MIPv6 and registers the IP address obtained in the PMIPv6 domain as CoA at the HA. A bi-directional tunnel is set up between the MN and HA. An additional PMIPv6 tunnel is in use between MAG1 and LMA1. Figure 1 illustrates the hierarchical application of MIPv6 and PMIPv6 protocols in scenario A. The CN relies on the PMIPv6 for mobility management, it is attached to MAG2 and anchored at LMA1, where the MN is anchored too. +----+ | HA | +----+ //\ // \ +------------//----\-------------+ ( // \ ) Global Mobile IPv6 ( // \ ) Domain +---------//----------\----------+ // \ +------+ +----+ | LMA1 | |LMA2| +------+ +----+ ////\\ \\ +----////--\\----+ +----\\------+ ( //// \\ ) ( \\ ) Local Mobility Network ( //// \\ ) ( \\ ) PMIPv6 domain +-////--------\\-+ +-------\\---+ //// \\ \\ //// \\ \\ //// \\ \\ +----+ +----+ +----+ |MAG1| |MAG2| |MAG3| +----+ +----+ +----+ || | | [MN] [CN] Figure 1 - Scenario A As MIPv6 bidirectional tunnel is set up between MN and HA, the PMIP entities (MAG1 and LMA1) cannot learn the address of the CN, and thus, cannot perform any actions with respect to proxy RO. Even if the CN is attached to the same or neighbour MAG, to which MN is attached, PMIP entities are unable to discover such a situation assuming that there is no explicit information between MN's HA and LMA. Therefore, proxy RO initiated by MN's MAG to the CN, i.e. case Velev & Weniger Expires August 28, 2008 [Page 6] Internet-Draft PMIPv6-MIPv6 RO Issues February 2008 2 from Section 3.2, is not possible. The MAG would rather see the HA as CN and establish an optimized route to the HA, which is of course not desired. Proxy RO between MAG1 and MAG2 (case 3) has the same problem as case 2: since a MIPv6 tunnel is set up between MN and HA, MAG1 cannot discover CN's address and initiate proxy RO. In contrary to cases 2 and 3, proxy RO tunnel between MN and MAG2 (case 1) is possible. MN initiates a MIPv6 RO with the CN and the MAG2 is configured to act as proxy CN on behalf CN. The resulting path in both directions (i.e. MN->CN and CN->MN) would be MN-MAG1- LMA1-MAG2-CN. Such a situation is comparable to usual PMIPv6 routing, although MIPv6 RO IP header options are present in the data packets (Routing Header Type 2 and Home Address destination option). This situation reveals CN address to MAG1 and hence gives opportunity for a proxy RO tunnel set up between MAG1 and MAG2. A potential to- be-standardized PMIPv6 RO procedure shall consider the handling of such a situation, where already MIPv6 RO is running between MN and CN (or CN's MAG, i.e. MAG2). In summary, proxy PMIPv6 RO from MAG1 to CN or from MAG1 to MAG2 in scenario A cannot be initiated unless MN performs MIPv6 RO with CN (unless there are other means of informing MAG1 of the CN address). Another proxy RO constellation is possbile, in which the MAG2 initiates proxy RO with the MN on behalf of the CN. After such a route optimized path is set up, the data packets would continue to flow via the HA, i.e. the path would the same as before the proxy RO. The MAG2 however cannot recognize such a constellation. Therefore it is advantageous if MAG2 does not initiate proxy RO with MN. Figure 1 shows a case where the CN is using only a PMIPv6 service. However, a situation is possible, in which the CN (analogically to MN) is also using PMIPv6 for local mobility and MIPv6 for global mobility. In such a situation both end nodes (MN and CN) must perform MIPv6 procedure in order to utilize a proxy RO tunnel between the MAGs. The proxy RO tunnel between the MAGs can be set up before the MIPv6 RO procedures are completed, however, the MAGs must know the care-of-address of the corresponding node and the respective MAG they are attached to. After the PMIPv6 RO is completed, the MAGs create a routing state pointing the CoA of the correspondent node to its respective MAG. The MAGs start to forward packets over the proxy RO tunnel as soon as the end nodes start to use the CoA of the correspondent node. 4.2. Proxy RO in scenario B In scenario B some MNs use MIPv6 to manage their movements while others rely on a PMIPv6 protocol provided by the network. The configuration of the MAG for supporting such scenario is described in Velev & Weniger Expires August 28, 2008 [Page 7] Internet-Draft PMIPv6-MIPv6 RO Issues February 2008 [ID-MIP-PMIP] Section 6.14. [ID-MIP-PMIP] assumes that the mobility anchor for MIPv6 and PMIPv6 is the same entity implementing the functions of both HA and LMA (below denoted as HA/LMA). For a MN, to which PMIPv6 service is offered, the HA/LMA is acting as LMA and for a MN, to which MIPv6 service is offered, the HA/LMA is acting as HA. Figure 2 illustrates scenario B where a MN uses MIPv6 and a CN relies on PMIPv6 for mobility management. The MN utilizes MIPv6 tunnel to the HA/LMA via AR whereas a PMIPv6 tunnel is set up for CN between MAG2 and HA/LMA. +------+ |HA/LMA| +------+ //\\ +- ---//--\\----+ ( // \\ ) Mixed MIPv6 and ( // \\ ) PMIPv6 mobility domain +--//--------\\-+ // \\ // \\ +----+ +----+ | AR | |MAG2| +----+ +----+ || | [MN] [CN] Figure 2 - Scenario B with colocated HA and LMA An additional case is possible in scenario B, where MN's HA and CN's LMA are not colocated, however, they are in the same PMIPv6 mobiltiy domain. Such a case is depicted on Figure 3. Velev & Weniger Expires August 28, 2008 [Page 8] Internet-Draft PMIPv6-MIPv6 RO Issues February 2008 +----+ +-----+ | HA | | LMA | +----+ +-----+ || || +--||---------- ||--+ ( || || ) Mixed MIPv6 and ( || || ) PMIPv6 mobility domain +--||-----------||--+ || || +----+ +----+ | AR | |MAG2| +----+ +----+ || | [MN] [CN] Figure 3 - Scenario B with separated HA and LMA First, the analyses focuses on the proxy RO from MN side. For the constellations in Figure 2 and Figure 3, proxy RO is possible only between MN and MAG2 (case 1). The proxy RO cases 2 and 3 from Section 3.2 are not possible because MN is attached to an AR. If the MN initiates a MIPv6 RO with CN, MAG2 may respond as proxy on behalf of the CN, which results in case 1. The RO path is set up between MN and MAG2, which is the optimal route from MN to CN. Additionally, MAG2 may initiate proxy RO with the MN in order to achieve route optimized path in direction from CN to MN. If the RO is performed in both directions, no further optimizations are needed. Second, the analyses focuses on the proxy RO from CN side. This is the case if MAG2 initiates proxy RO with MN. In Figure 2, the resulting route optimized path would be via the MN's HA/LMA, because MAG2 does not know MN's CoA. The proxy RO in such a case does not lead to any path optimization and hence it is beneficial if MAG1 does not initiate proxy RO with MN. In Figure 3, the resulting route optimized path would be from MAG2 directly to MN's HA. In such a case the proxy RO would have a small benefit, as the data path doesn't run over LMA. In summary, to achieve the optimal RO path in scenario B between MN using MIPv6 and CN relying on PMIPv6 service in the same network domain, the MN should initiate MIPv6 RO and additionally a proxy RO between MN and MAG should be performed. The network can assist the MN to initiate MIPv6 RO, as the network entities (most probably LMA) can discover such constellation. Velev & Weniger Expires August 28, 2008 [Page 9] Internet-Draft PMIPv6-MIPv6 RO Issues February 2008 4.3. Proxy RO in scenario C In scenario C a MIPv6-capable MN moves between access networks using different mobility management schemes, i.e. some access networks support PMIPv6 and others do not. This results in transition between PMIPv6 and MIPv6 mobility management for the particular MN and requires that LMA and HA functions are located in the same physical entity. Scenario C is depicted in Figure 4. +------+ |HA/LMA|-----------------------+ +------+ | //\\ | +-------//--\\--------+ | ( // \\ PMIPv6 ) | ( // \\ domain) +--------------+ +----//--------\\-----+ ( Non-PMIPv6 ) // \\ ( domain ) // \\ +--------------+ // \\ | +----+ +----+ +----+ |MAG1| |MAG2| | AR | +----+ +----+ +----+ | | | [MN1] [MN2] ------> (a) | (b) <------ [MN2] Figure 4 - Scenario C 4.3.1. MN2 performs MN role In order to anlyze the issues with RO in scenario C, first it is assumed that MN2 has the role of MN and MN1 has the role of CN. Further two transition scenarios are investigated denoted by the arrows (a) and (b) in Figure 4. In transition (a) the MN2 moves from MAG2 of PMIPv6 domain to an AR of non-PMIPv6 domain, whereas in transition (b) the MN2 moves from AR to MAG2. At first, transition (a) is analyzed. If a MN2 is attached to MAG2 and MN1 is attached to MAG1, a proxy RO path can be set up according to cases 2 (MAG2->MN1) and case 3 (MAG2->MAG1) from Section 3.2. Cases 1 (MN2->MAG1) is not possible because the assumption is that MN2 is at the home link supporting PMIPv6 service, i.e. the MN2 does not have a CoA to register with the CN. In the following analysis, cases 2 and 3 are investigated together because the only difference is which entity (MN1 or MAG1) performs the CN role regarding RO functionality. Therefore, below CN is indicated as MN1/MAG1. Velev & Weniger Expires August 28, 2008 [Page 10] Internet-Draft PMIPv6-MIPv6 RO Issues February 2008 If the MN2 moves outside the PMIP domain to an AR of a MIPv6 domain, the MN2 performs MIPv6 registration with the HA/LMA. Since the MN2 is not aware about the proxy RO before the handover, it does not necessarily initiate registration of its CoA to MN1/MAG1. It depends on the MN2's MIPv6 implementation whether MIPv6 RO is performed. Furthermore, there would be some delay till the MIPv6 RO path is setup after the handover. The steps performed by the MAG2, after detection of MN2 detachment, depend on a potential PMIPv6 RO specification. If the MAG2 does not deregister the MN2 with the MN1/ MAG1, MN1/MAG1 continues to send packets to MAG2 and this could lead to packet loss. Therefore a potential PMIPv6 RO protocol shall take care of this situation. On the other hand, if a mechanism is available in MAG2 to deregister MN2 with MN1/MAG1, then the proxy RO path is terminated and data packets are routed via HA/LMA. The change of route optimized to non-optimized path would result in increased end-to-end delay and possibly to data packets lost due to transport layer time out. To avoid this situation, a future protocol mechanism should allow to keep the RO path between the MN2 and MN1 after the MN2 moves out of the PMIPv6 domain. The transition (b) from Figure 4 is observed hereby, where the MN2 is first attached to a MIPv6 domain and later moves to the home link that supports PMIPv6 service (home PMIPv6 domain). Case 1 (MN2->MAG1) from Section 3.2 is the only possible way of performing proxy RO before the handover. While attached to the MIPv6 domain, a proxy RO path between MN2 and MAG1 is set up, i.e. MN2 creates BCE in MAG1. When the MN2 moves to the home PMIPv6 domain, it performs the returning home procedure described in [RFC3775], i.e. sends deregistration BU messages to HA and all CNs, to which a MIPv6 RO has been set up. Thus, the MN2 deletes the BCE in MAG1 and MAG1 sends data packets to MN2's HoA, i.e. to HA/LMA. Such a scenario does not result in data packet loss, however, the MN-CN path after the handover is not optimized. In conclusion, the MN2's transition between PMIPv6 and MIPv6 mobility schemes results in issues that should be considered by a future protocol mechanisms. The transition from PMIPv6 to non-PMIPv6 domain may result in packet loss or affect the transport layer application due to increased end-to-end delay. 4.3.2. MN2 performs CN role The MIPv6 RO procedure [RFC3775] specifies the functionality of a CN, however, it does not consider mobile CN. In the following a mobile CN performing PMIPv6-MIPv6 transition in scenario C is analyzed in order to identify possible issues. In scenarios A and B the mobile CN does not change the mobility management scheme and therefore such an analysis is not needed. With respect to Figure 4, the assumption Velev & Weniger Expires August 28, 2008 [Page 11] Internet-Draft PMIPv6-MIPv6 RO Issues February 2008 now is that the MN's role is implemented in MN1 (respectively MAG1) and CN's role - in MN2 (respectively MAG2). In transition (a) the MN2 hands over from MAG2 to the AR. Before the handover, a proxy RO tunnel exists between MAG1 and MAG2. MN2 sends data packets to MN1's HoA, but the MAG2 tunnels the packets to MAG1. After the handover, the MN2 performs MIPv6 registration with HA and continues to send the data packets to MN1's HoA. The LMA forwards the data packets to the MAG1 and they are delivered to MN1. However, in the oposit direction (MN1->MN2) MAG1 would continue to keep the proxy RO path with MAG2, although MN2 is no longer attached to MAG2, which would result in packet loss. Such a situation should be considered by the potential to-be-standardized proxy RO specification. In transition (b), the MN2 hands over from AR to MAG2. Before the handover, MN2 uses MIPv6 bi-directional tunneling to the home network and a proxy RO tunnel has been set up between MAG1 and MN2. MN2 performs the role of CN, i.e. the proxy BCE in MN2 is created by MAG1. Since in Figure 4 the MN2's HA is co-located with MN1's LMA, the proxy RO tunnel does not bring any benefit for the data path. The proxy RO tunnel would be beneficial in case that LMA and HA are not co-located (similar to Figure 3). After the handover to MAG2, the MN2 keeps the proxy BCE, and thus, sends the packets to MN1's CoA (e.g. MAG1's IP address). The packets are encapsulated by MAG2 in a PMIPv6 tunnel to LMA, an thus, the MN1-MN2 path results in an usual non-optimized PMIP path. However, in the direction MN1->MN2 the proxy RO state state in MAG1 is still active. MAG1 continues to update the MN2's BCE because MAG1 does not learn about the MN2 movement. Such a situation is undesired and shall be handled by a to-be-standardized proxy RO procedure. To sum up the issues with mobile CN in scenario C, transition (a) may lead to a situation in which the entity performing the MN's role (MAG1) continues to perform proxy RO with the MAG2, although MN2 is no longer attached to MAG2. Transition (b) results in the non- optimal situation of tunneling data packets between MAG2 and LMA although a BCE exists in MN2 for optimal route to MN1. 5. Summary of the issues The analyses of the different scenarios of MIPv6-PMIPv6 interactions with respect to RO shows a couple of issues that should be considered during the design of to-be-standardized proxy RO procedure. This section summarizes the main points of the above analyses: o In scenarios where both end nodes are located in the same PMIP domain and at least one of the end nodes uses MIPv6 for global mobility (scenario A and B), MIPv6 RO procedure should be Velev & Weniger Expires August 28, 2008 [Page 12] Internet-Draft PMIPv6-MIPv6 RO Issues February 2008 performed in order to utilize a PMIPv6 RO tunnel. In some constellations (scenario B, proxy RO tunnel MN-MAG2), the set up of proxy RO tunnel does not lead to any improvement in the data path unless the end node that uses MIPv6 does not perform MIPv6 RO. o In scenarios where transition between MIPv6 and PMIPv6 occurs (Scenario C), depending on the constellation, PMIP RO states must be transfered (from MAG to MN or from MN to MAG) or updated when the transition occurs. o In some constellations (in scenario A) it may be advantageous for MAGs to know the CoA of the corresponding end nodes in order to set up a proxy RO tunnel in advance before the MIPv6 RO procedure is completed. 6. Security Considerations The current document analyzes scenarios and describes issues; it does not present new protocol design. Therefore this document does not introduce any security issues in addition to those described in [ID-PMIPv6] or [RFC3775]. 7. References 7.1. Normative References [ID-PMIPv6] Gundavelli, S., Ed., "Proxy Mobile IPv6", February 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. [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", May 2007. Velev & Weniger Expires August 28, 2008 [Page 13] Internet-Draft PMIPv6-MIPv6 RO Issues February 2008 7.2. Informative References [ID-MIP-PMIP] Giaretta, G., Ed., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", November 2007, . [PMIPv6-RO-IPv4] Jeong, S. and R. Wakikawa, "Route Optimization for Proxy Mobile IPv6", July 2007, . [PMIPv6-RO-ROA] Liebsch, M. and A. Abeille, "Route Optimization for Proxy Mobile IPv6", November 2007, . [PMIPv6-RO-RR] Sarikaya, B., Qin, A., Huang, A., and W. Wu, "PMIPv6 Route Optimization Protocol", November 2007, . [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. Authors' Addresses Genadi Velev Panasonic Monzastr. 4c Langen 63225 Gemany Phone: Email: genadi.velev@eu.panasonic.com Kilian Weniger Panasonic Monzastr. 4c Langen 63225 Gemany Phone: Email: kilian.weniger@eu.panasonic.com Velev & Weniger Expires August 28, 2008 [Page 14] Internet-Draft PMIPv6-MIPv6 RO Issues February 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). Velev & Weniger Expires August 28, 2008 [Page 15]