Internet DRAFT - draft-boot-autoconf-nemo4manet
draft-boot-autoconf-nemo4manet
Ad-Hoc Network Autoconfiguration T. Boot
(Autoconf) Infinity Networks
Internet-Draft November 2, 2007
Expires: May 5, 2008
NEMO for Mobile Ad-hoc Networks
draft-boot-autoconf-nemo4manet-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Mobile Ad-hoc Networks could be attached to a fixed infrastructure
network, like the Internet. This document specifies a mechanism for
Border Router discovery and utilization. It provides facilities for
choosing the best Border Router, configuring IP addresses needed for
using the selected Border Router and providing a path to the selected
Border Router. Seamless transition to alternate Border Routers is
provided. When mobile nodes in the MANET make use of Mobile IP or
NEMO (NEtwork MObility), session continuity is provided. NEMO for
Boot Expires May 5, 2008 [Page 1]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
MANET is based on NEMO, which utilizes IPv6 mobility support. The
NEMO basic support protocol can easily be enhanced to support IPv4,
which provides IPv4 support by NEMO for MANET.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol overview and functioning . . . . . . . . . . . . . . 6
3.1. Border Router Discovery Protocol (BRDP) . . . . . . . . . 6
3.2. BRDP-based Autoconf . . . . . . . . . . . . . . . . . . . 6
3.3. NEMO for MANET . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Session continuity . . . . . . . . . . . . . . . . . . . . 7
3.5. Leech tunneling . . . . . . . . . . . . . . . . . . . . . 7
3.6. Anonymity and traffic flow confidentiality . . . . . . . . 7
4. Border Router Discovery Protocol . . . . . . . . . . . . . . . 8
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Border Router Information Option (BRIO) . . . . . . . . . 8
4.2.1. BRIO Base option . . . . . . . . . . . . . . . . . . . 8
4.2.2. BRIO suboptions . . . . . . . . . . . . . . . . . . . 11
4.3. BRDP processing . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. BRDP message reception and BRIO cache maintenance . . 13
4.3.2. Generating and sending BRDP messages . . . . . . . . . 14
4.3.3. BRDP loop prevention . . . . . . . . . . . . . . . . . 16
5. BRDP-based Autoconf . . . . . . . . . . . . . . . . . . . . . 18
5.1. Border Router selection . . . . . . . . . . . . . . . . . 18
5.2. MANET Address generation . . . . . . . . . . . . . . . . . 19
6. NEMO for MANET . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Need for enforcing usage of selected Border Router . . . . 21
6.2. Using NEMO as tunneling method . . . . . . . . . . . . . . 21
6.3. Header compression . . . . . . . . . . . . . . . . . . . . 22
7. Session continuity . . . . . . . . . . . . . . . . . . . . . . 23
8. Support for IPv4 . . . . . . . . . . . . . . . . . . . . . . . 24
9. Leech tunneling . . . . . . . . . . . . . . . . . . . . . . . 25
10. BRDP-based routing . . . . . . . . . . . . . . . . . . . . . . 26
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28
Boot Expires May 5, 2008 [Page 2]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
12. Security Considerations . . . . . . . . . . . . . . . . . . . 28
12.1. Anonymity and traffic flow confidentiality . . . . . . . . 28
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
14.1. Normative reference . . . . . . . . . . . . . . . . . . . 29
14.2. Informative Reference . . . . . . . . . . . . . . . . . . 30
Appendix A. Change Log From Previous Version . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 33
Boot Expires May 5, 2008 [Page 3]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
1. Introduction
The Autoconf workgroup is chartered for standardizing mechanisms to
be used by ad hoc nodes for configuring unique local and/or globally
routable IPv6 addresses. Issues and requirements related to prefix
and/or address providing entities shall be addressed. The reader
should be familiar with "Mobile Ad hoc Network Architecture" [1] and
"Address Autoconfiguration for MANET: Terminology and Problem
Statement" [2].
This document describes a complete solution for Autoconf. The
solution makes use of as many existing protocols as is feasible. One
new protocol is defined for Border Router discovery. All other
mechanisms used are existing IETF protocols.
The Autoconf solution uses three phases:
o Discovery of a Border Router
o Autoconfiguration of a globally routable IPv6 addresses to be used
for that Border Router
o Assurement that traffic sent with the configured globally routable
IPv6 address actually uses that Border Router
Address uniqueness is assured by IPv6 address generation mechanisms
used.
NOTE from the author:
This version of the document includes information on what
functionality NEMO for MANET provides and why. There is also a
section on routing, which is somewhat related to Autoconf. However,
the Autoconf workgroup should not work on this.
During peer reviewing, it was suggested to split this document for
better fitting IETF workgroups. This is processed after IETF-70.
End of note.
Boot Expires May 5, 2008 [Page 4]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
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 RFC2119 [10].
Readers are expected to be familiar with all the terms defined in
RFC3753: Mobility Related Terminology [11], RFC4885: Network Mobility
Support Terminology [13], Mobile Ad hoc Network Architecture [1] and
"Address Autoconfiguration for MANET: Terminology and Problem
Statement" [2].
Autoconf
Ad-Hoc Network Autoconfiguration
BRDP
Border Router Discovery Protocol
BRIO
Border Router Information Option
MNR-BR tunnel
NEMO based MANET Router to Border Router tunnel
MR-HA tunnel
Mobile Router to Home Agent tunnel
UPM
Uniform Path Metric
MANET Generated Address
Globally unique IPv6 and topologically correct address generated
for connectivity between nodes in the MANET and Corresponding
Nodes in the fixed infrastructure via a Border Router
MANET
A routing domain containing MANET routers [1].
Boot Expires May 5, 2008 [Page 5]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
3. Protocol overview and functioning
In the following subsections, the NEMO for MANET subcomponents are
briefly introduced.
3.1. Border Router Discovery Protocol (BRDP)
BRDP extends IPv6 neighbor discovery to provide information on MANET
Border Routers. Information is distributed in the MANET, where each
MANET Router selects one or more Border Routers and forwards the
Border Router information in the MANET. BRDP is implemented as
extension on IPv6 Neighbor Discovery [3].
Flood reduction mechanisms MAY be used. First of all, a MANET Router
MAY filter Border Routers, based on a path metric. The path metric
is the advertized bidirectional distance to the fixed infrastructure,
via that Border Router. Secondly, a MANET flooding reduction
mechanism MAY be used, if a MANET protocol running in the MANET
provides this service.
BRDP can carry detailed information for the Border Router, such as a
provider name and AAA options. AAA enables providers to control
access to the Border Routers. MANET Routers MAY select a Border
Router based on preferences for a provider.
BRDP can also be used to select an Access Router for Mobile IPv6, as
the Border Router option provides information for paths to the fixed
infrastructure. The provided information can be used among the
Default Router Preferences defined in RFC4191 [15].
3.2. BRDP-based Autoconf
BRDP provides prefix information to configure MANET Generated
Addresses. An MANET Generated Address is a globally unique IPv6 and
topologically correct address generated for connectivity between
nodes in the MANET and Corresponding Nodes in the fixed
infrastructure via a Border Router.
The nodes using BRDP-based Autoconf MUST implement a mechanism to
generate a unique 64-bit Interface Identifier. Uniqueness is
extremely likely when Modified EUI-64 format-based Interface
Identifiers are used [5], generated randomly [6], or by a well-
distributed hash function [7].
The generated Interface Identifier is combined with a BRDP provided
64-bit prefix, resulting in topologically correct address.
In this document, it is assumed the fixed infrastructure is the
Boot Expires May 5, 2008 [Page 6]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
Internet and globally unique addresses are used. The mechanisms
described in this document are compatible with unique local addresses
[16]. An implementation MAY provide configuration options for Border
Router selection based on offered global prefixes or unique local
prefixes, in cases where both types are used in the same MANET.
3.3. NEMO for MANET
When a Border Router has been selected and an accompanying address
has been configured, there is still a need for a mechanism enforcing
this Border Router to be used as an exit router to the fixed
infrastructure. NEMO basic support [14] is used as a dynamic
tunneling mechanism. Tunneling overhead is reduced by implementing
header compression, e.g. RoHC [9].
3.4. Session continuity
When mobile nodes in the MANET move, it is likely that the selected
Border Router becomes less optimal. Switching to an alternate Border
Router and updating addresses would break sessions to Corresponding
Nodes. By using "Mobility Support in IPv6" (RFC3775, [12]), session
continuity between the MANET Router and Corresponding Nodes is
provided. For hiding mobility for local fixed nodes (LFNs), the
MANET Router would act as Mobile Router implementing "Network
Mobility (NEMO) Basic Support Protocol" (RFC3963, [14]).
The nested NEMO approach introduces one additional tunneling header.
Once again, header compression is used to reduce the overhead.
Seamless handover is provided by a controlled switch between NEMO
MNR-BR tunnels. The MANET Router is responsible for setting up and
tearing down the tunnels, and switching traffic over these tunnels.
The NEMO MR-HA tunnel is also updated to reflect the new configured
address. Coherent switching does not result in any packet loss.
3.5. Leech tunneling
When a cluster of MANET Routers moves as a whole, a central node MAY
provide Border Router services for other nodes. This mechanism
reduces signaling overhead for tunnel maintenance.
3.6. Anonymity and traffic flow confidentiality
The mobile nodes in the MANET could require security services. By
using IPsec in the NEMO tunnels, traffic flow confidentiality and LFN
anonymity is provided. IPsec increases the overhead, but this is
kept at a minimum by using header compression.
Boot Expires May 5, 2008 [Page 7]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
4. Border Router Discovery Protocol
4.1. Introduction
BRDP is a simple distance vector protocol that distributes Border
Router information. It extends the Neighbor Discovery Protocol [3]
in order to carry information and metrics which help a MANET Router
to select a Border Router and help to configure addresses for
communication with the fixed infrastructure.
BRDP is a derivative of Tree Discovery [18], one of the candidate
protocols for Routing for Sensor Networks (RSN) and MANET for NEMO
(MANEMO). This document describes a protocol that best suits the
Autoconf requirements. It has to be determined if merging with
functionally equivalent RSN or MANEMO protocols is useful.
BRDP is a minimum extension to IPv6 Neighbor Discovery Router
Advertisements in order to distribute information on Border Routers.
It does not rely on any MANET protocol. Information is distributed
hop by hop from a Border Router downwards in the MANET using a tree
structure. Multiple Border Routers result in multiple, potentially
overlapping logical trees, i.e. a Directed Acyclic Graph (DAG).
ICMP Router Advertisement (RA) messages are used for distributing
Border Router information using the Border Router Information Option
(BRIO). BRIO allows MANET Routers to advertise Border Router
reachability, including information to select a preferred Border
Router. A MANET Router also destils a set of BRIOs for advertizing,
with a minimum of one. A mechanism is used to prevent looped
information, based on distance (Uniform Path Metric (UPM) and
Hopcount), sequence numbers and timing.
4.2. Border Router Information Option (BRIO)
The Border Router Information Option carries information that allows
a MANET Router to select and utilize a Border Router.
4.2.1. BRIO Base option
The BRIO is a container option, which might contain a number of
suboptions. The BRIO base option groups the minimum information set
that is mandatory in all cases.
Boot Expires May 5, 2008 [Page 8]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
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 |A|F|E|L|S|rsvd | Hopcount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Border Router Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uniform Path Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: BRIO base option
Fields:
Type:
8-bit identifier of the Router Advertisement option type. The
option identifier is to be determined.
Length:
8-bit unsigned integer. The length of the option (including the
type and length fields) in units of 8 octets. The minimum BRIO
option length is 4.
AAA(A):
Flag indicating using the Border Router needs authentication and
authorization. When set, a Service Selection suboption
immediately follows the BRIO base option. This document does only
describe BRIO forwarding rules considering the A-flag and Service
Selection suboption. Details on performing AAA is out-of-scope of
this document.
Boot Expires May 5, 2008 [Page 9]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
Floating(F):
When the F-flag is set, the Border Router has lost contact with
the fixed infrastructure. MANET Routers SHOULD stop using Border
Routers indicating that they are floating.
Emergency Response Services(E):
When the E-flag is set, the Border Router provides support for
emergency response services. Details on applications for
emergency response services are out-of-scope of this document.
The E-flag helps selecting BRIOs to be distributed in the MANET,
BRIO distribution SHOULD enable access to emergency response
services for all MANET nodes.
Loop-possible(L):
When the L-flag is set, an upstream MANET Router cannot guarantee
a loop-free path to the Border Router advertized in this BRIO.
Loop-possible status is cleared when a Border Router generated
BRIO with a new Sequence Number is forwarded in the MANET.
Solicitation Response(S):
When the S-flag is set, the Border Router requests forwarding the
BRIO downstream the BRIO forwarding tree as a response to a
special Router Solicitation. This provides a mechanism to speed
up convergence, requested by a downstream MANET Router. See
Section 4.3.3 for details.
rsvd, reserved:
Reserved bits. Set to 0.
Hopcount:
8-bit field registering the number of hops from the advertizing
MANET Router to the Border Router. Border Routers send BRIO with
a Hopcount zero. MANET Routers increment Hopcount by one when
forwarding a BRIO. Hopcount is used for to provide loop-free BRIO
forwarding.
Border Router Address:
128-bit address of the Border Router. The Border Router is
expected to add its own address as /128 prefix in the MANET
routing system.
Boot Expires May 5, 2008 [Page 10]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
Uniform Path Metric (UPM):
Uniform Path Metric is set to an initial value by the Border
Router and incremented by each MANET Router forwarding the BRIO.
The increment value MUST be between 1 and 16777215, allowing 255
hops with a maximum link metric. Border Router selection is based
on UPM and optionally other information. UPM is used to provide
loop-free BRIO forwarding.
Sequence Number:
16-bit unsigned integer set by the Border Router and incremented
with each new BRIO it sends on a link and propagated with no
change down the tree.
4.2.2. BRIO suboptions
In addition to the BRIO Base option, a number of suboptions are
defined. Suboptions MAY have alignment requirements.
4.2.2.1. Pad suboption
The Pad suboption format is as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
Figure 2: Pad suboption
Fields:
Type = 0
8-bit identifier of the Pad suboption type. The option identifier
is determined as 0.
The format of the Pad suboption has neither an suboption length nor
suboption data fields. The Pad suboption is used to insert one octet
of padding in the BRIO to enable alignment, either between suboptions
or for the whole suboption container.
Boot Expires May 5, 2008 [Page 11]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
4.2.2.2. Service Selection suboption
Each BRIO MAY have only one Service Selection suboption, identifying
the Service Provider and/or the provided service offered by the
Border Router. The Service Selection suboption MUST be the first
BRIO suboption.
The Service Selection suboption is equivalent to the Service
Selection Mobility Option defined in "Service Selection for Mobile
IPv6" [20].
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 = 1 | Length | Identifier... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Service Selection suboption
Fields:
Type = 1
8-bit identifier of the Service Selection suboption type. The
option identifier is determined as 1.
Length:
8-bit unsigned integer. The length represents the length of the
Service Selection Identifier in octets, excluding the suboption
type and length fields. Usage of the Length field is equivalent
to [20].
Identifier:
A variable length UTF-8 encoded Service Selection Identifier
string used to identify the Border Router service provider and
optionally the type of service. Valid examples are 'ims', 'voip'
and 'voip.companyxyz.example.com'.
A Border Router MAY offer multiple services using multiple BRIOs.
However, each BRIO MUST use a unique Border Router address.
Boot Expires May 5, 2008 [Page 12]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
4.3. BRDP processing
BRDP messages are initiated by Border Routers. MANET Routers forward
this information using ICMP ND Router Advertisements. The main BRDP
processing functions of a MANET Router are BRDP message reception,
maintaining a BRIO cache and forwarding BRDP messages.
4.3.1. BRDP message reception and BRIO cache maintenance
Border Router information included in received BRDP messages is
stored in a BRIO cache table. Along with the BRIO itself, context
information is maintained, such as the BRIO sender, history /
statistics and status information. History and statistics include a
timestamp indicating when the most recent message was received and a
measured or signaled RA interval. Status information includes Border
Router selection outcome for BRIO forwarding explained in
Section 4.3.2 and Border Router selection for its own usage explained
in Section 5.1 .
Cache entries are unique on Border Router Address and the neighbor
router address that forwarded the BRIO. Status information is also
maintained at Border Router Address and Service Selection Identifier
aggregation level. Also information on neighbor MANET Router is
maintained.
When a BRDP message is received, the Sequence Number field of
received BRIOs is checked; the Sequence of a received BRIO MUST be
equal to or higher than Sequence Number in the cache for an existing
entry in the cache, with wrap-around checking. BRIO messages do not
need to be forwarded at fixed time intervals, so large gaps in
sequence numbers may occur. Increment values between 0 and 65000 are
accepted. Increment values between 65001 and 65535 are rejected.
This specification does not mandate any new restriction on
unsolicited multicast Router Advertisements interval. Unsolicited
multicast Router Advertisements are sent with an interval between 30
milliseconds, specified in RFC3775 [12] and 1800 seconds, specified
in RFC2461 [3]. BRDP assumes unsolicited multicast Router
Advertisements have a somewhat stable interval. The RA Advertisement
Interval Option MAY provide the maximum interval being used [12] or
alternatively the interval can be measured during BRIO reception.
A cache cleanup routine SHOULD run at regular intervals to get rid of
stale entries. Stale entries are removed when the entry is not
updated for 5400 seconds or all following conditions are met:
o The stale entry is not used by the MANET Router itself.
Boot Expires May 5, 2008 [Page 13]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
o The stale entry was not selected for forwarding in the last Router
Advertisement.
o The stale entry was not recently updated by a received BRIO. In
this context, recently is defined as a) within its own unsolicited
multicast Router Advertisements interval and b) shorter than 3
times the measured senders unsolicited multicast Router
Advertisements interval.
Cache entries MAY also be removed, under condition that the BRIO
cache has reached a configured maximum number of entries and a new,
to be stored BRIO is received. A removal candidate is selected based
on:
o The candidate entry is not used by the MANET Router itself.
o The candidate entry is not selected for forwarding in the last
Router Advertisement.
o The candidate entry is redundant; other information for the same
Border Router is stored in the cache with a better UPM and / or
was received more recently.
o The candidate entry is redundant; other information for the same
Service Selection Identifier is stored in the cache with a better
UPM and / or was received more recently.
o The candidate entry is less attractive; other Border Routers are
stored in the cache with better UPM and / or were received more
recently.
4.3.2. Generating and sending BRDP messages
When a MANET Router sends an Router Advertisement it SHOULD include a
set of BRIOs. The maximum number of BRIOs to be sent in a BRDP
message is a MANET Router configuration parameter. BRIOs are
selected from the BRIO Cache.
Router Advertisements are sent in response to Router Solicitation
messages or unsolicited with a uniformly-distributed random interval
that falls between MinRtrAdvInterval and MaxRtrAdvInterval [3]. In
addition, the MANET Router MAY send a Router Advertisement when an
important change in a to be sent BRIO would occur. The Border Router
MAY request that the sent BRIO SHOULD be forwarded downstream in the
MANET, indicated by the S-flag, see Section 4.3.3. These additional
Router Advertisements are processed similar to responses on Router
Solicitations.
Boot Expires May 5, 2008 [Page 14]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
Before composing a set of BRIOs, the UPM increment is calculated for
each MANET Router from which a BRIO has been received. UPM
increments have a minimum value of 1 and SHOULD incorporate
bidirectional MANET link metrics for that neighbor. UPM is a
composed metric for both the inbound and the outbound path. Note
that MANET metrics are defined for one direction only. Using
bidirectional UPM optimizes Border Router selection for both inbound
and outbound traffic. In some cases it is far more important to
select the best path from the Border Router to the MANET Router than
the reverse path.
In case the link to the MANET Router from which a BRIO has been
received is broken, the UPM is set to the maximum value, i.e.
4294967295.
Border Router selection SHOULD be based on UPM, preferring the
shortest path for the bi-directional MNR-BR tunnel. Note that the
BRIO UPM includes the initial metric set by the Border Router, UPM is
not a metric between the MANET Router and the Border Router. Initial
metric set by Border Routers can be used for Border Router preference
and for load balancing.
Border Router selection does not select a routing path to the Border
Router. The MANET Protocol is used for routing functionality.
Section 10 discusses a future extension for NEMO for MANET, providing
BRDP-based routing.
The BRIO selection algorithm MUST implement a loop avoidance
mechanism, described in Section 4.3.3. BRIOs with the L-flag set
SHOULD NOT be selected.
The BRIO selection algorithm MAY incorporate a hysteresis and
dampening mechanism. It MAY also take into account other
information, such as history / statistics and status information
tracked in the BRIO cache.
At a minimum, one BRIO with the E-flag set MUST be selected, when
such an entry exists in the BRIO Cache.
BRIO selection SHOULD select a number of BRIOs with distinct Service
Selection Identifiers, where the selection mechanism MAY use a
preference scheme selecting and filtering Service Selection
Identifiers.
A MANET Router SHOULD inform downstream MANET Routers if the path to
a previous advertized Border Router is lost, by at least 3 times
retransmitting previous sent BRIO with a UPM value 4294967295 or by
selecting a BRIO that failed the loop prevention check, indicated
Boot Expires May 5, 2008 [Page 15]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
with the L-flag set. The MANET Router SHOULD include an alternative
BRIO for the same Service Selection Identifier in the to be sent BRDP
message, if such a BRIO is available in the cache.
The UPM and Hopcount fields of the to be sent BRIO are updated. The
calculated UPM increment is added to the UPM and the Hopcount is
incremented by 1. Incrementing UPM MAY incorporate a hysteresis and
dampening mechanism. Also forcasting information MAY be used.
For each Border Router listed in the cache, the UPM-loop-prevention-
threshold and the Hopcount-loop-prevention-threshold variables are
maintained. These variables are used for the loop prevention
mechanism described in Section 4.3.3. The variables are set or
updated when sending BRDP messages. For a to be sent BRIO with a
higher Sequence Number than the previous sent BRIO for that Border
Router, the variables are set on values in the to be sent BRIO. For
to be sent BRIO with the same Sequence Number, the variables are
updated when the UPM or Hopcount of the to be sent BRIO is lower than
the threshold.
The BRIOs are appended to the Router Advertisement message. The BRIO
cache information is updated.
A BRDP flooding reduction mechanism MAY be used, where the mechanism
reduces redundant BRIO distributing. Some MANET protocols can
provide information for the flooding reduction mechanism. No
additional protocol is required.
4.3.3. BRDP loop prevention
Each BRIO sent out by a Border Router has an increased Sequence
Number. This BRIO is forwarded in the MANET and it updates old BRIO
status with an outdated Sequence Number. Between these BRIO Sequence
updates, MANET Routers MAY repeatedly send BRIOs with a constant
Sequence Number and an updated UPM or Hopcount.
A MANET Router MUST check candidate BRIOs for providing loop-free
operation. Loop-free operation is guaranteed as long as at least one
of the following conditions is true:
o The BRIO has a higher Sequence Number than a BRIO for this Border
Router sent before. Using wrap-around logic, increments up to
32768 are acceptable. (wrap-around logic needs checking)
o The BRIO has the same Sequence Number than a BRIO for this Border
Router sent before and the UPM value is equal or lower than the
UPM-loop-prevention-threshold for this Border Router.
Boot Expires May 5, 2008 [Page 16]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
o The BRIO has the same Sequence Number than a BRIO for this Border
Router sent before and the Hopcount is equal or lower than the
Hopcount-loop-prevention-threshold for this Border Router.
When no candidate BRIO for a Border Router is available, the MANET
Router SHOULD select the previous sent BRIO. In such a case, the
downstream branch for that BRIO is getting frozen. Downstream MANET
Routers MAY jump to other branches of the BRIO forwarding tree, as
long as their path to the Border Router is shortened by lower UPM or
by lower Hopcount. A new BRIO sent by the Border Router thaws a
"loop-possible BRIO forwarding tree".
A MANET Router that detects an attractive candidate BRIO but is
prohibited for using it, because the Sequence Number is lower or
equal than the BRIO sent before, MAY send a special Router
Solicitation message to the Border Router. The Border Router
responds on such a Router Solicitation message with a BRIO with the
S-flag set. Sending Router Solicitations MUST be rate limited to at
most twice the reception rate of the attractive candidate BRIO. A
next version of this document will include a specification for the
special Router Solicitation message.
In some circumstances, a MANET Router MAY select a BRIO for
forwarding that fails the loop prevention check. For example, the
link to the upstream neighbor is lost and an alternative path is
available, with a higher UPM and a higher Hopcount or with a lower
Sequence Number. The MANET Router cannot assure selecting this
candidate BRIO provides a loop-free topology, but it could be better
than sending nothing or repeatedly sending unreachable. When a MANET
Router forwards a BRIO that failed the loop prevention check, the
L-flag MUST be set.
When a MANET Router selected a BRIO that failed the loop prevention
check, a duplicate packet detection mechanism MUST be implemented.
MANET Routers that select a BRIO with the L-flag set SHOULD have a
duplicate packet detection mechanism implemented. Details on
duplicate packet detection is out-of-scope of this document.
Boot Expires May 5, 2008 [Page 17]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
5. BRDP-based Autoconf
5.1. Border Router selection
When a MANET Router needs to communicate to the fixed infrastructure,
it MUST select a set of Border Routers. Information concerning
available Border Routers is kept in the BRIO cache.
Before selecting, the UPM increment is calculated as described in
Section 4.3.2.
The Border Router selection algorithm SHOULD be based on Service
Selection Identifiers (if available) and UPM. UPM indicates the best
Border Router, however such a Border Router MAY require
authorization. The A-flag and the Service Selection Identifier
provides the prime information for selecting a preferred provider or
preferred service. The Border Router selection algorithm MAY be
extended with any other information. Future defined BRIO suboptions
could provide additional information. Border Router selection MAY be
based on the type of the Border Router Address, e.g. a globally
unique address or a unique local address.
The BRIO flags MAY assist in Border Router selection.
o A Border Router could indicate that it is not connected to the
fixed infrastructure, signaled with the F-flag. Usage of this
Border Router SHOULD be avoided.
o For emergency response applications, a Border Router providing
such services SHOULD be selected, indicated by the E-flag.
o The guarantee for a loop-free path to a Border Router can
temporary be withdrawn, indicated by the L-flag set. Usage of
this Border Router SHOULD be avoided.
The Border Router selection mechanism MAY be triggered by received
BRDP messages, changes in metrics to neighbors advertising BRDP
messages, changes in MANET metrics to Border Routers used or with a
regular interval.
Details on authentication and authorization to the Border Router are
out-of-scope for this document.
A MANET Router MAY select multiple Border Routers for smooth handover
implementing make-before-break. It MAY also use multiple Border
Routers concurrently. A description how Border Routers can be used
concurrently or how traffic is distributed over MNR-BR tunnels is
out-of-scope for this document.
Boot Expires May 5, 2008 [Page 18]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
5.2. MANET Address generation
The MANET Router MUST use a topologically correct address when
communicating to corresponding nodes via the fixed infrastructure.
Topologically correct addresses SHOULD be generated for each Border
Router used. Only when it is known that for all Border Routers for a
Service Selection Identifier or a set of Service Selection
Identifiers a commonly used address is accepted, a previously
generated acceptable address can be reused.
A MANET Generated Address is used as a /128 prefix. It is built up
with an 64-bits Interface Identifier and a 64-bits prefix from the
Border Router Address. This generated /128 address SHOULD be added
in the MANET routing system and SHOULD be used as CoA for the NEMO
tunnel to the Border Router as discussed in Section 6. The MANET
Generated Address MAY also be used for other traffic, either inside
the MANET or towards the fixed infrastructure. For communication
towards the fixed infrastructure, this address SHOULD only be used if
the MANET Router is sure that the traffic is sent via the Border
Router that was used for address generation.
For the Interface Identifier used, the BRDP-based MANET Address
Generation MUST implement a mechanism for generating a unique
Interface Identifier. Known mechanisms are:
o Modified EUI-64 format-based Interface Identifier, RFC4291 [5],
based on IEEE 802 48-bit MAC address or IEEE EUI-64 identifier.
However, this method does not guarantee identifiers are unique as
duplicate MAC addresses can occur.
o Generated randomly, RFC3041 [6].
o Well-distributed hash function, RFC3972 [7].
After MANET Address Generation, RFC4429 Optimistic Duplicate Address
Detection [8] SHOULD be used. Still, uniqueness is not fully
guaranteed. Main reasons are merging of MANET segments, node
movement, node misbehavior or address spoofing attacks. Details on
handling this condition are out-of-scope of this document.
Address generation for globally unique addresses and RFC4193 unique
local addresses [16] is identical. Nodes MUST NOT use unique local
addresses to communicate with a Border Router with a globally unique
address. Nodes MUST NOT use globally unique addresses to communicate
with a Border Router with a unique local address.
In case a MANET Generated Addresses is needed but no BRIO information
is available, a MANET Router MAY generate an address using a unique
Boot Expires May 5, 2008 [Page 19]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
local addresses [16] /64 prefix.
A MANET Generated Addresses cleanup routine SHOULD run at regular
intervals to get rid of stale addresses.
Boot Expires May 5, 2008 [Page 20]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
6. NEMO for MANET
6.1. Need for enforcing usage of selected Border Router
Border Router selection and BRDP-based Autoconf is a MANET Router
local mechanism. Without an additional mechanism, other MANET
Routers are not notified of Border Router selections. As a
consequence, it is not enforced that the Border Router chosen is
actually used for packets sent to a Corresponding Node via the fixed
infrastructure using for example a default gateway.
The packets sent to the Corresponding Node need an attribute which
can be used to ensure that the packets are forwarded towards the
selected Border Router. This Border Router shall remove the
attribute and forward the packets.
For the return path, there is no such problem, as the MANET Generated
Address is associated with the Border Router using its prefix.
Packets from the Corresponding Node are forwarded to the Border
Router and from there, to the MANET Router that selected this Border
Router.
Usage of a Border Router could be limited to subscribers. This
scenario needs a method for controlled usage of a Border Router. By
using a protected tunnel between the node using the Border Router and
the Border Router itself, controlled access can be provided.
6.2. Using NEMO as tunneling method
By using tunneling, the destination address is used as attribute
ensuring the packets are forwarded to the selected Border Router.
NEMO basic support [14] is used as a dynamic tunneling mechanism. It
provides a mechanism for tunnel maintenance, based on Mobile IP.
This mechanism is used for dynamic tunnel setup and tunnel
maintenance. Updating tunnel CoA using a Bind Update is rarely
needed. However, it can be used to support some security features or
for MANET Generated Address changes. Address changes can be used as
a remedy against detected duplicate addresses.
After a Border Router is selected and a MANET address is generated,
the NEMO tunnel binding procedure is performed.
Binding is protected by the use of IPsec extension headers or by the
use of the Binding Authorization Data option [12]. The security
mechanism MUST support open access for binding when the A-flag is
cleared. Details on a protected binding to open access Border
Routers are to be described in a next version of this document.
Boot Expires May 5, 2008 [Page 21]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
When the A-flag is set, the binding mechanism is not defined in this
document.
When the binding procedure is completed, the MANET Router has access
to the fixed infrastructure and can start communicating to
corresponding nodes. It can use the MANET Generated Address for
short lived connections using the MANET Generated Address, e.g. DNS
requests. The MANET Router MUST NOT use the MANET Generated Address
for traffic sent via other Border Routers. For providing session
continuity while switching between Border Routers, a MIP6 or NEMO
MN-HA tunnel is used. The MANET Generated Address is used as CoA for
Mobile IPv6 or NEMO in a nested tunnel, as described in Section 7.
The MNR-BR (or MR-HA) tunnel MAY be used for DHCPv6 (or DHCP for IPv4
if IPv4 over the NEMO tunnel is supported) to facilitate a need for
prefixes / addresses in the MANET, other than provided by NEMO for
MANET address generation described in Section 5.2.
In this version of this document, it is assumed that DHCP
functionality on the Border Router is not needed. "Prefix delegation
for NEMO" [19] is to be used to provide addresses managed by a Home
Agent. Such addresses are independent from a Border Router.
However, the Border Router itself MAY also act as Home Agent. In
this scenario, nested tunneling for overlapping MNR-BR and MN-HA
SHOULD be circumvented. The HA functionality provided by the Border
Router SHOULD be accessible via the fixed infrastructure.
When multiple prefixes for a Mobile Network are being used, the
Mobile Router MUST forward packets accordingly. Packets with a
source address associated with a MR-HA tunnel SHOULD be forwarded
over this tunnel.
For successful binding, a two-way communication path between the
MANET Router and the Border Router is required. The new MANET
Generated Address is added in the MANET domain just before the
binding procedure. The MANET protocol could need some time to
converge and the delivery of the Binding Acknowledgement Message to
the MANET Router could fail. Section 10 provides a mechanism to
provide immediate bidirectional reachability between the MANET Router
and the Border Router. As an alternative, binding update retransmits
help complete the binding procedure.
6.3. Header compression
Tunneling overhead is reduced by implementing header compression,
e.g. RoHC [9]. However, header compression for MIPv6 or NEMO is not
defined yet. Individual proposals are work in progress, e.g. "IP
Tunneling Optimization in a Mobile Environment" [21].
Boot Expires May 5, 2008 [Page 22]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
7. Session continuity
In case the MANET Router prefers another Border Router, it MUST
generate a new MANET Generated Address and set up a new MNR-BR tunnel
before switching. However, changing addresses would break sessions
to Corresponding Nodes.
By using Mobile IP, session continuity is provided. To hide mobility
for local fixed nodes (LFNs), the MANET Router SHOULD act as Mobile
Router implementing NEMO Basic Support [14].
The nested NEMO approach introduces one additional tunneling header.
Once again, header compression is used to reduce the overhead. The
MNR-BR overhead reduction is also to be used for the MR-HA tunnel.
Seamless handover is provided by a controlled switch between NEMO
MNR-BR tunnels. The MANET Router is responsible for setting up and
tearing down the MNR-BR tunnels. Seamless switching traffic over
these tunnels requires "Multiple Care-of Addresses Registration"
[22], for the NEMO MR-HA tunnel. Also a mechanism is needed for
signaling the preferred CoA, such as "Flow Bindings in Mobile IPv6
and Nemo Basic Support" [23]. Coherent switching does not result in
any packet loss. The steps for a seamless handover are:
o Complete procedure for selecting a Border Router and generating an
Autoconf Address.
o Set-up a MNR-BR tunnel
o Register new CoA address for MR-HA tunnel on HA
o Switch traffic from other tunnels to this new tunnel
o Optionally, check connectivity through this updated tunnel; switch
back if check fails
o Clean up unused MR-HA CoA registrations
o Clean up unused MNR-BR tunnels
o Clean up unused MANET Generated Addresses
A MANET Router MAY keep any number of MNR-BR tunnels, but it SHOULD
restrict the number of tunnels to an acceptable value.
Boot Expires May 5, 2008 [Page 23]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
8. Support for IPv4
NEMO for MANET is designed for IP version 6. The used mechanism for
address generation extends the functionality specified in "IPv6
Stateless Address Autoconfiguration" (RFC2462, [4]).
IPv4 lacks a protocol for Stateless Address Autoconfiguration.
Dynamic link-Local addresses (RFC3927, [17]) could be used, but these
addresses are not globally routable.
A future enhancement for NEMO for MANET is supporting IPv4 by using
the MR-HA tunnel. After NEMO tunnel setup towards the Home Agent,
any NEMO support for IPv4 is provided for usage in the MANET. NEMO
for MANET IPv4 support depends on:
o NEMO support for IPv4 transport between Mobile Router and Home
Agent
o Deployment of IPv6 in the MANET
o IPv6 connectivity between Border Routers and Home Agents
Boot Expires May 5, 2008 [Page 24]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
9. Leech tunneling
NOTE from the author:
I used the term LEECH, because I could not find any other term for
this functionality. In the past, leeching was being used to reduce
blood pressure, so it could be some kind of a remedy. Too much
leeching weakens a person or can be cause of death. Same applies for
what is meant here, leech tunneling reduces binding update storms,
but it can overload an offering MANET Router.
End of note.
In a MANET, a group of MANET Routers could move as a whole.
Switching Border Routers would generate a storm of NEMO tunnel
maintenance overhead. In such a case, a single tunnel update
procedure for all MANET Routers in a cluster could be more efficient.
This mechanism can be supported by another NEMO nesting. MANET
Routers MAY select another MANET Router in the moving cluster as
(proxy) Border Router.
Leech tunneling is supported without any modification in BRDP, MANET
Generated Address generation or NEMO tunneling protocol. However,
leech tunneling depends on a MANET Router offering leeching as a
service. A MANET Router MAY advertise itself as Border Router, with
an UPM as calculated during the BRIO generation step described in
Section 4.3.2. The UPM MAY additionally be incremented, as the
additional nesting introduces additional overhead.
Next versions of this document might refine the Leech Tunneling
mechanism. BRIO suboptions could be added for improving performance,
e.g. clusterhead election.
Boot Expires May 5, 2008 [Page 25]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
10. BRDP-based routing
NOTE from the author:
BRDP-based routing is to be discussed in IETF, the expected outcome
would be to remove this idea out of this document and optionally to
describe this mechanism in more detail in a seperate Internet Draft.
End of note.
NEMO for MANET's primary goal is to provide a mechanism to distribute
Border Router information, address generation and Border Router
utilization. Providing a path between the MNR and the BR is a
responsibility of the MANET Routing protocol. However, the mechanism
can easily be extended to provide lightweight routing, providing only
the needed paths and nothing else.
The proposed mechanism described below could be somewhat optimized
for improved performance, e.g. better loop avoidance or speeding up
convergence time.
The paths provided by BRDP-based routing can span multiple MANET
protocols or MANET regions segmented by parameters (e.g. area ID) or
security mechanisms (e.g. shared key). BRDP-based routing is not a
replacement for MANET routing protocols. MANET routing protocols are
optimized for inner MANET routing, where BRDP-based routing is
optimized for Border Router reachability. Using two mechanisms
fulfilling these two objectives is practical and efficient.
BRDP provides loop-free BRIO distribution, but can also provide a
backwards path from MANET Routers to learned Border Routers. For
each Border Router Address, the neighbor advertizing the best path
(lowest UPM) incremented with a link metric to the neighbor is
selected as next-hop.
To provide a path from the Border Router to the MANET Routers, a new
mechanism is needed. Choices are:
o Implement some form of source routing, where the Border Router
caches this routing header and uses this information for sending
packets to the MANET Router. Such a mechanism is described in
"IPv6 Reverse Routing Header and its application to Mobile
Networks" [24].
o Implement some form of ND extension, signaling reachability
information towards the Border Router. Such a mechanism is
described in "Network In Node Advertisement" [25].
Boot Expires May 5, 2008 [Page 26]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
o Implement some kind of Routing header or Hop-by-Hop Options
header, signaling the MANET Router address used for forwarding the
packet to the Border Router. All MANET Routers in the path, used
for the MNR-BR tunnel, process this header. The routing table is
checked and updated if needed, storing the reverse path back to
the MANET Router. This provides a return path, from Border Router
to MANET Router as soon as the first packet with the MANET
Generated Address is received by the Border Router. This
mechanism is similar to an 802.1D self-learning bridge. Note that
this header information can also be used for loop detection, a
packet MUST NOT be forwarded back to the previous hop.
Routing table entries generated by BRDP-based routing SHOULD have an
expiration time. The maximum time suggested is two times the maximum
unsolicited multicast Router Advertisements interval, which is 1
hour.
Boot Expires May 5, 2008 [Page 27]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
11. IANA considerations
The IANA is requested to define a new IPv6 Neighbor Discovery option
for the Border Router Information Option, defined in this document.
+------+----------------------------------+-----------+
| Type | Description | Reference |
+------+----------------------------------+-----------+
| TBA | Border Router Information Option | [RFCXXXX] |
+------+----------------------------------+-----------+
Figure 4: IANA BRIO assignment
The registry for these options can be found at:
http://www.iana.org/assignments/icmpv6-parameters
The IANA is requested to create a new registration for BRIO
suboptions.
12. Security Considerations
NEMO for MANET inherits security considerations from MANET and NEMO
technology. BRDP is a new mechanism, based on ND. BRDP inherits
security considerations from ND.
A more detailed description on this subject is to be included in a
next version of this document.
12.1. Anonymity and traffic flow confidentiality
In a wireless environment, a major vulnerability is traffic
interception. Encrypting data traffic is used as a remedy.
By using IPsec in the NEMO tunnels, traffic flow confidentiality and
LFN anonymity can be provided. IPsec increases the overhead. Once
again, header compression is used to reduce overhead.
The following services are provided:
o Traffic between LFN and CN can be encrypted. This is an end-node
responsibility.
o The MR-HA tunnel can be encrypted. This protects the tunnel and
hides LFN and CN addresses.
Boot Expires May 5, 2008 [Page 28]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
o The MNR-BR tunnel can be encrypted. This protects the tunnel and
hides LFN and CN addresses. The CN address would be the MR-HA
tunnel HA address.
o The MNR-BR Bind Update MAY use random CoA addresses. Information
leakage is limited to the Border Router address and Border Router
prefix. Details on anonymous Bind Update for the MNR-BR tunnel
are to be included in one of the next versions of this document.
Anonymity is also related to information on other layers, e.g. 802
MAC addresses or mobile equipment identities (IMEI) / mobile
subscriber identities (IMSI).
13. Acknowledgments
The author wants to thank anyone involved in IETF on MANET and NEMO
technology for their efforts on mobile network infrastructures.
Special thanks to Pascal Thubert, Thomas Clausen and Ryuji Wakikawa
for their efforts on defining MANEMO technology, which inspired the
author to compose this document. Also special thanks to Benny Tops
and Ronald in 't Velt for reviewing.
14. References
14.1. Normative reference
[1] Chakeres, I., "Mobile Ad hoc Network Architecture",
draft-ietf-autoconf-manetarch-06 (work in progress),
October 2007.
[2] Baccelli, E., "Address Autoconfiguration for MANET: Terminology
and Problem Statement", draft-ietf-autoconf-statement-01 (work
in progress), September 2007.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[5] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[6] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
Boot Expires May 5, 2008 [Page 29]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
[7] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[8] Moore, N., "Optimistic Duplicate Address Detection (DAD) for
IPv6", RFC 4429, April 2006.
[9] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001.
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[11] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[12] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[13] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
[14] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
14.2. Informative Reference
[15] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", RFC 4191, November 2005.
[16] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[17] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration
of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[18] Thubert, P., "Nested Nemo Tree Discovery",
draft-thubert-tree-discovery-06 (work in progress), July 2007.
[19] Kniveton, T. and P. Thubert, "Mobile Network Prefix
Delegation", draft-ietf-nemo-prefix-delegation-02 (work in
progress), August 2007.
[20] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
Boot Expires May 5, 2008 [Page 30]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
Selection for Mobile IPv6", draft-korhonen-mip6-service-04
(work in progress), October 2007.
[21] Haddad, W., "IP Tunneling Optimization in a Mobile
Environment", draft-haddad-mip6-tunneling-optimization-01 (work
in progress), July 2007.
[22] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-03 (work in progress),
July 2007.
[23] Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic
Support", draft-soliman-monami6-flow-binding-04 (work in
progress), March 2007.
[24] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
its application to Mobile Networks",
draft-thubert-nemo-reverse-routing-header-07 (work in
progress), February 2007.
[25] Thubert, P., "Network In Node Advertisement",
draft-thubert-nina-01 (work in progress), July 2007.
Boot Expires May 5, 2008 [Page 31]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
Appendix A. Change Log From Previous Version
o 00: Initial Document.
Author's Address
Teco Boot
Infinity Networks B.V.
Elperstraat 4
Schoonloo 9443TL
Netherlands
Email: teco@inf-net.nl
Boot Expires May 5, 2008 [Page 32]
Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Boot Expires May 5, 2008 [Page 33]
