Network Working Group A. Qin
Internet-Draft A. Huang
Expires: August 29, 2007 W. Wu
B. Sarikaya
Huawei Technologies
February 25, 2007
PMIPv6 Route Optimization Protocol
draft-qin-mipshop-pmipro-00.txt
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 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Qin, et al. Expires August 29, 2007 [Page 1]
Internet-Draft PMIPv6 Route Optimization February 2007
Abstract
This document defines route optimization protocol for PMIPv6. Proxy
home test, concurrent proxy care-of test and handover procedures are
explained. Proxy mobile agent uses cryptographically generated home
addresses so that no more home test is needed after the initial home
test. Handover home keygen token is used during handover in order to
eliminate home test for the next proxy mobile agent. A different
route optimization protocol is defined for inter-proxy mobile agent
operation if the correspondent node is not Mobile IPv6 enabled.
Qin, et al. Expires August 29, 2007 [Page 2]
Internet-Draft PMIPv6 Route Optimization February 2007
1. Introduction
In Proxy Mobile IPv6 (PMIPv6) scheme, the mobility is transparent to
mobile nodes (MN) by the Proxy Mobility Agent (PMA) simulating a home
link and acting as a proxy on mobile IP operation, also is
transparent to correspondent nodes (CN) by forcing all datagrams for
a mobile node to be routed through its home agent (HA). Thus,
datagrams to the mobile node are often routed along paths that are
significantly longer than optimal. However, packets could be routed
directly between correspondent nodes and the proxy mobile agent
instead of through home agent, such path is optimal. Moreover,
immunity to impersonation, denial of service, and redirection-based
flooding is necessary for a route optimization protocol in PMIPv6.
This document presents a mechanism, based on PMIPv6 [4] and Enhanced
Route Optimization for Mobile IPv6 [5], to securely establish optimal
route path between PMA and correspondent nodes or between two PMAs.
The following types of correspondent nodes are considered:
correspondent nodes which have both Mobile IPv6 stack defined in
RFC3775 and recognize PMIPv6 messages, correspondent nodes without
Mobile IPv6 function which are provided mobility support by Proxy
Mobile IPv6, as well as a fixed correspondent node without mobility.
This document discusses both the first (Type 1 CNs) and the second
(Type 2 CNs).
Type 1 CN's MUST support Enhanced Route Optimization for Mobile IPv6
[5] and extensions defined in this document. PMIPv6 RO is
transparent for Type 2 CNs.
Some terminology is defined in Section 2. Section 3 presents PMIPv6
Route Optimization Protocol for Type 1 CNs and Section 4 presents
inter-PMA route optimization protocol for Type 2 CNs. Section 5
defines home agent, Section 6 defines proxy mobile agent and
Section 7 defines correspondent node behaviour. In Section 8,
formats and options of messages are defined.
2. Terminology
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 [1].
Proxy Mobile Agent (PMA)
The proxy mobile agent is a functional element on the access
router, which is defined in [4]. In PMIPv6, proxy mobile agent
acts an Mobile Ip client agent of MN. In this document, the route
optimization function is also provided by PMA.
Qin, et al. Expires August 29, 2007 [Page 3]
Internet-Draft PMIPv6 Route Optimization February 2007
Proxy Binding Cache
A cache of mobility bindings of mobile nodes, maintained by a
proxy mobile agent for use in sending or forwarding datagrams to
PMAs serving for these mobile nodes.
Cryptographically generated home addresses
A cryptographically generated home address enables correspondent
nodes to securely authenticate the owner of home address (HoA), by
means of a strong, cryptographic binding between the interface
identifier of the address and the address owner's public key.
From the perspective of correspondent node, the home address of
the mobile node is owned by proxy mobile agent during route
optimization procedure. In this document, proxy mobile IPv6 home
addresses are cryptographically generated home addresses using its
mobile node's public key. Home prefix could be per-MN prefix or
shared prefix.
Permanent home keygen token
A secret permanent home keygen token, which is generated by a
correspondent node for a mobile node, is exchanged between proxy
mobile agent and a correspondent node. Permanent home keygen
token is kept by proxy mobile agent. The permanent home keygen
token is used to authenticate the proxy mobile agent more
efficiently in subsequent correspondent registrations. The
permanent home keygen token is renewed as soon as the mobile node
moves to the next proxy mobile agent. Since the lifetime of proxy
binding update is due, permanent home keygen token should be re-
generated too.
Handover home keygen token
A secret handover home keygen token is used during handover, which
is generated by a correspondent node for a mobile node. Handover
home keygen token, kept by proxy mobile agent, is obtained along
with permanent home keygen token at initial time. However, it
will be not out-of-date even though the registration lifetime is
due. During handover, handover home keygen token is transferred
from the previous proxy mobile agent to the next proxy mobile
agent. The next proxy mobile agent uses this token to
authenticate the proxy binding update.
Type 1 Correspondent Node
A node that is Mobile IPv6 enabled to be a correspondent node as
per [2]. Type 1 CNs can receive route optimized traffic from
proxy mobile agents serving their mobile nodes.
Type 2 Correpondent Node
A mobile node that is served by proxy mobile agent. Route
optimization is transparent to Type 2 CNs. Proxy mobile agent
provides both mobility and route optimization services to Type 2
CNs.
Qin, et al. Expires August 29, 2007 [Page 4]
Internet-Draft PMIPv6 Route Optimization February 2007
3. PMIPv6 Route Optimization Protocol
This section consists of a set of approaches to meet requirements of
route optimization for PMIPv6.
3.1. Route Optimization for PMIPv6 Overview
This document describes a route optimization protocol for PMIPv6.
This protocol is based on PMIPv6 and Enhanced Route Optimization for
Mobile IPv6.
Once a mobile node enters its Proxy Mobile IPv6 domain, proxy mobile
agent which runs on the access router does the mobility related
signaling on behalf of the mobile node. In MIPv6, a mobile node may
determine when and which correspondent node needs route optimization.
In contrast, access router MAY inform proxy mobile agent to initiate
route optimization procedure according to some policies in PMIPv6.
The configuration of such policies is out of scope.
As soon as proxy mobile agent makes decision on which correspondent
node needs route optimization, proxy mobile agent initiates proxy
home test procedure depicted in Section 3.2. Correspondent nodes
verify the reachability of home address via this procedure.
Correspondent nodes also need to verify the reachability of care-of
address. Proxy care-of test init message is piggybacked on a proxy
binding update message which is sent by proxy mobile agent on behalf
of the mobile node to register with a correspondent node. After the
first round trip of proxy binding update exchange is over between a
correspondent node with proxy mobile agent, the correspondent node
sets up a binding cache entry and MAY start routing packets directly
to care-of address of the mobile node even though the care-of address
is not verified. However, the proxy mobile agent obtains care-of
keygen token via this round trip of proxy binding update exchange.
The proxy mobile agent MAY initiate another proxy binding update
exchange. Thus, the correspondent node MAY authenticate this proxy
binding update with both temporary home keygen token and care-of
keygen token, and then it makes sure of the validity of proxy binding
cache entry created by early proxy binding update exchange. In order
to protect against redirection-based flooding attacks, Credit-Based
Authorization (CBA) can be exploited as described in [5].
During handover, the next proxy mobile agent simulates home link for
the mobile node. For the sake of security, proxy home test should be
executed over again for correspondent node to verify the rachability
and validity of home address of MN. In order to reduce handover
latency brought up with the proxy home test, handover home keygen
Qin, et al. Expires August 29, 2007 [Page 5]
Internet-Draft PMIPv6 Route Optimization February 2007
token is introduced in Section 3.4.
In PMIPv6 route optimization protocol, the proxy home test and proxy
care-of test exchanges are initiated by PMA instead of MN. However,
both the source address of proxy home test init message and the
destination address of proxy home test message are home address of
mobile node. So, the proxy mobile agent MUST identify, intercept and
process the home test messages.
For the sake of security, cryptographically generated home addresses
and permanent home keygen token, defined in [5], are used in PMIPv6
route optimization (PMIPv6RO) protocol. Cryptographically generated
home addresses, CGA parameters and signature are calculated with the
mobile node's public key and private key by each PMA the mobile node
visits. The input parameters to the CGA calculations [3] like the
subnet prefix, public key and private key are available to each PMA.
One possible mechanism is context transfer from the previous PMA. In
order to decrease handover latency, handover home keygen token is
introduced in PMIPv6RO as a credential for the next proxy mobile
agent to be more efficient by means of eliminating home test
procedure.
As shown in Figure 1, the optimal route path is depicted by slashes
which connect correspondent node with proxy mobile agent.
+------+ +----+
| HA |-------------------| CN |
+------+ +----+
| HAA |
| +--------------------+
// \\ / /
// \\/ /
+---------//-----/--------------------/--+
| // / \\ PMIP Network / |
+-------//-----/----\\--------------/----+
// / \\ /
// / \\ /
//+----+ \\+-------/
CoA1 | | | CoA2
+----+ +----+
|PMA1|<- policies |PMA2|<- policies
+----+ for RO +----+ for RO
| |
-.-.-> [MN] HoA
Figure 1: PMIPv6 Route Optimization Operation
Qin, et al. Expires August 29, 2007 [Page 6]
Internet-Draft PMIPv6 Route Optimization February 2007
3.2. Proxy Home Test Procedure
Proxy Home Test procedure validates the home address. It includes
two messages as follows:
Proxy Home Test Init (Proxy HoTI)
Proxy Home Test (Proxy HoT).
Since the destination address of Proxy HoT message is the home
address of MN, the PMA MUST intercept and process Proxy Home Test
message instead of forwarding it to MN.
When handoff occurs, correspondent nodes must re-verify the
reachability of home address. The next proxy mobile agent MAY also
initiate the proxy home test. Proxy mobile agent must keep
correspondent nodes list in its Binding Update List. When MN roams
into the next PMA, these Binding Update List entries SHOULD be
transferred to the next PMA using context transfer protocol or other
protocols. When MN roams into the next PMA, the entries in the
Binding Update List on MN identity like NAI, private and public keys,
etc. SHOULD be transferred to the next PMA. The context transfer
protocol is out of scope.
As shown in Figure 2, the proxy mobile agent imitates the Mobile IP
client of the mobile node. The Proxy Home Test Init (PHoTI) message
is sent from PMA to the correspondent node, and it should be
transmitted via the shared tunnel between the Home Agent and PMA.
Proxy Mobile Agent Home agent Correspondent node
According to some policies
Decide to optimize route path | |
| | |
|==Proxy Home Test Init (PHoTI)=>|---------------------->|
| | |
| | |
|<====Proxy Home Test (PHoT)=====|<----------------------|
| | |
Figure 2: Proxy Home Test Procedure
3.3. Concurrent Proxy Care-of Test
Correspondent nodes also need to prove the reachability of care-of
address. In this document, since the care-of test is initiated by
proxy mobile agent instead of by mobile node, we call it as proxy
care-of test procedure in order to differentiate the procedure from
the definition in MIPv6 [2].
Qin, et al. Expires August 29, 2007 [Page 7]
Internet-Draft PMIPv6 Route Optimization February 2007
Proxy care-of test is piggybacked on a proxy binding update which is
sent by proxy mobile agent on behalf of the mobile node to register
with a correspondent node. The care-of test is done concurrently
with proxy binding update exchange, so we call it concurrent proxy
care-of test. As shown in Figure 3, as a correspondent node receives
a proxy binding update message, which contains care-of test init
option, the CGA Parameters and Signature options, it returns a
care-of keygen token in care-of test option piggybacked onto proxy
binding acknowledgement (PBA) message. The mechanism is as described
in [5].
After the first round trip of proxy binding update exchange is over
between a correspondent node with proxy mobile agent, the
correspondent node sets up a binding cache entry and may route
packets directly to care-of address of the mobile node even though
the care-of address is not verified. However, the proxy mobile agent
obtains care-of keygen token via this round trip of proxy binding
update exchange. The proxy mobile agent may initiate another proxy
binding update exchange. Thus, the correspondent node may
authenticate this proxy binding update with both temporary home
keygen token and care-of keygen token, and then it makes sure that
the proxy binding cache entry created by early proxy binding update
exchange is legitimate. In order to protect against redirection-
based flooding attacks, Credit-Based Authorization is also exploited,
which is already introduced in [5].
If proxy mobile agent has only temporary home keygen token instead of
permanent home keygen token, the proxy mobile agent calculates the
Binding Authorization Data option field of early proxy binding update
message with temporary home keygen token and care-of keygen token
which is set to ZERO. Proxy mobile agent calculates CGA parameters
and signature option according to MN's home address and private and
public keys to be sent in a proxy binding update message to acquire
permanent home keygen token and handover home keygen token.
If proxy mobile agent has permanent home keygen token, proxy mobile
agent calculates the Binding Authorization Data option field of early
proxy binding update with permanent home keygen token and care-of
keygen token which is set to ZERO. No CGA parameters and signature
are required.
If proxy mobile agent has only handover home keygen token, the proxy
mobile agent calculates the Binding Authorization Data option field
of early proxy binding update message with handover home keygen token
and care-of keygen token which is set to ZERO. In order to renew
permanent home keygen token and handover home keygen token, proxy
mobile agent must include MN's CGA parameters and signature in this
early proxy binding update.
Qin, et al. Expires August 29, 2007 [Page 8]
Internet-Draft PMIPv6 Route Optimization February 2007
Concurrent proxy care-of test procedure should proceed as soon as
mobile node moves into the next PMA. To save handoff latency,
concurrent proxy care-of test is piggybacked onto early proxy binding
update exchange. As handoff occurs, the next proxy mobile agent
calculates the Binding Authorization Data option for early proxy
binding update based on handover home keygen token if the next proxy
mobile agent has already obtained the handover home keygen token.
The next proxy mobile agent and correspondent nodes can resume
communication, while care-of address reachability verification
proceeds concurrently. The amount of data, which the correspondent
node is permitted to send to care-of address until reachability
verification completes, is governed by Credit-Based Authorization.
This mechanism conforms to [5].
Proxy Correspondent
Mobile Agent Node
| |
| -------Early Proxy Binding Update------------>|
| (care-of test init option) |
| |
| <------Proxy Binding Acknowledgement----------|
| (care-of test option) |
| |
Figure 3: Concurrent Proxy Care-of Test
3.4. Handover
Route optimization during handover is shown as Figure 4.
If the previous proxy mobile agent forecasts the forthcoming handover
of mobile node via layer 2 indication, such as link going down event
in the Media-Independent Handover, the previous proxy mobile agent
MAY transfer handover context to the next proxy mobile agent in
advance. The handover home keygen token and other key parameters
could help the next proxy mobile agent to pass the verification of
home address required by correspondent nodes. The next proxy mobile
agent MAY fetch the handover home keygen token through home agent via
proxy binding update exchanges with the home agent of mobile node.
After the mobile node left the previous proxy mobile agent, the
previous proxy mobile agent deregisters the proxy binding cache entry
with correspondent nodes. The correspondent node revokes permanent
home keygen token. After the next proxy mobile agent obtains
handover home keygen token, it sends out proxy binding update
piggybacked by care-of test init option to correspondent nodes.
As depicted in Figure 4, after the next proxy mobile agent obtains
Qin, et al. Expires August 29, 2007 [Page 9]
Internet-Draft PMIPv6 Route Optimization February 2007
the care-of keygen token via early proxy binding update and
acknowledges messages, the binding cache entry is generated but
unverified in the correspondent node. As soon as the complete proxy
binding update message is received by the correspondent node, the
binding cache entry could be verified. This proxy binding update
contains CGA parameters and signature option with proxy mobile
agent's public key and private key to request care-of keygen token.
The correspondent node receives the proxy binding update and
authenticates it with handover home keygen token and with CGA
property. If the proxy binding update passes the verification, the
correspondent node returns a care-of keygen token which is encrypted
with the next proxy mobile agent's public key. The care-of keygen
token is encrypted and sent over proxy binding acknowledgement
message as a field. As soon as the next proxy mobile agent receives
this proxy binding acknowledgement, it sends a complete proxy binding
update message to the correspondent nodes. Binding Authorization
Data option of the complete proxy binding update message is
calculated using both care-of keygen token and handover home keygen
token.
Previous Next Correspondent
Proxy mobile Agent Proxy mobile agent node
| Handover context | |
|----------------------->| |
|(HoA,CN address,handover| |
|home keygen token) | |
handover \\ \\ |
| Proxy binding update(lifetime = 0) |
|------------------------------------------------------>|
| Proxy binding Acknowledge (if sent) |
|<------------------------------------------------------|
| | Early Proxy Binding Update |
| |----------------------------->|
| | Proxy Binding Acknowledge |
| |<-----------------------------|
| | Complete Proxy Binding Update|
| |----------------------------->|
| |Proxy Binding Acknowledge |
| |<-----------------------------|
| |(new Permanent, |
| |Handover home keygen token) |
| | |
Figure 4: Route Optimization during Handover Procedure
Qin, et al. Expires August 29, 2007 [Page 10]
Internet-Draft PMIPv6 Route Optimization February 2007
3.5. Complete Proxy Binding Update
A complete proxy binding update is a proxy binding update defined in
[4]. After proxy binding update which piggybacks care-of test
exchanges is finished, a complete proxy binding update must be
brought forward. The Binding Authorization Data option field of it
is calculated by care-of keygen token for correspondent nodes to
verify the reachability of care-of address and authenticate the
legitimacy of the PMA which is sending this message on behalf of MN.
The complete proxy binding update is exchanged as depicted in
Figure 5.
After proxy care-of test is processed, the complete proxy binding
update exchange follows Figure 5. PBU message must be sent with CGA
parameters and signature option for the proxy mobile agent to request
permanent home keygen token and handover home keygen token from the
correspondent node. A CGA provides a strong binding between its
interface identifier and the CGA owner's public key. This enables
other nodes to securely authenticate the CGA owner. Depending on the
strong security brought up with Cryptographically generated home
addresses, lifetime of binding is extended to a longer period more
than 7 minutes [2]. Except for the initial test, the following home
tests every 7 minutes are no longer needed.
The correspondent node MUST authenticate the complete proxy binding
update message based on the CGA property of the mobile node's home
address. If the proxy mobile agent has only temporary home keygen
token, and then the proxy mobile agent uses it to calculate the
Binding Authorization Data option for the complete proxy Binding
Update message.
If the proxy mobile agent has permanent home keygen token, the proxy
mobile agent uses it to calculate the Binding Authorization Data
option. The home nonce index is set to ZERO.
If the permanent home keygen token is required, both permanent home
keygen token and handover home keygen token are generated and
encrypted with the proxy mobile agent's public key. Both of the two
tokens are transferred from correspondent node to the next proxy
mobile node via the proxy binding acknowledgement response to the
complete proxy binding update message. This new handover home keygen
token will be exploited when the next handover occurs.
The PBA MAY be protected by CGA property of correspondent nodes. If
another proxy mobile agent is sending PBA on behalf of the
correspondent node, that proxy mobile agent SHOULD use its own CGA
property to protect PBA instead of the correspondent node's CGA
property.
Qin, et al. Expires August 29, 2007 [Page 11]
Internet-Draft PMIPv6 Route Optimization February 2007
Proxy Correspondent Node
Mobile Agent
| Complete Proxy Binding Update |
|--------------------------------------------->|
| (CGA parameters, signature, home nonce index)|
| |
| |
| Proxy Binding Acknowledgement |
|<---------------------------------------------|
|(Permanent home keygen token, |
| Handover home keygen token) |
| |
| |
Figure 5: Complete Proxy Binding Update
4. Route Optimization for Correspondent Nodes without Mobile IP
This section describes route optimization procedure for correspondent
nodes which are not Mobile IP enabled. Trigerring and scenario
analysis are made. Two kinds of solutions are proposed: one without
return routability and the other with return routability.
4.1. Triggering and Scenario Analysis
Route optimization in Mobile IPv6 is an end-to-end operation. Once
mobile node and correspondent node complete the route optimization
procedure, all of communications between them will be optimized. In
Proxy Mobile IP, however, proxy mobile agent is not the communication
end but an intermediary router. Generally proxy mobile agent may not
be able to judge whether the packets need to be optimized or not.
So, it MAY be necessary to define a mechanism that allows mobile node
to inform the proxy mobile agent of its route optimization
requirement about its communication with the specific correspondent
node, or just let PMA to optimize all of the communications between
mobile node and other nodes.
A flag could be defined to identify two route optimization trigger
modes: implicit mode that means that it's up to proxy mobile agent to
decide and perform route optimization for mobile node, or explicit
mode that means mobile node MUST send a message to trigger proxy
mobile agent to perform route optimization for mobile node. The flag
of route optimization trigger mode can also be configured in a policy
store, such as in AAA infrastructure. After successful access
authentication and authorization, proxy mobile agent gets this flag
as part of the user profile from AAA infrastructure. On this point
route optimization can be considered as a kind of service that
Qin, et al. Expires August 29, 2007 [Page 12]
Internet-Draft PMIPv6 Route Optimization February 2007
network provides to mobile users.
Assuming that both mobile node and correspondent node are using Proxy
Mobile IPv6, there are four possible scenarios/cases due to the
different location of correspondent node: mobile node and
correspondent node attach to the same proxy mobile agent and they
belong to the same home agent (case 1), mobile node and correspondent
node attach to the same proxy mobile agent but they belong to
different home agents (case 2), mobile node and correspondent node
attach to different proxy mobile agents, but they have the same home
agent (case 3), mobile node and correspondent node attach to
different proxy mobile agents, and they have different home agents
(case 4).
Cases 1 and 2 do not require any signaling between PMAs and packets
can be locally routed. As mobile node and correspondent node both
attach to the same PMA and this PMA performs registration process on
behalf of them and maintains Binding Update List for them. When PMA
receives the packets from mobile node or correspondent node, proxy
mobile agent SHOULD look up the Binding Update List to check whether
or not the destination IP address in the IP packet appears in the
Binding Update List as home address. If yes, it means proxy mobile
agent has registered with home agent on behalf of destination node
and proxy mobile agent SHOULD directly forward the packet on the
connected interface instead of sending the packet to the home agent
through the bi-directional tunnel.
In cases 3 and 4, mobile node and correspondent node attach to
different PMAs, the ideal data path is to directly go through these
two PMAs to which mobile node and correspondent node attach. A bi-
directional tunnel needs to be established between these two proxy
mobile agents for route optimization.
Proxy mobile agent needs to know IP address of the corresponding PMA
to which correspondent node attaches so that it can initiate the
route optimization signaling process. HA of CN knows it because IP
address of corresponding PMA has been registered with the home agent
as the care-of address of CN. Proxy mobile agent can send a request
to the home agent of CN and ask for the Binding Cache Entry for the
correspondent node if it knows the IP address of that home agent.
Another method of obtaining PMAs' addresses is by exchanging them in
home test messages during return routability signaling. Modified
PHoTI and PHoT messages can be used for this purpose.
In Section 4.2 we present a route optimization technique based on
obtaining IP address of the corresponding PMA from the home agent and
in Section 4.3 based on return routability procedure.
Qin, et al. Expires August 29, 2007 [Page 13]
Internet-Draft PMIPv6 Route Optimization February 2007
4.2. Route Optimization without Return Routability
A possible route optimization process is illustrated in Figure 6,
where PMA1 performs route optimization process for communication
between MN1 and CN4 whose corresponding PMA is PMA3 and HA is HA2.
After getting home agent address of CN4, PMA1 first sends the request
with home address of CN4 to HA2 to inquire the IP address of PMA3.
HA2 looks up the Binding Cache and responds with the care-of address
of CN4.
PMA1 sends Proxy Binding Update to PMA3 to register the home address
of MN1 and IP address of PMA1 as care-of address with PMA3. PMA3
stores this information in the Binding Cache entry for the MN1 and
responds with another Proxy Binding Update sent to PMA1 which
interprets it as an acknowledgement as well. PMA1 sends Proxy
Binding Acknowledgement to PMA3 to confirm the registration request.
After this three-way handshake procedure, Binding Cache Entries for
MN1 and CN4 have been created in PMA3 and PMA1 respectively. The
packets between MN1 and CN4 can go through the bi-directional tunnel
between PMA1 and PMA3 to reach each other.
PMA1 HA2 PMA3
| | |
| Binding Cache Request/Ack | |
|<---------------------------->| |
| | |
| |
| Proxy Binding Update |
|----------------------------------------->|
| Proxy Binding Update |
|<-----------------------------------------|
| Proxy Binding Acknowledgement |
|----------------------------------------->|
| |
Figure 6: 3-way Handshake
4.2.1. Tunnel Re-establishment During the Handover
Suppose a bi-directional tunnel has been established for route
optimization in case 4, handover happens when MN1 moves from PMA1 to
PMA2 and PMA2 registers with HA1 on behalf of MN1 after performing
access authentication Figure 7. After the handover, PMA3 MUST be
informed of the mobility of MN1, or the packets from CN4 to MN1 will
still be sent to PMA1 because the Binding Cache Entry for MN1 hasn't
been updated in PMA3. In fact, the one end of tunnel has changed
from PMA1 to PMA2 due to handover, and the tunnel MUST be re-
Qin, et al. Expires August 29, 2007 [Page 14]
Internet-Draft PMIPv6 Route Optimization February 2007
established for route optimization.
+-----+ +-----+
| HA1 |~~~~~~~~~~~~~~~~~| HA2 |
/+-----+\\ +-----+\\
// \\ \\
// \\ \\
// \\ \\
// \\ \\
// \\ \\
+----+ +----+ +----+
|PMA2|~~~~~~~~~~~~~~~~~~|PMA1|~~~~~~~~~~~~~~~|PMA3|
+--+-+ +-+--+ +-+--+
| | |
| | |
-----+---- ----+------- ---+--+--
|
+-----+ +--+--+
<-----| MN1 | | CN4 |
+-----+ +-----+
Figure 7: Handover Scenario
The context transfer of Binding Update List entry for mobile node can
trigger the new proxy mobile agent to re-establish the tunnel for
route optimization so that route optimized communication can continue
after handover.
An example for route optimization signaling flow during handover is
depicted in Figure 8. Here, the handover is controlled by network in
a reactive mode, where new proxy mobile agent (PMA2) sends Context
Transfer Request message to old proxy mobile agent (PMA1) and PMA1
responds with Context Transfer Data message which carries user
profiles and Binding Update List entries for MN1. PMA2 SHOULD send
Proxy Binding Update message to corresponding proxy mobile agent
(PMA3 here) according to each Binding Update List entry. The
following flow is the same as all that described in Section 4.2
Qin, et al. Expires August 29, 2007 [Page 15]
Internet-Draft PMIPv6 Route Optimization February 2007
PMA1 PMA2 PMA3
| | |
| Context Transfer Request | |
|<---------------------------| |
| | |
| Context Transfer Data | |
|--------------------------->| |
| | |
| Proxy Binding Update |
|-------------------------------->|
| Proxy Binding Update |
|<--------------------------------|
| Proxy Binding Acknowledgement |
|-------------------------------->|
| |
Figure 8: RO in Handover
4.3. Route Optimization with Return Routability
If a proxy mobile agent provides mobility service for correspondent
nodes, PMIPv6 Route Optimization protocol could be used for such
correspondent nodes, as long as the proxy mobile agent intercepts and
processes route optimization extensions via looking over the MH types
and distinguishing Proxy Mobile IP signaling from data. The process
is shown in Figure 9. The proxy home test init message is
transmitted over the shared tunnel between proxy mobile agent of
mobile node and home agent of mobile node. This proxy home test init
message is forwarded to home address of the correspondent node by HA.
At the home agent of the correspondent node, this message is
tunnelled into the shared tunnel between the home agent of
correspondent node and the proxy mobile agent of the correspondent
node.
The proxy mobile agent of CN intercepts proxy home test init message
and extracts MN's home address and care-of address from PHoTI. PMA
of CN sends a proxy home test message back to PMA of MN and adds
care-of address of CN into PHoT message. PMA of CN creates a Binding
Cache entry for this MN. PHoT is transmitted over the shared tunnel
between PMA of CN and HA of CN. HA of CN forwards this message to
the home address of MN which tunnels it to PMA of MN.
PMA of MN receives PHoT message, it extracts the care-of address of
CN and adds this information to the Binding Cache entry for CN. PMA
of CN next starts care-of test signaling by sending an early binding
update message directly to the care-of address of CN, i.e. to PMA of
CN.
Qin, et al. Expires August 29, 2007 [Page 16]
Internet-Draft PMIPv6 Route Optimization February 2007
Due to the address exchange using PHoTI and PHoT messages, care-of
test signaling in Figure 9 MUST NOT be started in parallel to home
test signaling.
Proxy Home Agent(MN) Home Agent(CN) Proxy
Mobile Agent(MN) Mobile Agent(CN)
| Proxy HoTI | | |
|===============>|-------------->|===============>|
| Proxy HoT | | |
|<===============|<--------------|<===============|
| Early Proxy Binding Update | |
|------------------------------------------------>|
| Proxy Binding Acknowledgement| |
|<------------------------------------------------|
| Complete Proxy Binding Update| |
|------------------------------------------------>|
| Proxy Binding Acknowledgement| |
|<------------------------------------------------|
| | |
Figure 9: Route Optimization for Correspondent nodes without mobile
ip
5. Home Agent Considerations
The home agent MUST drop all HoTI messages received from a home
address that has corresponding Binding Cache entry with the proxy
registration flag set. The home agent MUST forward all Proxy HoTI
messages received from a home address that has corresponding Binding
Cache entry with the proxy registration flag set.
6. Proxy Mobile Agent Considerations
PMA, after successful Home and Care-of Test exchanges, creates a
Binding Cache entry for the correspondent node or PMA of the
correspondent node. For each mobile node, the Binding Cache contains
one entry for each correspondent node. After handover, PMA deletes
the Binding Cache entry and deregisters MN with all its correspondent
nodes.
PMA MUST maintain a Binding Update List for each MN. The fields are
as defined in [2] and with extensions defined in [4]. For each MN
for which route optimization service is offered, the list in addition
MUST contain the private and public keys of MN. Apart from home
registrations as in [4], Binding Update List contains correspondent
registrations for route optimization.
Qin, et al. Expires August 29, 2007 [Page 17]
Internet-Draft PMIPv6 Route Optimization February 2007
After handover, correspondent registration entries in the Binding
Update List SHOULD be transferred to the next PMA. Such a transfer
provides continuity of correspondent registrations for route
optimization. The next PMA refreshes such registrations only after
lifetime expiry.
PMA MUST maintain a Binding Cache if it has Type 2 CNs. Binding
cache entries are created when PMA receives a home test init message.
This Binding Cache is called Proxy Binding Cache.
From the correspondent nodes PMA receives data packets with Type 2
routing header. Type 2 routing header MUST conform to the structure
given in Section 6.1.5 of [2]. PMA MUST process the packet as
follows: PMA replaces the source address with the home address given
in Type 2 routing header. PMA removes Type 2 routing header. PMA
sends the packet to MN.
PMA MUST not include IPv4 home address option [6] in proxy binding
updates sent for route optimization. PMIPv6 route optimization for
dual-stack nodes is TBD.
7. Correspondent Node Considerations
This section state the differences in the behaviour of a
correspondent node that conforms to Section 9 of [2].
Upon receiving a Proxy Home Test Init message, Early Proxy Binding
Update and Complete Proxy Binding Update message, the correspondent
node verifies the following: The packet MUST NOT include a Home
Address destination option. The correspondent node MUST silently
ignore such packets.
After a successful Home and Care-of Test exchanges, the correspondent
node creates a Binding Cache entry for the proxy mobile agent
proxying the mobile node. The entry MUST be deleted after the
expiration of its lifetime or after receiving a proxy binding update
message which deregisters the mobile node.
Correspondent node MUST receive route optimized data packets from PMA
encapsulated in IP-in-IP encapsulation. Source address of the outer
header MUST be equal PMA's egress interface address and MUST match
the Binding Cache entry. CN MUST remove the outer header before
passing the packet to the upper layers.
CN MUST use Type 2 routing header in outgoing packets to PMA. The
destination address is PMA's egress interface address which serves as
Care-of address for the mobile node and the type 2 routing header
Qin, et al. Expires August 29, 2007 [Page 18]
Internet-Draft PMIPv6 Route Optimization February 2007
contains MN's home address.
8. Message Formats
This section defines extensions to the Proxy Mobile IPv6 [4] protocol
messages and the enhanced route optimization in MIPv6 protocol
messages [5].
8.1. Proxy Home Test
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Proxy Home Test
A new MH type should be assigned by IANA.
Home Keygen Token
This field contains the 64 bit temporary home keygen token used to
authenticate the proxy binding update.
Care-of Address
This field contains the care-of address assigned to the CN by PMA.
For descriptions of other fields present in this message, refer to
section 6.1.5 in [2].
Qin, et al. Expires August 29, 2007 [Page 19]
Internet-Draft PMIPv6 Route Optimization February 2007
8.2. Proxy Home Test Init Message
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Proxy Home Test Init
A new MH type should be assigned by IANA.
Care-of Address
This field contains the care-of address assigned to the mobile
node by PMA.
For descriptions of other fields present in this message, refer to
section 6.1.5 in [2].
8.3. Handover Home Keygen Token option
Handover home keygen token is a mobility option. It is sent by CN in
proxy binding acknowledgement message.
Qin, et al. Expires August 29, 2007 [Page 20]
Internet-Draft PMIPv6 Route Optimization February 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
: Handover Home Keygen Token :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Handover Home Keygen Token option
Option Type
8-bit identifier of the type of this mobility option. Its value
is TBD.
Option Length
8-bit unsigned integer representing the length of the Handover
Home Keygen Token field in octets.
Handover Home Keygen Token
This field contains the Handover home keygen token generated by
the correspondent node. The content of this field MUST be
encrypted with the proxy mobile agent's public key. The length of
the handover home keygen token is 8 octets before encryption.
After it is encrypted, this field may be longer than 8 octets.
9. Security Considerations
Security mechanism is very important in the route optimization
process, especially for the proposal of establishing the tunnel
between two proxy mobile agents. In the case of route optimization
without return routability, if proxy mobile agent does not
authenticate Proxy Binding Update and Proxy Binding Acknowledge
messages, a malicious node may send such signaling messages to proxy
mobile agents to get the data packets destined for other nodes
directed to itself.
In addition, when proxy mobile agent sends data packets through the
bi-directional tunnel between two proxy mobile agents, corresponding
PMA SHOULD examine the data packets to make sure there is a Binding
Cache entry for the data source terminal.
Route optimization signaling between PMA of MN and CN specified in
this document is based on [5] and use return routability with better
security properties than the return routability of the base protocol
Qin, et al. Expires August 29, 2007 [Page 21]
Internet-Draft PMIPv6 Route Optimization February 2007
[2].
Return routability signaling between two PMAs specified in this
document is also based on [5] and has better security properties.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[4] Gundavelli, S., "Proxy Mobile IPv6",
draft-sgundave-mip6-proxymip6-01 (work in progress),
January 2007.
[5] Arkko, J., "Enhanced Route Optimization for Mobile IPv6",
draft-ietf-mipshop-cga-cba-03 (work in progress), February 2007.
10.2. Informative references
[6] Soliman, H., "Mobile IPv6 support for dual stack Hosts and
Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-03 (work in
progress), October 2006.
Authors' Addresses
Alice Qin
Huawei Technologies
No.91 BaiXia Rd.
Nanjing, Jiangsu 210001
China
Email: Alice.Q@huawei.com
Qin, et al. Expires August 29, 2007 [Page 22]
Internet-Draft PMIPv6 Route Optimization February 2007
Andy Huang
Huawei Technologies
No.91 BaiXia Rd.
Nanjing, Jiangsu 210001
China
Phone: +86-25-84565457
Email: hpanda@huawei.com
Wenson Wu
Huawei Technologies
No.91 BaiXia Rd.
Nanjing, Jiangsu 210001
China
Phone: +86-25-84565459
Email: sunseawq@huawei.com
Behcet Sarikaya
Huawei Technologies
1700 Alma Dr. Suite 100
Plano, TX 75075
Email: sarikaya@ieee.org
Qin, et al. Expires August 29, 2007 [Page 23]
Internet-Draft PMIPv6 Route Optimization February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Qin, et al. Expires August 29, 2007 [Page 24]