MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.)
Internet-Draft INRIA
Expires: April 4, 2007 K. Mase
Niigata University
S. Ruffino
Telecom Italia
S. Singh
Samsung
October 2006
Address Autoconfiguration for MANET: Terminology and Problem Statement
draft-baccelli-autoconf-statement-01
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 April 4, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Traditional dynamic IP address assignment solutions are not adapted
to mobile ad hoc networks. This document elaborates on this problem,
states the need for a new solution, and provides guidelines and
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 1]
Internet-Draft MANET Autoconf Problem Statement October 2006
requirements for its design.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview of the Problem . . . . . . . . . . . . . . . . . 3
1.2. Specification of Requirements . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5
2.1. Standalone MANET . . . . . . . . . . . . . . . . . . . . . 5
2.2. MANET Connected to an External Network . . . . . . . . . . 5
2.3. Deployment Scenarios Selection . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Specific Broacast Characteristics . . . . . . . . . . . . 6
3.2. Dynamic Topology . . . . . . . . . . . . . . . . . . . . . 6
3.3. Locally Unique Addresses, Globally Unique Addresses . . . 7
3.4. Multiple Gateways . . . . . . . . . . . . . . . . . . . . 7
4. Solution Guidelines . . . . . . . . . . . . . . . . . . . . . 8
4.1. Solution Model . . . . . . . . . . . . . . . . . . . . . . 8
4.2. General Requirements . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 2]
Internet-Draft MANET Autoconf Problem Statement October 2006
1. Introduction
Mobile ad hoc networks (i.e. MANETs, refer to RFC 2501) are networks
composed of mobile devices, that communicate over wireless media, and
which dynamically self-organize multi-hop communication between each
other. Each device may generate and forward control traffic, and
forward user traffic (thus potentially behaving like a router). Each
device may also use the network by generating user traffic (and thus
potentially behaving like a host). We will call such devices MANET
routers in the rest of the document.
Some mobile ad hoc network may function regardless of the
availability of a connection to the infrastructure (i.e. the
Internet). More precisely, a MANET may either be disconnected from
the fixed IP infrastructure (then called a standalone MANET), or
connected to the fixed IP infrastructure (through one or more
gateways).
1.1. Overview of the Problem
Prior to participation in IP communication, each router's interface
on a MANET that does not beneficiate from appropriate static
configuration needs to be automatically assigned at least one IP
address, that SHOULD be unique (i) locally, for communication inside
the MANET, or (ii) globally, for communication accross the Internet.
However, standard automatic IP address assignment solutions do not
work "as-is" on MANETs due to ad hoc networks' characteristics, and
new mechanisms are therefore needed. The goal of this document is to
detail these problems, and to provide guidelines and requirements for
solutions to be designed.
1.2. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
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].
1.3. Terminology
In addition to the specific wording described in the previous
section, this document uses the following terminology :
MANET Router - A device with one or more wireless interfaces and
associated IP address(es) which is used by the MANET routing
protocol in use.
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 3]
Internet-Draft MANET Autoconf Problem Statement October 2006
Local address - An IP address configured on a MANET router and valid
for communication among MANET routers that are part of the same ad
hoc network. Routers MUST NOT communicate with other routers
outside the MANET using this address.
Global address - An IP address configured on a MANET router and
valid for communication with routers in the Internet, as well as
internally within the MANET.
Internet gateway - An edge router connected to MANET as well as to
the Internet and capable of providing bidirectional connectivity
between the Internet and MANET . These gateways are expected to
provide topologically correct IPv6 prefixes. Internet gateways
mostly run ad hoc routing protocols, but they can also run
infrastructure network protocols (e.g. OSPF).
Duplicate Address Detection (DAD) - The process by which a router
confirms the uniqueness of an address it wishes to configure or
has already configured. A router already equipped with an IP
address participates in DAD in order to protect its IP address
from being used by another router.
Pre-service DAD - The process verifying that a tentative new IP
address assignment will not create a conflict with other MANET
devices.
In-service DAD - The process of continuously checking that an IP
address already in use has not become duplicated in the MANET.
Standalone MANET - An independent ad hoc network which has no
connectivity, either direct of via Internet gateways, to any other
IP networks such as the Internet.
Network merger - The process by which two or more ad hoc networks,
previously disjoint, get connected. In general, network merger
happens as a consequence of router mobility and/or wireless link
environment.
Network partitioning - The process by which an ad hoc network splits
into two or more disconnected ad hoc networks. In general, this
proccess happens as a consequence of router mobility and/or
wireless link environment.
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 4]
Internet-Draft MANET Autoconf Problem Statement October 2006
2. Deployment Scenarios
Automatic configuration of IP addresses of MANET routers (AUTOCONF)
may be necessary in a number of deployment scenarios. In this
section, we outline the use cases that concern and reveal problems
related to the Autoconfiguration of MANET routers.
2.1. Standalone MANET
In this kind of scenario, the MANET is not connected to any external
network: all traffic is generated by MANET routers and destined to
routers in the same MANET. Routers joining a standalone MANET can
either (i) have no previous configuration, or (ii) already have one
or more MANET local and/or global addresses, statically or
dynamically pre-configured, to be used for IP communication. Due to
partitions and mergers, standalone MANETs can often be composed with
both kinds of routers.
Typical applications 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).
2.2. MANET Connected to an External Network
In this scenario, the MANET is connected to an external network,
(e.g. the Internet), by means of one or more gateways. MANET routers
can generate traffic directed to remote hosts accross the Internet.
As in Section 2.1, routers in a connected MANET could either (i)
already own a global IP address, which could be used for external
traffic, or (ii) have no previous configuration.
Examples include public wireless networks of scattered fixed WLAN
Access Points participating in the MANET of mobile users, and acting
as Internet Gateways. Another example of such a scenario is the
coverage extension of a fixed wide-area wireless network, where one
or more mobile routers in the MANET are connected to the Internet
through technologies such as UMTS or WiMAX.
2.3. Deployment Scenarios Selection
Both the standalone MANET scenario and the connected MANET scenario
are to be addressed by solutions for MANET autoconfiguration.
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 5]
Internet-Draft MANET Autoconf Problem Statement October 2006
3. Problem Statement
MANET routers that do not beneficiate from appropriate static IP
address configuration may need to automatically configure at least
one unique local IPv6 address, in order to enable IP communication
within the MANET.
To communicate with hosts across the Internet, configuration
mechanism may also need to provide one or more global IPv6 addresses.
Internet Gateways typically manage topologically correct IPv6
prefixes that can be used to configure global address. They are
usually managed by an administrative entity (i.e. a network operator
or service provider), however they can also be opportunistic and
unmanaged. Internet Gateways are typically fixed, but may also be
mobile. Their presence in the MANET may be intermittent (the number
of gateways may vary), and thus the availability of an Internet
connection in the MANET may also be intermittent.
3.1. Specific Broacast Characteristics
Traditional dynamic IP address assignment solutions, such as RFC
2462, 3315 and 2461, do not work as-is in MANETs due to these
networks' unique properties, as elaborated in the following sections.
These solutions assume that a broadcast direclty reaches every device
on the network, whereas it is generally not the case in MANETs.
Indeed, some routers in the MANET will typically be indirectly
connected to the source of the broadcast, through several
intermediate peer mobile ad hoc routers (see [2]). In that respect,
it is worth noting that IPv6 does not currently specify an address
scope that is applicable for MANET scope.
3.2. Dynamic Topology
A significant proportion of the routers in the MANET may be mobile
with wireless interface(s), leading to ever changing neighbors and
neighbor sets for most MANET routers. Therefore network topology may
change rather dynamically compared to traditional networks. In
particular, phenomena such as MANET paritionning (i.e. a MANET
separating into two or more disconnected MANETs) and MANET merging
(i.e. two or more disconnected MANETs suddenly being connected) are
potential events that may greatly disrupt the uniqueness of IP
addresses in use (see [2]). For instance, a standalone MANET A may
feature routers that use IP addresses that are locally unique within
MANET A, but this uniqueness is not guaranteed anymore if MANET A
merges at some point with another MANET B.
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 6]
Internet-Draft MANET Autoconf Problem Statement October 2006
3.3. Locally Unique Addresses, Globally Unique Addresses
Moreover, even if a router uses an IP address that is locally unique
within its MANET, this address may not be fit for Internet
communication. Indeed, in order to be able to communicate with
outside the MANET (i.e. the Internet), a router must use an IP
address that must be both globally unique, as well as topologically
correct, reflecting it's current location.
3.4. Multiple Gateways
In the case where multiple gateways are available in the MANET,
specific problems arise. One problem is the way in which global
prefixes are managed within the MANET. If *one* prefix is used for
the whole MANET, partitioning of the MANET may invalid routes in the
Internet towards MANET routers. On the other hand, use of *multiple*
network prefixes guarantees traffic is unambiguously routed towards
the gateway owning one particular prefix, but asymmetry in the
routers' choice of ingress/egress gateway can lead to non-optimal
paths followed by inbound/outbound data traffic. Additional problems
come from issues with current IPv6 specifications. For example, the
strict application of RFC2462 may lead to check every IPv6 unicast
for uniqueness : in a multiple-gateway / multiple-prefixes MANET,
this could bring to a large amount of control signalling, due to
frequent reconfiguration.
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 7]
Internet-Draft MANET Autoconf Problem Statement October 2006
4. Solution Guidelines
4.1. Solution Model
This section proposes a high-level conceptual view of generic MANET
autoconfiguration. The different phases of the autoconfiguration
process are abstracted by means of diagrams (Fig. 1 - 4), that
propose different approaches to the process of autoconfiguration,
which can be applied in different scenarios. The purpose of this
framework is to derive a checklist of autoconfiguration
functionalities, in order to build solutions taylored for different
scenarios.
In the "Full DAD" model, depicted in Fig 1, both in-service and pre-
service DAD aspects are present. Basically, with regards to IP
addressing, a device MAY find itself into any of the three different
phases depicted in Fig 1. :
The NO ADDRESS phase - In this phase a device does not have its own
IP address. It does not participate in user data forwarding. If
a routing protocol is in use in the MANET, the router does not
process, generate or forward routing control messages generated by
other devices. At some point, the router MAY generate a
(tentative) address by means of a given address generation method.
When it generates its address, the device should enter the
ADVERTISING phase.
The ADVERTISING phase - In this phase, a device does not participate
in user data forwarding. If a routing protocol is in use in the
MANET, the router does not forward routing control messages
generated by other routers. In this phase, the router MAY perform
pre-service DAD by means of a given mechanism (for instance by
using specific control signalling, that could be embeded in the ad
hoc routing signalling in use). If pre-service DAD is used, and
the device detects that its tentative address creates a conflict
with other MANET devices, it should re-enters the NO ADDRESS
phase. Else, if pre-service DAD completes without any address
conflict being detected, or if pre-service DAD is not required,
the router should enter the NORMAL phase. Note that if pre-
service DAD is used, the ADVERTISING phase MAY have incremental
substates in order to reduce the risks of routing table pollution
with duplicate addresses. In the LOCAL ADVERTISEMENT phase, pre-
service DAD control signalling reaches only a TTL-limited
neighborhood, whereas in the GLOBAL ADVERTISEMENT phase, pre-
service DAD control signalling reaches the whole MANET.
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 8]
Internet-Draft MANET Autoconf Problem Statement October 2006
The NORMAL phase - In this phase, the device participates in IP
communication normally. If a routing protocol is in use in the
MANET, the device MAY process, generate or forward routing control
messages as specified by the routing protocol in use, and MAY
generate or forward user data. A device in this phase MAY perform
in-service DAD by means of a given mechanism (for instance by
using specific control messages that can be embeded in the routing
control messages). If in-service DAD is used and if the device
detects an address conflict that forces it to acquire a new
address to resolve this conflict, the router should return to the
NO ADDRESS phase. Note that the phases in this model are cyclic,
and that a router can pop up in the MANET in any phase. For
instance, a router that beneficiated from appropriate static
preconfiguration MAY start directly in the NORMAL phase.
(Address generation) (In-service DAD)
Duplicate address
+--------------+ detected +--------------+
| NO ADDRESS |<-------------------| NORMAL |
+----------| phase | | phase |<--+
| +--------------+ +--------------+ |
| ^ |
| | Duplicate address |
|(Tentative) address | detected Address |
| generated +--------+ checked |
| | |
| +--------------------------------------------------------+ |
| | ADVERTISING phase | |
| | | |
| | +--------------+ +-------------+ | |
| | | LOCAL AD. | | GLOBAL AD. | | |
+--->| | phase |----------------->| phase | |---+
| +--------------+ +-------------+ |
+--------------------------------------------------------+
(Pre-service DAD)
Fig. 1 Phases model with full DAD.
This conceptual framework reveals three specific potential aspects of
the MANET autoconfiguration problem:
- The (tentative) IP addresses generation and assignment aspect.
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 9]
Internet-Draft MANET Autoconf Problem Statement October 2006
- The pre-service DAD aspect, to somehow ensure a reasonalble
belief in the fact that an address about to be assigned does not
create a conflict.
- The in-service DAD aspect, to deal with conflicts that are
detected between already assigned addresses.
These distinct aspects MAY be combined in order to build solutions
taylored for different requirements with regards to DAD, as shown in
Fig. 1 - 4.
+--------------+ +--------------+
| NO ADDRESS | | NORMAL |
| phase |------------------->| phase |
+--------------+ address +--------------+
generation
Fig. 2 Phases model without DAD.
Pre-service DAD
+-------------------------------------+
| |
| |
| +--------------+ +---------------+ +--------------+
| | NO ADDRESS | | ADVERTISING | | NORMAL |
+--->| phase |-------->| phase |-------->| phase |
+--------------+ +---------------+ +--------------+
Fig. 3 Phases model without in-service DAD.
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 10]
Internet-Draft MANET Autoconf Problem Statement October 2006
In-service DAD
+----------------------------------------------------------+
| |
| |
| +--------------+ +--------------+ |
| | NO ADDRESS | | NORMAL | |
+--->| phase |------------------>| phase |---+
+--------------+ +--------------+
Fig. 4 Phases model without pre-service DAD.
4.2. General Requirements
A solution for IP address autoconfiguration for MANETs is needed for
mobile ad hoc router to acquire a correct IP address prior to their
full participation in the mobile ad hoc routing protocol(s) in use.
Such a solution must address the distributed, multi-hop nature of
mobile ad hoc networks. Autoconfiguration mechanisms must be able to
follow changes in the MANET and react to gateway connectivity loss,
or to the event of new gateways becoming available, (re)configuring
addresses accordingly. A solution must achieve its task with minimal
overhead, due to scarse bandwidth, and minimal delay, due to the
dynamicity of the topology.
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 11]
Internet-Draft MANET Autoconf Problem Statement October 2006
5. Security Considerations
Address configuration in MANET could be prone to security attacks, as
in other type of IPv6 networks. Security threats to IPv6 neighbor
discovery are discussed in RFC 3756: in particular, analysis includes
trust model and threats for a specific ad hoc network scenario, where
all the routers share a common link (i.e. they are one hop away from
each other, full-meshed connectivity is available). Although the
document does not explicitly address MANETs, where routers can be
multiple hop away from each other, the trust model it provides could
be valid also in the context of AUTOCONF. It is also worth noting
that, in case of MANET connected to the Internet, other threats
defined in RFC3756 could apply here, e.g. attacks involving routers
and DoS attacks on Duplicate Address Detection procedures.
Analysis has to be further extended to include threats, specific to
multi-hop networks and, in particular, related to the address
configuration process: security issues of routing protocol operations
(e.g. how to secure routing protocol messages) are out of scope of
AUTOCONF WG.
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 12]
Internet-Draft MANET Autoconf Problem Statement October 2006
6. IANA Considerations
This document does currently not specify IANA considerations.
7. References
[1] Macker, J. and S. Corson, "MANET Routing Protocol Performance
Issues and Evaluation Considerations", RFC 2501, January 1999.
[2] Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc Network
Architecture", ID draft-chakeres-manet-arch, October 2006.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IPv6", RFC 2461, December 1998.
[4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6",
RFC 3315, July 2003.
[5] Narten, T. and S. Thomson, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 13]
Internet-Draft MANET Autoconf Problem Statement October 2006
Contributors
This document is the result of joint efforts, including those of the
following contributers, listed in alphabetical order: C. Adjih
(INRIA), T. Clausen (Ecole Polytechnique), C. Perkins (Nokia), P.
Ruiz (University of Murcia), P. Stupar (Telecom Italia), D. Thaler
(Microsoft).
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 14]
Internet-Draft MANET Autoconf Problem Statement October 2006
Authors' Addresses
Emmanuel Baccelli
INRIA
Phone: +33 1 69 33 55 11
Email: Emmanuel.Baccelli@inria.fr
Kenichi Mase
Niigata University
Phone: +81 25 262 7446
Email: Mase@ie.niigata-u.ac.jp
Simone Ruffino
Telecom Italia
Phone: +39 011 228 7566
Email: Simone.Ruffino@telecomitalia.it
Shubhranshu Singh
Samsung
Phone: +82 31 280 9569
Email: Shubranshu@gmail.com
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 15]
Internet-Draft MANET Autoconf Problem Statement October 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Baccelli (Ed.), et al. Expires April 4, 2007 [Page 16]