draft-ietf-autoconf-statement-01.txt   draft-ietf-autoconf-statement-02.txt 
MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.) MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.)
Internet-Draft INRIA Internet-Draft INRIA
Expires: February 2, 2008 K. Mase Expires: May 22, 2008 K. Mase
Niigata University Niigata University
S. Ruffino S. Ruffino
Telecom Italia Telecom Italia
S. Singh S. Singh
Samsung Samsung
August 2007 November 19, 2007
Address Autoconfiguration for MANET: Terminology and Problem Statement Address Autoconfiguration for MANET: Terminology and Problem Statement
draft-ietf-autoconf-statement-01 draft-ietf-autoconf-statement-02
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 February 2, 2008. This Internet-Draft will expire on May 22, 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 . . . . . . . . . . . . . . . . . . . . . 6
3.1. Standalone MANET . . . . . . . . . . . . . . . . . . . . . 5 3.1. Connected MANET . . . . . . . . . . . . . . . . . . . . . 6
3.2. Connected MANET . . . . . . . . . . . . . . . . . . . . . 5 3.2. Standalone MANET . . . . . . . . . . . . . . . . . . . . . 6
3.3. Deployment Scenarios Selection . . . . . . . . . . . . . . 5 3.3. Deployment Scenarios Selection . . . . . . . . . . . . . . 6
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
4.1. MANET Autoconfiguration Goals . . . . . . . . . . . . . . 7 4.1. MANET Autoconfiguration Goals . . . . . . . . . . . . . . 7
4.2. Existing Protocols' Shortcomings . . . . . . . . . . . . . 7 4.1.1. Multi-hop Support . . . . . . . . . . . . . . . . . . 7
4.2.1. Lack of Multi-hop Support . . . . . . . . . . . . . . 7 4.1.2. Dynamic Topology Support . . . . . . . . . . . . . . . 8
4.2.2. Lack of Dynamic Topology Support . . . . . . . . . . . 8 4.1.3. Network Merging Support . . . . . . . . . . . . . . . 8
4.2.3. Lack of Network Merging Support . . . . . . . . . . . 8 4.1.4. Network Partitioning Support . . . . . . . . . . . . . 9
4.2.4. Lack of Network Partitioning Support . . . . . . . . . 9 4.2. MANET Autoconfiguration Issues . . . . . . . . . . . . . . 9
4.3. MANET Autoconfiguration Issues . . . . . . . . . . . . . . 9 4.2.1. Address and Prefix Generation . . . . . . . . . . . . 10
4.3.1. Address and Prefix Generation . . . . . . . . . . . . 9 4.2.2. Prefix and Address Uniqueness Requirements . . . . . . 10
4.3.2. Prefix and Address Uniqueness Requirements . . . . . . 10 4.2.3. Internet Configuration Provider Related Issues . . . . 11
4.3.3. MANET Border Routers Related Issues . . . . . . . . . 10
5. Solutions Considerations . . . . . . . . . . . . . . . . . . . 12 5. Solutions Considerations . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Informative References . . . . . . . . . . . . . . . . . . . . 15 8. Informative References . . . . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19
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 [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 [2]. These routers dynamically self-organize and
a routing structure among themselves, regardless of the availability maintain a routing structure among themselves, regardless of the
of a connection to any infrastructure. MANET routers may be mobile availability of a connection to any infrastructure.
and may communicate over symmetric or assymetric wireless links.
They may thus join and leave the MANET at any time. MANET routers may be mobile and may communicate over symmetric or
assymetric wireless links. They may thus join and leave the MANET at
any time, at a rate that can be substantially higher than in usual
networks.
However, prior to participation in IP communication, each MANET However, prior to participation in IP communication, each MANET
router 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, and may also
required to be unique within a given scope, or to be topologically need to be delegated an IP prefix. This address or this prefix may
be required to be unique within a given scope, or to be topologically
appropriate. appropriate.
Standard automatic IPv6 address/prefix assignment solutions [5], [3] Standard automatic IPv6 address assignment and prefix delegation
[4] do not work "as-is" on MANETs due to ad hoc networks' unique solutions [5], [3] [4] do not work "as-is" on MANETs due to ad hoc
characteristics [2], therefore new or modified mechanisms are needed. networks' unique characteristics [2]. Therefore new or modified
This document thus details and categorizes the issues that need to be mechanisms are needed for operation within MANET scope, and this
document thus details and categorizes the issues that need to be
addressed. addressed.
2. Terminology 2. Terminology
This document uses the MANET architecture terminology defined in [2], This document uses the terminology defined in [2], as well as the
as well as the following terms : following terms :
MANET Local address (MLA) - An IP address configured on an interface MANET Local Prefix (MLP) - An IP prefix delegated to a MANET router,
of a router in a MANET and valid for communication inside this consisting in chunks of IP addresses valid for communications
MANET. inside the MANET.
Global address - An IP address configured on a MANET router and MANET Local Address (MLA) - An IP address configured on a MANET
valid for communication with routers in the Internet, as well as interface, and valid for communications inside the MANET.
internally within the MANET.
Standalone MANET - An independent ad hoc network, which does not Global prefix - An IP prefix delegated to a MANET router, consisting
contain a border router through which it is connected to the in chunks of IP addresses valid for communications reaching
Internet. outside the MANET (as well as communications within the MANET).
Global address - An IP address configured on an interface and valid
for communications reaching outside the MANET (as well as
communications within the MANET).
Internet Configuration Provider (ICP) - A router that can provide
other routers requesting configuration with addresses or prefixes
derived from a global prefix.
Connected MANET - A mobile ad hoc network, which contains at least
one ICP.
Standalone MANET - A mobile ad hoc network, which does not contain
any ICP.
Network merger - The process by which two or more previously Network merger - The process by which two or more previously
disjoint ad hoc networks get connected. disjoint ad hoc networks get connected.
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
view to configure an interface. with the purpose of configuring an interface.
Address assignment - The process of configuring a generated address Address assignment - The process of configuring an interface with a
on an interface. given address.
Prefix delegation - The process of providing a router with a set of
contiguous addresses it may manage for the purpose of configuring
interfaces or other routers.
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 within a given scope, and which is unique, assigned at most once within a given scope, and which is unique,
before it is being used. 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, after the address has started 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 on MANET interfaces and
interfaces is necessary in a number of deployment scenarios. This prefix delegation to MANET routers are necessary in a number of
section outlines the different categories of scenarios that are deployment scenarios. This section outlines the different categories
considered. of scenarios that are considered.
3.1. Standalone MANET
Standalone MANETs are not connected to any external network: all
traffic is generated by routers and hosts in the MANET and destined
to routers or hosts in the same MANET.
Routers joining a standalone MANET may either have (i) no previous
configuration, or (ii) pre-configured local or global IP addresses
(or prefixes). Due to potential network partitions and mergers,
standalone MANETs may be composed of routers of either types.
Typical instances of this scenario include private or temporary
networks, set-up in areas where neither wireless coverage nor network
infrastructure exist (e.g. emergency networks for disaster recovery,
or conference-room networks).
3.2. Connected MANET
Connected MANETs have, contrary to standalone MANETs, connectivity to 3.1. Connected MANET
one or more external networks (leaf networks, or other networks that
provide Internet connectivity) by means of one or more MANET border
router [2]. MANET routers may generate traffic destined to remote
hosts across these external networks, as well as to destination
inside the MANET.
Again, routers joining a connected MANET may either (i) have no Connected MANETs are mobile ad hoc networks which contain at least
one ICP, i.e. a router that can provide other routers requesting
configuration with addresses or prefixes derived from a global
prefix. Routers joining a connected MANET may either (i) have no
previous configuration, or (ii) 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 MANET border routers. Another example of mobile users, and acting as MANET border routers. Another example of
such a scenario is coverage extension of a fixed wide-area wireless such a scenario is coverage extension of a fixed wide-area wireless
network, where one or more mobile routers in the MANET are connected network, where one or more mobile routers in the MANET are connected
to the Internet through technologies such as UMTS or WiMAX. to the Internet through technologies such as UMTS or WiMAX.
3.2. Standalone MANET
Standalone MANETs are mobile ad hoc networks which do not contain any
ICP, i.e. which do not contain any router able to provide other
routers requesting configuration with addresses or prefixes derived
from a global prefix. Again, routers joining a standalone MANET may
either have (i) no previous configuration, or (ii) pre-configured
local or global IP addresses (or prefixes). Due to potential network
partitions and mergers, standalone MANETs may be composed of routers
of either types.
Typical instances of this scenario include private or temporary
networks, set-up in areas where neither wireless coverage nor network
infrastructure exist (e.g. emergency networks for disaster recovery,
or conference-room networks).
3.3. Deployment Scenarios Selection 3.3. Deployment Scenarios Selection
Both "Standalone MANET" and "Connected MANET" scenarios are to be Both "Standalone MANET" and "Connected MANET" scenarios are to be
addressed by solutions for MANET autoconfiguration. Note that addressed by solutions for MANET autoconfiguration. Note that
solutions should also aim at addressing cases where a MANET transits solutions should also aim at addressing cases where a MANET transits
from one scenario to an other. 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. A
highlights the shortcomings of existing autoconfiguration protocols. taxonomy of autoconfiguration issues specific to MANETs is then
A taxonomy of autoconfiguration issues on MANETs is then elaborated. elaborated.
4.1. MANET Autoconfiguration Goals 4.1. MANET Autoconfiguration Goals
A MANET router needs to configure IP addresses and/or prefixes on its A MANET router needs to configure IP addresses and prefixes as usual,
non-MANET interfaces. In addition, it needs to configure a link on its non-MANET interfaces as well as its attached hosts and
local address, a /128 and/or an MLA on its MANET interface. A MANET routers, if any. In addition, a MANET router needs to configure at
router may also configure a IP prefix shorter than /128 on its MANET least one IP address on its MANET interface, this being a link local
interface, provided prefix uniqueness is guaranteed [2]. address, an MLA or a global address. A MANET router may also require
a delegated MLP, provided prefix uniqueness is guaranteed [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 delegation and address assignment for
are suited for mobile ad hoc environments. Note that this task is operation on mobile ad hoc networks. Note that this task is distinct
distinct from that of propagating knowledge about address or prefix from that of propagating knowledge about address or prefix location,
location, as a routing protocol does (see for example [8], [9]), or as a routing protocol does (see for example [8], [9]), or as
as described in [7]. 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.
4.2. Existing Protocols' Shortcomings
Traditional dynamic IP address assignment protocols, 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 efficiently (if at all) on MANETs, due to these
properties. This section overviews the shortcomings of these networks' unique properties. The following thus overviews what must
solutions in mobile ad hoc environments. be specifically supported for efficient operation on mobile ad hoc
networks.
4.2.1. Lack of Multi-hop Support 4.1.1. 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 a MANET border router, server [4] that would be available through a MANET border router,
since the server and the MANET router are not located on the same since the server and the MANET router are not located on the same
logical link. While some DHCP extensions (such as the relay-agent logical link. While DHCP can to some extent overcome this issue in a
[11]) overcome this issue in a static network, it is not the case in static network, it is not the case in a dynamic topology, as
a dynamic topology, as explained below. explained below.
----- MR1...MR3 ----- MR1...MR3
/ . / .
+-------------+ +------------+ / . +-------------+ +------------+ / .
| | p2p | MANET |/ . | | p2p | MANET |/ .
| ISP Edge | Link | Border | . | ISP Edge | Link | Border | .
| Router +---------+ Router |\ . | Router +---------+ Router |\ .
| | | | \ . | | | | \ .
+-------------+ +------------+ \----- MR2 +-------------+ +------------+ \----- MR2
Fig. 1. Connected MANET router topology. Fig. 1. Connected MANET router topology.
4.2.2. Lack of Dynamic Topology Support 4.1.2. 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 do not assume infrastructure-based networks, such as [11], which do not assume
intermittent reachability of configuration server(s), and a intermittent reachability of configuration server(s), and a
potentially ever changing hierarchy among devices. For instance, in potentially ever changing hierarchy among devices. For instance, in
Fig. 1, even if MR1 would be able to delegate prefixes to MR3 with Fig. 1, even if MR1 would be able to delegate prefixes to MR3 with
DHCP [4], it cannot be assumed that MR1 and MR3 will not move and DHCP [4], it cannot be assumed that MR1 and MR3 will not move and
become unable to communicate directly. become unable to communicate directly. Moreover, possible frequent
reconfiguration due to intermittent reachability cause [5] to be less
efficient than expected, due to large amounts of control signalling.
4.2.3. Lack of Network Merging Support In particular, supporting multihop dynamic topologies means that even
if some address configuration servers are present somewhere, it
cannot be assumed that they are reachable most of the time, contrary
to usual scenarios. Therefore, reusing "as-is" existing solutions
(for instance [4]) using servers on a MANET would basically imply
that "everyone is a server" in order to ensure server reachability.
This implication is the specificity of MANETs that brings the
requirement for new levels of service distribution, since the
"everyone is a server" approach is essentially not functional.
4.1.3. 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.2.2), issues arise that were
not accounted for in traditional networks and solutions. For not accounted for in traditional networks and solutions. For
instance, [5] and [3] test address uniqueness via messages that are instance, [5] and [3] test address uniqueness via messages that are
sent to neighbors only, and as such cannot detect the presence of sent to neighbors only, and as such cannot detect the presence of
duplicate addresses configured within the network but located several duplicate addresses configured within the network but located several
hops away. However, since MANETs are generally multi-hop, detection hops away. However, since MANETs are generally multi-hop, detection
of duplicate addresses over several hops is a feature that may be of duplicate addresses over several hops is a feature that may be
required for MANET interface address assignment (see Section 4.3.2). required for MANET interface address assignment (see Section 4.2.2).
4.2.4. Lack of Network Partitioning Support 4.1.4. Network Partitioning Support
Network partitioning 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 partitioning infrastructure is not available, possibly due to network partitioning
and loss of connectivity to a MANET border router. The MANET must and loss of connectivity to a MANET border router. The MANET must
thus function without traditional address allocation server thus function without traditional address allocation server
availability. While stateless protocols such as [5] and [3] could availability. While stateless protocols such as [5] and [3] could
provide IP address configuration (for MANET interfaces, loopback provide IP address configuration (for MANET interfaces, loopback
skipping to change at page 9, line 31 skipping to change at page 9, line 39
/ . / .
/ . / .
/ . / .
MR4 . MR4 .
\ . \ .
\ . \ .
\----- MR2 \----- MR2
Fig. 2. Standalone MANET router topology. Fig. 2. Standalone MANET router topology.
4.3. MANET Autoconfiguration Issues 4.2. MANET Autoconfiguration Issues
Taking into account the shortcomings of traditional solutions, this Taking into account the shortcomings of traditional solutions in the
section categorizes general issues with regards to MANET mobile ad hoc context, this section categorizes general issues with
autoconfiguration. regards to MANET autoconfiguration.
4.3.1. Address and Prefix Generation 4.2.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 can complement existing solutions by
"client-server" schemes and hierarchies to provide MANET routers with supporting operation outside "client-server" schemes and without
addresses and prefixes. In addition, the multi-hop aspect of mobile fixed hierarchies to provide routers with appropriate addresses and
ad hoc networking makes it difficult to totally avoid address and prefixes. In addition, the multi-hop aspect of MANETs brings
prefix duplication a priori over all the MANET. specific needs as far as address and prefix uniqueness is concerned,
as detailed below.
4.3.2. Prefix and Address Uniqueness Requirements 4.2.2. Prefix and Address Uniqueness Requirements
If prefix or address uniqueness is required within a specific scope, If prefix or address uniqueness is required within a specific scope,
and if the address/prefix generation mechanism in use does not and if the address/prefix generation mechanism in use does not ensure
totally avoid address/prefix duplication, then additional issues address/prefix uniqueness, then additional issues arise. This
arise. This section overviews these problems. section overviews these problems.
Pre-service Issues -- One category of problems due to address or Pre-service Issues -- Address or prefix uniqueness problems in this
prefix uniqueness requirements are called pre-service issues. category are called pre-service issues. Conceptually, they relate to
Conceptually, they relate to the fact that before a generated address the fact that before a generated address or prefix is assigned and
or prefix is assigned and used, it should be verified that it will used, it should be verified that it will not create an address
not create an address conflict within the specified scope. This is conflict within the specified scope. This is essential in the
essential in the context of routing, where it is desireable to reduce context of routing, where it is desireable to reduce the risks of
the risks of loops due to routing table pollution with duplicate loops due to routing table pollution with duplicate addresses.
addresses.
In-Service Issues -- Another category of problems due to address and In-Service Issues -- Address or prefix uniqueness problems in this
prefix uniqueness are called in-service issues. They come from the category are called in-service issues. They come from the fact that
fact that even if an assigned address or prefix is currently unique even if an assigned address or prefix is currently unique within the
within the specified scope, it cannot be ensured that it will indeed specified scope, it cannot be ensured that it will indeed remain
remain unique over time. unique over time.
Phenomena such as MANET merging and MANET partitioning may 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 or prefixes that are already assigned and used. This need addresses or prefixes that are already assigned and used. This need
may depend on (i) the probability of address conflicts, (ii) the may depend on (i) the probability of address conflicts, (ii) the
amount of the overhead for checking uniqueness of addresses, and amount of the overhead for checking uniqueness of addresses, and
(iii) address/prefix uniqueness requirements from applications. (iii) address/prefix 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, then
uniqueness of addresses and prefixes may not be used. If on the checking pre-service uniqueness of addresses and prefixes may not be
other hand (i) is not extremely low, checking uniqueness of addresses used. If on the other hand (i) is not extremely low, then checking
and prefixes should be used. In any case, if the application has a pre-service and in-service uniqueness of addresses or prefixes may be
hard requirement for address uniqueness assurance, checking required. In any case, if the application has a hard requirement for
uniqueness of addresses and prefixes should always be used, no matter address uniqueness assurance, in-service uniqueness checks of
how unlikely is the event of address conflict. 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.2.3. Internet Configuration Provider Related Issues
Another category of problems concern MANET border router(s) Another category of problems concern the management of Internet
management. configuration providers (ICPs).
In the case where multiple MANET border routers are available in the In the case where multiple ICPs are available in the MANET, providing
MANET, providing access to multiple address configuration servers, access to multiple address configuration servers, specific problems
specific problems arise. One problem is the way in which global arise. One problem is the way in which global prefixes are managed
prefixes are managed within the MANET. If one prefix is used for the within the MANET. If one prefix is used for the whole MANET,
whole MANET, partitioning of the MANET may result in invalid routes partitioning of the MANET may result in invalid routes towards MANET
towards MANET routers, over the Internet. On the other hand, the use routers, over the Internet. On the other hand, the use of multiple
of multiple network prefixes guarantees traffic is unambiguously network prefixes guarantees traffic is unambiguously routed from the
routed from the hosts/routers in the Internet towards the MANET hosts/routers in the Internet towards the border router responsible
border router responsible for one particular prefix. However, for one particular prefix. However, asymmetry in the routers' choice
asymmetry in the routers' choice of ingress/egress MANET border of ingress/egress border router can lead to non-optimal paths
router can lead to non-optimal paths followed by inbound/outbound followed by inbound/outbound data traffic, or to broken connectivity,
data traffic, or to broken connectivity, if egress filtering is being if egress filtering is being done.
done.
When a device changes its MANET border router attachment, some routes When a router changes its ICP affiliation, some routes may be broken,
may be broken, affecting MANET packet forwarding performance and affecting MANET packet forwarding performance and applications. In a
applications. In a multiple border router / multiple-prefixes MANET, multiple border router / multiple-prefixes MANET, frequent
frequent reconfiguration could cause a large amount of control reconfiguration could cause a large amount of control signalling (for
signalling (for instance if [5] is used "as-is"). instance if [5] is used).
5. Solutions Considerations 5. Solutions Considerations
Solutions must achieve their task with (i) low overhead, due to Solutions must achieve their task with (i) low overhead, due to
scarse bandwidth, and (ii) low delay/convergence time, due to the scarse bandwidth, and (ii) low delay/convergence time, due to the
dynamicity of the topology. The evaluation of such criteria may dynamicity of the topology. The evaluation of such criteria may
depend on the targeted network properties, which include (but are not depend on the targeted network properties, which include (but are not
limited to) node cardinality, node mobility characteristics, etc. limited to) node cardinality, node mobility characteristics, etc.
Solutions are to be designed to work at the network layer and thus to 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 apply to all link types. However, in situations where link-layer
multicast is needed it is possible that on some link types (e.g. multicast is needed it is possible that on some link types (e.g.
NBMA links), alternative mechanisms or protocols specifying operation NBMA links), alternative mechanisms or protocols specifying operation
over a particular link type would be required. over a particular link type would be required.
Solutions must interact with existing protocols in a way that Solutions must interact with existing protocols in a way that
leverages as much as possible appropriate mechanisms that are leverages as much as possible appropriate mechanisms that are
deployed. For instance, besides the possible use of the well-known deployed. For instance, besides the possible use of the well-known
IPv6 multicast addresses defined for neighbor discovery in [3] (e.g. IPv6 multicast addresses defined for neighbor discovery in [3] (e.g.
for Duplicate Address Detection), solutions may as well use some for Duplicate Address Detection), solutions may as well use some
addresses defined in [10] for auto-configuration purposes. addresses defined in [10] for auto-configuration purposes. However,
it must be ensured that no modification of existing protocols is to
be required outside of MANET scope.
Solutions must also take into account the security and trust issues Solutions must also take into account the security and trust issues
that are specific to ad hoc networking (see Section 6). that are specific to ad hoc networking (see Section 6).
6. Security Considerations 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
skipping to change at page 15, line 14 skipping to change at page 15, line 14
8. 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., Simpson, W., and H. Soliman,
for IPv6", RFC 2461, December 1998. "Neighbor Discovery for IPv6", RFC 4861, September 2007.
[4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6", Carney, "Dynamic Host Configuration Protocol for IPv6",
RFC 3315, July 2003. RFC 3315, July 2003.
[5] Narten, T. and S. Thomson, "IPv6 Stateless Address [5] Narten, T., Thomson, S., and T. Jinmei, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 4862, September 2007.
[6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[7] Draves, R. and D. Thaler, "Default Router Preferences and More- [7] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", RFC 4191, 2005. Specific Routes", RFC 4191, 2005.
[8] Moy, J., "OSPF version 2", RFC 2328, 1998. [8] Moy, J., "OSPF version 2", RFC 2328, 1998.
[9] Moy, J., Coltun, R., and D. Ferguson, "OSPF for IPv6", [9] Moy, J., Coltun, R., and D. Ferguson, "OSPF for IPv6",
RFC 2740, 1999. RFC 2740, 1999.
[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.
[12] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, 2001.
[13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, 2005.
[14] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, 2005.
[15] Moore, N., "Optimistic Duplicate Address Detection (DAD) for
IPv6", RFC 4429, 2006.
[16] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, 2005.
[17] Thubert, P. and TJ. Kniveton, "Mobile Network Prefix
Delegation", ID draft-ietf-nemo-prefix-delegation, August 2007.
[18] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6",
RFC 3633, 2003.
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, C. following contributers, listed in alphabetical order: C. Adjih, C.
Bernardos, T. Boot, T. Clausen, C. Dearlove, H. Moustafa, C. Perkins, Bernardos, T. Boot, T. Clausen, C. Dearlove, H. Moustafa, C. Perkins,
A. Petrescu, P. Ruiz, P. 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
 End of changes. 51 change blocks. 
164 lines changed or deleted 216 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/