One document matched: draft-giaretta-netlmm-mip-interactions-01.txt
Differences from draft-giaretta-netlmm-mip-interactions-00.txt
NETLMM Working Group G. Giaretta, Ed.
Internet-Draft Qualcomm
Intended status: Informational July 6, 2007
Expires: January 7, 2008
Interactions between PMIPv6 and MIPv6: scenarios and related issues
draft-giaretta-netlmm-mip-interactions-01
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 January 7, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6
(MIPv6) protocols interact with each other need special
considerations. An analysis of all the scenarios that involve this
interaction is necessary in order to provide guidelines to PMIPv6
protocol design and applicability. This document describes all
identified possible scenarios, which require an interaction between
PMIPv6 and MIPv6 and discusses all issues related to these scenarios.
Solutions to enable these scenarios are also described.
Giaretta Expires January 7, 2008 [Page 1]
Internet-Draft PMIPv6-MIPv6 Interactions July 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of the scenarios and related issues . . . . . . . . . 3
3.1. Issues related to scenario A . . . . . . . . . . . . . . . 8
3.2. Issues related to scenario B . . . . . . . . . . . . . . . 8
3.3. Issues related to scenario C . . . . . . . . . . . . . . . 9
4. Analysis of possible solutions . . . . . . . . . . . . . . . . 12
4.1. Solutions related to scenario A . . . . . . . . . . . . . 12
4.2. Solutoins related to scenario B . . . . . . . . . . . . . 13
4.3. Solutions related to scenario C . . . . . . . . . . . . . 13
5. Conclusions/Recommendations . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Giaretta Expires January 7, 2008 [Page 2]
Internet-Draft PMIPv6-MIPv6 Interactions July 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.
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 worth investigating for example 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 and a MIPv6 home agent can be
extended to handle PMIPv6.
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 use Mobile IPv6; or the mobility
of a node is managed in turn by a host-based and a network-based
mechanism.
This document provides a taxonomy of all scenarios that require
direct interaction between MIPv6 and PMIPv6. Moreover, this document
presents and identifies all known issues pertained to these scenarios
and discusses possible means and mechanisms that may be required to
enable them. .
2. Terminology
General mobility terminology can be found in [RFC3753].
3. Overview of the scenarios and related issues
Several scenarios can be identified where Mobile IPv6 and Proxy
Mobile IPv6 are used. This document does not only focus on scenarios
where the two protocols are used by the same mobile node to manage
local and global mobility, but it investigates also more complex
scenarios where the protocols are more tightly integrated or where
there is a co-existence of nodes which do or do not implement Mobile
IPv6.
The following scenarios were identified:
Giaretta Expires January 7, 2008 [Page 3]
Internet-Draft PMIPv6-MIPv6 Interactions July 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 address managed by PMIPv6 (i.e. the
MN_HoA based on PMIPv6 terminology) 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 points to the MN_HoA.
The following figure illustrates this scenario.
+----+
| HA | MIPv6_HoA -> MN_HoA
+----+
/\
/ \
+-------------/----\--------------+
( / \ ) Global Mobile IPv6
( / \ ) Domain
+----------/----------\-----------+
/ \
+----+ +----+
MN_HoA -> MAG1 |LMA1| |LMA2|
+----+ +----+
//\\ \\
+----//--\\---+ +-----\\------+
( // \\ ) ( \\ ) Local Mobility Network
( // \\ ) ( \\ ) PMIPv6 domain
+-//--------\\+ +--------\\---+
// \\ \\
// \\ \\
// \\ \\
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
| | |
[MN]
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.
Giaretta Expires January 7, 2008 [Page 4]
Internet-Draft PMIPv6-MIPv6 Interactions July 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). In this case the
MIPv6_HoA is equal to the MN_HoA (i.e. the address managed by
PMIPv6).
Giaretta Expires January 7, 2008 [Page 5]
Internet-Draft PMIPv6-MIPv6 Interactions July 2007
MIPv6_HoA == MN_HoA -> MAG1
+------+
|HA/LMA|-----------------------+
+------+ |
//\\ |
+-------//--\\--------+ |
( // \\ PMIPv6 ) |
( // \\ domain) +--------------+
+----//--------\\-----+ ( Non-PMIPv6 )
// \\ ( domain )
// \\ +--------------+
// \\ |
+----+ +----+ +----+
|MAG1| |MAG2| | AR |
+----+ +----+ +----+
| | |
[MN]
Figure 3 - Scenario C
In the above figure the non-PMIPv6 domain can actually be also a
different PMIPv6 domain that handles a different MN_HoA. The
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
different IP address (managed by LMA2 using PMIPv6) and registers
it as a MIPv6 CoA.
Giaretta Expires January 7, 2008 [Page 6]
Internet-Draft PMIPv6-MIPv6 Interactions July 2007
MIPv6_HoA == MN_HoA -> MAG_1
+-------+
|HA/LMA1|-----------------------+
+-------+ |
//\\ +----+
+-------//--\\--------+ |LMA2|
( // \\ home ) +----+
( // \\ PMIPv6) +------||------+
( // \\domain) ( ||visited)
+---//----------\\----+ ( ||PMIPv6 )
// \\ ( ||domain )
// \\ +------||------+
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
| | |
[MN]
(a)
MIPv6_HoA -> MN_CoA
+-------+
|HA/LMA1|-----------------------+
+-------+ |
//\\ +----+
+-------//--\\--------+ |LMA2| MN_CoA -> MAG3
( // \\ home ) +----+
( // \\ PMIPv6) +------||------+
( // \\domain) ( ||visited)
+---//----------\\----+ ( ||PMIPv6 )
// \\ ( ||domain )
// \\ +------||------+
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
| | |
[MN]
(b)
Figure 4 - Scenario C with visited PMIPv6 domain
Note that some of the scenarios can be combined. For instance,
scenario B can be combined with scenario A or scenario C.
The following sections describe some possible issues for each
Giaretta Expires January 7, 2008 [Page 7]
Internet-Draft PMIPv6-MIPv6 Interactions July 2007
scenario. Note that the issues are described based on current
specification and does not assume any optimized solution for any
scenario. The specifications considered as a baseline for the
analysis are the following: [RFC3775], [RFC4877] and [pmipv6-draft].
For example, the collocation of HA and LMA are considered as the
combination of HA according [RFC3775] and LMA according to
[pmipv6-draft], e.g. no combined binding caches are considered. The
analysis of the collocated HA and LMA would show what is the
preferred behaviour for this entity. The behaviour and respective
recommendations are described in Section 4.3.
3.1. Issues related to scenario A
This scenarios is very similar to other hierarchical mobility
schemes, including a HMIPv6-MIPv6 scheme. This is the scenario
referenced in [RFC4830]. No issues have been identified in this
scenario. In particular,a race condition where the MN registers the
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
does not forward any packets sent by the MN until the PMIPv6 tunnel
is up, regardless the mechanism used for address allocation.
Section 4.1 will describe one flow in case PMIPv6 is used as a local
mobility protocol and MIPv6 is used as a global mobility protocol.
3.2. 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 may prefer to manage their own mobility. 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 related to this scenario may be solvable at system level
and may not be protocol issues. However, it is worth discussing them
in order to have a full picture of the peculiarities of a PMIPv6/
MIPv6 scenario.
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 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.
Giaretta Expires January 7, 2008 [Page 8]
Internet-Draft PMIPv6-MIPv6 Interactions July 2007
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. Therefore,
instead advertising the HNP, the MAG should advertise the
topologically correct 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
Some possible issues are present in this scenario:
1. 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. An identifier of the MN
is known by the Home Agent after the IKEv2 exchange, but this
is not used in the MIPv6 signaling, nor as a lookup key for
the binding cache. On the other hand, as specified in
[pmipv6-draft], 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. 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 these considerations, there is an
"unused" (proxy) binding cache entry in the Binding Cache of
the LMA/HA. Note that the assumption in this section is that
the binding caches of the LMA and the HA are different and
there is not any combined binding cache. The need of such a
combined binding cache will be discussed in Section 4.3.
* when the MN return back in the MIPv6 home link in MIPv6 that
is also a PMIPv6 domain, it has to de-registers the host-based
mobility binding cache entry. However in [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. In case the de-
Giaretta Expires January 7, 2008 [Page 9]
Internet-Draft PMIPv6-MIPv6 Interactions July 2007
registration BU is not sent, the PBU sent by the MAG will not
update the Binding Cache entry related to the HoA, but 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.
2. MIPv6 de-registration Binding Update deletes PMIPv6 binding cache
entry
* When the mobile node moves from a MIPv6 foreign network to the
PMIPv6 home domain, the MAG registers the mobile node at the
LMA by sending a Proxy Binding Update. Subsequently, the LMA
updates the mobile node's binding cache entry with the MAG
address and the MAG emulates the mobile node's home link.
Upon detection of the home link, the mobile node will send a
de-registration Binding Update to its home agent. According
to RFC3775, the home agent would delete the binding cache
entry after accepting the de-registration Binding Update,
i.e., it would delete the proxy binding cache entry that was
just established by the MAG. Hence, packets arriving at the
LMA and destined for the mobile node would not be forwarded to
the mobile node anymore.
3. Race condition between Binding Update and Proxy Binding Update
messages (Sequence Numbers and Timestamps)
* MIPv6 and PMIPv6 use different mechanisms for handling re-
ordering of registration messages and they are sent by
different entities. Whereas Binding Update messages are
ordered by a sequence numbers and sent by the mobile node,
Proxy Binding Update messages are ordered by a timestamp
option and sent by MAGs.
* Assuming the mobile node's MAG sends a Proxy Binding Update
message (for refreshing the mobile node's BCE or because the
mobile node has just done a handover to this MAG) and shortly
thereafter the mobile node moves out of the PMIP home domain,
where it configures a new MIPv6-CoA and sends a Binding Update
message to its home agent. If now the Proxy Binding Update
message from the MAG is delayed so that it reaches the LMA
after the Binding Update, the binding cache entry at the LMA
would wrongly point to the MAG. Without further measures,
packets are not forwarded to the mobile node unless a new
Binding Update is sent by the mobile node. This may result in
Giaretta Expires January 7, 2008 [Page 10]
Internet-Draft PMIPv6-MIPv6 Interactions July 2007
a significant packet loss. A similar situation can occur if
the mobile node sends a Binding Update messsage from outside
the PMIP home domain and shortly thereafter enters the PMIP
home domain.
4. Use of wrong home agent or LMA after handover
* This issues can arise if multiple LMAs are deployed in the
PMIP home domain. If the mobile node moves from a MIPv6
foreign network to the PMIP home domain, the MAG must send the
Proxy Binding Update to the particular LMA that is co-located
with the home agent which maintains the active binding cache
entry of the mobile node. If a different LMA is assigned to
the MAG, packets addressed to the mobile node's home address
do not reach the mobile node anymore.
* Similarly, if the mobile node moves from the PMIP 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
* 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, the MAG sends proxy binding updates
on behalf of a mobile node to update the binding cache entry
that corresponds to the mobile node's home address. Since the
MAG sends the binding updates, PMIPv6 requires security
associations between each MAG and the LMA.
* As described in [RFC4832], in PMIPv6 the MAG compromise or
impersonation is an issue. RFC4832, section 2.2, describes
how a compromised MAG can harm the functionality of LMA, e.g.
manipulating LMA's routing table (or binging cache).
* 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). Based on this
Giaretta Expires January 7, 2008 [Page 11]
Internet-Draft PMIPv6-MIPv6 Interactions July 2007
consideration, the threat desceibed in [RFC4832] is worse as
it affects also hosts that are using the LMA/HA as MIPv6 HA
and are not using PMIPv6.
4. Analysis of possible solutions
4.1. Solutions related to scenario A
As mentioned in Section 3.1, there are no significant issues in this
scenario.
Figures 5 and 6 show a scenario where a MN is moving from one PMIPv6
domain to another, based on the scenario of Figure 1. In Figure 5,
the MN moves from an old MAG to MAG2 in the same 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 CoA_1 registered at
the HA is the Home Address for the PMIPv6 session. In Figure 6, the
MN moves from MAG2 in the LMA1 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 other hand, the local address of the
MN is changed, as the LMA hss changed, and therefore the MN sends a
MIPv6 Binding Update to the HA with the new CoA_2.
+----+ +------+ +------+ +----+
| MN | | MAG2 | | LMA1 | | HA |
+----+ +------+ +------+ +----+
| | | |
| | | +-----------------+
| | | | HoA -> CoA_1 |
| | | | binding present |
| | | +-----------------+
| | | |
| CoA conf/confirm | PBU(CoA_1,MAG_2) | |
| <--------------->| ----------------->| |
| | +-----------------+|
| | | CoA_1 -> MAG_2 ||
| | | binding updated ||
| | +-----------------+|
| | PBA | |
| | <----------------| |
| | | |
Figure 5 - Local Mobility Message Flow
Giaretta Expires January 7, 2008 [Page 12]
Internet-Draft PMIPv6-MIPv6 Interactions July 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_2 |
| | | | binding updated |
| | | +-----------------+
| | BA | |
|<----------------------------------------------------|
Figure 6 - Global Mobility Message Flow
4.2. Solutoins related to scenario B
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 would require 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 TBD.
4.3. Solutions related to scenario C
As described in Section 3.3, in this scenario the mobile node relies
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
the PMIPv6 domain. As the PMIPv6 domain emulates the home link in
terms of MIPv6, the MN_HoA assigned by PMIPv6 is the equal to the
MIPv6 home address.
This implies that the mobile node has Mobile IPv6 stack 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 as if it is
attached to the home link. Based on the fact that the MIPv6 is
active, even when connected to the PMIPv6 domain, the mobile node may
Giaretta Expires January 7, 2008 [Page 13]
Internet-Draft PMIPv6-MIPv6 Interactions July 2007
setup IPsec security associations required for protecting the Mobile
IPv6 signaling message. This allows the mobile node to minimize the
handover latency in a subsequent PMIPv6 to MIPv6 transition. If the
mobile node does this, the security association must be bound to the
MN_HoA used in the PMIPv6 domain as per RFC4877.
If the mobile node attaches to an access network that is not part of
the Proxy Mobile IPv6 domain, a transition to MIPv6 is needed. The
mobile node acquires a care-of address from the access network,
treats the earlier home address in the PMIPv6 domain as the MIPv6
home address and performs a MIPv6 registration. In order to do that,
if the mobile node does not know the IP address of the LMA/HA, it
needs to discover it and bootstrap a security association with it.
During this procedure the HA has to assign the same HoA used by the
MN in the PMIPv6 domain; however this may not be known by the LMA as
only the Home Network Prefix is known by the LMA. To solve this
issue, the LMA/HA can provide the mobile node with the home prefix as
specified in [boot-split].
Anyway the LMA/HA needs to check the BCE when assigning the address
in IKEv2. It is up to the mobile node then keeping the same HoA used
in the PMIPv6 domain. As soon as the Security Association is
established, the mobile node sends the BU with (HoA, CoA) and the
LMA/HA must match the HoA with the MN-ID and update the respective
BCE accordingly. This implies a change in the BU processing if
compared to RFC 3775: the LMA/HA must match the HoA included in the
BU with the MN-ID known based on IKEv2 signalling and update the
respective BCE accordingly (clearing the P flag).
When the LMA and the HA are co-located, binding cache lookup for a
mobile node must use a combination of the mobile node's identifier
and the home address. The Binding Update from the mobile node
contains the home address of the mobile node, whereas the Proxy
Binding Update from the MAG contains only the mobile node's
identifier. Therefore when transitioning between using Proxy Mobile
IPv6 and Mobile IPv6, the Home Agent must ensure that the mobile
node's binding cache entry must be looked up with both the home
address and identifier of the mobile node. This requires the Home
Agent to acquire the mobile node identifier other than from the
Binding Update message (for e.g., from the preceding IKEv2 exchange
that set up security associations for sending the Binding Update) and
to store it as part of the binding cache entry for the mobile node.
Note that this requires that the MN-ID used by the mobile node during
the IKEv2 set-up is the same of the MN-ID used by the MAG in PMIPv6
signalling.
Note that in this scenario the same binding cache entry for the
mobile node is at times modified by the mobile node and other times
Giaretta Expires January 7, 2008 [Page 14]
Internet-Draft PMIPv6-MIPv6 Interactions July 2007
modified by a MAG. The home agent must ensure that only authorized
MAGs in addition to the mobile node are allowed to modify the binding
cache entry for the mobile node.
If the mobile node bootstraps from a non-PMIPv6 domain with a LMA/HA
and the LMA/HA does not have any entry for the MN, the LMA/HA must
allocate a home network prefix to the MN, even though during the
MIPv6 bootstrapping only a /128 Home Address is assigned. This is
needed in order to ensure that the PMIPv6 addressing model is
maintained when the MN moves back to the PMIPv6 domain.
When the mobile node moves to the PMIPv6 domain that corresponds to
its home link, it will send a de-registration binding update with
zero lifetime to its home agent. But at the same, the MAG the mobile
node is attached will send a proxy Binding Update to the LMA
functionality co-located with the home agent.
In this case, the HA/LMA MUST send a binding acknowledgment with
success status to the mobile node to indicate a successful de-
registration. In case the binding update is not valid, a binding
acknowledgement with the appropriate error status MUST be sent, as
specified in [RFC3775]. The HA/LMA must modify the binding cache
entry to reflect the fact that it is now a binding cache entry
created using PMIPv6. The home agent MUST NOT delete the binding
cache entry for the mobile node after receiving a de-registration BU
if in the binding cache there is a BCE with the P-flag set for the
same MN. A solution for race conditions between BU and PBU messages
(issue #3) is TBD.
Note that the bootstrapping mechanisms used to discover the LMA, the
Mobile IPv6 home agent and home address for the mobile node must be
configured such that the LMA assigned for a particular mobile node
can be used as a home agent and the address given to the mobile node
when it is attached to the PMIPv6 domain can be used as the MIPv6
home address when the mobile node is no longer attached to the PMIPv6
domain. How this is done is still TBD.
5. Conclusions/Recommendations
<This section will list the suggested modifications/extensions to
PMIPv6 and MIPv6 (if any)>
6. Security Considerations
Scenarios A and B described in Section 3 do not introduce any
security considerations in addition to those described in [pmipv6-
Giaretta Expires January 7, 2008 [Page 15]
Internet-Draft PMIPv6-MIPv6 Interactions July 2007
draft] or [RFC3775].
In Scenario C described in Section 3.3, the home agent has to allow
the authorized MAGs in a particular PMIPv6 domain to be able to
modify the binding cache entry for a mobile node. [RFC3775] requires
that only the right mobile node is allowed to modify the binding
cache entry for its home address. This document requires that the a
home agent that also implements the PMIPv6 LMA functionality should
allow both the mobile node and the authorized MAGs to modify the
binding cache entry for the mobile node. Note that the compromised
MAG threat described in [RFC4832] applies also here; in this scenario
the threat is worse as it affects also hosts that are using the
LMA/HA as MIPv6 HA and are not using PMIPv6.
7. Additional Authors
Chowdhury, Kuntal - kchowdhury@starentnetworks.com
Hesham Soliman - Hesham@elevatemobile.com
Vijay Devarapalli - vijay.devarapalli@azairenet.com
Sri Gundavelli - sgundave@cisco.com
Kilian Weniger - Kilian.Weniger@eu.panasonic.com
Genadi Velev - Genadi.Velev@eu.panasonic.com
Ahmad Muhanna - amuhanna@nortel.com
8. Acknowledgements
This document is a merge of three different Internet Drafts:
draft-weniger-netlmm-pmipv6-mipv6-issues-00,
draft-devarapalli-netlmm-pmipv6-mipv6-01 and
draft-giaretta-netlmm-mip-interactions-00. Thanks to the authors and
editors of those drafts.
The authors would also like ot thank Jonne Soininen and Vidya
Narayanan, NETLMM WG chairs, for their support.
9. References
Giaretta Expires January 7, 2008 [Page 16]
Internet-Draft PMIPv6-MIPv6 Interactions July 2007
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.
[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.
[RFC4830] Kempf, J., "Problem Statement for Network-Based Localized
Mobility Management (NETLMM)", April 2007.
[RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based
Localized Mobility Management (NETLMM)", April 2007.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", 2005.
[boot-split]
Giaretta, G., Ed., "MIPv6 bootstrapping in split
scenario", 2007.
[pmipv6-draft]
Gundavelli, S., Ed., "Proxy Mobile IPv6", 2007, <http://
www.ietf.org/internet-drafts/
draft-ietf-netlmm-proxymip6-01.txt>.
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.
Giaretta Expires January 7, 2008 [Page 17]
Internet-Draft PMIPv6-MIPv6 Interactions July 2007
Author's Address
Gerardo Giaretta (editor)
Qualcomm
Email: gerardog@qualcomm.com
Giaretta Expires January 7, 2008 [Page 18]
Internet-Draft PMIPv6-MIPv6 Interactions July 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).
Giaretta Expires January 7, 2008 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-22 04:54:33 |