NETLMM Working Group G. Velev
Internet-Draft K. Weniger
Intended status: Informational Panasonic
Expires: August 28, 2008 February 25, 2008
Interactions between PMIPv6 and MIPv6: Route Optimization Issues
draft-velev-netlmm-mip-pmip-ro-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The interactions scenarios between Proxy Mobile IPv6 (PMIPv6) and
Mobile IPv6 (MIPv6) protocols are described in [ID-MIP-PMIP]. This
document analyzes these scenarios when route optimization is used.
The analysis results in the identification of possible issues that
should be considered in the design of extensions for Route
Optimization in PMIPv6.
Velev & Weniger Expires August 28, 2008 [Page 1]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of route optimization . . . . . . . . . . . . . . . . 3
3.1. Route optimization in MIPv6 . . . . . . . . . . . . . . . 3
3.2. Route optimization in PMIPv6 . . . . . . . . . . . . . . . 4
4. Analysis of the scenarios and possible issues . . . . . . . . 5
4.1. Proxy RO in scenario A . . . . . . . . . . . . . . . . . . 5
4.2. Proxy RO in scenario B . . . . . . . . . . . . . . . . . . 7
4.3. Proxy RO in scenario C . . . . . . . . . . . . . . . . . . 10
4.3.1. MN2 performs MN role . . . . . . . . . . . . . . . . . 10
4.3.2. MN2 performs CN role . . . . . . . . . . . . . . . . . 11
5. Summary of the issues . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Velev & Weniger Expires August 28, 2008 [Page 2]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
1. Introduction
The NETLMM WG is standardizing Proxy Mobile IPv6 (PMIPv6) as the
protocol for network-based localized mobility management. The MIPv6-
PMIPv6 interactions document [ID-MIP-PMIP] captures the issues with
the inter-working between host-based (MIPv6) and network-based
(PMIPv6) mobility and identifies three main scenarios. However, the
document does not consider the cases when a route optimized path is
set up.
In PMIPv6 the mobile access gateway (MAG) manages the mobility-
related registrations with the local mobility agent (LMA) on behalf
of the mobile nodes (MNs) attached to it. According to the base
PMIPv6 specification [ID-PMIPv6] all data packets are bi-
directionally tunneled between MAG and LMA. In some scenarios, e.g.
if the communicating end nodes are located in the same PMIPv6 domain,
it is advantageous to route the packets directly between the MAGs to
which the nodes are attached. The PMIPv6 base spec does not support
route optimization (RO) between different MAGs, however, there are
individual proposals (see Section 3.2) for establishing such a route
optimized path. In these proposals the MNs are unaware about the
proxy RO set up in PMIPv6 domain between the MAGs. On the other
hand, in MIPv6 the MN itself performs the route optimization with a
CN.
This document provides an analysis of the scenarios and possible
issues when the PMIPv6 and MIPv6 route optimization procedures
interact.
2. Terminology
General mobility terminology can be found in [RFC3753]. Further,
PMIPv6-related terminology used in this document is defined in
[ID-PMIPv6]
3. Overview of route optimization
This section provides an overview of the route optimization
procedures specified for MIPv6 and the general characteristics of a
potential to-be-standardized route optimization procedure for PMIPv6.
3.1. Route optimization in MIPv6
MIPv6 protocol comes with a route optimization scheme that enables a
direct communication between MN and CN, i.e. the data packets are
bypassing the Home Agent. Route optimization requires the mobile
Velev & Weniger Expires August 28, 2008 [Page 3]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
node to register its current binding of home address (HoA) to care-
of-address (CoA) at the correspondent node. The CN establishes a
binding cache entry and packets from the CN can be routed directly to
the CoA of the MN.
MPv6 specification [RFC3775] defines the return routability (RR)
procedure that authorizes the BU sent by the MN by the use of a
cryptographic token exchange (keygen tokens). The binding update is
signed by binding management key (Kbm) that is generated based on the
keygen tokens obtained from CN separately for the home address and
care-of-address. The detailed RR and RO procedures are described in
sections 5.2, 6.1, 9.4 and 9.5 in [RFC3775].
3.2. Route optimization in PMIPv6
Route optimization in PMIPv6 (proxy RO) is not in the charter of the
NetLMM working group and is not specified in the PMIPv6 base
specification [ID-PMIPv6]. However, [ID-PMIPv6] describes one case
where the local routing at the MAG is possible. The local routing is
applied when the two communicating mobile nodes are attached to the
same MAG and the MAG's policy in coordination with LMA allows such
routing. In all other attachment constellations the PMIPv6 protocol
mandates reverse tunneling of data packets to the LMA.
However, interest in the area of PMIPv6 RO (henceforth called proxy
RO) exists from various working group members and individual
solutions are already available. In the following, the general
characteristics of possible PMIPv6 RO mechanisms are analyzed.
Subsequently, some individual submissions are briefly presented as
example solutions.
In general, the proxy RO can be categorized in the following cases:
1. Between the MN and the CN's MAG. In this case the RO is
initiated by the MN and the MAG is the endpoint of the route
optimized path. For instance, if MIPv6 RO is used, CN's MAG
performs the role of MIPv6 CN with respect to RO.
2. Between the MN's MAG and the CN. In this case the MN's MAG
initiates the RO with CN on behalf of the MN and the endpoint of
the route optimized path is MN's MAG instead of MN. For
instance, if MIPv6 RO is used the MAG performs the role of MIPv6
MN with respect to RO.
3. Between MAGs. In this case the MAG, to which the MN is attached,
initiates RO with the CN's MAG and a route optimized path between
both MAGs is established. For instance, if MIPv6 RO is used, the
MN's MAG performs the role of MIPv6 MN with respect to RO and the
Velev & Weniger Expires August 28, 2008 [Page 4]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
MAG, to which the CN is attached, performs the role of MIPv6 CN.
Each of the above cases is analyzed in different MIPv6-PMIPv6
interaction scenarios in Section 4.
The document [PMIPv6-RO-RR] describes the applicability of Enhanced
Route Optimization for Mobile IPv6 specified in [RFC4866] for PMIPv6,
i.e. how cryptographically generated addresses (CGA) and the
corresponding optimized RO signalling (compared to [RFC3775]) are
used. The authors describe a proxy Return Routability (RR) procedure
performed by the MAG on behalf of the MN. The document addresses
cases 2 and 3 from above.
Another individual approach for RO in PMIPv6 is described in
[PMIPv6-RO-ROA]. In this approach, the exchange of RO setup messages
(similar to binding updates messages) between the MAGs is performed
either a) via the LMAs, to which the MAGs are attached, or b)
directly between the MAGs. In the latter case, a route optimization
association (ROA) between the MAGs is needed. The document addresses
the case 3 (i.e. MAG-MAG RO) from above.
A further individual solution is described in [PMIPv6-RO-IPv4] that
presents a more general approach and considers a combination of both
individual solutions presented in the previous paragraphs: either
performing a proxy RR between MAGs or having a Security Association
between MAGs for direct exchange of binding updates.
In general, if a mobile node attached to a MAG in PMIPv6 domain moves
to a new MAG, the old MAG, the new MAG and the LMA should manage the
transition of the RO-related state from the old to the new MAG.
Further the new MAG shall update the BCE in the correspondent node.
These procedures are outside of the scope of this document because it
is not specific to MIPv6-PMIPv6 interactions and should be defined in
a potential to-be-standardized PMIPv6 RO procedure.
4. Analysis of the scenarios and possible issues
The categorization of the MIPv6-PMIPv6 interactions with respect to
RO is based on scenarios A, B and C described in [ID-MIP-PMIP] in
order to achieve compliance between both documents. For each of the
scenarios the cases from Section 3.2 are applied and the resulting
issues are identified.
4.1. Proxy RO in scenario A
In scenario A, PMIPv6 is used as a network-based local mobility
management protocol within one access network, whereas MIPv6 is used
Velev & Weniger Expires August 28, 2008 [Page 5]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
as a global mobility management protocol. Furthermore, HA and LMA
are not co-located.
In this scenario the MN uses MIPv6 and registers the IP address
obtained in the PMIPv6 domain as CoA at the HA. A bi-directional
tunnel is set up between the MN and HA. An additional PMIPv6 tunnel
is in use between MAG1 and LMA1. Figure 1 illustrates the
hierarchical application of MIPv6 and PMIPv6 protocols in scenario A.
The CN relies on the PMIPv6 for mobility management, it is attached
to MAG2 and anchored at LMA1, where the MN is anchored too.
+----+
| HA |
+----+
//\
// \
+------------//----\-------------+
( // \ ) Global Mobile IPv6
( // \ ) Domain
+---------//----------\----------+
// \
+------+ +----+
| LMA1 | |LMA2|
+------+ +----+
////\\ \\
+----////--\\----+ +----\\------+
( //// \\ ) ( \\ ) Local Mobility Network
( //// \\ ) ( \\ ) PMIPv6 domain
+-////--------\\-+ +-------\\---+
//// \\ \\
//// \\ \\
//// \\ \\
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
|| | |
[MN] [CN]
Figure 1 - Scenario A
As MIPv6 bidirectional tunnel is set up between MN and HA, the PMIP
entities (MAG1 and LMA1) cannot learn the address of the CN, and
thus, cannot perform any actions with respect to proxy RO. Even if
the CN is attached to the same or neighbour MAG, to which MN is
attached, PMIP entities are unable to discover such a situation
assuming that there is no explicit information between MN's HA and
LMA. Therefore, proxy RO initiated by MN's MAG to the CN, i.e. case
Velev & Weniger Expires August 28, 2008 [Page 6]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
2 from Section 3.2, is not possible. The MAG would rather see the HA
as CN and establish an optimized route to the HA, which is of course
not desired. Proxy RO between MAG1 and MAG2 (case 3) has the same
problem as case 2: since a MIPv6 tunnel is set up between MN and HA,
MAG1 cannot discover CN's address and initiate proxy RO.
In contrary to cases 2 and 3, proxy RO tunnel between MN and MAG2
(case 1) is possible. MN initiates a MIPv6 RO with the CN and the
MAG2 is configured to act as proxy CN on behalf CN. The resulting
path in both directions (i.e. MN->CN and CN->MN) would be MN-MAG1-
LMA1-MAG2-CN. Such a situation is comparable to usual PMIPv6
routing, although MIPv6 RO IP header options are present in the data
packets (Routing Header Type 2 and Home Address destination option).
This situation reveals CN address to MAG1 and hence gives opportunity
for a proxy RO tunnel set up between MAG1 and MAG2. A potential to-
be-standardized PMIPv6 RO procedure shall consider the handling of
such a situation, where already MIPv6 RO is running between MN and CN
(or CN's MAG, i.e. MAG2). In summary, proxy PMIPv6 RO from MAG1 to
CN or from MAG1 to MAG2 in scenario A cannot be initiated unless MN
performs MIPv6 RO with CN (unless there are other means of informing
MAG1 of the CN address).
Another proxy RO constellation is possbile, in which the MAG2
initiates proxy RO with the MN on behalf of the CN. After such a
route optimized path is set up, the data packets would continue to
flow via the HA, i.e. the path would the same as before the proxy RO.
The MAG2 however cannot recognize such a constellation. Therefore it
is advantageous if MAG2 does not initiate proxy RO with MN.
Figure 1 shows a case where the CN is using only a PMIPv6 service.
However, a situation is possible, in which the CN (analogically to
MN) is also using PMIPv6 for local mobility and MIPv6 for global
mobility. In such a situation both end nodes (MN and CN) must
perform MIPv6 procedure in order to utilize a proxy RO tunnel between
the MAGs. The proxy RO tunnel between the MAGs can be set up before
the MIPv6 RO procedures are completed, however, the MAGs must know
the care-of-address of the corresponding node and the respective MAG
they are attached to. After the PMIPv6 RO is completed, the MAGs
create a routing state pointing the CoA of the correspondent node to
its respective MAG. The MAGs start to forward packets over the proxy
RO tunnel as soon as the end nodes start to use the CoA of the
correspondent node.
4.2. Proxy RO in scenario B
In scenario B some MNs use MIPv6 to manage their movements while
others rely on a PMIPv6 protocol provided by the network. The
configuration of the MAG for supporting such scenario is described in
Velev & Weniger Expires August 28, 2008 [Page 7]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
[ID-MIP-PMIP] Section 6.14. [ID-MIP-PMIP] assumes that the mobility
anchor for MIPv6 and PMIPv6 is the same entity implementing the
functions of both HA and LMA (below denoted as HA/LMA). For a MN, to
which PMIPv6 service is offered, the HA/LMA is acting as LMA and for
a MN, to which MIPv6 service is offered, the HA/LMA is acting as HA.
Figure 2 illustrates scenario B where a MN uses MIPv6 and a CN relies
on PMIPv6 for mobility management. The MN utilizes MIPv6 tunnel to
the HA/LMA via AR whereas a PMIPv6 tunnel is set up for CN between
MAG2 and HA/LMA.
+------+
|HA/LMA|
+------+
//\\
+- ---//--\\----+
( // \\ ) Mixed MIPv6 and
( // \\ ) PMIPv6 mobility domain
+--//--------\\-+
// \\
// \\
+----+ +----+
| AR | |MAG2|
+----+ +----+
|| |
[MN] [CN]
Figure 2 - Scenario B with colocated HA and LMA
An additional case is possible in scenario B, where MN's HA and CN's
LMA are not colocated, however, they are in the same PMIPv6 mobiltiy
domain. Such a case is depicted on Figure 3.
Velev & Weniger Expires August 28, 2008 [Page 8]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
+----+ +-----+
| HA | | LMA |
+----+ +-----+
|| ||
+--||---------- ||--+
( || || ) Mixed MIPv6 and
( || || ) PMIPv6 mobility domain
+--||-----------||--+
|| ||
+----+ +----+
| AR | |MAG2|
+----+ +----+
|| |
[MN] [CN]
Figure 3 - Scenario B with separated HA and LMA
First, the analyses focuses on the proxy RO from MN side. For the
constellations in Figure 2 and Figure 3, proxy RO is possible only
between MN and MAG2 (case 1). The proxy RO cases 2 and 3 from
Section 3.2 are not possible because MN is attached to an AR. If the
MN initiates a MIPv6 RO with CN, MAG2 may respond as proxy on behalf
of the CN, which results in case 1. The RO path is set up between MN
and MAG2, which is the optimal route from MN to CN. Additionally,
MAG2 may initiate proxy RO with the MN in order to achieve route
optimized path in direction from CN to MN. If the RO is performed in
both directions, no further optimizations are needed.
Second, the analyses focuses on the proxy RO from CN side. This is
the case if MAG2 initiates proxy RO with MN. In Figure 2, the
resulting route optimized path would be via the MN's HA/LMA, because
MAG2 does not know MN's CoA. The proxy RO in such a case does not
lead to any path optimization and hence it is beneficial if MAG1 does
not initiate proxy RO with MN. In Figure 3, the resulting route
optimized path would be from MAG2 directly to MN's HA. In such a
case the proxy RO would have a small benefit, as the data path
doesn't run over LMA.
In summary, to achieve the optimal RO path in scenario B between MN
using MIPv6 and CN relying on PMIPv6 service in the same network
domain, the MN should initiate MIPv6 RO and additionally a proxy RO
between MN and MAG should be performed. The network can assist the
MN to initiate MIPv6 RO, as the network entities (most probably LMA)
can discover such constellation.
Velev & Weniger Expires August 28, 2008 [Page 9]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
4.3. Proxy RO in scenario C
In scenario C a MIPv6-capable MN moves between access networks using
different mobility management schemes, i.e. some access networks
support PMIPv6 and others do not. This results in transition between
PMIPv6 and MIPv6 mobility management for the particular MN and
requires that LMA and HA functions are located in the same physical
entity. Scenario C is depicted in Figure 4.
+------+
|HA/LMA|-----------------------+
+------+ |
//\\ |
+-------//--\\--------+ |
( // \\ PMIPv6 ) |
( // \\ domain) +--------------+
+----//--------\\-----+ ( Non-PMIPv6 )
// \\ ( domain )
// \\ +--------------+
// \\ |
+----+ +----+ +----+
|MAG1| |MAG2| | AR |
+----+ +----+ +----+
| | |
[MN1] [MN2] ------> (a) |
(b) <------ [MN2]
Figure 4 - Scenario C
4.3.1. MN2 performs MN role
In order to anlyze the issues with RO in scenario C, first it is
assumed that MN2 has the role of MN and MN1 has the role of CN.
Further two transition scenarios are investigated denoted by the
arrows (a) and (b) in Figure 4. In transition (a) the MN2 moves from
MAG2 of PMIPv6 domain to an AR of non-PMIPv6 domain, whereas in
transition (b) the MN2 moves from AR to MAG2. At first, transition
(a) is analyzed. If a MN2 is attached to MAG2 and MN1 is attached to
MAG1, a proxy RO path can be set up according to cases 2 (MAG2->MN1)
and case 3 (MAG2->MAG1) from Section 3.2. Cases 1 (MN2->MAG1) is not
possible because the assumption is that MN2 is at the home link
supporting PMIPv6 service, i.e. the MN2 does not have a CoA to
register with the CN. In the following analysis, cases 2 and 3 are
investigated together because the only difference is which entity
(MN1 or MAG1) performs the CN role regarding RO functionality.
Therefore, below CN is indicated as MN1/MAG1.
Velev & Weniger Expires August 28, 2008 [Page 10]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
If the MN2 moves outside the PMIP domain to an AR of a MIPv6 domain,
the MN2 performs MIPv6 registration with the HA/LMA. Since the MN2
is not aware about the proxy RO before the handover, it does not
necessarily initiate registration of its CoA to MN1/MAG1. It depends
on the MN2's MIPv6 implementation whether MIPv6 RO is performed.
Furthermore, there would be some delay till the MIPv6 RO path is
setup after the handover. The steps performed by the MAG2, after
detection of MN2 detachment, depend on a potential PMIPv6 RO
specification. If the MAG2 does not deregister the MN2 with the MN1/
MAG1, MN1/MAG1 continues to send packets to MAG2 and this could lead
to packet loss. Therefore a potential PMIPv6 RO protocol shall take
care of this situation. On the other hand, if a mechanism is
available in MAG2 to deregister MN2 with MN1/MAG1, then the proxy RO
path is terminated and data packets are routed via HA/LMA. The
change of route optimized to non-optimized path would result in
increased end-to-end delay and possibly to data packets lost due to
transport layer time out. To avoid this situation, a future protocol
mechanism should allow to keep the RO path between the MN2 and MN1
after the MN2 moves out of the PMIPv6 domain.
The transition (b) from Figure 4 is observed hereby, where the MN2 is
first attached to a MIPv6 domain and later moves to the home link
that supports PMIPv6 service (home PMIPv6 domain). Case 1
(MN2->MAG1) from Section 3.2 is the only possible way of performing
proxy RO before the handover. While attached to the MIPv6 domain, a
proxy RO path between MN2 and MAG1 is set up, i.e. MN2 creates BCE
in MAG1. When the MN2 moves to the home PMIPv6 domain, it performs
the returning home procedure described in [RFC3775], i.e. sends
deregistration BU messages to HA and all CNs, to which a MIPv6 RO has
been set up. Thus, the MN2 deletes the BCE in MAG1 and MAG1 sends
data packets to MN2's HoA, i.e. to HA/LMA. Such a scenario does not
result in data packet loss, however, the MN-CN path after the
handover is not optimized.
In conclusion, the MN2's transition between PMIPv6 and MIPv6 mobility
schemes results in issues that should be considered by a future
protocol mechanisms. The transition from PMIPv6 to non-PMIPv6 domain
may result in packet loss or affect the transport layer application
due to increased end-to-end delay.
4.3.2. MN2 performs CN role
The MIPv6 RO procedure [RFC3775] specifies the functionality of a CN,
however, it does not consider mobile CN. In the following a mobile
CN performing PMIPv6-MIPv6 transition in scenario C is analyzed in
order to identify possible issues. In scenarios A and B the mobile
CN does not change the mobility management scheme and therefore such
an analysis is not needed. With respect to Figure 4, the assumption
Velev & Weniger Expires August 28, 2008 [Page 11]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
now is that the MN's role is implemented in MN1 (respectively MAG1)
and CN's role - in MN2 (respectively MAG2). In transition (a) the
MN2 hands over from MAG2 to the AR. Before the handover, a proxy RO
tunnel exists between MAG1 and MAG2. MN2 sends data packets to MN1's
HoA, but the MAG2 tunnels the packets to MAG1. After the handover,
the MN2 performs MIPv6 registration with HA and continues to send the
data packets to MN1's HoA. The LMA forwards the data packets to the
MAG1 and they are delivered to MN1. However, in the oposit direction
(MN1->MN2) MAG1 would continue to keep the proxy RO path with MAG2,
although MN2 is no longer attached to MAG2, which would result in
packet loss. Such a situation should be considered by the potential
to-be-standardized proxy RO specification.
In transition (b), the MN2 hands over from AR to MAG2. Before the
handover, MN2 uses MIPv6 bi-directional tunneling to the home network
and a proxy RO tunnel has been set up between MAG1 and MN2. MN2
performs the role of CN, i.e. the proxy BCE in MN2 is created by
MAG1. Since in Figure 4 the MN2's HA is co-located with MN1's LMA,
the proxy RO tunnel does not bring any benefit for the data path.
The proxy RO tunnel would be beneficial in case that LMA and HA are
not co-located (similar to Figure 3). After the handover to MAG2,
the MN2 keeps the proxy BCE, and thus, sends the packets to MN1's CoA
(e.g. MAG1's IP address). The packets are encapsulated by MAG2 in a
PMIPv6 tunnel to LMA, an thus, the MN1-MN2 path results in an usual
non-optimized PMIP path. However, in the direction MN1->MN2 the
proxy RO state state in MAG1 is still active. MAG1 continues to
update the MN2's BCE because MAG1 does not learn about the MN2
movement. Such a situation is undesired and shall be handled by a
to-be-standardized proxy RO procedure.
To sum up the issues with mobile CN in scenario C, transition (a) may
lead to a situation in which the entity performing the MN's role
(MAG1) continues to perform proxy RO with the MAG2, although MN2 is
no longer attached to MAG2. Transition (b) results in the non-
optimal situation of tunneling data packets between MAG2 and LMA
although a BCE exists in MN2 for optimal route to MN1.
5. Summary of the issues
The analyses of the different scenarios of MIPv6-PMIPv6 interactions
with respect to RO shows a couple of issues that should be considered
during the design of to-be-standardized proxy RO procedure. This
section summarizes the main points of the above analyses:
o In scenarios where both end nodes are located in the same PMIP
domain and at least one of the end nodes uses MIPv6 for global
mobility (scenario A and B), MIPv6 RO procedure should be
Velev & Weniger Expires August 28, 2008 [Page 12]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
performed in order to utilize a PMIPv6 RO tunnel. In some
constellations (scenario B, proxy RO tunnel MN-MAG2), the set up
of proxy RO tunnel does not lead to any improvement in the data
path unless the end node that uses MIPv6 does not perform MIPv6
RO.
o In scenarios where transition between MIPv6 and PMIPv6 occurs
(Scenario C), depending on the constellation, PMIP RO states must
be transfered (from MAG to MN or from MN to MAG) or updated when
the transition occurs.
o In some constellations (in scenario A) it may be advantageous for
MAGs to know the CoA of the corresponding end nodes in order to
set up a proxy RO tunnel in advance before the MIPv6 RO procedure
is completed.
6. Security Considerations
The current document analyzes scenarios and describes issues; it does
not present new protocol design. Therefore this document does not
introduce any security issues in addition to those described in
[ID-PMIPv6] or [RFC3775].
7. References
7.1. Normative References
[ID-PMIPv6]
Gundavelli, S., Ed., "Proxy Mobile IPv6", February 2008,
<draft-ietf-netlmm-proxymip6-10.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", May 2007.
Velev & Weniger Expires August 28, 2008 [Page 13]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
7.2. Informative References
[ID-MIP-PMIP]
Giaretta, G., Ed., "Interactions between PMIPv6 and MIPv6:
scenarios and related issues", November 2007,
<draft-giaretta-netlmm-mip-interactions-02.txt>.
[PMIPv6-RO-IPv4]
Jeong, S. and R. Wakikawa, "Route Optimization for Proxy
Mobile IPv6", July 2007,
<draft-jeong-netlmm-ro-support-for-pmip6-00.txt>.
[PMIPv6-RO-ROA]
Liebsch, M. and A. Abeille, "Route Optimization for Proxy
Mobile IPv6", November 2007,
<draft-abeille-netlmm-proxymip6ro-01.txt>.
[PMIPv6-RO-RR]
Sarikaya, B., Qin, A., Huang, A., and W. Wu, "PMIPv6 Route
Optimization Protocol", November 2007,
<draft-qin-mipshop-pmipro-01.txt>.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
Authors' Addresses
Genadi Velev
Panasonic
Monzastr. 4c
Langen 63225
Gemany
Phone:
Email: genadi.velev@eu.panasonic.com
Kilian Weniger
Panasonic
Monzastr. 4c
Langen 63225
Gemany
Phone:
Email: kilian.weniger@eu.panasonic.com
Velev & Weniger Expires August 28, 2008 [Page 14]
Internet-Draft PMIPv6-MIPv6 RO Issues February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Velev & Weniger Expires August 28, 2008 [Page 15]