draft-ietf-netlmm-mip-interactions-00.txt   draft-ietf-netlmm-mip-interactions-01.txt 
NETLMM Working Group G. Giaretta, Ed. NETLMM Working Group G. Giaretta, Ed.
Internet-Draft Qualcomm Internet-Draft Qualcomm
Intended status: Informational October 24, 2008 Intended status: Informational November 15, 2008
Expires: April 27, 2009 Expires: May 19, 2009
Interactions between PMIPv6 and MIPv6: scenarios and related issues Interactions between PMIPv6 and MIPv6: scenarios and related issues
draft-ietf-netlmm-mip-interactions-00 draft-ietf-netlmm-mip-interactions-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2009. This Internet-Draft will expire on May 19, 2009.
Abstract Abstract
The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6
(MIPv6) protocols interact with each other need special (MIPv6) protocols are both deployed in a network require some
considerations. An analysis of all the scenarios that involve this analysis and considerations. This document describes all identified
interaction is necessary in order to provide guidelines to PMIPv6 possible scenarios, which require an interaction between PMIPv6 and
protocol design and applicability. This document describes all MIPv6 and discusses all issues related to these scenarios. Solutions
identified possible scenarios, which require an interaction between and reccomendations to enable these scenarios are also described.
PMIPv6 and MIPv6 and discusses all issues related to these scenarios.
Solutions to enable these scenarios are also described.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of the scenarios and related issues . . . . . . . . . 4 3. Overview of the scenarios and related issues . . . . . . . . . 4
3.1. Issues related to scenario A . . . . . . . . . . . . . . . 9 3.1. Issues related to scenario A . . . . . . . . . . . . . . . 9
3.2. Issues related to scenario B . . . . . . . . . . . . . . . 9 3.2. Issues related to scenario B . . . . . . . . . . . . . . . 9
3.3. Issues related to scenario C . . . . . . . . . . . . . . . 10 3.3. Issues related to scenario C . . . . . . . . . . . . . . . 10
4. Analysis of possible solutions . . . . . . . . . . . . . . . . 13 4. Analysis of possible solutions . . . . . . . . . . . . . . . . 12
4.1. Solutions related to scenario A . . . . . . . . . . . . . 13 4.1. Solutions related to scenario A . . . . . . . . . . . . . 12
4.2. Solutoins related to scenario B . . . . . . . . . . . . . 14 4.2. Solutions related to scenario B . . . . . . . . . . . . . 14
4.3. Solutions related to scenario C . . . . . . . . . . . . . 14 4.3. Solutions related to scenario C . . . . . . . . . . . . . 14
4.3.1. Mobility from a PMIPv6 domain to a non-PMIPv6 4.3.1. Mobility from a PMIPv6 domain to a non-PMIPv6
domain . . . . . . . . . . . . . . . . . . . . . . . . 15 domain . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.2. Mobility from a non-PMIPv6 domain to a PMIPv6 4.3.2. Mobility from a non-PMIPv6 domain to a PMIPv6
domain . . . . . . . . . . . . . . . . . . . . . . . . 16 domain . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 18 6. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
The NETLMM WG is chartered to standardize a network-based protocol Proxy Mobile IPv6 [RFC5213] is the network based protocol
for localized mobility management. The goals that must be fulfilled standardized by IETF. In many deployment scenarios this protocol
by the protocol design are listed in [RFC4831]. Proxy Mobile IPv6 will be deployed together with MIPv6 [RFC3775], for example with
[RFC5213] has been designated as the network-based localized mobility PMIPv6 as local mobility protocol and MIPv6 as global mobility
management protocol. protocol. While the usage of a local mobility protocol should not
have implications of how global mobility is managed, since PMIPv6 is
There are two main reasons why the interactions between Proxy Mobile partially based on MIPv6 signaling and data structure, some
IPv6 and Mobile IPv6 need to be studied. The first reason is that considerations are needed to understand how the protocols interact
Mobile IPv6 is the main global mobility management protocol developed and how the different scenarios can be enabled.
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 Proxy 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 Moreover, some SDOs are investigating complex scenarios where the
complex scenarios where the mobility of some nodes are handled using mobility of some nodes are handled using Proxy Mobile IPv6, while
Proxy Mobile IPv6, while other nodes use Mobile IPv6; or the mobility other nodes use Mobile IPv6; or the mobility of a node is managed in
of a node is managed in turn by a host-based and a network-based turn by a host-based and a network-based mechanism. This needs also
mechanism. to be analyzed as a possible deployment scenario.
This document provides a taxonomy of all scenarios that require This document provides a taxonomy of all scenarios that require
direct interaction between MIPv6 and PMIPv6. Moreover, this document direct interaction between MIPv6 and PMIPv6. Moreover, this document
presents and identifies all known issues pertained to these scenarios presents and identifies all known issues pertained to these scenarios
and discusses possible means and mechanisms that may be required to and discusses possible means and mechanisms that are recommended to
enable them. enable them.
2. Terminology 2. Terminology
General mobility terminology can be found in [RFC3753]. The General mobility terminology can be found in [RFC3753]. The
following acronyms are used in this document: following acronyms are used in this document:
MN-HoA: the home address of a mobile node in a Proxy Mobile IPv6 MN-HoA: the home address of a mobile node in a Proxy Mobile IPv6
domain. domain.
skipping to change at page 4, line 12 skipping to change at page 4, line 8
update messages. Based on the scenario, MIPv6-HoA and MN-HoA may update messages. Based on the scenario, MIPv6-HoA and MN-HoA may
be the same or different. be the same or different.
MIPv6-CoA: the Care-of Address the MN includes in MIPv6 binding MIPv6-CoA: the Care-of Address the MN includes in MIPv6 binding
update messages. Based on the scenario, MIPv6-HoA and MN-HoA may update messages. Based on the scenario, MIPv6-HoA and MN-HoA may
be the same or different. be the same or different.
3. Overview of the scenarios and related issues 3. Overview of the scenarios and related issues
Several scenarios can be identified where Mobile IPv6 and Proxy Several scenarios can be identified where Mobile IPv6 and Proxy
Mobile IPv6 are used in the same network. This document does not Mobile IPv6 are deployed in the same network. This document does not
only focus on scenarios where the two protocols are used by the same only focus on scenarios where the two protocols are used by the same
mobile node to manage local and global mobility, but it investigates mobile node to manage local and global mobility, but it investigates
also more complex scenarios where the protocols are more tightly also more scenarios where the protocols are more tightly integrated
integrated or where there is a co-existence of nodes which do or do or where there is a co-existence of nodes which do or do not
not implement Mobile IPv6. implement Mobile IPv6.
The following scenarios were identified: The following scenarios are identified:
o Scenario A - in this scenario Proxy Mobile IPv6 is used as a o Scenario A - in this scenario Proxy Mobile IPv6 is used as a
network based local mobility management protocol whereas Mobile network based local mobility management protocol whereas Mobile
IPv6 is used as a global mobility management protocol. This IPv6 is used as a global mobility management protocol. This
interaction is very similar to the HMIPv6-MIPv6 interaction; interaction is very similar to the HMIPv6-MIPv6 interaction;
Mobile IPv6 is used to manage mobility among different access Mobile IPv6 is used to manage mobility among different access
networks, while the mobility within the access network is handled networks, while the mobility within the access network is handled
by Proxy Mobile IPv6. The address managed by PMIPv6 (i.e. the MN- by Proxy Mobile IPv6. The address managed by PMIPv6 (i.e. the MN-
HoA based on PMIPv6 terminology) is registered as Care-of Address 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 by the MN at the HA. This means that the HA has a binding cache
skipping to change at page 5, line 38 skipping to change at page 5, line 38
+----+ +----+ +----+ +----+ +----+ +----+
|MAG1| |MAG2| |MAG3| |MAG1| |MAG2| |MAG3|
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | |
[MN] [MN]
Figure 1 - Scenario A Figure 1 - Scenario A
o Scenario B - in this scenario some mobile nodes use Mobile IPv6 to o Scenario B - in this scenario some mobile nodes use Mobile IPv6 to
manage their movements while others rely on a network-based manage their movements while others rely on a network-based
mobility solution provided by the network. There is a common mobility solution provided by the network. There may be a common
mobility anchor that acts as Mobile IPv6 Home Agent and Proxy mobility anchor that acts as Mobile IPv6 Home Agent and Proxy
Mobile IPv6 LMA, depending on the type of the node. Mobile IPv6 LMA, depending on the type of the node as depicted in
the figure. However, the LMA and HA can be also separated and
this has no impacts to the mobility of the nodes.
+--------+ +--------+
| HA/LMA | | HA/LMA |
+--------+ +--------+
+------+ +------+ +------+ +------+
| MAG1 | | MAG2 | | MAG1 | | MAG2 |
+------+ +------+ +------+ +------+
+-----------+ +-----------+
skipping to change at page 6, line 34 skipping to change at page 6, line 34
IPv6 and some others not supporting it. Therefore the mobile node IPv6 and some others not supporting it. Therefore the mobile node
is roaming from an access network where the mobility is managed is roaming from an access network where the mobility is managed
through a network-based solution to an access network where a through a network-based solution to an access network where a
host-based management (i.e. Mobile IPv6) is needed. This host-based management (i.e. Mobile IPv6) is needed. This
scenario may have different sub-scenarios depending on the scenario may have different sub-scenarios depending on the
relations between the Mobile IPv6 home network and the Proxy relations between the Mobile IPv6 home network and the Proxy
Mobile IPv6 domain. The following figure illustrates an example Mobile IPv6 domain. The following figure illustrates an example
of this scenario, where the MN is moving from an access network of this scenario, where the MN is moving from an access network
where PMIPv6 is supported (i.e. MAG functionality is supported) where PMIPv6 is supported (i.e. MAG functionality is supported)
to a network where PMIPv6 is not supported (i.e. MAG to a network where PMIPv6 is not supported (i.e. MAG
functionality is not supported by the AR). In this case the functionality is not supported by the AR). This implies that the
home link of the MN is actually a PMIPv6 domain. In this case the
MIPv6-HoA is equal to the MN-HoA (i.e. the address managed by MIPv6-HoA is equal to the MN-HoA (i.e. the address managed by
PMIPv6). PMIPv6).
MIPv6-HoA == MN-HoA -> MAG1 MIPv6-HoA == MN-HoA -> MAG1
+------+ +------+
|HA/LMA|-----------------------+ |HA/LMA|-----------------------+
+------+ | +------+ |
//\\ | //\\ |
+-------//--\\--------+ | +-------//--\\--------+ |
( // \\ PMIPv6 ) | ( // \\ PMIPv6 ) |
skipping to change at page 9, line 35 skipping to change at page 9, line 35
Section 4.1 describes one message flow in case PMIPv6 is used as a Section 4.1 describes one message flow in case PMIPv6 is used as a
local mobility protocol and MIPv6 is used as a global mobility local mobility protocol and MIPv6 is used as a global mobility
protocol. protocol.
3.2. Issues related to scenario B 3.2. Issues related to scenario 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 Mobile IPv6 while some others do not. The
rationale behind such a scenario is that the nodes implementing rationale behind such a scenario is that the nodes implementing
Mobile IPv6 may prefer or be configured to manage their own mobility. Mobile IPv6 may prefer or be configured to manage their own mobility
to achieve better performance, e.g. for inter-technology handovers.
Obviously, nodes that do not implement MIPv6 must rely on the network Obviously, nodes that do not implement MIPv6 must rely on the network
to manage their mobility: therefore Proxy MIPv6 is used for those to manage their mobility: therefore Proxy MIPv6 is used for those
nodes. 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
skipping to change at page 9, line 51 skipping to change at page 10, line 4
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 Mobile IPv6 and want
to use this protocol, the network must offer MIPv6 service to them. to use this protocol, the network must offer MIPv6 service to them.
In such case the MAG should not emulate the home link. Instead of In such case the MAG should not emulate the home link. Instead of
advertising the HNP, the MAG should advertise the topologically advertising the 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].
3.3. Issues related to scenario C 3.3. Issues related to scenario C
Some issues are present in this scenario: This section highlights some considerations that are applicable to
scenario C and need to be evaluated when selecting the technical
approach to be chosen.
1. HoA management and lookup key in the binding cache 1. HoA management and lookup key in the binding cache
* in MIPv6 [RFC3775] the lookup key in the Binding Cache is the * in MIPv6 [RFC3775] the lookup key in the Binding Cache is the
Home Address of the MN. In particular, based on the base Home Address of the MN. In particular, based on the base
specification [RFC3775], the MN does not include any specification [RFC3775], the MN does not include any
identifier, such as the MN-ID [RFC4283], in the Binding Update identifier, such as the MN-ID [RFC4283], in the Binding Update
message other than its Home Address. As described in message other than its Home Address. As described in
[RFC4877], the identifier of the MN is known by the Home Agent [RFC4877], the identifier of the MN is known by the Home Agent
after the IKEv2 exchange, but this is not used in the MIPv6 after the IKEv2 exchange, but this is not used in the MIPv6
skipping to change at page 10, line 34 skipping to change at page 10, line 38
contains the Home Prefix of the MN, the MN-ID and does not contains the Home Prefix of the MN, the MN-ID and does not
include the Home Address of the MN (since it may not be known 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 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 the binding cache of the LMA is either the home prefix or the
MN-ID. This implies that lookup keys for MIPv6 and PMIPv6 MN-ID. This implies that lookup keys for MIPv6 and PMIPv6
registrations are different. Because of that, when the MN registrations are different. Because of that, when the MN
moves from its home network (i.e. from the PMIPv6 domain) to moves from its home network (i.e. from the PMIPv6 domain) to
the foreign link, the Binding Update sent by the MN is not the foreign link, the Binding Update sent by the MN is not
identified by the HA as an update of the Proxy Binding Cache identified by the HA as an update of the Proxy Binding Cache
Entry containing the home prefix of the MN, but a new binding Entry containing the home prefix of the MN, but a new binding
cache entry is created. Based on these considerations, there cache entry is created. Therefore PMIPv6 and MIPv6 will
is an "unused" (proxy) binding cache entry in the Binding always create two different binding cache entries in the HA/
Cache of the LMA/HA. Note that the assumption in this section LMA which implies that the HA and LMA are logically separated.
is that the binding caches of the LMA and the HA are different How to handle the presence of the two binding cache entries
and there is not any combined binding cache. The need of such for the same MN is described in Section 4.3.
a combined binding cache will be discussed in Section 4.3.
* When the MN returns to the MIPv6 home link that is also a
PMIPv6 domain, it de-registers to remove the binding cache
entry it had created. However in [RFC3775], de-registration
is recommended (but not mandatory). This implies that the MN
receives a Router Advertisement with the home prefix, may
start 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-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 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
de-registration Binding Update to its home agent. According de-registration Binding Update to its home agent. It is
to RFC3775, the home agent would delete the binding cache necessary to make sure that the de-registration of the MIPv6
entry after accepting the de-registration Binding Update, BU does not change the PMIPv6 BCE just created by the MAG.
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 3. Race condition between Binding Update and Proxy Binding Update
messages (Sequence Numbers and Timestamps) messages (Sequence Numbers and Timestamps)
* MIPv6 and PMIPv6 use different mechanisms for handling re- * MIPv6 and PMIPv6 use different mechanisms for handling re-
ordering of registration messages and they are sent by ordering of registration messages and they are sent by
different entities. Whereas Binding Update messages are different entities. Whereas Binding Update messages are
ordered by a sequence numbers and sent by the mobile node, ordered by a sequence numbers and sent by the mobile node,
Proxy Binding Update messages are ordered by a timestamp Proxy Binding Update messages are ordered by a timestamp
option and sent by MAGs. 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, it is not clear if packets are forwarded to
the mobile node or not and for this reason the behavior of the
HA/LMA needs to be clarified in case there are two BCEs, one
PMIPv6 and one MIPv6 BCE, for the same MN.
* 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
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 domai
4. Use of wrong home agent or LMA after handover 4. Use of wrong home agent or LMA after handover
* This issues can arise if multiple LMAs are deployed in the * This issues can arise if multiple LMAs are deployed in the
PMIP home domain. If the mobile node moves from a MIPv6 PMIP home domain. If the mobile node moves from a MIPv6
foreign network to the PMIP home domain, the MAG must send the foreign network to the PMIP home domain, the MAG must send the
Proxy Binding Update to the particular LMA that is co-located Proxy Binding Update to the particular LMA that is co-located
with the home agent which maintains the active binding cache with the home agent which maintains the active binding cache
entry of the mobile node. If a different LMA is assigned to entry of the mobile node. If a different LMA is assigned to
the MAG, packets addressed to the mobile node's home address the MAG, the MN will not be on the home link but will still
do not reach the mobile node anymore. have MIPv6 active and this may be not desirable in some
deployments.
* Similarly, if the mobile node moves from the PMIP home domain * Similarly, if the mobile node moves from the PMIP home domain
to a MIPv6 foreign network, the mobile node must send the to a MIPv6 foreign network, the mobile node must send the
Binding Update to the particular home agent that is co-located Binding Update to the particular home agent that is co-located
with the LMA which maintains the active proxy binding cache with the LMA which maintains the active proxy binding cache
entry of the mobile node. If the mobile node selects a entry of the mobile node. If the mobile node selects a
different home agent, packets addressed to the mobile node's different home agent, packets addressed to the mobile node's
home address do not reach the mobile node. home address do not reach the mobile node.
5. Threat of compromised MAG 5. Threat of compromised MAG
skipping to change at page 14, line 29 skipping to change at page 14, line 5
| | | | | | | |
| | | +-----------------+ | | | +-----------------+
| | | | HoA -> CoA_2 | | | | | HoA -> CoA_2 |
| | | | binding updated | | | | | binding updated |
| | | +-----------------+ | | | +-----------------+
| | BA | | | | BA | |
|<----------------------------------------------------| |<----------------------------------------------------|
Figure 6 - Global Mobility Message Flow Figure 6 - Global Mobility Message Flow
4.2. Solutoins related to scenario B 4.2. Solutions related to scenario B
The solution for this scenario may depend on the access network being The solution for this scenario may depend 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 would require a solution at the system level for the IPv6. This would require a solution at the system level for the
access network and is out of scope of this document. Solutions that access network and is out of scope of this document. Solutions that
do not depend on the access network are out of the scope of this do not depend on the access network are out of the scope of this
document. document.
4.3. Solutions related to scenario C 4.3. Solutions related to scenario C
As described in Section 3.3, in this scenario the mobile node relies As described in Section 3.3, in this scenario the mobile node relies
on Proxy Mobile IPv6 as long as it is in the Proxy Mobile IPv6 on Proxy Mobile IPv6 as long as it is in the Proxy Mobile IPv6
domain. The mobile node then uses Mobile IPv6 whenever it moves out domain. The mobile node then uses Mobile IPv6 whenever it moves out
of the PMIPv6 domain. of the PMIPv6 domain which basically implies that the MIPv6 home link
is a PMIPv6 domain.
This section provides an analysis of the solutions for the issues Analyzing the issues described in Section 3.3, it is clear that most
described in Section 3.3. The analysis is performed in two different of them are applicable only to the case where there is a common BCE
subsections, depending if the MN moves from a PMIPv6 domain to a non- for the PMIPv6 registration and the MIPv6 registration. The issue on
PMIPv6 domain or vice versa. how the two protocols identify the BCE is valid only in case we
assume that a PMIPv6 message has any value for a MIPv6 BCE. If the
two different BCEs are considered completely independent, then the
issues described in Section 3.3 are not valid. For this reason, it
is recommended that when the MIPv6 home link is implemented as a
PMIPv6 domain, the HA/LMA implementation treats the two protocol as
independent.
NOTE: The NETLMM WG is still discussing the best approach to deal More in details the following principles should be followed by the
with this scenario, both in IETF meetings and on the NETLMM WG HA/LMA implementation:
mailing list. Current discussions are about handling this scenario
with the same vs. separate BCEs and on the external behavior of the o PMIPv6 signaling does not overwrite any MIPv6 BCE. In particular,
HA. For this reason, the analysis provided in this draft is to be when a PMIPv6 binding cache entry is created for a MN which has
considered tentative and the draft will be updated as soon as the previously created a MIPv6 BCE, the MIPv6 BCE of the UE is not
NETLMM WG has decided on the way forward. overwritten and a new PMIPv6 BCE is created.
o The downlink packets in the case where both the MIPv6 BCE and
PMIPv6 BCE exist are processed as follows:
o
1. 1) The MIPv6 BCE is processed first. If the destination
address of the received downlink packet matches the the BCE of
the HA, the packet is forwarded by encapsulating it with the
care-of-address contained in the BCE.
2. 2) If the destination address does not match the MIPv6 BCE,
the BCE created by PMIPv6 is applied and the packet are
encapsualted to the registered MAG.
The following subsections provide a description of the procedures
which will be followed by the MN and HA/LMA based on the above
principles. The analysis is performed in two different subsections,
depending if the MN moves from a PMIPv6 domain to a non-PMIPv6 domain
or vice versa.
4.3.1. Mobility from a PMIPv6 domain to a non-PMIPv6 domain 4.3.1. Mobility from a PMIPv6 domain to a non-PMIPv6 domain
Let's assume the MN is attached to a PMIPv6 domain and there is a Let's assume the MN is attached to a PMIPv6 domain and there is a
valid Proxy Binding Cache entry at the LMA. Then the MN moves to a valid Proxy Binding Cache entry at the LMA. Then the MN moves to a
adifferent access network and starts using MIPv6 (e.g. because PMIPv6 different access network and starts using MIPv6 (e.g. because PMIPv6
is not supported). The MN needs to bootstrap MIPv6 parameters and is not supported). The MN needs to bootstrap MIPv6 parameters and
send a MIPv6 Binding Update in order to have service continuity. send a MIPv6 Binding Update in order to have service continuity.
Therefore the following steps must be performed by the UE: Therefore the following steps must be performed by the UE:
o HA/LMA address discovery: the MN needs to discover the IP address o HA/LMA address discovery: the MN needs to discover the IP address
of the LMA which has a valid binding cache entry for its home of the LMA which has a valid binding cache entry for its home
network prefix. This is described in Section 3.3 as issue 4. network prefix. This is described in Section 3.3 as issue 4.
o Security Association establishment: the MN needs to establish an o Security Association establishment: the MN needs to establish an
IPsec Security Association with the HA/LMA as described in IPsec Security Association with the HA/LMA as described in
[RFC4877] [RFC4877]
o HoA assignment: as part of the MIPv6 bootstrapping procedure the o HoA or home network prefix assignment: as part of the MIPv6
HA assigns a MIPv6 HoA to the MN. This address must be the same bootstrapping procedure the HA assigns a MIPv6 HoA to the MN.
the MN was using in the PMIPv6 domain. This address must be the same the MN was using in the PMIPv6
domain.
Since all these steps must be performed by the MN before sending the Since all these steps must be performed by the MN before sending the
Binding Update, they have an impact on the handover latency Binding Update, they have an impact on the handover latency
experienced by the MN. For this reason it is recommended that the MN experienced by the MN. For this reason it is recommended that the MN
establishes the IPsec security association (and consequently is establishes the IPsec security association (and consequently is
provided by the HA/LMA with a MIPv6-HoA) when it is still attached to provided by the HA/LMA with a MIPv6-HoA) when it is still attached to
the PMIPv6 domain. This implies that the mobile node has Mobile IPv6 the PMIPv6 domain. This implies that the mobile node has Mobile IPv6
stack active while in the PMIPv6 domain, but as long as it is 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 attached to the same Proxy Mobile IPv6 domain, it will appear to the
mobile node as if it is attached to the home link. mobile node as if it is attached to the home link.
In order to establish the security association with the HA/LMA, the In order to establish the security association with the HA/LMA, the
MN needs to discover the IP address of the LMA/HA while in the PMIPv6 MN 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 DHCPv6, as domain. This can be done either based on DNS or based on DHCPv6, as
described in [RFC5026] and [boot-integrated]. The network should be described in [RFC5026] and [boot-integrated]. The network should be
configured so that the MN discovers or gets assigned the same HA/LMA configured so that the MN discovers or gets assigned the same HA/LMA
that was serving as the LMA in the PMIPv6 domain. Details of the that was serving as the LMA in the PMIPv6 domain. Details of the
exact procedure are out of scope of this document. exact procedure are out of scope of this document.
When the MN establishes the security association, it pacquires a home When the MN establishes the security association, it acquires a home
address based on [RFC5026]. However, based on PMIPv6 operations, the address based on [RFC5026]. However, based on PMIPv6 operations, the
LMA knows only the Home Network Prefix used by the MN and does not LMA knows only the Home Network Prefix used by the MN and does not
know the MN-HoA.For this reason, the MN must be configured to propose know the MN-HoA.For this reason, the MN must be configured to propose
MN-HoA as the home address in the IKEv2 INTERNAL_IP6_ADDRESS MN-HoA as the home address in the IKEv2 INTERNAL_IP6_ADDRESS
attribute during the IKEv2 exchange with the HA/LMA. Note that the attribute during the IKEv2 exchange with the HA/LMA. Alternatively
security association must be bound to the MN-HoA used in the PMIPv6 the HA/LMA can be configured to provide the entire Home Network
domain as per [RFC4877]. Prefix via the MIP6_HOME_LINK attribute to the MN as specified in
[RFC5026]; based on this Home Network Prefix the MN can configure a
home address. Note that the security association must be bound to
the MN-HoA used in the PMIPv6 domain as per [RFC4877]. Note that the
home network prefix is shared between the LMA and HA and this implies
that there is an interaction between the LMA and the HA in order to
assign a common home netowkr prefix when triggered by PMIPv6 and
MIPv6 signaling
When the MN hands over to an access network which does not support When the MN hands over to an access network which does not support
Proxy Mobile IPv6, it sends a Binding Update to the HA/LMA. The Proxy Mobile IPv6, it sends a Binding Update to the HA. A MIPv6 BCE
LMA/HA must match the HoA with the MN-ID and update the respective is created irrespective of the existing PMIPv6 BCE. Packets matching
BCE accordingly. This is because the proxy BCE is associated to the the MIPv6 BCE are sent to the CoA present in the MIPv6 BCE. The
MN-ID and MN-HNP and not to the MN-HoA. Note that this implies a PMIPv6 BCE will expire in case the MAG does not send a refresh PBU.
change in the BU processing if compared to RFC 3775: the LMA/HA must The refresh PBU is sent by the MAG in case the MN is multihomed and
match the HoA included in the BU with the MN-ID known based on IKEv2 one of the interface is still attached on the MAG link.
signalling and update the respective BCE accordingly (clearing the P
flag).
More generally, 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. This solves the issue 1 described in Section 3.3.
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
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. This is valid, even though not
explicitly mentioned, also for the next subsection.
4.3.2. Mobility from a non-PMIPv6 domain to a PMIPv6 domain 4.3.2. Mobility from a non-PMIPv6 domain to a PMIPv6 domain
In this section it is assumed that the MN is in a non-PMIPv6 access In this section it is assumed that the MN is in a non-PMIPv6 access
network and it has bootstrapped MIPv6 operations based on [RFC5026]; network and it has bootstrapped MIPv6 operations based on [RFC5026];
therefore there is valid binding cache for its MIPv6-HoA at the HA. therefore there is valid binding cache for its MIPv6-HoA at the HA.
Then the MN moves to a PMIPv6 domain which is configured to be the Then the MN moves to a PMIPv6 domain which is configured to be the
home link for the MIPv6-HoA the MN has been assigned. home link for the MIPv6-HoA the MN has been assigned.
In order to provide session continuity, the MAG needs to send a PBU In order to provide session continuity, the MAG needs to send a PBU
to the HA/LMA that was serving the MN. The MAG needs to discover the to the HA/LMA that was serving the MN. The MAG needs to discover the
HA/LMA; however the current version of [RFC5213] assumes that the LMA HA/LMA; however the current version of [RFC5213] assumes that the LMA
is assigned or discovered when the MN attaches to the MAG. the exact is assigned or discovered when the MN attaches to the MAG. the exact
mechanism is not specified in [RFC5213]. A detailed description of mechanism is not specified in [RFC5213]. A detailed description of
the necessary procedure is out of the scope of this document. Note the necessary procedure is out of the scope of this document. Note
that the MAG may also rely on static configuration or lower layer that the MAG may also rely on static configuration or lower layer
information provided by the MN in order to select the correct HA/LMA. information provided by the MN in order to select the correct HA/LMA.
The PBU sent by the MAG must update the MIPv6 BCE of the MN. However The PBU sent by the MAG creates a PMIPv6 BCE for the MN which is
this PBU contains the MN-HNP and not the MN-HoA. For this reason, in independent of the MIPv6 BCE. Traffic destined to the MIPv6-HoA is
order to ensure that the PMIPv6 addressing model is maintained when still forwarded to the CoA present in the MIPv6 BCE. When the MN
the MN moves back to the PMIPv6 domain, a HA which acts also as LMA wants to use the HoA directly from the home link, it sends a de-
must allocate a home network prefix to the MN, even though during the registration message and at that point only the PMIPv6 BCE is
MIPv6 bootstrapping only a /128 Home Address is assigned. It is present.
implementation specific if this prefix is stored on the MIPv6 BCE
when the MN is just using MIPv6.
As the MN moves to its home link, it will send a de-registration
binding update with zero lifetime to its home agent. This is done
approximately at the same time the MAG the sends a Proxy Binding
Update to the LMA functionality co-located with the home agent.
Actually the de-registration of the MN will be received by the HA/LMA
after the PBU from the MAG as, based on [RFC5213], the MAG forwards
pakets only when the PMIPv6 tunnel is established. The HA/LMA 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. This solves issue 2 described
in Section 3.3.
NOTE: A solution for race conditions between BU and PBU messages
(issue #3) is TBD.
5. Security Considerations 5. Security Considerations
Scenarios A and B described in Section 3 do not introduce any Scenarios A and B described in Section 3 do not introduce any
security considerations in addition to those described in [pmipv6- security considerations in addition to those described in [pmipv6-
draft] or [RFC3775]. draft] or [RFC3775].
In Scenario C described in Section 3.3, the home agent has to allow This document requires that the a home agent that also implements the
the authorized MAGs in a particular PMIPv6 domain to be able to PMIPv6 LMA functionality should allow both the mobile node and the
modify the binding cache entry for a mobile node. [RFC3775] requires authorized MAGs to modify the binding cache entries for the mobile
that only the right mobile node is allowed to modify the binding node. Note that the compromised MAG threat described in [RFC4832]
cache entry for its home address. This document requires that the a applies also here.
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.
6. Additional Authors 6. Additional Authors
Chowdhury, Kuntal - kchowdhury@starentnetworks.com Chowdhury, Kuntal - kchowdhury@starentnetworks.com
Hesham Soliman - Hesham@elevatemobile.com Hesham Soliman - Hesham@elevatemobile.com
Vijay Devarapalli - vijay.devarapalli@azairenet.com Vijay Devarapalli - vijay.devarapalli@azairenet.com
Sri Gundavelli - sgundave@cisco.com Sri Gundavelli - sgundave@cisco.com
Kilian Weniger - Kilian.Weniger@eu.panasonic.com Kilian Weniger - Kilian.Weniger@eu.panasonic.com
Genadi Velev - Genadi.Velev@eu.panasonic.com Genadi Velev - Genadi.Velev@eu.panasonic.com
Ahmad Muhanna - amuhanna@nortel.com Ahmad Muhanna - amuhanna@nortel.com
George Tsirtsis - tsirtsis@googlemail.com
Suresh Krishnan - suresh.krishnan@ericsson.com
7. Acknowledgements 7. Acknowledgements
This document is a merge of three different Internet Drafts: This document is a merge of four different Internet Drafts:
draft-weniger-netlmm-pmipv6-mipv6-issues-00, draft-weniger-netlmm-pmipv6-mipv6-issues-00,
draft-devarapalli-netlmm-pmipv6-mipv6-01and draft-devarapalli-netlmm-pmipv6-mipv6-01,
draft-tsirtsis-logically-separate-lmaha-01and
draft-giaretta-netlmm-mip-interactions-00. Thanks to the authors and draft-giaretta-netlmm-mip-interactions-00. Thanks to the authors and
editors of those drafts. editors of those drafts.
The authors would also like ot thank Jonne Soininen and Vidya The authors would also like ot thank Jonne Soininen and Vidya
Narayanan, NETLMM WG chairs, for their support. Narayanan, NETLMM WG chairs, for their support.
8. References 8. References
8.1. Normative References 8.1. Normative References
 End of changes. 38 change blocks. 
186 lines changed or deleted 152 lines changed or added

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