Request for Comments: 3963 Nokia
Category: Standards Track R. Wakikawa
Keio University
A. Petrescu
Motorola
P. Thubert
Cisco Systems
January 2005
Network Mobility (NEMO) Basic Support Protocol
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the Network Mobility (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 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 so that network mobility is
transparent to the nodes inside the Mobile Network.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the NEMO Protocol. . . . . . . . . . . . . . . . 4
4. Message Formats. . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Binding Update. . . . . . . . . . . . . . . . . . . . . 7
4.2. Binding Acknowledgement . . . . . . . . . . . . . . . . 7
4.3. Mobile Network Prefix Option. . . . . . . . . . . . . . 8
5. Mobile Router Operation. . . . . . . . . . . . . . . . . . . 9
5.1. Data Structures . . . . . . . . . . . . . . . . . . . . 10
5.2. Sending Binding Updates . . . . . . . . . . . . . . . . 10
5.3. Receiving Binding Acknowledgements. . . . . . . . . . . 11
5.4. Error Processing . . . . . . . . . . . . . . . . . . . 12
5.4.1. Implicit Mode. . . . . . . . . . . . . . . . . . 12
5.4.2. Explicit Mode. . . . . . . . . . . . . . . . . . 12
5.5. Establishment of Bi-directional Tunnel . . . . . . . . 13
5.6. Neighbor Discovery for Mobile Router . . . . . . . . . 13
5.7. Multicast Groups for Mobile Router . . . . . . . . . . 14
5.8. Returning Home . . . . . . . . . . . . . . . . . . . . 14
6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 15
6.1. Data Structures . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Binding Cache. . . . . . . . . . . . . . . . . . 15
6.1.2. Prefix Table . . . . . . . . . . . . . . . . . . 15
6.2. Mobile Network Prefix Registration . . . . . . . . . . 16
6.3. Advertising Mobile Network Reachability . . . . . . . . 17
6.4. Establishment of Bi-directional Tunnel . . . . . . . . 18
6.5. Forwarding Packets . . . . . . . . . . . . . . . . . . 18
6.6. Sending Binding Acknowledgements . . . . . . . . . . . 19
6.7. Mobile Network Prefix De-Registration . . . . . . . . . 19
7. Modifications to Dynamic Home Agent Address Discovery. . . . 20
7.1. Modified Dynamic Home Agent Discovery Request . . . . . 20
7.2. Modified Dynamic Home Agent Discovery Address Request . 20
7.3. Modified Home Agent Information Option . . . . . . . . 21
8. Support for Dynamic Routing Protocols. . . . . . . . . . . . 22
9. Security Considerations. . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 24
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
A. Examples of NEMO Basic Support Operation. . . . . . . . . 27
B. Running Link State Routing Protocol with NEMO Basic
Support . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.1. Tunnel Interface Considerations. . . . . . . . . . . 30
B.2. OSPF Area Considerations . . . . . . . . . . . . . . 30
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 33
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. The
solution described here satisfies the goals and requirements
identified in [11] for network mobility.
The NEMO Basic Support ensures session continuity 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 it 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
routing capability routing between its point of attachment (Care-of
Address) and a subnet that moves with the Mobile Router.
The solution described in this document proposes 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 [10] 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
note that this might introduce significant overhead on the data
packets as each level of nesting introduces another IPv6 header
encapsulation.
This document does not discuss multihoming for Mobile Routers.
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 BCP 14, RFC 2119 [7].
Network Mobility - related terminology is defined in [9] and [10].
This document in addition defines the following terms.
Mobile Network Prefix
An IPv6 prefix delegated to a Mobile Router and advertised in
the Mobile Network. More than one Mobile Network Prefix could
be advertised in a Mobile Network.
Prefix Table
A list of Mobile Network Prefixes indexed by the Home Address
of a Mobile Router. The Home Agent manages and uses Prefix
Table to determine which Mobile Network Prefixes belong to a
particular Mobile Router.
3. Overview of the NEMO Protocol
A Mobile Network is a network segment or subnet that can move and
attach to arbitrary points in the routing infrastructure. A Mobile
Network can only be accessed via specific gateways called Mobile
Routers that manage its movement. Mobile Networks have at least 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
bi-directional tunnel to a Home Agent that advertises an aggregation
of Mobile Networks to the infrastructure. The Mobile Router is also
the default gateway for the Mobile Network.
A Mobile Network can also comprise of multiple and nested subnets. A
router without mobility support 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 may
form a graph. In particular, with Basic NEMO Support, each Mobile
Router is attached to another Mobile Network by a single interface.
If loops are avoided, the graph is a tree.
A Mobile Router has a unique Home Address through which it is
reachable when it is registered with its Home Agent. The Home
Address is configured from a prefix aggregated and advertised by its
Home Agent. The prefix could be either 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 as a Mobile Router. It acts as a Mobile Host as defined in [1]
for sessions it originates and provides connectivity to the Mobile
Network. 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
cache entry binding the Mobile Router’s Home Address to its Care-of
Address at the current point of attachment.
If the Mobile Router seeks 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 by 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 for
carrying prefix information 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 of 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 would
already know which prefixes belong to a Mobile Router by an alternate
mechanism such as static configuration. 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 Mobile Router Flag (R) set.
The Home Agent acknowledges the Binding Update by sending a Binding
Acknowledgement to the Mobile Router. A positive acknowledgement
with the Mobile Router Flag (R) set means that the Home Agent has set
up forwarding for the Mobile Network. Once the binding process
finishes, a bi-directional tunnel is established between the Home
Agent and the Mobile Router. The tunnel end points are the 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 Correspondent Node sends a data packet to a node in the Mobile
Network, the packet is routed to the Home Agent that currently has
the binding for the Mobile Router. The Mobile Router’s network
prefix would be aggregated at the Home Agent, which would advertise
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 the 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. Before
decapsulating the tunneled packet, the Mobile Router has to check
whether the Source address on the outer IPv6 header is the Home
Agent’s address. This check is not necessary if the packet is
protected by IPsec in tunnel mode. The Mobile Router also has to
make sure that the destination address on the inner IPv6 header
belongs to a prefix used in the Mobile Network before forwarding the
packet to the Mobile Network. If it does not, the Mobile Router
should drop the packet.
The Mobile Network could include nodes that do not support mobility
and nodes that do. A node in the Mobile Network can also be a fixed
or a Mobile Router. The protocol 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.
The Mobile Router and the Home Agent can run a routing protocol
through the bi-directional tunnel. In this case, the Mobile Router
need not include prefix information in the Binding Update. Instead,
the Home Agent uses the routing protocol updates to set up forwarding
for the Mobile Network. When the routing protocol is running, the
bi-directional tunnel must be treated as a tunnel interface. The
tunnel interface is included in the list of interfaces on which
routing protocol is active. The Mobile Router should be configured
not to send any routing protocol messages on its egress interface
when it is away from the home link and connected to a visited link.
Finally, the Home Agent may be configured with static routes to the
Mobile Network Prefix via the Mobile Router’s Home Address. In this
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 additional signalling in the form of routing updates
in the home network. The drawback is that the routes are present
even if the related Mobile Routers are not reachable (at home or
bound) at a given point of time.
4. Message Formats
4.1. Binding Update
A new flag (R) is included in the Binding Update to indicate to the
Home Agent whether 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|M|R| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
behaving as a Mobile Node, and it MUST NOT forward packets
destined for the Mobile Network to the Mobile Router.
Mobility Options
A variable length field that can include zero or more mobility
options. This document defines a new mobility option in
addition to what is defined in [1].
For descriptions 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 that 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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Flag (R)
The Mobile Router Flag is set to indicate that the Home Agent
that 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 descriptions of the other fields in the message, see [1].
This document also introduces the following new Binding
Acknowledgement status values. The values shown below are decimal
values.
140 Mobile Router Operation not permitted
141 Invalid Prefix
142 Not Authorized for Prefix
143 Forwarding Setup failed (prefixes missing)
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 the prefix information for the Mobile Network to the Home
Agent. There could be multiple Mobile Network Prefix Options 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |