NEMO Working Group C. Bernardos
Internet-Draft M. Bagnulo
Expires: January 12, 2006 M. Calderon
I. Soto
UC3M
July 11, 2005
Mobile IPv6 Route Optimisation for Network Mobility (MIRON)
draft-bernardos-nemo-miron-00
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 January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Network Mobility Basic Support protocol enables networks to roam
and attach to different access networks without disrupting the
ongoing sessions that nodes of the network may have. By extending
the Mobile IPv6 support to Mobile Routers, nodes of the network are
not required to support any kind of mobility, since packets must go
through the Mobile Router-Home Agent (MRHA) bidirectional tunnel. On
Bernardos, et al. Expires January 12, 2006 [Page 1]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
the other hand, this introduces delivery latency - due to the
increased length of the route - and packet overhead.
This document describes an approach to the Route Optimisation for
NEMO, called Mobile IPv6 Route Optimisation for NEMO (MIRON). MIRON
enables mobility-agnostic nodes of the mobile network to directly
communicate (i.e., without traversing the MRHA bidirectional tunnel)
with Correspondent Nodes. The solution is based on the Mobile Router
performing the Mobile IPv6 Route Optimisation signalling on behalf of
the nodes of the mobile network.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3. Mobile Router operation . . . . . . . . . . . . . . . . . . . 9
3.1 Data Structures . . . . . . . . . . . . . . . . . . . . . 9
3.2 Performing Route Optimisation . . . . . . . . . . . . . . 9
4. Home Agent, Local Fixed Node and Correspondent Node
operation . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1 Normative References . . . . . . . . . . . . . . . . . . . 15
8.2 Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 17
Bernardos, et al. Expires January 12, 2006 [Page 2]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
1. Introduction
This document assumes that the reader is familiar with the
terminology related to Network Mobility [1] and [2] (Figure 1), and
with the Mobile IPv6 [3] and NEMO Basic Support [4] protocols.
The goals of the Network Mobility (NEMO) Support are described in
[5]. Basically, the main goal is to enable networks to move while
preserving the communications of their nodes (Mobile Network Nodes,
or MNNs), without requiring any support on them. The NEMO Basic
Support protocol [4] is the solution designed by the NEMO Working
Group, consisting on setting a bidirectional tunnel (Figure 2)
between the Mobile Router (MR) of the network (that connects the
mobile network to the Internet) and its Home Agent (located at the
Home Network of the mobile network). This solution is quite similar
to the solution designed for host mobility, Mobile IPv6 [3], but
without supporting Route Optimisation. Actually, the protocol
extends the existing Binding Update (BU) message to inform the Home
Agent (HA) of the current location of the mobile network (i.e., the
MR's Care-of Address, CoA), through which the HA has to forward the
packets addressed to the network prefix managed by the MR (Mobile
Network Prefix, or MNP).
---------
| HA_MR |
---------
|
------ +-----------+---------+
| CN |----| Internet |
------ +---+-----------------+
|
------ ------------------------------
| AR | | AR: Access Router |
------ | CN: Correspondent Node |
| | MR: Mobile Router |
===?========== | HA_MR: MR's Home Agent |
MR | MNP: Mobile Network Prefix |
| | MNN: Mobile Network Node |
===|========|====(MNP) ------------------------------
MNN MNN
Figure 1: Basic scenario of Network Mobility
However, because of the bidirectional tunnel that is established
between HA and MR to transparently enable the movement of networks,
the NEMO Basic Support protocol [4] introduces the following
limitations:
Bernardos, et al. Expires January 12, 2006 [Page 3]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
o It forces suboptimal routing (known as angular or triangular
routing), since packets are always forwarded through the HA
following a suboptimal path and therefore adding a delay in the
packet delivery.
o It introduces non-negligible packet overhead, reducing the Path
MTU (PMTU). An additional IPv6 header (40 bytes) is added to
every packet because of the MR-HA bidirectional tunnel.
o The HA becomes a bottleneck of the communication. This is
because, even if a direct path is available between a MNN and a
CN, the NEMO Basic Support protocol forces traffic to follow the
CN-HA=MR-MNN path. This may cause the Home Link to be congested,
resulting in some packets to be discarded.
In order to overcome such limitations, it is necessary to provide
what have been called Route Optimisation for NEMO [6], [7], [8]. In
Mobile IPv6 [3], the Route Optimisation is achieved by allowing the
Mobile Node (MN) to send Binding Update messages also to the CNs. In
this way the CN is also aware of the CoA where the MN's Home Address
(HoA) is currently reachable. The Return Routability (RR) procedure
is defined to authenticate new CoAs that the MN may use, thus
securing the change that the CN makes in the IPv6 destination address
(using the MN's CoA) of the packets it sends addressed to the MN's
HoA [9].
__ _____ __ ___
| | | | | | | |
|CN| |HA_MR| |MR| |MNN|
|__| |_____| |__| |___|
| | | |
| ------------ | ------------------------------ | ------------ |
| |S:CN,D:MNN| | |S:HA_MR,D:MR_CoA[S:CN,D:MNN]| | |S:CN,D:MNN| |
| | DATA | | | DATA | | | DATA | |
| ------------ | ------------------------------ | ------------ |
|-------------->|-------------------------------->|-------------->|
| | | |
| ------------ | ------------------------------ | ------------ |
| |S:MNN,D:CN| | |S:MR_CoA,D:HA_MR[S:MNN,D:CN]| | |S:MNN,D:CN| |
| | DATA | | | DATA | | | DATA | |
| ------------ | ------------------------------ | ------------ |
|<--------------|<--------------------------------|<--------------|
| | | |
Figure 2: NEMO Basic Support protocol
This document provides a Route Optimisation solution for nodes of a
mobile network that do not have (or use) any kind of mobility
Bernardos, et al. Expires January 12, 2006 [Page 4]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
support, that is, Local Fixed Nodes (LFNs). The solution enables
direct path communication between an LFN and a CN, without requiring
any change on the operation of CNs nor LFNs. In order to do that,
the MR performs all the Route Optimisation signalling and mobility
tasks defined by Mobile IPv6 [3] on behalf of the LFNs attached to
the mobile network [10].
Bernardos, et al. Expires January 12, 2006 [Page 5]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
2. Protocol Overview
The mechanism, called Mobile IPv6 Route Optimisation for NEMO
(MIRON), essentially consists in enabling a MR to behave as a proxy
for nodes that do not have any kind of mobility support (i.e., LFNs),
performing the Mobile IPv6 Route Optimisation signalling and packet
handling [3] on behalf of the LFNs.
__ _____ __ ___
| | | | | | | |
|CN| |HA_MR| |MR| |LFN|
|__| |_____| |__| |___|
| | | |
| ------------ | ------------------------------ | |
| |S:LFN,D:CN| | |S:MR_CoA,D:HA_MR[S:LFN,D:CN]| | |
| | HoTI | | | HoTI | | |
| ------------ | ------------------------------ | |
|<-----------------|<--------------------------------| |
| | --------------- | |
| | |S:MR_CoA,D:CN| | |
| | | CoTI | | |
| | --------------- | |
|<---------------------------------------------------| |
| | | |
| ------------ | ------------------------------ | |
| |S:CN,D:LFN| | |S:HA_MR,D:MR_CoA[S:CN,D:LFN]| | |
| | HoT | | | HoT | | |
| ------------ | ------------------------------ | |
|----------------->|-------------------------------->| |
| --------------- | | |
| |S:CN,D:MR_CoA| | | |
| | CoT | | | |
| --------------- | | |
|--------------------------------------------------->| |
| | | |
| | --------------- | |
| | |S:MR_CoA,D:CN| | |
| | | BU(HoA:LFN) | | |
| | --------------- | |
|<---------------------------------------------------| |
| | | |
Figure 3: MIRON signalling
In order to enable packets to be directly routed between the CN and
the LFN (avoiding the MRHA tunnel), the MR sends a Binding Update
message on behalf of the LFN, binding the address of the LFN to the
MR's CoA.
Bernardos, et al. Expires January 12, 2006 [Page 6]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
Mobile IPv6 [3] requires an additional procedure to be performed
before actually sending a Binding Update message to a certain CN (and
therefore enabling the Route Optimisation between MN and CN).
Basically, this procedure, called Return Routability (RR) - needed in
order to mitigate possible security concerns [9] - is used to verify
that the MN, besides being reachable at the HoA, is also able to
send/respond to packets sent to a given address (different to its
HoA). This mechanism can be deceived only if the routing
infrastructure is compromised or if there is an attacker between the
verifier node and the addresses (HoA and CoA) that are being
verified. With these exceptions, the test is used to ensure that the
MN's Home Address (HoA) and MN's Care-of Address (CoA) are
collocated.
Since MIRON proposes the MR to behave as a "proxy" (Figure 3), the MR
has to perform the Mobile IPv6 Return Routability procedure on behalf
of the LFNs. This involves the MR sending the Home Test Init (HoTI)
and Care-of Test Init (CoTI) messages to the CN and processing the
replies (Home Test message - HoT - and Care-of Test message - CoT).
These messages are sent as specified in [3], using the LFN's address
as the source address in the HoTI message - which is sent
encapsulated through the MR's HA -, and the MR's CoA as the source
address in the CoTI message. With the information contained in the
HoT and CoT messages, sent by the CN in response to the HoTI and CoTI
messages respectively, the MR is able to build a BU message to be
sent to the CN on behalf of the LFN. This message is sent using the
MR's CoA as the packet source address and carries a Home Address
destination option set to the LFN's address.
Once the Return Routability procedure has been done and the MR has
sent the BU message - binding the address of the LFN (belonging to
the MR's MNP) to the MR's CoA - packets between the CN and the LFN do
not follow the suboptimal CN-HA=MR-LFN path anymore, but the CN-MR-
LFN optimised route (Figure 4).
In addition to generating and receiving all the signalling related to
Route Optimisation on behalf of the LFNs, the MR has also to process
the "route optimised" packets sent by/directed to the LFNs
(Figure 4):
o Packets sent by a CN are addressed to the MR's CoA and contain
IPv6 extension headers (a type 2 Routing Header) that are not
understood by the LFN. Therefore, the MR has to change the
destination address and remove the routing header before
delivering the packet to the LFN.
o Packets sent by an LFN have to be also processed. The MR, in
order to be able to send packets directly to the CN, has to use
Bernardos, et al. Expires January 12, 2006 [Page 7]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
its CoA as source address of the packets and has also to add a
Home Address destination option to every packet (set to the LFN's
address).
__ _____ __ ___
| | | | | | | |
|CN| |HA_MR| |MR| |LFN|
|__| |_____| |__| |___|
| | | |
| --------------- | | |
| |S:CN,D:MR_CoA| | | ------------ |
| | RH (NH:LFN) | | | |S:CN,D:LFN| |
| | DATA | | | | DATA | |
| --------------- | | ------------ |
|-------------------------------------------->|-------------->|
| | | |
| | --------------- | |
| | |S:MR_CoA,D:CN| | ------------ |
| | | HoA:LFN | | |S:LFN,D:CN| |
| | | DATA | | | DATA | |
| | --------------- | ------------ |
|<--------------------------------------------|<--------------|
| | | |
Figure 4: MIRON packet handling (Route Optimised operation)
Bernardos, et al. Expires January 12, 2006 [Page 8]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
3. Mobile Router operation
The Mobile Router operation defined by the NEMO Basic Support
protocol [4] is extended in order to be able to generate and process
the Mobile IPv6 Route Optimisation signalling (i.e., Return
Routability and Binding Update) [3], since the MR is behaving as a
"Proxy-MR" for their LFNs.
3.1 Data Structures
In addition to the data structures defined in [4], the MR need also
to maintain the following information:
o The MR extends the Binding Update List (BUL) to contain also some
information per each LFN-CN communication that is being optimised.
Basically the added fields are those described in [3] that are
related to the Route Optimisation procedure defined by Mobile IPv6
(such as IP addresses of CNs, binding lifetimes, Return
Routability state, etc.), since the MR is behaving as Proxy-MR for
the LFNs attached to it.
o The BUL is not indexed only by the address of the CN, since there
is a different binding is per each CN-LFN pair. Therefore, the
address of the LFN has to be also included in every BUL entry.
3.2 Performing Route Optimisation
Since the proposed optimisation has to be done per each LFN-CN
communication, the MR should track the different ongoing
communications that attached LFNs may have, in order to identify
potential LFN-CN communications that may be worth to be optimised.
Due to the fact that optimising a certain LFN-CN communication
involves a cost - in terms of signalling and computation resources at
the MR - it may not be worth to perform such a optimisation for some
kinds of flows (e.g., DNS queries). The decision about whether to
perform Route Optimisation to a certain LFN-CN communication or not
is out of the scope of this document.
Per each LFN-CN communication that has been decided to be route
optimised, the MR has to perform the following actions:
o The MR performs the Return Routability procedure as described in
Section 2.
o The MR sends a Binding Update message to the CN on behalf of the
LFN. The BU contains the address of the LFN as the MN's Home
Address (HoA) and the MR's CoA as the MN's CoA (the MR's CoA is
Bernardos, et al. Expires January 12, 2006 [Page 9]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
the only address that is reachable without requiring any agent to
be deployed to forward packets to the current location of the
mobile network). This procedure binds the LFN's address to the
MR's CoA at the CN (i.e., an entry is added at the CN's Binding
Cache).
o The MR processes every packet received from the CN as follows:
* These packets carry the MR's CoA as destination address, and
also carry a Type 2 Routing Header with the LFN's address as
next hop. The MR processes and removes the Routing Header of
the packet, checking if the next hop address belongs to one of
its LFNs and, if so, delivering the packet to the LFN (with the
destination address of the packet set to the address contained
in the routing header: the LFN's address).
* [3] defines that IPv6 nodes which process a Type 2 Routing
Header must verify that the address contained within is the
node's own Home Address. This is done in order to prevent
packets from being forwarded outside the node, but MIRON
changes the processing of this kind of routing header - at the
MRs - to verify that the address contained within is an address
of one of the LFNs the MR is acting as Proxy-MR.
o The MR processes every packet received from the LFN as follows:
* The MR's CoA is set as IPv6 source address.
* An IPv6 Home Address destination option, carrying the address
of the LFN, is inserted.
Bernardos, et al. Expires January 12, 2006 [Page 10]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
4. Home Agent, Local Fixed Node and Correspondent Node operation
The operation of the Home Agent, the Local Fixed Nodes and the
Correspondent Nodes remains unchanged. The only requirement is that
CNs must implement the Correspondent Node part of the Route
Optimisation defined by Mobile IPv6 [3] (section 9).
Bernardos, et al. Expires January 12, 2006 [Page 11]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
5. Conclusions
This document describes a Route Optimisation for NEMO for LFN-CN
flows. The MR performs all the Route Optimisation tasks on behalf of
the LFNs that are attached to it. This involves generating and
processing all the related signalling (that is, the Return
Routability procedure and the Binding Update message), but also
handling the packets sent and received by the LFNs, in order to
enable the direct CN-MR-LFN route (avoiding the suboptimal CN-HA=MR-
LFN path) without requiring any change on the operation of the CNs
nor LFNs.
The Route Optimisation here described is intended for LFN-CN
communications in a non-nested NEMO. However, nothing prevents this
solution to be applied also in a nested NEMO, avoiding the last
tunnel, or even all the tunnels if the MR is provided somehow with a
topologically valid IPv6 address that is reachable without traversing
any HA (for example, as described in [10]).
MIRON has been designed and implemented within the framework of the
European DAIDALOS project (http://www.ist-daidalos.org). The
implementation of the NEMO Basic Support protocol of MR and HA and
the MIRON code at the MR have been done for Linux (2.6 kernel),
mostly at user space (in C). The implementation used at the CNs is
MIPL-2.0 (http://wwww.mobile-ipv6.org).
Conducted tests show that the performance obtained with MIRON is much
better - in terms of latency and effective TCP throughput - than the
obtained by the NEMO Basic Support protocol, specially when the
"distance" (i.e., RTT) between the HA and the CN is increased.
Bernardos, et al. Expires January 12, 2006 [Page 12]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
6. Security Considerations
Because an LFN trusts its MR for the routing of all its traffic (both
incoming and outcoming), allowing the MR to perform some signalling
and processing on behalf of the LFNs attached to it does not
introduce any new threat. From the architectural point of view, the
solution is also natural, since the Route Optimisation support
defined by Mobile IPv6 [3] conceptually could be implemented in
multiple boxes. MIRON just applies this mechanism, by splitting the
mobility functionalities among two different physical boxes, but
actually the conceptual basis of the solution is the same as the one
defined by Mobile IPv6.
Bernardos, et al. Expires January 12, 2006 [Page 13]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
7. Acknowledgements
The authors would like to thank Erik Nordmark and Pascal Thubert for
their valuable comments.
The work described in this Internet-Draft is based on results of IST
FP6 Integrated Project DAIDALOS. DAIDALOS receives research funding
from the European Community's Sixth Framework Programme. Apart from
this, the European Commission has no responsibility for the content
of this Internet-Draft. The information in this document is provided
as is and no guarantee or warranty is given that the information is
fit for any particular purpose. The user thereof uses the
information at its sole risk and liability.
Bernardos, et al. Expires January 12, 2006 [Page 14]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
8. References
8.1 Normative References
[1] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-03 (work in progress),
February 2005.
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[5] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-04 (work in progress),
February 2005.
[6] Ng, C., "Network Mobility Route Optimization Problem Statement",
draft-ietf-nemo-ro-problem-statement-00 (work in progress),
July 2005.
[7] Zhao, F., "NEMO Route Optimization Problem Statement and
Analysis", draft-zhao-nemo-ro-ps-01 (work in progress),
February 2005.
[8] Thubert, P., Molteni, M., and C. Ng, "Taxonomy of Route
Optimization models in the Nemo Context",
draft-thubert-nemo-ro-taxonomy-04 (work in progress),
February 2005.
[9] Nikander, P., "Mobile IP version 6 Route Optimization Security
Design Background", draft-ietf-mip6-ro-sec-03 (work in
progress), May 2005.
8.2 Informative References
[10] Bernardos, C., Bagnulo, M., and M. Calderon, "MIRON: Mobile
IPv6 Route Optimization for NEMO", 4th Workshop on Applications
and Services in Wireless Networks (ASWN) , 2004.
Bernardos, et al. Expires January 12, 2006 [Page 15]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
Authors' Addresses
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 8859
Email: cjbc@it.uc3m.es
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 8837
Email: marcelo@it.uc3m.es
Maria Calderon
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 8780
Email: maria@it.uc3m.es
Ignacio Soto
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 5974
Email: isoto@it.uc3m.es
Bernardos, et al. Expires January 12, 2006 [Page 16]
Internet-Draft Mobile IPv6 RO for NEMO July 2005
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 (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bernardos, et al. Expires January 12, 2006 [Page 17]