MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.)
Internet-Draft INRIA
Expires: January 25, 2007 K. Mase
Niigata University
S. Ruffino
Telecom Italia
S. Singh
Samsung
July 24, 2006
Address Autoconfiguration for MANET: Terminology and Problem Statement
draft-baccelli-autoconf-statement-00
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 January 25, 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 January 25, 2007 [Page 1]
Internet-Draft MANET Autoconf Problem Statement July 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
3. Deployment Scenarios Selection . . . . . . . . . . . . . . . . 6
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Specific Broacast Characteristics . . . . . . . . . . . . 7
4.2. Dynamic Topology . . . . . . . . . . . . . . . . . . . . . 7
4.3. Locally Unique Addresses, Globally Unique Addresses . . . 8
4.4. Multiple Gateways . . . . . . . . . . . . . . . . . . . . 8
5. Solution Guidelines . . . . . . . . . . . . . . . . . . . . . 9
5.1. Solution Model . . . . . . . . . . . . . . . . . . . . . . 9
5.2. General Requirements . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Baccelli (Ed.), et al. Expires January 25, 2007 [Page 2]
Internet-Draft MANET Autoconf Problem Statement July 2006
1. Introduction
Mobile ad hoc networks (i.e. MANETs, refer to RFC 2501) are networks
composed of mobile devices also called nodes, that communicate over
wireless media, and which dynamically self-organize multi-hop
communication between each other. Each node may generate and
forwards control traffic, and forward user traffic (thus potentially
behaving like a router). Each node may also use the network by
generating user traffic (and thus potentially behaving like a host).
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 node'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 Node - 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 January 25, 2007 [Page 3]
Internet-Draft MANET Autoconf Problem Statement July 2006
Local address - An IP address configured on a MANET node and valid
for communication among MANET nodes that are part of the same ad
hoc network. Nodes MUST NOT communicate with other nodes outside
the MANET using this address.
Global address - An IP address configured on a MANET node and valid
for communication with nodes in the Internet, as well as
internally within the MANET.
Internet gateway - An edge node 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 node
confirms the uniqueness of an address it wishes to configure or
has already configured. A node already equipped with an IP
address participates in DAD in order to protect its IP address
from being used by another node.
Pre-service MANET-DAD - The process verifying that a tentative new
IP address assignment will not create a conflict with other MANET
devices.
In-service MANET-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 node 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 node mobility and/or wireless
link environment.
Baccelli (Ed.), et al. Expires January 25, 2007 [Page 4]
Internet-Draft MANET Autoconf Problem Statement July 2006
2. Deployment Scenarios
Automatic configuration of IP addresses of MANET nodes (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 nodes.
2.1. Standalone MANET
In this kind of scenario, the MANET is not connected to any external
network: all traffic is generated by MANET nodes and destined to
nodes in the same MANET. Nodes 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
nodes.
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 nodes
can generate traffic directed to remote hosts accross the Internet.
As in Section 2.1, nodes 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 nodes in the MANET are connected to the Internet
through technologies such as UMTS or WiMAX.
Baccelli (Ed.), et al. Expires January 25, 2007 [Page 5]
Internet-Draft MANET Autoconf Problem Statement July 2006
3. Deployment Scenarios Selection
TBD
Baccelli (Ed.), et al. Expires January 25, 2007 [Page 6]
Internet-Draft MANET Autoconf Problem Statement July 2006
4. Problem Statement
MANET nodes 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.
4.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 nodes in the MANET will typically be indirectly
connected to the source of the broadcast, through several
intermediate peer mobile ad hoc nodes. In that respect, it is worth
noting that IPv6 does not currently specify an address scope that is
applicable for MANET scope.
4.2. Dynamic Topology
A significant proportion of the nodes in the MANET may be mobile with
wireless interface(s), leading to ever changing neighbors and
neighbor sets for most MANET nodes. 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. For instance, a standalone MANET A may feature
nodes 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 January 25, 2007 [Page 7]
Internet-Draft MANET Autoconf Problem Statement July 2006
4.3. Locally Unique Addresses, Globally Unique Addresses
Moreover, even if a node 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 node must use an IP address
that must be both globally unique, as well as topologically correct,
reflecting it's current location.
4.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 nodes. 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 nodes'
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 January 25, 2007 [Page 8]
Internet-Draft MANET Autoconf Problem Statement July 2006
5. Solution Guidelines
5.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 a diagram (see Fig. 1), that may
serve as conceptual framework of the issues that nodes have to solve.
However, note that solutions do not have to follow this framework.
The purpose of this framework is merely to derive a checklist of
autoconfiguration functionalities, in order to build solutions
taylored for different scenarios.
Basically, with regards to IP addressing, a device may find itself
into the 3 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 node does not
process, generate or forward routing control messages generated by
other devices. At some point, the node 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 in in use in the
MANET, the node does not forward routing control messages
generated by other nodes. In this phase, the node may perform
pre-service MANET-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 MANET-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 MANET-DAD completes without
any address conflict being detected, or if pre-service DAD is not
required, the node should enter the NORMAL phase. Note that if
pre-service MANET-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 MANET-DAD control signalling
reaches only a TTL-limited neighborhood, whereas in the GLOBAL
ADVERTISEMENT phase, pre-service MANET-DAD control signalling
reaches the whole MANET.
Baccelli (Ed.), et al. Expires January 25, 2007 [Page 9]
Internet-Draft MANET Autoconf Problem Statement July 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 MANET-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 MANET-DAD is used and if
the device detects an address conflict that forces it to acquire a
new address to resolve this conflict, the node should return to
the NO ADDRESS phase. Note that the phases in this model are
cyclic, and that a node can pop up in the MANET in any phase. For
instance, a node that beneficiated from appropriate static
preconfiguration may start directly in the NORMAL phase.
(Address generation) (In-service MANET-DAD)
+--------------+ Duplicate address +--------------+
| NO ADDRESS | detected | NORMAL |
+----------| phase |<-------------------| phase |<--+
| +--------------+ +--------------+ |
| ^ |
| | Duplicate address |
|(Tentative) address | detected Address |
| generated +--------+ checked |
| | |
| +--------------------------------------------------------+ |
| | ADVERTISING phase | |
| | | |
| | +--------------+ +-------------+ | |
| | | LOCAL AD. | | GLOBAL AD. | | |
+--->| | phase |----------------->| phase | |---+
| +--------------+ +-------------+ |
+--------------------------------------------------------+
(Pre-service MANET-DAD)
Fig. 1 Generic autoconfiguration phases.
This conceptual framework reveals three specific potential aspects of
the problem, which solutions MUST be designed take into account:
- The (tentative) IP addresses generation and assignment aspect.
- The pre-service DAD aspect, to somehow ensure a reasonalble
belief in the fact that an address about to be assigned does not
Baccelli (Ed.), et al. Expires January 25, 2007 [Page 10]
Internet-Draft MANET Autoconf Problem Statement July 2006
create a conflict.
- The in-service DAD aspect, to deal with conflicts that are
detected between already assigned addresses.
5.2. General Requirements
A solution for IP address autoconfiguration for MANETs is needed for
mobile ad hoc node 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 January 25, 2007 [Page 11]
Internet-Draft MANET Autoconf Problem Statement July 2006
6. 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 nodes 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 nodes 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 January 25, 2007 [Page 12]
Internet-Draft MANET Autoconf Problem Statement July 2006
7. IANA Considerations
This document does currently not specify IANA considerations.
8. References
[1] Macker, J. and S. Corson, "MANET Routing Protocol Performance
Issues and Evaluation Considerations", RFC 2501, January 1999.
[2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IPv6", RFC 2461, December 1998.
[3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6",
RFC 3315, July 2003.
[4] Narten, T. and S. Thomson, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Baccelli (Ed.), et al. Expires January 25, 2007 [Page 13]
Internet-Draft MANET Autoconf Problem Statement July 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 January 25, 2007 [Page 14]
Internet-Draft MANET Autoconf Problem Statement July 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 January 25, 2007 [Page 15]
Internet-Draft MANET Autoconf Problem Statement July 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 January 25, 2007 [Page 16]