draft-ietf-netlmm-mip-interactions-04.txt   draft-ietf-netlmm-mip-interactions-05.txt 
NETLMM Working Group G. Giaretta, Ed. NETLMM Working Group G. Giaretta, Ed.
Internet-Draft Qualcomm Internet-Draft Qualcomm
Intended status: Informational June 1, 2009 Intended status: Informational April 30, 2010
Expires: December 3, 2009 Expires: November 1, 2010
Interactions between PMIPv6 and MIPv6: scenarios and related issues Interactions between PMIPv6 and MIPv6: scenarios and related issues
draft-ietf-netlmm-mip-interactions-04 draft-ietf-netlmm-mip-interactions-05
Abstract
The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the
same network requires some care. This document discusses scenarios
where such mixed usage is appropriate and points out the need for
interaction between the two mechanisms. Solutions and
recommendations to enable these scenarios are also described.
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].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 1, 2010.
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 December 3, 2009.
Abstract Copyright Notice
The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 Copyright (c) 2010 IETF Trust and the persons identified as the
(MIPv6) protocols are both deployed in a network require some document authors. All rights reserved.
analysis and considerations. This document describes all identified
possible scenarios, which require an interaction between PMIPv6 and
MIPv6 and discusses all issues related to these scenarios. Solutions
and recommendations to enable these scenarios are also described.
Requirements Language This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document may contain material from IETF Documents or IETF
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Contributions published or made publicly available before November
document are to be interpreted as described in RFC 2119 [RFC2119]. 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the scenarios and related issues . . . . . . . . . 4 3. Overview of the scenarios and related issues . . . . . . . . . 5
3.1. Issues related to scenario A . . . . . . . . . . . . . . . 9 3.1. Issues related to scenario A.1 . . . . . . . . . . . . . . 9
3.2. Issues related to scenario B . . . . . . . . . . . . . . . 9 3.2. Issues related to scenario A.2 . . . . . . . . . . . . . . 10
3.3. Issues related to scenario C . . . . . . . . . . . . . . . 10 3.3. Issues related to scenario B . . . . . . . . . . . . . . . 12
4. Analysis of possible solutions . . . . . . . . . . . . . . . . 12 4. Analysis of possible solutions . . . . . . . . . . . . . . . . 12
4.1. Solutions related to scenario A . . . . . . . . . . . . . 12 4.1. Solutions related to scenario A.1 . . . . . . . . . . . . 12
4.2. Solutions related to scenario B . . . . . . . . . . . . . 14 4.2. Solutions related to scenario A.2 . . . . . . . . . . . . 14
4.3. Solutions related to scenario C . . . . . . . . . . . . . 14 4.2.1. Mobility from a PMIPv6 domain to a non-PMIPv6
4.3.1. Mobility from a PMIPv6 domain to a non-PMIPv6
domain . . . . . . . . . . . . . . . . . . . . . . . . 15 domain . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.2. Mobility from a non-PMIPv6 domain to a PMIPv6 4.2.2. Mobility from a non-PMIPv6 domain to a PMIPv6
domain . . . . . . . . . . . . . . . . . . . . . . . . 16 domain . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Solutions related to scenario B . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 17 7. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
Proxy Mobile IPv6 [RFC5213] is a network based IP mobility protocol Proxy Mobile IPv6 [RFC5213] is a network based IP mobility protocol
standardized by IETF. In some deployment scenarios this protocol standardized by IETF. In some deployment scenarios this protocol
will be deployed together with MIPv6 [RFC3775], for example with will be deployed together with MIPv6 [RFC3775], for example with
PMIPv6 as local mobility protocol and MIPv6 as global mobility PMIPv6 as local mobility protocol and MIPv6 as global mobility
protocol. While the usage of a local mobility protocol should not protocol. While the usage of a local mobility protocol should not
have implications of how global mobility is managed, since PMIPv6 is have implications of how global mobility is managed, since PMIPv6 is
partially based on MIPv6 signaling and data structure, some partially based on MIPv6 signaling and data structure, some
considerations are needed to understand how the protocols interact considerations are needed to understand how the protocols interact
and how the different scenarios can be enabled. and how the different scenarios can be enabled.
Some SDOs are also investigating more complex scenarios where the Some standardization fora are also investigating more complex
mobility of some nodes is handled using Proxy Mobile IPv6, while scenarios where the mobility of some nodes is handled using Proxy
other nodes use Mobile IPv6; or the mobility of a node is managed in Mobile IPv6, while other nodes use Mobile IPv6; or the mobility of a
turn by a host-based and a network-based mechanism. This needs also node is managed in turn by a host-based and a network-based
to be analyzed as a possible deployment scenario. mechanism. This needs also to be analyzed as a possible deployment
scenario.
This document provides a taxonomy of all scenarios that require This document provides a taxonomy of the most common scenarios that
direct interaction between MIPv6 and PMIPv6. Moreover, this document require direct interaction between MIPv6 and PMIPv6. The list is not
presents and identifies all issues pertained to these scenarios and meant to be exhaustive. Moreover, this document presents and
discusses possible means and mechanisms that are recommended to identifies all issues pertained to these scenarios and discusses
enable them. 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 MN-HoA: the home address of a mobile node in a Proxy Mobile IPv6
domain. domain.
MN-HNP: the IPv6 prefix that is always present in the Router MN-HNP: the IPv6 prefix that is always present in the Router
skipping to change at page 4, line 15 skipping to change at page 5, line 15
3. Overview of the scenarios and related issues 3. Overview of the scenarios and related issues
Several scenarios can be identified where Mobile IPv6 and Proxy Several scenarios can be identified where Mobile IPv6 and Proxy
Mobile IPv6 are deployed in the same network. This document does not Mobile IPv6 are deployed in the same network. This document does not
only focus on scenarios where the two protocols are used by the same only focus on scenarios where the two protocols are used by the same
mobile node to manage local and global mobility, but it investigates mobile node to manage local and global mobility, but it investigates
also more complex scenarios where the protocols are more tightly also more complex scenarios where the protocols are more tightly
integrated or where there is a co-existence of nodes which do or do integrated or where there is a co-existence of nodes which do or do
not implement Mobile IPv6. not implement Mobile IPv6.
The following scenarios are identified: In particular the scenario space can be split into hierarchical
deployments and alternative deployments of Mobile IP and Proxy Mobile
IP. 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 mobile node.
o Scenario A - in this scenario Proxy Mobile IPv6 is used as a The following hierarchical scenarios are identified:
o Scenario A.1 - in this scenario Proxy Mobile IPv6 is used as a
network based local mobility management protocol whereas Mobile network based local mobility management protocol whereas Mobile
IPv6 is used as a global mobility management protocol. This IPv6 is used as a global mobility management protocol. This
interaction is very similar to the HMIPv6-MIPv6 interaction; interaction is very similar to the HMIPv6-MIPv6 interaction;
Mobile IPv6 is used to manage mobility among different access Mobile IPv6 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 Proxy Mobile IPv6. The address managed by PMIPv6 (i.e. the MN- by Proxy Mobile IPv6. The address managed by PMIPv6 (i.e. the MN-
HoA) is registered as Care-of Address by the MN at the HA. This HoA) is registered as Care-of Address by the MN at the HA. This
means that the HA has a binding cache entry for MIPv6-HoA that means that the HA has a binding cache entry for MIPv6-HoA that
points to the MN-HoA. points to the MN-HoA.
skipping to change at page 5, line 34 skipping to change at page 6, line 34
+-//--------\\+ +--------\\---+ +-//--------\\+ +--------\\---+
// \\ \\ // \\ \\
// \\ \\ // \\ \\
// \\ \\ // \\ \\
+----+ +----+ +----+ +----+ +----+ +----+
|MAG1| |MAG2| |MAG3| |MAG1| |MAG2| |MAG3|
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | |
[MN] [MN]
Figure 1 - Scenario A Figure 1 - Scenario A.1
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 as they don't support
Mobile IPv6. There may be a common mobility anchor that acts as
Mobile IPv6 Home Agent and Proxy Mobile IPv6 LMA, depending on the
type of the node as depicted in the figure. However, the LMA and
HA can be also separated and this has no impacts to the mobility
of the nodes.
+--------+
| 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 o Scenario A.2 - in this scenario the mobile node is moving across
different access networks, some of them supporting Proxy Mobile different access networks, some of them supporting Proxy Mobile
IPv6 and some others not supporting it. Therefore the mobile node IPv6 and some others not supporting it. Therefore the mobile node
is roaming from an access network where the mobility is managed is roaming from an access network where the mobility is managed
through a network-based solution to an access network where a through a network-based solution to an access network where a
host-based management (i.e. Mobile IPv6) is needed. This host-based management (i.e. Mobile IPv6) is needed. This
scenario may have different sub-scenarios depending on the scenario may have different sub-scenarios depending on the
relations between the Mobile IPv6 home network and the Proxy relations between the Mobile IPv6 home network and the Proxy
Mobile IPv6 domain. The following figure illustrates an example Mobile IPv6 domain. The following figure illustrates an example
of this scenario, where the MN is moving from an access network of this scenario, where the MN is moving from an access network
where PMIPv6 is supported (i.e. MAG functionality is supported) where PMIPv6 is supported (i.e. MAG functionality is supported)
to a network where PMIPv6 is not supported (i.e. MAG to a network where PMIPv6 is not supported (i.e. MAG
functionality is not supported by the AR). This implies that the functionality is not supported by the AR). This implies that the
home link of the MN is actually a PMIPv6 domain. In this case the home link of the MN is actually a PMIPv6 domain. In this case the
MIPv6-HoA is equal to the MN-HoA (i.e. the address managed by MIPv6-HoA is equal to the MN-HoA (i.e. the address managed by
PMIPv6). 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 C Figure 3 - Scenario A.2
In the above figure the non-PMIPv6 domain can actually be also a In the above figure the non-PMIPv6 domain can actually be also a
different PMIPv6 domain that handles a different MN_HoA. The different PMIPv6 domain that handles a different MN_HoA. The
following figure illustrates this sub-case: the MIPv6-HoA is equal following figure illustrates this sub-case: the MIPv6-HoA is equal
to the MN_HoA; however when the MN hands over to MAG3 it gets a to the MN_HoA; however when the MN hands over to MAG3 it gets a
different IP address (managed by LMA2 using PMIPv6) and registers different IP address (managed by LMA2 using PMIPv6) and registers
it as a MIPv6 CoA. 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 C with visited PMIPv6 domain Figure 4 - Scenario A.2 with visited PMIPv6 domain
The following alternative deployment has been identified:
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 as they don't support Mobile IPv6.
There may be a common mobility anchor that acts as Mobile IPv6 Home
Agent and Proxy Mobile IPv6 LMA, depending on the type of the node as
depicted in the figure. However, the LMA and HA can be also
separated and this has no impacts to the mobility of the nodes.
+--------+
| HA/LMA |
+--------+
+------+ +------+
| MAG1 | | MAG2 |
+------+ +------+
+-----------+
| IPv6 host | ----------------->
+-----------+ movement
+----------+
| MIPv6 MN | ----------------->
+----------+ movement
Figure 2 - 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 or scenario C. 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: [RFC3775], [RFC4877] and [RFC5213].
3.1. Issues related to scenario A 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 a 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 PMIPv6 specification the MAG
does not forward any packets sent by the MN until the PMIPv6 tunnel does not forward any packets sent by the MN until the PMIPv6 tunnel
is up, regardless the mechanism used for address allocation. 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 B 3.2. Issues related to scenario A.2
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 manage their own mobility to achieve better performance,
e.g. for inter-technology handovers. Obviously, nodes that do not
implement MIPv6 must rely on the network to manage their mobility:
therefore Proxy MIPv6 is used for those nodes.
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, 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 network prefix
(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
context transfer or via a policy store.
However, in case there are nodes that implement Mobile IPv6 and want
to use this protocol, the network must offer MIPv6 service to them.
In such case the MAG should not emulate the home link. Instead of
advertising the HNP, the MAG should advertise the topologically
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
MIPv6 Binding Update based on [RFC3775].
3.3. Issues related to scenario C
This section highlights some considerations that are applicable to This section highlights some considerations that are applicable to
scenario C where the LMA and HA are logically collocated and need to scenario A.2.
be evaluated when selecting the technical approach to be chosen.
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 [RFC3775] the lookup key in the Binding Cache is the
Home Address of the MN. In particular, based on the base Home Address of the MN. In particular, based on the base
specification [RFC3775], the MN does not include any specification [RFC3775], the MN does not include any
identifier, such as the MN-ID [RFC4283], in the Binding Update identifier, such as the MN-ID [RFC4283], in the Binding Update
message other than its Home Address. As described in message other than its Home Address. As described in
[RFC4877], the identifier of the MN is known by the Home Agent [RFC4877], the identifier of the MN is known by the Home Agent
after the IKEv2 exchange, but this is not used in the MIPv6 after the IKEv2 exchange, but this is not used in the MIPv6
skipping to change at page 10, line 36 skipping to change at page 10, line 35
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 Binding Cache
Entry containing the home prefix of the MN, but a new binding Entry containing the home prefix of the MN, but a new binding
cache entry is created. Therefore PMIPv6 and MIPv6 will cache entry is created. Therefore PMIPv6 and MIPv6 will
always create two different binding cache entries in the HA/ always create two different binding cache entries in the HA/
LMA which implies that the HA and LMA are logically separated. LMA which implies that the HA and LMA are logically separated.
How to handle the presence of the two binding cache entries How to handle the presence of the two binding cache entries
for the same MN is described in Section 4.3. 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 mobile node moves from a MIPv6 foreign network to the
PMIPv6 home domain, the MAG registers the mobile node at the PMIPv6 home domain, the MAG registers the mobile node at the
LMA by sending a Proxy Binding Update. Subsequently, the LMA LMA by sending a Proxy Binding Update. Subsequently, the LMA
updates the mobile node's binding cache entry with the MAG updates the mobile node's binding cache entry with the MAG
address and the MAG emulates the mobile node's home link. address and the MAG emulates the mobile node's home link.
Upon detection of the home link, the mobile node will send a Upon detection of the home link, the mobile node will send a
skipping to change at page 11, line 14 skipping to change at page 11, line 14
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 re-
ordering of registration messages and they are sent by 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 mobile node to the home agent are ordered by
the sequence numbers. The other side, in PMIP, Proxy Binding the sequence numbers. The other side, in PMIP, 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. . ordered by a timestamp option. When the mobile node moves
from one access where Mobile IP is used to another access when
4. Use of wrong home agent or LMA after handover Proxy Mobile IP is used, delay in the mobility signaling sent
may imply adverse situations. For example if the mobile node
* This issues can arise if multiple LMAs are deployed in the sends a Mobile IP binding update from access A before moving
PMIPv6 home domain. If the mobile node moves from a MIPv6 to access B and this binding update gets delayed (e.g. a
foreign network to the PMIPv6 home domain, the MAG must send refresh binding update), the binding update may reach the
the Proxy Binding Update to the particular LMA that is co- combined LMA/HA after the proxy binding update sent by the
located with the home agent which maintains the active binding MAG, re-directing packets to access A even after the mobile
cache entry of the mobile node. If a different LMA is has moved to access B.
assigned to the MAG, the mobile node will not be on the home
link but will still have an active MIPv6 binding cache entry
and this may be not desirable in some deployments..
* Similarly, if the mobile node moves from the PMIPv6 home
domain to a MIPv6 foreign network, the mobile node must send
the Binding Update to the particular home agent that is co-
located with the LMA which maintains the active proxy binding
cache entry of the mobile node. If the mobile node selects a
different home agent, packets addressed to the mobile node's
home address do not reach the mobile node.
5. Threat of compromised MAG 4. Threat of compromised MAG
* In MIPv6 base specification [RFC3775] there is a strong * In MIPv6 base specification [RFC3775] there is a strong
binding between the Home Address registered by the mobile node binding between the Home Address registered by the mobile node
and the Security Association used to modify the corresponding and the Security Association used to modify the corresponding
binding cache entry. binding cache entry.
* In PMIPv6 specification, the MAG sends proxy binding updates * In PMIPv6 specification, the MAG sends proxy binding updates
on behalf of a mobile node to update the binding cache entry on behalf of a mobile node to update the binding cache entry
that corresponds to the mobile node's home address. Since the that corresponds to the mobile node's home address. Since the
MAG sends the binding updates, PMIPv6 requires security MAG sends the binding updates, PMIPv6 requires security
skipping to change at page 12, line 13 skipping to change at page 12, line 5
manipulating LMA's routing table (or binging cache). manipulating LMA's routing table (or binging cache).
* In this mixed scenario, both host-based and network-based * In this mixed scenario, both host-based and network-based
security associations are used to update the same binding security associations are used to update the same binding
cache entry at the HA/LMA (but see the first bullet of this cache entry at the HA/LMA (but see the first bullet of this
list, as the entry may not be the same). Based on this list, as the entry may not be the same). Based on this
consideration, the threat described in [RFC4832] is worse as consideration, the threat described in [RFC4832] is worse as
it affects also hosts that are using the LMA/HA as MIPv6 HA it affects also hosts that are using the LMA/HA as MIPv6 HA
and are not using PMIPv6 and are not using PMIPv6
3.3. Issues related to scenario B
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 manage their own mobility to achieve better performance,
e.g. for inter-technology handovers. Obviously, nodes that do not
implement MIPv6 must rely on the network to manage their mobility:
therefore Proxy MIPv6 is used for those nodes.
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, 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 network prefix
(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
context transfer or via a policy store.
However, in case there are nodes that implement Mobile IPv6 and want
to use this protocol, the network must offer MIPv6 service to them.
In such case the MAG should not emulate the home link. Instead of
advertising the MN-HNP, the MAG should advertise the topologically
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
MIPv6 Binding Update based on [RFC3775].
4. Analysis of possible solutions 4. Analysis of possible solutions
4.1. Solutions related to scenario A 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 a mobile node is moving from
one PMIPv6 domain to another, based on the scenario of Figure 1. In one PMIPv6 domain to another, based on the scenario of Figure 1. In
Figure 5, the mobile node moves from an old MAG to MAG2 in the same Figure 5, the mobile node moves from an old MAG to MAG2 in the same
PMIPv6 domain: this movement triggers a PBU to LMA1 and the updating PMIPv6 domain: this movement triggers a PBU to LMA1 and the updating
of the binding cache at the LMA1; there is no MIPv6 signaling as the of the binding cache at the LMA1; there is no MIPv6 signaling as the
CoA_1 registered at the HA is the Home Address for the PMIPv6 CoA_1 registered at the HA is the Home Address for the PMIPv6
session. In Figure 6, the mobile node moves from MAG2 in the LMA1 session. In Figure 6, the mobile node moves from MAG2 in the LMA1
PMIPv6 domain to MAG3 in a different PMIPv6 domain: this triggers the PMIPv6 domain to MAG3 in a different PMIPv6 domain: this triggers the
PMIPv6 signaling and the creation of a binding at the LMA2. On the PMIPv6 signaling and the creation of a binding at the LMA2. On the
other hand, the local address of the mobile node is changed, as the other hand, the local address of the mobile node is changed, as the
LMA hss changed, and therefore the mobile node sends a MIPv6 Binding LMA has changed, and therefore the mobile node 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 |
| | | +-----------------+ | | | +-----------------+
skipping to change at page 14, line 5 skipping to change at page 14, line 5
| | | | | | | |
| | | +-----------------+ | | | +-----------------+
| | | | 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 B 4.2. Solutions related to scenario A.2
The solution for this scenario may depend on the access network being
able to determine that a particular mobile node wants to use Mobile
IPv6. This requires a solution at the system level for the access
network and is out of scope of this document. Solutions that do not
depend on the access network are out of the scope of this document.
4.3. Solutions related to scenario C
As described in Section 3.3, in this scenario the mobile node relies As described in Section 3.2, in this scenario the mobile node relies
on Proxy Mobile IPv6 as long as it is in the Proxy Mobile IPv6 on Proxy Mobile IPv6 as long as it is in the Proxy Mobile IPv6
domain. The mobile node then uses Mobile IPv6 whenever it moves out domain. The mobile node then uses Mobile IPv6 whenever it moves out
of the PMIPv6 domain which basically implies that the MIPv6 home link of the PMIPv6 domain which basically implies that the MIPv6 home link
is a PMIPv6 domain. is a PMIPv6 domain.
Analyzing the issues described in Section 3.3, 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
binding cache entry for the PMIPv6 registration and the MIPv6 binding cache entry for the PMIPv6 registration and the MIPv6
registration. The issue 1 on how the two protocols identify the registration. The issue 1 on how the two protocols identify the
binding cache entry is valid only in case we assume that a PMIPv6 binding cache entry is valid only in case we assume that a PMIPv6
message has any value for a MIPv6 BCE. Also the issues 2 and 3 are message has any value for a MIPv6 BCE. Also the issues 2 and 3 are
not applicable in case different logical BCEs are used by the LMA and not applicable in case different logical BCEs are used by the LMA and
the HA. For this reason, it is recommended that when the MIPv6 home the HA. For this reason, it is recommended that when the MIPv6 home
link is implemented as a PMIPv6 domain, the HA/LMA implementation link is implemented as a PMIPv6 domain, the HA/LMA implementation
treats the two protocol as independent. treats the two protocol as independent.
skipping to change at page 14, line 45 skipping to change at page 14, line 37
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 binding cache entry is created for a mobile node
which has previously created a MIPv6 BCE, the MIPv6 binding cache which has previously created a MIPv6 BCE, the MIPv6 binding cache
entry of the MN is not overwritten and a new PMIPv6 binding cache entry of the MN is not overwritten and a new PMIPv6 binding cache
entry 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 binding
cache entry and PMIPv6 binding cache entry exist are processed as cache entry and PMIPv6 binding cache entry exist are processed as
follows: follows:
o
1. The MIPv6 binding cache entry is processed first. If the 1. The MIPv6 binding cache entry is processed first. If the
destination address of the received downlink packet matches destination address of the received downlink packet matches
the the binding cache entry of the HA, the packet is forwarded the the binding cache entry of the HA, the packet is forwarded
by encapsulating it with the care-of-address contained in the by encapsulating it with the care-of-address contained 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 binding cache entry created by PMIPv6 is applied and the
packet are encapsualted to the registered MAG. packet are encapsualted 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 which will be followed by the mobile node and HA/LMA based on the
above principles. The analysis is performed in two different above principles. The analysis is performed in two different
subsections, depending if the mobile node moves from a PMIPv6 domain subsections, depending if the mobile node moves from a PMIPv6 domain
to a non-PMIPv6 domain or vice versa. to a non-PMIPv6 domain or vice versa.
4.3.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 mobile node is attached to a PMIPv6 domain and there
is a valid Proxy Binding Cache entry at the LMA. Then the mobile is a valid Proxy Binding Cache entry at the LMA. Then the mobile
node moves to a different access network and starts using MIPv6 (e.g. node moves to a different access network and starts using MIPv6 (e.g.
because PMIPv6 is not supported). The mobile node needs to bootstrap because PMIPv6 is not supported). The mobile node needs to bootstrap
MIPv6 parameters and send a MIPv6 Binding Update in order to have MIPv6 parameters and send a MIPv6 Binding Update in order to have
service continuity. Therefore the following steps must be performed service continuity. Therefore the following steps must be performed
by the UE: by the UE:
o HA/LMA address discovery: the mobile node needs to discover the IP o HA/LMA address discovery: the mobile node needs to discover the IP
address of the LMA which has a valid binding cache entry for its address of the LMA which has a valid binding cache entry for its
home network prefix. This is described in Section 3.3 as issue 4. home network prefix. This is described in Section 3.2 as issue 4.
o Security Association establishment: the mobile node needs to o Security Association establishment: the mobile node needs to
establish an IPsec Security Association with the HA/LMA as establish an IPsec Security 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 mobile node was using in the
PMIPv6 domain. PMIPv6 domain.
Since all these steps must be performed by the mobile node before Since all these steps must be performed by the mobile node before
sending the Binding Update, they have an impact on the handover sending the Binding Update, they have an impact on the handover
latency experienced by the MN. For this reason it is recommended latency experienced by the MN. For this reason it is recommended
that the mobile node establishes the IPsec security association (and that the mobile node establishes the IPsec security association (and
consequently is provided by the HA/LMA with a MIPv6-HoA) when it is consequently is provided by the HA/LMA with a MIPv6-HoA) when it is
still attached to the PMIPv6 domain. This implies that the mobile initialized. This implies that the mobile node has Mobile IPv6 stack
node has Mobile IPv6 stack active while in the PMIPv6 domain, but as active while in the PMIPv6 domain, but as long as it is attached to
long as it is attached to the same Proxy Mobile IPv6 domain, it will the same Proxy Mobile IPv6 domain, it will appear to the mobile node
appear to the mobile node as 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 security association with the HA/LMA, the
mobile node needs to discover the IP address of the LMA/HA while in mobile node needs to discover the IP address of the LMA/HA while in
the PMIPv6 domain. This can be done either based on DNS or based on the PMIPv6 domain. This can be done either based on DNS or based on
DHCPv6, as described in [RFC5026] and [boot-integrated]. The network DHCPv6, as described in [RFC5026] and [boot-integrated]. The network
should be configured so that the mobile node discovers or gets should be configured so that the mobile node discovers or gets
assigned the same HA/LMA that was serving as the LMA in the PMIPv6 assigned the same HA/LMA that was serving as the LMA in the PMIPv6
domain. Details of the exact procedure are out of scope of this domain. Details of the exact procedure are out of scope of this
document. document.
skipping to change at page 16, line 33 skipping to change at page 16, line 23
When the mobile node hands over to an access network which does not When the mobile node hands over to an access network which does not
support Proxy Mobile IPv6, it sends a Binding Update to the HA. The support Proxy Mobile IPv6, it sends a Binding Update to the HA. The
mobile node may set the R bit defined in NEMO specification (implicit mobile node may set the R bit defined in NEMO specification (implicit
mode) in order to indicate that the entire HNP is moved to the new mode) in order to indicate that the entire HNP is moved to the new
CoA. A MIPv6 binding cache entry is created irrespective of the CoA. A MIPv6 binding cache entry is created irrespective of the
existing PMIPv6 BCE. Packets matching the MIPv6 binding cache entry existing PMIPv6 BCE. Packets matching the MIPv6 binding cache entry
are sent to the CoA present in the MIPv6 BCE. The PMIPv6 binding 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. cache entry will expire in case the MAG does not send a refresh PBU.
4.3.2. Mobility from a non-PMIPv6 domain to a PMIPv6 domain 4.2.2. Mobility from a non-PMIPv6 domain to a PMIPv6 domain
In this section it is assumed that the mobile node is in a non-PMIPv6 In this section it is assumed that the mobile node is in a non-PMIPv6
access network and it has bootstrapped MIPv6 operations based on access network and it has bootstrapped MIPv6 operations based on
[RFC5026]; therefore there is valid binding cache for its MIPv6-HoA [RFC5026]; therefore there is valid binding cache for its MIPv6-HoA
(or HNP in case of NEMO) at the HA. Then the mobile node moves to a (or HNP in case of NEMO) at the HA. Then the mobile node moves to a
PMIPv6 domain which is configured to be the home link for the MIPv6- PMIPv6 domain which is configured to be the home link for the MIPv6-
HoA the mobile node has been assigned. HoA the mobile node 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
skipping to change at page 17, line 13 skipping to change at page 17, line 5
mobile node in order to select the correct HA/LMA. mobile node in order to select the 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 binding cache entry for the
mobile node which is independent of the MIPv6 BCE. Traffic destined mobile node which is independent of the MIPv6 BCE. Traffic destined
to the MIPv6-HoA (or to the HNP in case the mobile node had set the to the MIPv6-HoA (or to the HNP in case the mobile node had set the
flag R in the last BU) is still forwarded to the CoA present in the flag R in the last BU) is still forwarded to the CoA present in the
MIPv6 BCE. When the mobile node wants to use the HoA directly from MIPv6 BCE. When the mobile node wants to use the HoA directly from
the home link, it sends a de-registration message and at that point the home link, it sends a de-registration message and at that point
only the PMIPv6 binding cache entry is present. only the PMIPv6 binding cache entry is present.
4.3. Solutions related to scenario B
The solution for this scenario depends on the access network being
able to determine that a particular mobile node wants to use Mobile
IPv6. This requires a solution at the system level for the access
network and is out of scope of this document.
5. Security Considerations 5. Security Considerations
Scenarios A and B described in Section 3 do not introduce any Scenarios A.1 and B described in Section 3 do not introduce any
security considerations in addition to those described in [pmipv6- security considerations in addition to those described in [pmipv6-
draft] or [RFC3775]. draft] or [RFC3775].
This document requires that the a home agent that also implements the This document requires that the a home agent that also implements the
PMIPv6 LMA functionality should allow both the mobile node and the PMIPv6 LMA functionality should allow both the mobile node and the
authorized MAGs to modify the binding cache entries for the mobile authorized MAGs to modify the binding cache entries for the mobile
node. Note that the compromised MAG threat described in [RFC4832] node. Note that the compromised MAG threat described in [RFC4832]
applies also here. applies also here.
6. IANA considerations 6. IANA considerations
skipping to change at page 20, line 4 skipping to change at line 756
[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
Full Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
 End of changes. 48 change blocks. 
209 lines changed or deleted 223 lines changed or added

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