draft-ietf-autoconf-statement-00.txt   draft-ietf-autoconf-statement-01.txt 
MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.) MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.)
Internet-Draft INRIA Internet-Draft INRIA
Expires: December 20, 2007 K. Mase Expires: February 2, 2008 K. Mase
Niigata University Niigata University
S. Ruffino S. Ruffino
Telecom Italia Telecom Italia
S. Singh S. Singh
Samsung Samsung
June 18, 2007 August 2007
Address Autoconfiguration for MANET: Terminology and Problem Statement Address Autoconfiguration for MANET: Terminology and Problem Statement
draft-ietf-autoconf-statement-00 draft-ietf-autoconf-statement-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 20, 2007. This Internet-Draft will expire on February 2, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Traditional dynamic IPv6 address assignment solutions are not adapted Traditional dynamic IPv6 address assignment solutions are not adapted
to mobile ad hoc networks. This document elaborates on this problem, to mobile ad hoc networks. This document elaborates on this problem,
states the need for new solutions, and requirements to these states the need for new solutions, and requirements to these
solutions. solutions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5
3.1. Standalone MANET . . . . . . . . . . . . . . . . . . . . . 5 3.1. Standalone MANET . . . . . . . . . . . . . . . . . . . . . 5
3.2. Connected MANET . . . . . . . . . . . . . . . . . . . . . 5 3.2. Connected MANET . . . . . . . . . . . . . . . . . . . . . 5
3.3. Deployment Scenarios Selection . . . . . . . . . . . . . . 5 3.3. Deployment Scenarios Selection . . . . . . . . . . . . . . 5
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
4.1. MANET Autoconfiguration Goals . . . . . . . . . . . . . . 6 4.1. MANET Autoconfiguration Goals . . . . . . . . . . . . . . 7
4.2. Existing Solutions' Shortcomings . . . . . . . . . . . . . 6 4.2. Existing Protocols' Shortcomings . . . . . . . . . . . . . 7
4.2.1. Lack of Multi-hop Support . . . . . . . . . . . . . . 7 4.2.1. Lack of Multi-hop Support . . . . . . . . . . . . . . 7
4.2.2. Lack of Dynamic Topology Support . . . . . . . . . . . 7 4.2.2. Lack of Dynamic Topology Support . . . . . . . . . . . 8
4.2.3. Lack of Network Merging Support . . . . . . . . . . . 7 4.2.3. Lack of Network Merging Support . . . . . . . . . . . 8
4.2.4. Lack of Network Partitionning Support . . . . . . . . 8 4.2.4. Lack of Network Partitioning Support . . . . . . . . . 9
4.3. MANET Autoconfiguration Issues . . . . . . . . . . . . . . 8 4.3. MANET Autoconfiguration Issues . . . . . . . . . . . . . . 9
4.3.1. Address and Prefix Generation . . . . . . . . . . . . 9 4.3.1. Address and Prefix Generation . . . . . . . . . . . . 9
4.3.2. Address Uniqueness Requirements . . . . . . . . . . . 9 4.3.2. Prefix and Address Uniqueness Requirements . . . . . . 10
4.3.3. MANET Border Routers Related Issues . . . . . . . . . 10 4.3.3. MANET Border Routers Related Issues . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Solutions Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Informative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
A Mobile Ad hoc NETwork (also known as a MANET [2] [1]) consists of a A Mobile Ad hoc NETwork (also known as a MANET [2] [1]) consists of a
loosely connected set of MANET routers. Each MANET router embodies loosely connected set of MANET routers. Each MANET router embodies
IP routing/forwarding functionality and may also incorporate host IP routing/forwarding functionality and may also incorporate host
functionality. These routers dynamically self-organize and maintain functionality. These routers dynamically self-organize and maintain
a routing structure among themselves, regardless of the availability a routing structure among themselves, regardless of the availability
of a connection to any infrastructure. MANET routers may be mobile of a connection to any infrastructure. MANET routers may be mobile
and may communicate over symmetric or assymetric wireless links. and may communicate over symmetric or assymetric wireless links.
They may thus join and leave the MANET at any time. They may thus join and leave the MANET at any time.
However, prior to participation in IP communication, each MANET However, prior to participation in IP communication, each MANET
interface that does not benefit from appropriate static configuration router that does not benefit from appropriate static configuration
needs to automatically acquire at least one IP address, that may be needs to automatically acquire at least one IP address, that may be
required to be unique within a given scope. required to be unique within a given scope, or to be topologically
appropriate.
Standard automatic IPv6 address/prefix assignment solutions [5], [3] Standard automatic IPv6 address/prefix assignment solutions [5], [3]
[4] do not work "as-is" on MANETs due to ad hoc networks' unique [4] do not work "as-is" on MANETs due to ad hoc networks' unique
characteristics [2], and new mechanisms are therefore needed. This characteristics [2], therefore new or modified mechanisms are needed.
document thus details and categorizes the issues that need to be This document thus details and categorizes the issues that need to be
addressed. addressed.
2. Terminology 2. Terminology
In this document, several words are used to signify the requirements This document uses the MANET architecture terminology defined in [2],
of the specification. These words are often capitalized. The key as well as the following terms :
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119].
In addition, this document uses the MANET architecture terminology
defined in [2], as well as the following terms :
Local address - An IP address configured on an interface of a router MANET Local address (MLA) - An IP address configured on an interface
in a MANET and valid for communication inside this MANET. A local of a router in a MANET and valid for communication inside this
address MUST NOT be used for communication including routers MANET.
outside the MANET.
Global address - An IP address configured on a MANET router and Global address - An IP address configured on a MANET router and
valid for communication with routers in the Internet, as well as valid for communication with routers in the Internet, as well as
internally within the MANET. internally within the MANET.
Standalone MANET - An independent ad hoc network, which does not Standalone MANET - An independent ad hoc network, which does not
contain a border router through which it is connected to the contain a border router through which it is connected to the
Internet. Internet.
Network merger - The process by which two or more previously Network merger - The process by which two or more previously
skipping to change at page 4, line 42 skipping to change at page 4, line 35
Network partitioning - The process by which an ad hoc network splits Network partitioning - The process by which an ad hoc network splits
into two or more disconnected ad hoc networks. into two or more disconnected ad hoc networks.
Address generation - The process of selecting a tentative address in Address generation - The process of selecting a tentative address in
view to configure an interface. view to configure an interface.
Address assignment - The process of configuring a generated address Address assignment - The process of configuring a generated address
on an interface. on an interface.
Pre-service address uniqueness - The property of an address which is Pre-service address uniqueness - The property of an address which is
assigned at most once at this given point in time, within a given assigned at most once within a given scope, and which is unique,
scope. before it is being used.
In-service address uniqueness - The property of an address which was In-service address uniqueness - The property of an address which was
assigned at most once within a given scope, and which remains assigned at most once within a given scope, and which remains
unique over time, as the address is being used. unique over time, after the address has started being used.
3. Deployment Scenarios 3. Deployment Scenarios
Automatic configuration of IP addresses and/or prefixes on MANET Automatic configuration of IP addresses and/or prefixes on MANET
interfaces is necessary in a number of deployment scenarios. This interfaces is necessary in a number of deployment scenarios. This
section outlines the different categories of scenarios that are section outlines the different categories of scenarios that are
considered. considered.
3.1. Standalone MANET 3.1. Standalone MANET
Standalone MANETs are not connected to any external network: all Standalone MANETs are not connected to any external network: all
traffic is generated by MANET nodes and destined to nodes in the same traffic is generated by routers and hosts in the MANET and destined
MANET. to routers or hosts in the same MANET.
Routers joining a standalone MANET may either have (i) no previous Routers joining a standalone MANET may either have (i) no previous
configuration, or (ii) pre-configured local or global IP addresses configuration, or (ii) pre-configured local or global IP addresses
(or prefixes). Due to potential network partitions and mergers, (or prefixes). Due to potential network partitions and mergers,
standalone MANETs may be composed of routers of either either types. standalone MANETs may be composed of routers of either types.
Typical instances of this scenario include private or temporary Typical instances of this scenario include private or temporary
networks, set-up in areas where neither wireless coverage nor network networks, set-up in areas where neither wireless coverage nor network
infrastructure exist (e.g. emergency networks for disaster recovery, infrastructure exist (e.g. emergency networks for disaster recovery,
or conference-room networks). or conference-room networks).
3.2. Connected MANET 3.2. Connected MANET
Connected MANETs have, contrary to standalone MANETs, connectivity to Connected MANETs have, contrary to standalone MANETs, connectivity to
one or more external networks, typically the Internet, by means of one or more external networks (leaf networks, or other networks that
one or more MBR (Manet Border Router, see [2]). MANET routers may provide Internet connectivity) by means of one or more MANET border
generate traffic destined to remote hosts accross these external router [2]. MANET routers may generate traffic destined to remote
networks, as well as to destination inside the MANET. hosts across these external networks, as well as to destination
inside the MANET.
Again, routers joining a connected MANET may either (i) have no Again, routers joining a connected MANET may either (i) have no
previous configuration, or (i) already own pre-configured local or previous configuration, or (ii) already own pre-configured local or
global IP addresses (or prefixes). global IP addresses (or prefixes).
Typical instances of this scenario include public wireless networks Typical instances of this scenario include public wireless networks
of scattered fixed WLAN Access Points participating in a MANET of of scattered fixed WLAN Access Points participating in a MANET of
mobile users, and acting as MBRs. Another example of such a scenario mobile users, and acting as MANET border routers. Another example of
is coverage extension of a fixed wide-area wireless network, where such a scenario is coverage extension of a fixed wide-area wireless
one or more mobile routers in the MANET are connected to the Internet network, where one or more mobile routers in the MANET are connected
through technologies such as UMTS or WiMAX. to the Internet through technologies such as UMTS or WiMAX.
3.3. Deployment Scenarios Selection 3.3. Deployment Scenarios Selection
Both "Standalone MANET" scenario and "Connected MANET" scenarii are Both "Standalone MANET" and "Connected MANET" scenarios are to be
to be addressed by solutions for MANET autoconfiguration. addressed by solutions for MANET autoconfiguration. Note that
solutions should also aim at addressing cases where a MANET transits
from one scenario to an other.
4. Problem Statement 4. Problem Statement
This section details the goals of MANET autoconfiguration, and This section details the goals of MANET autoconfiguration, and
highlights the shortcomings of existing autoconfiguration solutions. highlights the shortcomings of existing autoconfiguration protocols.
A taxonomy of autoconfiguration issues on MANETs is then elaborated. A taxonomy of autoconfiguration issues on MANETs is then elaborated.
4.1. MANET Autoconfiguration Goals 4.1. MANET Autoconfiguration Goals
A MANET router needs to configure an IPv6 prefix(es) on its host A MANET router needs to configure IP addresses and/or prefixes on its
interface and/or an IPv6 address on its loopback interface. Besides, non-MANET interfaces. In addition, it needs to configure a link
it needs to configure a /128 and/or a link local address on its MANET local address, a /128 and/or an MLA on its MANET interface. A MANET
interface. A MANET router may also configure a prefix shorter than router may also configure a IP prefix shorter than /128 on its MANET
/128 on its MANET interface provided prefix uniqueness is guaranteed interface, provided prefix uniqueness is guaranteed [2].
[2].
The primary goal of MANET autoconfiguration is thus to provide The primary goal of MANET autoconfiguration is thus to provide
mechanisms for IPv6 prefix allocation and address assignment, that mechanisms for IPv6 prefix allocation and address assignment, that
are suited for mobile ad hoc environments. Note that this task is are suited for mobile ad hoc environments. Note that this task is
namely distinct from that of just vehiculing knowledge about address distinct from that of propagating knowledge about address or prefix
or prefix location such as a routing protocol does (see for example location, as a routing protocol does (see for example [8], [9]), or
[8], [9]), or such as described in [7]. as described in [7].
The mechanisms employed by solutions to be designed must address the The mechanisms employed by solutions to be designed must address the
distributed, multi-hop nature of MANETs [2], and be able to follow distributed, multi-hop nature of MANETs [2], and be able to follow
topology and connectivity changes by (re)configuring addresses and/or topology and connectivity changes by (re)configuring addresses and/or
prefixes accordingly. prefixes accordingly.
Solutions must achieve their task with (i) low overhead, due to 4.2. Existing Protocols' Shortcomings
scarse bandwidth, and (ii) low delay, due to the dynamicity of the
topology. Solutions are designed to work at the network layer and
thus applies to all link types. However, in situations where link-
layer multicast is needed it is possible that on some link types
(e.g. NBMA links), alternative mechanisms or protocols specifying
operation over a particular link type would be required.
Besides the possible use of the well-known IPv6 multicast addresses
defined for neighbor discovery in [3] (e.g. for Duplicate Address
Detection), solutions may also use some addresses defined in [10] for
auto-configuration purposes.
4.2. Existing Solutions' Shortcomings
Traditional dynamic IP address assignment solutions, such as [5], [3] Traditional dynamic IP address assignment protocols, such as [5], [3]
or [4], do not work as-is on MANETs due to these networks' unique or [4], do not work as-is on MANETs due to these networks' unique
properties. This section overviews the shortcomings of these properties. This section overviews the shortcomings of these
solutions in mobile ad hoc environments. solutions in mobile ad hoc environments.
4.2.1. Lack of Multi-hop Support 4.2.1. Lack of Multi-hop Support
Traditional solutions assume that a broadcast directly reaches every Traditional solutions assume that a broadcast directly reaches every
router or host on the subnetwork, whereas this generally is not the router or host on the subnetwork, whereas this generally is not the
case in MANETs (see [2]). Some routers in the MANET will typically case in MANETs (see [2]). Some routers in the MANET will typically
assume multihop broadcast, and expect to receive through several assume multihop broadcast, and expect to receive through several
intermediate relayings by peer MANET routers. For example, in Fig. intermediate relayings by peer MANET routers. For example, in Fig.
1, the MANET router MR3 cannot communicate directly with a DHCP 1, the MANET router MR3 cannot communicate directly with a DHCP
server [4] that would be available through an MBR, since the server server [4] that would be available through a MANET border router,
and the MANET router are not located on the same logical link. While since the server and the MANET router are not located on the same
some DHCP extensions (such as the relay-agent [11]) overcome this logical link. While some DHCP extensions (such as the relay-agent
issue in a static network, it is not the case in a dynamic topology, [11]) overcome this issue in a static network, it is not the case in
as explained below. a dynamic topology, as explained below.
----- MR1...MR3 ----- MR1...MR3
/ . / .
+-------------+ +------------+ / . +-------------+ +------------+ / .
| | p2p | MANET |/ . | | p2p | MANET |/ .
| ISP Edge | Link | Border | . | ISP Edge | Link | Border | .
| Router +---------+ Router |\ . | Router +---------+ Router |\ .
| | | (MBR) | \ . | | | | \ .
+-------------+ +------------+ \----- MR2 +-------------+ +------------+ \----- MR2
Fig. 1. Connected MANET router topology. Fig. 1. Connected MANET router topology.
4.2.2. Lack of Dynamic Topology Support 4.2.2. Lack of Dynamic Topology Support
A significant proportion of the routers in the MANET may be mobile A significant proportion of the routers in the MANET may be mobile
with wireless interface(s), leading to ever changing neighbor sets with wireless interface(s), leading to ever changing neighbor sets
for most MANET routers (see [1]). Therefore, network topology may for most MANET routers (see [1]). Therefore, network topology may
change rather dynamically compared to traditional networks, which change rather dynamically compared to traditional networks, which
invalidates traditional delegation solutions that were developed for invalidates traditional delegation solutions that were developed for
infrastructure-based networks, such as [11], which assume the infrastructure-based networks, such as [11], which do not assume
existence of a permanent hierarchy among devices and the permanent intermittent reachability of configuration server(s), and a
reachability of a configuration server. For instance, in Fig. 1, potentially ever changing hierarchy among devices. For instance, in
even if MR1 would be able to delegate prefixes to MR3 with DHCP [4], Fig. 1, even if MR1 would be able to delegate prefixes to MR3 with
it cannot be assumed that MR1 and MR3 will not move and become unable DHCP [4], it cannot be assumed that MR1 and MR3 will not move and
to communicate directly. become unable to communicate directly.
4.2.3. Lack of Network Merging Support 4.2.3. Lack of Network Merging Support
Network merging is a potential event that was not considered in the Network merging is a potential event that was not considered in the
design of traditional solutions, and that may greatly disrupt the design of traditional solutions, and that may greatly disrupt the
autoconfiguration mechanisms in use (see [2]). Examples of network autoconfiguration mechanisms in use (see [2]). Examples of network
merging related issues include cases where a MANET A may feature merging related issues include cases where a MANET A may feature
routers and hosts that use IP addresses that are locally unique routers and hosts that use IP addresses that are locally unique
within MANET A, but this uniqueness is not guaranteed anymore if within MANET A, but this uniqueness is not guaranteed anymore if
MANET A merges with another MANET B. If address uniqueness is MANET A merges with another MANET B. If address uniqueness is
required within the MANET (see Section 4.3.2), issues arise that were required within the MANET (see Section 4.3.2), issues arise that were
not accounted for in traditional networks and solutions. not accounted for in traditional networks and solutions. For
instance, [5] and [3] test address uniqueness via messages that are
sent to neighbors only, and as such cannot detect the presence of
duplicate addresses configured within the network but located several
hops away. However, since MANETs are generally multi-hop, detection
of duplicate addresses over several hops is a feature that may be
required for MANET interface address assignment (see Section 4.3.2).
4.2.4. Lack of Network Partitionning Support 4.2.4. Lack of Network Partitioning Support
Network partinionning is a potential event that was not considered in Network partitioning is a potential event that was not considered in
the design of traditional solutions, and that may invalidate usual the design of traditional solutions, and that may invalidate usual
autoconfiguration mechanisms (see [2]). Examples of related issues autoconfiguration mechanisms (see [2]). Examples of related issues
include cases such as a standalone MANET, whereby connection to the include cases such as a standalone MANET, whereby connection to the
infrastructure is not available, possibly due to network infrastructure is not available, possibly due to network partitioning
partitnionning and loss of connectivity to an MBR. The MANET must and loss of connectivity to a MANET border router. The MANET must
thus function without traditional server availability. While thus function without traditional address allocation server
stateless protocols such as [5] and [3] could provide IP address availability. While stateless protocols such as [5] and [3] could
configuration (for MANET interfaces, loopback interfaces), these provide IP address configuration (for MANET interfaces, loopback
solutions do not provide any mechanism for allocating "unique interfaces), these solutions do not provide any mechanism for
prefix(es)" to routers in order to enable the configuration of host allocating "unique prefix(es)" to routers in order to enable the
interfaces. Moreover, [5] and [3] test address uniqueness via configuration of host interfaces.
messages that are sent to neighbors only, and as such cannot detect
the presence of duplicate addresses configured within the network but
located several hops away. However, since MANETs are generally
multi-hop, detection of duplicate addresses over several hops is a
feature that is required in most cases of MANET interface address
assignment (see Section 4.3.2).
----- MR1...MR3...MR5 ----- MR1...MR3...MR5
/ . / .
/ . / .
/ . / .
MR4 . MR4 .
\ . \ .
\ . \ .
\----- MR2 \----- MR2
skipping to change at page 9, line 14 skipping to change at page 10, line 5
4.3.1. Address and Prefix Generation 4.3.1. Address and Prefix Generation
The distributed nature of MANETs brings the need for address The distributed nature of MANETs brings the need for address
generation algorithms that are not always based on traditional generation algorithms that are not always based on traditional
"client-server" schemes and hierarchies to provide MANET routers with "client-server" schemes and hierarchies to provide MANET routers with
addresses and prefixes. In addition, the multi-hop aspect of mobile addresses and prefixes. In addition, the multi-hop aspect of mobile
ad hoc networking makes it difficult to totally avoid address and ad hoc networking makes it difficult to totally avoid address and
prefix duplication a priori over all the MANET. prefix duplication a priori over all the MANET.
4.3.2. Address Uniqueness Requirements 4.3.2. Prefix and Address Uniqueness Requirements
If address uniqueness is required within a specific scope, and if the If prefix or address uniqueness is required within a specific scope,
address/prefix generation mechanism in use does not totally avoid and if the address/prefix generation mechanism in use does not
address/prefix duplication, then additional issues arise. This totally avoid address/prefix duplication, then additional issues
section overviews these problems. arise. This section overviews these problems.
Pre-service Issues -- One category of problems due to address Pre-service Issues -- One category of problems due to address or
uniqueness requirements are called pre-service issues. Conceptually, prefix uniqueness requirements are called pre-service issues.
they relate to the fact that before a generated address is assigned Conceptually, they relate to the fact that before a generated address
and used, it should be verified that it will not create an address or prefix is assigned and used, it should be verified that it will
conflict within the specified scope. This is essential in the not create an address conflict within the specified scope. This is
context of routing, where it is desireable to reduce the risks of essential in the context of routing, where it is desireable to reduce
loops due to routing table pollution with duplicate addresses. the risks of loops due to routing table pollution with duplicate
addresses.
In-Service Issues -- Another category of problems due to address In-Service Issues -- Another category of problems due to address and
uniqueness are called in-service issues. They come from the fact prefix uniqueness are called in-service issues. They come from the
that even if an assigned address is currently unique within the fact that even if an assigned address or prefix is currently unique
specified scope, it cannot be ensured that it will indeed remain within the specified scope, it cannot be ensured that it will indeed
unique over time. remain unique over time.
Phenomena such as MANET merging and MANET partitionning can bring the Phenomena such as MANET merging and MANET partitioning may bring the
need for checking the uniqueness (within the specified scope) of need for checking the uniqueness (within the specified scope) of
addresses that are already assigned and used, if in-service address addresses or prefixes that are already assigned and used. This need
uniqueness is required. may depend on (i) the probability of address conflicts, (ii) the
amount of the overhead for checking uniqueness of addresses, and
The need for checking uniqueness of addresses that are to be assigned (iii) address/prefix uniqueness requirements from applications.
or already assigned and used may depend on (i) the probability of
address conflicts, (ii) the amount of the overhead for checking
uniqueness of addresses, and (iii) address uniqueness requirements
from applications.
For instance, if (i) is extremely low and (ii) significant, checking For instance, if (i) is extremely low and (ii) significant, checking
uniqueness of addresses may not be used. If on the other hand (i) is uniqueness of addresses and prefixes may not be used. If on the
not extremely low, checking uniqueness of addresses should be used. other hand (i) is not extremely low, checking uniqueness of addresses
In any case, if the application has a hard requirement for address and prefixes should be used. In any case, if the application has a
uniqueness assurance, checking uniqueness of addresses should always hard requirement for address uniqueness assurance, checking
be used, no matter how unlikely is the event of address conflict. uniqueness of addresses and prefixes should always be used, no matter
how unlikely is the event of address conflict.
4.3.3. MANET Border Routers Related Issues 4.3.3. MANET Border Routers Related Issues
Another category of problems concern MBR management. Another category of problems concern MANET border router(s)
management.
MBR Mobility -- Some addresses may be configured by servers available In the case where multiple MANET border routers are available in the
through MBRs that may themselves be mobile and that may therefore MANET, providing access to multiple address configuration servers,
leave the MANET. In this case, global addresses used by routers in specific problems arise. One problem is the way in which global
the MANET may no longer be valid. prefixes are managed within the MANET. If one prefix is used for the
whole MANET, partitioning of the MANET may result in invalid routes
towards MANET routers, over the Internet. On the other hand, the use
of multiple network prefixes guarantees traffic is unambiguously
routed from the hosts/routers in the Internet towards the MANET
border router responsible for one particular prefix. However,
asymmetry in the routers' choice of ingress/egress MANET border
router can lead to non-optimal paths followed by inbound/outbound
data traffic, or to broken connectivity, if egress filtering is being
done.
MBR Multiplicity -- In the case where multiple MBRs are available in When a device changes its MANET border router attachment, some routes
the MANET, providing access to multiple address configuration may be broken, affecting MANET packet forwarding performance and
servers, specific problems arise. One problem is the way in which applications. In a multiple border router / multiple-prefixes MANET,
global prefixes are managed within the MANET. If one prefix is used frequent reconfiguration could cause a large amount of control
for the whole MANET, partitioning of the MANET may invalid routes in signalling (for instance if [5] is used "as-is").
the Internet towards MANET routers. On the other hand, use of
multiple network prefixes guarantees traffic is unambiguously routed
towards the MBR responsible for one particular prefix, but asymmetry
in the routers' choice of ingress/egress MBR can lead to non-optimal
paths followed by inbound/outbound data traffic. When a device
changes its MBR attachment, some routes may be broken, affecting
MANET packet forwarding performance and applications.
IPv6 Specifications -- Additional problems come from issues with 5. Solutions Considerations
current IPv6 specifications. For example, the strict application of
[5] may lead to check every IPv6 unicast address for uniqueness: in a
multiple-MBR / multiple-prefixes MANET, this could bring to a large
amount of control signalling, due to frequent reconfiguration.
Moreover, IPv6 does not currently specify an address scope that is
appropriate to fit the scope of a MANET, which could lead to
undesireable behavior such as MBRs leaking MANET local traffic
outside the MANET.
5. Security Considerations Solutions must achieve their task with (i) low overhead, due to
scarse bandwidth, and (ii) low delay/convergence time, due to the
dynamicity of the topology. The evaluation of such criteria may
depend on the targeted network properties, which include (but are not
limited to) node cardinality, node mobility characteristics, etc.
Solutions are to be designed to work at the network layer and thus to
apply to all link types. However, in situations where link-layer
multicast is needed it is possible that on some link types (e.g.
NBMA links), alternative mechanisms or protocols specifying operation
over a particular link type would be required.
Solutions must interact with existing protocols in a way that
leverages as much as possible appropriate mechanisms that are
deployed. For instance, besides the possible use of the well-known
IPv6 multicast addresses defined for neighbor discovery in [3] (e.g.
for Duplicate Address Detection), solutions may as well use some
addresses defined in [10] for auto-configuration purposes.
Solutions must also take into account the security and trust issues
that are specific to ad hoc networking (see Section 6).
6. Security Considerations
Address configuration in MANET could be prone to security attacks, as Address configuration in MANET could be prone to security attacks, as
in other types of IPv6 networks. Security threats to IPv6 neighbor in other types of IPv6 networks. Security threats to IPv6 neighbor
discovery were discussed in SEND WG and described in [6]: three discovery were discussed in SEND WG and described in [6]: three
different trust models are specified, with varying levels of trust different trust models are specified, with varying levels of trust
among network nodes and routers. Among them, the model by which no among network nodes and routers. Among them, the model by which no
trust exists among nodes is considered most suitable for ad hoc trust exists among nodes may be suitable a priori for most ad hoc
networks, although the other two models may also be applicable in networks. However, the other two models may be applicable in some
some cases, for example when a trust relationship exists between an cases, for example when a trust relationship exists between an
operator and some MANET routers. Although [6] does not explicitly operator and some MANET routers, or between military devices that are
address MANETs, the trust models it provides for ad hoc networks can in the same unit. Although [6] does not explicitly address MANETs,
be valid also in the context of MANET autoconfiguration. the trust models it provides for ad hoc networks can be valid also in
the context of MANET autoconfiguration.
It is worth noting that analysis of [6] is strictly related to It is worth noting that analysis of [6] is strictly related to
Neighbor Discovery, Neighbor Unreachability Detection and Duplicate Neighbor Discovery, Neighbor Unreachability Detection and Duplicate
Address Detection procedures, as defined in [3] and [5]. As Address Detection procedures, as defined in [3] and [5]. As
explained in the present document, current standard procedures cannot explained in the present document, current standard procedures cannot
be used as-is in MANET context to achieve autoconfiguration of MANET be used as-is in MANET context to achieve autoconfiguration of MANET
routers and, therefore, design of new mechanisms can be foreseen. routers and, therefore, design of new mechanisms can be foreseen.
In this case, although security threats and attacks defined in [6] In this case, although security threats and attacks defined in [6]
could also apply in presence of new solutions, additional threats and could also apply in presence of new solutions, additional threats and
attacks could be possible (e.g., non-cooperation in message attacks could be possible (e.g., non-cooperation in message
forwarding in multi-hop communications). Therefore, the security forwarding in multi-hop communications). Therefore, the security
analysis has to be further extended to include threats, specific to analysis has to be further extended to include threats, specific to
multi-hop networks and related to the particular address multi-hop networks and related to the particular address
configuration solution. configuration solution.
General security issues of ad hoc routing protocols' operations are General security issues of ad hoc routing protocols' operations are
not in the scope of MANET autoconfiguration. not in the scope of MANET autoconfiguration.
6. IANA Considerations 7. IANA Considerations
This document does currently not specify IANA considerations. This document does currently not specify IANA considerations.
7. Informative References 8. Informative References
[1] Macker, J. and S. Corson, "MANET Routing Protocol Performance [1] Macker, J. and S. Corson, "MANET Routing Protocol Performance
Issues and Evaluation Considerations", RFC 2501, January 1999. Issues and Evaluation Considerations", RFC 2501, January 1999.
[2] Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc [2] Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc
Network Architecture", ID draft-ietf-autoconf-manetarch, Network Architecture", ID draft-ietf-autoconf-manetarch,
February 2007. February 2007.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IPv6", RFC 2461, December 1998. for IPv6", RFC 2461, December 1998.
skipping to change at page 14, line 8 skipping to change at page 16, line 8
[10] Chakeres, I., "Internet Assigned Numbers Authority (IANA) [10] Chakeres, I., "Internet Assigned Numbers Authority (IANA)
Allocations for the Mobile Ad hoc Networks (MANET) Working Allocations for the Mobile Ad hoc Networks (MANET) Working
Group", ID draft-ietf-manet-iana, May 2007. Group", ID draft-ietf-manet-iana, May 2007.
[11] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, [11] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
2001. 2001.
Contributors Contributors
This document is the result of joint efforts, including those of the This document is the result of joint efforts, including those of the
following contributers, listed in alphabetical order: C. Adjih, T. following contributers, listed in alphabetical order: C. Adjih, C.
Boot, T. Clausen, C. Dearlove, C. Perkins, A. Petrescu, P. Ruiz, P. Bernardos, T. Boot, T. Clausen, C. Dearlove, H. Moustafa, C. Perkins,
Stupar, F. Templin, D. Thaler, K. Weniger. A. Petrescu, P. Ruiz, P. Stupar, F. Templin, D. Thaler, K. Weniger.
Authors' Addresses Authors' Addresses
Emmanuel Baccelli Emmanuel Baccelli
INRIA INRIA
Phone: +33 1 69 33 55 11 Phone: +33 1 69 33 55 11
Email: Emmanuel.Baccelli@inria.fr Email: Emmanuel.Baccelli@inria.fr
Kenichi Mase Kenichi Mase
 End of changes. 49 change blocks. 
174 lines changed or deleted 174 lines changed or added

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