< draft-ietf-netlmm-mip-interactions-06.txt   draft-ietf-netlmm-mip-interactions-07.txt >
NETLMM Working Group G. Giaretta, Ed. NETLMM Working Group G. Giaretta, Ed.
Internet-Draft Qualcomm Internet-Draft Qualcomm
Intended status: Informational May 03, 2010 Intended status: Informational October 28, 2010
Expires: November 4, 2010 Expires: May 1, 2011
Interactions between PMIPv6 and MIPv6: scenarios and related issues Interactions between PMIPv6 and MIPv6: scenarios and related issues
draft-ietf-netlmm-mip-interactions-06 draft-ietf-netlmm-mip-interactions-07
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 Requirements Language
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on November 4, 2010. This Internet-Draft will expire on May 1, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 3, line 11 skipping to change at page 3, line 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the scenarios and related issues . . . . . . . . . 5 3. Overview of the scenarios and related issues . . . . . . . . . 5
3.1. Issues related to scenario A.1 . . . . . . . . . . . . . . 9 3.1. Issues related to scenario A.1 . . . . . . . . . . . . . . 9
3.2. Issues related to scenario A.2 . . . . . . . . . . . . . . 10 3.2. Issues related to scenario A.2 . . . . . . . . . . . . . . 9
3.3. Issues related to scenario B . . . . . . . . . . . . . . . 12 3.3. Issues related to scenario B . . . . . . . . . . . . . . . 11
4. Analysis of possible solutions . . . . . . . . . . . . . . . . 12 4. Analysis of possible solutions . . . . . . . . . . . . . . . . 12
4.1. Solutions related to scenario A.1 . . . . . . . . . . . . 12 4.1. Solutions related to scenario A.1 . . . . . . . . . . . . 12
4.2. Solutions related to scenario A.2 . . . . . . . . . . . . 14 4.2. Solutions related to scenario A.2 . . . . . . . . . . . . 14
4.2.1. Mobility from a PMIPv6 domain to a non-PMIPv6 4.2.1. Mobility from a PMIPv6 domain to a non-PMIPv6
domain . . . . . . . . . . . . . . . . . . . . . . . . 15 domain . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.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 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 . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 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 IETF. In some deployment scenarios this
will be deployed together with MIPv6 [RFC3775], for example with protocol will be deployed together with Mobile IPv6 (MIPv6)
PMIPv6 as local mobility protocol and MIPv6 as global mobility [RFC3775], 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 of 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 needs also 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 pertained 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
Cache.
o LMA (Local Mobility Anchor): the PMIPv6 mobility anchor as
specified in [RFC5213]
o MAG (Mobility Access Gateway): the PMIPv6 client as specified in
[RFC5213]
o MN-HoA: the home address of a mobile node in a PMIPv6 domain.
o MN-HNP: the IPv6 prefix that is always present in the Router
Advertisements that the mobile node receives when it is attached Advertisements that the mobile node receives when it is attached
to any of the access links in that Proxy Mobile IPv6 domain. MN- to any of the access links in that PMIPv6 domain. MN-HoA always
HoA always belongs to this prefix. belongs to this prefix.
MIPv6-HoA: the Home Address the MN includes in MIPv6 binding o MIPv6-HoA: the Home Address the MN includes in MIPv6 binding
update messages. update messages.
MIPv6-CoA: the Care-of Address the MN includes in MIPv6 binding o MIPv6-CoA: the Care-of Address the MN includes in MIPv6 binding
update messages. update messages.
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 MIPv6 and PMIPv6 are
Mobile IPv6 are deployed in the same network. This document does not deployed in the same network. This document not only focuses on
only focus on scenarios where the two protocols are used by the same scenarios where the two protocols are used by the same mobile node to
mobile node to manage local and global mobility, but it investigates manage local and global mobility, but also investigates more complex
also more complex scenarios where the protocols are more tightly scenarios where the protocols are more tightly integrated or where
integrated or where there is a co-existence of nodes which do or do there is a co-existence of nodes which do or do not implement MIPv6.
not implement Mobile IPv6.
In particular the scenario space can be split into hierarchical In particular the scenario space can be split into hierarchical
deployments and alternative deployments of Mobile IP and Proxy Mobile deployments and alternative deployments of Mobile IP (MIP) and Proxy
IP. Hierarchical deployments are scenarios where the two mobility Mobile IP (PMIP). Hierarchical deployments are scenarios where the
protocols are used in the same network in a hierarchical manner for two mobility protocols are used in the same network in a hierarchical
global and local mobility management. Alternative deployments are manner for global and local mobility management. Alternative
scenarios where only one of the two protocols is used for mobility deployments are scenarios where only one of the two protocols is used
management of a given mobile node. for mobility management of a given mobile node.
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 HMIPv6-MIPv6 interaction [RFC4140]; MIPv6 is used to manage
Mobile IPv6 is used to manage mobility among different access mobility among different access networks, while the mobility within
networks, while the mobility within the access network is handled the access network is handled by PMIPv6. The address managed by
by Proxy Mobile IPv6. The address managed by PMIPv6 (i.e. the MN- PMIPv6 (i.e. the MN-HoA) is registered as Care-of Address by the MN
HoA) is registered as Care-of Address by the MN at the HA. This at the HA. This means that the HA has a binding cache entry for
means that the HA has a binding cache entry for MIPv6-HoA that MIPv6-HoA that points to the MN-HoA.
points to the 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 36 skipping to change at page 6, line 35
// \\ \\ // \\ \\
// \\ \\ // \\ \\
+----+ +----+ +----+ +----+ +----+ +----+
|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 mobile node is moving across
different access networks, some of them supporting Proxy Mobile different access networks, some of them supporting PMIPv6 and some
IPv6 and some others not supporting it. Therefore the mobile node others not supporting it. Therefore the mobile node is roaming from
is roaming from an access network where the mobility is managed an access network where the mobility is managed through a network-
through a network-based solution to an access network where a based solution to an access network where a host-based management
host-based management (i.e. Mobile IPv6) is needed. This (i.e. Mobile IPv6) is needed. This scenario may have different sub-
scenario may have different sub-scenarios depending on the scenarios depending on the relations between the MIPv6 home network
relations between the Mobile IPv6 home network and the Proxy and the PMIPv6 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 where
of this scenario, where the MN is moving from an access network PMIPv6 is supported (i.e. MAG functionality is supported) to a
where PMIPv6 is supported (i.e. MAG functionality is supported) network where PMIPv6 is not supported (i.e. MAG functionality is not
to a network where PMIPv6 is not supported (i.e. MAG supported by the AR). This implies that the home link of the MN is
functionality is not supported by the AR). This implies that the actually a PMIPv6 domain. In this case the MIPv6-HoA is equal to the
home link of the MN is actually a PMIPv6 domain. In this case the MN-HoA (i.e. 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
+------+
|HA/LMA|-----------------------+
+------+ |
//\\ |
+-------//--\\--------+ |
( // \\ PMIPv6 ) |
( // \\ domain) +--------------+
+----//--------\\-----+ ( Non-PMIPv6 )
// \\ ( domain )
// \\ +--------------+
// \\ |
+----+ +----+ +----+
|MAG1| |MAG2| | AR |
+----+ +----+ +----+
| | |
[MN]
Figure 3 - Scenario A.2 MIPv6-HoA == MN-HoA -> MAG1
+------+
|HA/LMA|-----------------------+
+------+ |
//\\ |
+-------//--\\--------+ |
( // \\ PMIPv6 ) |
( // \\ domain) +--------------+
+----//--------\\-----+ ( Non-PMIPv6 )
// \\ ( domain )
// \\ +--------------+
// \\ |
+----+ +----+ +----+
|MAG1| |MAG2| | AR |
+----+ +----+ +----+
| | |
[MN]
In the above figure the non-PMIPv6 domain can actually be also a Figure 2 - Scenario A.2
different PMIPv6 domain that handles a different MN_HoA. The In the scenario illustrated in Figure 2 the non-PMIPv6 domain can
following figure illustrates this sub-case: the MIPv6-HoA is equal actually be also a different PMIPv6 domain that handles a different
to the MN_HoA; however when the MN hands over to MAG3 it gets a MN_HoA. The following figure illustrates this sub-case: the MIPv6-
different IP address (managed by LMA2 using PMIPv6) and registers HoA is equal to the MN_HoA; however when the MN hands over to MAG3 it
it as a MIPv6 CoA. gets a different IP address (managed by LMA2 using PMIPv6) and
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)
skipping to change at page 8, line 45 skipping to change at page 8, line 45
// \\ ( ||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 mobile nodes use MIPv6 to manage
manage their movements while others rely on a network-based mobility their movements while others rely on a network-based mobility
solution provided by the network as they don't support Mobile IPv6. 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.
+--------+ There may be a common mobility anchor that acts as MIPv6 Home Agent
| HA/LMA | and PMIPv6 LMA, depending on the type of the node as depicted in the
+--------+ figure. However, the LMA and HA can also be separated and this has
no impacts to the mobility of the nodes.
+--------+
| 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: [RFC3775], [RFC4877] and [RFC5213].
3.1. Issues related to scenario A.1 3.1. Issues related to scenario A.1
skipping to change at page 10, line 13 skipping to change at page 10, line 8
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 [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, the base specification
specification [RFC3775], the MN does not include any [RFC3775] 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 Home Address. As described in [RFC4877], the
[RFC4877], the identifier of the MN is known by the Home Agent identifier of the MN is known by the Home Agent after the
after the IKEv2 exchange, but this is not used in the MIPv6 IKEv2 exchange, but this is not used in the MIPv6 signaling,
signaling, nor as a lookup key for the binding cache. On the nor as a lookup key for the binding cache. On the other hand,
other hand, as specified in [RFC5213], a Proxy Binding Update as specified in [RFC5213], a Proxy Binding Update contains the
contains the Home Prefix of the MN, the MN-ID and does not Home Prefix of the MN, the MN-ID and does not include the Home
include the Home Address of the MN (since it may not be known Address of the MN (since it may not be known by the MAG and
by the MAG and consequently by the HA/LMA). The lookup key in consequently by the HA/LMA). The lookup key in the binding
the binding cache of the LMA is either the home prefix or the cache of the LMA is either the home prefix or the MN-ID. This
MN-ID. This implies that lookup keys for MIPv6 and PMIPv6 implies that lookup keys for MIPv6 and PMIPv6 registrations
registrations are different. Because of that, when the MN are different. Because of that, when the MN moves from its
moves from its home network (i.e. from the PMIPv6 domain) to home network (i.e. from the PMIPv6 domain) to the foreign
the foreign link, the Binding Update sent by the MN is not link, the Binding Update sent by the MN is not identified by
identified by the HA as an update of the Proxy Binding Cache the HA as an update of the Proxy Binding Cache Entry
Entry containing the home prefix of the MN, but a new binding containing the home prefix of the MN, but a new binding cache
cache entry is created. Therefore PMIPv6 and MIPv6 will entry is created. Therefore PMIPv6 and MIPv6 will always
always create two different binding cache entries in the HA/ create two different binding cache entries in the HA/LMA which
LMA which implies that the HA and LMA are logically separated. implies that the HA and LMA are logically separated. How to
How to handle the presence of the two binding cache entries handle the presence of the two binding cache entries for the
for the same MN is described in Section 4.2. 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 41 skipping to change at page 11, line 33
* 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
associations 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 the 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 LMA, e.g.
manipulating LMA's routing table (or binging cache). manipulating 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
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 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 mobile node's home
link, advertising the home link prefix to the MN in a unicast Router 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 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 mobile node's profile that is obtained by the MAG via
context transfer or via a policy store. context 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 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 [RFC3775].
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
skipping to change at page 14, line 8 skipping to change at page 14, line 8
| | | | 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 mobile node relies
on Proxy Mobile IPv6 as long as it is in the Proxy Mobile IPv6 on PMIPv6 as long as it is in the PMIPv6 domain. The mobile node
domain. The mobile node then uses Mobile IPv6 whenever it moves out then uses MIPv6 whenever it moves out of the PMIPv6 domain which
of the PMIPv6 domain which basically implies that the MIPv6 home link basically implies 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
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
skipping to change at page 15, line 33 skipping to change at page 15, line 33
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
initialized. This implies that the mobile node has Mobile IPv6 stack initialized. This implies that the mobile node has MIPv6 stack
active while in the PMIPv6 domain, but as long as it is attached to active while in the PMIPv6 domain, but as long as it is attached to
the same Proxy Mobile IPv6 domain, it will appear to the mobile node the same PMIPv6 domain, it will appear to the mobile node as if it is
as if it is attached to the home link. 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 17 skipping to change at page 16, line 17
Prefix the mobile node can configure a home address. Note that the Prefix the mobile node can configure a home address. Note that the
security association must be bound to the MN-HoA used in the PMIPv6 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 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 HA and this implies that there is an interaction
between the LMA and the HA in order to assign a common home network between the LMA and the HA in order to assign a common home network
prefix when triggered by PMIPv6 and MIPv6 signaling prefix when triggered by PMIPv6 and MIPv6 signaling
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) [RFC3963]in order to indicate that the entire HNP is moved to
CoA. A MIPv6 binding cache entry is created irrespective of the the new CoA. A MIPv6 binding cache entry is created irrespective of
existing PMIPv6 BCE. Packets matching the MIPv6 binding cache entry the existing PMIPv6 BCE. Packets matching the MIPv6 binding cache
are sent to the CoA present in the MIPv6 BCE. The PMIPv6 binding entry are sent to the CoA present in the MIPv6 BCE. The PMIPv6
cache entry will expire in case the MAG does not send a refresh PBU. 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 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.
skipping to change at page 17, line 16 skipping to change at page 17, line 16
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 mobile node wants to use Mobile
IPv6. This requires a solution at the system level for the access IPv6. This requires a solution at the system level for the access
network and may require knowledge of the detailed configuration and network and may require knowledge of the detailed configuration and
software capabilities of every mobile node in the system. These software capabilities of every mobile node in the system. These
issues are out of scope of this document issues are out of 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 [RFC3775].
draft] or [RFC3775].
This document requires that the a home agent that also implements the For scenario A.2, this document requires that the a home agent that
PMIPv6 LMA functionality should allow both the mobile node and the also implements the PMIPv6 LMA functionality should allow both the
authorized MAGs to modify the binding cache entries for the mobile mobile node and the authorized MAGs to modify the binding cache
node. Note that the compromised MAG threat described in [RFC4832] entries for the mobile node. Note that the compromised MAG threat
applies also here. described in [RFC4832] applies also here in a more severe form as
explained in Section 3.2. Scenario B relies on the secure
identification of mobile nodes and their capabilities so that the
right service can be provided for the right mobile nodes. For
instance, a malicious mobile node should not get the home address of
some other node assigned to it, and a mobile node 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.
6. IANA considerations 6. IANA considerations
This document has no IANA actions. This document has no IANA actions.
7. Additional Authors 7. Additional Authors
Chowdhury, Kuntal - kchowdhury@starentnetworks.com Chowdhury, Kuntal - kchowdhury@starentnetworks.com
Hesham Soliman - Hesham@elevatemobile.com Hesham Soliman - Hesham@elevatemobile.com
skipping to change at page 18, line 27 skipping to change at page 18, line 32
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., "Network Mobility (NEMO) Basic Support
Protocol", January 2005,
<http://www.rfc-editor.org/rfc/rfc3963.txt>.
[RFC4140] Soliman, H., "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", August 2005,
<http://www.rfc-editor.org/rfc/rfc4140.txt>.
[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)", 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", 2005.
[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., "Proxy Mobile IPv6", August 2008.
 End of changes. 37 change blocks. 
164 lines changed or deleted 184 lines changed or added

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