Mobile IP Working Group Timothy J. Kniveton
Internet Draft Jari T. Malinen
Expires: August 2002 Vijay Devarapalli
Informational: February 2002 Charles E. Perkins
Nokia Research Center
Mobile Router Support with Mobile IP
draft-kniveton-mobrtr-01.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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 document is a submission by the Mobile IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted to
the mobileip@sunroof.eng.sun.com mailing list.
Distribution of this memo is unlimited.
Abstract
This document describes how to support mobile networks with Mobile IP or
Mobile IPv6. It provides this support with no modifications to Mobile
IP or routing protocol signaling. It also describes two scenarios
of mobile router support, consumer mode, and fully enabled mode. In
the former, the mobile router is not allowed to use routing protocol
signaling with the home agent, but performs routing for subnet(s)
assigned to it. In the latter mode, both the home agent and the mobile
router use a routing protocol in the same manner as fixed routers.
Kniveton, et al. Expires August 2002 [Page 1]
Internet Draft Mobile Router Support with Mobile IP February 2002
Contents
Status of This Memo 1
Abstract 1
1. Introduction 2
2. Terms 4
3. Solution Overview 4
3.1. Application Scenarios . . . . . . . . . . . . . . . . . . 7
3.2. Mapping to requirements . . . . . . . . . . . . . . . . . 8
4. Alternate Solutions 9
5. Support for Dynamic Routing Protocol 9
5.1. Processing the Tunneled Routing Messages . . . . . . . . 10
5.2. Forwarding Packets to MR's subnet . . . . . . . . . . . . 10
6. Security Considerations 11
7. Intellectual Property Right Considerations 11
8. Acknowledgements 11
Authors' Addresses 12
Full Copyright Statement 12
1. Introduction
This document describes the problem of mobile router support with Mobile
IP [9] or Mobile IPv6 [5], and outlines requirements for such support.
The document then describes two scenarios, static (``consumer'') and
dynamic (``fully enabled'') mobile router support, and outlines how
these scenarios are possible using unmodified Mobile IP or Mobile IPv6
with or without a dynamic routing protocol.
Within the context of this document, a Mobile Router is defined as a
node which operates as a Mobile Node as detailed in Mobile IP or Mobile
IPv6, but has the additional capability of routing between its point of
attachment (Care-of Address), and a network fragment which moves with
the mobile router.
Kniveton, et al. Expires August 2002 [Page 2]
Internet Draft Mobile Router Support with Mobile IP February 2002
An architecture to enable mobile routers is required to:
1 support unmodified Mobile IP or Mobile IPv6 signaling.
2 support communication to or from nodes on subnetwork(s) connected
to and moving with the mobile router.
3 support both fixed and mobile nodes in the network moving with
the mobile router. Fixed nodes are unmodified IP or IPv6 hosts
or routers which do not necessarily have any mobility support
nor any knowledge of the mechanisms described in this document.
Mobile nodes are nodes supporting Mobile IP or Mobile IPv6 with
no knowledge of the mechanisms described in this document.
4 support arbitrary nesting level of mobile routers; i.e., support
connection (into the mobile router's moving network) of another
mobile router and its associated network.
5 support static configuration; that is, the mobile router need not
have a dynamic routing protocol running on it.
6 support dynamic configuration; that is, the mobile router may run
a dynamic routing protocol and communicate with such a routing
protocol to signal its home agent.
7 allow routing entities such as the home agent and mobile router
to be able to run these dynamic routing protocols with no
modifications to their signaling.
8 support an end-to-end security model for mobility where no
intermediate node or router alters mobility state in mobile
nodes, routers, or their respective home agents and correspondent
nodes.
Mobile router support described here is NOT assumed to:
- solve the problems resulting from excessively fast relative
topology changes. The outcome of implementing a mobile network
as described here will inherit the characteristics of Mobile IP
and the routing protocol chosen, and thus be able to support
movement and topology changes to the same extent as those
protocols. Hence, any routing protocol which would be used to
support mobile routers is assumed to be suitable for the rate of
change to topology in anticipated usage scenarios.
- solve the problem of scalability resulting from fixed
network connectivity of a cascaded mesh of routers (and their
subnetworks) that contain non-aggregable, host-based routes.
Kniveton, et al. Expires August 2002 [Page 3]
Internet Draft Mobile Router Support with Mobile IP February 2002
2. Terms
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 [1].
In addition, this document uses the following terms:
Fixed Node
A host not capable moving from its home link to other
links. A fixed node is capable of sending and receiving
packets, that is, being a source or destination of
traffic, but not a forwarder of it.
Fixed Router
A router not capable of moving from its home link to
other links. A fixed router is capable of forwarding
packets between two or more interfaces, and possibly
running a dynamic routing protocol modifying the state by
which to do packet forwarding.
Mobile Node
A host moving from its home link to other links. A
mobile node is capable of sending and receiving packets,
that is, being a source or destination of traffic, but
not a forwarder of it.
Mobile Router
A router moving from its home link to other links. A
mobile router is capable of forwarding packets between
two or more interfaces, and possibly running a dynamic
routing protocol modifying the state by which to do
packet forwarding.
This terminology is intended to conform to those that have been used in
IPv6, Mobile IPv6, and other Internet protocols [3, 5].
3. Solution Overview
This document outlines a solution which satisfies the above
requirements. The one-digit prefixes are assumed to be legal prefixes
for globally routable links, e.g,. with prefix length 64.
In Figure 1, a mobile node (MN) 1::2 is at home on its home link where
we have its home agent 1::3 (HA_MN). A mobile router (MR) 4::2 is at
its home. It also provides routing for an access link 5::, on which
there is a fixed node (FN). MR also provides access for access link 6::,
which is behind a fixed fouter (FR). MR, GW, and HA are supposed to be
Kniveton, et al. Expires August 2002 [Page 4]
Internet Draft Mobile Router Support with Mobile IP February 2002
+----+ +-------+
| MN | | HA_MN |
+--+-+ 1:: +---+---+
2+-------------+3
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ +------------ GW ---+ +-------+
4:: |
2+-------------+3
+--+-+ +---+---+
| MR | | HA_MR |
+--+-+ +-------+
5:: |1
----------
2| |3
+--+-+ +--+-+
| FN | | FR |
+--+-+ +--+-+
6:: |1
----------
Figure 1: Mobile node and mobile router at home.
routers, so that they at least forward packets. They may also run the
same dynamic routing protocol.
In Figure 2 we see the bindings when MN moves away from its home to link
6::, after MN has signaled its home agent (HA_MN) and its correspondent
node (CN_MN), assuming mobile nodes or routers get the same host number
as in their home addresses.
In Figure 3 we see the bindings when MR moves away from its home
link, to link 7::, and it has updated its home agent (MR_HA), and its
correspondent node (MR_CN) on its new location.
Both MN and MR hence use unmodified Mobile IPv6, except that there are
minor implications to the packet forwarding implementation of MR and
HA_MR. Basically, MR and HA_MR have a bidirectional tunnel between them.
These rules are simply that
- MR locally knows it is a mobile router and when not at home it
installs an encapsulation interface towards its home agent.
Through this interface, MR forwards (reverse-tunnels) all packets
not originated from MR towards its HA. For packets originated
from MR the behavior is as if MR were a normal MN; they get
Kniveton, et al. Expires August 2002 [Page 5]
Internet Draft Mobile Router Support with Mobile IP February 2002
+-------+
| HA_MN | 3::2->6::2
1:: +---+---+
-------------|3
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ +------------ GW ---+ +-------+
3::2->6::2 4:: |
2+-------------+3
+--+-+ +---+---+
| MR | | HA_MR |
+--+-+ +-------+
5:: |1
----------
2| |3
+--+-+ +--+-+
| FN | | FR |
+--+-+ +--+-+
6:: |1
--------+-
|2
+--+-+
| MN |
+----+
Figure 2: Mobile node not at home.
forwarded on the visited link, except if the packets are targeted
to the home link; then they get reverse-tunneled to HA. Hence,
when arriving at a visited link, MR injects a default route and
a network route of its home link, towards the reverse tunnel it
creates pointing to its home agent, in addition to a default
route to MR's default router on the visited link.
- If MR, HA_MR, and GW were running a dynamic routing protocol,
MR redirects control traffic of this protocol towards HA_MR,
tunneling these packets through the reverse tunnel pointing to
HA_MR. The dynamic routing protocol updates the routing state
between GW, HA_MR, and MR, so that next hops between GW and MR
now go through intermediate router HA_MR. There MAY be expedition
of routing state update, triggered by registration of MR with its
home agent.
- If it is not desired that MR runs a dynamic routing protocol,
HA_MR MUST inject routing entries for all mobile links behind
Kniveton, et al. Expires August 2002 [Page 6]
Internet Draft Mobile Router Support with Mobile IP February 2002
+-------+
| HA_MN | 3::2->6::2
1:: +---+---+
-------------|3
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ ++----------- GW ---+ +-------+
3::2->6::2 | 7:: 4:: | 4::2->7::2
2+---- ------+3
+--+-+ +---+---+
| MR | | HA_MR | 4::2->7::2
+--+-+ +-------+
5:: |1
----------
2| |3
+--+-+ +--+-+
| FN | | FR |
+--+-+ +--+-+
6:: |1
--------+-
|2
+--+-+
| MN |
+----+
Figure 3: Mobile node and mobile router both on a visited link.
MR, using MR's home address as the next hop. That is, in our
example, HA_MR would inject network routes for 5:: and 6:: with
next hop 4::2.
- When HA_MR captures a data packet forwarded towards MR, its
forwarding engine then does a route lookup for this packet. If
the returned route has MR's home address as the next hop, it then
does a binding cache lookup for this next hop, and tunnels the
packet to the registered care-of-address of MR.
3.1. Application Scenarios
There are two application scenarios for this proposal, one for
restricted ``consumer'' mobile router support, and one for ``fully
enabled'' mobile router support. In the former, HA_MR injects static
routes for a restricted set of links behind each MR, when MR registers
with its HA. These are statically configured for each MR in its HA. In
Kniveton, et al. Expires August 2002 [Page 7]
Internet Draft Mobile Router Support with Mobile IP February 2002
this mode, MR cannot run dynamic routing protocol and arbitrarily modify
provider's routing cloud state. In the latter scenario, MR is a genuine
router running dynamic routing protocol. This provides support e.g. for
the case when provider's router moves to a visited link, or there is
exterior routing protocol running between MR and its GW, that is, when
the mobile router support is ``fully enabled''.
3.2. Mapping to requirements
With the simple scenario presented above, we can support the
requirements stated above. The solution
1 supports unmodified Mobile IP or Mobile IPv6 signaling.
2 supports communication to or from nodes on subnetwork(s)
connected to and moving with the mobile router.
3 supports both fixed and mobile nodes in the network moving with
the mobile router. Since links moving with MR do not change as
a result of movement, and their traffic get forwarded via MR's
home address, these nodes do not need separate binding updates
to any nodes. Binding-triggered route updates, as stated above,
keep them connected in a timely manner as a result of standard
routing.
4 supports arbitrary nesting level of mobile routers. MR support
provides transparency where second-level MR only sets up a tunnel
to its HA, this tunnel going inside tunnel set up by first-level
MR. This can then applied to subsequent levels, inductively.
5 supports static configuration; that is, the mobile router need
not have a dynamic routing protocol running on it. This is
provided by the ``consumer'' scenario.
6 supports dynamic configuration; This is provided by the
``fully-enabled'' scenario.
7 allows routing entities to run the dynamic routing protocols
with no modifications to their signaling. Routing protocols are
not affected, though there can be route injections triggered by
binding updates from MR.
8 supports the end-to-end security model for mobility. No
intermediate node or router alters mobility state in mobile
nodes, routers, or their respective home agents and correspondent
nodes, since nodes do not sends any additional binding updates on
behalf of other nodes.
Kniveton, et al. Expires August 2002 [Page 8]
Internet Draft Mobile Router Support with Mobile IP February 2002
However, this solution has one drawback: it has less than full route
optimization for the packets as they get forwarded through two-way
tunneling via MR's home agent. Route optimization is available for MN
in that it can let its CNs know its CoA. However, these packets pass
through the tunnel between MR and HA_MR. Route optimization is, however,
fully available for communication between MR and its CNs. With this
restriction, however, we can support arbitrary links behind MRs, nested
MNs, MRs, stub- and transit networks.
4. Alternate Solutions
Another solution [4] was previously proposed, and follows a slightly
different set of requirements. It includes support for route
optimization, and requires changes to Mobile IP signaling. Providing
a generic scalable solution for the address ownership problem may
prove to be complicated. A problem is, how can a mobile router or an
intermediate agent efficiently authorize multiple fixed and mobile nodes
to communicate with their peers, when all these may be from multiple
different domains, and the mobile router is not and end node for their
communication. However, if this issue can be solved, or if a controlled
security environment is feasible, this alternate may provide additional
benefits when compared to this proposal.
5. Support for Dynamic Routing Protocol
In the fully enabled mode, the mobile router (MR) runs a dynamic routing
protocol with its home agent (assumed to be a router) to exchange
up-to-date routing information. The mobile router continues running
this intra-domain routing protocol even when it moves away from home
and attaches to a visited domain. One of the requirements listed in
section 1 is to avoid any modifications to the routing protocol. This
can be done by dynamically modifying the list the interfaces on which
the routing protocol is active. For example, let us assume a mobile
router used inteface 'A' when it was connected to its home network
and was exchanging routing updates through that interface. When the
mobile router moves and attaches to a visited network with the same
interface, the routing protocol is turned off for that interface. This
is to prevent the mobile router from advertising the routes in its
mobile subnet to the visited network. The mobile router then sets up
a encapsulating tunnel to its home agent (HA_MR). This encapsulating
tunnel is then added as a virutal interface to the list of interfaces
on which the routing protocol is active. The mobile router then
starts sending routing information through this tunnel to the HA_MR.
Most IPv6 intra-domain routing protocols assume link local address to
appear as the source address for routing information messages. The
encapsulating tunnel takes care of this, by encapsulating the routing
messages in a IP header whose source address is the mobile router's CoA
Kniveton, et al. Expires August 2002 [Page 9]
Internet Draft Mobile Router Support with Mobile IP February 2002
and the destination address is HA_MR's address. When HA_MR receives the
tunneled routing message, it decapsulates it and processes the inner
routing message. The inner routing message appears as if the packet was
sent from a node on the link.
The HA_MR also sets up a similar tunnel to the MR and adds the tunnel to
the list of interfaces on which the routing protocol is active. HA_MR
then tunnels the routing information it has towards the mobile router.
The mobile router now learns about HA_MR's routing information.
The tunneled packets are sent through a secured channel between the
mobile router and HA_MR. This secured channel is made possible by a
static or a pre-negotiated security association between the mobile
router and its HA_MR. The tunneled routing messages MUST be protected by
Authentication Header [6]. If data confidentiality is required, ESP [7]
SHOULD be used.
Certain routing protocols like OSPFv2 [8]or OSPF for IPv6 [2] exchange
periodic HELLO messages between adjacent routers. In our case these
periodic messages from the mobile router are sent through this tunnel to
its HA_MR.
5.1. Processing the Tunneled Routing Messages
When the HA_MR receives the routing information from the mobile router
through the bidirectional tunnel, it adds the corresponding routes to
its routing table with the next hop set to the mobile router's address,
in case of IPv6 MR's link local address. This next hop address is
obtained from the source address of the inner packet. The HA_MR in
turn propagates this information when it sends routing updates to other
routers on the mobile router's home link.
The HA_MR also needs a binding cache entry for that address which is the
next hop address for the MR's subnet. In case if IPv4 this is created
when the MR sends a registration request [?] for its home address when
it moves away from its home link. In the case of IPv6 HA_MR needs a
binding cache entry to the mobile router's link local address. This
is because the next hop address in the routing table entry returns the
mobile router's link local address. And to forward packets to the
mobile router's link local address, a binding cache entry is needed.
A binding cache entry is not created unless HA_MR receives a binding
update from the mobile router. Therefore the mobile router MUST send
a binding update for its link local address in addition to its home
address. This is optional in the current Mobile IPv6 [5] specification.
Kniveton, et al. Expires August 2002 [Page 10]
Internet Draft Mobile Router Support with Mobile IP February 2002
5.2. Forwarding Packets to MR's subnet
Since HA_MR advertised routing reachability information for MR's
subnet, it receives the packets meant for the nodes in the MR's subnet.
Route lookup on HA_MR returns the address of the mobile router as the
next hop address. By making use of the binding cache entry for the
mobile router's address (link local address in case of IPv6) and the
bi-directional tunnel with the mobile router, HA_MR starts forwarding
packets throught the tunnel to the mobile router. The mobile router in
turn decapsulates the packet and fowards it on its subnet.
6. Security Considerations
The mechanism described in this draft requires routing messages
exchanged between a mobile router and its home agent to be secured when
the mobile router is not on its home link. This is done by creaating
a static security association between the mobile router and its home
agent. This document does not require changes to either Mobile IP or
any routing protocol. Therefore, it does not introduce any additional
security requirements.
7. Intellectual Property Right Considerations
On IPR related issues, Nokia refers to its statement on patent
licensing. Please see http://www.ietf.org/ietf/IPR/NOKIA.
8. Acknowledgements
References
[1] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[2] R. Coltun, D. Ferguson, and J. Moy. OSPF for IPv6. Request for
comments (proposed standard), Internet Engineering Task Force,
December 1999.
[3] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6)
Specification. Request for Comments (Draft Standard) 2460,
Internet Engineering Task Force, December 1998.
[4] et al. Ernst, T. Mobile networks support in mobile ipv6.
Internet Draft, Internet Engineering Task Force, June 2001.
Kniveton, et al. Expires August 2002 [Page 11]
Internet Draft Mobile Router Support with Mobile IP February 2002
[5] D. Johnson and C. Perkins. Mobility support in IPv6 (work in
progress). Internet Draft, Internet Engineering Task Force,
November 1998.
[6] S. Kent and R. Atkinson. IP Authentication Header. Request for
Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998.
[7] S. Kent and R. Atkinson. IP Encapsulating Security Payload
(ESP). Request for Comments (Proposed Standard) 2406, Internet
Engineering Task Force, November 1998.
[8] J. Moy. OSPF Version 2. Request for Comments (Standard) 2328,
Internet Engineering Task Force, April 1998.
[9] C. Perkins. IP Mobility Support. Request for Comments (Proposed
Standard) 2002, Internet Engineering Task Force, October 1996.
Authors' Addresses
Timothy J. Kniveton Vijay Devarapalli
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Phone: +1 650 625-2025 Phone: +1 650 625-2320
EMail: Timothy.Kniveton@Nokia.com EMail: vijayd@iprg.nokia.com
Fax: +1 650 625-2502 Fax: +1 650 625-2502
Jari T. Malinen Charles Perkins
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Phone: +1 650 625-2355 Phone: +1 650 625-2986
EMail: jmalinen@iprg.nokia.com EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502 Fax: +1 650 625-2502
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
Kniveton, et al. Expires August 2002 [Page 12]
Internet Draft Mobile Router Support with Mobile IP February 2002
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards
in which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Kniveton, et al. Expires August 2002 [Page 13]