< draft-petrescu-nemo-mrha-01.txt   draft-petrescu-nemo-mrha-02.txt >
Internet Draft A. Petrescu, ed. Internet Draft A. Petrescu, ed.
Document: draft-petrescu-nemo-mrha-00.txt M. Catalina-Gallego Document: draft-petrescu-nemo-mrha-02.txt M. Catalina-Gallego
Expires: May 2003 C. Janneteau Expires: September 2003 C. Janneteau
H. Y. Lach H.-Y. Lach
A. Olivereau A. Olivereau
Motorola Motorola
November 2002 March 2003
Issues in Designing Mobile IPv6 Network Mobility Issues in Designing Mobile IPv6 Network Mobility
with the MR-HA Bidirectional Tunnel (MRHA) with the MR-HA Bidirectional Tunnel (MRHA)
<draft-petrescu-nemo-mrha-01.txt> <draft-petrescu-nemo-mrha-02.txt>
Status of this Nemo Status of this Nemo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document presents various issues related to designing a This document describes several issues relevant to the design of a
network mobility solution with Mobile IPv6 and the MRHA network mobility support solution that relies on the bi-directional
bidirectional tunnel. Scenarios are presented with the MR at home tunnel between Mobile Router and Home Agent, with Mobile IP.
and in a visited network, from which an argumentation is made that Examples of issues are: conflicting Mobile IP and RIPng/OSPF
all routing information is available in the HA (when BR and HA are requirements on link-local addresses, HA/BR co-location, and
co-located) or can be communicated by ICMP Redirect (when the BR "cross-over" tunnels.
and HA are separated). This raises questions on the necessity of
more information than the 'R' bit into the Mobile IPv6 BUs
(i.e. /128 prefixes are sufficient). Other generic issues with an
MRHA solution, like link-local addresses in Mobile IPv6, router
renumbering, or ND for the MR are presented. Route Optimization
and security aspects are only briefly touched.
Table of Contents Table of Contents
Status of this Memo................................................i Status of this Nemo................................................i
Abstract...........................................................i Abstract...........................................................i
Conventions used in this document.................................ii Conventions Used in this Document.................................ii
1. Introduction....................................................1 1. Introduction....................................................1
1.1 Prior descriptions...........................................2 2. Definitions.....................................................1
2. Definitions.....................................................2 3. NEMO "Basic" preliminary descriptions...........................1
3. Data structures.................................................3 4. Issues..........................................................2
4. Description of a Home Network...................................3 4.1 Implementation-independent specification terms...............2
5. Scenarios.......................................................5 4.2 Allow for deployment flexibility.............................3
5.0 Manual mobile networks.......................................5 4.3 Dynamic routing protocol and the HA..........................3
5.1 Scenarios with co-located HA and BR..........................6 4.4 Link-local addresses.........................................3
5.2 Scenarios with HA and BR separated..........................10 4.5 Mobile Router as a Mobile Host...............................4
5.3 MR Redirects to BR..........................................15 4.6 Neighbour Discovery for MR's egress interface................4
6. Informing the HA about the route to MR.........................15 4.7 Separation of routing and mobility for MR....................5
6.1 ICMP Redirect from BR to HA.................................15 4.8 Prefix-based routing and host-based routing exceptions.......5
6.2 Static route method.........................................16 4.9 IPv4 Issues..................................................5
6.3 Dynamic route method........................................17 4.10 "Cross-over" tunnels........................................6
7. Other Issues...................................................17 5. Security Considerations.........................................6
7.1 Link-local addresses........................................17 5.1 A tool: HA ingress filtering.................................6
7.2 MR as an MN.................................................18 Acknowledgements...................................................6
7.3 Prefix-based routing and host-based routing.................18 References.........................................................7
7.4 Multicast subscriptions of the MR...........................18 Changes............................................................9
7.5 Neighbour Discovery for MR..................................19 A. Motivation for Full Addresses in Binding Updates................9
7.6 Separation of routing and mobility for MR...................19 A.1 Description of a Home Network................................9
7.7 Router Renumbering..........................................20 A.2 Scenarios...................................................10
7.8 IPv4 issues.................................................20 A.2.1 Manual Mobile Networks..................................11
8. Mobile Router behaviour........................................20 A.2.2 Scenarios with Co-located HA and BR.....................11
8.1 CoA Configuration...........................................21 A.2.3 Scenarios with HA and BR Separated......................16
8.2 Discovering HA..............................................21 A.3 MR Redirects to BR..........................................20
8.3 Sending BUs to HA...........................................21 A.4 Informing the HA about the Route to MR......................20
8.4 Search order in various tables..............................22 A.4.1 ICMP Redirect from BR to HA.............................21
9. Home Agent behaviour...........................................22 A.4.2 Static Route Method.....................................21
10. Route Optimization............................................22 A.4.3 Dynamic Route Method....................................23
11. Security Considerations.......................................23 B. Examples and Other Issues......................................23
11.1 Security of the MRHA tunnel................................23 B.1 Example of issue for Mobile Router as Mobile Host...........23
11.2 Security for Route Optimization............................23 B.2 Multicast Subscriptions of the MR...........................23
Acknowledgements..................................................24 B.3 Examples of issues for Neighbour Discovery for MR...........24
Intellectual Property Rights Considerations.......................24 B.4 Router Renumbering..........................................24
Changes...........................................................24 B.5 Example of disconnected operation issue.....................25
References........................................................24 B.6 Example for the "cross-over" tunnels issue..................25
Chairs' Addresses.................................................26 B.7 Example of use of HA ingress filtering......................26
Authors' Addresses................................................26 C. A Digression...................................................27
Copyright Notice..................................................27 Intellectual Property Rights Considerations.......................27
Chairs' Addresses.................................................28
Authors' Addresses................................................28
Copyright Notice..................................................29
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1]. this document are to be interpreted as described in RFC-2119 [1].
1. Introduction 1. Introduction
This document identifies issues when designing an enhancement of This document describes several issues relevant to the design of a
the Mobile IPv6 protocol to support mobile networks. The network mobility support solution that relies on the bi-directional
background is the extensive use of the bidirectional tunnel between tunnel between Mobile Router and Home Agent, with Mobile IP.
MR and HA. The HA acts on behalf of the link-local address of the Examples of issues are: conflicting Mobile IP and RIPng/OSPF
moving interface of the Mobile Router when the MR is in a foreign requirements on link-local addresses, HA/BR co-location and
network. "cross-over" tunnels.
The Mobile Router is using BUs and BAcks with the Home Agent to The Mobile Router is using Binding Updates, Binding
maintain the MRHA bidirectional tunnel. The modifications to Acknowledgments, Binding Requests and Binding Errors with the Home
Mobile IPv6 HA and MN are minimal. The BU format contains, in Agent to maintain the MRHA bidirectional tunnel.
addition to all Mobile IPv6 fields, an additional bit 'R' that
informs the HA that this is a mobile router instead of a mobile
host. The 'R' bit is used by the HA to perform certain tasks
differently for this home address than if it were a host.
Traffic coming from outside the home link, or from other hosts on The document is organized as follows: the next section presents a
the home link, and directed to hosts behind the mobile router short perspective on three preliminary proposals for a NEMO "Basic"
normally only need to go through the L2 address of the mobile type of solution; the following section lists the issues that
router's correspoinding to its L3 address. With Proxy ND [19], it appear in this type of protocols. Two additional sections, or
is the HA that pretends to own MR's L3 address by advertising new appendices, give more detail of issues by way of motivations,
associations of of the MR's L3 address to the HA's L2 address, thus examples and other related issues.
intercepting MR's home traffic and forwarding it to the current CoA
of the MR.
When the MR is in a foreign network, traffic coming from the mobile 2. Definitions
network and towards anywhere to the Internet, is first forwarded by
the MR through the reverse tunnel MRHA to the HA. Then HA
decapsulates and forwards to the specific host on the home link or
outside the home link.
When the MR acts as a mobile host, vanilla Mobile IPv6 is used. MR Complete NEMO terminology can be found in [9].
can send both BUs with the R bit set and without the R bit set.
Depending on what is decided for the home address to be like
(link-local or other), the HA could deduce both.
A nemo solution with the MRHA tunnel should allow for a clean MH: a mobile host, which is a mobile node (MN) as defined by Mobile
separation between routing maintenance and mobility bindings IPv6, except all router parts. In Mobile IPv6 terminology, MN
maintenance. The route maintenance is done unmodified between MR can be either a host or a router. An MH can only be a host.
and BR, while the mobility bindings are done unmodified between MR
and HA.
Much of the argumentation made around routing can be considered as MR_HoA: mobile router's Home Address, or the home address of the
operator, or administrative issues, which seen otherwise can mobile (egress) interface of the mobile router.
discard some of the conclusions, but not all.
The document is organized as follows: the next sections present a MNP: mobile network prefix, or the prefix of the link of the mobile
description of the home network, where the HA could be co-located network that will move away. Note that in the most general
with the BR, or separated. Then a set of simple scenarios are case a single MR may route multiple prefixes, in which case
presented describing the normal routing behaviour of the MR when it there would be multiples MNPs per one mobile network.
is at home, and the desired behaviour of routing and of ND
messaging at home, when the MR is in a foreign network. These
scenarios are presented such that they expose the need for new
behaviours only in the case where the HA is separated from the BR;
otherwise (HA/BR co-located), all routing information is already
present in the HA. The following section presents possible
approaches for adding to HA routing information related to MR, one
based on ICMP Redirects, one based on static or dynamic routes
(from previous documents) and a third approach as a slight
modifications of dynamic routing where the HA "only listens" to
route updates but doesn't advertise.
Additional sections present other issues related to maintaining FN: fixed node on the home link. It doesn't stand for fixed
normal MR behaviour when it is not at home (e.g. renumbering or network.
multicast subscriptions) and then detailed behaviour of the HA and
of the MR. The Route Optimization problem and the Security
Considerations are briefly touched at the end.
1.1 Prior descriptions of mobile network support with Mobile IPv6 3. NEMO "Basic" preliminary descriptions
A complete description of the previous proposals to support mobile An exhaustive description of the proposals to support mobile
networks or mobile routers with Mobile IP bi-directional tunnel can networks or mobile routers with Mobile IP bi-directional tunnel can
not be made here due to space constraints. hardly fit in the usual space reserved for an Internet Draft, which
is traditionally a short document. We retain three main
descriptions: Cisco Mobile IPv4 for Mobile Routers [4], MRTP [13]
and the "Basic" approach [22].
The closest description to mobile network support in Mobile IPv6 MRTP is a method of enabling mobile routers by using dynamic tunnel
with the MRHA tunnel can be found in [13]. The approach described registrations between the AR's point of attachment and its HA.
in that document relies on the bidirectional tunnel between MR and This tunnel allows the HA to tunnel all traffic for the mobile
HA. The solution proposed is valid for Mobile IPv6 as for Mobile network prefix to the MR, and also lets the MR forward all mobile
IPv4. The MR and HA behaviours still represent a sensitive network traffic back to the home network, where it is topologically
departure from the Mobile IPv6 protocol in that MR informs its HA correct, and can avoid ingress routing in the visited network.
directly about the tunnel interface and dynamically triggers
additions of routing table entries in the HA's routing table for
the MR's tunnel. In addition, the most recent version of the draft
proposes usage of the PSBUs in order to inform the HA about the
prefix of the mobile network (thus a combination with the PSBU
approach). Moreover, the considerations about dynamic routing in
this draft refer only to how dynamic routing would work with a MR,
but not about the necessity of running a routing protocol between
HA and MR. See sections 6.2 and 6.3 for an overview of the methods
presented in these documents.
Using PSBUs as proposed in [8] and [13] has many other side-effects MRTP does not suffer from the authorization problem of how to show
not considered until recently. When the mobile network is assigned that the MR owns the routing authority for the Mobile Network.
several prefixes instead of one, then it is not clear whether
several BUs are being sent or only one with several prefixes The approach relies on the bidirectional tunnel between MR and HA.
inside. Remark that in the vanilla Mobile IPv6 case, only one CoA The solution proposed is valid for Mobile IPv6 as for Mobile IPv4.
can be sent with a BU (the alternative CoA is only an alternative The MR and HA behaviours still represent a sensitive departure from
not a substitute). the Mobile IPv6 protocol in that MR informs its HA directly about
the tunnel interface and dynamically triggers additions of routing
table entries in the HA's routing table for the MR's tunnel. In
addition, the most recent version of the draft proposes usage of
the PSBUs in order to inform the HA about the prefix of the mobile
network (thus a combination with the PSBU approach). Moreover, the
considerations about dynamic routing in this draft refer only to
how dynamic routing would work with a MR, but not about the
necessity of running a routing protocol between HA and MR.
In the Mobile IPv4 case, the network mobility support with the MRHA In the Mobile IPv4 case, the network mobility support with the MRHA
tunnel has been reported at least by various teams at Cisco [4] and tunnel has been reported at least by various teams at Cisco [4] and
NASA [14]. NASA [14].
2. Definitions The Basic protocol proposed in [22] takes a different tack at
assigning the home addresses: it assigns it to the MR's ingress
interface, instead of the egress interface. In addition, it
proposes a two step approach for the search algorithm in the HA's
binding cache: the first step is a search based on a key that is a
full /128 address, while the second step is a search based on
longest-prefix match. A new aspect is that this proposals relies
also on a (yet to be developped) prefix delegation scheme where the
HA assigns the mobile network prefix to MR, in a dynamic manner.
Many relevant definitions for network mobility with the MRHA (could For a more detailed analysis on the first two approaches (MRTP and
me spelled emra) tunnel can be found in [9]. In addition to those Cisco Mobile Routers) see sections A.4.2 and A.4.3.
definitions:
MRHA bidirectional tunnel, sometimes referred to as a reverse 4. Issues
tunnel. As described in [6], [12], [17], [20].
MIMR: the Mobile Interface of the Mobile Router: the interface that The following is a list of issues that we believe might be relevant
connects MR to the home link and that changes its Care-of Address when designing a Basic type of solution by the NEMO WG. Some of
when away from home. the issues are exemplified in the Appendices.
MR_HoA: mobile router's Home Address, or the home address of the 4.1 Implementation-independent specification terms
MIMR.
MNP: mobile network prefix, or the prefix of the link of the mobile The specification of the basic network mobility support should be
network that will move away. Note that in the most general case a expressed with implementation-independent terms. In other words,
single MR may route multiple prefixes, in which case there would be clear distinction should be made between the specification of the
multiples MNPs per one mobile network. protocol and a description of a possible implementation of this
protocol. Especially, since it is to be based on Mobile IP(v6), the
basic NEMO support specification should not make any assumption on
how Mobile IP(v6) is implemented but instead re-use (and possibly
extend) data structures from the Mobile IP(v6) specification
(e.g. Binding Cache), and eventually introduce new ones if
needed. Below are two examples of how attention should be payed in
the specification of the protocol.
FN: fixed node on the home link. It doesn't stand for fixed The bi-directional approach requires MR's HA to configure a
network. "forwarding information" for the mobile network prefix towards the
mobile router. Since the Mobile IP(v6) specification introduces a
dedicated structure, so-called Binding Cache, to store
mobility-related "forwading information" on the HA, the
specification of basic NEMO support should re-use/extend the
Binding Cache to include the new mobility-related "forwarding
information" for a mobile network. Even though a Binding Cache may
be implemented as an extension of a routing table, the
specification should relate to the Binding Cache and not the
routing table. For instance, the specification should relate to
the "forwading information" to be configured on MR's HA for the
mobile network prefix in terms of a prefix entry in the Binding
Cache instead of an entry in the routing table of MR's HA.
Especially, Mobile IP(v6) specification does not specify any
routing table for a HA.
3. Data structures Similarly, the specification should not assume that a tunnel,
e.g. the MRHA bi-directionnal tunnel, is visible as a virtual
network interface on the MR or HA. This is an
implementation-related consideration that may not be true for all
IP(v6)/MobileIP(v6) stacks.
A home agent that supports mobile networks maintains the following Such considerations will allow to clearly draw the line between the
structures: destination cache [19], binding cache [12] and routing specification and a description of a possible implementation, and
table [11]. The binding cache is modified from Mobile IPv6, such as a result ease any future implementation of the basic NEMO
that. The Home Agent also maintains the MRHA Tunnel Table. support as an extention of an existing Mobile IPv6 implementation.
A Mobile Router contains an on-link prefix list, a neighbour cache, 4.2 Allow for deployment flexibility
a destination cache, routing table, a binding update list, a home
agents list and so on.
Additionally, it contains an MRHA Tunnel Table with the following The basic NEMO support specification should not assume MR's HA to
fields: be co-located with the Border Router (BR) of MR's home network. The
-interface number HA should be allowed to be a one-interface machine, separated from
-address of the tunnel endpoint corresponding to the mobile BR, that does only NEMO HA functionalities (as a Mobile IP(v6) HA
router. This is normally a CoA. can be). This way, HA can be deployed in a home domain without the
-address of the tunnel endpoint corresponding to the home need to upgrade deployed BRs offering an easy deployment path.
agent. This is normally the HA address.
-list of entries present in the neighbour cache.
-list of entries present in the destination cache.
-list of entries present in the prefix list.
-list of entries present in the default router list.
-list of entries present in every other structure.
The idea behind the MRHA tunnel table is to have as little 4.3 Dynamic routing protocol and the HA
modifications as possible to the other ND and Mobile IPv6 tables
such that the MR acts as if it were at home, but across the MR-HA
tunnel.
All the mechanisms related to ND and classic routing are being Considering the case of a HA deployed as a one-interface machine
subjected to this tunnel table, such as to allow for mobility of not co-located with BR, the basic NEMO support specification should
the mobile network. One example is to stop doing ND for the home not mandate the HA to run a routing protocol, even in situation
address of the MR's interface that acquired a new CoA. It also when MR runs a routing protocol. On the other hand, such HA should
prevents the MR to have routing interactions with the visited allow MR and BR to continue running the dynamic routing protocol as
domain, but it alows it to continue having "normal" routing if MR was at home. Suffices it for the HA to: (1) join the
interactions with its home domain, including exchanging of normal corresponding multicast address, intercept all packets addressed to
dynamic routing messages, multicast routing messages, ICMP the link-local address of MR and encapsulate towards current MR CoA
redirects and others. and (2) relay, or forward, towards BR all dynamic routing message
exchanges coming from MR.
4. Description of a Home Network 4.4 Link-local addresses
According to section 10.4.2 of Mobile IPv6 spec [12] the HA will
not allow re-direction of traffic of a Home Address towards a CoA,
when that Home Address is link-local. Two relevant paragraphs:
"However, packets addressed to the mobile node's link-local
address MUST NOT be tunneled to the mobile node."
"Multicast packets addressed to a multicast address with
link-local scope [], to which the mobile node is subscribed,
MUST NOT be tunneled to the mobile node;"
which exposes, of course, the very nature of link-local addresses:
they are local, not going anywhere.
On another hand, OSPF for IPv6 [5] requires that:
"On all OSPF interfaces except virtual links, OSPF packets are
sent using the interface's associated link-local unicast address
as source."
Moreover, RIPng [16] requires that: (1) next hop addresses in
routing tables managed by RIPng be link-local and (2) a large part
of RIPng messages be originated and adressed to link-local
addresses:
"An address specified as a next hop must be a link-local
address."
or
"Response Messages: [...] the source of the datagram must be a
link-local address."
or
"Generating Response messages: [...] The IPv6 source address
must be a link-local address of the possible addresses of the
sending router's interface, except when replying to a unicast
Request Message from a port other than the RIPng port."
Overall, keeping in mind that Mobile IPv6 is not dealing with
link-local home addresses and that routing protocols and forwarding
process make substantial use of link-local addresses, the issue is
clearly how to make the routing protocols work together with Mobile
IPv6. Basic NEMO support specification should enable redirection of
traffic destined to MR's link-local addresses.
4.5 Mobile Router as a Mobile Host
There are several scenarios that involve an MR that needs to act as
a MH too, that is, send normal BUs and use existing Mobile IPv6.
Applications running on the MR should take advantage of MR's
session continuity and universal reachability at its home address.
For more example issues see section B.
4.6 Neighbour Discovery for MR's egress interface
Neighbour Discover on the MR's egress interface is particularly
delicate in that Neighbour Discovery should act differently when MR
is at home and when MR is in a foreign network. A simple example
is that when MR is at home, it has little reason to listen to RAs.
However, when MR is in a foreign network, receiving RAs is very
important in order to have a good working of Mobile IPv6. For more
example issues see section B.
4.7 Separation of routing and mobility for MR
The necessity of the distinction between mobility vs. routing
exchanges holds true irrespective to whether dynamic or static
routing is used. If static routing is used, then BR has routes
towards the mobile network through the MR, and MR has routes
towards the Internet through the BR. If dynamic routing is used,
then the MR and BR dynamically exchange routing information that is
manually configured in the routing configuration files of MR and of
BR, as well as routing information that is delivered by other
routers external to the home network (be it beyond the BR or beyond
the MR). The entities concerned with routing in the home network
are only BR and MR. This behaviour should continue when network
mobility is introduced, presumably by deploying an HA (but not
touching the BR). MR and HA should exchange only the information
related to mobility but not the information related to routing.
4.8 Prefix-based routing and host-based routing exceptions
Prefix-based hierarchical routing (where the mobile network link
has a prefix that is a subset of the home-network link) is the
preferred type of routing for IPv6. Practically though, it is
possible for the BR to have a routing table entry containing the
prefix of the mobile network, as well as a host-based entry that
points to a certain LFN also in the mobile network. Those two
entries might or might not have the same common sub-prefix. With a
MR at home, being a normal router, BR will know how to forward to
all hosts behind the MR as well as only to the specific LFN of the
host-based route. This behaviour should be maintained when the MR
is no longer at home and when it has a bidirectional tunnel MRHA.
4.9 IPv4 Issues
The mechanisms and issues described in this draft for IPv6 mobile
networks can be applied for IPv4 network mobility as well. RFC
3344 [21] provides important intuititve support for IPv4 network
mobility through the 'R' bit in Registration Requests/Replies.
Some solutions have already been successfully tested in [4] and
[14]. The support provided in RFC 3344 [21] as well as those
solutions keep the HA co-located with the BR. In a general case in
which the BR and HA are kept on separate machines (scenarios 9 to
16 in section A.2.3) the same issues as in IPv6 apply to the IPv4
case.
Additionally, in Mobile IPv4 there is a distinction between the MN
and FA functionality, and it is possible to have the FA separated
from the MN, whereas in IPv6 MN and FA are always co-located. This
gets us to the following additional cases:
-When the MR is in a visited network it can send BU's using a
co-located care-of address or a Foreing Agent care-of address
if an FA is available. In the latter case, two reverse
tunneling modes are possible: direct delivery style and
encapsulated delivery style [17].
-The MR may be itself a FA for Leaf Mobile Nodes (LMNs), or the
mobile network may contain a FA for LMNs.
4.10 "Cross-over" tunnels
A rough definition: two MR-HA tunnels are "crossing over" each
other when the path between one tunnel's endpoints includes only
one of the other tunnel's endpoints.
Support of nested mobile networks is possible only when the path
from MR2 to MR1's HA does not go through MR1 (path considered when
both mobile routers are at home and no tunnels are in place).
An example of the dynamics of two MR-HA crossing tunnels is given
in section B.6.
5. Security Considerations
A detailed threat analysis is to be performed for a NEMO "Basic"
type of solution. But that's what the Charter says anyways.
One issue is related to when the MR runs a dynamic routing
protocol. In that case, MR is able to inform the routers in the
home domain about new routes (or "inject" routes in the home
domain). Considering that MR might be a small device, not locked
in a highly secured room, not a tamper-proof device, potentially
being stolen, then it is clear that the ability to introduce routes
in the home domain, and worse, propagating upper to backbones, is
inducing serious risks.
5.1 A tool: HA ingress filtering
Home Agents supporting mobile networks are normally able to perform
ingress filtering, so that only topologically correct packets leave
the HA. See section B.7 on how HA could do ingress filtering.
Acknowledgements
Authors of this document acknowledge the following WG members and
non-members for their remarks, improvements to this draft and
fruitful discussions:
Tim Leinumeller for many insightful remarks and implementation
aspects.
Mattias Petterson.
Vijay Devarapalli.
TJ Kniveton.
Pekka P„„kk÷nen.
Mooi Choo Chuah.
Erik Nordmark.
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[2] Arkko, Jari, Devarapalli, Vijay, and Dupont, Francis, "Using
IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes
and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-03.txt,
IETF Internet Draft, February 2003. (Work in Progress).
[3] Baker, F. and Atkinson, R., "RIP-2 MD5 Authentication", RFC
2082, January 1997.
[4] Cisco authors, "Cisco Mobile Networks", whitepaper browsed
March 3rd, 2003 at
http://www.cisco.com/univercd/cc/td/doc/product/software/
ios122/122newft/122t/122t4/ftmbrout.pdf
[5] Coltun, R., Ferguson, D. and Moy, J., "OSPF for IPv6", RFC
2740, December 1999.
[6] Conta, A. and Deering, S.,"Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[7] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August
2000.
[8] Ernst, Thierry, Olivereau, Alexis, Bellier, Ludovic,
Castelluccia, Claude and Lach, Hong-Yon, "Mobile Networks
Support in Mobile IPv6",
draft-ernst-mobileip-v6-network-03.txt, IETF Internet Draft,
March 2002. (Work in Progress).
[9] Ernst, Thierry and Lach, Hong-Yon, "Network Mobility Support
Terminology", draft-ernst-nemo-terminology-01.txt, IETF
Internet Draft, November 2002. (Work in Progress).
[10] Harkins, D., Mankin, A., Narten, T., Nikander, P., Nordmark,
E., Patil, B. and Roberts, P., "Threat Models introduced by
Mobile IPv6 and Requirements for Security",
draft-ietf-mobileip-mipv6-scrty-reqts-02.txt, IETF Internet
Draft, November 2001. (Work in Progress).
[11] Hedrick, C., "Routing Information Protocol", RFC 1058, June
1998.
[12] Johnson, David B., Perkins, Charles E. and Arkko, Jari,
"Mobility Support in IPv6", draft-ietf-mobileip-ipv6-20.txt,
IETF Internet Draft, January 2003. (Work in Progress).
[13] Kniveton, Timothy J., Malinen, Jari T. and Devarapalli, Vijay,
"Mobile Router Tunneling Protocol",
draft-kniveton-mobrtr-03.txt, IETF Internet Draft, November
2003. (Work in Progress).
[14] Leung, K. and Shell, D. and Ivancic, W. D. and Stewart,
D. H. and Bell, T. L. and Kachmar, B. A., "Application of
Mobile-IP to Space and Aeronautical Networks", IEEE Proceedngs
of the Aerospace Conference, 2001.
[15] Malkin, G., "RIP Version 2, Carrying Additional Information",
RFC 1723, November 1994.
[16] Malkin, G., "RIPng for IPv6", RFC 2080, January 1997.
[17] Montenegro, G., ed., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, January 2001.
[18] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[19] Narten, T., Nordmark, E. and Simpson, W., "Neighbour Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[20] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[21] Perkins, C., ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[22] Wakikawa, R., Uehara, K., Mitsuya, K. and Ernst, T., "Basic
Network Mobility Support", draft-wakikawa-nemo-basic-00.txt,
IETF Internet Draft, February 2003. (Work in Progress).
Changes
October 2002: revision 00 submitted.
November 2002: revision 01:
-added discussion on multicast addresses with link-local scope.
-added Chairs' addresses.
-modified the abstract to better express the fact that /128s are
probably sufficient.
-added section on v4 issues, and Mobile IPv4 issues.
-added an empty IPR section.
March 2003: revision 02:
-major overhaul from revision 01: shorter, focused on main
issues, integrated some ml discussions, moved large "Motivation"
parts to appendices.
-added MH definition and used MH instead of MN when MR acts as an
MH.
-added more detailed acknowledgements.
-added "cross-over" tunnels discussion.
-added HA ingress filtering.
Appendix A: Motivation for Full Addresses in Binding Updates
An initial remark is that traffic coming from outside the home
link, or from other hosts on the home link, and directed to hosts
in the mobile network (or behind the mobile router) only need to go
through the L2 address of the mobile router (corresponding to its
L3 address). With Proxy ND [19], it is the HA that pretends to own
MR's L3 address by advertising new associations of the MR's L3
address to the its own L2 address, thus intercepting MR's home
traffic and forwarding it to the current CoA of the MR.
With this in mind, it can be stated that when the MR is in a
foreign network, traffic coming from hosts in the mobile network
and towards anywhere to the Internet, is first forwarded by the MR
through the reverse tunnel MRHA to the HA. Then HA decapsulates
and forwards to the address specified in the inner packet.
A.1 Description of a Home Network
When designing a NEMO solution with the MRHA tunnel, the first When designing a NEMO solution with the MRHA tunnel, the first
steps are to carefully consider the actual behaviour of the home steps are to carefully consider the actual behaviour of the home
network when the mobile network is at home, employing normal network when the mobile network is at home, employing normal
routing. Then this behaviour should be maintained as much as routing. Then this behaviour should be maintained as much as
possible when the MR is not at home (e.g. MR should be able to send possible when the MR is not at home (e.g. MR should be able to send
redirects through the MRHA tunnel); reciprocically, the normal redirects through the MRHA tunnel); reciprocically, the normal
behaviour of an FR at home should change when that FR is an MR and behaviour of an FR at home should change when that FR is an MR and
is at home (e.g. when MR at home, the MRHA tunnel should be torn is at home (e.g. when MR at home, the MRHA tunnel should be torn
down). When the MR is in a foreign network, its presence at home down). When the MR is in a foreign network, its presence at home
skipping to change at page 5, line 19 skipping to change at page 10, line 38
several local operator's views of smaller sized networks. Addition several local operator's views of smaller sized networks. Addition
of mobility should not change this. of mobility should not change this.
If static routing is used instead of dynamic routing, then static If static routing is used instead of dynamic routing, then static
routes are added manually both on MR and on the BR. When routes are added manually both on MR and on the BR. When
considering adding *static* routes in a *dynamic* manner for considering adding *static* routes in a *dynamic* manner for
prefixes shorter than /128 by Mobile IP, authors of this document prefixes shorter than /128 by Mobile IP, authors of this document
realize (in truth, hopefully) that Mobile IP starts using semantics realize (in truth, hopefully) that Mobile IP starts using semantics
that are traditionally belonging to routing protocols. that are traditionally belonging to routing protocols.
5. Scenarios A.2 Scenarios
For the sake of completetess, we first describe a simple "manual" For the sake of completetess, we first describe a simple "manual"
scenario for mobile networks based on the MRHA tunnel, that exposes scenario for mobile networks based on the MRHA tunnel, that exposes
relative simplicity, that uses static routing and doesn't use relative simplicity, that uses static routing and doesn't use
Mobile IP. Mobile IP.
Then, adding the Mobile IP behaviour, we present detailed scenarios Then, adding the Mobile IP behaviour, we present detailed scenarios
of communication between an FN on the home link and an LFN on the of communication between an FN on the home link and an LFN on the
mobile network link and a CN on the Internet, when the mobile mobile network link and a CN on the Internet, when the mobile
network is at home and away from home in a visited network, and network is at home and away from home in a visited network, and
skipping to change at page 5, line 49 skipping to change at page 11, line 13
MRHA tunnel. MRHA tunnel.
The scenarios where HA and BR are separated (9 up to 16) expose The scenarios where HA and BR are separated (9 up to 16) expose
that HA needs an entry in its routing table in order to be capable that HA needs an entry in its routing table in order to be capable
of forwarding packets to the MR (when it is not at home). of forwarding packets to the MR (when it is not at home).
An additional scenario is then presented where MR at home is using An additional scenario is then presented where MR at home is using
ICMP Redirect, a functionality that might be needed even when the ICMP Redirect, a functionality that might be needed even when the
MR is not at home. MR is not at home.
5.0 Manual mobile networks A.2.1 Manual Mobile Networks
Authors of this draft have experimented with "manual" mobile Authors of this draft have experimented with "manual" mobile
networks in IPv4, where the addition of routes and tunnels on the networks in IPv4, where the addition of routes and tunnels on the
MR and on the BR are done manually, by operators talking on the MR and on the BR are done manually, by operators talking on the
phone. phone.
A home network was used that contains about 10 routers and about 12 A home network was used that contains about 10 routers and about 12
subnets. That home network is connected to the Internet with a BR. subnets. That home network is connected to the Internet with a BR.
All routers have static routes among them. All routers have static routes among them.
Then, one slice of that home network (the mobile network) Then, one slice of that home network (the mobile network)
containing one "MR", one normal router and 6 subnets, was containing one "MR", one normal router and 6 subnets, was
disconnected from home, and moved across the Atlantic. Once the disconnected from home, and moved across the Atlantic. Once the
"MR" was connected on the other side, it was manually configured "MR" was connected on the other side, it was manually configured
with a new IPv4 address, mask and default route. Then a tunnel with a new IPv4 address, mask and default route. Then a tunnel
interface and a route were manually set up on the MR, a tunnel interface and a route were manually set up on the MR, a tunnel
interface and a route were manually set up on the BR. All other interface and a route were manually set up on the BR. All other
routes on all other routers where not touched. Mobile IP software routes on all other routers where not touched. Mobile IP software
skipping to change at page 6, line 28 skipping to change at page 11, line 45
acted, as if the mobile slice were at home. During this, several acted, as if the mobile slice were at home. During this, several
applications were tested between hosts in the mobile network, hosts applications were tested between hosts in the mobile network, hosts
in the home network and hosts on the Internet (incidentally, one of in the home network and hosts on the Internet (incidentally, one of
the applications was relying on Mobile IPv4 for hosts, but in no the applications was relying on Mobile IPv4 for hosts, but in no
relation with the mobile network moving). relation with the mobile network moving).
Again, this "manual" mobile networks scenario was not using any Again, this "manual" mobile networks scenario was not using any
dynamic routing protocol, and the tunnel was not supporting any dynamic routing protocol, and the tunnel was not supporting any
form of broadcast of multicast. form of broadcast of multicast.
5.1 Scenarios with co-located HA and BR A.2.2 Scenarios with Co-located HA and BR
1. FN sends packet to LFN, mobile network home, HA/BR colocated 1. FN sends packet to LFN, mobile network home, HA/BR colocated
---- ----
| FN | | FN |
---- ----
| ------- | -------
home link -------------------| HA/BR |---> Internet home link -------------------| HA/BR |---> Internet
| ------- | -------
---- ----- ---- -----
| MR | | LFN | | MR | | LFN |
---- ----- ---- -----
| | | |
mobile link --------- mobile link ---------
-FN scans its routing table for LFN's address, and finds default -FN scans its routing table for LFN's address, and finds default
route towards BR (if towards MR, see section 6.1). route towards BR.
-FN sends NS for L2 address of BR. -FN sends NS for L2 address of BR.
-BR replies NA. -BR replies NA.
-FN sends packet to BR. -FN sends packet to BR.
-BR scans its routing table for LFN's address, and finds route -HA scans its BC to find out whether MR is at home; BR scans its
through MR; routing table for LFN's address, and finds route through MR;
-BR sends NS for MR. -BR sends NS for MR.
-MR replies NA with its L2 address. -MR replies NA with its L2 address.
-BR forwards packet to MR and sends ICMP Redirect to FN such that -BR forwards packet to MR and sends ICMP Redirect to FN such that
subsequent packets from FN to LFN go straight through MR and not subsequent packets from FN to LFN go straight through MR and not
through BR. through BR.
-MR forwards packet to FN. -MR forwards packet to FN.
The sensitive issue exposed here is the way in which initially the The sensitive issue exposed here is the way in which initially the
packet travels from FN to BR to MR, the dynamic addition of an packet travels from FN to BR to MR, the dynamic addition of an
entry in the routing table of the FN (even if FN doesn't run a entry in the routing table of the FN (even if FN doesn't run a
skipping to change at page 8, line 41 skipping to change at page 14, line 4
-LFN sends NS for L2 address of MR. -LFN sends NS for L2 address of MR.
-MR replies NA. -MR replies NA.
-LFN sends packet to MR. -LFN sends packet to MR.
-MR encapsulates this packet through the MRHA tunnel and sends to -MR encapsulates this packet through the MRHA tunnel and sends to
HA. HA.
-HA receives this packet and decapsulates. -HA receives this packet and decapsulates.
-HA scans its routing table for FN's address, and finds route -HA scans its routing table for FN's address, and finds route
'on-link'; 'on-link';
-HA sends NS for FN. -HA sends NS for FN.
-FN replies NA with its L2 address. -FN replies NA with its L2 address.
-HA forwards packet to FN (on behalf of the MR). -HA forwards packet to FN (on behalf of the MR).
5. CN sends packet to LFN, mobile network home, HA/BR co-located 5. CN sends packet to LFN, mobile network home, HA/BR co-located
---- CN link ---- CN link
--| BR1|------ --| BR1|------
/ ---- | / ---- |
/ | / |
----------/ ---- ----------/ ----
------- | | | CN | ------- | | | CN |
----------------| HA/BR |---| Internet | ---- ----------------| HA/BR |---| Internet | ----
| home link ------- | | | home link ------- | |
---- ----- ----------\ ---- ----- ----------\
| MR | | LFN | \ | MR | | LFN | \
---- ----- \ ---- ----- \
| | | |
--------- ---------
mobile net link mobile net link
-BR receives packet from CN towards LFN. -BR receives packet from CN towards LFN.
-HA scans its BC to see whether MR is at home; BR scans its routing
-BR scans its routing table and finds dest through MR. table and finds dest through MR.
-BR sends NS for L2 address of MR and MR replies NA. -BR sends NS for L2 address of MR and MR replies NA.
-BR forwards packet to MR. -BR forwards packet to MR.
-MR forwards packet to LFN. -MR forwards packet to LFN.
6. CN sends packet to LFN, mobile network visits, HA/BR colocated 6. CN sends packet to LFN, mobile network visits, HA/BR colocated
---- CN link ---- CN link
--| BR1|------ --| BR1|------
/ ---- | / ---- |
/ | / |
skipping to change at page 10, line 40 skipping to change at page 16, line 5
mobile net mobile net
-MR receives packet from LFN towards CN. -MR receives packet from LFN towards CN.
-MR scans its tables and finds it needs to send it through the MRHA -MR scans its tables and finds it needs to send it through the MRHA
tunnel. tunnel.
-BR receives this packet, decapsulates and forwards to Internet. -BR receives this packet, decapsulates and forwards to Internet.
-BR1 forwards this packet to CN. -BR1 forwards this packet to CN.
(this is sometimes referred to as triangular routing, since the (this is sometimes referred to as triangular routing, since the
packet from LFN to CN travels artificially through BR) packet from LFN to CN travels artificially through BR)
5.2 Scenarios with HA and BR separated A.2.3 Scenarios with HA and BR Separated
9. FN sends packet to LFN, mobile network home, HA separated BR 9. FN sends packet to LFN, mobile network home, HA separated BR
---- ---- ---- ----
| FN | | HA | | FN | | HA |
---- ---- ---- ----
| | ---- | | ----
home link -------------------| BR |------> Internet home link -------------------| BR |------> Internet
| ---- | ----
---- ----- ---- -----
| MR | | LFN | | MR | | LFN |
skipping to change at page 12, line 4 skipping to change at page 17, line 24
through BR. BR also sends ICMP Redirect to HA, such that HA knows through BR. BR also sends ICMP Redirect to HA, such that HA knows
a route through MR. The logic of this last ICMP Redirect is a route through MR. The logic of this last ICMP Redirect is
described in section 6.1. described in section 6.1.
-HA scans its routing table for LFN's address, and finds through MR; -HA scans its routing table for LFN's address, and finds through MR;
-HA scans binding cache and finds 'through MRHA tunnel'; -HA scans binding cache and finds 'through MRHA tunnel';
-HA encapsulates and sends packet to MR. -HA encapsulates and sends packet to MR.
-MR decapsulates and forwards to LFN. -MR decapsulates and forwards to LFN.
The problem in the above case is how to inform the HA about the The problem in the above case is how to inform the HA about the
route towards MR. When MR at home, and HA being a host, normally route towards MR. When MR at home, and HA being a host, normally
HA doesn't have a route towards MR. See discussion in section 6.1. HA doesn't have a route towards MR.
11. LFN sends packet to FN, mobile network home, HA separated BR 11. LFN sends packet to FN, mobile network home, HA separated BR
---- ---- ---- ----
| FN | | HA | | FN | | HA |
---- ---- ---- ----
| | ---- | | ----
home link -------------------| BR |------> Internet home link -------------------| BR |------> Internet
| ---- | ----
---- ----- ---- -----
| MR | | LFN | | MR | | LFN |
skipping to change at page 13, line 58 skipping to change at page 19, line 31
---- ----- ---- -----
| MR | | LFN | | MR | | LFN |
---- ----- ---- -----
| | | |
--------- ---------
mobile net mobile net
-BR receives packet from CN towards LFN. -BR receives packet from CN towards LFN.
-BR scans its routing table to and finds dest through MR. -BR scans its routing table to and finds dest through MR.
-BR sends NS for L2 address of MR. HA replies NA on behalf of MR. -BR sends NS for L2 address of MR. HA replies NA on behalf of MR.
-BR sends Redirect to HA informing it about a route towards MR. -BR sends Redirect to HA informing it about a route towards MR.
See section 6.1 on a discussion about this ICMP Redirect.
-Simultaneously with previous packet, BR forwards packet to HA. -Simultaneously with previous packet, BR forwards packet to HA.
-HA scans its routing table and finds an entry to MR (added as a -HA scans its routing table and finds an entry to MR (added as a
result to ICMP redirect), it also has a BC entry for MR, so it result to ICMP redirect), it also has a BC entry for MR, so it
sends the packet through the MRHA tunnel. sends the packet through the MRHA tunnel.
The problem in the above case is how to inform the HA about the The problem in the above case is how to inform the HA about the
route towards MR. When MR at home, and HA being a host, normally route towards MR. When MR at home, and HA being a host, normally
HA doesn't have a route towards MR. See discussion in section 6.1. HA doesn't have a route towards MR.
15. LFN sends packet to CN, mobile network home, HA separated BR 15. LFN sends packet to CN, mobile network home, HA separated BR
---- CN link ---- CN link
--| BR1|------ --| BR1|------
---- / ---- | ---- / ---- |
| HA | / | | HA | / |
---- ----------/ ---- ---- ----------/ ----
| ---- | | | CN | | ---- | | | CN |
-------------------| BR |---| Internet | ---- -------------------| BR |---| Internet | ----
skipping to change at page 15, line 5 skipping to change at page 20, line 29
---- ----- ---- -----
| MR | | LFN | | MR | | LFN |
---- ----- ---- -----
| | | |
--------- ---------
mobile net mobile net
-MR receives packet from LFN towards CN. -MR receives packet from LFN towards CN.
-MR encapsulates this packet through the MRHA tunnel. -MR encapsulates this packet through the MRHA tunnel.
-HA receives this packet, decapsulates and sends to CN. -HA receives this packet, decapsulates and sends to CN.
5.3 MR Redirects to BR A.3 MR Redirects to BR
Also, consider the scenario where the FN has a default route Also, consider the scenario where the FN has a default route
towards the MR instead of the BR, and sending packets to a CN on towards the MR instead of the BR, and sending packets to a CN on
the Internet. This might very well happen when the MR is at home the Internet. This might very well happen when the MR is at home
and sending RAs, in addition to the RAs sent by the BR. FN might and sending RAs, in addition to the RAs sent by the BR. FN might
configure a default route through the MR instead of the BR. If MR configure a default route through the MR instead of the BR. If MR
is at home, MR will redirect the FN towards the BR. So, even if is at home, MR will redirect the FN towards the BR. So, even if
this looks like a wrong configuration on the FN (its default route this looks like a wrong configuration on the FN (its default route
should point to BR and not MR), packets will still travel correctly should point to BR and not MR), packets will still travel correctly
when MR is at home. This should be maintained when the MR is not when MR is at home. This should be maintained when the MR is not
at home. There are two possibilities: either the HA (replacing the at home. There are two possibilities: either the HA (replacing the
MR) redirects the FN towards the BR, or it is the MR itself that MR) redirects the FN towards the BR, or it is the MR itself that
sends the respective ICMP redirect message to the FN (through the sends the respective ICMP redirect message to the FN (through the
MRHA tunnel). The first case supposes that HA maintains a routing MRHA tunnel). The first case supposes that HA maintains a routing
table, which contains routes towards the mobile network. This is table, which contains routes towards the mobile network. This is
less desirable if the HA is not co-located with BR, and where we less desirable if the HA is not co-located with BR, and where we
prefer not to have routing interactions with the HA. The latter prefer not to have routing interactions with the HA. The latter
case is more plausible, keeping the default routing behaviour to case is more plausible, keeping the default routing behaviour to
the MR. the MR.
6. Informing the HA about the route to MR A.4 Informing the HA about the Route to MR
In certain scenarios presented previously, with the HA dissociated In certain scenarios presented previously, with the HA dissociated
from the BR and the MR in the visited network, there is a need for from the BR and the MR in the visited network, there is a need for
the HA to maintain in its routing table an entry towards the MR. A the HA to maintain in its routing table an entry towards the MR. A
scenario where packets from CN towards LFN are looping between MR scenario where packets from CN towards LFN are looping between BR
and HA has been described in detail in section 3.2.4 of [8]. and HA has been described in detail in section 3.2.4 of [8].
Several solutions exist to avoid this looping, described below. Several solutions exist to avoid this looping, described below.
6.1 ICMP Redirect from BR to HA A.4.1 ICMP Redirect from BR to HA
One alternative for avoiding the loop problem is by using ICMP One alternative for avoiding the loop problem is by using ICMP
Redirects [19] sent by BR to HA in order to communicate to HA the Redirects [19] sent by BR to HA in order to communicate to HA the
route it misses towards the MR. ICMP Redirects are deployed and route it misses towards the MR. ICMP Redirects are deployed and
used in existing networks. The classic behaviour of ICMP Redirects used in existing networks. The classic behaviour of ICMP Redirects
is presented in scenario 1. Scenarios 10 and 14 with is presented in scenario 1. Scenarios 10 and 14 with
MR-not-at-home and BR dissociated from HA, present the fact that MR-not-at-home and BR dissociated from HA, present the fact that
classic ICMP Redirects are not triggered normally and thus classic ICMP Redirects are not triggered normally and thus
modifications are needed. modifications are needed.
skipping to change at page 16, line 8 skipping to change at page 21, line 34
of BR. of BR.
-another possibility is for BR to react at the moment it receives -another possibility is for BR to react at the moment it receives
the proxy NA from HA (on behalf of the MR), compare to the the proxy NA from HA (on behalf of the MR), compare to the
current entry it has in the Neighbour Cache for MR, and then current entry it has in the Neighbour Cache for MR, and then
decide that, because MR has moved away, send Redirect to HA to decide that, because MR has moved away, send Redirect to HA to
inform HA about the route to MR. This is the route (or set of inform HA about the route to MR. This is the route (or set of
routes) normally maintained by the BR with the MR, doesn't routes) normally maintained by the BR with the MR, doesn't
contain any form of the new position (CoA) of the MR. This contain any form of the new position (CoA) of the MR. This
route, or set of routes (in which case a set of Redirects are route, or set of routes (in which case a set of Redirects are
sent), is copied from MR's routing table. All routes that have sent), is copied from BR's routing table. All routes that have
destination the MR's home address need to be communicated to HA destination the MR's home address need to be communicated to HA
with ICMP Redirects. This modifies the normal behaviour of BR. with ICMP Redirects. This modifies the normal behaviour of BR.
-yet another possibility is to consider modifications on HA (from -yet another possibility is to consider modifications on HA (from
vanilla Mobile IPv6), but don't touch BR, such that HA generates vanilla Mobile IPv6), but don't touch BR, such that HA generates
a new packet, thus obtaining a classic ICMP Redirect from BR. a new packet, thus obtaining a classic ICMP Redirect from BR.
When the HA receives a packet that is not for itself, it When the HA receives a packet that is not for itself, it
encapsulates it with an IP-in-IP tunnel, having the src address encapsulates it with an IP-in-IP tunnel, having the src address
its own address and the destination address copied from the dst its own address and the destination address copied from the dst
address of the original packet. Then try to route this packet address of the original packet. Then try to route this packet
and find the default route towards BR. Then BR sends a normal and find the default route towards BR. Then BR sends a normal
ICMP Redirect informing HA there is a better route for this ICMP Redirect informing HA there is a better route for this
packet towards MR. Thus HA acquires the MR route dynamically. packet towards MR. Thus HA acquires the MR route dynamically.
The packet will be passed on by BR to HA again, and further The packet will be passed on by BR to HA again, and further
details are needed here. Remark that this is equivalent to one details are needed here. Remark that this is equivalent to one
iteration of the loop (a particular case of the fixed iterations iteration of the loop (a particular case of the fixed iterations
loop mentioned previously). loop mentioned previously).
6.2 Static route method A.4.2 Static Route Method
This is proposed by [4] and [13], where operator statically This is proposed by [4] and [13], where a route is statically
introduces a route in the HA, for MR's prefix, towards MR's introduced in the HA upon receiption of a Binding Update from
address, or towards the specific MRHA tunnel. MR. This route for MR's prefix may point towards MR's home address
(next hop), towards a specific tunnel to MR's home address(output
interface), or towards a specific tunnel to MR's care-of address
(output interface).
The first approach proposed in [4] suggests to configure a new The first approach proposed in [4] suggests to configure a new
static tunnel on the MR's HA towards MR_HoA. This static tunnel, static tunnel on the MR's HA towards MR_HoA. This static tunnel,
that we call here MR_HoA_tunnel, is to be used as output interface that we call here MR_HoA_tunnel, is to be used as output interface
of a new static entry added in the routing table of HA for MR's of a new static entry added in the routing table of HA for MR's
prefix: MR prefix -> MR_HoA_tunnel. Upon reception of a data prefix: MR prefix -> MR_HoA_tunnel. Upon reception of a data
packet from CN addressed to a LFN, MR's HA will consult its routing packet from CN addressed to a LFN, MR's HA will consult its routing
table and find a match for that packet for this static route since table and find a match for that packet for this static route since
LFN address matches MR's prefix. As a results it will encapsulate LFN address matches MR's prefix. As a results it will encapsulate
the packet with an additional header that will have MR's HA as the packet with an additional header that will have MR's HA as
skipping to change at page 17, line 6 skipping to change at page 22, line 34
The second approach proposed in [13] suggests a similar method but The second approach proposed in [13] suggests a similar method but
avoids the overhead introduced by the two tunnels. It consists in avoids the overhead introduced by the two tunnels. It consists in
configuring a static route in MR's HA routing table for MR's prefix configuring a static route in MR's HA routing table for MR's prefix
towards MR's Home Address: MR prefix -> MR_HoA. Upon reception of towards MR's Home Address: MR prefix -> MR_HoA. Upon reception of
a data packet from CN addressed to a LFN, MR's HA will consult its a data packet from CN addressed to a LFN, MR's HA will consult its
routing table and, again, find a match for that packet for this routing table and, again, find a match for that packet for this
static route since LFN address matches MR's prefix. This indicates static route since LFN address matches MR's prefix. This indicates
the MR's HA that the packet should be routed towards MR_HoA. From the MR's HA that the packet should be routed towards MR_HoA. From
its binding cache it discovers MR's CoA and as a consequence its binding cache it discovers MR's CoA and as a consequence
forwards the incoming packet for CN directly through the MRHA forwards the incoming packet from the CN directly through the MRHA
tunnel. This approach reduces the overhad of the MR_HoA_tunnel but tunnel. This approach reduces the overhead of the MR_HoA_tunnel but
requires a suitable coordination of the routing table and binding requires a suitable coordination of the routing table and binding
cache on the HA. cache on the HA.
A third possible approach is similar to the previous one but
directly uses the MR's care-of address as the tunnel termination
point instead of MR's home address. As such the new static entry
added in the routing table of HA for MR's prefix is then MR prefix
-> MRHA_tunnel.
Analyzed from the perspective where HA is separated from BR, and Analyzed from the perspective where HA is separated from BR, and
where MR doesn't normally maintain routes with HA, then this where MR doesn't normally maintain routes with HA, then this
addition might seem superfluous. Consider a situation where MR and addition might seem superfluous. Consider a situation where MR and
BR maintain routing information and where that manual route is BR maintain routing information and where that manual route is
added on HA. When the MR is not at home, consider that added on HA. When the MR is not at home, consider that
administrator decides to add a new fixed subnet at home, with its administrator decides to add a new fixed subnet at home, with its
own router neighbouring with BR on the home link. Consider the new own router neighbouring with BR on the home link. Consider the new
subnet's prefix being a longer prefix derived from the prefix subnet's prefix being a longer prefix derived from the prefix
assigned to the MR's subnet. This is perfectly feasible by assigned to the MR's subnet. This is perfectly feasible by
changing configurations on the MR and BR. That can work perfectly changing configurations on the MR and BR. That can work perfectly
even if MR is not at home. But if HA doesn't participate in this even if MR is not at home. But if HA doesn't participate in this
exchange (which is the case if HA separated from BR) then the exchange (which is the case if HA separated from BR) then the
manual route added previously in the HA is no longer valid. Thus, manual route added previously in the HA is no longer valid. Thus,
a potential issue. a potential issue.
Further explanation or simplification needed here. Using PSBUs as proposed in [8] and [13] has many side-effects not
clearly considered. When the mobile network is assigned several
prefixes instead of one, then it is not clear whether several BUs
are being sent or only one with several prefixes inside. Remark
that in the vanilla Mobile IPv6 case, only one CoA can be sent with
a BU (the alternative CoA is only an alternative not a substitute).
6.3 Dynamic route method A.4.3 Dynamic Route Method
It is possible for the HA, being either separated or co-located It is possible for the HA, being either separated or co-located
with the BR, to run a specific routing protocol, participating in with the BR, to run a specific routing protocol, participating in
the routing interactions between BR and all other neighbouring the routing interactions between BR and all other neighbouring
routers on the home link. Thus, the HA always has the necessary routers on the home link. Thus, the HA always has the necessary
route it needs to join the MR's network. route it needs to join the MR's network.
If the HA is a one-interface machine, and separated from the BR, it If the HA is a one-interface machine, and separated from the BR, it
seems that it maintains information that is not always necessary to seems that it maintains information that is not always necessary to
its well working as a HA. For example, it will maintain routes to its well working as a HA. For example, it will maintain routes to
skipping to change at page 17, line 60 skipping to change at page 23, line 44
advertise. advertise.
RIP [11] supports having a silent host that only listens to update RIP [11] supports having a silent host that only listens to update
messages, but does not advertise new routes. With OSPF [18] the messages, but does not advertise new routes. With OSPF [18] the
"listening only" requirement is complicated by the fact that the HA "listening only" requirement is complicated by the fact that the HA
would needs to participate in OSPF's HELLO protocol. would needs to participate in OSPF's HELLO protocol.
The advantage of using this solution is that it does not require The advantage of using this solution is that it does not require
additional changes to Mobile IPv6, and PSBUs are not needed. The additional changes to Mobile IPv6, and PSBUs are not needed. The
disadvantage is that if the MR does not run a routing protocol then disadvantage is that if the MR does not run a routing protocol then
we still need some way of telling the HA the routes to the MNPs, we still need some way of telling the HA the routes to the MNPs.
which gets us back to sections 6.1 and 6.2.
Further explanation or simplification needed here.
7. Other Issues
7.1 Link-local addresses
When the MR is at home, and if it runs a dynamic routing protocol,
it exchanges routing information with BR, by using its link-local
address and BR's link-local address. When the MR is not at home,
and HA defends the MR's home address, the HA is normally doing this
for any type of addresses except link-locals. The immediate
necessity would be for the HA to defend a link-local address of the
MR, instead of a global-scoped home address. However, this is in
conflict with the necessity of dynamic routing protocols to use
link-local addresses only.
According to section 6.3 of Mobile IPv6 spec [] the HA will not
allow re-direction of traffic of a Home Address towards a CoA, when
that Home Address is link-local.
Even more concrete, section 6.3 of MIPv6 says that it is not
possible to put a ll-address in a HA option. Of course this is
equivalent.
Another issue concerning link local addresses: the MR has routes to
the BR using BR's link local address. When the MR is away from
home: how does the MR reach BR's link local address? How does it
tell the difference between a link local address on the home link
and a link local address on the visited link?
Moreover, Mobile IPv6 forbids re-directing (through the MHHA Appendix B: Examples and Other Issues
tunnel) of packets addressed to a multicast address with
link-scope. RIP uses this extensively.
7.2 MR as an MN B.1 Example of issue for Mobile Router as Mobile Host
If the MR is at home and it has an address configured on the moving If the MR is at home and it has an address configured on the moving
interface other than a link-local address, then the MR can act as interface other than a link-local address, then the MR can act as
an MH too, and send normal Mobile IPv6 BUs, binding that Home an MH too, and send normal Mobile IPv6 BUs, binding that Home
Address to a newly configured CoA; thus allowing the MR to be an MH Address to a newly configured CoA; thus allowing the MR to be an MH
for itself only, ignoring the LFNs. If the MR at home doesn't have for itself only, ignoring the LFNs. If the MR at home doesn't have
other addresses than link-local on the mobile interface then the MR other addresses than link-local on the mobile interface then the MR
can not send normal Mobile IPv6 BUs and can not be an MH. It can can not send normal Mobile IPv6 BUs and can not be an MH. It can
however be an MR for the hosts on the mobile network. however be an MR for the hosts on the mobile network.
7.3 Prefix-based routing and host-based routing B.2 Multicast Subscriptions of the MR
Prefix-based hierarchical routing (where the mobile network link
has a prefix that is a subset of the home-network link) is the
preferred type of routing for IPv6. Practically though, it is
possible for the BR to have a routing table entry containing the
prefix of the mobile network, as well as a host-based entry that
points to a certain LFN also in the mobile network. Those two
entries might or might not have the same common sub-prefix. With a
MR at home, being a normal router, BR will know how to forward to
all hosts behind the MR as well as only to the specific LFN of the
host-based route. This behaviour should be maintained when the MR
is no longer at home and when it has a bidirectional tunnel MRHA.
7.4 Multicast subscriptions of the MR
When the MR is at home, it normally joins certain multicast groups When the MR is at home, it normally joins certain multicast groups
related to routing (e.g. all-routers multicast group with site related to routing (e.g. all-routers multicast group with site
scope). This is assumed by dynamic routing protocols, or by scope). This is assumed by dynamic routing protocols, or by
renumbering mechanisms. When the MR is no longer at home, its renumbering mechanisms. When the MR is no longer at home, its
multicast subscription should continue as if it were at home. This multicast subscription should continue as if it were at home. This
can be achieved by "home subscription" techniques considered in can be achieved by "home subscription" techniques considered in
relation with Mobile IPv6. relation with Mobile IPv6.
7.5 Neighbour Discovery for MR B.3 Examples of issues for Neighbour Discovery for MR
When MR is at home and sends RA towards the home link, it should When MR is at home and sends RA towards the home link, it should
not advertise itself as being capable of being a default router not advertise itself as being capable of being a default router
(Router Lifetime should be 0). (Router Lifetime should be 0).
When the MR is visiting, it should not respond to RSs sent on the When the MR is visiting, it should not respond to RSs sent on the
visited link and it should not send RAs on the visited link. visited link and it should not send RAs on the visited link.
When the MR is at home, it doesn't normally use any information When the MR is at home, it doesn't normally use any information
received from RAs sent by a neighbouring router, i.e. the BR. It received from RAs sent by a neighbouring router, i.e. the BR. It
skipping to change at page 19, line 29 skipping to change at page 24, line 36
received in RAs more than for logging and synchronization purposes. received in RAs more than for logging and synchronization purposes.
When the MR is in a foreign network, it needs a way to configure a When the MR is in a foreign network, it needs a way to configure a
Care-of Address. In the hosts case this is done by stateless or Care-of Address. In the hosts case this is done by stateless or
stateful autoconf. In the MR case, the stateful is possible, while stateful autoconf. In the MR case, the stateful is possible, while
the stateless is normally prohibited. A good way for address the stateless is normally prohibited. A good way for address
autococnfiguration for the MR should be identified, be it DHCP, or autococnfiguration for the MR should be identified, be it DHCP, or
modified RAs, or modified router's behaviour to accept RAs. modified RAs, or modified router's behaviour to accept RAs.
Assume the MR is at home and a non-link-local (site- or global) Assume the MR is at home and a non-link-local (site- or global)
home address is configured on the interface connecting to the home home address is configured on the interface connecting to the home
link (supposedly the same interface that will change CoAqs when link (supposedly the same interface that will change CoAs when
visiting). The MR-at-home will do periodic NAs for this home visiting). The MR-at-home will do periodic NAs for this home
address; this behaviour should stop when MR is visiting. This address; this behaviour should stop when MR is visiting. This
modified behaviour is already taken into consideration by Mobile modified behaviour is already taken into consideration by Mobile
IPv6 MN. In the particular MR case, most ND operations of MR are IPv6 MN. In the particular MR case, most ND operations of MR are
delegated to the HA, and such most entries of Neighbour Cache, delegated to the HA, and such most entries of Neighbour Cache,
Destination Cache that are related to the home link will disappear. Destination Cache that are related to the home link will disappear.
New entries that are relevant in the foreign network will populate New entries that are relevant in the foreign network will populate
those tables. When coming back home, all ND entries should be those tables. When coming back home, all ND entries should be
replaced back with the entries related to the home network. replaced back with the entries related to the home network.
Another specific case in point is the default route. As already Another specific case in point is the default route. As already
presented with the router behaviour with respect to RAs, a default presented with the router behaviour with respect to RAs, a default
route is not normally configured by MR from a received RA. When route is not normally configured by MR from a received RA. When
the MR is in a foreign network, it should have a default route that the MR is in a foreign network, it should have a default route that
points to its BR (but through the MRHA tunnel) and another points to its BR (but through the MRHA tunnel) and another
non-tunnelled default route towards the current AR. Moreover, all non-tunnelled default route towards the current AR. Moreover, all
MR's routing table entries that pointed to BR when the MR was at MR's routing table entries that pointed to BR when the MR was at
home, should still continue to point to BR (through the MRHA home, should still continue to point to BR (through the MRHA
tunnel). The same is true for all routing table entries of the BR. tunnel). The same is true for all routing table entries of the BR.
7.6 Separation of routing and mobility for MR B.4 Router Renumbering
The necessity of the separation between mobility vs. routing
exchanges holds true irrespective to whether dynamic or static
routing is used. If static routing is used, then BR has routes
towards the mobile network through the MR, and MR has routes
towards the Internet through the BR. If dynamic routing is used,
then the MR and BR dynamically exchange routing information that is
manually configured in the routing configuration files of MR and of
BR, as well as routing information that is delivered by other
routers external to the home network (be it beyond the BR or beyond
the MR). The entities concerned with routing in the home network
are only BR and MR. This behaviour should continue when network
mobility is introduced, presumably by deploying an HA (but not
touching the BR). MR and HA should exchange only the information
related to mobility but not the information related to routing.
7.7 Router Renumbering
Router Renumbering for IPv6 [7] is a technique where routers of a Router Renumbering for IPv6 [7] is a technique where routers of a
home network are instructed to change the prefixes they advertise. home network are instructed to change the prefixes they advertise.
In the context here, it should be possible for the MR to be In the context here, it should be possible for the MR to be
re-numbered when it is at home as well as when it is visiting. re-numbered when it is at home as well as when it is visiting.
The renumbering mechanisms provided by Mobile IPv6 (mobile prefix The renumbering mechanisms provided by Mobile IPv6 (mobile prefix
solicitations and advertisements) are not relevant for changing the solicitations and advertisements) are not relevant for changing the
prefixes advertised by the MR towards the mobile network; but these prefixes advertised by the MR towards the mobile network; but these
mechanisms should still be used for MR when MR is acting as an MH. mechanisms should still be used for MR when MR is acting as an MH.
In order for router renumbering to work for MR when acting as MR, In order for router renumbering to work for MR when acting as MR,
the MR should at least be able to maintain its multicast the MR should at least be able to maintain its multicast
subscription to all-routers group valid at home. subscription to all-routers group valid at home.
7.8 IPv4 issues B.5 Example of disconnected operation issue
The mechanisms and issues described in this draft for IPv6 mobile
networks can be applied for IPv4 network mobility as well. RFC
3344 [21] provides important intuititve support for IPv4 network
mobility through the 'R' bit in Registration Requests/Replies.
Some solutions have already been successfully tested in [4] and
[14]. The support provided in RFC 3344 [21] as well as those
solutions keep the HA co-located with the BR. In a general case in
which the BR and HA are kept on separate machines (scenarios 9 to
16 in Section 5.2) the same issues as in IPv6 apply to the IPv4
case.
Additionally, in Mobile IPv4 there is a distinction between the MN
and FA functionality, and it is possible to have the FA separated
from the MN, whereas in IPv6 MN and FA are always co-located. This
gets us to the following additional cases:
-When the MR is in a visited network it can send BU's using a
co-located care-of address or a Foreing Agent care-of address
if an FA is available. In the latter case, two reverse
tunneling modes are possible: direct delivery style and
encapsulated delivery style [17].
-The MR may be itself a FA for Leaf Mobile Nodes (LMNs), or the
mobile network may contain a FA for LMNs.
Some of these issues have been identified in [22].
8. Mobile Router behaviour
The MR-HA tunnel is an IP-in-IP tunnel maintained by MR and HA.
This is not a "tunnel" in the sense referred to sometimes by
employing the IPv6 routing headers.
The behaviour of the Mobile Router is the behaviour of a normal
router with the main exception of the order of search in relevant
routing tables, with the addition of a step to search in the MRHA
tunnel table. The exact search steps will be detailed later.
Various implementations do it in various ways.
A generic behaviour of a router forwarding a packet having
destination d, or the behaviour of MR when it is at home:
-determine the packet is for itself or not, by comparing d to all
addresses assigned to all interfaces.
-if not for itself then search the routing table for a prefix that
matches d under a prefix. Pick d2.
-search the destination cache for an exact match for d2. If found,
then send the packet to the L2 address in the DC entry. If not
found, then create it by doing the ND exchange; then send it to
what ND found.
From that behaviour, here is the modified mobile router behaviour:
-determine the packet is for itself or not, by comparing d to all
addresses assigned to all interfaces.
-if not for itself then search the routing table for a prefix that
matches d under a prefix. Pick d2.
+determine whether this entry in the routing table has a
corresponding entry in the MRHA tunnel table. If yes, then
encapsulate towards the HA marked there and create a new packet,
with source s CoA and new destination d from the tunnel table
(Home Agent address).
-search the destination cache for an exact match for d2, and that
is not linked to the tunnel table. If found, then send the packet
to the L2 address in the DC entry. If not found, then create it
by doing the ND game; then send it to what ND found.
8.1 CoA Configuration
This can be done by configuring an address based on a prefix
received from the AR. However, routers don't take into account
RAs, normally. It can be solved by saying that in this case MR is
not quite a router but more of a host.
It can also be done by means of DHCPv6 messaging, where there is no
distinction between hosts and routers.
8.2 Discovering HA
Do it as a Mobile IPv6 MH, except that. Anycast.
8.3 Sending BUs to HA
Do the normal Mobile IPv6 signalling with its Home Agent. The BUs
sent contain a distinguishing bit 'R'.
8.4 Search order in various tables
Further complicating the mobile routing issues, the Destination
Cache is being specified with the option of being capable of being
fusioned with the Routing Table. The same stands for the Binding
Cache. It is then possible to have the DC, the BC and the routing
table as a unique and only large routing table. With this kinds of
unknowns, it is difficult for the authors, at present time, to
specify a proper search order in the respective structures, even if
we feel this is truly important. Or probably the behaviour of a MR
and HA can be specified without going into the details of these
structures, leaving implementations freedom of choice.
9. Home Agent behaviour
The MR-HA tunnel is an IP-in-IP encapsulation tunnel [20]
maintained by MR and HA. This is not a "tunnel" in the sense
referred to sometimes by employing the IPv6 routing headers.
The behaviour of the Home Agent is the behaviour of a normal Mobile
IPv6 HA with the main exception of the order of search in relevant
routing tables, with the addition of a step to search in the MRHA
tunnel table. The exact search steps will be detailed.
The Home Agent uses proxy-ND to defend the link-local address of
the MR when the MR is not at home. When the MR is at home, the HA
stops defending MR's link-local address.
When the MR is not at home, the L2 address of the link-local
address of the MR is requested by neighbouring routers (such as BR)
or by FNs that have entries in their routing tables or destination
caches through MR's link-local address. HA should reply to these
requests with its own L2 address and as such receive all packets
that have dst address containing any address of all hosts and
routers in the mobile network. Following this, the HA will search
its BC as well as its routing table, then it will encapsulate those
packets through the MRHA tunnel and sent according to the normal
HA's destination cache and routing tables, towards the current
Care-of Address of the Mobile Router.
When HA is a host, HA doesn't need to have a routing table
containing entries towards MR or hosts and routers behind MR. When
HA is a host, HA's routing table should contain only entries
related to the neighbouring fixed routers. For example HA has a
default route towards BR.
10. Route Optimization
Route Optimization problem description is elsewhere.
RO is an absolutely necessary need for mobile networks for Mobile
IPv6.
It might very well be that the need for RO might bring with it the
need to put prefixes in the BUs towards CN.
The previous scenarios allow for nested mobile networks as well.
But the functioning suffers of drawbacks.
The MRHA-enhanced Mobile IPv6 scenarios described previously suffer
from important drawbacks, such as multiple nested tunnels, lack of
route optimization with the CN.
An example of an important inconvenient of using exclusively An example of an important inconvenient of using exclusively
vanilla Mobile IPv6 with MRHA is when nesting: consider two mobile vanilla Mobile IPv6 with MRHA is when nesting: consider two mobile
networks, each MR having its own HA in different domains. The networks, each MR having its own HA in different domains. The
first MR attaches to an AR and the second MR attaches under the first MR attaches to an AR and the second MR attaches under the
first mobile network. In this case, two LFNs situated one on the first mobile network. In this case, two LFNs situated one on the
first net and the second on the second net are capable to first net and the second on the second net are capable to
communicate with each other, but communication goes through both communicate with each other, but communication goes through both
first MR's HA and through second's. In practice this exposes a first MR's HA and through second's. In practice this exposes a
paradox where if first MR loses connection to AR, then even if the paradox where if first MR loses connection to AR, then even if the
two nets stay attached, the two LFNs can not communicate. two nets stay attached, the two LFNs can not communicate.
11. Security Considerations B.6 Example for the "cross-over" tunnels issue
Security threat analysis of Mobile IPv6 when a Mobile Router is
used instead of a Mobile Host. Not a threat analysis of RO.
The threat analysis of Mobile IPv6 for hosts is presented in [10].
When router moves instead of host, new threats appear.
When MR at home and using secured RIP [3] or OSPF [18] (whose IPv6
version [5] employs IPsec), then that level of security must be
maintained when MR is away from home.
11.1 Security of the MRHA tunnel
The MRHA tunnel is protected as required by the Mobile IPv6
specification for the MNHA tunnel [2].
MR and HA maintain a security association, share the same key.
11.2 Security for Route Optimization
Since RO is not treated in this document, then the return
routability tests for MR are not described.
MR could do CoTI for MR's CoA and HoTI for LFN's address. In that
case LFN's address must be bound to MR, presumably by delegation
mechanisms.
MR if acting as an MN must do HoTI/CoTI for itself, if that MN
needs RO. If MR acting as MN, then its LFNs must not take
advantage of the results of having an SA MN-CN. Or if they do,
then MR must have some form of delegation support.
Acknowledgements
Some of the issues presented in this document have not yet been
discussed publicly, as far as the authors are aware, except for the
places where specific references to prior drafts is explicitely
made. Some of the issues have been discussed on the nemo mailing
list, and proper acknowledgment will be given here. This document
being submitted for public review, all comments are welcome and
contributors will be properly acknowledged.
Intellectual Property Rights Considerations
Consult Motorola on IPRs. Put the url here.
Changes
October 2002: revision 00 submitted.
November 2002: revision 01:
-added discussion on multicast addresses with link-local scope.
-added Chairs' addresses.
-modified the abstract to better express the fact that /128s are
probably sufficient.
-added section on v4 issues, and Mobile IPv4 issues.
-added an empty IPR section.
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[2] Arkko, Jari, Devarapalli, Vijay, and Dupont, Francis, "Using
IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes
and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-01.txt,
IETF Internet Draft, October 2002. (Work in Progress).
[3] Baker, F. and Atkinson, R., "RIP-2 MD5 Authentication", RFC
2082, January 1997.
[4] Cisco authors, "Cisco Mobile Networks", whitepaper browsed
October 25, 2002 at
http://www.cisco.com/univercd/cc/td/doc/product/software/
ios122/122newft/122t/122t4/ftmbrout.pdf
[5] Coltun, R., Ferguson, D. and Moy, J., "OSPF for IPv6", RFC Consider the following example, where both MRs are at home and where
2740, December 1999. MR1's mobile network contains HA2. MR1 belongs to HA1 and MR2
belongs to HA2.
----------/
------- | |
-----------------------| HA1/BR|---| Internet |
| ------- | |
| ----------
----- -----
| MR1 | | HA2 |
----- -----
| |
------------
|
----- -----
| MR2 | | LFN |
----- -----
| |
------------
[6] Conta, A. and Deering, S.,"Generic Packet Tunneling in IPv6 In the next step, consider that the MR2's mobile network goes visit
Specification", RFC 2473, December 1998. AR, like in the figure below:
[7] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August ----------/
2000. ------- | |
---------------| HA1/BR|---| Internet |
| ------- | |
----- ----- ----------\
| MR1 | | HA2 | \
----- ----- -----
| | | AR |
------------ -----
|
----- -----
| MR2 | | LFN |
----- -----
| |
------------
[8] Ernst, Thierry, Olivereau, Alexis, Bellier, Ludovic, The tunnel setup procedure of this movement is between MR2 and HA2.
Castelluccia, Claude and Lach, Hong-Yon, "Mobile Networks This tunnel can be easily setup; consider now the next movement:
Support in Mobile IPv6",
draft-ernst-mobileip-v6-network-03.txt, IETF Internet Draft,
March 2002. (Work in Progress).
[9] Ernst, Thierry and Lach, Hong-Yon, "Network Mobility Support ----------/
Terminology", draft-ernst-nemo-terminology-00.txt, IETF ------- | |
Internet Draft, October 2002. (Work in Progress). | HA1/BR|---| Internet |
------- | |
----------\
\
-----
| AR |
-----
|
----- -----
| MR2 | | LFN |
----- -----
| |
------------
|
----- -----
| MR1 | | HA2 |
----- -----
| |
------------
[10] Harkins, D., Mankin, A., Narten, T., Nikander, P., Nordmark, After this movement, MR1 tries to setup its bidirectional tunnel
E., Patil, B. and Roberts, P., "Threat Models introduced by with HA1, by sending a BU to HA1. This BU is encapsulated by MR2
Mobile IPv6 and Requirements for Security", towards HA2. However, HA2 is no longer at home (having moved
draft-ietf-mobileip-mipv6-scrty-reqts-02.txt, IETF Internet together with MR1); thus the tunnel between MR1 and HA1 can not be
Draft, November 2001. (Work in Progress). set up, because if it were set up, it would have "crossed over" the
tunnel between MR2 and HA2. If one were to draw the two tunnels in
the above picture, a tunnel would be between MR2 and HA2 and the
other between MR1 and HA1. The path MR1-HA1 includes only the MR2
endpoint of the tunnel MR2-HA2.
[11] Hedrick, C., "Routing Information Protocol", RFC 1058, June B.7 Example of use of HA ingress filtering
1998.
[12] Johnson, David B., Perkins, Charles E. and Arkko, Jari, HA should verify that packets it receives from the MRHA tunnel have
"Mobility Support in IPv6", draft-ietf-mobileip-ipv6-18.txt, a source address that matches what's in HA's routing table. HA
IETF Internet Draft, June 2002. (Work in Progress). should have a route for the mobile prefix pointing into the MRHA
tunnel, and the LFN should have use a source address derived from
that prefix when sending its packets. Other packets will be
dropped.
[13] Kniveton, Timothy J., Malinen, Jari T. and Devarapalli, Vijay, Appendix C: A Digression
"Mobile Router Support with Mobile IP",
draft-kniveton-mobrtr-02.txt, IETF Internet Draft, July
2002. (Work in Progress).
[14] Leung, K. and Shell, D. and Ivancic, W. D. and Stewart, Two types of approaches have been distinguished in designing a
D. H. and Bell, T. L. and Kachmar, B. A., "Application of network mobility support with Mobile IPv6 and the bidirectional
Mobile-IP to Space and Aeronautical Networks", IEEE Proceedngs tunnel.
of the Aerospace Conference, 2001.
[15] Malkin, G., "RIP Version 2, Carrying Additional Information", Clean-slate Mobile IP-centric approach
RFC 1723, November 1994.
[16] Malkin, G., "RIPng for IPv6", RFC 2080, January 1997. In this approach, it is assumed that a home network is in fact a
new 1-link network. This home network connects to the Internet
with one or more BRs. The BRs have HA functionality with Mobile IP
for hosts. There are no other routers or hosts in the home network
than the BRs and the MRs. MRs are seldom at home. MRs and BRs
would presumably have little need to run a dynamic routing
protocol. Most, if not all, routing information exhanges happen
with Mobile IP BUs.
[17] Montenegro, G., ed., "Reverse Tunneling for Mobile IP, Nodes in the mobile networks communicate with CNs. Those CNs are
revised", RFC 3024, January 2001. anywhere in the Internet, but not in the home network (there's no
node in the home network than BRs and/or other MRs).
[18] Moy, J., "OSPF Version 2", RFC 2328, April 1998. Evolutionary approach
[19] Narten, T., Nordmark, E. and Simpson, W., "Neighbour Discovery In this type of approach, it is assumed that a home network is
for IP Version 6 (IPv6)", RFC 2461, December 1998. already deployed. The home network has several routers that run
dynamic routing protocols (non-Mobile IP) to maintain connectivity
between various endpoints. The home network is connected to the
Internet with one or more BRs.
[20] Perkins, C., "IP Encapsulation within IP", RFC 2003, October From this, it is possible to "mobilize" some slices (or chunks of
1996. this network), maintaining session continuity and reachability at a
permanent home address for fixed nodes of that slice. Consider
that the slice that needs to be physically disconnected from the
home network uses a router (called "MR") that connects the slice to
the home network. A minimal deployment effort could be the
following: (1) modify software on MR and (2) place a new box with
new software on the link where MR was connecting the slice to the
home network (this entity called "HA"). MR and the slice move away
and HA stays in place.
[21] Perkins, C., ed., "IP Mobility Support for IPv4", RFC 3344, Intellectual Property Rights Considerations
August 2002.
[22] Sarikaya, B., "Architectural Requirements for Base Network Consult Motorola on IPR (authors believe no IPR here, but depends
Mobility Using Bidirectional Tunneling", who asks; the complete and authoritative answers can be found from
draft-sarikaya-nemo-archreqs-00.txt, IETF Internet Draft, IPD or Public Relations of Motorola, corelated with IPD of ECRL).
October 2002. (Work in Progress).
Chairs' Addresses Chairs' Addresses
Thierry Ernst, Timothy J. Kniveton Thierry Ernst, Timothy J. Kniveton
French National Institute for Communication Systems Lab French National Institute for Communication Systems Lab
Research in Computer Science and Nokia Research Center Research in Computer Science and Nokia Research Center
Control 313 Fairchild Drive Control 313 Fairchild Drive
Visiting Researcher at WIDE Mountain View, California 94043 Visiting Researcher at WIDE Mountain View, California 94043
Project USA Project USA
Jun Murai lab. Faculty of Phone: +1 650 625-2025 Jun Murai lab. Faculty of Phone: +1 650 625-2025
Environmental Information, EMail: timothy.kniveton@nokia.com Environmental Information, EMail: timothy.kniveton@nokia.com
Keio University. Fax: +1 650 625-2502 Keio University. Fax: +1 650 625-2502
5322 Endo, Fujisawa-shi, Kanagawa 5322 Endo, Fujisawa-shi, Kanagawa
252-8520, Japan. 252-8520, Japan.
Phone : +81-466-49-1100 Phone : +81-466-49-1100
Fax : +81-466-49-1395 Fax : +81-466-49-1395
E-mail: ernst@sfc.wide.ad.jp E-mail: ernst@sfc.wide.ad.jp
Web: Web:
http://www.sfc.wide.ad.jp/~ernst/ http://www.sfc.wide.ad.jp/~ernst/
Authors' Addresses Authors' Addresses
 End of changes. 88 change blocks. 
571 lines changed or deleted 645 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/