draft-ietf-netlmm-mip-interactions-02.txt   draft-ietf-netlmm-mip-interactions-03.txt 
NETLMM Working Group G. Giaretta, Ed. NETLMM Working Group G. Giaretta, Ed.
Internet-Draft Qualcomm Internet-Draft Qualcomm
Intended status: Informational February 23, 2009 Intended status: Informational May 1, 2009
Expires: August 19, 2009 Expires: November 2, 2009
Interactions between PMIPv6 and MIPv6: scenarios and related issues Interactions between PMIPv6 and MIPv6: scenarios and related issues
draft-ietf-netlmm-mip-interactions-02 draft-ietf-netlmm-mip-interactions-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
This Internet-Draft will expire on August 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 recommendations 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 . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 13 4.2. Solutions related to scenario B . . . . . . . . . . . . . 14
4.3. Solutions related to scenario C . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 16 6. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
Proxy Mobile IPv6 [RFC5213] is a network based IP mobility protocol Proxy Mobile IPv6 [RFC5213] is a network based IP mobility protocol
standardized by IETF. In some 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.
Some SDOs are also investigating more 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 is 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 issues pertained to these scenarios and presents and identifies all issues pertained to these scenarios and
discusses possible means and mechanisms that are recommended to discusses possible means and mechanisms that are recommended to
enable them. enable them.
skipping to change at page 9, line 10 skipping to change at page 9, line 10
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. Respective recommendations are described in Section 4.3. scenario. Respective recommendations are described in Section 4.3.
The specifications considered as a baseline for the analysis are the The specifications considered as a baseline for the analysis are the
following: [RFC3775], [RFC4877] and [RFC5213]. following: [RFC3775], [RFC4877] and [RFC5213].
3.1. Issues related to scenario A 3.1. Issues related to scenario A
This scenarios is very similar to other hierarchical mobility This scenario is very similar to other hierarchical mobility schemes,
schemes, including a HMIPv6-MIPv6 scheme. This is the scenario including a HMIPv6-MIPv6 scheme. This is the scenario referenced in
referenced in [RFC4830]. No issues have been identified in this [RFC4830]. No issues have been identified in this scenario. Note
scenario. Note that a race condition where the MN registers the CoA that a race condition where the MN registers the CoA at the HA before
at the HA before the CoA is actually bound to the MAG at the LMA is the CoA is actually bound to the MAG at the LMA is not possible. The
not possible. The reason is that per PMIPv6 specification the MAG reason is that per PMIPv6 specification the MAG does not forward any
does not forward any packets sent by the MN until the PMIPv6 tunnel packets sent by the MN until the PMIPv6 tunnel is up, regardless the
is up, regardless the mechanism used for address allocation. mechanism used for address allocation.
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
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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 where the LMA and HA are logically collocated and need to scenario C where the LMA and HA are logically collocated and need to
be evaluated when selecting the technical 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
signaling, nor as a lookup key for the binding cache. On the signaling, nor as a lookup key for the binding cache. On the
other hand, as specified in [RFC5213], a Proxy Binding Update other hand, as specified in [RFC5213], a Proxy Binding Update
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
skipping to change at page 10, line 49 skipping to change at page 10, line 49
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. It is de-registration Binding Update to its home agent. It is
necessary to make sure that the de-registration of the MIPv6 necessary to make sure that the de-registration of the MIPv6
BU does not change the PMIPv6 BCE just created by the MAG. BU does not change the PMIPv6 binding cache entry 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. In MIPv6, Binding Update messages that
ordered by a sequence numbers and sent by the mobile node, are sent by the mobile node to the home agent are ordered by
Proxy Binding Update messages are ordered by a timestamp the sequence numbers. The other side, in PMIP, Proxy Binding
option and sent by MAGs. Update messages that are sent by the MAG to the LMA are
ordered by a timestamp option. .
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 PMIPv6 home domain. If the mobile node moves from a MIPv6
foreign network to the PMIPv6 home domain, the MAG must send foreign network to the PMIPv6 home domain, the MAG must send
the Proxy Binding Update to the particular LMA that is co- the Proxy Binding Update to the particular LMA that is co-
located with the home agent which maintains the active binding located with the home agent which maintains the active binding
cache entry of the mobile node. If a different LMA is cache entry of the mobile node. If a different LMA is
assigned to the MAG, the MN will not be on the home link but assigned to the MAG, the mobile node will not be on the home
will still have MIPv6 active and this may be not desirable in link but will still have an active MIPv6 binding cache entry
some deployments. and this may be not desirable in some deployments..
* Similarly, if the mobile node moves from the PMIPv6 home * Similarly, if the mobile node moves from the PMIPv6 home
domain to a MIPv6 foreign network, the mobile node must send domain to a MIPv6 foreign network, the mobile node must send
the Binding Update to the particular home agent that is co- the Binding Update to the particular home agent that is co-
located with the LMA which maintains the active proxy binding located with the LMA which maintains the active proxy binding
cache 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 mobile node
Security Association used to modify the corresponding binding and the Security Association used to modify the corresponding
cache entry. binding cache entry.
* In PMIPv6 specification, the MAG sends proxy binding updates * In PMIPv6 specification, the MAG sends proxy binding updates
on behalf of a mobile node to update the binding cache entry on behalf of a mobile node to update the binding cache entry
that corresponds to the mobile node's home address. Since the that corresponds to the mobile node's home address. Since the
MAG sends the binding updates, PMIPv6 requires security MAG sends the binding updates, PMIPv6 requires security
associations between each MAG and the LMA. associations between each MAG and the LMA.
* As described in [RFC4832], in PMIPv6 the MAG compromise or * As described in [RFC4832], in PMIPv6 the MAG compromise or
impersonation is an issue. RFC4832, section 2.2, describes impersonation is an issue. RFC4832, section 2.2, describes
how a compromised MAG can harm the functionality of LMA, e.g. how a compromised MAG can harm the functionality of LMA, e.g.
manipulating LMA's routing table (or binging cache). manipulating LMA's routing table (or 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 mobile node is moving from
domain to another, based on the scenario of Figure 1. In Figure 5, one PMIPv6 domain to another, based on the scenario of Figure 1. In
the MN moves from an old MAG to MAG2 in the same PMIPv6 domain: this Figure 5, the mobile node moves from an old MAG to MAG2 in the same
movement triggers a PBU to LMA1 and the updating of the binding cache PMIPv6 domain: this movement triggers a PBU to LMA1 and the updating
at the LMA1; there is no MIPv6 signaling as the CoA_1 registered at of the binding cache at the LMA1; there is no MIPv6 signaling as the
the HA is the Home Address for the PMIPv6 session. In Figure 6, the CoA_1 registered at the HA is the Home Address for the PMIPv6
MN moves from MAG2 in the LMA1 PMIPv6 domain to MAG3 in a different session. In Figure 6, the mobile node moves from MAG2 in the LMA1
PMIPv6 domain: this triggers the PMIPv6 signaling and the creation of PMIPv6 domain to MAG3 in a different PMIPv6 domain: this triggers the
a binding at the LMA2. On the other hand, the local address of the PMIPv6 signaling and the creation of a binding at the LMA2. On the
MN is changed, as the LMA hss changed, and therefore the MN sends a other hand, the local address of the mobile node is changed, as the
MIPv6 Binding Update to the HA with the new CoA_2. LMA hss changed, and therefore the mobile node sends a MIPv6 Binding
Update to the HA with the new CoA_2.
+----+ +------+ +------+ +----+ +----+ +------+ +------+ +----+
| MN | | MAG2 | | LMA1 | | HA | | MN | | MAG2 | | LMA1 | | HA |
+----+ +------+ +------+ +----+ +----+ +------+ +------+ +----+
| | | | | | | |
| | | +-----------------+ | | | +-----------------+
| | | | HoA -> CoA_1 | | | | | HoA -> CoA_1 |
| | | | binding present | | | | | binding present |
| | | +-----------------+ | | | +-----------------+
| | | | | | | |
skipping to change at page 13, line 48 skipping to change at page 14, line 22
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
for the PMIPv6 registration and the MIPv6 registration. The issue 1 binding cache entry for the PMIPv6 registration and the MIPv6
on how the two protocols identify the BCE is valid only in case we registration. The issue 1 on how the two protocols identify the
assume that a PMIPv6 message has any value for a MIPv6 BCE. Also the binding cache entry is valid only in case we assume that a PMIPv6
issues 2 and 3 are not applicable in case different logical BCEs are message has any value for a MIPv6 BCE. Also the issues 2 and 3 are
used by the LMA and the HA. For this reason, it is recommended that not applicable in case different logical BCEs are used by the LMA and
when the MIPv6 home link is implemented as a PMIPv6 domain, the HA/ the HA. For this reason, it is recommended that when the MIPv6 home
LMA implementation treats the two protocol as independent. link is implemented as a PMIPv6 domain, the HA/LMA implementation
treats the two protocol as 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 mobile node
previously created a MIPv6 BCE, the MIPv6 BCE of the UE is not which has previously created a MIPv6 BCE, the MIPv6 binding cache
overwritten and a new PMIPv6 BCE is created. entry of the MN is not overwritten and a new PMIPv6 binding cache
entry 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 binding
PMIPv6 BCE exist are processed as follows: cache entry and PMIPv6 binding cache entry exist are processed as
follows:
1. The MIPv6 BCE is processed first. If the destination address o
of the received downlink packet matches the the BCE of the HA,
the packet is forwarded by encapsulating it with the care-of- 1. The MIPv6 binding cache entry is processed first. If the
address contained in the BCE. destination address of the received downlink packet matches
the the binding cache entry of the HA, the packet is forwarded
by encapsulating it with the care-of-address contained in the
BCE.
2. If the destination address does not match the MIPv6 BCE, the 2. If the destination address does not match the MIPv6 BCE, the
BCE created by PMIPv6 is applied and the packet are binding cache entry created by PMIPv6 is applied and the
encapsualted to the registered MAG. packet are 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 mobile node and HA/LMA based on the
principles. The analysis is performed in two different subsections, above principles. The analysis is performed in two different
depending if the MN moves from a PMIPv6 domain to a non-PMIPv6 domain subsections, depending if the mobile node moves from a PMIPv6 domain
or vice versa. 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 mobile node is attached to a PMIPv6 domain and there
valid Proxy Binding Cache entry at the LMA. Then the MN moves to a is a valid Proxy Binding Cache entry at the LMA. Then the mobile
different access network and starts using MIPv6 (e.g. because PMIPv6 node moves to a different access network and starts using MIPv6 (e.g.
is not supported). The MN needs to bootstrap MIPv6 parameters and because PMIPv6 is not supported). The mobile node needs to bootstrap
send a MIPv6 Binding Update in order to have service continuity. MIPv6 parameters and send a MIPv6 Binding Update in order to have
Therefore the following steps must be performed by the UE: service continuity. 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 mobile node needs to discover the IP
of the LMA which has a valid binding cache entry for its home address of the LMA which has a valid binding cache entry for its
network prefix. This is described in Section 3.3 as issue 4. home 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 mobile node needs to
IPsec Security Association with the HA/LMA as described in establish an IPsec Security Association with the HA/LMA as
[RFC4877] described in [RFC4877]
o HoA or home network prefix assignment: as part of the MIPv6 o HoA or home network prefix assignment: as part of the MIPv6
bootstrapping procedure the HA assigns a MIPv6 HoA to the MN. bootstrapping procedure the HA assigns a MIPv6 HoA to the MN.
This address must be the same the MN was using in the PMIPv6 This address must be the same the mobile node was using in the
domain. PMIPv6 domain.
Since all these steps must be performed by the MN before sending the Since all these steps must be performed by the mobile node before
Binding Update, they have an impact on the handover latency sending the Binding Update, they have an impact on the handover
experienced by the MN. For this reason it is recommended that the MN latency experienced by the MN. For this reason it is recommended
establishes the IPsec security association (and consequently is that the mobile node establishes the IPsec security association (and
provided by the HA/LMA with a MIPv6-HoA) when it is still attached to consequently is provided by the HA/LMA with a MIPv6-HoA) when it is
the PMIPv6 domain. This implies that the mobile node has Mobile IPv6 still attached to the PMIPv6 domain. This implies that the mobile
stack active while in the PMIPv6 domain, but as long as it is node has Mobile IPv6 stack active while in the PMIPv6 domain, but as
attached to the same Proxy Mobile IPv6 domain, it will appear to the long as it is attached to the same Proxy Mobile IPv6 domain, it will
mobile node as if it is attached to the home link. appear to the 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 mobile node needs to discover the IP address of the LMA/HA while in
domain. This can be done either based on DNS or based on DHCPv6, as the PMIPv6 domain. This can be done either based on DNS or based on
described in [RFC5026] and [boot-integrated]. The network should be DHCPv6, as described in [RFC5026] and [boot-integrated]. The network
configured so that the MN discovers or gets assigned the same HA/LMA should be configured so that the mobile node discovers or gets
that was serving as the LMA in the PMIPv6 domain. Details of the assigned the same HA/LMA that was serving as the LMA in the PMIPv6
exact procedure are out of scope of this document. domain. Details of the exact procedure are out of scope of this
document.
When the MN establishes the security association, it acquires a home When the mobile node establishes the security association, it
address based on [RFC5026]. However, based on PMIPv6 operations, the acquires a home address based on [RFC5026]. However, based on PMIPv6
LMA knows only the Home Network Prefix used by the MN and does not operations, the LMA knows only the Home Network Prefix used by the
know the MN-HoA.For this reason, the MN must be configured to propose mobile node and does not know the MN-HoA.For this reason, the mobile
MN-HoA as the home address in the IKEv2 INTERNAL_IP6_ADDRESS node must be configured to propose MN-HoA as the home address in the
attribute during the IKEv2 exchange with the HA/LMA. Alternatively IKEv2 INTERNAL_IP6_ADDRESS attribute during the IKEv2 exchange with
the HA/LMA can be configured to provide the entire Home Network the HA/LMA. Alternatively the HA/LMA can be configured to provide
Prefix via the MIP6_HOME_LINK attribute to the MN as specified in the entire Home Network Prefix via the MIP6_HOME_LINK attribute to
[RFC5026]; based on this Home Network Prefix the MN can configure a the mobile node as specified in [RFC5026]; based on this Home Network
home address. Note that the security association must be bound to Prefix the mobile node can configure a home address. Note that the
the MN-HoA used in the PMIPv6 domain as per [RFC4877]. Note that the security association must be bound to the MN-HoA used in the PMIPv6
home network prefix is shared between the LMA and HA and this implies domain as per [RFC4877]. Note that the home network prefix is shared
that there is an interaction between the LMA and the HA in order to between the LMA and HA and this implies that there is an interaction
assign a common home netowrk prefix when triggered by PMIPv6 and between the LMA and the HA in order to assign a common home network
MIPv6 signaling prefix when triggered by PMIPv6 and MIPv6 signaling
When the MN hands over to an access network which does not support When the mobile node hands over to an access network which does not
Proxy Mobile IPv6, it sends a Binding Update to the HA. The MN may support Proxy Mobile IPv6, it sends a Binding Update to the HA. The
set the R bit defined in NEMO specification (implicit mode) in order mobile node may set the R bit defined in NEMO specification (implicit
to indicate that the entire HNP is moved to the new CoA. A MIPv6 BCE mode) in order to indicate that the entire HNP is moved to the new
is created irrespective of the existing PMIPv6 BCE. Packets matching CoA. A MIPv6 binding cache entry is created irrespective of the
the MIPv6 BCE are sent to the CoA present in the MIPv6 BCE. The existing PMIPv6 BCE. Packets matching the MIPv6 binding cache entry
PMIPv6 BCE will expire in case the MAG does not send a refresh PBU. are sent to the CoA present in the MIPv6 BCE. The PMIPv6 binding
cache entry will expire in case the MAG does not send a refresh PBU.
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 mobile node is in a non-PMIPv6
network and it has bootstrapped MIPv6 operations based on [RFC5026]; access network and it has bootstrapped MIPv6 operations based on
therefore there is valid binding cache for its MIPv6-HoA (or HNP in [RFC5026]; therefore there is valid binding cache for its MIPv6-HoA
case of NEMO) at the HA. Then the MN moves to a PMIPv6 domain which (or HNP in case of NEMO) at the HA. Then the mobile node moves to a
is configured to be the home link for the MIPv6-HoA the MN has been PMIPv6 domain which is configured to be the home link for the MIPv6-
assigned. HoA the mobile node 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 to the MAG or discovered by the MAG when the MN attaches is assigned to the MAG or discovered by the MAG when the mobile node
to the MAG. the exact mechanism is not specified in [RFC5213]. A attaches to the MAG. the exact mechanism is not specified in
detailed description of the necessary procedure is out of the scope [RFC5213]. A detailed description of the necessary procedure is out
of this document. Note that the MAG may also rely on static of the scope of this document. Note that the MAG may also rely on
configuration or lower layer information provided by the MN in order static configuration or lower layer information provided by the
to select the correct HA/LMA. mobile node 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 binding cache entry for the
independent of the MIPv6 BCE. Traffic destined to the MIPv6-HoA (or mobile node which is independent of the MIPv6 BCE. Traffic destined
to the HNP in case the MN had set the flag R in the last BU) is still to the MIPv6-HoA (or to the HNP in case the mobile node had set the
forwarded to the CoA present in the MIPv6 BCE. When the MN wants to flag R in the last BU) is still forwarded to the CoA present in the
use the HoA directly from the home link, it sends a de-registration MIPv6 BCE. When the mobile node wants to use the HoA directly from
message and at that point only the PMIPv6 BCE is present. the home link, it sends a de-registration message and at that point
only the PMIPv6 binding cache entry 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 23 skipping to change at page 18, line 4
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
This document is a merge of four 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-01, 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 to 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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
skipping to change at page 18, line 9 skipping to change at page 18, line 35
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007. Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5213] Gundavelli, S., "Proxy Mobile IPv6", August 2008. [RFC5213] Gundavelli, S., "Proxy Mobile IPv6", August 2008.
[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]
Tsirtsis, G., "Behavior of Collocated HA/LMA", April 2008,
draft-tsirtsis-logically-separate-lmaha-01.txt
[pmipv6-draft]
Gundavelli, S., Ed., "Proxy Mobile IPv6", 2007,
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.
[RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility
 End of changes. 38 change blocks. 
148 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/