INTERNET DRAFT Ryuji Wakikawa
Expires: 24 Apr 2005 Masafumi Watari
Keio Univ./WIDE
24 Oct 2004
Optimized Route Cache Protocol (ORC)
draft-wakikawa-nemo-orc-01.txt
Status of This Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This draft proposes Optimized Route Cache Protocol (ORC) to provide
route optimization for the NEMO Basic Support protocol. ORC provides
a dynamic route optimization mechanism, similar to route optimization
in Mobile IPv6.
The ORC aims to manage binding information for when routing
information of each mobile network are located at special routers
called ``Correspondent Router''.
Wakikawa and Watari Expires 24 Apr 2005 [Page i]
Internet Draft ORC 24 Oct 2004
Contents
Status of This Memo i
Abstract i
1. Introduction 3
2. ORC Concept 3
3. Terminology 4
4. ORC Overview 5
4.1. Correspondent Router Discovery . . . . . . . . . . . . . 5
4.2. Binding Registration to Correspondent Router . . . . . . 5
4.3. Forwarding between Mobile Router and Correspondent Router 6
5. Extensions to Mobile IPv6 and the Basic NEMO protocol 6
5.1. Forwarding Table Data Structure . . . . . . . . . . . . . 6
5.2. Mobility Header Messages . . . . . . . . . . . . . . . . 7
5.2.1. Binding Update . . . . . . . . . . . . . . . . . 7
5.2.2. Binding Acknowledgment . . . . . . . . . . . . . 7
5.2.3. Managed Prefix Lists sub-option . . . . . . . . . 7
5.3. New ICMP Messages . . . . . . . . . . . . . . . . . . . . 8
5.3.1. Correspondent Router Discovery Request . . . . . 8
5.3.2. Correspondent Router Discovery Reply . . . . . . 9
6. Protocol Operations 11
6.1. Correspondent Router Discovery . . . . . . . . . . . . . 11
6.2. Binding Registration to Correspondent Router . . . . . . 12
6.2.1. Sending Binding Update . . . . . . . . . . . . . 12
6.2.2. Return Routability . . . . . . . . . . . . . . . 12
6.3. Intercepting Packets by Correspondent Router . . . . . . 13
6.4. Routing to Mobile Network . . . . . . . . . . . . . . . . 14
7. Security Consideration 14
8. Acknowledgements 14
References 14
Authors' Addresses 16
Appendices 17
A. Example Scenario 17
B. Correspondent Router Hierarchy 19
Wakikawa and Watari Expires 24 Apr 2005 [Page 1]
Internet Draft ORC 24 Oct 2004
C. Modifications from the last version 21
Wakikawa and Watari Expires 24 Apr 2005 [Page 2]
Internet Draft ORC 24 Oct 2004
1. Introduction
The NEMO Basic Support protocol [4] is currently being standardized
at the IETF NEMO working group. However, the NEMO Basic Support
protocol does not provide route optimization, but always use a
bi-directional tunnel established between a mobile router and
its home agent. Optimized route cache protocol is designed as an
extension to the NEMO Basic Support protocol for providing certain
route optimization. ORC was proposed earlier in the paper [8].
In the NEMO Basic Support protocol, a binding of a mobile network
can be treated as routing information of the mobile network. For
instance, a care-of address in the binding can be treated as a
next hop address in a routing table. It is against the general
standard operations of the Internet for each end-node to handle
route information. End nodes should be unaware of routing since
managements of a binding may bother them.
2. ORC Concept
In Mobile IPv6 [5] and the NEMO Basic Support protocol, a home agent
is an original anchor router of a mobile network and maintains a
binding of the mobile network persistently. All packets are first
routed to the home agent and are tunneled to the mobile router by the
home agent unless the mobile router starts route optimization.
On the other hand, the optimized route cache protocol introduces
correspondent routers that can be configured anywhere in the
Internet to be an anchor router for the mobile network, providing
certain level of route optimization. Practically, the correspondent
routers should be scattered near the transit AS to allow direct
forwarding to the mobile network before reaching the home agent.
Because it is impossible to replace all routers on the Internet
with the correspondent routers support, it is effective to place a
correspondent router at places where traffic is converged like the
Internet Exchange Point (IXP).
The optimized routing cache protocol provides optimal route path in
best effort when correspondent routers exist. However, the level of
optimization can be improved depending on where the correspondent
routers are placed, and the path it takes. The correspondent routers
can also be dynamically discovered if necessary, to provide certain
route optimization.
Since the binding is processed and maintained only by the
correspondent routers scattered over the Internet, mobile router
does not need to handle bindings for each correspondent nodes. It
is clearly redundant operations if both the mobile router and the
Wakikawa and Watari Expires 24 Apr 2005 [Page 3]
Internet Draft ORC 24 Oct 2004
remote network manage bindings for the same communicating network.
This also allows the end-nodes to communicate in the optimized route
without requiring any additional functions.
This concept can be applied to Mobile IPv6 as well. In Mobile IPv6,
correspondent nodes are required to extend its protocols suites for
route optimization. However, it is not reasonable to assume all
end-nodes to support the Mobile IPv6 protocol. Therefore, a mobile
host can not initiate route optimization (i.e. return routability)
to all correspondent nodes. In such case, the network of which the
correspondent nodes are connected to can provides route optimization
on behalf of the correspondent nodes.
3. Terminology
Most of the terminology is described in [5] and [3]. This document
in addition defines the following terms.
Correspondent Router
An edge router of correspondent nodes' network. A
Correspondent Router is well defined in [7] and is also defined
as ``ORC router'' in the paper [8]. A correspondent router
is capable to manage a binding of any mobile router and setup
forwarding for mobile network prefixes. A correspondent router
can be statically configured or dynamically discovered by the
mobile router.
Correspondent Router Anycast address
An anycast address assigned to each correspondent router. It
is generated by the correspondent router's 64 bit prefix and an
anycast identifier. The anycast identifier is to be defined by
IANA.
Managed Prefix
Prefixes which are managed by each correspondent router.
The Managed Prefix is often configured with administrative
policy. For example, if a correspondent router is placed for
an administrative domain (let's say 2001:a:b::/32), the Managed
Prefix for the correspondent router is the 2001:a:b::/32.
Mobile router can tunnel any packets meant for the managed
prefixes to the correspondent router. The correspondent
router has responsibility to route packets correctly to the
destination which is in the managed prefixes.
Wakikawa and Watari Expires 24 Apr 2005 [Page 4]
Internet Draft ORC 24 Oct 2004
Proxy Route
A proxy Route is used to intercept packets by a correspondent
router at an administrative domain. A proxy route is to direct
a route of a mobile network prefix to a correspondent router.
Proxy route contains a mobile network prefix of a correspondent
router as a destination and the correspondent router's address
as a next hop. The proxy route will not be aggregated in an
IGP domain, but can be distributed inside the IGP domain.
Proxy Route is used to intercept packets when a correspondent
router is not on the path of the traffic from the correspondent
node to the Mobile Networks. (i.e. The correspondent router
is neither Default Router nor Core Router. See [7]).
4. ORC Overview
4.1. Correspondent Router Discovery
Each mobile router may have the list of the correspondent routers
beforehand by system administrators or users.
In addition, when a mobile network node starts communication with
a correspondent node, a mobile router may dynamically discover a
correspondent router for the correspondent node. The discovery is
triggered when a mobile router receives tunneled packets from its
Home Agent. The mobile router first sends a correspondent router
Discovery Request to the correspondent router anycast address.
The anycast address is created with the prefix address of the
correspondent node and the well-known anycast identifier. The
prefix length for the anycast address is always 64. When one of
correspondent router receives the Correspondent Router Discovery
Request, it replies back a Correspondent Router Discovery Reply
including all correspondent routers of the administrative domain of
which the correspondent node is located.
4.2. Binding Registration to Correspondent Router
After receiving the correspondent router addresses, the mobile router
can attempt Binding Registration to the correspondent router. The
mobile router sends a Binding Update which is protected by IPsec to
the correspondent router. The mobile router MUST set ORC flag 'O' in
the Binding Update and include the Mobile Network Prefix sub-options.
The Binding Update message is same as a Binding Update sent to a Home
Agent except for the flag field (i.e. 'O' flag set and 'H' flag
unset).
Wakikawa and Watari Expires 24 Apr 2005 [Page 5]
Internet Draft ORC 24 Oct 2004
After processing the Binding Update successfully, the correspondent
router MUST return a Binding Acknowledgment including the managed
prefix list. The managed prefix is used when the mobile router
decides which packets are sent to which correspondent router. The
correspondent router setup forwarding for all the mobile network
prefixes notified by the mobile router.
After getting successful Binding Acknowledgment, the mobile router
set up forwarding for all managed prefixes. If the mobile router
gets error status code in the Binding Acknowledgment or cannot get
any Binding Acknowledgment, it SHOULD stop sending Binding Update to
the correspondent router and SHOULD mark the correspondent router as
invalid.
There is alternative mechanism based on Return Routability to send
secured Binding Update. The detailed operation is introduced in
Appendix.
4.3. Forwarding between Mobile Router and Correspondent Router
Once a mobile router registers its binding to a correspondent router,
it forwards packets destined to an address which is in range of
correspondent router's managed prefix. The correspondent router also
intercepts packets sent to the Mobile Network and tunnels them to
mobile router by IP-in-IP encapsulation.
5. Extensions to Mobile IPv6 and the Basic NEMO protocol
5.1. Forwarding Table Data Structure
Forwarding table is maintained by each mobile router. It has
conceptually the following fields. How to implement forwarding table
is up to implementations.
- Correspondent Router Address
- Managed Prefix Lists
The list of Managed Prefix which is notified by the correspondent
router
Wakikawa and Watari Expires 24 Apr 2005 [Page 6]
Internet Draft ORC 24 Oct 2004
5.2. Mobility Header Messages
5.2.1. Binding Update
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|O| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ORC Flag (O)
The flag is used to identify a Binding Update sent
for a correspondent router.
5.2.2. Binding Acknowledgment
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ORC Flag (O)
The flag is used to identify a Binding Acknowledgment
sent from a correspondent router.
5.2.3. Managed Prefix Lists sub-option
The managed prefix lists mobility header sub-option is valid only in
the Binding Acknowledgment.
Wakikawa and Watari Expires 24 Apr 2005 [Page 7]
Internet Draft ORC 24 Oct 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| |
+ Managed Prefix List +
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
To be assigned by IANA
Length
The length of sub-option.
Managed Prefix List
The list of prefixes which are managed by a
correspondent router. Lower bit after prefix
length should be set zero. (ex. 2001:a:b:c::/64 is
expressed by 2001:a:b:c:0:0:0:0)
5.3. New ICMP Messages
Two new ICMP messages are defined for the discovery of the
correspondent routers. Two messages have similar structure of home
agent address discovery request and reply messages defined in Mobile
IPv6 [5].
5.3.1. Correspondent Router Discovery Request
The Correspondent Router Discovery Request message is used by a
mobile node to discover correspondent routers where correspondent
nodes are located. The message format is as follows.
Wakikawa and Watari Expires 24 Apr 2005 [Page 8]
Internet Draft ORC 24 Oct 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
To be assigned by IANA
Code
0
Checksum
The ICMP Checksum
Identifier
The 16-bit identifier to aid in matching
correspondent router Discovery Reply message. The
identifier should never be set to 0 and should always
be more than 1.
Reserved
0
5.3.2. Correspondent Router Discovery Reply
The Correspondent Router Discovery Reply message is used by a
correspondent router to send lists of correspondent routers
configured at the network in reply to the Correspondent Router
Discovery Request message. The message format is as follows.
Wakikawa and Watari Expires 24 Apr 2005 [Page 9]
Internet Draft ORC 24 Oct 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Preference | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Correspondent Router Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Preference | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Correspondent Router Address +
| |
+ +
| |
. .
. .
. .
Type
To be assigned by IANA
Code
0
Checksum
The ICMP Checksum
Identifier
The 16-bit identifier to aid in matching
Correspondent Router Discovery Reply message. The
identifier should never be set to 0 and should
always be more than 1.
Reserved
0
Wakikawa and Watari Expires 24 Apr 2005 [Page 10]
Internet Draft ORC 24 Oct 2004
Preference
The 8-bit preference value of each correspondent
router. The default preference value is zero.
Higher value indicate higher preference.
Prefix length
The length of prefix with which a correspondent
router is configured and responsible for.
Correspondent Router Address
A global IPv6 address of a correspondent router.
A correspondent router replies multiple addresses of correspondent
routers that are configured in same network domain by a single
Correspondent Router Discovery Reply message.
6. Protocol Operations
6.1. Correspondent Router Discovery
A correspondent router is dynamically discovered with Correspondent
Router Discovery and Correspondent Router Reply. The discovery
mechanism is similar to the dynamic home agent discovery mechanism of
Mobile IPv6 [5].
When a mobile router detects that a received packet is tunneled by
its home agent, it can initiate Correspondent Router Discovery on
demand by sending a Correspondent Router Discovery Request to the
correspondent router anycast address. The mobile router learns
the correspondent router anycast address from the correspondent
node's prefix and the anycast identification. The prefix length
of the correspondent node's prefix is always assumed to be 64-bit.
Correspondent routers with a shorter prefix length are notified later
with a Correspondent Router Discovery Reply.
If no replies are received, the mobile router stops further discovery
for correspondent routers to the network of which the correspondent
node are located. The mobile router must then communicate through
its home agent.
If the mobile router receives a Correspondent Router Discovery
Reply, it first verifies the message header (e.g. ICMP checksum
and identifier). If all verifications are passed, it retrieves
the correspondent router addresses. If more than one addresses
are included, the mobile router selects one of the addresses and
starts explicit binding registration described in section 6.2. The
determination of which correspondent routers to select are handled
Wakikawa and Watari Expires 24 Apr 2005 [Page 11]
Internet Draft ORC 24 Oct 2004
with preference values and prefix length. Some examples are shown in
Appendix B.
6.2. Binding Registration to Correspondent Router
6.2.1. Sending Binding Update
A mobile router MAY maintain IPsec Security Association with
correspondent routers. Alternatively, it MAY use Return Routability
mechanism to protect Binding Update described in Section 6.2.2.
A mobile router creates a Binding Update as indicated in the basic
NEMO protocol. It MUST set 'O' flag in the Flag field of a Binding
Update. The Binding Update MUST be always protected by IPsec or
Return Routability mechanism.
A mobile router also records the sent Binding Update as a Binding
Update list entry for each correspondent router.
6.2.2. Return Routability
In Mobile IPv6, a mobile host provides reasonable assurance with the
correspondent nodes through the return routability mechanism, and
securely register its binding. A correspondent router is similar
to the correspondent node in terms of security relationship with a
mobile router. Although IPsec provides stubborn security for binding
registration, it is expensive operations for both a mobile router and
a correspondent router. The ORC follows similar approach to Mobile
IPv6 so that secured binding registration is performed with the
return routability mechanism.
It is necessary to extend the return routability procedure to
register mobile network prefix information. To complete return
routability for a mobile network, a mobile router is required to
generate its home address from its mobile network prefix instead of
its home network.
In Mobile IPv6, return routability procedure plays two roles when
authenticating a binding update. One is to verify if the binding
between the home address and the care-of address is legit, The other
role is to exchange keys for authorizing binding update. In the
optimized route cache protocol, following extensions are required in
addition to return routability procedure. The home agent must verify
the HoTI that is securely tunneled from the mobile router. The HoTI
should be checked for its source address and prefix length.
Wakikawa and Watari Expires 24 Apr 2005 [Page 12]
Internet Draft ORC 24 Oct 2004
HoTI will be sent with the home address as the source address,
generated from the mobile network prefix. Thus, if the source
address does not match the home address registered in home agent's
binding, the home agent discards the HoTI. Furthermore, if the prefix
length registered for the mobile router is different from the prefix
sub-option sent, the home agent also discards the HoTI. On the other
hand, CoTI will be sent with the care-of address as its source
address. Once the mobile router receives both HoT and CoT back from
the correspondent router, it is assured that the mobile router exists
in topologically correct attachment point and also assures that it is
the router of the network with the mobile network prefix. The mobile
router can now send a binding update to the correspondent router
with the keys exchanged in return routability. If the correspondent
router can recompute the encryption, the binding update completes in
success.
When a mobile router sends a binding update, it must set the binding
acknowledge flag in order for it to receive a binding acknowledgment
message from the recipient. The correspondent router must return
a binding acknowledgment message containing a list of managed
prefixes of its IGP domain in the managed prefix mobility option.
The managed prefix mobility option is defined in section 5.2.3. If
the binding update is successfully processed by the correspondent
router, the mobile router establishes a bi-directional tunnel with
the correspondent router as in [5]. The mobile router also records
the pair of the prefixes retrieved from the managed prefix mobility
option and the correspondent router's address as route entries in its
routing table. These routes may be used to search a correspondent
router in a routing table when the mobile router sends packet to
correspondent nodes described in section 6.4.
6.3. Intercepting Packets by Correspondent Router
A correspondent router basically intercepts packets for a registered
mobile router by IP level routing. However, there is different
operations depending on correspondent router's topological location.
If a correspondent router is located as a gateway router of a
network, it intercepts packets by parsing all packets' destination
address with registered bindings.
On the other hand, if a correspondent router is located in a network,
it MUST advertise a proxy route for a mobile network prefix of
registered binding to its routing domain. All routers in the same
routing domain forward packets meant for the mobile network prefix to
the correspondent router who is advertising the prefix route.
Wakikawa and Watari Expires 24 Apr 2005 [Page 13]
Internet Draft ORC 24 Oct 2004
6.4. Routing to Mobile Network
Whenever a correspondent router receives packets and query routing
table as general router operations, it also searches for binding
cache for a destination address in the IPv6 header just like any
home agent. The correspondent router should select the prefix
longest matched binding and route for the destination. When the
correspondent router finds the prefix longest matched binding for the
destination, it must search binding cache database recursively for
the next hop address of the binding and must select the last matched
binding for the destination. This recursive operation is aimed to
support nested mobility.
Once the correspondent router finds a binding instead of an IGP
route for outgoing packets, it tunnels the packets directly to the
care-of address of the destination according to the registered
binding. For the opposite direction, the mobile router may reverse
tunnel packets to the correspondent router at correspondent node's
IGP domain which is found with route of the correspondent router's
managed prefixes in mobile router's routing table. The correspondent
router then decapsulates packets and route them to a correspondent
node. The mobile router does not insert the home address option as
Mobile IPv6, since falsification of mobile network node's packets
on intermediate nodes like the mobile router should be avoided
for security considerations. The encapsulation of packets adds
additional IPv6 header, and it does not change original packets.
7. Security Consideration
The optimized route cache protocol enables to manage routing
information across AS boundaries. In other words, it is possible for
a mobile router to alter routing table of opposite routers. Wrong
binding registrations will cause opposite ASs to fall into confusion
or to have black-hole of routing. The ORC employees Mobile IPv6
security mechanism [5] for protecting binding updates which are the
IPsec authentication header [1] and the return routability scheme.
Furthermore, recipient routers can apply their IGP domain or AS
routing policies to handle each binding.
8. Acknowledgements
The authors would like to thank Keisuke Uehara, Susumu Koshiba, Jun
Murai, and WIDE Project for their contributions.
Wakikawa and Watari Expires 24 Apr 2005 [Page 14]
Internet Draft ORC 24 Oct 2004
References
[1] R. Atkinson. IP Authentication Header. Request for Comments
(Proposed Standard) 1826, Internet Engineering Task Force, August
1995.
[2] A. Conta and S. Deering. Generic Packet Tunneling in IPv6
Specification. Request for Comments (Proposed Standard) 2473,
Internet Engineering Task Force, December 1998.
[3] Thierry E. et al. Network Mobility Support Terminology.
Internet Draft, Internet Engineering Task Force, February 2002.
[4] Vijay Devarapalli. et al. Network Mobility (NEMO) Basic Support
Protocol. Internet Draft, Internet Engineering Task Force, June
2004.
[5] David B. Johnson, C. Perkins, and Jari Arkko. Mobility Support
in IPv6. Request For Comments 3775, Internet Engineering Task
Force, June 2004.
[6] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4).
Request for Comments (Draft Standard) 1771, Internet Engineering
Task Force, March 1995.
[7] P. Thubert, M. Molteni, C. Ng, and E. Ohnishi, H. Paik. Taxonomy
of Route Optimization models in the Nemo context (work in
progress). Internet Draft, Internet Engineering Task Force,
February 2004.
[8] R. Wakikawa, S. Koshiba, K. Uehara, and J. Murai. ORC: Optimized
Route Cache Management Protocol for Network Mobility. In The
10th International Conference on Telecommunication (ICT) 2003,
pages 119--126, February 2003.
Wakikawa and Watari Expires 24 Apr 2005 [Page 15]
Internet Draft ORC 24 Oct 2004
Authors' Addresses
Ryuji Wakikawa
Graduate School of Media and
Governance, KEIO University
5322 Endo Fujisawa
Kanagawa, 252-8520
JAPAN
Phone: +81-466-49-1100
EMail: ryuji@sfc.wide.ad.jp
Fax: +81-466-49-1395
Masafumi Watari
Graduate School of Media and
Governance, KEIO University
5322 Endo Fujisawa
Kanagawa, 252-8520
JAPAN
Phone: +81-466-49-1100
EMail: watari@sfc.wide.ad.jp
Fax: +81-466-49-1395
Wakikawa and Watari Expires 24 Apr 2005 [Page 16]
Internet Draft ORC 24 Oct 2004
A. Example Scenario
Figure 1 shows the configuration of the optimized route cache
protocol. In the figure, there are five ASs connected to each other
by Border Gateway Protocol (BGP) [6]. This can be assumed to be
typical Internet BGP routing topology.
In Mobile IPv6 and the NEMO Basic Support protocol, a home agent is
an original anchor router of a mobile network and maintains a binding
of the mobile network persistently. All packets are first routed
to the home agent and are tunneled to the mobile router by the home
agent unless the mobile router starts route optimization. Therefore,
in the case when correspondent nodes in AS3 communicates with the
mobile network nodes in AS5, packets must first be routed to the HA
in AS2 via AS1, before being tunneled to the destination nodes.
On the other hand, the optimized route cache protocol introduces
correspondent routers that can be configured anywhere in the Internet
to be an anchor router, providing route optimization. Practically,
the correspondent routers should be placed on expected networks
where there exist correspondent nodes for a mobile router and a
| | +----+
|----| | HA | Home Agent
Correspondent Router | | +----+ AS2
+----+ | +--------------------------------
| CR | |
+----+ | +------------------------
AS1 +------------+
---------+---------+ | +--------+ + CN
| | | Router |----+ CN
---------+-----------+ | +--------+ + CN
AS4 +----+ +----------+ AS3
| CR | | +----+-------------------
+----+ | |
| | +---------+-------------------
+--+--+ | | AS5
CN CN CN | | +----+
Correspondent Nodes | | | MR | Mobile Router
| +-+--+
| |
| +---+---+- Mobile Network
| MNN MNN MNN
| Mobile Network Nodes
Figure 1: Optimized Route Cache Protocol Overview
Wakikawa and Watari Expires 24 Apr 2005 [Page 17]
Internet Draft ORC 24 Oct 2004
mobile network because it is impossible to replace all routers on the
Internet with the correspondent routers support. It is effective to
place a correspondent router where traffic is converged like Internet
Exchange Point (IXP).
Whenever a mobile router moves, correspondent routers may receive
a binding update notification on-demand from the mobile router and
cache them. The correspondent router must authorize the mobile
network to receive the binding as described in section 6.2. After
creation of the binding, the correspondent router intercepts packets
destined to the mobile network, and tunnels them to the care-of
address which is registered in the binding.
For example, as soon as one of the nodes inside AS4 communicates with
the mobile network the mobile router registers its binding to the
correspondent router in AS4. After the registration, any packets
meant for the mobile network from AS4 are always intercepted by the
correspondent router and tunneled to the mobile router. On the
return path, the mobile router could tunnel packets that are sent to
AS4 to the correspondent router by IP-in-IP encapsulation [2].
All correspondent routers advertise a proxy route of the mobile
prefix to capture packets destined to the mobile network by routing
protocols regardless of IGP or EGP. The proxy route may not be
inter-exchanged by correspondent routers with any Exterior Gateway
Protocol (EGP) such as BGP. The correspondent route advertises the
proxy route only while the received binding is valid. After the
binding expiration, the correspondent router removes the proxy route
from the routing table. Thus, it may lead to frequent changes on BGP
routing tables that is not desired on the Internet.
Correspondent routers can intercept packets that are from transit
AS. For instance, if a correspondent node in AS3 send packets to the
mobile network, the packets are routed towards the home agent since
there are no correspondent routers in AS3. However, on the way to
the home agent, a correspondent router in AS1 which is the transit AS
of AS3, can intercept the packets and tunnels them directly to the
mobile router.
The proxy route is not a binding, but it contains the mobile prefix
as a destination and the correspondent router's address as the
next hop. The proxy route will not be aggregated in correspondent
router's IGP domain. The correspondent router can reject receiving a
binding of any mobile network according to administrative policies,
because the advertisement of unaggregatable routes may swell routing
entries on routers. According to routing management policies of each
AS, correspondent routers should be approved to provide services for
mobile router from their affiliated IGP domain.
Wakikawa and Watari Expires 24 Apr 2005 [Page 18]
Internet Draft ORC 24 Oct 2004
B. Correspondent Router Hierarchy
Figure 2 shows the case where the mobile router selects the
correspondent router that has shorter prefix. In this case, the
correspondent router advertises the proxy route(PR) for the mobile
router to one router nearby. Since two routers are configured as
border routers, packets sent to the mobile router are routed to one
of routers according to the default route of other routers. Once the
router having the proxy route intercepts the packets, it re-routes
the packets to the correspondent router. Finally the correspondent
router tunnels the packets to the mobile router.
Figure 3 shows the case where the mobile router selects the
correspondent router configured at the leaf network. The
correspondent router advertises the proxy route for the mobile router
to other routers in the same network domain. Otherwise, packets
are silently routed to the Internet without interception of the
correspondent router. Packets sent to the mobile router are routed
to one of routers according to the proxy route and then routed to the
Mobile Router
+
|
+-----+-------------+
| Internet |
+--+------------+---+
| |
+-----+--+ +--+-----+
| CR +------+ Router | /32 network
+-BC--+--+ +--+--PR-+
Binding Cache / " / " Proxy Route
/ " / "
/ " / "
+------+-+ +-+----+-+ +-+------+
| Router | | Router | | Router | /48 network
+--------+ +---+----+ +--------+
|
+---+----+
| Router | /64 network
+---+----+
|
+--+--+--+--+
CN CN CN CN CN
Correspondent Nodes
Figure 2: Registration to Higher Router
Wakikawa and Watari Expires 24 Apr 2005 [Page 19]
Internet Draft ORC 24 Oct 2004
correspondent router. The correspondent router tunnels these packets
to the mobile router. As a result, the route may become longer than
the route between the higher route and the mobile router according to
the tunnel end point.
It is better to activate a correspondent router located higher in
the network hierarchy in terms of proxy route advertisements and
shorter bi-directional tunnel between a correspondent router and a
mobile node. However, corruption of higher router causes the network
separation from the Internet. Thus, higher routers administratively
prohibits the correspondent router support.
Increasing the number of correspondent routers caring the mobile
network is an important factor to optimize routes between a mobile
node and correspondent nodes as much as possible. By contrast,
the optimized route cache protocol does not always force to have a
number of correspondent routers. Binding registrations to all the
correspondent routers bring considerable overheads to a mobile router
and prevents scalability and quickness of movement processing.
Mobile Router
+
|
+-----+-------------+
| Internet |
+--+------------+---+
| |
+-----+--+ +--+-----+
| Router +------+ Router | /32 network
+-PR--+--+ +--+--PR-+
Proxy Route / " / " Proxy Route
/ " / "
/ " / "
+------+-+ +-+----+-+ +-+------+
| Router | | Router | | Router | /48 network
+-PR-----+ +---+-PR-+ +-----PR-+
|
+---+----+
| CR | /64 network
+---+-BC-+
| Binding Cache
+--+--+--+--+
CN CN CN CN CN
Correspondent Nodes
Figure 3: Registration to Lower Router
Wakikawa and Watari Expires 24 Apr 2005 [Page 20]
Internet Draft ORC 24 Oct 2004
C. Modifications from the last version
- remove nested mobile networks support
- fix a few typo and packet formats
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Wakikawa and Watari Expires 24 Apr 2005 [Page 21]
Internet Draft ORC 24 Oct 2004
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wakikawa and Watari Expires 24 Apr 2005 [Page 22]