MANET Autoconfiguration (AUTOCONF) C. Bernardos
Internet-Draft M. Calderon
Intended status: Informational UC3M
Expires: May 6, 2009 H. Moustafa
France Telecom
November 2, 2008
Ad-Hoc IP Autoconfiguration Solution Space Analysis
draft-bernardos-autoconf-solution-space-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 6, 2009.
Abstract
This draft aims at analysing the solution space for the ad hoc IP
autoconfiguration problem, based on the problem statement draft and
the MANET architecture draft. Some evaluation considerations, are
also taken into account. This draft classifies, at a generic level,
the solution space of the possible approaches that could be followed
to solve the IPv6 autoconfiguration for MANETs problem. The various
approaches of IPv6 autoconfiguration for MANETs are illustrated, and
the benefits and tradeoffs in different aspects of IPv6
autoconfiguration are explored.
Bernardos, et al. Expires May 6, 2009 [Page 1]
Internet-Draft AUTOCONF Solution Space November 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Issues of IP autoconfiguration in MANETs . . . . . . . . . . . 4
3.1. Additional signalling overhead . . . . . . . . . . . . . . 4
3.2. Increased protocol complexity and processing load . . . . 5
3.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Security considerations . . . . . . . . . . . . . . . . . 5
3.5. Convergence time . . . . . . . . . . . . . . . . . . . . . 5
3.6. Routing protocol dependency . . . . . . . . . . . . . . . 6
3.7. IP address space assignment efficiency . . . . . . . . . . 7
4. IP autoconfiguration solution space analysis . . . . . . . . . 7
4.1. Which entities are involved? . . . . . . . . . . . . . . . 8
4.1.1. MANET Routers (distributed approach) . . . . . . . . . 8
4.1.2. MANET Routers and Border Routers . . . . . . . . . . . 9
4.1.3. MANET Routers and distributed servers . . . . . . . . 9
4.1.4. MANET Routers and centralised server(s)
(centralised approach) . . . . . . . . . . . . . . . . 10
4.2. What type of IP delegation: addresses or prefixes? . . . . 10
4.3. How are IP addresses obtained? . . . . . . . . . . . . . . 11
4.4. How is IP address uniqueness guaranteed? . . . . . . . . . 12
4.4.1. How is address uniqueness detection performed? . . . . 12
4.4.2. When address uniqueness detection is performed:
pre-service and/or in-service? . . . . . . . . . . . . 14
4.4.3. How are address conflicts resolved? . . . . . . . . . 15
4.5. How is signalling performed? . . . . . . . . . . . . . . . 15
4.6. Are existing protocols modified? . . . . . . . . . . . . . 16
4.7. What are the security considerations? . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Bernardos, et al. Expires May 6, 2009 [Page 2]
Internet-Draft AUTOCONF Solution Space November 2008
1. Introduction
Due to the spontaneous nature of mobile ad hoc networks, there is a
need to automatically provide IP configuration for MANET Routers,
allowing them to establish communications. Each MANET Router needs a
local address that can be used for intra-MANET connectivity, and an
external address allowing for Internet connectivity. An IP
autoconfiguration solution should be able to satisfy the self-
deployment requirements of ad hoc networks and should be flexible to
accommodate special features for different ad hoc environments.
However, the dynamic and random characteristics of MANETs, the type
of scenario, and the type of application make it difficult to have
one single standard IP autoconfiguration solution.
Based on the MANET architectural concepts presented in [1], the
autoconf problem statement draft [2] describes the issues that should
be addressed during the development of IP autoconfiguration
solutions. Some evaluation considerations for IP autoconfiguration
solutions are also presented in [3] highlighting some important
behaviours for the different autoconfiguration solutions to help
solution developers during design and to help implementers during the
choice of autoconfiguration mechanisms. A number of proposed
solutions has been made; however, there is no existing classification
or standard for these different proposed solutions. The present
draft aims at providing an analysis of the solutions space for the
current IP autoconfiguration proposed solutions. The draft discusses
the different approaches that an IP autoconfiguration solution could
take, giving a generic level classification for the solution space.
Also, the main key features, benefits and scope for the different IP
autoconfiguration approaches are illustrated.
2. Scenarios
The ad-hoc term is highly overloaded nowadays and it usually
comprises many different network architectures, with disparate
characteristics and requirements. As an example, today we can find
several instances of ad-hoc networks: Mobile Ad-hoc Networks
(MANETs), sensor networks, Vehicular Ad-hoc Networks (VANETs),
Wireless Mesh Networks (WMNs), etc. All of them share their multi-
hop, unmanaged and decentralised nature, but also present very
important differences.
As described in [3], there are many evaluation considerations and
characteristics that a particular IP autoconfiguration mechanism
might present. The requirements that an IP autoconfiguration
solution should meet will greatly depend on the application scenarios
that are considered. Some representative examples of scenario's
Bernardos, et al. Expires May 6, 2009 [Page 3]
Internet-Draft AUTOCONF Solution Space November 2008
characteristics that may have an impact on the adopted IP
autoconfiguration solution include, but are not limited to, the
following:
o Connected vs Standalone MANET. The technical requirements that a
connected MANET scenario imposes on the solution (such as
delegation of global IPv6 addresses/prefixes, MANET Border Router
-- also known as Internet Gateway -- discovery, etc.) differ from
the ones posed by a standalone MANET scenario (only local IPv6
addressing is required). It should also be noticed that a
transition can take place in the connected scenarios, where they
may become standalone scenarios from time to time.
o Node mobility. The mobility of MANET Routers has also a big
impact on the requirements of an IP autoconfiguration solution.
For example, in high dynamic environments, solutions should
present low convergence time values and should not require a high
signalling load in order to deal with MANET topology changes
(e.g., a node joining/leaving the network, partitioning and
merging), since this would limit the applicability or at least the
overall performance of the network.
o Power consumption. An IP autoconfiguration solution for network
deployments composed of battery-limited devices should pay special
attention to energy-related issues, such as signalling and
processing load.
o Network size. Solutions that aimed at supporting the IP
autoconfiguration of large MANETs in terms of number of
participant nodes, should carefully look at issues related to
convergence time, signalling load and scalability.
3. Issues of IP autoconfiguration in MANETs
Although IP autoconfiguration is a necessary step to enable ad-hoc
networks to benefit from IP and Internet connectivity, there are some
tradeoffs -- posed by the different possible approaches that can be
used -- that are worth looking at. This section explores some
general issues that may impact -- e.g., in terms of applicability or
performance -- an IP autoconfiguration mechanism.
3.1. Additional signalling overhead
The nodes involved in performing IP autoconfiguration could require
to exchange additional signalling messages in order to achieve its
goal. The required amount of signalling depends on the particular
solution, but it could range from no overhead at all (e.g., passive
autoconfiguration), local message exchange/piggybacking, to
additional message flooding (that could be limited in scope and/or
optimised). The amount of signalling is likely to increase with the
number of ad-hoc nodes participating in the autoconfiguration
Bernardos, et al. Expires May 6, 2009 [Page 4]
Internet-Draft AUTOCONF Solution Space November 2008
process. Special care should be taken in order to avoid these
overhead scale to unacceptable heights, specially to resource-limited
devices with low power and/or processing capacity.
3.2. Increased protocol complexity and processing load
Due to the multi-hop, unmanaged and decentralised nature that usually
characterise ad-hoc networks, it is expected that IP
autoconfiguration in MANETs will be more complicated than in
infrastructure-based networks using standard IPv6 autoconfiguration
protocols (e.g., RFCs 4861 [4], RFC 4862 [5]). Therefore, nodes
participating in an IP autoconfiguration mechanism would be more
complex than current legacy IPv6 hosts. In addition to this
additional complexity, MANET Routers will likely have to bear an
increased processing load. Again, this increased protocol complexity
and processing load may be overwhelming for certain types of MANET
Routers (e.g., limited devices in terms of power and processing
capacity).
3.3. Scalability
IP autoconfiguration solutions will likely make use of additional
signalling and/or require to keep track of the IP prefixes/address
that are currently being used within the MANET. This may lead to
scalability issues, especially in the case of centralised solutions,
in which a single node (or a reduced set) play a special role in the
IP autoconfiguration process.
3.4. Security considerations
Depending on the particular scenario, it might be possible that MANET
Routers do not belong to the same administrative domain, and
therefore it is not possible to assume the existence of security
associations between participants. For this reason, the security
protection of IP autoconfiguration mechanisms could be harder than
that of standard IPv6 autoconfiguration mechanisms (based for example
on SeND [6]) or it could be accepted that a "weaker" protection is
provided in these environments.
3.5. Convergence time
The convergence time of a MANET Router is the time required to have a
unique IPv6 address since it joins the MANET or a address conflict is
detected (e.g., a duplicated), while the convergence time of the
whole MANET is the time required to have all its nodes configured
with the correct addresses. The convergence time of an IP
autoconfiguration mechanism depends on the MANET scenario and the
application type, and hence can greatly impact the mechanism's
Bernardos, et al. Expires May 6, 2009 [Page 5]
Internet-Draft AUTOCONF Solution Space November 2008
efficiency. Long convergence times may be expected when there is a
sudden large scale change in the structure of the network. On the
other hand, as the density of the network increases and the mobility
decreases, the convergence time may become shorter.
The convergence time can also differ according to the type of the IP
autoconfiguration mechanism. For example, in IP autoconfiguration
mechanisms based on signalling flooding or employing periodic
procedures, the convergence time can highly impact the mechanisms'
scalability, especially for high mobility scenarios. In IP
autoconfiguration mechanisms, in which MANET Routers request IP
addresses firstly for joining the MANET and then whenever needed, the
convergence time has lesser impact on the mechanisms' scalability.
3.6. Routing protocol dependency
IP autoconfiguration mechanisms require special signalling in order
to allow each node to be assigned a usable and unique IP address.
Such signalling constitutes additional overhead, as mentioned in
Section 3.1. Depending on the amount of signalling, which itself
depends on the MANET scenario, the convergence time of IP
autoconfiguration mechanisms and hence their scalability can be
impacted.
Consequently, one approach is to encapsulate the IP autoconfiguration
signalling into the routing protocol messages, where in this case IP
autoconfiguration mechanisms can be either routing protocol dependent
or routing protocol partially dependent. The former necessitates the
existence of a particular routing protocol in order to function,
where the IP autoconfiguration mechanism in this case is considered
to be tailored to a specific routing protocol (for instance,
extending an existing routing protocol to support IP
autoconfiguration). In the latter, the IP autoconfiguration
mechanism needs the routing protocol messages in order to transfer
its signalling, but is adaptive to any existing routing protocol
(especially when there are no special constraints in the IP
autoconfiguration mechanism, for instance, periodic messages
exchange, proactive approach, reactive approach).
On the other hand, IP autoconfiguration mechanisms can be routing
protocol independent, where in such case they do not consider at all
the existence of any particular routing protocol, however they
function in a complete independent manner. Although the
autoconfiguration mechanisms function in an independent manner of the
routing protocol in this case, it may happen that the routing
protocol messages can be used (if a routing protocol is found) for
optimised functioning of autoconfiguration mechanisms.
Bernardos, et al. Expires May 6, 2009 [Page 6]
Internet-Draft AUTOCONF Solution Space November 2008
3.7. IP address space assignment efficiency
IP autoconfiguration mechanisms have different approaches for the IP
address space assignment, which in turn leads to different IP
assignment techniques. One approach is to keep the existing address
space centralised for all MANET Routers. Another approach is to
split the existing IP address space among the MANET Routers. The
first approach can suffer from IP address waste if the information
about addresses' release is not updated frequently by MANET Routers.
Even the process of IP address release synchronisation in this case
can require considerable exchange of messages between MANET Routers
and thus scalability can be impacted, especially for large scale
MANETs scenarios. The second approach is useful in the sense of
being fully distributed; however it can be less efficient in some
MANET scenarios especially those having frequent topology changes,
where some nodes may suffer from address space leak while others may
have address space waste. Consequently, this may impact the
convergence time and hence the scalability of IP autoconfiguration
mechanisms.
A third approach appears to be independent of any address space
assignment, where each node derives its IP address, for instance
using special stateful functions or using its subnet prefix and the
EUI-64 interface address. This approach seems interesting in the
sense of not taking care of any address space assignment process,
however, address uniqueness should be assured and the process of
subnet prefix assignment should not cause much signalling.
4. IP autoconfiguration solution space analysis
There are various different approaches to enable IP autoconfiguration
in ad-hoc networks [7]. In this section, we attempt to analyse the
vast solution space of MANET IP autoconfiguration by asking the
following questions:
1. Which entities are involved?
2. What type of IP delegation: addresses or prefixes?
3. How are IP addresses obtained?
4. How is IP address uniqueness guaranteed?
5. How is signalling performed?
6. What are the security considerations?
Bernardos, et al. Expires May 6, 2009 [Page 7]
Internet-Draft AUTOCONF Solution Space November 2008
7. Are existing protocols modified?
4.1. Which entities are involved?
There are several combinations of entities involved in IP
autoconfiguration process. Below is a list of combinations to be
discussed in the following sub-sections:
o MANET Routers (distributed approach).
o MANET Routers and Border Routers.
o MANET Routers and distributed servers.
o MANET Routers and centralised server(s) (centralised approach).
4.1.1. MANET Routers (distributed approach)
A MANET can be IP autoconfigured in a fully distributed way, without
any nodes having special responsibilities in the IP autoconfiguration
process. In this scenario, the responsibility of the task is shared
among all the participant nodes.
A possible approach is that each MANET Router chooses randomly an IP
address and then checks that there is no address conflict, by asking
the other nodes in the MANET (e.g., [8] follows this approach).
Additionally, the responsibility of detecting conflicts may be
distributed, having all the nodes have the potential to detect
conflicts. This can be done, for example, by analysing incoming
routing protocol messages and looking for inconsistencies [9], [10],
[11].
Some solution assign an IP address pool to every new node that enters
into the MANET and as of that moment, this node has the potential to
split their own IP pool and assign it to another new node [12] [13]
(e.g., all nodes collectively perform the functionality of a DHCP
server).
The main advantage of this distributed approach is that the existence
of a single point of failure is avoided and, therefore, in general
this kind of solution would be more robust and scalable than a
centralised approach. On the other hand, the main concern with this
approach is that the probability of an address conflict to happen is
higher, since there is no server that can assure that two nodes are
not assigned the same address.
Bernardos, et al. Expires May 6, 2009 [Page 8]
Internet-Draft AUTOCONF Solution Space November 2008
4.1.2. MANET Routers and Border Routers
Some solution may involve Border Router(s) (also known as Internet
Gateways) playing an active role in the IP autoconfiguration process
(besides its role of gateways bounding the MANET and providing
connectivity to other routing domains). The most common approach is
that Border Routers (BRs) announce within the MANET the global IPv6
prefixes that can be used by MANET Routers in the configuration of
their IPv6 addresses [14]. MANET Routers would still play an
important role in the IP autoconfiguration process, and may for
example be responsible for the detection and resolution of address
conflicts.
The main concern with this approach is the need for BRs to be
deployed within the MANET. Basically, there are two possibilities:
o BRs are fixed routers in the infrastructure (they do not present
any kind of mobility) that support the attachment of MANET
Routers. There could be several application scenarios in which
assuming such an existence might be difficult or even impossible.
o BRs are special MANET Routers with the ability to connect to a
different routing domain (e.g., an infrastructure-based network
such as the Internet). Due to the node mobility of the MANET, it
could be possible that the network gets partitioned with no BR
available in one or more partitions, making then impossible for
MANET Routers belonging to that partition neither to communicate
to the other routing domain (in case of connected MANETs) nor to
provide with IP autoconfiguration support to new nodes that may
arrive and join the partition (that is, these new nodes will not
be able to configure a valid IP address while there is no BR
reachable within the network). In case of all BRs of a particular
MANET managing the same global IP prefixes, a partition of the
network might result in topologically incorrect configurations
and/or invalid routes towards MANET Routers.
4.1.3. MANET Routers and distributed servers
Alternatively, it may be considered the existence of some special
nodes within the MANET that participate in the IP autoconfiguration
process playing a predominant/special role (leader nodes). These
nodes are responsible for parts of the IP autoconfiguration of some
other MANET Routers [15] (e.g., by issuing Router Advertisements to
nodes within their scope). In some solutions, a hierarchy is
established by these special nodes.
The advantage of this approach is that may be easier to avoid address
conflicts than in a completely distributed approach, because there
exist a set of servers in charge of assigning IP addresses.
Furthermore, the reliability of the solution -- when compared to a
Bernardos, et al. Expires May 6, 2009 [Page 9]
Internet-Draft AUTOCONF Solution Space November 2008
completely centralised solution (described next) -- is improved,
since there is no single point of failure. The main concern with
this approach is the need for a mechanism to elect these leader nodes
and to coordinate/synchronise them (in case this is required). If
the leader node role cannot be played by every node (when requested
to behave as leader node), then only specific ones can do it. In
this case, the same issues pointed out about Border Routers also
apply here.
4.1.4. MANET Routers and centralised server(s) (centralised approach)
In this case, a centralised server is in charge of the whole IP
autoconfiguration process.
Centralised approaches may make use of DHCPv6 [16], for example by
deploying a DHCPv6 server (within the infrastructure -- e.g., in case
of connected MANETS -- or within the MANET itself) and configuring
all MANET Routers as DHCP relays to get to the server when a new node
joins the network [17].
Due to the centralised nature of these solutions (i.e. all the IP
autoconfiguration information is managed and kept in one single
entity), it becomes easier to ensure a correct IP configuration
across the MANET (e.g., no duplicate addresses configured). The main
concerns with this kind of approach are related to scalability and
reliability (the server is a single point of failure). Besides,
support of partitioning and merging becomes more complicated and the
mobility management in general is not easy.
4.2. What type of IP delegation: addresses or prefixes?
One important aspect of an IP autoconfiguration mechanism, that
usually has a very important impact on the mechanism operation, is
the type of IP addressing resources that are delegated to MANET
Routers: addresses or prefixes.
Current MANET architecture model [1] basically defines MANET
participant nodes as MANET Routers. These MANET Routers, besides
having one or more MANET interfaces, may also have non-MANET
interfaces, enabling legacy/non-MANET enabled IPv6 hosts (i.e. hosts
not running a MANET routing protocol) to attach to and obtain
connectivity from a MANET Router. In this particular scenario,
allocating IPv6 prefixes to MANET Routers appears as an important
feature to be provided. Most of the first proposals for IP
autoconfiguration mechanisms only tackled the address delegation
problem, whereas it has been lately when some proposals support also
prefix delegation.
Bernardos, et al. Expires May 6, 2009 [Page 10]
Internet-Draft AUTOCONF Solution Space November 2008
It is usually harder to check prefix uniqueness within a MANET than
address uniqueness. Because of that, the most straightforward
approach to provide prefix allocation is to do it in such a way that
it is not needed to perform a prefix duplication check. Some ways of
doing that is by using a centralised mechanism (for example, based on
DHCPv6 [17]) or by using a generation/delegation approach that
guarantees the prefix uniqueness before-hand.
4.3. How are IP addresses obtained?
This is an important question, since the way an IP address/prefix is
obtained may also have an impact on other questions, for example
those related to the uniqueness of this address/prefix within the
MANET.
One of the goals that IP autoconfiguration mechanisms try to achieve
is the efficient provision of valid IP addresses to nodes, requiring
as less time as possible. In IPv6, there are several mechanisms
currently defined for infrastructure-based networks, and they can be
classified basically into two main groups, depending on how the IP
address is obtained: a) the IP address is locally selected by the
node (stateless autoconfiguration [5]), or b) the IP address is
assigned by a DHCPv6 [16] server (stateful autoconfiguration).
Additionally, the node is responsible for checking that the obtained
candidate IP address is not being used in the subnet. To do that, a
mechanism, called Duplicate Address Detection (DAD), has been also
standardised [5].
Some of the autoconfiguration mechanisms used by non-MANET IPv6 nodes
to choose/generate an IP address can also be considered for the MANET
scenario. For example, a MANET Router may generate its addresses
based on the EUI-64 mechanism [5]. This approach has two main
advantages: by re-using the same solution that has been defined for
IPv6 infrastructure-based networks, the implementation of the
mechanism becomes easier. Additionally, the EUI-64 procedure
provides certain guarantees on the global uniqueness of the generated
IPv6 address (basically, if the IEEE MAC addresses were globally
unique -- which is almost true in most cases -- the EUI-64 generated
IPv6 addresses would be globally unique).
An alternative approach, used by several ad-hoc IP autoconfiguration
mechanisms (e.g., [8]), consists in generating a random IPv6 address
out of a known prefix. This solution has the advantage of being
quite simple, but special care should be taken in the implementation
of the random generator, since a bad/limited one may lead to
different nodes choosing the same IPv6 addresses. This could be an
issue in resource-limited devices, where the implementation of a good
random number generator could be hard/difficult.
Bernardos, et al. Expires May 6, 2009 [Page 11]
Internet-Draft AUTOCONF Solution Space November 2008
Other solutions may make use of address pools, from which nodes may
take IP addresses from. These pools can also be distributed within
the ad-hoc network -- for example, hierarchically, by using a binary
split approach [12] -- providing also certain address uniqueness
guarantees. On the other hand, the management of these address pools
may be complicated, especially in environments that present high
mobility patterns.
Alternative ways of IP address generation can also be considered, for
example those that embed certain information on the IP address. This
is the case for example of the Cryptographic Generated Address (CGAs)
[18], for which the interface identifier is generated by computing a
cryptographic one-way hash function from the node's public key and
the IPv6 prefix (among other additional information).
An additional aspect that might be also worthwhile being tackled is
the address space distribution within the MANET (already briefly
discussed when we described the address pool distribution).
Basically, in IPv6 infrastructure-based networks, nodes are attached
to subnets, where all the attached nodes share the same prefix(es).
In ad-hoc networks, given its multi-hop nature, this is not the only
model that can be considered (that is, all the MANET Routers within a
MANET configuring their IPv6 addresses from the same prefix). We may
consider for example the distribution of different IPv6 prefixes
within the MANET, so different MANET Routers may configure addresses
from disjoint IPv6 prefixes. How these prefixes are distributed may
be based on different aspects, such as the geographic location of the
node, its relative position and distance from a MANET Border Router,
its position within a particular hierarchy, etc. The extreme case of
this prefix distribution approach is the delegation of a different
IPv6 prefix per MANET Router.
4.4. How is IP address uniqueness guaranteed?
This question actually encompasses the three different important
ones, to be discussed in the following sub-sections:
o How is address uniqueness detection performed?
o When address uniqueness detection is performed: pre-service and/or
in-service?
o How are address conflicts resolved?
4.4.1. How is address uniqueness detection performed?
It should be noted that a Non-unique Address Detection mechanism is
not always needed, since some methods of obtaining/generating
Bernardos, et al. Expires May 6, 2009 [Page 12]
Internet-Draft AUTOCONF Solution Space November 2008
addresses (see section Section 4.3) ensure the uniqueness of the
assigned addresses/prefixes. This is the case when a centralised
approach is followed (e.g., a DHCPv6 server) which keeps an up-to-
date list of assigned/available addresses, or when a set of
coordinated servers is deployed -- collectively perform the DHCP
functionality --. For example, a new MANET Router may take IP
addresses from a set of address pools (a disjoint set of available IP
addresses) distributed within the ad-hoc network -- for example,
hierarchically, by using a binary split approach [13] -- and nodes
owning a pool which collectively perform the DHCP functionality, are
somehow coordinated to assure the pools are collision-free.
Additionally, there exist some methods of address generation which
ensure the uniqueness of assigned addresses (e.g., a special type of
function is used to generate a series of random numbers -- IPv6
addresses -- [19]).
On the other hand, some methods of obtaining/generating addresses do
not ensure the uniqueness of the assigned addresses/prefixes (e.g.,
each MANET Router generates a random IPv6 address out of a known
prefix [8]). In these cases, mechanisms to detect and resolve
address conflicts are needed.
A first approach to detect address conflicts is to check that the
tentative address (e.g., randomly chosen) is not being used by
another node in the network. A first possibility is that each MANET
Router, before using a tentative address, floods an Address Request
message [8] in the network to query for the usage of this address.
The node waits for a while after sending this query for the reception
of a reply. The process is repeated if no answer is received, and if
after a number of attempts no reply has been received, the node
assumes that the tentatively chosen IPv6 address is unique and starts
using it. A main concern with this approach is its scalability which
is strongly correlated with the organisation of the network, i.e. a
flat structure, or a hierarchical one. If the former case, every
address acquisition results in extra traffic throughout the whole
network; however, only group leaders/representatives need to take
action in the latter case [15]. Additionally, this approach is not
applicable in networks where message delays cannot be bounded (e.g.,
the use of timeouts cannot reliably detect absence of a message).
Another possibility is that before choosing a tentative address a
positive acknowledgement (ACK) is required from all known nodes in
the network [20]. This approach requires each MANET Router to
maintain an up-to-date list of all the nodes in the network. This
list can additionally be used to detect partitions in the network
(e.g., if a set of nodes do not reply, it could be due to a
partition). This approach has several significant drawbacks: its
scalability, the cost of updating this list of participants in highly
Bernardos, et al. Expires May 6, 2009 [Page 13]
Internet-Draft AUTOCONF Solution Space November 2008
dynamic scenarios, and it is not applicable in networks where message
delays cannot be bounded -- which is a likely occurrence in dynamic
ad hoc networks -- because of its use of timeouts (e.g., the absence
of a message could be misinterpreted as a partition).
Another plausible approach is to relax the requirement of avoiding
duplicate addresses and focus on preventing a packet from being
routed to a wrong destination even if an address conflict exists
[21]. For example, a unique per MANET Router key is included in the
routing control packets and in the routing table entries. So, every
node is identified by a unique tuple <address, key> (e.g., virtual IP
address). Following this approach, even if two nodes happen to have
chosen the same IP address, they can still be identified by the use
of their unique keys. The main concern with this approach is that it
implies to modify current routing protocols.
Another way of addressing the detection of duplicate addresses events
is looking for the consequences/results of a potential address
conflict. This can be accomplished passively by continuously
monitoring routing protocol traffic (e.g., looking for
inconsistencies) [9]. The basic idea of this approach is to exploit
the fact that some protocol events occur in case of duplicate
address, but (almost) never in case of a unique address. Most of the
existing solutions following this approach work with proactive
routing protocols (i.e. OLSR) but it can also be applied to on-
demand routing protocols [10]. The main advantages of this approach
are that it can work with current routing protocols (e.g., without
any modifications) and it does not introduce any extra overhead to
perform address uniqueness detection. On the other hand, the time
needed to detect conflicts may be high and during this time a MANET
Router may be experiencing deficiencies in their communications.
4.4.2. When address uniqueness detection is performed: pre-service
and/or in-service?
Address uniqueness detection may be needed at different times of the
communication. A first situation is when a MANET Router has just
chosen a tentative address and, before assigning it to the interface
and using it, it is checked that there is not an address conflict
(i.e. pre-service detection).
Additionally address conflicts may occur at any time, mainly caused
by mergers and partitions in the MANET. It may happen that nodes in
different networks/partitions may independently obtain the same
address, and duplicate addresses result if these networks merge
later. Thus, the address uniqueness detection may be needed to take
place in a continuous manner during the whole life of the MANET (in-
service detection) [2].
Bernardos, et al. Expires May 6, 2009 [Page 14]
Internet-Draft AUTOCONF Solution Space November 2008
Generally speaking, address uniqueness detection approaches commented
above could be used both as pre-service and as in-service mechanisms
[15] [21] [22]. Nevertheless, some of them seem to be more
appropriate for just one of the situations (pre-service or in-
service). For instance, querying the rest of MANET Routers to check
whether an IP address is available or not, seems to be more
acceptable in the case of pre-service detection (e.g., flooding is
not repeated periodically over the time). In general the overhead
introduced by the mechanism is going to be a more critical issue in
the case of in-service than in the case of pre-service detection.
So, approaches that analyse routing protocol messages looking for
inconsistencies (e.g., [21]) or uniquely identify nodes in routing
protocol messages (e.g., [19]) without adding extra messages seem to
be more suitable for the case of in-service detection.
4.4.3. How are address conflicts resolved?
Whenever an address conflict is detected the most common approach is
to use a heuristic to decide which MANET Router keeps on using the
duplicated address and which one has to look for a new IP address.
In the case of pre-service detection the solution is quite
straightforward the newcomer (e.g., trying to use an already-assigned
address) has to look for a new address. However if the conflict has
been caused by a merging (in-service detection) different heuristic
can be used (e.g., the node that detects the conflict keeps on using
the duplicated address [22]).
An interesting issue to be addressed is what happens in the event of
an address conflict while the node has an ongoing session. Session
continuity should be guaranteed after an address duplication episode.
One possible way of ensuring session continuity is IP tunnelling data
packets to the new assigned address (e.g., The MANET Router, keeping
on using the duplicated address, tunnels packets to the other MANET
Router [22]).
4.5. How is signalling performed?
In general, the IP configuration mechanism requires some extra
signalling -- additional to the signalling introduced by the ad-hoc
routing -- in order to reach its goal. The ways signalling is
performed may have an impact on the scalability and convergence time
of the IP autoconfiguration mechanism.
This extra signalling may be sent as separate messages or may be
added/piggybacked to existing routing protocol messages (e.g., prefix
or Border Router Information). The size of this added overhead and
its periodicity may vary on the different solutions. The main
concern of adding/piggybacking signalling information to the existing
Bernardos, et al. Expires May 6, 2009 [Page 15]
Internet-Draft AUTOCONF Solution Space November 2008
routing protocol messages is that the IP autoconfiguration mechanism
is routing protocol dependant (see Section 4.6). On the other hand,
the main advantages of this approach are that the IP
autoconfiguration mechanism may somehow take advantage of the routing
discovery phase of the ad-hoc routing protocol (e.g., discovering of
available prefix and border routers) and do not introduce extra
messages (e.g., MANET Routers have to process less messages).
Flooding the MANET with signalling messages is required by some
mechanisms, for example asking for the approval of the rest of the
nodes with each new address acquisition. There exist different ways
of decreasing the effects of flooding such as limiting the scope, for
example organisging the network in a hierarchical structure, where
only group leaders need to take action with each new address
acquisition.
An alternative approach consists on relying -- partially or totally
-- on ad-hoc routing signalling to perform IP autoconfiguration. An
example of this approach is passive address uniqueness detection [15]
where conflicts are identified by analysing received routing protocol
messages and detecting inconsistencies. The main advantage of this
approach is that no extra signalling is introduced in the network and
the routing protocol is used as-is (e.g., without modifications), on
the other hand this kind of mechanism are routing protocol dependant
(e.g., the mechanism may be quite different for each particular
routing protocol).
4.6. Are existing protocols modified?
IP autoconfiguration mechanisms should function in a compatible
manner to the other underlying protocols; however some of these
protocols can be modified or extended in order to allow the proper IP
autoconfiguration mechanisms' functioning and signalling transfer.
Autoconfiguration mechanisms can extend the IPv6 Neighbour Discovery
Protocol (NDP) to work in multi-hop wireless networks (for instance
extending the NDP router solicitation and advertisement messages), or
employ ICMPv6 messages in a modified manner. Also, some mechanisms
can modify DHCP protocol, allowing MANET Routers to act as modified
DHCP proxies.
As discussed in Section Section 3.6, IP autoconfiguration mechanisms
can use the routing protocol messages to transfer the IP
autoconfiguration signalling. This takes place whether by simply
encapsulating such signalling in routing protocols control messages
with no routing protocols modification, or through adding new control
messages to the routing protocol ones. In the former, IP
autoconfiguration mechanisms are mostly open to any existing routing
protocol, proactive or reactive according to their functioning mode.
Bernardos, et al. Expires May 6, 2009 [Page 16]
Internet-Draft AUTOCONF Solution Space November 2008
While in the latter, IP autoconfiguration mechanisms extend the
functioning of a given routing protocol to support IP
autoconfiguration, which in turn limits their application scope.
4.7. What are the security considerations?
The wireless ad hoc environment attacks can lead to improper
functioning of autoconfiguration mechanisms. Nevertheless, the IP
autoconfiguration mechanisms proposed so far do not propose special
mechanisms to secure the address autoconfiguration process.
Assuring reliable IP autoconfiguration mechanisms' signalling (i.e.
secure transfer) is critical for the proper functionality of any IP
autoconfiguration mechanism. In this sense secure communication
should be assured between MANET Routers, where this problem can be
differently treated according to the approach used by the IP
autoconfiguration mechanism. For IP autoconfiguration mechanisms
depending on the routing protocol, this can be done through securing
the routing protocol (especially, the control messages' transfer).
However, IP autoconfiguration mechanisms that are routing protocol
independent needs special security mechanisms. In spite of the type
of IP autoconfiguration mechanism (routing protocol dependent or
not), cooperation between nodes is an important factor in order to
assure the proper messages' (signalling) forwarding during the
autoconfiguration process.
Generally, security considerations can differ depending on different
MANET scenarios, where connected MANETs allows to have a central
authority that can play the role of a trusted third party to
authenticate MANET Routers for example or provide cryptographic keys.
5. Security Considerations
This draft highlights the security considerations issue during the
analysis of the solution space of MANET IP autoconfiguration; however
no special security mechanisms are given. The autoconfiguration
problem statement draft [2] states some important security issues
that worth considerations. Also, the IP evaluation considerations
draft [3] discusses the issue of trust and security in order to
assure the proper functioning of IP autoconfiguration solutions.
6. IANA Considerations
This document has no actions for IANA.
Bernardos, et al. Expires May 6, 2009 [Page 17]
Internet-Draft AUTOCONF Solution Space November 2008
7. Acknowledgements
The structure and rationale of this I-D has been greatly inspired by
RFC 4889 [23].
The work of Carlos J. Bernardos and Maria Calderon has been partially
supported by the Spanish Government under the POSEIDON (TSI2006-
12507-C03-01) project.
The work of Carlos J. Bernardos and Maria Calderon has also been
partially supported by the EU through the ICT FP7 European Project
CARMEN (INFSO-ICT-214994). Apart from this, the European Commission
has no responsibility for the content of this Internet-Draft. The
information in this document is provided as is and no guarantee or
warranty is given that the information is fit for any particular
purpose. The user thereof uses the information at its sole risk and
liability.
8. References
8.1. Normative References
[1] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc
Network Architecture", draft-ietf-autoconf-manetarch-07 (work
in progress), November 2007.
[2] Baccelli, E., Mase, K., Ruffino, S., and S. Singh, "Address
Autoconfiguration for MANET: Terminology and Problem
Statement", draft-ietf-autoconf-statement-04 (work in
progress), February 2008.
8.2. Informative References
[3] Moustafa, H., Bernardos, C., and M. Calderon, "Evaluation
Considerations for IP Autoconfiguration Mechanisms in MANETs",
draft-bernardos-autoconf-evaluation-considerations-03 (work in
progress), November 2008.
[4] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[5] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address
Autoconfiguration", RFC 4862, September 2007.
[6] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
Bernardos, et al. Expires May 6, 2009 [Page 18]
Internet-Draft AUTOCONF Solution Space November 2008
[7] Bernardos, C., Calderon, M., and H. Moustafa, "Survey of IP
address autoconfiguration mechanisms for MANETs",
draft-bernardos-manet-autoconf-survey-04 (work in progress),
November 2008.
[8] Perkins, C., "IP Address Autoconfiguration for Ad Hoc
Networks", draft-perkins-manet-autoconf-01 (work in progress),
November 2001.
[9] Weniger, K., "PACMAN: Passive autoconfiguration for mobile ad
hoc networks", IEEE Journal on Selected Areas in
Communications, vol. 23, no. 3, Mar 2005 pp. 507-519 , 2005.
[10] Jeong, H., "Passive Duplicate Address Detection for On-demand
Routing Protocols", draft-jeong-autoconf-pdad-on-demand-01
(work in progress), April 2007.
[11] Mase, K. and C. Adjih, "No Overhead Autoconfiguration OLSR",
draft-mase-manet-autoconf-noaolsr-01 (work in progress),
April 2006.
[12] Mohsin, M. and R. Prakash, "IP Address Assignment in a Mobile
Ad Hoc Network", MILCOM 2002 , 2002.
[13] Tayal, A. and L. Patnaik, "An address assignment for the
automatic configuration of mobile ad hoc networks", Personal
Ubiquitous Computing , 2004.
[14] Ruffino, S. and P. Stupar, "Automatic configuration of IPv6
addresses for MANET with multiple gateways (AMG)",
draft-ruffino-manet-autoconf-multigw-03 (work in progress),
June 2006.
[15] Weniger, K. and M. Zitterbart, "IPv6 Autoconfiguration in Large
Scale Mobile Ad-Hoc Networks", European Wireless 2002 , 2002.
[16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[17] Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-autoconf-dhcp-20 (work in progress),
October 2008.
[18] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[19] Zhou, H., Ni, L., and M. Mutka, "Prophet Address Allocation for
Bernardos, et al. Expires May 6, 2009 [Page 19]
Internet-Draft AUTOCONF Solution Space November 2008
Large Scale MANETs", Proceedings of INFOCOM 2003 , 2003.
[20] Nesargi, S. and R. Prakash, "MANETconf: Configuration of hosts
in a mobile ad hoc network", INFOCOM 2002 , 2002.
[21] Vaidya, N., "Weak Duplicate Address Detection in Mobile Ad Hoc
Networks", MOBIHOC'02 , 2002.
[22] Jeong, J., "Ad Hoc IP Address Autoconfiguration",
draft-jeong-adhoc-ip-addr-autoconf-06 (work in progress),
January 2006.
[23] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility
Route Optimization Solution Space Analysis", RFC 4889,
July 2007.
Appendix A. Change Log
Changes from -01 to -02:
o New release to keep the document alive.
o Update of some references.
Changes from -00 to -01:
o New release to keep the document alive.
o Update of some references.
Authors' Addresses
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
Bernardos, et al. Expires May 6, 2009 [Page 20]
Internet-Draft AUTOCONF Solution Space November 2008
Maria Calderon
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 8780
Email: maria@it.uc3m.es
Hassnaa Moustafa
France Telecom
38-40 rue du General Leclerc
Issy Les Moulineaux 92794 Cedex 9
France
Phone: +33 145296389
Email: hassnaa.moustafa@orange-ftgroup.com
Bernardos, et al. Expires May 6, 2009 [Page 21]
Internet-Draft AUTOCONF Solution Space November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Bernardos, et al. Expires May 6, 2009 [Page 22]