draft-ietf-netlmm-mip-interactions-06.txt   rfc6612.txt 
NETLMM Working Group G. Giaretta, Ed. Internet Engineering Task Force (IETF) G. Giaretta, Ed.
Internet-Draft Qualcomm Request for Comments: 6612 Qualcomm
Intended status: Informational May 03, 2010 Category: Informational May 2012
Expires: November 4, 2010 ISSN: 2070-1721
Interactions between PMIPv6 and MIPv6: scenarios and related issues Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6):
draft-ietf-netlmm-mip-interactions-06 Scenarios and Related Issues
Abstract Abstract
The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the
same network requires some care. This document discusses scenarios same network requires some care. This document discusses scenarios
where such mixed usage is appropriate and points out the need for where such mixed usage is appropriate and points out the need for
interaction between the two mechanisms. Solutions and interaction between the two mechanisms. Solutions and
recommendations to enable these scenarios are also described. recommendations to enable these scenarios are also described.
Requirements Language Status of This Memo
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].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on November 4, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6612.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 19
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................3
3. Overview of the scenarios and related issues . . . . . . . . . 5 3. Overview of the Scenarios and Related Issues ....................4
3.1. Issues related to scenario A.1 . . . . . . . . . . . . . . 9 3.1. Issues Related to Scenario A.1 .............................8
3.2. Issues related to scenario A.2 . . . . . . . . . . . . . . 10 3.2. Issues Related to Scenario A.2 .............................8
3.3. Issues related to scenario B . . . . . . . . . . . . . . . 12 3.3. Issues Related to Scenario B ..............................10
4. Analysis of possible solutions . . . . . . . . . . . . . . . . 12 4. Analysis of Possible Solutions .................................11
4.1. Solutions related to scenario A.1 . . . . . . . . . . . . 12 4.1. Solutions Related to Scenario A.1 .........................11
4.2. Solutions related to scenario A.2 . . . . . . . . . . . . 14 4.2. Solutions Related to Scenario A.2 .........................13
4.2.1. Mobility from a PMIPv6 domain to a non-PMIPv6 4.2.1. Mobility from a PMIPv6 Domain to a
domain . . . . . . . . . . . . . . . . . . . . . . . . 15 Non-PMIPv6 Domain ..................................14
4.2.2. Mobility from a non-PMIPv6 domain to a PMIPv6 4.2.2. Mobility from a Non-PMIPv6 Domain to a
domain . . . . . . . . . . . . . . . . . . . . . . . . 16 PMIPv6 Domain ......................................15
4.3. Solutions related to scenario B . . . . . . . . . . . . . 17 4.3. Solutions Related to Scenario B ...........................15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations ........................................16
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Contributors ...................................................16
7. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements ...............................................16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. References .....................................................17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References ......................................17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.2. Informative References ....................................17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Proxy Mobile IPv6 [RFC5213] is a network based IP mobility protocol Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network-based IP mobility
standardized by IETF. In some deployment scenarios this protocol protocol standardized by the IETF. In some deployment scenarios,
will be deployed together with MIPv6 [RFC3775], for example with this protocol will be deployed together with Mobile IPv6 (MIPv6)
PMIPv6 as local mobility protocol and MIPv6 as global mobility [RFC6275], for example, with PMIPv6 as local mobility protocol and
protocol. While the usage of a local mobility protocol should not MIPv6 as global mobility protocol. While the usage of a local
have implications of how global mobility is managed, since PMIPv6 is mobility protocol should not have implications on how global mobility
partially based on MIPv6 signaling and data structure, some is managed, since PMIPv6 is partially based on MIPv6 signaling and
considerations are needed to understand how the protocols interact data structure, some considerations are needed to understand how the
and how the different scenarios can be enabled. protocols interact and how the different scenarios can be enabled.
Some standardization fora are also investigating more complex Some standardization fora are also investigating more complex
scenarios where the mobility of some nodes is handled using Proxy scenarios where the mobility of some nodes is handled using Proxy
Mobile IPv6, while other nodes use Mobile IPv6; or the mobility of a Mobile IPv6, while other nodes use Mobile IPv6; or the mobility of a
node is managed in turn by a host-based and a network-based node is managed in turn by a host-based and a network-based
mechanism. This needs also to be analyzed as a possible deployment mechanism. This also needs to be analyzed as a possible deployment
scenario. scenario.
This document provides a taxonomy of the most common scenarios that This document provides a taxonomy of the most common scenarios that
require direct interaction between MIPv6 and PMIPv6. The list is not require direct interaction between MIPv6 and PMIPv6. The list is not
meant to be exhaustive. Moreover, this document presents and meant to be exhaustive. Moreover, this document presents and
identifies all issues pertained to these scenarios and discusses identifies most of the issues pertaining to these scenarios and
possible means and mechanisms that are recommended to enable them. discusses possible means and mechanisms that are recommended to
enable them.
2. Terminology 2. Terminology
General mobility terminology can be found in [RFC3753]. The General mobility terminology can be found in [RFC3753]. The
following acronyms are used in this document: following acronyms are used in this document:
MN-HoA: the home address of a mobile node in a Proxy Mobile IPv6 o AR (Access Router): first hop router
domain.
MN-HNP: the IPv6 prefix that is always present in the Router o BCE (Binding Cache Entry): an entry of the MIPv6 or PMIPv6 binding
Advertisements that the mobile node receives when it is attached cache
to any of the access links in that Proxy Mobile IPv6 domain. MN-
HoA always belongs to this prefix.
MIPv6-HoA: the Home Address the MN includes in MIPv6 binding o LMA (Local Mobility Anchor): the PMIPv6 mobility anchor as
update messages. specified in [RFC5213]
MIPv6-CoA: the Care-of Address the MN includes in MIPv6 binding o MAG (Mobility Access Gateway): the PMIPv6 client as specified in
update messages. [RFC5213]
3. Overview of the scenarios and related issues o MN-HoA: the Home Address (HoA) of a Mobile Node (MN) in a PMIPv6
domain
Several scenarios can be identified where Mobile IPv6 and Proxy o MN-HNP: the IPv6 prefix that is always present in the Router
Mobile IPv6 are deployed in the same network. This document does not Advertisements that the MN receives when it is attached to any of
only focus on scenarios where the two protocols are used by the same the access links in that PMIPv6 domain (MN-HoA always belongs to
mobile node to manage local and global mobility, but it investigates this prefix.)
also more complex scenarios where the protocols are more tightly
integrated or where there is a co-existence of nodes which do or do
not implement Mobile IPv6.
In particular the scenario space can be split into hierarchical o MIPv6-HoA: the HoA the MN includes in MIPv6 Binding Update
deployments and alternative deployments of Mobile IP and Proxy Mobile messages
IP. Hierarchical deployments are scenarios where the two mobility
protocols are used in the same network in a hierarchical manner for o MIPv6-CoA: the Care-of Address the MN includes in MIPv6 Binding
global and local mobility management. Alternative deployments are Update messages
scenarios where only one of the two protocols is used for mobility
management of a given mobile node. 3. Overview of the Scenarios and Related Issues
Several scenarios can be identified where MIPv6 and PMIPv6 are
deployed in the same network. This document not only focuses on
scenarios where the two protocols are used by the same MN to manage
local and global mobility but also investigates more complex
scenarios where the protocols are more tightly integrated or where
there is a coexistence of nodes that do or do not implement MIPv6.
In particular, the scenario space can be split into hierarchical
deployments and alternative deployments of Mobile IP (MIP) and Proxy
Mobile IP (PMIP). Hierarchical deployments are scenarios where the
two mobility protocols are used in the same network in a hierarchical
manner for global and local mobility management. Alternative
deployments are scenarios where only one of the two protocols is used
for mobility management of a given MN.
The following hierarchical scenarios are identified: The following hierarchical scenarios are identified:
o Scenario A.1 - in this scenario Proxy Mobile IPv6 is used as a Scenario A.1: In this scenario, PMIPv6 is used as a network-based
network based local mobility management protocol whereas Mobile local mobility management protocol whereas MIPv6 is used as a global
IPv6 is used as a global mobility management protocol. This mobility management protocol. This interaction is very similar to
interaction is very similar to the HMIPv6-MIPv6 interaction; the interaction between Hierarchical Mobile IPv6 (HMIPv6) and MIPv6
Mobile IPv6 is used to manage mobility among different access [RFC5380]; MIPv6 is used to manage mobility among different access
networks, while the mobility within the access network is handled networks, while the mobility within the access network is handled by
by Proxy Mobile IPv6. The address managed by PMIPv6 (i.e. the MN- PMIPv6. The address managed by PMIPv6 (i.e., the MN-HoA) is
HoA) is registered as Care-of Address by the MN at the HA. This registered as the Care-of Address by the MN at the Home Agent (HA).
means that the HA has a binding cache entry for MIPv6-HoA that This means that the HA has a BCE for MIPv6-HoA that points to the
points to the MN-HoA. MN-HoA.
The following figure illustrates this scenario. The following figure illustrates this scenario.
+----+ +----+
| HA | MIPv6-HoA -> MN-HoA | HA | MIPv6-HoA -> MN-HoA
+----+ +----+
/\ /\
/ \ / \
+-------------/----\--------------+ +-------------/----\--------------+
( / \ ) Global Mobile IPv6 ( / \ ) Global Mobile IPv6
( / \ ) Domain ( / \ ) Domain
+----------/----------\-----------+ +----------/----------\-----------+
skipping to change at page 6, line 34 skipping to change at page 5, line 34
+-//--------\\+ +--------\\---+ +-//--------\\+ +--------\\---+
// \\ \\ // \\ \\
// \\ \\ // \\ \\
// \\ \\ // \\ \\
+----+ +----+ +----+ +----+ +----+ +----+
|MAG1| |MAG2| |MAG3| |MAG1| |MAG2| |MAG3|
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | |
[MN] [MN]
Figure 1 - Scenario A.1 Figure 1: Scenario A.1
o Scenario A.2 - in this scenario the mobile node is moving across Scenario A.2: In this scenario, the MN is moving across different
different access networks, some of them supporting Proxy Mobile access networks, some of them supporting PMIPv6 and some others not
IPv6 and some others not supporting it. Therefore the mobile node supporting it. Therefore, the MN is roaming from an access network
is roaming from an access network where the mobility is managed where the mobility is managed through a network-based solution to an
through a network-based solution to an access network where a access network where a host-based management (i.e., Mobile IPv6) is
host-based management (i.e. Mobile IPv6) is needed. This needed. This scenario may have different sub-scenarios depending on
scenario may have different sub-scenarios depending on the the relations between the MIPv6 home network and the PMIPv6 domain.
relations between the Mobile IPv6 home network and the Proxy The following figure illustrates an example of this scenario, where
Mobile IPv6 domain. The following figure illustrates an example the MN is moving from an access network where PMIPv6 is supported
of this scenario, where the MN is moving from an access network (i.e., MAG functionality is supported) to a network where PMIPv6 is
where PMIPv6 is supported (i.e. MAG functionality is supported) not supported (i.e., MAG functionality is not supported by the AR).
to a network where PMIPv6 is not supported (i.e. MAG This implies that the home link of the MN is actually a PMIPv6
functionality is not supported by the AR). This implies that the domain. In this case, the MIPv6-HoA is equal to the MN-HoA (i.e.,
home link of the MN is actually a PMIPv6 domain. In this case the the address managed by PMIPv6).
MIPv6-HoA is equal to the MN-HoA (i.e. the address managed by
PMIPv6).
MIPv6-HoA == MN-HoA -> MAG1 MIPv6-HoA == MN-HoA -> MAG1
+------+ +------+
|HA/LMA|-----------------------+ |HA/LMA|-----------------------+
+------+ | +------+ |
//\\ | //\\ |
+-------//--\\--------+ | +-------//--\\--------+ |
( // \\ PMIPv6 ) | ( // \\ PMIPv6 ) |
( // \\ domain) +--------------+ ( // \\ domain) +--------------+
+----//--------\\-----+ ( Non-PMIPv6 ) +----//--------\\-----+ ( Non-PMIPv6 )
// \\ ( domain ) // \\ ( domain )
// \\ +--------------+ // \\ +--------------+
// \\ | // \\ |
+----+ +----+ +----+ +----+ +----+ +----+
|MAG1| |MAG2| | AR | |MAG1| |MAG2| | AR |
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | |
[MN] [MN]
Figure 3 - Scenario A.2 Figure 2: Scenario A.2
In the above figure the non-PMIPv6 domain can actually be also a In the scenario illustrated in Figure 2, the non-PMIPv6 domain can
different PMIPv6 domain that handles a different MN_HoA. The actually also be a different PMIPv6 domain that handles a different
following figure illustrates this sub-case: the MIPv6-HoA is equal MN_HoA. The following figure illustrates this sub-case: the MIPv6-
to the MN_HoA; however when the MN hands over to MAG3 it gets a HoA is equal to the MN_HoA; however, when the MN hands over to MAG3,
different IP address (managed by LMA2 using PMIPv6) and registers it gets a different IP address (managed by LMA2 using PMIPv6) and
it as a MIPv6 CoA. registers it as a MIPv6 CoA.
MIPv6-HoA == MN-HoA -> MAG_1 MIPv6-HoA == MN-HoA -> MAG_1
+-------+ +-------+
|HA/LMA1|-----------------------+ |HA/LMA1|-----------------------+
+-------+ | +-------+ |
//\\ +----+ //\\ +----+
+-------//--\\--------+ |LMA2| +-------//--\\--------+ |LMA2|
( // \\ home ) +----+ ( // \\ home ) +----+
( // \\ PMIPv6) +------||------+ ( // \\ PMIPv6) +------||------+
( // \\domain) ( ||visited) ( // \\domain) ( ||visited)
+---//----------\\----+ ( ||PMIPv6 ) +---//----------\\----+ ( ||PMIPv6 )
// \\ ( ||domain ) // \\ ( ||domain )
// \\ +------||------+ // \\ +------||------+
+----+ +----+ +----+ +----+ +----+ +----+
|MAG1| |MAG2| |MAG3| |MAG1| |MAG2| |MAG3|
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | |
[MN] [MN]
(a) (a)
MIPv6-HoA -> MN_CoA MIPv6-HoA -> MN_CoA
+-------+ +-------+
|HA/LMA1|-----------------------+ |HA/LMA1|-----------------------+
+-------+ | +-------+ |
//\\ +----+ //\\ +----+
+-------//--\\--------+ |LMA2| MN_CoA -> MAG3 +-------//--\\--------+ |LMA2| MN_CoA -> MAG3
( // \\ home ) +----+ ( // \\ home ) +----+
( // \\ PMIPv6) +------||------+ ( // \\ PMIPv6) +------||------+
( // \\domain) ( ||visited) ( // \\domain) ( ||visited)
+---//----------\\----+ ( ||PMIPv6 ) +---//----------\\----+ ( ||PMIPv6 )
// \\ ( ||domain ) // \\ ( ||domain )
// \\ +------||------+ // \\ +------||------+
+----+ +----+ +----+ +----+ +----+ +----+
|MAG1| |MAG2| |MAG3| |MAG1| |MAG2| |MAG3|
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | |
[MN] [MN]
(b) (b)
Figure 4 - Scenario A.2 with visited PMIPv6 domain Figure 3: Scenario A.2 with Visited PMIPv6 Domain
The following alternative deployment has been identified: The following alternative deployment has been identified:
Scenario B - in this scenario some mobile nodes use Mobile IPv6 to Scenario B: In this scenario, some MNs use MIPv6 to manage their
manage their movements while others rely on a network-based mobility movements while others rely on a network-based mobility solution
solution provided by the network as they don't support Mobile IPv6. provided by the network as they don't support Mobile IPv6. There may
There may be a common mobility anchor that acts as Mobile IPv6 Home be a common mobility anchor that acts as MIPv6 Home Agent and PMIPv6
Agent and Proxy Mobile IPv6 LMA, depending on the type of the node as LMA, depending on the type of the node as depicted in the figure.
depicted in the figure. However, the LMA and HA can be also However, the LMA and HA can also be separated, and this has no impact
separated and this has no impacts to the mobility of the nodes. on the mobility of the nodes.
+--------+
+--------+ | HA/LMA |
| HA/LMA | +--------+
+--------+
+------+ +------+ +------+ +------+
| MAG1 | | MAG2 | | MAG1 | | MAG2 |
+------+ +------+ +------+ +------+
+-----------+ +-----------+
| IPv6 host | -----------------> | IPv6 host | ----------------->
+-----------+ movement +-----------+ movement
+----------+ +----------+
| MIPv6 MN | -----------------> | MIPv6 MN | ----------------->
+----------+ movement +----------+ movement
Figure 2 - Scenario B Figure 4: Scenario B
Note that some of the scenarios can be combined. For instance, Note that some of the scenarios can be combined. For instance,
scenario B can be combined with scenario A.1 or scenario A.2. Scenario B can be combined with Scenario A.1 or Scenario A.2.
The following sections describe some possible issues for each The following sections describe some possible issues for each
scenario. Respective recommendations are described in Section 4.3. scenario. Respective recommendations are described in Section 4.3.
The specifications considered as a baseline for the analysis are the The specifications considered as a baseline for the analysis are the
following: [RFC3775], [RFC4877] and [RFC5213]. following: [RFC6275], [RFC4877], and [RFC5213].
3.1. Issues related to scenario A.1 3.1. Issues Related to Scenario A.1
This scenario is very similar to other hierarchical mobility schemes, This scenario is very similar to other hierarchical mobility schemes,
including a HMIPv6-MIPv6 scheme. No issues have been identified in including an HMIPv6-MIPv6 scheme. No issues have been identified in
this scenario. Note that a race condition where the MN registers the this scenario. Note that a race condition where the MN registers the
CoA at the HA before the CoA is actually bound to the MAG at the LMA CoA at the HA before the CoA is actually bound to the MAG at the LMA
is not possible. The reason is that per PMIPv6 specification the MAG is not possible. The reason is that per the PMIPv6 specification
does not forward any packets sent by the MN until the PMIPv6 tunnel [RFC5213], the MAG does not forward any packets sent by the MN until
is up, regardless the mechanism used for address allocation. the PMIPv6 tunnel is up, regardless the mechanism used for address
allocation.
Section 4.1 describes one message flow in case PMIPv6 is used as a Section 4.1 describes one message flow in case PMIPv6 is used as a
local mobility protocol and MIPv6 is used as a global mobility local mobility protocol and MIPv6 is used as a global mobility
protocol. protocol.
3.2. Issues related to scenario A.2 3.2. Issues Related to Scenario A.2
This section highlights some considerations that are applicable to This section highlights some considerations that are applicable to
scenario A.2. scenario A.2.
1. HoA management and lookup key in the binding cache 1. HoA management and lookup key in the binding cache
* In MIPv6 [RFC3775] the lookup key in the Binding Cache is the * In MIPv6 [RFC6275], the lookup key in the binding cache is the
Home Address of the MN. In particular, based on the base HoA of the MN. In particular, the base specification
specification [RFC3775], the MN does not include any [RFC6275] doesn't require the MN to include any identifier,
identifier, such as the MN-ID [RFC4283], in the Binding Update such as the MN-ID [RFC4283], in the Binding Update message
message other than its Home Address. As described in other than its HoA. As described in [RFC4877], the identifier
[RFC4877], the identifier of the MN is known by the Home Agent of the MN is known by the Home Agent after the Internet Key
after the IKEv2 exchange, but this is not used in the MIPv6 Exchange Protocol (IKEv2) exchange, but this is not used in
signaling, nor as a lookup key for the binding cache. On the the MIPv6 signaling or as a lookup key for the binding cache.
other hand, as specified in [RFC5213], a Proxy Binding Update On the other hand, as specified in [RFC5213], a Proxy Binding
contains the Home Prefix of the MN, the MN-ID and does not Update contains the home prefix of the MN, the MN-ID and does
include the Home Address of the MN (since it may not be known not include the HoA of the MN (since it may not be known by
by the MAG and consequently by the HA/LMA). The lookup key in 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 the binding cache of the LMA is either the home prefix or the
MN-ID. This implies that lookup keys for MIPv6 and PMIPv6 MN-ID. This implies that lookup keys for MIPv6 and PMIPv6
registrations are different. Because of that, when the MN registrations are different. Because of that, when the MN
moves from its home network (i.e. from the PMIPv6 domain) to moves from its home network (i.e., from the PMIPv6 domain) to
the foreign link, the Binding Update sent by the MN is not the foreign link, the Binding Update sent by the MN is not
identified by the HA as an update of the Proxy Binding Cache identified by the HA as an update of the Proxy BCE containing
Entry containing the home prefix of the MN, but a new binding the home prefix of the MN, but a new binding cache entry is
cache entry is created. Therefore PMIPv6 and MIPv6 will created. Therefore, PMIPv6 and MIPv6 will always create two
always create two different binding cache entries in the HA/ different BCEs in the HA/LMA, which implies that the HA and
LMA which implies that the HA and LMA are logically separated. LMA are logically separated. How to handle the presence of
How to handle the presence of the two binding cache entries the two BCEs for the same MN is described in Section 4.2.
for the same MN is described in Section 4.2.
2. MIPv6 de-registration Binding Update deletes PMIPv6 binding cache 2. MIPv6 de-registration Binding Update deletes PMIPv6 binding cache
entry entry
* When the mobile node moves from a MIPv6 foreign network to the * When the MN moves from a MIPv6 foreign network to the PMIPv6
PMIPv6 home domain, the MAG registers the mobile node at the home domain, the MAG registers the MN at the LMA by sending a
LMA by sending a Proxy Binding Update. Subsequently, the LMA Proxy Binding Update. Subsequently, the LMA updates the MN's
updates the mobile node's binding cache entry with the MAG BCE with the MAG address and the MAG emulates the MN's home
address and the MAG emulates the mobile node's home link. link. Upon detection of the home link, the MN will send a
Upon detection of the home link, the mobile node will send a
de-registration Binding Update to its home agent. It is de-registration Binding Update to its home agent. It is
necessary to make sure that the de-registration of the MIPv6 necessary to make sure that the de-registration of the MIPv6
BU does not change the PMIPv6 binding cache entry just created Binding Update does not change the PMIPv6 BCE just created by
by the MAG. the MAG.
3. Race condition between Binding Update and Proxy Binding Update 3. Race condition between Binding Update and Proxy Binding Update
messages (Sequence Numbers and Timestamps) messages (Sequence Numbers and Timestamps)
* MIPv6 and PMIPv6 use different mechanisms for handling re- * MIPv6 and PMIPv6 use different mechanisms for handling
ordering of registration messages and they are sent by re-ordering of registration messages and they are sent by
different entities. In MIPv6, Binding Update messages that different entities. In MIPv6, Binding Update messages that
are sent by the mobile node to the home agent are ordered by are sent by the MN to the home agent are ordered by the
the sequence numbers. The other side, in PMIP, Proxy Binding sequence numbers. The other side, in PMIPv6, Proxy Binding
Update messages that are sent by the MAG to the LMA are Update messages that are sent by the MAG to the LMA are
ordered by a timestamp option. When the mobile node moves ordered by a timestamp option. When the MN moves from one
from one access where Mobile IP is used to another access when access where Mobile IP is used to another access when Proxy
Proxy Mobile IP is used, delay in the mobility signaling sent Mobile IP is used, delay in the mobility signaling sent may
may imply adverse situations. For example if the mobile node imply adverse situations. For example, if the MN sends a
sends a Mobile IP binding update from access A before moving Mobile IP Binding Update from access A before moving to access
to access B and this binding update gets delayed (e.g. a B and this Binding Update gets delayed (e.g., a refresh
refresh binding update), the binding update may reach the Binding Update), the Binding Update may reach the combined
combined LMA/HA after the proxy binding update sent by the LMA/HA after the Proxy Binding Update sent by the MAG,
MAG, re-directing packets to access A even after the mobile re-directing packets to access A even after the MN has moved
has moved to access B. to access B.
4. Threat of compromised MAG 4. Threat of compromised MAG
* In MIPv6 base specification [RFC3775] there is a strong * In the MIPv6 base specification [RFC6275], there is a strong
binding between the Home Address registered by the mobile node binding between the HoA registered by the MN and the Security
and the Security Association used to modify the corresponding Association (SA) used to modify the corresponding BCE.
binding cache entry.
* In PMIPv6 specification, the MAG sends proxy binding updates * In the PMIPv6 specification [RFC5213], the MAG sends Proxy
on behalf of a mobile node to update the binding cache entry Binding Updates on behalf of a MN to update the BCE that
that corresponds to the mobile node's home address. Since the corresponds to the MN's HoA. Since the MAG sends the Binding
MAG sends the binding updates, PMIPv6 requires security Updates, PMIPv6 requires SAs between each MAG and the LMA.
associations between each MAG and the LMA.
* As described in [RFC4832], in PMIPv6 the MAG compromise or * As described in [RFC4832], in PMIPv6, MAG compromise or
impersonation is an issue. RFC4832, section 2.2, describes impersonation is an issue. [RFC4832], Section 2.2, describes
how a compromised MAG can harm the functionality of LMA, e.g. how a compromised MAG can harm the functionality of an LMA,
manipulating LMA's routing table (or binging cache). e.g., manipulating the LMA's routing table (or binding cache).
* In this mixed scenario, both host-based and network-based * In this mixed scenario, both host-based and network-based SAs
security associations are used to update the same binding are used to update the same binding cache entry at the HA/LMA
cache entry at the HA/LMA (but see the first bullet of this (but see the first bullet of this list, as the entry may not
list, as the entry may not be the same). Based on this be the same). Based on this consideration, the threat
consideration, the threat described in [RFC4832] is worse as described in [RFC4832] is worse as it also affects hosts that
it affects also hosts that are using the LMA/HA as MIPv6 HA are using the LMA/HA as MIPv6 HA and not using PMIPv6.
and are not using PMIPv6
3.3. Issues related to scenario B 3.3. Issues Related to Scenario B
In this scenario there are two types of nodes in the access 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 some nodes support MIPv6 while some others do not. The rationale
rationale behind such a scenario is that the nodes implementing behind such a scenario is that the nodes implementing MIPv6 manage
Mobile IPv6 manage their own mobility to achieve better performance, their own mobility to achieve better performance, e.g., for inter-
e.g. for inter-technology handovers. Obviously, nodes that do not technology handovers. Obviously, nodes that do not implement MIPv6
implement MIPv6 must rely on the network to manage their mobility: must rely on the network to manage their mobility; therefore, Proxy
therefore Proxy MIPv6 is used for those nodes. MIPv6 is used for those nodes.
Based on the current PMIPv6 solution described in [RFC5213], in any Based on the current PMIPv6 solution described in [RFC5213], in any
link of the PMIPv6 domain the MAG emulates the mobile node's home link of the PMIPv6 domain, the MAG emulates the MN's home link,
link, advertising the home link prefix to the MN in a unicast Router advertising the home link prefix to the MN in a unicast Router
Advertisement message. This ensures that the IP address of the MN is Advertisement message. This ensures that the IP address of the MN is
still considered valid by the MN itself. The home network prefix still considered valid by the MN itself. The home network prefix
(and any other information needed to emulate the home link) is (and any other information needed to emulate the home link) is
included in the mobile node's profile that is obtained by the MAG via included in the MN's profile that is obtained by the MAG via context
context transfer or via a policy store. transfer or via a policy store.
However, in case there are nodes that implement Mobile IPv6 and want However, in case there are nodes that implement MIPv6 and want to use
to use this protocol, the network must offer MIPv6 service to them. this protocol, the network must offer MIPv6 service to them. In such
In such case the MAG should not emulate the home link. Instead of a case, the MAG should not emulate the home link. Instead of
advertising the MN-HNP, the MAG should advertise the topologically advertising the MN-HNP, the MAG should advertise the topologically
correct local IP prefix, i.e. the prefix belonging to the MAG, so correct local IP prefix, i.e., the prefix belonging to the MAG, so
that the MN detects an IP movement, configures a new CoA and sends a that the MN detects an IP movement, configures a new CoA, and sends a
MIPv6 Binding Update based on [RFC3775]. MIPv6 Binding Update based on [RFC6275].
4. Analysis of possible solutions 4. Analysis of Possible Solutions
4.1. Solutions related to scenario A.1 4.1. Solutions Related to Scenario A.1
As mentioned in Section 3.1, there are no significant issues in this As mentioned in Section 3.1, there are no significant issues in this
scenario. scenario.
Figures 5 and 6 show a scenario where a mobile node is moving from Figures 5 and 6 show a scenario where an MN is moving from one PMIPv6
one PMIPv6 domain to another, based on the scenario of Figure 1. In domain to another, based on the scenario of Figure 1. In Figure 5,
Figure 5, the mobile node moves from an old MAG to MAG2 in the same the MN moves from an old MAG to MAG2 in the same PMIPv6 domain: this
PMIPv6 domain: this movement triggers a PBU to LMA1 and the updating movement triggers a PBU to LMA1 and the updating of the binding cache
of the binding cache at the LMA1; there is no MIPv6 signaling as the at the LMA1. There is no MIPv6 signaling as the CoA_1 registered at
CoA_1 registered at the HA is the Home Address for the PMIPv6 the HA is the HoA for the PMIPv6 session. In Figure 6, the MN moves
session. In Figure 6, the mobile node moves from MAG2 in the LMA1 from MAG2 in the LMA1 PMIPv6 domain to MAG3 in a different PMIPv6
PMIPv6 domain to MAG3 in a different PMIPv6 domain: this triggers the domain: this triggers the PMIPv6 signaling and the creation of a
PMIPv6 signaling and the creation of a binding at the LMA2. On the binding at the LMA2. On the other hand, the local address of the
other hand, the local address of the mobile node is changed, as the mobile node is changed, as the LMA has changed; therefore, the MN
LMA has changed, and therefore the mobile node sends a MIPv6 Binding sends a MIPv6 Binding Update to the HA with the new CoA_2.
Update to the HA with the new CoA_2.
+----+ +------+ +------+ +----+ +----+ +------+ +------+ +----+
| MN | | MAG2 | | LMA1 | | HA | | MN | | MAG2 | | LMA1 | | HA |
+----+ +------+ +------+ +----+ +----+ +------+ +------+ +----+
| | | | | | | |
| | | +-----------------+ | | | +-----------------+
| | | | HoA -> CoA_1 | | | | | HoA -> CoA_1 |
| | | | binding present | | | | | binding present |
| | | +-----------------+ | | | +-----------------+
| | | | | | | |
| CoA conf/confirm | PBU(CoA_1,MAG_2) | | | CoA conf/confirm | PBU(CoA_1,MAG_2) | |
| <--------------->| ----------------->| | | <--------------->| ----------------->| |
| | +-----------------+| | | +-----------------+|
| | | CoA_1 -> MAG_2 || | | | CoA_1 -> MAG_2 ||
| | | binding updated || | | | binding updated ||
| | +-----------------+| | | +-----------------+|
| | PBA | | | | PBA | |
| | <----------------| | | | <----------------| |
| | | | | | | |
Figure 5 - Local Mobility Message Flow Figure 5: Local Mobility Message Flow
+----+ +------+ +------+ +----+ +----+ +------+ +------+ +----+
| MN | | MAG3 | | LMA2 | | HA | | MN | | MAG3 | | LMA2 | | HA |
+----+ +------+ +------+ +----+ +----+ +------+ +------+ +----+
| CoA config | PBU(CoA_2,MAG_3) | | | CoA config | PBU(CoA_2,MAG_3) | |
|<---------------->|------------------->| | |<---------------->|------------------->| |
| | +-----------------+ | | | +-----------------+ |
| | | CoA_2 -> MAG_3 | | | | | CoA_2 -> MAG_3 | |
| | | binding created | | | | | binding created | |
skipping to change at page 13, line 49 skipping to change at page 12, line 49
| | BU (HoA, CoA_2) | | | | BU (HoA, CoA_2) | |
|---------------------------------------------------->| |---------------------------------------------------->|
| | | | | | | |
| | | +-----------------+ | | | +-----------------+
| | | | HoA -> CoA_2 | | | | | HoA -> CoA_2 |
| | | | binding updated | | | | | binding updated |
| | | +-----------------+ | | | +-----------------+
| | BA | | | | BA | |
|<----------------------------------------------------| |<----------------------------------------------------|
Figure 6 - Global Mobility Message Flow Figure 6: Global Mobility Message Flow
4.2. Solutions related to scenario A.2 4.2. Solutions Related to Scenario A.2
As described in Section 3.2, in this scenario the mobile node relies As described in Section 3.2, in this scenario, the MN relies on
on Proxy Mobile IPv6 as long as it is in the Proxy Mobile IPv6 PMIPv6 as long as it is in the PMIPv6 domain. The MN then uses MIPv6
domain. The mobile node then uses Mobile IPv6 whenever it moves out whenever it moves out of the PMIPv6 domain, which basically implies
of the PMIPv6 domain which basically implies that the MIPv6 home link that the MIPv6 home link is a PMIPv6 domain.
is a PMIPv6 domain.
Analyzing the issues described in Section 3.2, it is clear that most Analyzing the issues described in Section 3.2, it is clear that most
of them are applicable only to the case where there is a common of them are applicable only to the case where there is a common BCE
binding cache entry for the PMIPv6 registration and the MIPv6 for the PMIPv6 registration and the MIPv6 registration. Issue 1, on
registration. The issue 1 on how the two protocols identify the how the two protocols identify the BCE, is valid only in the case in
binding cache entry is valid only in case we assume that a PMIPv6 which we assume that a PMIPv6 message has any value for a MIPv6 BCE.
message has any value for a MIPv6 BCE. Also the issues 2 and 3 are Also, Issues 2 and 3 are not applicable in the case in which
not applicable in case different logical BCEs are used by the LMA and different logical BCEs are used by the LMA and the HA. For this
the HA. For this reason, it is recommended that when the MIPv6 home reason, it is recommended that when the MIPv6 home link is
link is implemented as a PMIPv6 domain, the HA/LMA implementation implemented as a PMIPv6 domain, the HA/LMA implementation treat the
treats the two protocol as independent. two protocols as independent.
More in details the following principles should be followed by the In more detail, the following principles should be followed by the
HA/LMA implementation: HA/LMA implementation:
o PMIPv6 signaling does not overwrite any MIPv6 BCE. In particular, o PMIPv6 signaling does not overwrite any MIPv6 BCE. In particular,
when a PMIPv6 binding cache entry is created for a mobile node when a PMIPv6 BCE is created for an MN that has previously created
which has previously created a MIPv6 BCE, the MIPv6 binding cache a MIPv6 BCE, the MIPv6 BCE of the MN is not overwritten, and a new
entry of the MN is not overwritten and a new PMIPv6 binding cache PMIPv6 BCE is created.
entry is created.
o The downlink packets in the case where both the MIPv6 binding o The downlink packets in the case where both the MIPv6 BCE and
cache entry and PMIPv6 binding cache entry exist are processed as PMIPv6 BCE exist are processed as follows:
follows:
1. The MIPv6 binding cache entry is processed first. If the 1. The MIPv6 BCE is processed first. If the destination address
destination address of the received downlink packet matches of the received downlink packet matches the BCE of the HA, the
the the binding cache entry of the HA, the packet is forwarded packet is forwarded by encapsulating it with the CoA contained
by encapsulating it with the care-of-address contained in the in the BCE.
BCE.
2. If the destination address does not match the MIPv6 BCE, the 2. If the destination address does not match the MIPv6 BCE, the
binding cache entry created by PMIPv6 is applied and the BCE created by PMIPv6 is applied, and the packets are
packet are encapsualted to the registered MAG. encapsulated to the registered MAG.
The following subsections provide a description of the procedures The following subsections provide a description of the procedures
which will be followed by the mobile node and HA/LMA based on the that will be followed by the MN and HA/LMA based on the above
above principles. The analysis is performed in two different principles. The analysis is performed in two different subsections,
subsections, depending if the mobile node moves from a PMIPv6 domain depending on whether the MN moves from a PMIPv6 domain to a non-
to a non-PMIPv6 domain or vice versa. PMIPv6 domain or vice versa.
4.2.1. Mobility from a PMIPv6 domain to a non-PMIPv6 domain 4.2.1. Mobility from a PMIPv6 Domain to a Non-PMIPv6 Domain
Let's assume the mobile node is attached to a PMIPv6 domain and there Let's assume the MN is attached to a PMIPv6 domain and there is a
is a valid Proxy Binding Cache entry at the LMA. Then the mobile valid Proxy BCE at the LMA. Then, the MN moves to a different access
node moves to a different access network and starts using MIPv6 (e.g. network and starts using MIPv6 (e.g., because PMIPv6 is not
because PMIPv6 is not supported). The mobile node needs to bootstrap supported). The MN needs to bootstrap MIPv6 parameters and send a
MIPv6 parameters and send a MIPv6 Binding Update in order to have MIPv6 Binding Update in order to have service continuity. Therefore,
service continuity. Therefore the following steps must be performed the following steps must be performed by the User Equipment (UE):
by the UE:
o HA/LMA address discovery: the mobile node needs to discover the IP o HA/LMA address discovery: the MN needs to discover the IP address
address of the LMA which has a valid binding cache entry for its of the LMA that has a valid BCE for its home network prefix. This
home network prefix. This is described in Section 3.2 as issue 4. is described in Section 3.2 as Issue 4.
o Security Association establishment: the mobile node needs to o SA establishment: the MN needs to establish an IPsec Security
establish an IPsec Security Association with the HA/LMA as Association with the HA/LMA as described in [RFC4877].
described in [RFC4877]
o HoA or home network prefix assignment: as part of the MIPv6 o HoA or home network prefix assignment: as part of the MIPv6
bootstrapping procedure the HA assigns a MIPv6 HoA to the MN. bootstrapping procedure, the HA assigns a MIPv6 HoA to the MN.
This address must be the same the mobile node was using in the This address must be the same the MN was using in the PMIPv6
PMIPv6 domain. domain.
Since all these steps must be performed by the mobile node before Since all these steps must be performed by the MN before sending the
sending the Binding Update, they have an impact on the handover Binding Update, they have an impact on the handover latency
latency experienced by the MN. For this reason it is recommended experienced by the MN. For this reason, it is recommended that the
that the mobile node establishes the IPsec security association (and MN establish the IPsec SA (and, consequently, be provided by the HA/
consequently is provided by the HA/LMA with a MIPv6-HoA) when it is LMA with a MIPv6-HoA) when it is initialized. This implies that the
initialized. This implies that the mobile node has Mobile IPv6 stack MN has MIPv6 stack active while in the PMIPv6 domain, but as long as
active while in the PMIPv6 domain, but as long as it is attached to it is attached to the same PMIPv6 domain, it will appear to the MN as
the same Proxy Mobile IPv6 domain, it will appear to the mobile node if it is attached to the home link.
as if it is attached to the home link.
In order to establish the security association with the HA/LMA, the In order to establish the SA with the HA/LMA, the MN needs to
mobile node needs to discover the IP address of the LMA/HA while in discover the IP address of the LMA/HA while in the PMIPv6 domain.
the PMIPv6 domain. This can be done either based on DNS or based on This can be done either based on DNS or based on DHCPv6, as described
DHCPv6, as described in [RFC5026] and [boot-integrated]. The network in [RFC5026] and [RFC6611]. The network should be configured so that
should be configured so that the mobile node discovers or gets the MN discovers or gets assigned the same HA/LMA that was serving as
assigned the same HA/LMA that was serving as the LMA in the PMIPv6 the LMA in the PMIPv6 domain. Details of the exact procedure are out
domain. Details of the exact procedure are out of scope of this of scope of this document.
document.
When the mobile node establishes the security association, it When the MN establishes the SA, it acquires an HoA based on
acquires a home address based on [RFC5026]. However, based on PMIPv6 [RFC5026]. However, based on PMIPv6 operations, the LMA knows only
operations, the LMA knows only the Home Network Prefix used by the the home network prefix used by the MN and does not know the MN-HoA.
mobile node and does not know the MN-HoA.For this reason, the mobile For this reason, the MN must be configured to propose the MN-HoA as
node must be configured to propose MN-HoA as the home address in the the HoA in the IKEv2 INTERNAL_IP6_ADDRESS attribute during the IKEv2
IKEv2 INTERNAL_IP6_ADDRESS attribute during the IKEv2 exchange with exchange with the HA/LMA. Alternatively, the HA/LMA can be
the HA/LMA. Alternatively the HA/LMA can be configured to provide configured to provide the entire home network prefix via the
the entire Home Network Prefix via the MIP6_HOME_LINK attribute to MIP6_HOME_LINK attribute to the MN as specified in [RFC5026]; based
the mobile node as specified in [RFC5026]; based on this Home Network on this home network prefix, the MN can configure an HoA. Note that
Prefix the mobile node can configure a home address. Note that the the SA must be bound to the MN-HoA used in the PMIPv6 domain as per
security association must be bound to the MN-HoA used in the PMIPv6
domain as per [RFC4877]. Note that the home network prefix is shared
between the LMA and HA and this implies that there is an interaction
between the LMA and the HA in order to assign a common home network
prefix when triggered by PMIPv6 and MIPv6 signaling
When the mobile node hands over to an access network which does not [RFC4877]. Note that the home network prefix is shared between the
support Proxy Mobile IPv6, it sends a Binding Update to the HA. The LMA and HA, and this implies that there is an interaction between the
mobile node may set the R bit defined in NEMO specification (implicit LMA and the HA in order to assign a common home network prefix when
mode) in order to indicate that the entire HNP is moved to the new triggered by PMIPv6 and MIPv6 signaling.
CoA. A MIPv6 binding cache entry is created irrespective of the
existing PMIPv6 BCE. Packets matching the MIPv6 binding cache entry
are sent to the CoA present in the MIPv6 BCE. The PMIPv6 binding
cache entry will expire in case the MAG does not send a refresh PBU.
4.2.2. Mobility from a non-PMIPv6 domain to a PMIPv6 domain When the MN hands over to an access network that does not support
Proxy Mobile IPv6, it sends a Binding Update to the HA. The MN may
set the R bit defined in the Network Mobility (NEMO) specification
(implicit mode) [RFC3963] in order to indicate that the entire HNP is
moved to the new CoA. A MIPv6 BCE is created irrespective of the
existing PMIPv6 BCE. Packets matching the MIPv6 BCE are sent to the
CoA present in the MIPv6 BCE. The PMIPv6 BCE will expire in the case
in which the MAG does not send a refresh PBU.
In this section it is assumed that the mobile node is in a non-PMIPv6 4.2.2. Mobility from a Non-PMIPv6 Domain to a PMIPv6 Domain
access network and it has bootstrapped MIPv6 operations based on
[RFC5026]; therefore there is valid binding cache for its MIPv6-HoA In this section, it is assumed that the MN is in a non-PMIPv6 access
(or HNP in case of NEMO) at the HA. Then the mobile node moves to a network, and it has bootstrapped MIPv6 operations based on [RFC5026];
PMIPv6 domain which is configured to be the home link for the MIPv6- therefore, there is valid binding cache for its MIPv6-HoA (or HNP in
HoA the mobile node has been assigned. case of NEMO) at the HA. Then, the MN moves to a PMIPv6 domain that
is configured to be the home link for the MIPv6-HoA the MN has been
assigned.
In order to provide session continuity, the MAG needs to send a PBU In order to provide session continuity, the MAG needs to send a PBU
to the HA/LMA that was serving the MN. The MAG needs to discover the to the HA/LMA that was serving the MN. The MAG needs to discover the
HA/LMA; however the current version of [RFC5213] assumes that the LMA HA/LMA; however, [RFC5213] assumes that the LMA is assigned to the
is assigned to the MAG or discovered by the MAG when the mobile node MAG or discovered by the MAG when the MN attaches to the MAG. The
attaches to the MAG. the exact mechanism is not specified in exact mechanism is not specified in [RFC5213]. A detailed
[RFC5213]. A detailed description of the necessary procedure is out description of the necessary procedure is out of the scope of this
of the scope of this document. Note that the MAG may also rely on document. Note that the MAG may also rely on static configuration or
static configuration or lower layer information provided by the lower-layer information provided by the MN in order to select the
mobile node in order to select the correct HA/LMA. correct HA/LMA.
The PBU sent by the MAG creates a PMIPv6 binding cache entry for the The PBU sent by the MAG creates a PMIPv6 BCE for the MN that is
mobile node which is independent of the MIPv6 BCE. Traffic destined independent of the MIPv6 BCE. Traffic destined to the MIPv6-HoA (or
to the MIPv6-HoA (or to the HNP in case the mobile node had set the to the HNP in case the MN had set the flag R in the last BU) is still
flag R in the last BU) is still forwarded to the CoA present in the forwarded to the CoA present in the MIPv6 BCE. When the MN wants to
MIPv6 BCE. When the mobile node wants to use the HoA directly from use the HoA directly from the home link, it sends a de-registration
the home link, it sends a de-registration message and at that point message and, at that point only, the PMIPv6 BCE is present.
only the PMIPv6 binding cache entry is present.
4.3. Solutions related to scenario B 4.3. Solutions Related to Scenario B
The solution for this scenario depends on the access network being The solution for this scenario depends on the access network being
able to determine that a particular mobile node wants to use Mobile able to determine that a particular MN wants to use Mobile IPv6.
IPv6. This requires a solution at the system level for the access This requires a solution at the system level for the access network
network and may require knowledge of the detailed configuration and and may require knowledge of the detailed configuration and software
software capabilities of every mobile node in the system. These capabilities of every MN in the system. These issues are out of the
issues are out of scope of this document scope of this document.
5. Security Considerations 5. Security Considerations
Scenarios A.1 and B described in Section 3 do not introduce any Scenario A.1 does not introduce any new security issues in addition
security considerations in addition to those described in [pmipv6- to those described in [RFC5213] or [RFC6275].
draft] or [RFC3775].
This document requires that the a home agent that also implements the
PMIPv6 LMA functionality should allow both the mobile node and the
authorized MAGs to modify the binding cache entries for the mobile
node. Note that the compromised MAG threat described in [RFC4832]
applies also here.
6. IANA considerations
This document has no IANA actions.
7. Additional Authors For Scenario A.2, this document requires that the a home agent that
also implements the PMIPv6 LMA functionality should allow both the MN
and the authorized MAGs to modify the BCEs for the MN. Note that the
compromised MAG threat described in [RFC4832] also applies here in a
more severe form as explained in Section 3.2. Scenario B relies on
the secure identification of MNs and their capabilities so that the
right service can be provided for the right MNs. For instance, a
malicious MN should not get the HoA of some other node assigned to
it, and a MN that desires to employ its own mobility management
should be able to do so. The ability to identify nodes is already a
requirement in [RFC5213], but Scenario B adds a requirement on
identification of node capabilities.
Chowdhury, Kuntal - kchowdhury@starentnetworks.com 6. Contributors
Hesham Soliman - Hesham@elevatemobile.com Kuntal Chowdhury - kuntal@hotmail.com
Vijay Devarapalli - vijay.devarapalli@azairenet.com Vijay Devarapalli - vijay.devarapalli@azairenet.com
Sri Gundavelli - sgundave@cisco.com Sri Gundavelli - sgundave@cisco.com
Kilian Weniger - Kilian.Weniger@googlemail.com Suresh Krishnan - suresh.krishnan@ericsson.com
Genadi Velev - Genadi.Velev@eu.panasonic.com
Ahmad Muhanna - amuhanna@nortel.com Ahmad Muhanna - amuhanna@nortel.com
Hesham Soliman - Hesham@elevatemobile.com
George Tsirtsis - tsirtsis@googlemail.com George Tsirtsis - tsirtsis@googlemail.com
Suresh Krishnan - suresh.krishnan@ericsson.com Genadi Velev - Genadi.Velev@eu.panasonic.com
8. Acknowledgements Kilian Weniger - Kilian.Weniger@googlemail.com
This document is a merge of four different Internet Drafts: 7. Acknowledgements
draft-weniger-netlmm-pmipv6-mipv6-issues-00,
draft-devarapalli-netlmm-pmipv6-mipv6-01, This document is a merge of four different documents: "Proxy Mobile
draft-tsirtsis-logically-separate-lmaha-01and IPv6 and Mobile IPv6 interworking issues" (April 2007), "Proxy Mobile
draft-giaretta-netlmm-mip-interactions-00. Thanks to the authors and IPv6 and Mobile IPv6 interworking" (April 2007), "Behavior of
editors of those drafts. Collocated HA/LMA" (October 2008), and "Interactions between PMIPv6
and MIPv6: scenarios and related issues" (November 2007). Thanks to
the authors and editors of those documents.
The authors would also like to thank Jonne Soininen and Vidya The authors would also like to thank Jonne Soininen and Vidya
Narayanan, NETLMM WG chairs, for their support. Narayanan, NETLMM WG chairs, for their support.
9. References 8. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 8.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
in IPv6", RFC 3775, June 2004. Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based [RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based
Localized Mobility Management (NETLMM)", April 2007. Localized Mobility Management (NETLMM)", RFC 4832,
April 2007.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", 2005. IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007. Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5213] Gundavelli, S., "Proxy Mobile IPv6", August 2008. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[boot-integrated] [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Chowdhury, K., Ed., "MIP6-bootstrapping for the Integrated Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Scenario", 2007. Management", RFC 5380, October 2008.
9.2. Informative References [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6611] Chowdhury, K., Ed. and A. Yegin, "Mobile IPv6 (MIPv6)
Bootstrapping for the Integrated Scenario", RFC 6611,
May 2012.
8.2. Informative References
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005. (MIPv6)", RFC 4283, November 2005.
Author's Address Author's Address
Gerardo Giaretta (editor) Gerardo Giaretta (editor)
Qualcomm Qualcomm
Email: gerardog@qualcomm.com EMail: gerardog@qualcomm.com
 End of changes. 105 change blocks. 
458 lines changed or deleted 453 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/