draft-ietf-netlmm-mip-interactions-01.txt   draft-ietf-netlmm-mip-interactions-02.txt 
NETLMM Working Group G. Giaretta, Ed. NETLMM Working Group G. Giaretta, Ed.
Internet-Draft Qualcomm Internet-Draft Qualcomm
Intended status: Informational November 15, 2008 Intended status: Informational February 23, 2009
Expires: May 19, 2009 Expires: August 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-01 draft-ietf-netlmm-mip-interactions-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at 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 May 19, 2009. This Internet-Draft will expire on August 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 are both deployed in a network require some (MIPv6) protocols are both deployed in a network require some
analysis and considerations. This document describes all identified analysis and considerations. This document describes all identified
possible scenarios, which require an interaction between PMIPv6 and possible scenarios, which require an interaction between PMIPv6 and
MIPv6 and discusses all issues related to these scenarios. Solutions MIPv6 and discusses all issues related to these scenarios. Solutions
and reccomendations to enable these scenarios are also described. and reccomendations to enable these scenarios are also described.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . 12 4. Analysis of possible solutions . . . . . . . . . . . . . . . . 12
4.1. Solutions related to scenario A . . . . . . . . . . . . . 12 4.1. Solutions related to scenario A . . . . . . . . . . . . . 12
4.2. Solutions related to scenario B . . . . . . . . . . . . . 14 4.2. Solutions related to scenario B . . . . . . . . . . . . . 13
4.3. Solutions related to scenario C . . . . . . . . . . . . . 14 4.3. Solutions related to scenario C . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . 16
6. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 17 6. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
Proxy Mobile IPv6 [RFC5213] is the network based protocol Proxy Mobile IPv6 [RFC5213] is a network based IP mobility protocol
standardized by IETF. In many deployment scenarios this protocol standardized by IETF. In some deployment scenarios this protocol
will be deployed together with MIPv6 [RFC3775], for example with will be deployed together with MIPv6 [RFC3775], for example with
PMIPv6 as local mobility protocol and MIPv6 as global mobility PMIPv6 as local mobility protocol and MIPv6 as global mobility
protocol. While the usage of a local mobility protocol should not protocol. While the usage of a local mobility protocol should not
have implications of how global mobility is managed, since PMIPv6 is have implications of how global mobility is managed, since PMIPv6 is
partially based on MIPv6 signaling and data structure, some partially based on MIPv6 signaling and data structure, some
considerations are needed to understand how the protocols interact considerations are needed to understand how the protocols interact
and how the different scenarios can be enabled. and how the different scenarios can be enabled.
Moreover, some SDOs are investigating complex scenarios where the Some SDOs are also investigating more complex scenarios where the
mobility of some nodes are handled using Proxy Mobile IPv6, while 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 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 needs also turn by a host-based and a network-based mechanism. This needs also
to be analyzed as a possible deployment scenario. 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 issues pertained to these scenarios and
and discusses possible means and mechanisms that are recommended to 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.
MN-HNP: the IPv6 prefix that is always present in the Router MN-HNP: the IPv6 prefix that is always present in the Router
Advertisements that the mobile node receives when it is attached Advertisements that the mobile node receives when it is attached
to any of the access links in that Proxy Mobile IPv6 domain. MN- to any of the access links in that Proxy Mobile IPv6 domain. MN-
HoA always belongs to this prefix. HoA always belongs to this prefix.
MIPv6-HoA: the Home Address the MN includes in MIPv6 binding MIPv6-HoA: the Home Address the MN includes in MIPv6 binding
update messages. Based on the scenario, MIPv6-HoA and MN-HoA may update messages.
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.
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 deployed in the same network. This document does not Mobile IPv6 are deployed in the same network. This document does not
only focus on scenarios where the two protocols are used by the same only focus on scenarios where the two protocols are used by the same
mobile node to manage local and global mobility, but it investigates mobile node to manage local and global mobility, but it investigates
also more scenarios where the protocols are more tightly integrated also more complex scenarios where the protocols are more tightly
or where there is a co-existence of nodes which do or do not integrated or where there is a co-existence of nodes which do or do
implement Mobile IPv6. not implement Mobile IPv6.
The following scenarios are 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) is registered as Care-of Address by the MN at the HA. This
by the MN at the HA. This means that the HA has a binding cache means that the HA has a binding cache entry for MIPv6-HoA that
entry for MIPv6-HoA that points to the MN-HoA. points to the MN-HoA.
The following figure illustrates this scenario. The following figure illustrates this scenario.
+----+ +----+
| HA | MIPv6-HoA -> MN-HoA | HA | MIPv6-HoA -> MN-HoA
+----+ +----+
/\ /\
/ \ / \
+-------------/----\--------------+ +-------------/----\--------------+
( / \ ) Global Mobile IPv6 ( / \ ) Global Mobile IPv6
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 may be a common mobility solution provided by the network as they don't support
mobility anchor that acts as Mobile IPv6 Home Agent and Proxy Mobile IPv6. There may be a common mobility anchor that acts as
Mobile IPv6 LMA, depending on the type of the node as depicted in Mobile IPv6 Home Agent and Proxy Mobile IPv6 LMA, depending on the
the figure. However, the LMA and HA can be also separated and type of the node as depicted in the figure. However, the LMA and
this has no impacts to the mobility of the nodes. 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 9, line 4 skipping to change at page 9, line 4
[MN] [MN]
(b) (b)
Figure 4 - Scenario C with visited PMIPv6 domain Figure 4 - Scenario C with visited PMIPv6 domain
Note that some of the scenarios can be combined. For instance, Note that some of the scenarios can be combined. For instance,
scenario B can be combined with scenario A or scenario C. scenario B can be combined with scenario A or scenario C.
The following sections describe some possible issues for each The following sections describe some possible issues for each
scenario. Note that the issues are described based on current scenario. Respective recommendations are described in Section 4.3.
specification and does not assume any optimized solution for any The specifications considered as a baseline for the analysis are the
scenario. The specifications considered as a baseline for the following: [RFC3775], [RFC4877] and [RFC5213].
analysis are the following: [RFC3775], [RFC4877] and [RFC5213]. For
example, the collocation of HA and LMA are considered as the
combination of HA according [RFC3775] and LMA according to [RFC5213],
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 3.1. Issues related to scenario A
This scenarios is very similar to other hierarchical mobility This scenarios is very similar to other hierarchical mobility
schemes, including a HMIPv6-MIPv6 scheme. This is the scenario schemes, including a HMIPv6-MIPv6 scheme. This is the scenario
referenced in [RFC4830]. No issues have been identified in this referenced in [RFC4830]. No issues have been identified in this
scenario. Note that a race condition where the MN registers the CoA scenario. Note that a race condition where the MN registers the CoA
at the HA before the CoA is actually bound to the MAG at the LMA is 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 not possible. The reason is that per PMIPv6 specification the MAG
does not forward any packets sent by the MN until the PMIPv6 tunnel does not forward any packets sent by the MN until the PMIPv6 tunnel
skipping to change at page 9, line 35 skipping to change at page 9, line 28
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 manage their own mobility to achieve better performance,
to achieve better performance, e.g. for inter-technology handovers. e.g. for inter-technology handovers. Obviously, nodes that do not
Obviously, nodes that do not implement MIPv6 must rely on the network implement MIPv6 must rely on the network to manage their mobility:
to manage their mobility: therefore Proxy MIPv6 is used for those 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
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.
skipping to change at page 10, line 4 skipping to change at page 9, line 44
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
This section highlights some considerations that are applicable to This section highlights some considerations that are applicable to
scenario C and need to be evaluated when selecting the technical scenario C where the LMA and HA are logically collocated and need to
approach to be chosen. 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 11, line 16 skipping to change at page 11, line 13
BU does not change the PMIPv6 BCE just created by the MAG. BU does not change the PMIPv6 BCE just created by the MAG.
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.Assuming the mobile node's MAG sends a option and sent by MAGs.
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.
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 PMIPv6 home domain, the MAG must send
Proxy Binding Update to the particular LMA that is co-located the Proxy Binding Update to the particular LMA that is co-
with the home agent which maintains the active binding cache located with the home agent which maintains the active binding
entry of the mobile node. If a different LMA is assigned to cache entry of the mobile node. If a different LMA is
the MAG, the MN will not be on the home link but will still assigned to the MAG, the MN will not be on the home link but
have MIPv6 active and this may be not desirable in some will still have MIPv6 active and this may be not desirable in
deployments. some deployments.
* Similarly, if the mobile node moves from the PMIP home domain * Similarly, if the mobile node moves from the PMIPv6 home
to a MIPv6 foreign network, the mobile node must send the domain to a MIPv6 foreign network, the mobile node must send
Binding Update to the particular home agent that is co-located the Binding Update to the particular home agent that is co-
with the LMA which maintains the active proxy binding cache located with the LMA which maintains the active proxy binding
entry of the mobile node. If the mobile node selects a cache 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
* In MIPv6 base specification [RFC3775] there is a strong * In MIPv6 base specification [RFC3775] there is a strong
binding between the Home Address registered by the MN and the binding between the Home Address registered by the MN and the
Security Association used to modify the corresponding binding Security Association used to modify the corresponding binding
cache entry. cache entry.
skipping to change at page 12, line 29 skipping to change at page 12, line 11
impersonation is an issue. RFC4832, section 2.2, describes impersonation is an issue. RFC4832, section 2.2, describes
how a compromised MAG can harm the functionality of LMA, e.g. how a compromised MAG can harm the functionality of LMA, e.g.
manipulating LMA's routing table (or binging cache). manipulating LMA's routing table (or binging cache).
* In this mixed scenario, both host-based and network-based * In this mixed scenario, both host-based and network-based
security associations are used to update the same binding security associations are used to update the same binding
cache entry at the HA/LMA (but see the first bullet of this cache entry at the HA/LMA (but see the first bullet of this
list, as the entry may not be the same). Based on this list, as the entry may not be the same). Based on this
consideration, the threat described in [RFC4832] is worse as consideration, the threat described in [RFC4832] is worse as
it affects also hosts that are using the LMA/HA as MIPv6 HA it affects also hosts that are using the LMA/HA as MIPv6 HA
and are not using PMIPv6 and are not using PMIPv6.
4. Analysis of possible solutions 4. Analysis of possible solutions
4.1. Solutions related to scenario A 4.1. Solutions related to scenario A
As mentioned in Section 3.1, there are no significant issues in this As mentioned in Section 3.1, there are no significant issues in this
scenario. scenario.
Figures 5 and 6 show a scenario where a MN is moving from one PMIPv6 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, domain to another, based on the scenario of Figure 1. In Figure 5,
skipping to change at page 14, line 9 skipping to change at page 13, line 35
| | | +-----------------+ | | | +-----------------+
| | BA | | | | BA | |
|<----------------------------------------------------| |<----------------------------------------------------|
Figure 6 - Global Mobility Message Flow Figure 6 - Global Mobility Message Flow
4.2. Solutions related to scenario B 4.2. Solutions related to scenario 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 requires a solution at the system level for the access
access network and is out of scope of this document. Solutions that network and is out of scope of this document. Solutions that do not
do not depend on the access network are out of the scope of this 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 which basically implies that the MIPv6 home link of the PMIPv6 domain which basically implies that the MIPv6 home link
is a PMIPv6 domain. is a PMIPv6 domain.
Analyzing the issues described in Section 3.3, it is clear that most Analyzing the issues described in Section 3.3, it is clear that most
of them are applicable only to the case where there is a common BCE of them are applicable only to the case where there is a common BCE
for the PMIPv6 registration and the MIPv6 registration. The issue on for the PMIPv6 registration and the MIPv6 registration. The issue 1
how the two protocols identify the BCE is valid only in case we on 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 assume that a PMIPv6 message has any value for a MIPv6 BCE. Also the
two different BCEs are considered completely independent, then the issues 2 and 3 are not applicable in case different logical BCEs are
issues described in Section 3.3 are not valid. For this reason, it used by the LMA and the HA. For this reason, it is recommended that
is recommended that when the MIPv6 home link is implemented as a when the MIPv6 home link is implemented as a PMIPv6 domain, the HA/
PMIPv6 domain, the HA/LMA implementation treats the two protocol as LMA implementation treats the two protocol as independent.
independent.
More in details the following principles should be followed by the More in details the following principles should be followed by the
HA/LMA implementation: HA/LMA implementation:
o PMIPv6 signaling does not overwrite any MIPv6 BCE. In particular, o PMIPv6 signaling does not overwrite any MIPv6 BCE. In particular,
when a PMIPv6 binding cache entry is created for a MN which has when a PMIPv6 binding cache entry is created for a MN which has
previously created a MIPv6 BCE, the MIPv6 BCE of the UE is not previously created a MIPv6 BCE, the MIPv6 BCE of the UE is not
overwritten and a new PMIPv6 BCE is created. overwritten and a new PMIPv6 BCE is created.
o The downlink packets in the case where both the MIPv6 BCE and o The downlink packets in the case where both the MIPv6 BCE and
PMIPv6 BCE exist are processed as follows: PMIPv6 BCE exist are processed as follows:
o 1. The MIPv6 BCE is processed first. If the destination address
of the received downlink packet matches the the BCE of the HA,
1. 1) The MIPv6 BCE is processed first. If the destination the packet is forwarded by encapsulating it with the care-of-
address of the received downlink packet matches the the BCE of address contained in the BCE.
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, 2. If the destination address does not match the MIPv6 BCE, the
the BCE created by PMIPv6 is applied and the packet are BCE created by PMIPv6 is applied and the packet are
encapsualted to the registered MAG. encapsualted to the registered MAG.
The following subsections provide a description of the procedures The following subsections provide a description of the procedures
which will be followed by the MN and HA/LMA based on the above which will be followed by the MN and HA/LMA based on the above
principles. The analysis is performed in two different subsections, principles. The analysis is performed in two different subsections,
depending if the MN moves from a PMIPv6 domain to a non-PMIPv6 domain depending if the MN moves from a PMIPv6 domain to a non-PMIPv6 domain
or vice versa. 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
skipping to change at page 16, line 18 skipping to change at page 15, line 45
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. Alternatively attribute during the IKEv2 exchange with the HA/LMA. Alternatively
the HA/LMA can be configured to provide the entire Home Network the HA/LMA can be configured to provide the entire Home Network
Prefix via the MIP6_HOME_LINK attribute to the MN as specified in 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 [RFC5026]; based on this Home Network Prefix the MN can configure a
home address. Note that the security association must be bound to 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 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 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 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 assign a common home netowrk prefix when triggered by PMIPv6 and
MIPv6 signaling 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. A MIPv6 BCE Proxy Mobile IPv6, it sends a Binding Update to the HA. The MN may
set the R bit defined in NEMO specification (implicit mode) in order
to indicate that the entire HNP is moved to the new CoA. A MIPv6 BCE
is created irrespective of the existing PMIPv6 BCE. Packets matching is created irrespective of the existing PMIPv6 BCE. Packets matching
the MIPv6 BCE are sent to the CoA present in the MIPv6 BCE. The the MIPv6 BCE are sent to the CoA present in the MIPv6 BCE. The
PMIPv6 BCE will expire in case the MAG does not send a refresh PBU. PMIPv6 BCE will expire in case the MAG does not send a refresh PBU.
The refresh PBU is sent by the MAG in case the MN is multihomed and
one of the interface is still attached on the MAG link.
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 (or HNP in
Then the MN moves to a PMIPv6 domain which is configured to be the case of NEMO) at the HA. Then the MN moves to a PMIPv6 domain which
home link for the MIPv6-HoA the MN has been assigned. is configured to be the 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 to the MAG or discovered by the MAG when the MN attaches
mechanism is not specified in [RFC5213]. A detailed description of to the MAG. the exact mechanism is not specified in [RFC5213]. A
the necessary procedure is out of the scope of this document. Note detailed description of the necessary procedure is out of the scope
that the MAG may also rely on static configuration or lower layer of this document. Note that the MAG may also rely on static
information provided by the MN in order to select the correct HA/LMA. configuration or lower layer information provided by the MN in order
to select the correct HA/LMA.
The PBU sent by the MAG creates a PMIPv6 BCE for the MN which is The PBU sent by the MAG creates a PMIPv6 BCE for the MN which is
independent of the MIPv6 BCE. Traffic destined to the MIPv6-HoA is independent of the MIPv6 BCE. Traffic destined to the MIPv6-HoA (or
still forwarded to the CoA present in the MIPv6 BCE. When the MN to the HNP in case the MN had set the flag R in the last BU) is still
wants to use the HoA directly from the home link, it sends a de- forwarded to the CoA present in the MIPv6 BCE. When the MN wants to
registration message and at that point only the PMIPv6 BCE is use the HoA directly from the home link, it sends a de-registration
present. message and at that point only the PMIPv6 BCE is present.
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].
This document requires that the a home agent that also implements the This document requires that the a home agent that also implements the
PMIPv6 LMA functionality should allow both the mobile node and the PMIPv6 LMA functionality should allow both the mobile node and the
authorized MAGs to modify the binding cache entries for the mobile authorized MAGs to modify the binding cache entries for the mobile
skipping to change at page 17, line 22 skipping to change at page 17, line 4
PMIPv6 LMA functionality should allow both the mobile node and the PMIPv6 LMA functionality should allow both the mobile node and the
authorized MAGs to modify the binding cache entries for the mobile authorized MAGs to modify the binding cache entries for the mobile
node. Note that the compromised MAG threat described in [RFC4832] node. Note that the compromised MAG threat described in [RFC4832]
applies also here. applies also here.
6. 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@googlemail.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 George Tsirtsis - tsirtsis@googlemail.com
Suresh Krishnan - suresh.krishnan@ericsson.com Suresh Krishnan - suresh.krishnan@ericsson.com
7. Acknowledgements 7. Acknowledgements
skipping to change at page 18, line 30 skipping to change at page 18, line 11
Bootstrapping in Split Scenario", RFC 5026, October 2007. Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5213] Gundavelli, S., "Proxy Mobile IPv6", August 2008. [RFC5213] Gundavelli, S., "Proxy Mobile IPv6", August 2008.
[boot-integrated] [boot-integrated]
Chowdhury, K., Ed., "MIP6-bootstrapping for the Integrated Chowdhury, K., Ed., "MIP6-bootstrapping for the Integrated
Scenario", 2007. Scenario", 2007.
[draft-tsirtsis] [draft-tsirtsis]
Tsirtsis, G., "Behavior of Collocated HA/LMA", April 2008, Tsirtsis, G., "Behavior of Collocated HA/LMA", April 2008,
<http://www.ietf.org/internet-drafts/ draft-tsirtsis-logically-separate-lmaha-01.txt
draft-tsirtsis-logically-separate-lmaha-01.txt>.
[pmipv6-draft] [pmipv6-draft]
Gundavelli, S., Ed., "Proxy Mobile IPv6", 2007, <http:// Gundavelli, S., Ed., "Proxy Mobile IPv6", 2007,
www.ietf.org/internet-drafts/ draft-ietf-netlmm-proxymip6-01.txt
draft-ietf-netlmm-proxymip6-01.txt>.
8.2. Informative References 8.2. Informative References
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005. (MIPv6)", RFC 4283, November 2005.
skipping to change at page 20, line 7 skipping to change at page 19, line 7
Author's Address Author's Address
Gerardo Giaretta (editor) Gerardo Giaretta (editor)
Qualcomm Qualcomm
Email: gerardog@qualcomm.com Email: gerardog@qualcomm.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 This document is subject to BCP 78 and the IETF Trust's Legal
copyrights, patents or patent applications, or other proprietary Provisions Relating to IETF Documents in effect on the date of
rights that may cover technology that may be required to implement publication of this document (http://trustee.ietf.org/license-info).
this standard. Please address the information to the IETF at Please review these documents carefully, as they describe your
ietf-ipr@ietf.org. rights and restrictions with respect to this document.
 End of changes. 41 change blocks. 
155 lines changed or deleted 97 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/