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