NETLMM Working Group H. Soliman Internet-Draft Elevate Technologies Intended status: Informational G. Giaretta, Ed. Expires: October 26, 2007 April 24, 2007 Interactions between PMIPv6 and MIPv6: scenarios and related issues draft-giaretta-netlmm-mip-interactions-00 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 October 26, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract There has been a lot of discussion and analysis of how Mobile IPv6 and Proxy Mobile IPv6 can interact. A deeper analysis on the possible scenarios and related issues is necessary in order to provide guidelines to PMIPv6 protocol specification. With this purpose in mind, this document describes all scenarios of possible interactions between Mobile IPv6 and Proxy Mobile IPv6 and discusses a list of issues related to the each scenario. Soliman & Giaretta Expires October 26, 2007 [Page 1]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of the scenarios . . . . . . . . . . . . . . . . . . 4 4. Scenarios and related issues . . . . . . . . . . . . . . . . . 7 4.1. Scenario A - Hierarchical Mobility . . . . . . . . . . . . 7 4.2. Scenario B - Two types of nodes in the network . . . . . . 11 4.3. Scenario C - Movements between PMIPv6-enable and non PMIPv6-enabled access networks . . . . . . . . . . . . . . 13 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Soliman & Giaretta Expires October 26, 2007 [Page 2]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 1. Introduction The NETLMM WG is chartered to standardize a network-based protocol for localized mobility management. The goals that must be fulfilled by the protocol design are listed in rfc4831. Proxy Mobile IPv6 has been designated as the network-based localized mobility management protocol that will be standardized by IETF. There are two main reasons why the interactions between Proxy Mobile IPv6 and Mobile IPv6 need to be studied. The first reason is that Mobile IPv6 is the main global mobility management protocol developed in IETF; it is therefore natural to investigate the details of a hierarchical mobility scheme where Proxy Mobile IPv6 is used for local mobility and Mobile IPv6 is used for global mobility. The second reason is that Mobile IPv6 has been chosen by the NETLMM WG mainly for reusability grounds: during the protocol selection decision, it has been stated that Mobile IPv6 HA implementation can be somehow re-used (with minimal modifications) to act as Proxy Mobile IPv6 Local Mobility Anchor. Moreover, based on these considerations, some SDOs are investigating complex scenarios where the mobility of some nodes are handled using Proxy Mobile IPv6, while other nodes manage their own movements using Mobile IPv6; or the mobility of a node is managed in turn by a host- based and a network-based mechanism. The main purpose of this document is to provide a taxonomy of the scenarios where Mobile IPv6 and Proxy Mobile IPv6 can be used together. Moreover the document will also identify the issues that may be present in those scenarios, identifying the requirements that Proxy Mobile IPv6 and/or Mobile IPv6 must fulfill in order to enable them. In this document we make the assumption that a node using Mobile IPv6 is compliant with the Mobile IPv6 base specification [RFC3775] [RFC3776] (i.e. extensions defined [RFC4283] [RFC4285] in are not used). Note that some issues identified in this document may be solved by existing internet drafts that provide PMIPv6 solutions. However, these issues are listed anyhow as the intent of this document is to list the issues that some scenarios may present without going into the details of the solution space. This document is organized as follows: Section 3 gives an overview of the scenarios, Section 4 describes in details the scenarios and list the issues that must be solved in order to enable those scenarios and Soliman & Giaretta Expires October 26, 2007 [Page 3]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 Section 5 provides some final considerations and some suggestions on the next steps in NETLMM WG. 2. Terminology General mobility terminology can be found in [RFC3753]. Other terms used in this document are defined as follows: o Local Mobility Anchor (LMA) Local Mobility Anchor is the home agent for the mobile node in the Proxy Mobile IPv6 domain. It is the topological anchor point for the mobile node's home prefix and is the entity that manages the mobile node's reachability state. o Mobile Access Gateway (MAG) Mobile Access Gateway (MAG) is the proxy mobility agent in the network which manages the mobility related signaling for a mobile node that is attached to its access link. It is the entity responsible for tracking the mobile node's attachment to the link and for signaling the mobile node's local mobility anchor. o Proxy Mobile IPv6 Domain (PMIPv6-Domain) It is a localized mobility management domain where the mobility management of a mobile node is handled using Proxy Mobile IPv6 protocol as defined in this specification. o Proxy Binding Update (PBU) A PMIPv6 Binding Update sent by the MAG to the LMA as specified in draft-ietf-netlmm-proxymip6-00. 3. Overview of the scenarios Several scenarios can be identified where Mobile IPv6 and Proxy Mobile IPv6 are used. This document will not focus only on scenarios where the two protocols are used by the same mobile node to manage local and global mobility, but it will also investigate also more complex scenarios where the protocols are used beyond their original scope or where some nodes implement Mobile IPv6 and others do not implement it. The following scenarios were identified: Soliman & Giaretta Expires October 26, 2007 [Page 4]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 o Scenario A - in this scenario Proxy Mobile IPv6 is used as a network based local mobility management protocol whereas Mobile IPv6 is used as a global mobility management protocol. This interaction is very similar to the HMIPv6-MIPv6 interaction; Mobile IPv6 is used to manage mobility among different access networks, while the mobility within the access network is handled by Proxy Mobile IPv6. The following figure illustrates this scenario. +----+ | HA | +----+ Access Net #1 Access Net #2 (PMIPv6 Domain #1) (PMIPv6 Domain #2) ________________ ________________ / \ / \ / +------+ \ / +------+ \ / | LMA1 | \ / | LMA2 | \ \ +------+ / \ +------+ / \ / \ / \________________/ \________________/ +----+ | MN | -----------------> +----+ movement Figure 1 - Scenario A o Scenario B - in this scenario some mobile nodes use Mobile IPv6 to manage their movements while others rely on a network-based mobility solution provided by the network. There is a common mobility anchor that acts as Mobile IPv6 Home Agent and Proxy Mobile IPv6 LMA, depending on the type of the node. Soliman & Giaretta Expires October 26, 2007 [Page 5]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 +--------+ | HA/LMA | +--------+ +------+ +------+ | MAG1 | | MAG2 | +------+ +------+ +-----------+ | IPv6 host | -----------------> +-----------+ movement +----------+ | MIPv6 MN | -----------------> +----------+ movement Figure 2 - Scenario B o Scenario C - in this scenario the mobile node is moving across different access networks, some of them supporting Proxy Mobile IPv6 and some others not supporting it. Therefore the mobile node is roaming from an access network where the mobility is managed through a network-based solution to an access network where a host-based management (i.e. Mobile IPv6) is needed. This scenario may have different sub-scenarios depending on the relations between the Mobile IPv6 home network and the Proxy Mobile IPv6 domain. The following figure illustrates an example of this scenario, where the MN is moving from an access network where PMIPv6 is supported (i.e. MAG functionality is supported) to a network where PMIPv6 is not supported (i.e. MAG functionality is not supported by the AR): more details are described in section Section 4. +--------+ | HA/LMA | +--------+ +-----+ +----+ | MAG | | AR | +-----+ +----+ +----------+ | MIPv6 MN | -----------------> +----------+ movement Figure 3 - Scenario C Soliman & Giaretta Expires October 26, 2007 [Page 6]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 4. Scenarios and related issues In this section a more comprehensive description of the identified scenarios is presented. Moreover, for each scenarios the possible issues are identified. Note that, as mentioned before, some of these issues may be already solved in any of the PMIPv6 related internet drafts; however, the intent of this document is just to highlight the possible issues related to the identified scenarios, without going into solution space (at least for now), in order to get a complete picture of the possible interactions between PMIPv6 and MIPv6 and to understand which functionalities are needed from a protocol perspective. 4.1. Scenario A - Hierarchical Mobility As described in Section 3, in this scenario PMIPv6 is used as a local mobility management protocol, while Mobile IPv6 is used to manage global mobility. This means that the address handled by PMIPv6 operations is the Care-of Address from a Mobile IPv6 perspective. Figure 4 shows the details of this scenario. In figure (a) the mobile node has a Home Address and a Care-of Address (CoA_1) and is registered at the HA based on [RFC3775]; therefore there is a MIPv6 tunnel between the HA and the MN. Since the MN is attached at MAG1, there is a PMIPv6 tunnel between the LMA1 and the MAG1: the address managed by this tunnel is the CoA_1 of the MN. +----+ | HA | HoA -> CoA_1 +----+ CoA_1 -> MAG_1 | +------+ . +------+ | LMA1 | | | LMA2 | +------+ . +------+ | | +------+ +------+ . | MAG1 | | MAG2 | | +------+ +------+ . ^ | | | v . +----+ | | MN | . +----+ | HoA & CoA_1 . | Soliman & Giaretta Expires October 26, 2007 [Page 7]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 . PMIPv6 Domain #1 | PMIPv6 Domain #2 (a) +----+ | HA | HoA -> CoA_1 +----+ CoA_1 -> MAG_2 | +------+ . +------+ | LMA1 | | | LMA2 | +------+ . +------+ | | +------+ +------+ . | MAG1 | | MAG2 | | +------+ +------+ . ^ | | | v . +----+ | | MN | . +----+ | HoA & CoA_1 . | . PMIPv6 Domain #1 | PMIPv6 Domain #2 (b) Figure 4 - Local Mobility with PMIPv6 Figure 4 (b) shows the MN attached at MAG2. After the MN has moved to MAG2 link, based on PMIPv6 protocol operations, MAG2 sends a Proxy Binding Update to the LMA1 containing its own address and the address of the MN (i.e. CoA_1). The result of this registration is that the PMIPv6 tunnel is switched from MAG1 to MAG2 and therefore a tunnel between LMA1 and MAG2 is created. Note that the MN has experienced a movement within the PMIPv6 Domain #1: this movement has not triggered any Mobile IPv6 operations, since the MN does not need to change its CoA_1 based on PMIPv6 operations. Soliman & Giaretta Expires October 26, 2007 [Page 8]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 Figure 5 shows a global mobility scenario: the MN is moving across different PMIPv6 domains: in the new link, belonging to PMIPv6 domain #2, the MN configures a new CoA (i.e. CoA_2) and sends a MIPv6 Binding Update to the HA, updating its binding cache entry. On the other hand, MAG3 sends a Proxy Binding Update to LMA2, creating a new PMIPv6 binding cache entry related to CoA_2. +----+ | HA | HoA -> CoA_2 +----+ | CoA_2 -> MAG_3 +------+ . +------+ | LMA1 | | | LMA2 | +------+ . +------+ | | +------+ +------+ . +------+ | MAG1 | | MAG2 | | | MAG3 | +------+ +------+ . +------+ | ^ | | . v | +----+ . | MN | | +----+ . HoA & CoA_2 | . PMIPv6 Domain #1 | PMIPv6 Domain #2 Figure 5 - Global Mobility with Mobile IPv6 This scenarios and the related sub-scenarios are very similar to any other hierarchical mobility scheme, including a HMIPv6-MIPv6 scheme. However, there are two main differences between the case when the local mobility is handled via a network-based scheme: o if a host-based protocol is used, such as HMIPv6 [RFC4140], smooth transition can be achieved when handing off between two different LMM domains as the MN may keep the binding at the old MAP, while creating a binding with the new MAP and configuring a new Regional CoA. In particular, the overlapping domains allow the MN to configure more than on RCoA and manage the tunnels between them, based on the mobility pattern and the MN's requirements. This is Soliman & Giaretta Expires October 26, 2007 [Page 9]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 surely more difficult if PMIPv6 is used, since when the MN gets a new address, it will swtch using that one (i.e. the usage of mutiple addresses in PMIPv6 seems more difficult than in a host- based mobility solution such as HMIPv6). o if a host-based protocol is used for local mobility, race conditions cannot occur since the MN sends the MIPv6 Binding Update only when the Regional Care-of Address has been confirmed by the local anchor (e.g. MAP). This should occur also in the case the local mobility is handled by the network: the CoA should be confirmed to the MN only after a correct binding at the local anchor (i.e. LMA) is created. However, since the address allocation to the MN is not fully in the scope of PMIPv6 (i.e. MN-AR interface is system-specific), it may occur that the MN registers the CoA at the HA before the CoA is actually bound to the location of the MN (i.e. MAG). This seems only an issue in principle and it should occur very rarely, though. The following figures describe the details of the message flows for local and global mobility in this hierarchical scheme. +----+ +------+ +------+ +----+ | MN | | MAG2 | | LMA1 | | HA | +----+ +------+ +------+ +----+ +-----------------+ | HoA -> CoA_1 | | binding present | +-----------------+ CoA config/confirm PBU(CoA_1,MAG_2) <----------------> ------------------> +-----------------+ | CoA_1 -> MAG_2 | | binding updated | +-----------------+ PBA <------------------ Figure 6 - Local Mobility Message Flow (see Figure 4b) Soliman & Giaretta Expires October 26, 2007 [Page 10]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 +----+ +------+ +------+ +----+ | MN | | MAG3 | | LMA2 | | HA | +----+ +------+ +------+ +----+ CoA config PBU(CoA_2,MAG_3) <----------------> ------------------> +-----------------+ | CoA_2 -> MAG_3 | | binding created | +-----------------+ PBA <------------------ BU (HoA, CoA_2) ----------------------------------------------------> +-----------------+ | HoA -> CoA_1 | | binding updated | +-----------------+ BA <---------------------------------------------------- Figure 7 - Global Mobility Message Flow (see Figure 5) Based on the message flows of Figure 6 and Figure 7 and on the analysis presented above, there is not any issue in this scenario. The only possible issue is the race condition mentioned earlier but we have already stated that such an event should not occur if the entry in the LMA is created before the local address is confirmed to the MN. 4.2. Scenario B - Two types of nodes in the network In this scenario there are two types of nodes in the access network: some nodes support Mobile IPv6 while some others do not. The rationale behind such a scenario is that the nodes implementing Mobile IPv6 may prefer to manage their own mobility leveraging a host-based paradigm, in order for example to exploit some advantages of Mobile IPv6 protocol (e.g. route optimization support, confidentiality support for data packets between MN and HA). Obviously, nodes that do not implement MIPv6 must rely on the network to manage their mobility: therefore Proxy MIPv6 is used for those nodes. The issues with this scenario are related to the design of the MN-AR interface, that is out of scope of current NETLMM WG charter (even Soliman & Giaretta Expires October 26, 2007 [Page 11]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 though there is an Informational RFC on this topic among the milestones). However, it is worth discussing the possible issues introduced by this scenario in order to understand whether they can be solved at system level or have any impact on the choices in the PMIPv6 protocol design. Based on the current PMIPv6 solution described in draft-ietf-netlmm-proxymip6-00, in any link of the PMIPv6 domain the MAG emulates the mobile node's home link, advertising the home link prefix to the MN in a unicast Router Advertisement message. This ensures that the IP address of the MN is still considered valid by the MN itself. The home link prefix information (and any other information needed to emulate the home link) are included in the mobile node's profile that is obtained by the MAG via context transfer or via a policy store. However, in case there are nodes that implement Mobile IPv6 and want to use this protocol to manage their movements, the MAG should not emulate the home link. Instead, a prefix specific of the access link should be advertised so that the MN detects an IP movement, configures a new CoA and sends a MIPv6 Binding Update based on [RFC3775]. Therefore the MAG should somehow know that a MN is using MIPv6 in order to send the correct Router Advertisement. A possible solution could be that this information is stored in the mobile node's profile; however, this approach is affected by some issues: o Mobile IPv6 support on the terminal may not be an information that is available in the mobile node profile. This is because MIPv6 may be an additional software on a terminal, that can be installed or activated at any time. Moreover, draft-ietf-netlmm-proxymip6-00 does not give enough information on what is the mobile node's profile and how is created (e.g. whether it is linked to the user's profile, whether it is created at the attach and how it is maintained). o this approach implies that the access network must have a new functionality, since the Access Router must check the mobile node's profile even if the MN is using Mobile IPv6. This does not follow the Mobile IPv6 assumption that the access network does not have any role in the procedures related to the change of the IP address. Moreover, if context transfer is used to make the MAG aware of the mobile node's profile, a context transfer may be needed also for Mobile IPv6 nodes, but it is unclear how this context transfer should be triggered and performed. Solutions at the system level may be possible: for example, in the Soliman & Giaretta Expires October 26, 2007 [Page 12]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 attach procedure to cellular networks, the mobile node usually exchanges a lot of information with the network about its capabilities and the support of Mobile IPv6 may be one of this information. However, even in this case, the issues mentioned above apply. Based on the considerations in this section, there is therefore a clear need to define some mechanisms in order to manage the co- existence of nodes that use Mobile IPv6 and nodes that rely on Proxy Mobile IPv6. 4.3. Scenario C - Movements between PMIPv6-enable and non PMIPv6- enabled access networks In this scenario the MN moves from one access network that supports Proxy MIPv6 to an access network that does not support PMIPv6. Therefore the mobility of the MN may be handled using Proxy MIPv6 in some access network, but must be also managed by Mobile IPv6 if the MN attaches to an access network that does not have any PMIPv6 functionality. Two different sub-cases can be identified in this scenario: o PMIPv6 is used to handle local mobility and the MN is moving from an access network that supports PMIPv6 to an access network that does not support PMIPv6, but the LMA is not co-located with the HA. This means that Proxy Mobile IPv6 handles the Care-of Address of the MN, and that Mobile IPv6 is always used by the MN, either the MN is in an access network that supports Mobile IPv6 or it is in an access network with no PMIPv6 support. This scenario is, as shown in the following figure, very similar to Scenario A and therefore does not imply any specific issue. Soliman & Giaretta Expires October 26, 2007 [Page 13]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 +----+ | HA | HoA -> CoA_1 +----+ CoA_1 (prefix) -> MAG_2 | +------+ . | LMA1 | | +------+ . | | +------+ +------+ . +----+ | MAG1 | | MAG2 | | | AR | +------+ +------+ . +----+ ^ | | | v . +----+ | | MN | . +----+ | HoA & CoA_1 . . PMIPv6 Domain | (a) Soliman & Giaretta Expires October 26, 2007 [Page 14]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 +----+ | HA | HoA -> CoA_2 +----+ | +------+ . | LMA1 | | +------+ . | | +------+ +------+ . +----+ | MAG1 | | MAG2 | | | AR | +------+ +------+ . +----+ | ^ | | . v | +----+ . | MN | | +----+ . HoA & CoA_2 | . PMIPv6 Domain | (b) Figure 8 - Mobility between a PMIPv6 domain and a non-PMIPv6 domain o the home subnet is a PMIPv6 domain and the MN moves from its home subnet to a different link. This is the scenario where the LMA is managing the same address managed by the HA; note that in this case PMIPv6 manages the Mobile IPv6 HoA. The following figure illustrates this scenario. Soliman & Giaretta Expires October 26, 2007 [Page 15]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 +--------+ | HA/LMA | HoA (Home Prefix) -> MAG_1 +--------+ | +------+ . +----+ | MAG1 | | | AR | +------+ . +----+ ^ | | | v . +----+ | | MN | . +----+ | HoA . | PMIPv6 Domain (emulated home link) (a) +--------+ | HA/LMA | HoA -> CoA_1 +--------+ | +------+ . +----+ | MAG1 | | | AR | +------+ . +----+ | ^ | | . v | +----+ . | MN | | +----+ . HoA & CoA_1 | PMIPv6 Domain (emulated home link) (b) Figure 9 - Mobility between a PMIPv6 domain and a non-PMIPv6 domain The scenario described in Figure 8 (a and b) is very similar to the Soliman & Giaretta Expires October 26, 2007 [Page 16]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 scenario A. This is because PMIPv6 is used to manage the CoA and has no visibility of the HoA. Note that this applies also if LMA and HA are co-located in the same box, as long as PMIPv6 is used only to manage the Care-of Address mobility. For this reason, in the rest of this sub-section we will concentrate on the scenario in Figure 9a and 9b. In Figure 9a, the mobility of the MN is managed by the network through Proxy Mobile IPv6: the node acting as LMA has a proxy binding cache entry with the tuple (Home Prefix, MAG_1, MN_ID). The Mobile Node is "at home" from a Mobile IPv6 perspective and therefore uses directly its Home Address for new and existing communications. In case the MN moves within the PMIPv6 domain, PMIPv6 is triggered, a new MAG registers the home prefix of the MN at the LMA and the MN's home prefix is advertised to the MN so that the HoA can still be considered valid. Note that this implies that the PMIPv6 domain coincides with the home network from a MIPv6 perspective: while the MN is roaming in the PMIPv6 domain, the MN can use the Home Address to exchange packets without any need of tunneling. Downlink packets are tunneled to the MAG, but tunnel over the wireless link is avoided in this way. In Figure 9b, the MN has moved to an access network that does not have any support for Proxy Mobile IPv6. In this case the MN receives a Router Advertisement message containing a different IPv6 prefix than its home prefix and therefore it detects a movement at the IP- layer level. Based on that, the MN configures a new CoA and sends a Binding Update to the HA (i.e. the LMA) with the couple (HoA, CoA). Several possible issues are present in this scenario (direction of movement from the PMIPv6 domain to the non-PMIPv6 access network): o HoA management and lookup key in the binding cache * in MIPv6 [RFC3775] the lookup key in the Binding Cache is the Home Address of the MN. In particular, based on the base specification [RFC3775], the MN does not include any identifier, such as the MN-ID [RFC4283], in the Binding Update message other than its Home Address. * as specified in draft-netlmm-pmip6 [], a Proxy Binding Update contains the Home Prefix of the MN, the MN-ID and may not include the Home Address of the MN (since it may not be known by the MAG and consequently by the HA/LMA). The lookup key in the binding cache of the LMA is either the home prefix or the MN-ID. Soliman & Giaretta Expires October 26, 2007 [Page 17]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 * this implies that lookup keys for MIPv6 and PMIPv6 registrations are different. Because of that, when the MN moves from its home network (i.e. from the PMIPv6 domain) to the foreign link, the Binding Update sent by the MN is not identified by the HA as an update of the Proxy Binding Cache Entry containing the home prefix of the MN, but a new binding cache entry is created. * based on above bullets, there is an "unused" (proxy) binding cache entry in the Binding Cache of the LMA/HA. Note that, if HA runs a longest-prefix-matching algorithm in order to tunnel downlink packets to the MN, packets destined to the HoA are anyway delivered correctly. o Sequence Numbers and Timestamps * in MIPv6 Sequence Numbers are used for message identification and replay protection. In the latest PMIPv6 draft [], timestamps are used instead since the new MAG may not know the Sequence Number used in the last PBU. * this implies that there are two different mechanisms for packet identification and replay protection; in the case of Figure 9b, the HA will receive a Binding Update from the MN that will modify a proxy binding cache entry that is identified by the timestamp. * a specification of how the HA/LMA behaves in this case and how it processes BUs/PBUs with different identification mechanisms seem needed. o Threat of compromised MAG * in MIPv6 base specification [RFC3775] there is a strong binding between the Home Address registered by the MN and the Security Association used to modify the corresponding binding cache entry. * in PMIPv6 specification different Security Associations are used to update the same entry related to a MN since a per-MAG Security Association model is adopted. * in this mixed scenario, both host-based and network-based security associations are used to update the same binding cache entry at the HA/LMA (but see the first bullet of this list, as the entry may not be the same). Soliman & Giaretta Expires October 26, 2007 [Page 18]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 * based on this consideration, a compromised MAG can send a bogus Proxy BU to the HA/LMA even when the Mobile Node is not in the PMIPv6 domain, since the MAG is in the MIPv6 "home" domain. This introduces third part traffic stealing and reflection attacks, effectively bypassing MIPv6 security. Those two attacks are not acceptable on the Internet and are avoided in MIPv6. * note that the same issue applies in a simple PMIPv6 scenario; however, in the mixed scenario described in Figure 8, this is not possible, since the MAG is managing only the CoA of the MN and not the HoA. Therefore, if PMIPv6 is used to handle the HoA mobility, the security of Mobile IPv6 is lowered to the PMIPv6 security. This is not true if PMIPv6 is used together with MIPv6 but only to handle the CoA. In case the MN is returning home (i.e.moving into the PMIPv6 domain), several other considerations apply: o HoA management and lookup key in the binding cache * in MIPv6 [RFC3775], de-registration is recommended (but not mandatory). This implies that the MN receives a Router Advertisement with the home prefix, starts using its HoA directly, without tunneling uplink packets but may not send a Binding Update to remove the binding cache entry related to the HoA. * based on the same considerations made in the previous case, the PBU sent by the MAG will not update the Binding Cache entry related to the HoA, but more probably will create a new proxy binding cache entry including the home prefix of the MN, the MN-ID and the MAG address. * this implies that, in case the MN does not send a de- registration binding update when returning home, the downlink packets may still be tunneled to the CoA and not to the MAG. o Race condition in the registration from MAG and de-registration of the MN * even though the MN sends a de-registration Binding Update, for example including a MN-ID in order that PBUs and BUs update the same binding cache entry (note however that this is not possible based on [RFC3775]), a race condition may happen if the de-registration BU sent from the MN is received by the HA after the PBU sent by the MAG. In this case the BU from the MN will delete the entry created/updated by the MAG and therefore Soliman & Giaretta Expires October 26, 2007 [Page 19]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 downlink packets will not be correctly routed to the MN. o Sequence Numbers and Timestamps * the same considerations done for the handover from the PMIPv6 domain to the non-PMIPv6 access network applies also in this direction. As a general issue, this scenario contradicts with the scope of PMIPV6. The NETLMM WG is chartered to produce a protocol to handle network-based local mobility management. In the context of MIPv6, the main distinction between a local mobility management protocol and a global one is that former manages the changes in a CoA within a local domain and the latter manages the changes in the CoA globally. While the protocol itself may allow both types of mobility management with minimal change, there is a significant difference in terms of the security requirements, stability of an address and the relevant policies associated with such identifier. A change in the context of the protocol would result in subtle violations of these issues, which can introduce significant security issues that do not exist in MIPv6. 5. Conclusion The analysis provided in this document shows that PMIPv6 can be used for local mobility management when MIPv6 is used to handle global mobility. No significant issues have been identified for such a scenario. Note that this is the main scenario the NETLMM WG was chartered for rfc4830. Some issues have been identified in the two other scenarios considered. Concerning scenario B (contemporary co-existence of MIPv6 and non-MIPv6 nodes), a method to allow MIPv6 nodes to use host-based mobility is needed: this implies that within a PMIPv6 domain the MAG must be able to emulate the home network for some nodes and advertise link-specific prefixes for other nodes. Concerning scenario C, several issues have been identified, related to possible race conditions, the way the binding cache entries are identified at the HA and security threats. It seems that the implementation of this scenario requires some additional capabilities from the MN, that cannot implement only MIPv6 base specification [RFC3775]. 6. IANA Considerations This document makes no request of IANA. Soliman & Giaretta Expires October 26, 2007 [Page 20]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 7. Security Considerations The co-existence between PMIPv6 and MIPv6 is possible in some scenarios. Essentially, such co-existence is seamless when PMIPv6 is restricted to the mobility management of the CoA. However, the use of PMIPv6 for managing the home address introduces a number of security issues. Mobile IPv6 assumes a particular trust relationship between the MN and the HoA. For instance, a MN does not do a CoA test when registering its home address. The assumption here is that the HoA can trace a MN if it's reported as "misbehaving" (e.g. if it floods other nodes by registering a fake CoA). The same assumption is not necessarily true for every local HA/MAP/LMA that a mobile node happens to be associated with. Therefore, if an LMA is passed the MN's HoA to emulate a home link for a roaming node, there is a subtle violation of the security assumptions. A more significant violation of security policy can occur if a MAG is compromised while managing the mobility of the home address. A compromised MAG can launch off-path attacks to steal or redirect the mobile node's traffic. This situation is not possible in MIPv6 unless an attacker can break the IPsec SA between the MN and the HA, which is an unlikely scenario. Hence, changing the end points for the signalling, while almost seamless to the actual protocol, can cause significant unintended consequences. For this reason, and others, it is strongly recommended that PMIPv6 is only used to manage a local address and limit any potential attacks to the scope of the local domain. 8. Acknowledgements The authors would like to thank Vidya Narayanan, Patrick Stupar and Stefano Faccin for their valuable comments. 9. References 9.1. Normative References [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. Soliman & Giaretta Expires October 26, 2007 [Page 21]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 [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. 9.2. Informative References [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005. [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006. Authors' Addresses Hesham Soliman Elevate Technologies Email: Hesham@elevatemobile.com Gerardo Giaretta (editor) Email: gerardo.giaretta@gmail.com Soliman & Giaretta Expires October 26, 2007 [Page 22]
Internet-Draft PMIPv6-MIPv6 Interactions April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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). Soliman & Giaretta Expires October 26, 2007 [Page 23]