NEMO Working Group Vijay Devarapalli
INTERNET DRAFT Nokia
Category: Standards Track Ryuji Wakikawa
Expires June 2004 Keio University
Alexandru Petrescu
Motorola
Pascal Thubert
Cisco Systems
December 2003
Network Mobility (NEMO) Basic Support Protocol
draft-ietf-nemo-basic-support-02.txt
Status of This Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
This document describes the NEMO Basic Support protocol that enables
mobile networks to attach to different points in the Internet. The
protocol is an extension of Mobile IPv6 and allows for session
continuity for every node in the mobile network as the network moves.
It also allows every node in the mobile network to be reachable while
moving around. The Mobile Router, which connects the network to the
Internet, runs the NEMO Basic Support protocol with its Home Agent.
The protocol is designed in such a way that network mobility is
transparent to the nodes inside the mobile network.
Devarapalli, et al. [Page 1]
Internet Draft NEMO Basic Support December 2003
Contents
Status of This Memo 1
Abstract 1
1. Introduction 4
2. Terminology 5
3. Overview of the NEMO Protocol 6
4. Message Formats 9
4.1. Binding Update . . . . . . . . . . . . . . . . . . . . . 9
4.2. Binding Acknowledgement . . . . . . . . . . . . . . . . . 9
4.3. Mobile Network Prefix Option . . . . . . . . . . . . . . 10
5. Mobile Router Operation 12
5.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 12
5.2. Sending Binding Updates . . . . . . . . . . . . . . . . . 13
5.3. Receiving Binding Acknowledgements . . . . . . . . . . . 13
5.4. Error Processing . . . . . . . . . . . . . . . . . . . . 14
5.5. Establishment of Bi-directional Tunnel . . . . . . . . . 15
5.6. Neighbor Discovery for Mobile Router . . . . . . . . . . 16
5.7. Multicast Groups for Mobile Router . . . . . . . . . . . 16
5.8. Returning Home . . . . . . . . . . . . . . . . . . . . . 16
6. Home Agent Operation 18
6.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 18
6.1.1. Binding Cache . . . . . . . . . . . . . . . . . . 18
6.1.2. Prefix Table . . . . . . . . . . . . . . . . . . 18
6.2. Mobile Network Prefix Registration . . . . . . . . . . . 19
6.3. Advertising Mobile Network Reachability . . . . . . . . . 20
6.4. Establishment of Bi-directional Tunnel . . . . . . . . . 20
6.5. Forwarding Packets . . . . . . . . . . . . . . . . . . . 21
6.6. Sending Binding Acknowledgements . . . . . . . . . . . . 21
6.7. Mobile Network Prefix De-Registration . . . . . . . . . . 22
7. Modifications to Dynamic Home Agent Discovery 23
7.1. Modified Dynamic Home Agent Discovery Request . . . . . . 23
7.2. Modified Dynamic Home Agent Discovery Reply . . . . . . . 23
7.3. Modified Home Agent Information Option . . . . . . . . . 24
8. Support for Dynamic Routing Protocols 25
9. Security Considerations 27
Devarapalli, et al. [Page 2]
Internet Draft NEMO Basic Support December 2003
10. IANA Considerations 28
11. Contributors 28
12. Acknowledgements 28
A. Examples of NEMO Basic Support Operation 31
B. Changes from Previous Version 34
Devarapalli, et al. [Page 3]
Internet Draft NEMO Basic Support December 2003
1. Introduction
This document describes protocol extensions to Mobile IPv6 (MIPv6)
[1] to enable support for network mobility. The extensions are
backward compatible with Mobile IPv6. In particular, a NEMO
compliant Home Agent can operate as a Mobile IPv6 Home Agent as well.
The NEMO Basic Support works in such a way that session continuity is
ensured for all the nodes in the mobile network even as the Mobile
Router changes its point of attachment to the Internet. It also
provides connectivity and reachability for all nodes in the mobile
network as the network moves. The solution supports both mobile
nodes and hosts that do not support mobility in the mobile network.
Within the context of this document, the definition of a Mobile
Router extends that of a Mobile IPv6 [1] Mobile Node, by adding
the capability of routing between its point of attachment (Care-of
Address) and a subnet which moves with the Mobile Router.
The solution described in this document requires setting up a
bi-directional tunnel between the Mobile Router and its Home Agent.
This tunnel is set up when the Mobile Router sends a successful
Binding Update to its Home Agent, informing the Home Agent of its
current point of attachment.
All traffic between the nodes in the mobile network and Correspondent
Nodes passes through the Home Agent. This document does not describe
route optimization of this traffic.
The terminology document [9] describes Nested Mobility as a scenario
where a Mobile Router allows another Mobile Router to attach to its
mobile network. There could be arbitrary levels of nested mobility.
The operation of each Mobile Router remains the same whether the
Mobile Router attaches to another Mobile Router or to a fixed Access
Router on the Internet. The solution described here does not place
any restriction on the number of levels for nested mobility. But it
should be noted that this might introduce significant overhead on the
data packets as each level of nesting introduces another IPv6 header
encapsulation.
Devarapalli, et al. [Page 4]
Internet Draft NEMO Basic Support December 2003
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
Network Mobility related terminology is defined in [8] [9]. This
document in addition defines the following terms.
Mobile Network Prefix
An IPv6 prefix that is delegated to a Mobile
Router and advertised in the mobile network. There could
be more than one Mobile Network Prefix being advertised in
a mobile network.
Prefix Table
It is a list of Mobile Network Prefixes indexed by
the Home Address of a Mobile Router. The prefix table is
managed by the Home Agent and is used by the Home Agent
to determine which Mobile Network Prefixes belong to a
particular Mobile Router.
Devarapalli, et al. [Page 5]
Internet Draft NEMO Basic Support December 2003
3. Overview of the NEMO Protocol
A Mobile Network is a network segment or subnet which can move and
attach to arbitrary points in the Internet. A mobile network can
only be accessed via specific gateways called Mobile Routers that
manage its movement. Mobile networks have atleast one Mobile Router
serving them. A Mobile Router does not distribute the mobile network
routes to the infrastructure at its point of attachment (i.e. in the
visited network). Instead, it maintains a bidirectional tunnel to a
Home Agent that advertises an aggregation of mobile networks to the
infrasructure. The Mobile Router is also the default gateway for the
mobile network.
A mobile network can also consist of multiple and nested subnets. A
router with no support for mobility may be permanently attached to
a mobile network for local distribution. Also, Mobile Routers may
be attached to mobile networks owned by different Mobile Routers and
form a graph. In particular, with Basic NEMO Support, each Mobile
Router is attached to another mobile network by a single interface,
and if loops are avoided, the graph is a tree.
A Mobile Router has an unique Home Address through which it is
reachable when it is registered with its Home Agent. The Home
Address is configured from a prefix that is aggregated and advertised
by its Home Agent. The prefix could either be the prefix advertised
on the home link or the prefix delegated to the Mobile Router.
The Mobile Router can have more than one Home Address if there
are multiple prefixes in the home link. The Mobile Router also
advertises one or more prefixes in the mobile network attached to it.
The actual mechanism for assigning these prefixes to a given Mobile
Router is outside the scope of this specification.
When the Mobile Router moves away from the home link and attaches to
a new access router, it acquires a Care-of Address from the visited
link. The Mobile Router can at any time act either as a Mobile Host
or a Mobile Router. In either case, as soon as the Mobile Router
acquires a Care-of Address, it immediately sends a Binding Update to
its Home Agent as described in [1]. When the Home Agent receives
this Binding Update it creates a binding cache entry binding the
Mobile Router's Home Address to its Care-of address at the current
point of attachment.
If the Mobile Router wishes to act as a Mobile Router and provide
connectivity to nodes in the mobile network, it indicates this to the
Home Agent by setting a flag (R) in the Binding Update. It MAY also
include information about the Mobile Network Prefix in the Binding
Update using one of the modes described in Section 5.2, so that the
Home Agent can forward packets meant for nodes in the mobile network
to the Mobile Router. A new Mobility Header Option is described in
Devarapalli, et al. [Page 6]
Internet Draft NEMO Basic Support December 2003
this document to carry prefix information. This option is described
in Section 4.3. If the mobile network has more than one IPv6 prefix
and wants the Home Agent to setup forwarding for all these prefixes,
it includes multiple prefix information options in a single Binding
Update. The Home Agent sets up forwarding for each of these prefixes
to the Mobile Router's Care-of Address. In some scenarios the Home
Agent already knows which prefixes belong to a Mobile Router. In
these scenarios, the Mobile Router does not include any prefix
information in the Binding Update. The Home Agent sets up forwarding
for all prefixes owned by the Mobile Router, when it receives a
Binding Update from the mobile router with the router flag (R) set.
The Home Agent acknowledges the Binding Update by sending a Binding
Acknowledgement to the Mobile Router. A positive acknowledgement
means that the Home Agent has set up forwarding for the mobile
network. Once the binding process completes, a bi-directional tunnel
is established between the Home Agent and the Mobile Router. The
tunnel end points are Mobile Router's Care-of Address and the Home
Agent's address. If a packet with a source address belonging to
the Mobile Network Prefix is received from the mobile network, the
Mobile Router reverse-tunnels the packet to the Home Agent through
this tunnel. This reverse-tunneling is done by using IP-in-IP
encapsulation [3]. The Home Agent decapsulates this packet and
forwards it to the Correspondent Node. For traffic originated by
itself, the Mobile Router can use either reverse tunneling or route
optimization as specified in [1].
When a data packet is sent by a Correspondent Node to a node in the
mobile network, it gets routed to the Home Agent which currently
has the binding for the Mobile Router. It is expected that the
Mobile Router's network prefix would be aggregated at the Home Agent,
which advertises the resulting aggregation. Alternatively, the Home
Agent may receive the data packets destined to the mobile network
by advertising routes to the Mobile Network Prefix. The actual
mechanism by which these routes are advertised is outside the scope
of this document. When the Home Agent receives a data packet meant
for a node in the mobile network, it tunnels the packet to Mobile
Router's current Care-of address. The Mobile Router decapsulates
the packet and forwards it onto the interface where the mobile
network is connected. The Mobile Router before decapsulating the
tunneled packet, has to check if the Source address on the outer IPv6
header is the Home Agent's address. It also has to make sure the
destination address on the inner IPv6 header belongs to one of its
Mobile Network Prefixes before forwarding the packet to the mobile
network.
The mobile network could consist of nodes that do not support
mobility and nodes that support mobility. A node in the mobile
network can also be a fixed or a mobile router. The protocol
Devarapalli, et al. [Page 7]
Internet Draft NEMO Basic Support December 2003
described here ensures complete transparency of network mobility to
the nodes in the mobile network. Mobile Nodes that attach to the
mobile network treat it as a normal IPv6 access network and run the
Mobile IPv6 protocol.
It is also possible for the Mobile Router and the Home Agent to run
a routing protocol through the bi-directional tunnel. In that case,
the Mobile Router need not include prefix information in the Binding
Update. Instead the Home Agent uses the routing protocol updates to
setup forwarding for the mobile network. When running the routing
protocol it is required that the bi-directional tunnel be treated as
a tunnel interface. The tunnel interface is included as the list of
interfaces on which routing protocol is active. The Mobile Router
should be configured not to run the routing protocol on its egress
interface when it is away from the home link.
Finally, the Home Agent may be configured with static routes to the
Mobile Network Prefix via the Mobile Router's Home Address. In that
case, the routes are set independently of the binding flows and the
returning Home of a Mobile Router. The benefit is that such movement
does not induce any additional signalling in the form of routing
updates in the Home Network. The drawback of that model is that the
routes are present even if the related Mobile Routers that are not
reachable (at Home or bound) at a given point of time.
Devarapalli, et al. [Page 8]
Internet Draft NEMO Basic Support December 2003
4. Message Formats
4.1. Binding Update
A new flag (R) is included in the Binding Update to indicate to the
Home Agent if the Binding Update is coming from a Mobile Router
and not from a mobile node. The rest of the Binding Update format
remains the same as defined in [1].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|R| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Flag (R)
The Mobile Router Flag is set to indicate to the Home Agent
that the Binding Update is from a Mobile Router. If the flag
is set to 0, the Home Agent assumes that the Mobile Router is
just behaving as a Mobile Node, and MUST NOT forward packets
destined for the mobile network to the Mobile Router.
Mobility Options
Variable length field which can include zero or more mobility
options. This document defines a new mobility option in
addition to what is defined in [1].
For a description of the other fields in the message, see [1].
4.2. Binding Acknowledgement
A new flag (R) is included in the Binding Acknowledgement to indicate
that the Home Agent which processed the corresponding Binding Update
supports Mobile Routers. The flag is set only if the corresponding
Binding Update had the Mobile Router flag (R) set to 1. The rest of
Devarapalli, et al. [Page 9]
Internet Draft NEMO Basic Support December 2003
the Binding Acknowledgement format remains the same as defined in
[1].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Flag (R)
The Mobile Router Flag is set to indicate that the Home Agent
which processed the Binding Update supports Mobile Routers. It
is set to 1 only if the corresponding Binding Update had the
Mobile Router flag set to 1.
For a description of the other fields in the message, see [1].
This document also introduces the following new Binding
Acknowledgement status values.
140 Mobile Router Operation not permitted
141 Invalid Prefix
142 Not Authorized for Prefix
143 Forwarding Setup failed
Status values less than 128 indicate that the Binding Update was
processed successfully by the receiving nodes. Values greater than
128 indicate that the Binding Update was rejected by the Home Agent.
4.3. Mobile Network Prefix Option
The Mobile Network Prefix Option is included in the Binding Update
to indicate to the Home Agent the prefix information for the mobile
network. There could be multiple Mobile Network Prefix Options
Devarapalli, et al. [Page 10]
Internet Draft NEMO Basic Support December 2003
if the Mobile Router has more than one IPv6 prefix in the mobile
network and wants the Home Agent to forward packets for each of these
prefixes to the Mobile Router's current location.
The Mobile Network Prefix Option has an alignment requirement of
8n+4. Its format is as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Mobile Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA
Length
8 bit unsigned integer indicating the length in octets of the
option excluding the type and length fields. Set to 18.
Reserved
This field is unused for now. The value MUST be initialized to
zero by the sender, and MUST be ignored by the receiver.
Prefix Length
8 bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option.
Mobile Network Prefix
A 16 byte field contains the Mobile Network Prefix.
Devarapalli, et al. [Page 11]
Internet Draft NEMO Basic Support December 2003
5. Mobile Router Operation
Mobile Router operation is derived largely from the combined
behaviors of a Host, of a Router [6], and of a Mobile Node [1].
A Mobile Node can act in two different ways: (1) as a Mobile Host
(in which case the Mobile IPv6 Home Agent doesn't maintain any prefix
information related to the Mobile Host's Home Address, but does
maintain a binding cache entry related to the Mobile Host's Home
Address) and (2) as a Mobile Router (in which case, in addition to
maintaining the binding cache entry corresponding to the Mobile
Router Home Address, the Mobile IPv6 Home Agent also maintains
forwarding information related to prefixes assigned to the mobile
network). The distinction between the the two modes is represented
by the value of the Mobile Router flag (R).
A Mobile Router MUST implement all requirements for IPv6 Mobile
Nodes, Section 8.5 in [1]. However if a Mobile Router is not
expected to initiate sessions of its own and behaves purely as a
router serving the mobile network most of the time, then the Route
Optimization functionality MAY be implemented.
5.1. Data Structures
Like a Mobile Host, a Mobile Router also maintains a Binding Update
List, described in Section 11.1 of Mobile IPv6 specification[1]. The
Binding Update list is a conceptual data structure which records
information that is sent in the Binding Updates. There is one entry
per each destination that the Mobile Router is currently sending
Binding Updates to.
This document introduces a new Prefix Information field in the
Binding Update list structure. This field is used to store any
prefix information that the Mobile Router includes in the Binding
Update. If the Mobile Router sets the Mobile Router flag (R) in the
Binding Update, but does not include any prefix information in it
this field is set to null. The Mobile Router does not include prefix
information in the Binding Update in the implicit mode or when it
runs a dynamic routing protocol with its Home Agent.
Similar to a Mobile Host, a Mobile Router stores the information
regarding status of flags of the Binding Update, in the corresponding
Binding Update List entry. This document introduces a new mobile
router flag (R) for this entry. The status of this flag is stored in
the Binding Update list whenever a Binding Update is sent.
A Mobile Router also maintains a Home Agent list populated according
to the same procedure as a Mobile Host.
Devarapalli, et al. [Page 12]
Internet Draft NEMO Basic Support December 2003
5.2. Sending Binding Updates
A Mobile Router sends Binding Updates to its Home Agent as described
in [1]. It uses one of the following modes to instruct the Home
Agent to determine the prefixes that belong to the Mobile Router. In
all the modes, the Mobile Router sets the Mobile Router flag (R).
Implicit:
In this mode, the Mobile Router does not include either a
Mobile Network Prefix Option or a Mobile Network Prefix Length
Option in the Binding Update (but it does include the Home
Address Option in the Destination Options header, as all Mobile
Hosts do). The Home Agent can use any mechanism (not defined
in this document) to determine the Mobile Network Prefix(es)
owned by the Mobile Router and setup forwarding for the mobile
network. One example would be manual configuration at the
Home Agent mapping the Mobile Router's Home Address to the
information required for setting up forwarding for the mobile
network.
Explicit:
In this mode, the Mobile Router includes one or more Mobile
Network Prefix Options in the Binding Update. These options
contain information about the Mobile Network Prefix(es)
configured on the mobile network.
A Mobile Router MUST implement atleast one mode and MAY implement
both modes. If the Mobile Router flag is set, Home Registration flag
(H) MUST be set.
5.3. Receiving Binding Acknowledgements
The Mobile Router receives Binding Acknowledgements from the Home
Agent, corresponding to the Binding Updates it sent. If the Binding
Acknowledgement status is set to '0' (Binding Update accepted) and
the Mobile Router flag (R) is set to 1, the Mobile Router assumes
that the Home Agent has successfully processed the Binding Update
and has set up forwarding for the mobile network. The Mobile Router
can then start using the bi-directional tunnel for reverse tunneling
traffic from the mobile network. If the Mobile Router flag (R) is
not set, then the Mobile Router concludes that its current Home
Agent does not support Mobile Routers and performs Dynamic Home
Agent Discovery again to discover Home Agents which support Mobile
Routers. Additional the Mobile Router MUST also de-register with the
Home Agent which did not support Mobile Routers before attempting
registration with another Home Agent.
Devarapalli, et al. [Page 13]
Internet Draft NEMO Basic Support December 2003
5.4. Error Processing
If the Binding Acknowledgement status is set to a value between 128
and 140, the Mobile Router takes necessary actions as described in
the Mobile IPv6 specification [1].
If the Mobile Router sent a Binding Update to the Home Agent in
implicit mode (i.e. the prefix field in the Binding Update list
entry is null) then the Mobile Router interprets only the error
status '140' (Mobile Router Operation not permitted) and '143'
(Forwarding Setup failed). For this Binding Update, the Mobile
Router MUST discard Binding Acknowledgements with codes '141' and
'142'.
For the same Binding Update, if the status is '140', then the Mobile
Router should send a similar Binding Update (implicit mode) to
another Home Agent on the same home link. If no Home Agent replies
positively then the Mobile Router MUST refrain from sending any
Binding Update with the Mobile Router flag set to any Home Agent on
the home link, and log the information.
For the same Binding Update, if the status is '143', then the Mobile
Router should send a similar Binding Update (implicit mode) to
another Home Agent on the same home link. If no Home Agent replies
positively then Mobile Router SHOULD refrain from sending this
Binding Update to any Home Agent on the home link, and MAY send
Binding Updates in another mode (e.g. explicitly include a prefix)
to a Home Agent on the same home link.
If the Mobile Router sent a Binding Update to Home Agent in explict
mode then the Mobile Router interprets only the error status
'141' (Invalid Prefix) and '142' (Not Authorized for Prefix).
For this Binding Update, the Mobile Router MUST discard Binding
Acknowledgements with codes '140' and '143'.
For the same Binding Update, if the status is set to '141', then the
Mobile Router should send a similar Binding Update to another Home
Agent on the same home link. If no Home Agent replies positively
then Mobile Router SHOULD refrain from sending this Binding Updates
to any Home Agent on the home link. At this point, Mobile Router MAY
try to obtain and own a prefix by the same means that it initially
got assigned the current Mobile Network Prefix. Alternatively,
Mobile Router MAY send Binding Updates in another mode (e.g.
implicit mode) to a Home Agent on the same home link.
For the same Binding Update, if the status is set to '142', then the
Mobile Router should send a similar Binding Update to another Home
Agent on the same home link. If no Home Agent replies positively
then Mobile Router SHOULD refrain from sending this Binding Updates
Devarapalli, et al. [Page 14]
Internet Draft NEMO Basic Support December 2003
to any Home Agent on the home link. Additionally, the Home Agent
MUST stop advertising the respective prefix(es) in the mobile network
with associated Router Advertisements, and modify its own forwarding
information accordingly. Following this, the Mobile Router MAY send
Binding Updates in another mode (e.g. implicit) to a Home Agent on
the same home link.
If at the end of this Error Processing procedure the Mobile Router
has tried every available modes of sending Binding Updates and still
has not received a positive Binding Acknowledgement (status value
between 0 and 127) for this Home Address from any Home Agent on its
home link, then the Mobile Router MUST stop sending Binding Updates
with the Mobile Router flag set for this Home Address and log the
information.
In all the above cases, the Mobile Router MUST conclude that the Home
Agent did not create a binding cache entry for the Mobile Router's
Home Address.
5.5. Establishment of Bi-directional Tunnel
When a successful Binding Acknowledgement is received, the Mobile
Router sets up its endpoint of the bi-directional tunnel.
The bi-directional tunnel between Mobile Router and Home Agent allows
packets to flow in both directions between these entities, while the
Mobile Router is connected to a Visited Link. The bi-directional
tunnel involves two virtual links [3]: one virtual link has the
address of the tunnel entry point as the Care-of Address of the
Mobile Router and the tunnel exit point as the address of the
Home Agent; the other virtual link has as tunnel entry point the
Home Agent address and as tunnel exit point the Care-of Address
of the Mobile Router. Both addresses are unicast addresses. All
IPv6 traffic to and from the mobile network is sent through this
bi-directional tunnel.
A Mobile Router MAY limit the number of mobile routers that attach to
its mobile network (the number of levels in the nested aggregation)
by means of setting the Tunnel Encapsulation Limit field of the
Tunnel Encapsulation option.
A Mobile Router uses the Tunnel Hop Limit that is normally assigned
to routers (not to hosts). Please refer to [3] for more details.
Devarapalli, et al. [Page 15]
Internet Draft NEMO Basic Support December 2003
5.6. Neighbor Discovery for Mobile Router
When the Mobile Router is at home, it MAY be configured to send
Router Advertisements and reply to Router Solicitations on the
interface attached to the home link. The value of the Router
Lifetime field MUST be set to zero to prevent other nodes from
configuring the Mobile Router as the default router.
A Mobile Router SHOULD NOT send unsolicited Router Advertisements
and SHOULD NOT reply to Router Solicitations on any egress interface
when that interface is attached to a visited link. However, the
Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor
Solicitations received on the egress interface, for topologically
correct addresses.
A router typically ignores router advertisements sent by other
routers on a link. However, a Mobile Router MUST NOT ignore Router
Advertisements received on the egress interface. The received Router
Advertisements MAY be used for address configuration, default router
selection or movement detection.
5.7. Multicast Groups for Mobile Router
When at home, the Mobile Router joins the multicast group All Routers
Address with scopes '1' interface-local (on the home-advertising
interface) and '2' link-local on any of its egress interfaces. When
in a visited network, the Mobile Router MUST NOT join the above
multicast groups on the corresponding interface.
5.8. Returning Home
When the Mobile Router realizes it has returned to its home link
through movement detection mechanisms, it MUST de-register with
its Home Agent. The Mobile Router MUST implement and follow the
returning home procedures defined for a mobile node in [1]. In
addition, the Mobile Router MAY start behaving as a router on its
egress interface. In particular,
- The Mobile Router MAY send router advertisements on its egress
interfaces. But the router lifetime SHOULD be set to 0, so that
hosts on the home link do not pick the Mobile Router as the
default router.
- The Mobile Router MAY join the All Routers multicast group on the
home link.
Devarapalli, et al. [Page 16]
Internet Draft NEMO Basic Support December 2003
- The Mobile Router MAY send routing protocol messages on its
egress interface if it is configured to run a dynamic routing
protocol.
Devarapalli, et al. [Page 17]
Internet Draft NEMO Basic Support December 2003
6. Home Agent Operation
In order for a Mobile Router to operate correctly, the Home Agent
MUST satisfy all the requirements listed in Section 8.4 of [1]. The
Home Agent MUST implement both modes described in Section 5.2 of this
document.
6.1. Data Structures
6.1.1. Binding Cache
The Home Agent maintains Binding Cache Entries for each Mobile Router
that is currently registered with the Home Agent. The Binding Cache
is a conceptual data structure described in detail in [1].
The Home Agent might need to store the Mobile Network Prefixes
associated with a Mobile Router in the corresponding Binding Cache
Entry. This is required if the Binding Update (that created the
Binding Cache Entry) contained explicit prefix information. This
information can be used later to cleanup routes installed in explicit
mode, when the Binding Cache Entry is removed, and to maintain the
routing table, for instance should the routes be manually removed.
The Home Agent also stores the status of the Mobile Router Flag (R)
in the Binding Cache entry.
6.1.2. Prefix Table
The Home Agent SHOULD be able to prevent a Mobile Router from
claiming Mobile Network Prefixes that belong to another Mobile
Router. The Home Agent can prevent such attacks if it maintains a
Prefix Table and verifies the Prefix Information provided by the
Mobile Router against the entries in the Prefix Table. The Prefix
Table SHOULD be used by the Home Agent when it processes a Binding
Update in explicit mode. It is not required when a dynamic routing
protocol is run between the Mobile Router and the Home Agent.
Each entry in the Prefix Table conceptually contains the following
fields:
- The Home Address of the Mobile Router. This field is used as the
key for searching the pre-configured prefix table.
- The Mobile Network Prefix of the Mobile Router associated with
the Home Address.
Devarapalli, et al. [Page 18]
Internet Draft NEMO Basic Support December 2003
6.2. Mobile Network Prefix Registration
The Home Agent processes the Binding Update as described in Section
10.3.1 of the Mobile IPv6 specification [1]. This section describes
the processing of the Binding Update if the Mobile Router (R) flag is
set. The Home Agent performs the following check in addition.
- The Home Registration (H) flag MUST be set. If not, the
Home Agent MUST reject the Binding Update and send a Binding
Acknowledgement with status set to 140. Note: The basic support
does not allow sending Binding Update for a Mobile Network Prefix
to correspondent nodes (for route optimization).
- Mobile IPv6 specification [1] requires that the Home Address in
the Binding Update should be configured from a prefix advertised
on the home link. Otherwise the Binding Update is rejected
with status value 132 [1]. This specification relaxes this
requirement so that the Home Agent rejects the Binding Update
only if Home Address does not belong to the prefix that the Home
Agent is configured to serve.
If the Home Agent does not reject the Binding Update as described
above, then it retrieves the Mobile Network Prefix information as
described below.
- If a Mobile Network Prefix Option is present in the Binding
Update, the prefix information for the Mobile Network Prefix is
retrieved from the Mobile Network Prefix field and the Prefix
Length field of the option. If the Binding Update contains more
than one option, the Home Agent MUST set up forwarding for all of
the Mobile Network Prefixes. If the Home Agent fails to setup
forwarding to all the prefixes listed in the Binding Update, then
it MUST NOT forward traffic to any of the prefixes, reject the
Binding Update and send a Binding Acknowledgement with status set
to 141 (Invalid Prefix).
If the Home Agent verifies the prefix information with the Prefix
Table and the check fails, the Home Agent MUST discard the
Binding Update and send a Binding Acknowldegement with status set
to 142 (Not Authorized for Prefix).
- If there are is no option in the Binding Update carying
prefix information, the Home Agent uses manual pre-configured
information to determine the prefixes assigned to the Mobile
Router and for setting up forwarding for the mobile network. If
there is no information that the Home Agent can use, it MUST
reject the Binding Update and send a Binding Acknowledgement with
status set to 143 (Forwarding Setup failed).
Devarapalli, et al. [Page 19]
Internet Draft NEMO Basic Support December 2003
If the Lifetime specified in the Binding Update is zero or the
specified Care-of address matches the Home Address in the Binding
Update, then this is a request to delete the cached binding for
the home address and specified Mobile Network Prefixes. The
Binding Update is processed according to the procedure described in
Section 6.7.
If all checks are passed, the Home Agent creates a binding cache
entry for Mobile Router's Home Address, or updates the binding cache
entry if it already exists. Otherwise, the Home Agent MUST NOT
register the binding of the Mobile Router's Home Address.
The Home Agent defends the Mobile Router's Home Address through Proxy
Neighbor Discovery by multicasting onto the home link a Neighbor
Advertisement message on behalf of the mobile router. All fields in
the Proxy Neighbor Advertisement message should be set in the same
way they would be set by the Mobile Router itself if sending this
Neighbor Advertisement while at home, as described in [7], with the
exception that the Router (R) bit in the Advertisement MUST be set if
the Mobile Router (R) flag has been set in the Binding Update.
The Home Agent also creates a bi-directional tunnel to the mobile
router for the requested Mobile Network Prefix, or update an existing
bi-directional tunnel as described in Section 6.4.
6.3. Advertising Mobile Network Reachability
In order to be able to receive packets meant for the mobile network,
the Home Agent advertises reachability to the mobile network. If the
Home Link is configured with a prefix that is an aggregation and if
the Mobile Network Prefix is aggregated under that prefix, then the
routing updates advertising reachability to the mobile network are
sent only on the Home Link. If the Home Agent is the only default
router on the Home Link, routes to the Mobile Network Prefix get
aggregated naturally under the Home Agent and the Home Agent does not
have to do anything special.
If the Home Agent receives routing updates through a dynamic routing
protocol from the Mobile Router, those routes are propagated by
the routing protocol running on the Home Agent on the relevant
interfaces.
6.4. Establishment of Bi-directional Tunnel
The implementation of the bi-directional tunnels and the mechanism
of attaching them to the IP stack are outside the scope of this
Devarapalli, et al. [Page 20]
Internet Draft NEMO Basic Support December 2003
specification. However, all implementations MUST be capable of the
following operations.
- The Home Agent can tunnel packets meant for the mobile network
prefix to the Mobile Router's current location, the Care-of
Address of the Mobile Router.
- The Home Agent can accept packets tunneled by the Mobile Router
with source address of the outer IPv6 header set to the Care-of
Address of the Mobile Router.
6.5. Forwarding Packets
When the Home Agent receives a data packet destined for the mobile
network, it MUST forward the packet to the Mobile Router through the
bi-directional tunnel. The Home Agent either uses only the routing
table, only the Binding Cache or a combination of routing table
and Binding Cache to route packets to the mobile network. This is
implementation specific. Two examples are shown below.
1. The Home Agent maintains a route to the Mobile Network Prefix
with the next hop set to the Mobile Router's Home Address. When
the Home Agent tries to forward the packet to the next hop, it
finds a binding cache entry for the home address. Then the Home
Agent extracts the Mobile Router's Care-of address and tunnels
the packet to the Care-of address.
2. The Home Agent maintains a route to the Mobile Network Prefix
with the outgoing interface set to the bi-directional tunnel
interface between the Home Agent and the Mobile Router. For
this purpose, the Home Agent MUST treat this tunnel as a tunnel
interface. When the packets are forwarded through the tunnel
interface, they get encapsulated automatically with the source
address and destination address in the outer IPv6 header set to
the Home Agent's address and the Mobile Router's Care-of address,
respectively.
6.6. Sending Binding Acknowledgements
A Home Agent serving a Mobile Router sends Binding Acknowledgements
according to the same rules it uses for sending Binding
Acknowledgements to Mobile Hosts [1], with the following
enhancements.
The Home Agent sets the status code in the Binding Acknowledgement
to '0' (Binding Update accepted) in order to indicate to the Mobile
Router that it successfully processed the Binding Update. It also
Devarapalli, et al. [Page 21]
Internet Draft NEMO Basic Support December 2003
sets the Mobile Router flag (R) to indicate to the Mobile Router that
it has setup forwarding for the mobile network.
If the Home Agent is configured not to support mobile routers, it
sets the status code in the Binding Acknowledgement to '140' (Mobile
Router Operation not permitted).
If one or more prefixes received in the Binding Update are invalid
and the Home Agent cannot setup forwarding for the prefixes, the Home
Agent sets the status code in the Binding Acknowledgement to '141'
(Invalid Prefix) in order to indicate this to the Mobile Router.
If the Mobile Router is not authorized to use this Home Address to
forward packets for one or more prefixes that are present in the
Binding Update, the Home Agent sets the status code in the Binding
Acknowledgement to '142' (Not Authorized for Prefix) in order to
indicate this.
The Home Agent sets the status code to 143 (Forwarding Setup
failed) if it is unable to determine the information needed to setup
forwarding for the mobile network. This is used in the Implicit mode
where the Mobile Router does not include any prefix information in
the Binding Update.
6.7. Mobile Network Prefix De-Registration
The Mobile Router de-registers with the Home Agent by sending a
Binding Update with the lifetime set to zero. When the Home Agent
successfully processes the de-registration BU, it deletes the Binding
Cache Entry for the Mobile Router's Home Address and stops proxying
the Home Address. This is described in detail in the Mobile IPv6
specification [1].
In addition, the Home Agent also removes the bi-directional tunnel
and stops forwarding packets to the mobile network. The Home Agent
should keep all necessary information to clean up whichever routes it
installed, whether they come from implicit or explicit source.
Devarapalli, et al. [Page 22]
Internet Draft NEMO Basic Support December 2003
7. Modifications to Dynamic Home Agent Discovery
This document extends the Dynamic Home Agent Discovery mechanism
defined in [1], so that Mobile Routers attempt registration only with
Home Agents that support Mobile Routers.
7.1. Modified Dynamic Home Agent Discovery Request
A new flag (R) (Support for Mobile Routers) is introduced in the
Dynamic Home Agent Discovery Reguest message defined in [1]. The
Mobile Router sets this flag to indicate that it wants to discover
Home Agents that support Mobile Routers.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Support Flag (R)
A 1 bit flag which when set indicates that the Mobile Router
wants to discover Home Agents that support Mobile Routers.
For a description of the other fields in the message, see [1].
7.2. Modified Dynamic Home Agent Discovery Reply
A new flag (R) (Support for Mobile Routers) is introduced in the
Dynamic Home Agent Discovery Reply message defined in [1]. If a Home
Agent receives a Dynamic Home Agent Discovery request message with
the Mobile Router Support flag set, it MUST reply with a list of Home
Agents that support Mobile Routers. The Mobile Router Support flag
MUST be set if there is atleast one Home Agent that supports Mobile
Routers. If none of the Home Agents support Mobile Routers, the Home
Agent MAY reply with a list of Home Agents that support just Mobile
IPv6 Mobile Nodes. In this case, the Mobile Router Support flag MUST
be set to 0.
Devarapalli, et al. [Page 23]
Internet Draft NEMO Basic Support December 2003
The modified message format is as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Home Agent Addresses .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Support Flag (R)
A 1 bit flag which when set indicates that the Home Agents
listed in this message support Mobile Routers.
For a description of the other fields in the message, see [1].
7.3. Modified Home Agent Information Option
A new flag (R) (Support for Mobile Routers) is introduced in the Home
Agent Information Option defined in [1]. If a Home Agent supports
Mobile Routers, it SHOULD set the flag.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Support Flag (R)
A 1 bit flag which when set indicates that the Home Agent
supports Mobile Routers.
For a description of the other fields in the message, see [1].
Devarapalli, et al. [Page 24]
Internet Draft NEMO Basic Support December 2003
8. Support for Dynamic Routing Protocols
In the solution described so far, forwarding to the mobile network
at the Home Agent is set up when the Home Agent receives a Binding
Update from the Mobile Router. An alternative to this is for the
Home Agent and the Mobile Router to run an intra-domain routing
protocol like RIPng [11] and OSPF [12] through the bi-directional
tunnel. The Mobile Router can continue running the same routing
protocol that it was running when it was attached to the home link.
This feature is very useful when the mobile network is large with
multiple subnets containing different IPv6 prefixes. Routing changes
in the mobile network are propagated to the Home Agent quickly.
Routing changes in the home link are also propogated to the Mobile
Router very quickly.
When the Mobile Router is attached to the home link, it runs a
routing protocol by sending routing updates through its egress
interface. When the mobile router moves and attaches to a visited
network, it MUST stop sending routing updates on the interface with
which it attaches to the visited link. This is very important so
that IPv6 prefixes specific to the mobile network do not leak into
the visited network. The Mobile Router then starts sending routing
protocol messages through the bi-directional tunnel towards the Home
Agent. Most routing protocols use link local addresses as source
addresses for the routing information messages. The Mobile Router is
allowed to use link local addresses for the inner IPv6 header of an
encapsulated packet. But these messages after decapsulation MUST NOT
be forwarded to another link by either the Mobile Router or the Home
Agent.
When the Home Agent receives the encapsulated routing protocol
message, it processes the inner packets and updates its routing table
accordingly. The next hop information in these routing entries is
filled with the Mobile Router's link local address with the outgoing
interface set to the bi-directional tunnel.
Similary, the Home Agent also sends routing updates through the
bi-directional tunnel to the Mobile Router. The Mobile Router
processes these routing protocol messages and updates its routing
table. For all routes advertised by the Home Agent, the Mobile
Router sets the outgoing interface to the bi-directional tunnel to
the Home Agent.
When the Mobile Router and the Home Agent exchange routes through
a dynamic routing protocol, the Mobile Router should be careful in
including the same Mobile Network Prefixes in the Binding Update to
the Home Agent and in the routing protocol updates. The Home Agent
depending on its configuration might not add routes based on the
Devarapalli, et al. [Page 25]
Internet Draft NEMO Basic Support December 2003
prefix information in the Binding Updates at all, and might use only
the routing protocol updates. Moreover, including the same prefix
information in both the Binding Update and the routing protocol
update is redundant.
Since the routing protocol messages from the Home Agent to the Mobile
Router could potentially contain information about the internal
routing structure of the home network, these messages require
authentications and confidentiality protection. Confidentialy
protection using IPsec ESP [4] MUST be supported and SHOULD be
used. For protecting routing protocol messages using ESP, the
bi-directional tunnel between the Mobile Router and the Home
Agent should be treated as the outgoing interface, with link local
addresses as source and destination addresses for the messages.
IPsec ESP with a non-null encryption algorithm should be used
in transport mode for protecting the routing protocol messages.
Examples of SPD entries for protecting OSPFv3 messages are described
in [13].
Devarapalli, et al. [Page 26]
Internet Draft NEMO Basic Support December 2003
9. Security Considerations
All signaling messages between the Mobile Router and the Home Agent
MUST be authenticated by IPsec [5]. The use of IPsec to protect
Mobile IPv6 signaling messages is described in detail in the HA-MN
IPsec specification [2]. The signaling messages described in this
document just extend Mobile IPv6 messages and do not require any
changes to what is described in the HA-MN IPsec specification.
The Mobile Router has to perform ingress filtering on packets
received from the mobile network to ensure that nodes in the Mobile
Network do not use the bi-directional tunnel to launch IP spoofing
attacks. In particular the Mobile Router SHOULD check that the IP
source address in the packets received from the nodes in the Mobile
Network belongs to the Mobile Network Prefix and is not the same as
one of the addresses used by the Mobile Router. In case the Mobile
Router receives a IP-in-IP tunneled packet from a node in the Mobile
Network and the Mobile Router has to forward the decapsulated packet,
it SHOULD perform the above mentioned checks on the source address of
the inner packet.
The Home Agent has to verify that packets received through the
bi-directional tunnel belong to the mobile network. This check is
necessary in order to prevent nodes from using the Home Agent to
launch attacks that would have otherwise been prevented by ingress
filtering. The source address of the outer IPv6 header MUST be set
to the Mobile Router's current Care-of address. The source address
of the inner IPv6 header MUST be a topologically correct address with
respect to the IPv6 prefixes used in the mobile network.
When the Mobile Router is running a dynamic routing protocol as
described in Section 8, it injects routing update messages into the
Home Link. The Home Agent MUST verify that the Mobile Router is
allowed to send routing updates before processing the messages and
propagating the routing information.
Please refer to the Mobile IPv6 specification [1] for security
considerations when the Mobile Router operates as a Mobile Host.
Devarapalli, et al. [Page 27]
Internet Draft NEMO Basic Support December 2003
10. IANA Considerations
This document defines a new Mobility Header Option, the Mobile
Network Prefix Option. This option is described in Section 4.3. The
type value for this option needs to be assigned from the same space
used by the mobility options defined in [1].
This document also defines the following new Binding Acknowledgement
status values. These status values are defined in Section 4.2
and need to be assigned from the same space used for Binding
Acknowledgement status values in [1].
- Mobile Router Operation not permitted
- Invalid Prefix
- Not Authorized for Prefix
- Forwarding Setup failed
11. Contributors
We would like to acknowledge Ludovic Bellier, Claude Castelluccia,
Thierry Ernst, Miguel Catalina-Gallego, Christophe Janneteau, T.J.
Kniveton, Hong-Yon Lach, Jari T. Malinen, Koshiro Mitsuya, Alexis
Olivereau, Charles E. Perkins and Keisuke Uehara, for their work on
earlier proposals for Network Mobility. This document inherits a lot
of ideas from these proposals.
12. Acknowledgements
We thank all members of the NEMO Working Group, and of the preceding
MONET BoF for fruitful discussions on the mailing list and at IETF
meetings.
Kent Leung, Marco Molteni and Patrick Wetterwald for their work on
Network Mobility for IPv4 and IPv6.
Tim Leinmueller for many insightful remarks and for Section 7.
Jari Arkko, James Kempf and Chan-Wah Ng for their thorough review and
comments.
Devarapalli, et al. [Page 28]
Internet Draft NEMO Basic Support December 2003
References
[1] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6.
Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt (work in
progress). June 2003.
[2] J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to Protect
Mobile IPv6 Signaling between Mobile Nodes and Home Agents.
Internet Draft, IETF. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt
(work in progress). June 2003.
[3] A. Conta and S. Deering. Generic Packet Tunneling in IPv6
Specification. RFC 2473, IETF. December 1998.
[4] S. Kent and R. Atkinson. IP Encapsulating Security Payload
(ESP). RFC 2402, IETF. November 1998.
[5] S. Kent and R. Atkinson. Security Architecture for the Internet
Protocol. RFC 2401, IETF. November 1998.
[6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 2460, IETF. December 1998.
[7] T. Narten, E. Nordmark and W. Simpson. Neighbour Discovery for
IP Version 6 (IPv6). RFC 2461, IETF. December 1998.
References
[8] J. Manner and M. Kojo. Mobility Related Terminology. Internet
Draft, IETF. draft-ietf-seamoby-mobility-terminology-05.txt
(work in progress). November 2003.
[9] T. Ernst and H.-Y. Lach. Network Mobility Support Terminology.
Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt (work
in progress). May 2003.
[10] T. Ernst. Network Mobility Support Goals and Requirements.
Internet Draft, IETF. draft-ietf-nemo-requirements-01.txt (work
in progress). May 2003.
[11] G. Malkin and R. Minnear. RIPng for IPv6. RFC 2080, IETF.
January 1997.
[12] R. Coltun, D. Ferguson and J. Moy. OSPF for IPv6. RFC 2470,
IETF. December 1999.
Devarapalli, et al. [Page 29]
Internet Draft NEMO Basic Support December 2003
[13] M. Gupta and N. Melam. Authentication/Confidentiality for
OSPFv3. Internet Draft, IETF. draft-ietf-ospf-ospfv3-auth-04.txt
(work in progress). December 2003.
[14] T. Ernst. Network Mobility Support in IPv6. PhD Thesis,
University Joseph Fourier, Grenoble, France. October 2001.
[15] T. Ernst, K, Mitsuya and K. Uehara. Network Mobility from the
InternetCAR perspective. Journal of Interconnection Networks
(JOIN), Vol. 4, No. 3. September 2003.
Devarapalli, et al. [Page 30]
Internet Draft NEMO Basic Support December 2003
A. Examples of NEMO Basic Support Operation
This section tries to illustrate the NEMO protocol using a Mobile
Router and a Mobile Node belonging to different administrative
domains. The Mobile Router's mobile network consists of a Local
Fixed Node (LFN) and a Local Fixed Router (LFR) [9]. The LFR has
an access link to which other Mobile Nodes or Mobile Routers could
attach to.
Figure 1 depicts the scenario where both the Mobile Router and the
Mobile Node are at home.
+----+ +-------+
| MN | | HA_MN |
+--+-+ 1:: +---+---+
2+-------------+3
|
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ +-------------------+ +-------+
4:: |
|
2+-------------+3
+--+-+ +---+---+
| MR | | HA_MR |
+--+-+ +-------+
5:: |1
----------
2| |3
+--+-+ +--+-+
| LFN| | LFR|
+--+-+ +--+-+
6:: |1
----------
Figure 1: Mobile Router and Mobile Node at home.
Devarapalli, et al. [Page 31]
Internet Draft NEMO Basic Support December 2003
The Mobile Router then moves away from the home link and attaches to
a visited link. This is shown in Figure 2. The Mobile Router sends
a Binding Update to HA_MR when it attaches to a visited link and
configures a Care-of Addres. HA_MR creates a binding cache entry for
the Mobile Router's Home Address and also sets up forwarding for the
prefixes on the mobile network.
+----+ +-------+
| MN | | HA_MN |
+--+-+ 1:: +---+---+
2+-------------+3
|
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ ++------------------+ +-------+
| 7:: 4:: | 4::2->7::2
| |
2+ +3
+--+-+ +---+---+
| MR | | HA_MR | 4::2->7::2
+--+-+ +-------+ 5::/prefixlen -> forward
5:: |1 to MR
---------- 6::/prefixlen -> forward
2| |3 to MR
+--+-+ +--+-+
| LFN| | LFR|
+--+-+ +--+-+
6:: |1
----------
Figure 2: Mobile Router on a Visited Link.
Devarapalli, et al. [Page 32]
Internet Draft NEMO Basic Support December 2003
Figure 3 shows the Mobile Node moving away from its home link and
attaching to the Mobile Router. The Mobile Node configures a Care-of
Address from the prefix advertised on the mobile network and sends a
Binding Update to its Home Agent (HA_MN) and its Correspondent Node
(CN_MN). Both HA_MN and CN_MN create binding cache entries for the
Mobile Node's Home Address.
+-------+
| HA_MN | 1::2->6::2
1:: +---+---+
---------|3
|
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ ++------------------+ +-------+
1::2->6::2 | 7:: 4:: | 4::2->7::2
| |
2+ +3
+--+-+ +---+---+
| MR | | HA_MR | 4::2->7::2
+--+-+ +-------+ 5::/prefixlen -> forward
5:: |1 to MR
---------- 6::/prefixlen -> forward
2| |3 to MR
+--+-+ +--+-+
| LFN| | LFR|
+--+-+ +--+-+
6:: |1
--------+-
|2
+--+-+
| MN |
+----+
Figure 3: Mobile Node attached to Mobile
Router on a Visited Link
Devarapalli, et al. [Page 33]
Internet Draft NEMO Basic Support December 2003
B. Changes from Previous Version
The following changes have been made to this document from version 01
- Dynamic Home Agent Discovery was modified to return only Home
Agents that support Mobile Routers. A new section was added to
the specification. (Issue 16).
- A new flag (R) was introduced in the Binding Acknowledgement for
the Home Agent to indicate to the Mobile Router that it processed
the Mobile Router flag (R) in the corresponding Binding Update.
(Issue 16).
- Relaxed a Mobile IPv6 requirement which said the Home Agent MUST
drop a Binding Update if the home address is not configured from
the home prefix. NEMO Home Agent drops the Binding Update only
if the Home Address does not belong to the prefix that the Home
Agent is currently configured to serve. (Issue 19)
- Explicit Prefix Length mode is removed. (Issue 20).
- Text related to Mobile Router performing ingress filtering was
added to the Security Considerations section to prevent some
threats due to tunneling. (Issue 23).
- Added a new section on Mobile Router returning home. (Issue 25).
- Clarified that the Prefix Table is not required when a dynamic
routing protocol is being run between the Mobile Router and the
Home Agent. (Issue 26).
- Clarified the use of Prefix Table. (Issue 25).
- Clarified Mobile Router sending router advertisements on its
egress interface when at home. (Issue 21 and 26).
- Clarified implementation requirements with respect to the Mobile
IPv6 specification. (Issue 27).
- Modified/added network mobility terms so that the NEMO
terminology document becomes an informative reference. (Issue
28).
- Provided more information for creating SPD entries for protecting
routing protocol messages. (Issue 29).
Devarapalli, et al. [Page 34]
Internet Draft NEMO Basic Support December 2003
Authors Addresses
Vijay Devarapalli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Email: vijay.devarapalli@nokia.com
Ryuji Wakikawa
Keio University and WIDE
5322 Endo Fujisawa Kanagawa
252-8520 Japan
Email: ryuji@sfc.wide.ad.jp
Alexandru Petrescu
Motorola Labs
Parc les Algorithmes Saint Aubin
Gif-sur-Yvette 91193
France
Email: Alexandru.Petrescu@motorola.com
Pascal Thubert
Cisco Systems Technology Center
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
France
Email: pthubert@cisco.com
Devarapalli, et al. [Page 35]
Internet Draft NEMO Basic Support December 2003
Intellectual Property Statement
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However,
this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
Devarapalli, et al. [Page 36]
Internet Draft NEMO Basic Support December 2003
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Devarapalli, et al. [Page 37]