One document matched: draft-cui-mext-route-optimization-cn-proxy-00.txt
Internet Engineering Task Force X. Cui, Ed.
Internet-Draft Huawei Technologies
Intended status: Informational A. Makela, Ed.
Expires: January 5, 2012 Aalto University, Department of
Communications and
Networking (Comnet)
P. McCann, Ed.
Huawei Technologies
July 4, 2011
Proxy Correspondent Node Operation for Mobile IPv6 Route Optimization
draft-cui-mext-route-optimization-cn-proxy-00
Abstract
Route Optimization is an useful aspect of Mobile IPv6. In Route
Optimization mode Mobile Node (MN) can communicate with Correspondent
Node (CN) without the involvement of MN's home agent. However, there
are some limitations to this feature, including that the Mobile Node
and the Correspondent Node must both be capable of Route
Optimization. This document introduces a Route Optimization Proxy
function used for Route Optimization which can be used to enable
Route Optimization between Mobile Node and arbitrary IP node - the
Route Optimization functions are delegated to the Proxy. The Route
Optimization Proxy function may be implemented in the access router
attached to the CN or any other node present on the path between MN
and CN, and the Route Optimization Proxy can conduct RO-related
signaling and accomplish the Route Optimization procedure on behalf
of the Correspondent Node.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 5, 2012.
Cui, et al. Expires January 5, 2012 [Page 1]
Internet-Draft Route Optimization Proxy July 2011
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scenario analysis and use case . . . . . . . . . . . . . . . . 4
3.1. Route Optimization Requirement from Other SDOs . . . . . . 4
3.2. Issues if the CN doesn't support Route Optimization . . . 5
3.3. Previous analysis of the problem and proposed solutions . 6
3.4. Use case for Route Optimization proxy . . . . . . . . . . 7
3.5. Additional motivation for Route Optimization Proxy . . . . 10
4. Concerns on different approaches for initiating Route
Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Static Shared Key Authorization . . . . . . . . . . . . . 12
4.2. Enhanced Route Optimization . . . . . . . . . . . . . . . 12
5. Route Optimization Proxy operation . . . . . . . . . . . . . . 13
5.1. Requirements on Route Optimization Proxy . . . . . . . . . 13
5.2. Route Optimization Proxy operation . . . . . . . . . . . . 14
5.2.1. Incoming Flow Transmission . . . . . . . . . . . . . . 15
5.2.2. Outgoing Flow Transmission . . . . . . . . . . . . . . 17
5.2.3. Conceptual Data Structures . . . . . . . . . . . . . . 17
6. Configuration Variables . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Cui, et al. Expires January 5, 2012 [Page 2]
Internet-Draft Route Optimization Proxy July 2011
1. Introduction
Mobile IPv6 protocol [RFC3775] provides a mobility support to basic
IPv6 and introduces Route Optimization (RO) mechanism. Route
Optimization enables mobile node (MN) to establish a direct
communications path between Mobile Node(MN) and correspondent node
(CN) without the involvement of MN's home agent (HA).
Route Optimization typically requires Mobile Node and Correspondent
Node to have certain capabilities, such as possibility to conduct
Return Routability procedure - MN transmitting Home Test Init (HoTI),
Care-of Test Init (CoTI) and direct Binding Update messages to CN,
and CN responding with respective Home Test (HoT), Care-of Test Init
(CoT), and Binding Acknowledgement messages to MN.
If the correspondent node is a basic IP node without support for
Route Optimization, the MN with support for Route Optimization can't
set up Route Optimization to this CN, as RFC 3775 [RFC3775] specifies
"If a mobile node attempts to set up route optimization with a node
with only basic IPv6 support, an ICMP error will signal that the node
does not support such optimizations and communications will flow
through the home agent".
From the MN's viewpoint, the IPv6 nodes with support for MIP and IPv6
nodes without support for MIP are using the unified address space, so
the MN can't distinguish whether a correspondent node is a RO-capable
node or a non-RO-capable node. When the network is composed of
mobile IPv6 nodes, IPv6 nodes with support for Route Optimization and
enormous quantity of basic IPv6 nodes without Route Optimization
support, a lot of Route Optimization attempts are made for naught as
they are prone to fail.
The result is that Route Optimization has a deployment problem
because specific functionalities are required from CNs. However, if
we can delegate that functionality to occur on network level (e.g.
In an access router) it might be a help toward getting wider
deployment for RO. For this purpose, this document introduces a
mechanism for such delegation - a Route Optimization Proxy - , which
can be used to obtain Route Optimization for IP nodes with only
support for basic IPv6 protocol.
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 RFC 2119 [RFC2119].
Cui, et al. Expires January 5, 2012 [Page 3]
Internet-Draft Route Optimization Proxy July 2011
All the mobility related terms used in this document are to be
interpreted as defined in the Mobile IPv6 specification [RFC3775].
This document also provides the following context-specific
explanation to the following terms used in this document.
Route Optimization Proxy (ROP)
Route Optimization Proxy is the logical function that acts
on behalf of the CN to achieve Route Optimization with MN.
The Route Optimization Proxy entity MUST be present on the
path on both directions between MN and CN.
Proxy Binding Cache (PBC)
The Proxy Binding Cache is the cache of for binding source
nodes and destination nodes together and is maintained by
the Route Optimization Proxy entity. The cache contains
associations of Home Address of the source node, the
Care-of Address(s) of the source(Mobile) node and the IP
address of the destination (Correspondent) node. Note the
Proxy Binding Cache can, if permitted, support Multiple
Care-of Addresses Registration defined in [RFC5648], in a
single Proxy Binding Cache entry.
3. Scenario analysis and use case
3.1. Route Optimization Requirement from Other SDOs
Route Optimization is specified in RFC 3775 [RFC3775] and also
adopted by other SDOs, such as 3GPP2, because Route Optimization can
provide better performance and avoid bottleneck at the Home Agent.
3GPP2 has highlighted the requirements and feature description in
3GPP2 documents.
Section 4.4 "MIP6" of [X.S0011-001-D] is about MIP6 protocol and
Figures 13 and 16 in this section illustrate the protocol reference
model for MIP6 Route Optimization mode.
Section 5.3 "Home Agent Requirements" of [X.S0011-002-D] introduces
the requirements of Home Agent on Route Optimization, as specified in
section 5.3.6 "Return Routability Support for Route Optimization":
"The Home Agent shall support Return Routability (RR) for Route
Optimization as specified in RFC 3775 [RFC3775] with the exception
that IPsec is not used to protect the RR messages".
Section 6 "MIP6 Route Optimization" of [X.S0047-0] introduces the
Cui, et al. Expires January 5, 2012 [Page 4]
Internet-Draft Route Optimization Proxy July 2011
requirements of mobile node on Route Optimization, as specified in
section 6.1 "MS Requirements", "The MS may support the return
routability procedure, binding update procedure, and packet
processing for the Mobile Node Operation and Correspondent Node
Operation, according to RFC 3775 [RFC3775]".
Based on these statement, MN and HA in a 3GPP2 network can support
Route Optimization already, however, the Correspondent node would
disregard the Route Optimization procedure just like a basic IP node.
3.2. Issues if the CN doesn't support Route Optimization
If the correspondent node does not support Route Optimization, the
correspondent node will reply an with an ICMP Parameter Problem, Code
1, message to the Mobile Node who attempted to initiate Route
Optimization. The process is shown in Figure 1.
MN HA Network AR CN
| | | | |
(a) ============= the CN is a node with basic IP ==========
| | | | |
| HoTI | | | |
(b) |---------->| HoTI | | |
(c) | |------------>| HoTI | |
(d) | | |---------->| HoTI |
(e) | | | |---------->|
| | | | ICMP(err) |
(f) | | | |<----------|
| CoTI | | |
(g) |------------------------>| CoTI | |
(h) | | |---------->| CoTI |
(I) | | | |---------->|
| | | | ICMP(err) |
(j) | | | |<----------|
| ICMP(err) | | | |
(k) |<----------| | | |
| | | | |
| | | | |
Figure 1: Issue in Route Optimization
The detailed descriptions of events in are as follows:
Cui, et al. Expires January 5, 2012 [Page 5]
Internet-Draft Route Optimization Proxy July 2011
(a) Scenario:The MN supports MIP6 and the CN supports only
basic IPv6.
(b-e) The MN initiates Route Optimization and sends Home Test
Init message to the CN. The destination address of the
packet is the address of the CN and the packet goes through
the HA and the access router of the CN.
(f) The CN does not recognize the Home Test Init message and
replies an ICMP Parameter Problem, Code 1, message to the
MN.
(g-i) The MN sends Care-of Test Init message to CN. The
destination address of the packet is the address of the CN
and the packet goes through the access router of the CN.
(j) The CN does not recognize the Care-of Test Init message and
replies an ICMP Parameter Problem, Code 1, message to the
MN.
(k) The MN receives the ICMP error message sent by the CN,
stops (aborts) Route Optimization establishment.
In this example, because the CN does not support Route Optimization,
the direct communication path fails.
3.3. Previous analysis of the problem and proposed solutions
RFC 4889 [RFC4889] focuses on NEMO Route Optimization and provides
many valuable analyses on this topic. The conclusions section
(section 6) shows some consideration on the aspects of Route
Optimization: the benefits that Route Optimization solution is
expected to bring, the different scenarios in which a Route
Optimization solution applies and issues a Route Optimization
solution might face.
Some scenarios are also included in Section 5. When RO is applied
between Mobile Router and Correspondent Node, RFC 4889 [RFC4889]
states, "However, new functionality is likely to be required on the
Correspondent Node".
Draft The draft-ohnishi-nemo-ro-hmip-00 [I-D.ohnishi-nemo-ro-hmip]
introduces some scenarios and solutions about Route Optimization, as
well. For example, Figure 11 in section 3 illustrates the Proxy CN
case. In this case a Mobile Router takes the proxy role of the
correspondent node. But the solution in this scenario is not
introduced in detail and the solution also requires the correspondent
node (here an MN but not an LFN) to support Routing Header and Home
Cui, et al. Expires January 5, 2012 [Page 6]
Internet-Draft Route Optimization Proxy July 2011
Address Options.
This Route Optimization Proxy introduced in this documents provides a
new approach for the similar scenario. In this solution there are no
requirements or new functionality on the Correspondent Node and the
proxy can manage all the mobility management functions for the
Correspondent Node.
3.4. Use case for Route Optimization proxy
The use case is related to 3GPP2 network. A mobile node in 3GPP2
network can attempt to set up Route Optimization with a Correspondent
Node, but as mentioned before, Route Optimization might fail due to
e.g. CN being basic IP node.
As an approach to these issues, this document introduces Route
Optimization Proxy functionality. The functionality allows a
separate network entity to manage Route Optimization-related
signaling on behalf of the CN, thus allowing for deployment of Route
Optimization on a network level. Additional benefits consist of
bringing higher QoE/QoS to both the initiating and responding user
and reducing network resource costs. The applicable scenarios
include CN's that are basic IPv6 nodes and Mobile Nodes that only
support basic IPv6 protocol. The possible caveat is performance
issues appearing on the entity running Route Optimization Proxy
functionality. However, similar packet interception functionality is
already present in several network entities, e.g. Home Agent, so
performance loss should be acceptable for any router-like components.
Furthermore, if required by e.g. Security and accounting policies
the ROP may be used to conduct all Route Optimization-related
functionalities, even if some or all of the possible CN's managed by
the ROP are capable of Route Optimization.
One use case example is show below in Figure 2.
Cui, et al. Expires January 5, 2012 [Page 7]
Internet-Draft Route Optimization Proxy July 2011
MN HA Network AR (ROP) CN
| | | | |
a ============= CN is a node with basic IP =============
| | | | |
| HoTI | | | |
b1 |---------->| HoTI | | |
b2 | |------------>| HoTI | |
b3 | | |---------->| HoTI |
b4 | | | |---------->|
| | | | ICMP(err) |
d1 | | |<----------|
| CoTI | | |
c1 |------------------------>| CoTI | |
c2 | | |---------->| |
| | | HoT | |
d2 | | HoT |<----------| |
d3 | HoT |<------------| | |
d4 |<----------| | | CoTI |
c3 | | | |---------->|
| | | | ICMP(err) |
e1 | | | |<----------|
| | | CoT | |
e2 | CoT |<----------| |
e3 |<------------------------| | |
| | | |
| | | |
| BU | | |
f1 |------------------------>| BU | |
f2 | |---------->| |
| |Binding Ack| |
g1 | Binding Ack |<----------| |
g2 |<------------------------| | |
| Traffic data | | |
-|------------------------>| Traffic | |
/ | |---------->| Traffic |
/ | | |---------->|
h | | | | Traffic |
\ | | Traffic |<----------|
\ | Traffic data |<----------| |
-|<------------------------| | |
| | | |
Figure 2: Route Optimization Proxy operations.
The detailed descriptions are as follows:
Cui, et al. Expires January 5, 2012 [Page 8]
Internet-Draft Route Optimization Proxy July 2011
(a) The MN supports MIP6 and the CN supports only basic IPv6.
(b1-b3) The MN initiates Route Optimization and sends Home Test
Init message to the CN. The source address of this packet
is the home address of the MN and the destination address
of the packet is the address of the CN and the packet goes
through MN's HA and reaches the CN's access router (AR).
(b4) When the CN's AR, who is running Route Optimization Proxy
function, receives the HoTI message, it recognizes the HoTI
message, caches the message, starts a timer Timer(HoTI) for
this transaction (identified by the address pair and MH
Type value) and forwards the message to the CN. If the AR
can't recognize this packet, or this packet is not a
validated RO-related message, the AR MUST forward this
packet as normal (i.e. without any additional operations).
(c1-c2) The MN sends Care-of Test Init message to the CN. The
source address of the packet is the care-of address of the
MN and the destination address of the packet is the address
of the CN and the packet reaches the CN's AR.
(c3) When the CN's AR, who is running Route Optimization Proxy
function, receives the CoTI message, it recognizes the CoTI
message, caches the message, starts a timer Timer(CoTI) for
this transaction (identified by the address pair and MH
Type value) and forwards the CoTI message to the CN. If
the AR can't recognize this packet, or this packet is not a
RO-related message, the AR MUST forward this packet as
normal (i.e. without any additional operation).
(d1-d4) When the Route Optimization Proxy entity receives an ICMP
Parameter Problem, Code 1, message from the correspondent
node, it checks if there is a cached HoTI or CoTI message
for this transaction (depending on the IP address pair and
MH Type value), the AR will
* Stops Timer (CoTI) or (HoTI) depending on the
message the ICMP message was a response to
* Discards the ICMP message
* Waits for CoTI or HoTI message, if needed
* Starts timer Timer(BU) if the ICMP error message
is the response to HoTI and the timer Timer(BU)
is not running
Cui, et al. Expires January 5, 2012 [Page 9]
Internet-Draft Route Optimization Proxy July 2011
* Generates a HoT message or a CoT message to the
MN as the role of CN as specified in RFC 3775
[RFC3775].
(e1-e3) As described in d1-d4, if the ICMP error message is the
response to CoTI message, no new timer is started.
(f1-f2) The MN receives Home Test and Care-of Test message and
sends Binding Update message to the address of the CN as
specified in RFC 3775 [RFC3775]. The Binding Update
message reaches the AR.
(g1-g2) When the Route Optimization Proxy entity receives a Binding
Update message (i.e. Correspondent registration request)
from the mobile node, if there is a cache for this
transaction (depending on the IP address set and
Timer(BU)), it stops the running timer, establishes the
Proxy Binding Update entity and responds a Binding
Acknowledgement message to the MN as the role of CN as
specified in RFC 3775 [RFC3775]..
(h) Route Optimization is achieved and the Home Agent of the MN
is not involved in the traffic data transport. For the
traffic flow between the MN and the CN, the Route
Optimization Proxy entity forwards all the traffic between
the node pair, with some additional operation (specified in
section 6.2) implemented.
3.5. Additional motivation for Route Optimization Proxy
(Editor's Note: this section may be removed in the final version.)
The motivation for this extension is based on some mechanisms that
have been introduced in IETF. For example, Proxy ARP (Address
Resolution Protocol) protocol, which is specified in[RFC1027], has
been adopted by a number of routers and gateways.
One basic Proxy ARP flow is as below:
Cui, et al. Expires January 5, 2012 [Page 10]
Internet-Draft Route Optimization Proxy July 2011
Host A Gateway Host B
| e0 | e1 |
| | |
------- Host A and Host B attached to the Gateway -------
| | |
| ARP request (IP B) | |
|------------------------->| |
| | |
| proxy ARP reply (IP B) | |
|<-------------------------| |
| | |
| traffic data (IP B) | |
|------------------------->| traffic data (IP B) |
| |-------------------->|
| | |
| | |
Proxy ARP message flow
In this case, when host A wants to send IP packets to host B, if host
A knows only the IP address of host B but doesn't know the MAC
address of host B, host A need send out a ARP request message and
broadcast the message in MAC layer. The gateway will receive this
ARP request, whose destination IP address is the IP address of host
B. The destination of this message is not the gateway, but the
gateway knows that the destination (i.e. host B) is attached to
itself and also knows the destination can't receive this ARP request,
so in this situation, the gateway replies an ARP reply message for
host B. In the proxy ARP reply message, the source IP address is the
IP address of host B and the source MAC address is the MAC address of
the e0 interface in the gateway. When host A receives this proxy ARP
reply message, it can know how to send IP packets to host B. Host A
will send IP packets to the gateway (i.e. the e0 interface) and the
gateway will forward these packets to host B.
Similar to this case, when the CN's access router receives some
mobility-related signal messages (i.e. HoTI, CoTI and BU) destined
to the correspondent node that is attached to its access link, it can
also know that the corresponding node can't recognize these messages
(by receiving ICMP Error message from the correspondent node). This
judgment may depend on the policy profile of the corresponding node,
the configuration variables of the access router, or other manners.
Since the Route Optimization Proxy entity is the mobility proxy of
the correspondent node and can manage the mobility-related signaling
for the correspondent node, it is reasonable for the Route
Optimization Proxy entity to dispose these messages on behalf of the
Cui, et al. Expires January 5, 2012 [Page 11]
Internet-Draft Route Optimization Proxy July 2011
correspondent node.
4. Concerns on different approaches for initiating Route Optimizations
Besides the Return Routability procedure introduced in [RFC3775], a
few additional methods for setting up RO have been published as RFCs.
4.1. Static Shared Key Authorization
RFC 4449 [RFC4449] introduces another method to protect signaling
related to the route optimization in Mobile IPv6. The static shared
key authentication mechanism requires the configuration of a shared
secret between Mobile Node and Correspondent Node. However, if the
Correspondent Node doesn't support Route Optimization feature, this
shared secret is meaningless. On the other hand, pre-shared keys
might be even more manageable when there is a centralized node to
configure rather than numerous CNs. Thus, Route Optimization Proxy
may be used in this scenario and the shared secret is configured on
the Route Optimization Proxy instead of the CN.
A policy may be configured in the access router with the shared key.
The policy may be used to decide when to trigger the Route
Optimization Proxy function - the moment when the Route Optimization
Proxy receives the BU message from the MN or the moment when the
Route Optimization Proxy receives the ICMP Error message from the CN.
When the Route Optimization Proxy decides to take over the role of CN
Proxy after the CN responds ICMP Error, it MUST cache the BU message.
The Route Optimization Proxy can be involved in the Route
Optimization procedure on behalf of CN and acts as specified in this
document and [RFC4449].
4.2. Enhanced Route Optimization
RFC 4866 [RFC4866] introduces an enhanced route optimization
mechanism. If the mobile node initiates enhanced route optimization,
the Route Optimization Proxy can act as a proxy for the following CN
operations defined in RFC 4866 [RFC4866]:
1. Intercepting and receiving Binding Update messages as
specified in section 4.2;
2. Sending Binding Acknowledgment Messages as specified in
section 4.3;
3. Sending CGA Parameters as specified in section 4.;
Cui, et al. Expires January 5, 2012 [Page 12]
Internet-Draft Route Optimization Proxy July 2011
4. Intercepting and receiving CGA parameters as specified in
section 4.6;
5. Sending Permanent Home Keygen Tokens as specified in
section 4.7;
6. Credit Aging as specified in section 4.11.
5. Route Optimization Proxy operation
5.1. Requirements on Route Optimization Proxy
The Route Optimization Proxy function introduced in this document
depends on the operation of the network entity. The Home Test, the
Care-of Test and the Binding Acknowledgement messages are essentially
spoofed by the Route Optimization Proxy entity so that from the
viewpoint of the Mobile Node they appear to be coming from the CN.
The requirements of the Route Optimization Proxy function include
following:
R1 Route Optimization Proxy can monitor, intercept and recognize
mobility-related signaling messages. When the Route
Optimization Proxy receives mobility-related signaling destined
to a CN that is attached to the monitored network, the Route
Optimization Proxy can intercept the messages and temporarily
cache them. When the Route Optimization Proxy receives
(intended for forwarding) the corresponding ICMP Error message
from the Correspondent Node, it can discard the ICMP Error
message and send Return Routability response messages to the
Mobile Node which initiated the Route Optimization. Since all
the mobility-related signaling messages contain mobility header
and MH Type field, the Route Optimization Proxy can fulfill this
requirement with relative ease.
R2 Route Optimization Proxy can conduct the operations of a CN for
Return Routability and Route Optimization specified in RFC 3775
[RFC3775]. Route Optimization Proxy maintains a Proxy Binding
Cache and inserts entries as necessary for this purpose. In
addition, the ROP maintains additional caches for mobility
signaling-related information.
R3 Route Optimization Proxy can modify the outgoing packets and
route the packets via optimized route depending on the created
Proxy Binding Cache. The Route Optimization Proxy checks
whether a Proxy Binding Cache entry exists and if yes (i.e.,
destination address is equal to the home address of the MN and
Cui, et al. Expires January 5, 2012 [Page 13]
Internet-Draft Route Optimization Proxy July 2011
source address is equal to the address of the CN), the Route
Optimization Proxy modifies the destination address in the IP
header and includes Type 2 Routing Header in the outgoing
packets. The Route Optimization Proxy sets the destination
address to the care-of address of the destined mobile node and
sets the Home Address field in the Type 2 Routing Header to the
home address of the destination mobile node.
R4 Route Optimization Proxy can modify the source address of the
incoming packets depending on the Proxy Binding Cache entries.
The Route Optimization Proxy checks whether a Proxy Binding
Cache entry exists and if yes (i.e., destination address is
equal to the address of the CN and source address is equal to
the care-of address of the MN), the Care-of Address in the
source address of the packet is replaced by the home address of
the remote mobile node and the Home Address Option contained in
the packet is removed.
R5 Route Optimization Proxy can dynamically disable the proxy
functionality when it runs out of resources (e.g. capacity and
PBU entry resource). When the proxy functionality is disabled,
the proxy entity stops intercepting the packets and only
forwards them as normal.
R6 Route Optimization Proxy is topologically located in correct
position in the network to execute previous functionalities.
5.2. Route Optimization Proxy operation
The Route Optimization Proxy is a function that would typically runs
on the access router for nodes with only basic IP. The Route
Optimization Proxy forwards all the IP packets sent from or destined
to the basic IP node that is attached to the network. However, some
more operations are defined in this document for the expansion
solution.
The operations for Route Optimization Proxy consist of following:
o Monitoring, intercepting and disposing of the mobility-related
signaling destined to the attached IP nodes.
o Creating, maintaining and deleting the Proxy Binding Cache entries
for the IP node to which the initiator wants to establish or
release a Route Optimization.
o Destination Address replacement and Type 2 Routing Header
insertion for the outgoing traffic from the attached IP node.
Cui, et al. Expires January 5, 2012 [Page 14]
Internet-Draft Route Optimization Proxy July 2011
o Source Address replacement and Home Address Option elimination for
the incoming traffic destined to the attached IP node.
o Security operation for the Return Routability Procedure and Route
Optimization. The Route Optimization Proxy MUST works as
specified in section 5.2 and section 15.4 of RFC 3775 [RFC3775]for
the role of correspondent node.
5.2.1. Incoming Flow Transmission
For an incoming packet (from the remote IP node (the Mobile Node) to
the IP node that is attached to the Route Optimization Proxy), the
Route Optimization Proxy needs to parse the IP header to check the
packet type as soon as it receives the packet from the remote IP
node.
If no mobility header and no Home Address Option are included in the
packet, the Route Optimization Proxy MUST forward the packet
according to normal routing rules, without any modifications.
If the IP packet received does not contain a mobility header but
includes a Home Address Option, i.e. the IP packet is not mobility-
related signaling, the Route Optimization Proxy needs to examine its
Proxy Binding Cache for an entry for the 3-Tuple address set (the
Home Address, the source address and the destination address of the
IP packet).
If a corresponding Proxy Binding Cache entry exists, it means Route
Optimization has been established between the IP node pair. In this
situation the Route Optimization Proxy replaces the source address
(MN's CoA) of the packet with the Home Address of the Mobile Node,
removes the Home Address Option and forwards the modified packet to
the attached Correspondent Node.
If no mobility header is contained in the packet and the Home Address
Option is contained, but no Proxy Binding Cache entry exists, the
Route Optimization Proxy MUST forward the packet according to normal
routing rules, without any modifications. This implies that the RO
has been established between the MN and CN directly (or that the
packet has arrived due to error).
If the IP packet received from other IP node contains a mobility
header, the Route Optimization Proxy needs to further check the MH
type field in the mobility header:
If the received packet is Home Test Init Message, the Route
Optimization Proxy MUST conduct one of the following options,
depending of configuration and policy decisions:
Cui, et al. Expires January 5, 2012 [Page 15]
Internet-Draft Route Optimization Proxy July 2011
1. Caches the message, starts Timer(HoTI) for the message and
forward the packet to the attached IP Node. When the Timer(HoTI)
expires, the HoTI message is removed from the cache.
2. Immediately respond with a HoT message as described below and not
forward the packet to the attached IP node.
If the received packet is Home Test Init Message, the Route
Optimization Proxy MUST conduct one of the following options,
depending of configuration and policy decisions:
1. Caches the message, starts Timer(CoTI) for the message and
forward the packet to the attached IP Node. When the Timer(CoTI)
expires, the CoTI message is removed from the cache.
2. Immediately respond with a CoT message as described below and not
forward the packet to the attached IP node.
If the Route Optimization Proxy opted to forward the message to the
Correspondent Node and receives a ICMP Error message from the CN node
that the HoTI and CoTI messages are destined to, the Route
Optimization Proxy pops the cached HoTI or CoTI message, stops the
corresponding timer, and responds a HoT or a CoT message to the
Mobile Node which originated the init-messages, and executes the
operations as specified for the correspondent node role in section
9.4.1, 9.4.2, 9.4.3 and 9.4.4 of RFC 3775 [RFC3775].
When the Route Optimization Proxy transmits the HoT message, it
starts the timer of Timer(BU) for the Mobile Node.
If the received packet is a valid Binding Update message, the Route
Optimization Proxy checks if a corresponding timer exists. If yes,
the ROP stops the Timer(BU), does not forward the packet to the
attached IP node and executes the operation as specified for the
correspondent node role in section 9.5.1 and 9.5.4 of RFC 3775
[RFC3775]. The exception is that the Route Optimization Proxy
creates or updates Proxy Binding Cache entity and includes the
destination address of the BU message in the Proxy Binding Cache
entry.
If the ROP receives an ICMP Error message from a CN for which no
cached HoTI or CoTI message exists, or a Binding Update message from
a Mobile Node for which no timer exists, the ROP MUST forward the
packet according to normal routing rules.
Cui, et al. Expires January 5, 2012 [Page 16]
Internet-Draft Route Optimization Proxy July 2011
5.2.2. Outgoing Flow Transmission
For the outgoing (from the IP node that is attached to the Route
Optimization Proxy to the remote IP (Mobile) node) flow, the Route
Optimization Proxy needs to examine its Proxy Binding Cache for an
entry for the address pair (i.e. the source address and the
destination address of the IP packet) as soon as it receives packet
from the attached IP node.
If no corresponding Proxy Binding Cache entry exists, the Route
Optimization Proxy MUST forward the packet without any modification
according to normal routing rules.
If a corresponding Proxy Binding Cache entry exists, it means Route
Optimization has been established between the IP node pair. The
Route Optimization Proxy can use a type 2 routing header to route the
packet to the destination node by the way of its care-of address.
The Route Optimization Proxy conducts following operations on the
packet:
o Inserts Type 2 routing header and sets the Home Address in the
routing header to the remote Mobile Node's Home Address (the
original destination address to which the packet was being sent).
o Sets the Destination Address in the packet's header to the remote
mobile node's Care-of Address according to the corresponding Proxy
Binding Cache entry.
Route Optimization Proxy MUST NOT conduct the operations in the
following cases:
o When forwarding an IPv6 Neighbor Discovery packet.
o When forwarding the packets that are noted in Section 6.1 of RFC
3775 [RFC3775].
Note that the implementation creates some additional requirements for
path MTU discovery since the modification changes the packet size.
The Route Optimization Proxy should choose an appropriate way to
indicate the attached IP node this situation.
5.2.3. Conceptual Data Structures
This document introduces Proxy Binding Cache to the Route
Optimization Proxy entity. When the Route Optimization Proxy
receives the Binding Update message destined to the attached IP node
the Route Optimization Proxy creates or updates the Proxy Binding
Cui, et al. Expires January 5, 2012 [Page 17]
Internet-Draft Route Optimization Proxy July 2011
Cache entry and includes the destination address of the Binding
Update message in the Proxy Binding Cache entry.
The newly introduced Proxy Binding Cache entry for this extension
contains two additional fields than the Binding Cache entry data
structure specified in section 9.1 of RFC 3775 [RFC3775].
The Proxy Binding Cache entry contains a flag indicating either this
is an Proxy Binding Cache entry (Defined by this document) or a
normal Binding Cache entry (Defined by RFC 3775 [RFC3775]).
The Proxy Binding Cache entry contains a destination IP address,
which is the true destination of the intercepted Binding Update
message.
Each Proxy Binding Cache entry is mapped with a 3-Tuple address set
(i.e. HoA of MN, CoA of MN and IP address of CN). The incoming
packet (from MN to CN) lookup key is the 3-Tuple address set (i.e.
the source address, the destination address of the IP packet and the
Home Address Option contained in the packet). For the incoming
packet, if the HoA of MN, CoA of MN and CN address all matches, then
the Proxy Binding Cache entry is found. The outgoing packet lookup
key is the 2-Tuple address pair (i.e. the destination address and the
source address of the IP packet). For the outgoing packet, if the
HoA of MN and CN address pair matches, then the Proxy Binding Cache
entry is found. Proxy Route Optimization may be applied between the
IP node pair in these two cases.
6. Configuration Variables
A configuration variable of EnableRouteOptimizationProxy is defined
in this document for Route Optimization Proxy function.
This variable is available in Route Optimization Proxy entity. When
the value of this variable is 1, the Route Optimization Proxy
function is enabled. When the value of this variable is 0, the Route
Optimization Proxy function is disabled.
The default value of EnableRouteOptimizationProxy is 0.
Three Timer is defined in this document, Timer(HoTI), Timer(CoTI) and
Timer(BU).
Timer(HoTI) default value is 10 seconds.
Timer(CoTI) default value is 10 seconds.
Timer(BU) default value is 10 seconds.
Cui, et al. Expires January 5, 2012 [Page 18]
Internet-Draft Route Optimization Proxy July 2011
7. Security Considerations
The extension in this document expands the scope of the mobility
management to cover the reactive mobility management proxy function,
such as the acceptance of Route Optimization, and the Route
Optimization Proxy still follows the principle that providing
network-based mobility management to the IP node that is attached to
its access link. So this extension brings no new security issue to
mobility management.
But this extension requires the Route Optimization Proxy to implement
packet inspection on the packets destined to the IP node, which would
impact the performance of the proxy entity and maybe bring some
security risk. By the time when this document is written, no
explicit security problem has been found and the accurate security
consideration needs to be further studied.
Security concerns primarily consist of authorization; does an
arbitrary ROC implicitly have permission of any CN to act as a proxy.
8. IANA Considerations
This memo includes no requests to IANA.
9. Acknowledgements
The authors would like to thank Jouni Korhonen, Hidetoshi Yokota, Sri
Gundavelli, Qin Wu, Yungui Wang and Carlos J. Bernardos for their
comments and discussion on this extension idea.
10. References
10.1. Normative References
[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.
10.2. Informative References
[RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to
implement transparent subnet gateways", RFC 1027,
October 1987.
Cui, et al. Expires January 5, 2012 [Page 19]
Internet-Draft Route Optimization Proxy July 2011
[RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization
Using a Static Shared Key", RFC 4449, June 2006.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network
Mobility Route Optimization Solution Space Analysis",
RFC 4889, July 2007.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009.
[I-D.ohnishi-nemo-ro-hmip]
Ohnishi, H., "HMIP based Route optimization method in a
mobile network", draft-ohnishi-nemo-ro-hmip-00 (work in
progress), October 2003.
[X.S0011-001-D]
3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard:
Introduction, X.S0011-001-D v2.0", 2008.
[X.S0011-002-D]
3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard:
Simple IP and Mobile IP Access Services, X.S0011-002-D
v2.0", 2008.
[X.S0047-0]
3GPP2 TSG-X, "Mobile IPv6 Enhancements, X.S0047-0 v1.0",
2009.
Authors' Addresses
Xiangsong Cui (editor)
Huawei Technologies
Beijing,
P.R. China
Phone:
Email: Xiangsong.Cui@huawei.com
Cui, et al. Expires January 5, 2012 [Page 20]
Internet-Draft Route Optimization Proxy July 2011
Antti Makela (editor)
Aalto University, Department of Communications and Networking (Comnet)
FIN-00076 Aalto
P.O. BOX 13000
FINLAND
Phone:
Email: antti.makela@aalto.fi
Pete McCann (editor)
Huawei Technologies
U.S.A.
Phone:
Email: Peter.McCann@huawei.com
Cui, et al. Expires January 5, 2012 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 09:46:41 |