MANET Autoconfiguration (AUTOCONF) C. Bernardos
Internet-Draft M. Calderon
Intended status: Informational UC3M
Expires: January 3, 2008 H. Moustafa
France Telecom
July 2, 2007
Survey of IP address autoconfiguration mechanisms for MANETs
draft-bernardos-manet-autoconf-survey-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 January 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Bernardos, et al. Expires January 3, 2008 [Page 1]
Internet-Draft MANET autoconf survey July 2007
Abstract
This Internet Draft aims at providing a general reference for the
AUTOCONF solution space. We present most of the previously proposed
IP AUTOCONF mechanisms in MANETs, classifying them according to a
number of useful criteria, conforming to the AUTOCONF problem
statement draft and the MANET architecture draft. Furthermore, an
analysis of each proposed solution is carried out illustrating its
key characteristics, advantages and correspondence to the
classification criteria.
Bernardos, et al. Expires January 3, 2008 [Page 2]
Internet-Draft MANET autoconf survey July 2007
Table of Contents
1. Introduction and motivation . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Classification Criteria for Existing Autoconfiguration
Contributions in MANETs . . . . . . . . . . . . . . . . . . . 8
4. IP address auto-configuration protocols . . . . . . . . . . . 11
4.1. Solutions for Standalone MANET scenarios . . . . . . . . . 11
4.1.1. No partitioning/merging support . . . . . . . . . . . 11
4.1.1.1. IP address Autoconfiguration for Ad Hoc
Networks (Perkins et al.) . . . . . . . . . . . . 11
4.1.2. Partitioning/merging support . . . . . . . . . . . . . 13
4.1.2.1. IPv6 Autoconfiguration in Large Scale Mobile
Ad-Hoc Networks (Weniger et al.) . . . . . . . . . 13
4.1.2.2. Ad Hoc IP Address Autoconfiguration (Jeong et
al.) . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.2.3. IP Address Assignment in a Mobile Ad Hoc
Network (Mohsin et al.) . . . . . . . . . . . . . 16
4.1.2.4. An Address Assignment for the Automatic
Configuration of Mobile Ad Hoc Networks (Tayal
et al.) . . . . . . . . . . . . . . . . . . . . . 18
4.1.2.5. No Overhead Autoconfiguration OLSR (Mase et
al.) . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2.6. PDAD-OLSR: Passive Duplicate Address Detection
for OLSR (Weniger et al.) . . . . . . . . . . . . 21
4.1.2.7. Passive Duplicate Address Detection for
On-demand Routing Protocols (Jeong et al.) . . . . 23
4.1.2.8. Prophet Address Allocation for Large Scale
MANETs (Zhou et al.) . . . . . . . . . . . . . . . 25
4.2. Solutions for Connected MANET scenarios . . . . . . . . . 27
4.2.1. No partitioning/merging support . . . . . . . . . . . 27
4.2.1.1. Automatic Configuration of IPv6 Addresses for
Nodes in a MANET with Multiple Gateways
(Ruffino et al.) . . . . . . . . . . . . . . . . . 27
4.2.1.2. Simple MANET Address Autoconfiguration
(Clausen et al.) . . . . . . . . . . . . . . . . . 28
4.2.1.3. Extensible MANET Auto-configuration Protocol
(EMAP) (Ros et al.) . . . . . . . . . . . . . . . 30
4.2.1.4. Global Connectivity for IPv6 Mobile Ad Hoc
Networks (Wakikawa et al.) . . . . . . . . . . . . 32
4.2.1.5. Multihop Radio Access Network (MRAN) Protocol
Specification (Hofmann) . . . . . . . . . . . . . 34
4.2.1.6. Automatic IP Address Configuration in VANETs
(Fazio et al.) . . . . . . . . . . . . . . . . . . 37
4.2.2. Partitioning/merging support . . . . . . . . . . . . . 39
4.2.2.1. Address Autoconfiguration in Optimized Link
State Routing Protocol (Adjih et al.) . . . . . . 39
4.2.2.2. Extended Support for Global Connectivity for
Bernardos, et al. Expires January 3, 2008 [Page 3]
Internet-Draft MANET autoconf survey July 2007
IPv6 Mobile Ad Hoc Networks (Cha et al.) . . . . . 41
4.2.2.3. Gateway and Address Autoconfiguration for IPv6
Adhoc Networks (Jelger et al.) . . . . . . . . . . 42
4.2.2.4. MANET Autoconfiguration using DHCP (Templin et
al.) . . . . . . . . . . . . . . . . . . . . . . . 44
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 48
6. Security Considerations . . . . . . . . . . . . . . . . . . . 49
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.1. Normative References . . . . . . . . . . . . . . . . . . . 52
9.2. Informative References . . . . . . . . . . . . . . . . . . 52
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . . . 57
Bernardos, et al. Expires January 3, 2008 [Page 4]
Internet-Draft MANET autoconf survey July 2007
1. Introduction and motivation
Multi-hop communication in ad hoc networks presents some interesting
advantages, where no permanent infrastructure is required. Also, the
coverage area of an existing infrastructure can be extended through
multi-hop ad hoc communication. Several MANET routing protocol
specifications have been developed by the IETF MANET WG. Currently,
ad hoc networks are mostly restricted to the research community and
some experimental testbeds. In order to allow real deployment of ad
hoc networks, in which IP routing is the most candidate approach, IP
configuration of nodes is a strong requirement that need to be
satisfied. In this context, the AUTOCONF WG is working towards
standard specifications and solutions for IP address
autoconfiguration within different MANET environments.
Ad hoc networks present particular characteristics that should be
taken into account when designing address auto-configuration
protocols. These unique characteristics make existing solutions for
IP infrastructure-based networks (e.g., RFCs 2461, 2462, 3315 etc.)
have shortcomings when applied to MANETs. These shortcomings are
stated in [3] and they mainly concern: the lack of multi-hop support,
the lack of dynamic topology support, the lack of network merging
support and the lack of network partitioning support.
The main goal of the AUTOCONF WG is to develop solutions for IPv6
address auto-configuration (both MANET-local and global scoped). The
group has identified two possible scenarios of MANET where IP address
auto-configuration is required [3]:
o Standalone MANETs: these networks are not connected to any
external network. All traffic is generated by MANET nodes and
destined to nodes in the same MANET. Examples of these networks
are conference networks, battlefield networks, surveillance
networks, etc. In this scenario, nodes may join or leave
randomly. Besides, most likely no pre-established nor reliable
address or prefix allocation agency will be present in the
network.
o Connected (also known as hybrid) MANETs. These networks have
connectivity to one or more external networks, typically the
Internet, by means of one or more gateways that are also known as
MBRs (MANET Border Routers). These networks may be connected to
the Internet in permanent fashion or in intermittent fashion.
This draft aims at providing a survey on most of the previously
proposed autoconfiguration mechanisms, trying to provide a general
reference for the solution space and giving useful information for
solutions' developers. In this draft, a classification is also
Bernardos, et al. Expires January 3, 2008 [Page 5]
Internet-Draft MANET autoconf survey July 2007
derived for the different proposed solutions based on different
criteria and a description and analysis are presented for each type
of solution.
The given analysis and classifications conform to the AUTOCONF
problem statement draft [3] and the MANET architecture draft [4].
Bernardos, et al. Expires January 3, 2008 [Page 6]
Internet-Draft MANET autoconf survey July 2007
2. Terminology
This document uses the MANET architecture terminology defined in [4],
the AUTOCONF problem statement terminology defined in [3], as well as
the following terms:
Passive DAD: a set of rather simple algorithms that allows nodes
to detect address conflicts in the network based on routing
protocol anomalies. A specific combination of algorithms is
supposed to detect all conflicts in the network running a specific
routing protocol.
Duplicate address detection (DAD) or MANET DAD: Process used in a
MANET by which a node detects that another station is using the
same address that it has generated. This address may be either
going to be configured on one of the node's interfaces (Pre-
service DAD) or it is already being used by the node (In-service
DAD).
Duplicate address resolution: Process used to solve duplicate
address conflicts.
Bernardos, et al. Expires January 3, 2008 [Page 7]
Internet-Draft MANET autoconf survey July 2007
3. Classification Criteria for Existing Autoconfiguration Contributions
in MANETs
There are some contributions, within the AUTOCONF WG and in the
literature, for automatic IP configurations in ad hoc networks. Some
of these contributions are designated for pure ad hoc scenarios only
considering standalone ad hoc networks. On the other hand, there are
some other contributions designated for hybrid ad hoc networks
scenarios, whether in a permanently connected or intermittently
connected manner. Section 4 discusses most of the existing
contributions, characterising them according to the used approach in
each contribution. As well, an analysis is given for each
contribution taking into consideration the AUTOCONF problem statement
draft [3] as well as the MANET architecture document [4].
The different contributions, discussed in Section 4, are classified
according to a number of criteria related to the used approach in
each contribution as well as the scope of its application. The
defined classification in this draft is based on seven main criteria
and one sub-criteria, which are as follows:
MANET Scenario: this classification criterion concerns the MANET
environment, whether pure MANETs or hybrid MANETs. Pure MANETs
are standalone MANETs which are not connected to any
infrastructure and communication between nodes takes place in a
totally dynamic manner. On the other hand, hybrid MANETs are
connected to an infrastructure network whether in permanent
fashion or intermittent fashion. Some contributions are
designated for standalone MANET scenarios, others are designated
for hybrid MANET scenarios. Solutions designed for hybrid MANET
scenarios also have to deal with the issue of getting global IPv6
addresses, that allow nodes to get Internet connectivity. In
fact, contributions designated for hybrid MANETs can mostly be
general for both types of scenarios.
Gateway involvement: in hybrid scenarios, Internet Gateways
(IGW) / MANET Border Routers (MBR) are considered to provide
the MANET with connectivity to the fixed infrastructure. These
IGWs might also have a role/involvement in the IP address
assignment procedure (e.g., in some solutions, the gateway
might only be responsible of forwarding packets to the
infrastructure, while in other solutions it may also be
involved in the task of providing nodes with addresses/
prefixes).
DAD-based or DAD-free: Duplicate Address Detection (DAD) is the
process used to verify the uniqueness of an IP address within the
MANET. This is a heavy process in MANET IP autoconfiguration,
Bernardos, et al. Expires January 3, 2008 [Page 8]
Internet-Draft MANET autoconf survey July 2007
requiring a considerable number of control messages. Most of the
existing contributions employ a DAD procedure, whether through
developing a DAD mechanism or through using an existing one. Due
to MANETs' merging and separation, the DAD process should take
place in a continuous manner before the IP assignment (In-service
DAD) as well as after the IP assignment (Pre-service DAD) [3].
However, there are some contributions that are DAD-free, which do
not use any DAD mechanism while being capable of assuring the IP
address uniqueness.
Routing Protocol Dependency: any IP autoconfiguration mechanism
requires special signalling and thus control overhead in order to
assign a unique IP address for each MANET node and, in a lot of
cases, to verify the uniqueness of each assigned address.
Consequently, some of the proposed IP autoconfiguration mechanisms
are routing protocols dependent; making use of the ad hoc routing
protocol in transmitting their own signals, especially benefiting
from the routing discovery phase in the ad hoc routing protocol.
In this context, some proposed autoconfiguration mechanisms are
tailored for specific ad hoc routing protocols, i.e. extending
some existing routing protocols to carryout automatic IP address
assignment for mobile nodes. On the other hand, there are some
proposed autoconfiguration mechanisms that are routing protocols
independent.
Distributed/centralised approach: there are different possible
approaches that an IP autoconfiguration protocol might follow to
assign IP addresses to all the nodes of a MANET. One possibility
is to deploy a centralised server that are in charge of the IP
address assignment (e.g., DHCPv6). The opposite approach is not
to make use of any server, but to share the IP address assignment
task among all the participant nodes. Between these two extreme
cases, intermediate approaches can be found, for example those
that deploy several distributed servers within the MANET and
therefore can be considered as distributed solutions in one sense,
while they can also be considered as centralised in a certain
level, since they still make use of servers.
Partitioning/Merging support: a solution supports partitioning/
merging if it is able to detect MANETs' partitioning and merging
and provide mechanisms to avoid IP address conflicts and
connectivity problems in such cases. For example, if two
previously disjoint ad hoc networks get connected, there might be
nodes with duplicated address in the merged network, and therefore
it is needed to make some nodes change the IP addresses they are
using to avoid the conflict (this can be achieved for example by
using in-service DAD). Partitioning support is also important,
specially in hybrid scenarios, in which as a result of a network
Bernardos, et al. Expires January 3, 2008 [Page 9]
Internet-Draft MANET autoconf survey July 2007
split, some nodes of the ad hoc network might loose the
connectivity to the node that they were using as Internet Gateway.
Prefix assignment support: the MANET architecture document [4]
considers nodes of a MANET as routers (MANET Routers) that can
have attached "traditional" hosts, and that therefore need to
acquire IPv6 prefixes instead of just single addresses. Because
of that, it is important to analyse if a particular AUTOCONF
solution supports the assignment of IPv6 prefixes to nodes.
Protocol overhead: an IP address autoconfiguration solution might
require additional control messages to work. This signalling is
considered as protocol overhead that may have a significant impact
on the performance of certain solutions. We classify the protocol
overhead of each solution as follows:
'High': if the IP autoconf solution (not the ad-hoc routing
protocol) requires additional message flooding.
'Medium'/'Low': if the IP address autoconfiguration solution
requires some protocol messages (besides the normal routing
protocol messages) to be exchanged or if it modifies existing
routing protocol messages to add some information (e.g., prefix
or GW information). Depending on the size of the added
information and how often this information is sent, a solution
may be classified as 'medium' or 'low' protocol overhead.
'None': if an IP address autoconfiguration solution does not
require any new autoconf protocol message to be sent, this
solution has no protocol overhead.
In the following section, we provide a description of several
existing AUTOCONF proposals, analysing them from the viewpoint of the
previously defined criteria. In order to present the analysed
solutions in a structured way, two major classification levels are
used: i) standalone/connected, and ii) partitioning/merging support.
Bernardos, et al. Expires January 3, 2008 [Page 10]
Internet-Draft MANET autoconf survey July 2007
4. IP address auto-configuration protocols
In this section we briefly describe some of the existing proposals
for IP address autoconfiguration, classifying them according to the
set of criteria introduced in the previous section.
4.1. Solutions for Standalone MANET scenarios
4.1.1. No partitioning/merging support
4.1.1.1. IP address Autoconfiguration for Ad Hoc Networks (Perkins et
al.)
This address autoconfiguration mechanism -- proposed in [5] --
basically consists in choosing an address randomly from an address
pool (i.e., a network prefix) available to the MANET and then
performing a Duplicate Address Detection procedure within the MANET.
Assumptions: It is assumed that nodes performing this
autoconfiguration protocol obtain a non-link-local prefix (it cannot
be link-local, since the addresses have to be valid over a multiple-
hop distance) from which to configure an address. The method to
obtain a globally routable prefix is not specified in the solution
and, in case it is not possible to obtain any suitable one, a
reserved IPv6 prefix, called MANET_PREFIX, is used: fec0:0:0:
ffff::/64.
Approach description: This solution basically works as follows: a
node first selects a random address from the non-link-local prefix
that is deployed in the MANET and then performs a DAD procedure to
check for its uniqueness across the MANET. To perform this
uniqueness check, the node sends an Address Request (AREQ) message,
including the randomly chosen tentative non-link-local IP address.
This message is broadcast to its neighbours, by sending the message
using the all-nodes multicast IPv6 address as destination of the
packet. The source address used by the node to send the AREQ message
is another temporary IP address, acquired only for the purpose of
sending these messages. This temporary IPv6 address belongs to a
different non-overlapping prefix -- called MANET_INITIAL_PREFIX -- so
the probability of this address to be duplicated in the network is
very low, given its short lifetime (this address is only used in this
message exchange and discarded thereafter). When a node receives an
AREQ message, it creates a reverse route entry for the temporary IPv6
address of the node. If the tentative address contained in the AREQ
message does not match the address of the receiving node, it
rebroadcasts the message to its neighbours. If the IP address of the
receiving node matches the tentative address contained in the AREQ
message it sends an Address Reply (AREP) message to the sender,
Bernardos, et al. Expires January 3, 2008 [Page 11]
Internet-Draft MANET autoconf survey July 2007
indicating that the address is already in use. The route created by
the AREQ messages is used to route the message back to the source
node.
A node waits for a certain amount of time after sending an AREQ
message, for the reception of an AREP message. The process is
repeated if no answer is received, and if after a number of attempts
no AREP has been received, the node assumes that the tentatively
chosen IPv6 address is unique and starts using it. The values
configured for the involved timers and retry parameters have an
impact on the maximum size of the MANET where the solution would
properly work. Additionally, since the DAD procedure is performed
only when the node initially chooses the tentative IPv6 address to
use, this mechanism does not support merging of MANETs.
AREQ and AREP are a modification of the standard ICMPv6 Neighbour
Advertisement and Neighbour Solicitation messages, respectively.
Correspondence to the criteria described in Section 3:
o MANET scenario: the solution targets standalone MANETs, although
it considers the possibility of being applied to connected
scenarios in those cases in which nodes are provided with the non-
link-local prefix to be used in the MANET.
o Routing protocols' dependency: the solution is routing protocol
independent.
o DAD-based: the proposed solution makes use of DAD in the initial
address assignment phase.
o Distributed/centralised approach: the solution does not make use
of any centralised server.
o Partitioning/Merging support: the solution does not support
merging.
o Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
o Protocol overhead: 'high', since the solution requires additional
message flooding (AREQ messages) to verify if an IP address is
being used in the MANET.
Bernardos, et al. Expires January 3, 2008 [Page 12]
Internet-Draft MANET autoconf survey July 2007
4.1.2. Partitioning/merging support
4.1.2.1. IPv6 Autoconfiguration in Large Scale Mobile Ad-Hoc Networks
(Weniger et al.)
The solution described in [6] extends the Neighbour Discovery and
IPv6 Stateless Address Autoconfiguration mechanisms to work in multi-
hop wireless networks.
Assumptions: The solution assumes a hierarchical approach, where
there are two different types of participating nodes: those that
obtain IPv6 addresses by using a modified version of IPv6 Neighbour
Discovery, and special nodes -- called leader nodes --, that are
responsible for parts of the address configuration of other nodes.
Approach description: The solution basically extends IPv6 Neighbour
Discovery to provide nodes within a multi-hop environment with IPv6
address autoconfiguration capabilities. To do so, the following
modifications to the IPv6 Neighbour Discovery protocol are proposed:
o The Neighbour Solicitation message is modified to allow it to be
broadcast to a bounded area of radius r_s hops (instead of only a
single hop). In addition, a new option for Neighbour Discovery is
defined (called MANET option) which contains a Random Source ID
(RS-ID) field, that is used to distinguish different nodes. Nodes
use the all-nodes multicast address instead of the solicited-node
multicast address. This mechanism guarantees link-local addresses
to be unique within the scope (limited by r_s) of each node.
o To enable the configuration of unique site-local addresses, a
hierarchy is established by special nodes (called leader nodes)
that configure a group of nodes by issuing Router Advertisements
(RA) within their scope, containing the subnet ID (i.e., network
prefix) and its link-local address as source address. The subnet
ID has to be unique for each leader node, so MANET-DAD has to be
performed between the leader nodes within the entire Ad hoc
network. An algorithm is provided for the election of leader
nodes.
It should be noted that because of the nature of the solution, it
would be possible to have multihomed nodes -- that is, nodes with
more than one IPv6 address -- if a node is within the scope of more
than one leader node.
Correspondence to the criteria described in Section 3:
o MANET scenario: the solution targets standalone MANETs, although
it could be possible to extend it to support the assignment of
Bernardos, et al. Expires January 3, 2008 [Page 13]
Internet-Draft MANET autoconf survey July 2007
global IPv6 addresses.
o Routing protocols' dependency: the solution is not restricted to
any particular ad-hoc routing protocol, but it may be advantageous
if it follows a hierarchical structure. Besides, it is also
preferable that nodes move in logical groups. Otherwise, the cost
of maintaining the hierarchical structure may be considerable.
o DAD-based: the proposed solution makes use of a periodic DAD for
ensuring the address uniqueness within the scope of the leader
node. Since each leader node makes use of a different Subnet ID,
the uniqueness of the assigned address within the entire MANET is
ensured.
o Distributed/centralised approach: the solution does not make use
of any centralised server, but considers the existence of special
nodes (leader nodes) that participate in the mechanism in a
distributed fashion.
o Partitioning/Merging support: the solution support partitioning/
merging, by leader nodes performing periodic DAD that ensures the
uniqueness of Subnet IDs.
o Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
o Protocol overhead: 'high', since the solution requires additional
message flooding within a bounded area of radius r_s hops.
4.1.2.2. Ad Hoc IP Address Autoconfiguration (Jeong et al.)
The solution described in [7] proposes two DAD mechanisms. The first
one -- strong DAD -- is done in the initial phase when the ad hoc
node does not have an IP address configured yet, it relates to the
fact that before a randomly generated address is assigned and used,
it should be verified that it will not create an address conflict.
On the other hand the second DAD mechanism -- weak DAD -- is always
executed by nodes taking part in ad hoc routing in order to prevent
any address conflicts due to mergers.
Assumptions: The solution assumes that initially a random address is
selected by ad hoc nodes using the reserved IPv6 prefix MANET_PREFIX.
Approach description: This approach includes two different DAD
mechanisms:
o Strong DAD: based on [5]. Strong DAD is done initially after an
ad hoc node has chosen randomly an IP address and it is trying to
Bernardos, et al. Expires January 3, 2008 [Page 14]
Internet-Draft MANET autoconf survey July 2007
find out whether there is a duplication conflict or not. AREQ
message for Strong DAD is broadcast in site-local scoped all node
multicast address, IPV6_MANET_BROADCAST_ADDRESS. The ad hoc node
waits for an AREP message -- indicating the selected address has
already been utilised -- until the timer for Strong DAD expires.
In the case an AREP message arrives it chooses a new address and
executes Strong DAD mechanism again. [7] describes the message
format, using ICMPv6 messages (new types are defined). [8]
describes the message format for AODV.
o Weak DAD: based on [9]. During ad hoc routing, weak DAD is used
to find out whether address duplication, due to merging has
occurred or not. The concept of ``Virtual IP address'', which is
the combination of an ''IP address'' and an ``Key'', is used,
which is selected to be unique by each mobile ad hoc node. This
''key'' is appended to control packets of ad hoc routing protocol,
such as route discovery messages or hello messages. Intermediate
routing points must store the ''key'' value for each address in
its routing table. Using these ''keys'', duplication conflicts
can be found out during ad hoc routing process. An AERR message
is sent during Weak DAD for the purpose of indicating that an
address duplication happened. The ad hoc node that receives an
AERR message should autoconfigure a new IPv6 address through
Strong DAD. The same AERR message is used to inform each peer
node that its address has been changed. In order to keep ongoing
sessions after an address duplication episode, data packets are
sent to the new address through IP tunnelling. The destination
address in outer IP header is the new IP address of the node that
announced duplicate address and the inner IP header contains the
duplicate IP address of the node, i.e. the old address of the
node. The match duplicate address and new address is done in an
Address Mapping Cache.
Correspondence to the criteria described in Section 3:
o MANET scenario: the solution targets standalone MANETs.
o Routing protocols' dependency: the solution is not restricted to
any particular ad-hoc routing protocols.
o DAD-based: the proposed solution makes use of two different DAD
mechanisms.
o Distributed/centralised approach: the solution is distributed. It
does not make use of either any centralised servers or special
nodes.
Bernardos, et al. Expires January 3, 2008 [Page 15]
Internet-Draft MANET autoconf survey July 2007
o Partitioning/Merging support: the solution supports partitioning/
merging by looking for duplicate addresses on an ongoing basis.
o Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
o Protocol overhead: The Strong DAD mechanism introduces a 'high'
protocol overhead since it requires additional message flooding
(AREQ messages) to find out whether there is a duplication
conflict or not. The Weak DAD mechanism introduces a 'medium'
protocol overhead since the Key extension (20 bytes) is appended
to each control packet of the ad hoc routing protocol.
4.1.2.3. IP Address Assignment in a Mobile Ad Hoc Network (Mohsin et
al.)
This proposed solution [10] is based on a dynamic allocation of IP
addresses in MANETs using the concept of binary split. A proactive
approach is used, in the sense that each node can independently
assign a new IP address without consulting any other node in the
network. Partitioning and merging as well as nodes abrupt departures
are supported in this solution.
Assumptions: It is assumed that all nodes collectively perform the
DHCP functionality; where each node is capable of configuring a new
node and providing it with a new IP address. It is also assumed that
one MANET node have the entire pool of IP addresses at the beginning.
Approach description: In this proposed solution the concept of Buddy
Systems is used. This is a type of segregated lists used in memory
allocation and supports efficient splitting and coalescing. In the
context of the proposed solution, binary buddies are used, where all
buddy sizes are a power of two, and each size is divided into two
equal parts. Thus, every node has a disjoint set of IP addresses
that it can assign to a new node without consulting any other node in
the network. When a new unconfigured mobile node (B) joins the
network, it requests the nearest neighbour (A) an IP address. Node
(A) divides its IP address set into two, giving one half to the
requesting node (B). The new node assigns itself an IP address from
the acquired pool of addresses, storing the rest of addresses to
configure other nodes afterwards. The new node (B) is now configured
and is considered as the Buddy of node (A). The scheme of the IP
address assignment can be seen as a handshaking protocol between the
server and the client, where the node requesting the IP address is
considered as the client node and the node that actually assigns the
IP address is considered as the server node.
Nodes synchronise the IP blocks which they store to keep track of the
Bernardos, et al. Expires January 3, 2008 [Page 16]
Internet-Draft MANET autoconf survey July 2007
assigned IP addresses and detect any IP leakage, where every node
keeps a record of all the IP address blocks in the network by
maintaining a corresponding table. Each node sends its IP address
pool to all other nodes in the network, and each node receiving an IP
pool from another node records the received information in its IP
address table. Through this approach, the network has among its
nodes the available IP addresses organised in the form of a binary
tree with a division of two identical blocks (Buddies) per level.
Two mechanisms are proposed for releasing the node's IP address pool
when the node leaves the network: i) graceful leave, in which the
leaving node gives its IP address pool to any nearby node. This
nearby node may keep the IP address pool for itself or may search in
its IP address table the Buddy of the leaving node and forward to it
the IP pool. ii) abrupt leave, in which the node leaves with its IP
address pool that leads to IP leakage. In such a case, a pool of IP
addresses that is not assigned to any node is not available. IP
leakage is detected from the IP address table stored at each node.
Each node scans from time to time its IP address table for the IP
pool of its Buddy node, if it does not find it, it concludes that the
node has left and it merges this missing IP block to itself.
Correspondence to the criteria described in Section 3:
o MANET scenario: This proposed solution targets pure MANETs
scenarios.
o Routing protocols' dependency: This proposed solution is
independent of the underlying routing protocol.
o DAD-based: The proposed solution does not use any DAD mechanism.
o Distributed/Centralised approach: Although this solution is based
on IP address pools assignment and splitting, it has a distributed
approach, where all nodes collectively perform the functionality
of a DHCP server.
o Partitioning/Merging support: Thanks to employing the buddy
systems, the proposed solution supports partitioning and merging.
In case of partitioning, IP addresses that are not used are
detected and released, these may also be appended to other nodes'
IP pools. In case of merging, the process of buddies splitting
allows the merging node to be assigned an IP address and an IP
pool.
o Prefix assignment support: Since the notion of gateways does not
exist in this proposed solution, there is no support for prefixes
assignment.
Bernardos, et al. Expires January 3, 2008 [Page 17]
Internet-Draft MANET autoconf survey July 2007
o Protocol overhead: 'high', since the solution requires a kind of
flooding so that each node sends its IP address block to all other
nodes in the network. Furthermore, other control messages are
required in the form of request-reply messages to enable a new
joining node to be assigned an IP address, or in the form of
announcement in the case of IP release.
4.1.2.4. An Address Assignment for the Automatic Configuration of
Mobile Ad Hoc Networks (Tayal et al.)
The solution described in [11] is very similar to the previous one
([10]), sharing the idea (also used by others) of nodes assignment of
half of their address pools to newly arrived nodes that request IP
addresses.
Assumptions: It is assumed that initially there is one node that
configures itself as initiator node (when there is no other node in
the network), configuring itself with a default IP address and
starting to manage a default address pool.
Approach description: The solution basically works as follows: when a
new node i (called requester node) is willing to join the MANET, it
has to contact an existing node j in the network. If node j has the
address pool, it divides it into two parts and allocates one part to
node i. The starting address of the allocated pool is the address of
node i. In case node j does not have the address pool, j starts
searching for nodes that might have an address pool, by broadcasting
a message (called SEARCH_ADDR). The search message is forwarded by
all the nodes which do not have an address pool. A node receiving
the search message, either replies with the address pool or with
negative ACK. If a node replies with its address pool, it marks half
of its addresses as under allocation and wait for a POOL_ACCEPTED
message from node j. Node j replies with POOL_ACCEPTED message to
the node whose address pool it received first, and allocates the
received address pool to node i.
This solution defines mechanisms to handle different scenarios, such
as network partitioning and merging, message loss, etc. More details
can be found in [11].
Correspondence to the criteria described in Section 3:
o MANET scenario: This proposed solution targets standalone
scenarios.
o Routing protocols' dependency: This proposed solution is
independent of the underlying routing protocol.
Bernardos, et al. Expires January 3, 2008 [Page 18]
Internet-Draft MANET autoconf survey July 2007
o DAD-based: The proposed solution does not use any DAD mechanism,
since the uniqueness of the solution is based on the split of the
initially available IP address pool.
o Distributed/Centralised approach: the solution is based on IP
address pools assignment and splitting, where all nodes
collectively perform the functionality of assigning addresses to
newcomers.
o Partitioning/Merging support: the solution defines a mechanism to
detect merging, through redistributing information about assigned
addresses and pools. If an address collision is detected, then
the solution defines a mechanism to solve that, based on giving
up/shrinking the address pool used by one of the nodes detecting
the conflict.
o Prefix assignment support: Since the solution supports the
assignment of address pools, it can be possible to use it to
assign prefixes to nodes, although it is not explicitly covered by
the mechanism.
o Protocol overhead: 'high', since the solution requires some
message flooding to search nodes that have an address pool
available.
4.1.2.5. No Overhead Autoconfiguration OLSR (Mase et al.)
This solution [12] proposes some passive DAD techniques to be used in
MANETs running the OLSR protocol. It utilises the Passive Duplicate
Address Detection concept [13], [14], which enables nodes to
passively detect duplicate addresses in the network (e.g., occurring
after network merging) by analysing received routing protocol
messages. The basic idea of PDAD is to exploit the fact that some
protocol events occur in case of duplicate address, but (almost)
never in case of a unique address. The proposed techniques may be
used to ensure uniqueness of an address when it is initially
generated before being assigned to an interface and the solution also
performs to ensure uniqueness of addresses which have been assigned
and used, and then a network merger happens.
This is one of the multiple drafts proposing the use of PDAD for OLSR
[15], [16].
Assumptions: The protocol assumes the existence of a DAD-based IP
address generation mechanism.
Approach description: The solution proposes an ongoing duplicate
address detection mechanism, checking for inconsistencies in the
Bernardos, et al. Expires January 3, 2008 [Page 19]
Internet-Draft MANET autoconf survey July 2007
routing protocol messages to diagnose duplicate address detection.
The first kind of inconsistency is based on information included in
OLSR messages (such as HELLO messages and TC messages) and the second
kind of inconsistency is based on sequence numbers (when two nodes --
which selected the same IP address -- are present in a network, they
would send control messages that will be inconsistent).
Different DAD rules -- twelve in total -- are proposed to handle the
cases where the distance between conflicting nodes is one hop, two
hops and, three hops or more. In the two first cases the detection
is done by means of HELLO messages and in the last case -- three hops
or more -- the detection is fulfilled by using information inside TC
messages. Also, an additional case is taken into account: this is a
specific multihop address conflict case, where the address conflict
results in deficiencies in the MPR selection.
Each node has an "autoconfiguration state". This state is an
indicator of how long the node has been in the network. The central
idea, is that each time a node generates a tentative address, it
should enter the network gradually, running a restrained version of
the OLSR protocol. In this way, the node can detect which addresses
are being used, checking for duplicates of its own address, while
avoiding to disrupt the routing tables of the other nodes, in the
event that its address is actually found to be in conflict.
Correspondence to the criteria described in Section 3:
o MANET scenario: This DAD technique is to be used in standalone
MANETs.
o Routing protocols' dependency: This DAD technique is designed for
MANETs running the OLSR protocol.
o DAD-based: The proposed mechanism assumes the existence of a DAD-
based address assignment mechanism.
o Distributed/centralised approach: the proposed solution follows a
distributed approach given that all nodes have the same
responsibility detecting address conflicts.
o Partitioning/Merging support: The proposed solution supports
mergers enabling nodes to continuously detect duplicate addresses
by analysing received routing protocol messages.
o Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
Bernardos, et al. Expires January 3, 2008 [Page 20]
Internet-Draft MANET autoconf survey July 2007
o Protocol overhead: 'none', since the proposed mechanism does not
add any additional messages but it checks for inconsistencies in
the routing protocol messages to diagnose duplicate address
detection.
4.1.2.6. PDAD-OLSR: Passive Duplicate Address Detection for OLSR
(Weniger et al.)
This solution [15] proposes a passive DAD mechanism for configured
address uniqueness maintenance in MANETs running the OLSR protocol.
Assumptions: The protocol assumes the existence of a DAD-based
address generation mechanism.
Approach description: The proposed solution is made up of a set of
algorithms which specify how to detect duplicate addresses based on
incoming routing protocol messages. The algorithms utilise different
parameters in TC and HELLO messages such as link states (i.e.,
neighbour interface addresses), link codes, (message) sequence
numbers, and addresses in OLSR routing protocol messages as well as
addresses in the IP header. PDAD-OLSR allows the detection of
conflicts by intermediate nodes that have unique addresses.
Each node conceptually maintains two tables for PDAD: a Last received
Protocol Messages (LRM) table and a Neighbour History (NH) table.
LRM table contains information about the last TC and HELLO protocol
message received from a specific originator address (e.g., originator
address, message type, sequence number, neighbour interface
addresses, receive time). NH table contains the history of
neighbouring node addresses and is built from received HELLO messages
(e.g., neighbour interface address, last time the receiver has
selected this neighbour interface address as MPR, Last time the
receiver has been selected as MPR by this neighbour interface
address, reception time).
The solution proposes eight different algorithms for conflict
detection:
o PDAD-Source Address (SA). Whenever a node receives a TC or HELLO
message, it compares the source address in the IP header to its
own address (the IP source address is always the address of the
last forwarder). This mechanism (e.g., Both addresses coincide)
allows nodes to detect conflicts with its neighbouring nodes.
o PDAD-Sequence Numbers (SN): If a node receives a TC or HELLO
message, it compares the originator address with its own address.
If they are equal and the sequence number in the message is higher
than the receiver's sequence number, a conflict of the originator
Bernardos, et al. Expires January 3, 2008 [Page 21]
Internet-Draft MANET autoconf survey July 2007
address is detected. This mechanism allows to detect conflicts
between nodes that are any number of hops away from each other.
o PDAD-Sequence Number Difference (SND): If a node receives a TC or
HELLO message, it compares the sequence number in the message with
the sequence number in the previously received message from the
same originator address and with the same message type (there is a
relation between the time a node has originated two TC messages
and the sequence number in those TC messages). This mechanism
allows to detect conflicts between nodes that are any number of
hops away from each other.
o PDAD-Sequence Numbers Equal (SNE): If an intermediate node
receives a TC or HELLO message, it searches its LRM table for a
message with the same type value and the same tuple < sequence
number, originator address > (the tuple < sequence number,
originator address > uniquely identifies messages originated by a
specific node. This mechanism allows to detect conflicts between
nodes that are any number of hops away from each other.
o PDAD-SNs Always Increment (SNI): If a node receives a HELLO
message, it compares the sequence number in the message with the
sequence number in the previous HELLO message from the same
originator address (HELLO messages sent by a specific node are
received in the order they are sent). This mechanism only allows
to detect conflicts between nodes that are at most two hops away
from each other.
o PDAD-Neighbourhood History (NH): If a node receives a TC message,
it checks whether its own address is part of the neighbour
interface addresses in the TC message. If this is the case and
the link code indicates a bi-directional link, the node searches
the originator address in its NH table (a TC message only contains
neighbours that have selected the originator address as MPRs and
that requires a bi-directional link). This mechanism allows to
detect conflicts between nodes that are any number of hops away
from each other.
o PDAD-Link States (LS): If a node receives a TC message with its
own address as originator address, it searches in its NH table for
each of the neighbour interface addresses (if the message has been
originated by the receiver, it must only contain addresses of
recent neighbour interfaces). This mechanism allows to conflicts
between nodes that are any number of hops away from each other.
o PDAD-extended Neighbourhood History (eNH): If a node receives a TC
message, it checks for each neighbour interface address in the
message if it is a neighbour. This algorithm is basically the
Bernardos, et al. Expires January 3, 2008 [Page 22]
Internet-Draft MANET autoconf survey July 2007
PAD-NH algorithm executed on behalf of a neighbouring node.
Minimal additional signalling is needed. This mechanism allows to
detect conflicts between nodes that are any number of hops away
from each other.
For some of the above mechanisms it is crucial to detect a possible
sequence number wrap-around, so a mechanism to detect this kind of
events is proposed.
Correspondence to the criteria described in Section 3:
o MANET scenario: The solution targets standalone MANETs. Although
it proposes a DAD mechanism suitable for any kind of addresses
exchanged in routing protocol messages, be it MANET-local or
globally routable addresses, the solution does not address the
issue of how to obtain global IPv6 addresses.
o Routing protocols' dependency: The set of proposed techniques are
applicable to MANETs running the OLSR protocol.
o DAD-based: The proposed mechanism assume the existence of an
address assignment mechanism which may assign duplicate addresses.
o Distributed/centralised approach: The solution follows a
completely distributed approach, every node has the same
responsibility in detecting duplicate addresses and does the same
processing.
o Partitioning/Merging support: The proposed solution supports
mergers given that it enables nodes to continuously detect
duplicate addresses in the network by analysing received routing
protocol messages.
o Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
o Protocol overhead: 'none', since the solution enables nodes to
passively detect duplicate addresses in the network by analysing
received routing protocol messages.
4.1.2.7. Passive Duplicate Address Detection for On-demand Routing
Protocols (Jeong et al.)
This solution [17] proposes a set of DAD techniques to be used
jointly with an on-demand routing protocol. In this proposal passive
duplicate address detection is performed by analysing incoming on-
demand routing protocol packets.
Bernardos, et al. Expires January 3, 2008 [Page 23]
Internet-Draft MANET autoconf survey July 2007
Assumptions: The protocol assumes the existence of an on-demand
routing protocol and a DAD-based IP address configuration mechanism.
Approach description: In this proposal passive duplicate address
detection is performed by analysing incoming on-demand routing
protocol packets. Additional information included in routing
protocol packets allows end-points of a communication -- source or
destination -- to detect that the other end-point is using an address
which is duplicated in the MANET.
This additional information is included into routing control packets
exchanged for route discovery and it may be: the node location when
it configured its IP address, the node's neighbour list when it
configured its IP address, or a sequence number in RREP packets
(increased whenever a destination node sends a new RREP packet).
The authors propose different mechanisms for detecting address
conflicts:
o PDAD-RREQ-with-Location-information Technique (RQL): This
technique includes location information in RREQ packets to
differentiate between RREQ packets which contain the same source
address but are generated by different nodes.
o PDAD-RREQ-with-Neighbour-knowledge Technique (RQN): This technique
includes a list of neighbour nodes (this list is captured and
recorded when the node's IP address is configured) in RREQ packets
to differentiate between RREQ packets which contain the same
source address but are generated by different nodes.
o PDAD-RREP-with-SEQ Technique (RPS) : This technique requires an
incremental PDAD-sequence number to be included in each RREP
packet transmitted by a destination node. Therefore, when a
source node receives more than one RREP packet with the same PDAD-
sequence number and the same destination address, the source node
can detect the address conflict of destination nodes.
o PDAD-RREP-with-Location-information Technique (RPL): This
technique includes location information into RREP packets to
differentiate between RREP packets which contain the same source
address (the source address of RREP packets is the destination
address of RREQ packets) but are generated by different nodes.
o PDAD-RREP-with-Neighbour-knowledge Technique (RPN): When a
destination node replies with an RREP packet, a list of neighbour
nodes of the destination node (this list is captured and recorded
when the node's IP address is configured) is included in the RREP
packet.
Bernardos, et al. Expires January 3, 2008 [Page 24]
Internet-Draft MANET autoconf survey July 2007
The document does not include how to perform address conflict
resolution.
Correspondence to the criteria described in Section 3:
o MANET scenario: The solution targets standalone MANETs. Although
the proposed DAD mechanism is suitable for any kind of addresses
exchanged in routing protocol messages, be it MANET-local or
globally routable addresses, it does not define any mechanism to
obtain global IPv6 addresses.
o Routing protocols' dependency: The set of proposed techniques
suppose the existence of an on-demand ad-hoc routing protocol.
o DAD-based: The proposed mechanism assumes the existence of a DAD-
based address assignment mechanism.
o Distributed/centralised approach: The solution follows a
completely distributed approach, every node has the same
responsibility in detecting duplicate addresses and does the same
processing.
o Partitioning/Merging support: The proposed solution supports
mergers given that it enables nodes to continuously detect
duplicate addresses in the network by analysing received routing
protocol messages.
o Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
o Protocol overhead: 'none', since the solution enables nodes to
passively detect duplicate addresses in the network by analysing
received routing protocol messages.
4.1.2.8. Prophet Address Allocation for Large Scale MANETs (Zhou et
al.)
The mechanism defined in [18] is based on the use of a special type
of function to derive the IPv6 addresses of nodes, so the probability
of address duplication is very low, and therefore DAD can be avoided.
Assumptions: This solution is based on the use of a stateful function
f(n) (where the initial state of f(n) is the seed) that produces as
output an integer sequence of numbers. Different seeds lead to
different sequences, and the state of f(n) is updated. This function
can be used to generate IP addresses, since it satisfies the
following properties:
Bernardos, et al. Expires January 3, 2008 [Page 25]
Internet-Draft MANET autoconf survey July 2007
o The interval between two occurrences of the same number in a
sequence is extremely long.
o The probability of more than one occurrence of the same number in
a limited number of different sequences initiated by different
seeds during some interval is extremely low.
These properties may be satisfied if the space of available addresses
is large, so it is relatively easy to achieve in IPv6.
Approach description: The mechanism basically work as follows: the
first node in the MANET chooses a random number as its IP address and
uses a random or default state value as the seed for its f(n). When
a different node approaches, the first node uses its f(n) to obtain a
different number and state. This number is used by the second node
as its IP address, and the state is used as the seed for its f(n).
After that both nodes are able to assign IP addresses to other nodes.
Authors of the mechanism propose different mechanisms to support
partitioning/merging, such as for example including the seed used in
the MANET in the messages of the routing protocol. By doing that,
nodes of different merging MANETs can easily detect the merge (if
different seeds are received, that would mean that a merge has
happened) and start checking if there are potential IP address
conflicts. Given the characteristics of the function f(n) if a MANET
gets partitioned and later merges, IP address conflicts are very
unlikely to occur.
Correspondence to the criteria described in Section 3:
o MANET scenario: the solution targets standalone MANETs.
o Routing protocols' dependency: the solution is routing protocol
independent.
o DAD-based: the proposed solution does not define any DAD
mechanism. The address uniqueness is ensured by using a "prophet"
allocation with a very low probability of collision.
o Distributed/centralised approach: the solution does not make use
of any centralised server.
o Partitioning/Merging support: the solution proposes different
mechanisms to support partitioning/merging.
o Prefix assignment support: the solution supports the assignment of
IPv6 prefixes to nodes, by using the DHCP prefix delegation.
Bernardos, et al. Expires January 3, 2008 [Page 26]
Internet-Draft MANET autoconf survey July 2007
o Protocol overhead: 'low', since only few additional messages are
required to assign addresses to new nodes.
4.2. Solutions for Connected MANET scenarios
4.2.1. No partitioning/merging support
4.2.1.1. Automatic Configuration of IPv6 Addresses for Nodes in a MANET
with Multiple Gateways (Ruffino et al.)
This proposed solution [19] describes a mechanism enabling nodes
belonging to a MANET connected to the infrastructure -- by means of
one or more gateways -- to obtain global IPv6 addresses that could be
used to communicate with external nodes.
Assumptions: This mechanism assumes the existence of one or more
gateways that provide MANET nodes with connectivity to external
networks (e.g., the Internet). It is also assumed that nodes running
this solution obtain at the bootstrapping phase a MANET local IPv6
address (which is the address that the node uses when it participates
in the routing protocol, which is assumed to be OLSR). The
uniqueness of the obtained address should be ensured by means of a
DAD method. Neither the procedure followed to obtain this address,
nor the DAD method used to check its uniqueness, are defined in this
solution.
Approach description: The mechanism basically works as follows: at
bootstrap, a node configures a Primary Address (PADD) that is MANET-
scoped and is used as main address in OLSR messages. The node then
is able to start participating to OLSR and receiving topology
information. Each of the gateways available at the MANET has a
global IPv6 prefix that is announced using a new OLSR message type,
called Prefix Advertisement (PA).
With the prefix information received in the PA messages, a node is
able to build a set of global IPv6 addresses (called Secondary
Addresses: SADDs). Among them, the node chooses the "best" prefix
and starts using the address formed from this prefix (called,
Designated Secondary Address: DSADD). The node introduces all (or a
subset) of the SADDs (including the DSADD) in OLSR messages and
starts broadcasting them, enabling these addresses to be routable and
reachable within the MANET. It should be noted, that this solution
does not define any new DAD mechanism, while it is suggested to use a
generic MANET DAD procedure, such as [5], to verify the uniqueness of
MANET-local and global addresses.
Correspondence to the criteria described in Section 3:
Bernardos, et al. Expires January 3, 2008 [Page 27]
Internet-Draft MANET autoconf survey July 2007
o MANET scenario: the solution targets connected MANETs.
* Gateway involvement: each of the gateways present in the MANET
obtains an IPv6 prefix and announces it using a new OLSR
message type, called Prefix Advertisement (PA).
o Routing protocols' dependency: the solution is restricted to OLSR.
o DAD-based: the proposed solution does not define any DAD
mechanism, although requires some generic one to be used to ensure
the uniqueness of MANET-local and global addresses.
o Distributed/centralised approach: the solution does not make use
of any centralised server, but requires gateways to announce the
global IPv6 prefixes that can be used by MANET nodes in the
configuration of their IPv6 addresses.
o Partitioning/Merging support: the solution partially supports
partitioning/merging, since the scenario in which new gateways
join the network as a result of a merger is considered. However,
since no DAD mechanism is defined, the solution does not describe
how to deal with IPv6 address duplication after merging of
different MANETs.
o Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
o Protocol overhead: 'medium', since Gateways broadcast prefix
information.
4.2.1.2. Simple MANET Address Autoconfiguration (Clausen et al.)
This proposed solution [20] aims to provide a simple IP
autoconfiguration mechanism for mobile nodes joining an existing
MANET. This mechanism is designed for MANETs that act as an edge-
extension to the Internet, where mobile nodes need to maintain the
connections with each other and with the Internet.
Assumptions: It is assumed that at least one node in the network is
already configured with a permanent address. In the absence of a
configured node, it is assumed that an election mechanism is
undertaken allowing a selected node to be self-configured.
Approach description: In this proposed solution, only configured
nodes can participate in the MANET and are considered as MANET nodes.
These nodes are also considered as "configuring nodes" aiding the new
joining nodes to acquire an IP address. Actually, each new joining
node is firstly assigned a temporary local address then a permanent
Bernardos, et al. Expires January 3, 2008 [Page 28]
Internet-Draft MANET autoconf survey July 2007
global address. The configuring nodes emit periodical ADDR_BEACON
messages to their neighbours in order to signal their existence to
new nodes. A new node joining the network selects a configuring node
from its neighbours, then sends an Address Request (AREQ) to this
selected configuring node and waits for a reply. The process of
sending AREQ may be repeated for a number of trials until either
receiving a reply or selecting a new configuring node. The
configuring node replies by an Addr-Config message, containing a
local temporary address, and keeps track of the link existence with
the new joining node through local routing messages exchange on this
link. If this link disappears then the configuring node gives up,
otherwise the configuring node assigns a global address to the new
joining node.
The process of obtaining a temporary address consists of having an
address space, where each MANET node independently selects an address
sequence from this space and signals it to its neighbours (through
beacons). Each MANET node records the address sequence received from
is neighbours to avoid conflicts in the chosen addresses. If a
conflict is detected between two nodes, the node with the lowest ID
should select a new sequence if both nodes are not configuring nodes
(MANET nodes that are not yet engaged in configuring a new node).
Otherwise, if one or more configuring nodes are involved in the
conflict, each configuring node should narrow its sequence of
addresses to contain only the address that is currently assigned (in
order to keep on the configuring session). On the other hand two
options exist for global addresses allocation. One option is that
the configuring node acts as a modified DHCP proxy and transmits a
request to a DHCP server to acquire a global address for each new
node it configures. Another option is that the configuring node
consults the nodes' topology tables (containing destinations and thus
network addresses), and then picks up an unused address. It then
sends an advertisement to all MANET nodes to be sure that this
address is not used. If a node detects that its address is being
used, it can signal the conflict to the originator of the
advertisement.
Correspondence to the criteria described in Section 3:
o MANET scenario: This proposed solution targets connected MANET
scenarios.
* Gateway involvement: Although the proposed solution targets a
connected MANET, there is no specific role for a Gateway node
among the MANET nodes.
Bernardos, et al. Expires January 3, 2008 [Page 29]
Internet-Draft MANET autoconf survey July 2007
o Routing protocols' dependency: This proposed solution uses OLSR,
typically extending OLSR messages. Although the proposed solution
is open to any routing protocol, the fact that periodical beacons
are used requires a proactive routing protocol.
o DAD-based: The proposed solution uses a DAD mechanism to avoid
conflicts in IP address assignment. In global address allocation,
using a DAD mechanism is an option but the proposed solution can
function without a DAD mechanism if the modified DHCP proxy
approach is followed. While in temporary address allocation, a
limited DAD is used with the neighbourhood to resolve any conflict
when assigning temporary addresses sequences to MANET nodes.
o Distributed/Centralised approach: The proposed solution is
distributed in the sense that it can employ a decentralised DHCP
server using the concept of proxy DHCP to reach the server.
o Partitioning/Merging support: This proposed solution has no
merging support.
o Prefix assignment support: The proposed solution does not support
prefix assignment since no gateways are involved in the IP address
assignment process.
o Protocol overhead: 'high', since the solution requires a
considerable number of signalling. This is mainly during the
advertisement messages for global addresses flooded to all nodes
in the network for verifying the global address uniqueness, the
periodical ADDR_BEACON messages that are transmitted by each
configuring nodes to its neighbours, and the Beacon messages
signalling the selected address space by each configuring node
during the process of temporary address assignment. Furthermore,
AREQ messages are used by each new joining node while
communicating a neighbour configuring node, which in turn replies
by an Addr-config message.
4.2.1.3. Extensible MANET Auto-configuration Protocol (EMAP) (Ros et
al.)
The Extensible MANET Auto-configuration Protocol (EMAP) [21] provides
an autoconfiguration solution for isolated as well as hybrid MANETs.
EMAP is envisioned to be integrated within unicast routing protocols
as DYMO or OLSRv2. The notion of intermediate proxies is used in the
autoconfiguration process. The general EMAP framework may be used as
a service discovery protocol for MANETs, however the approach is
extensible to other services. An optional feature in EMAP includes
DNS discovery, where nodes can discover DNS servers reachable from
the MANET, and this feature can be extended to services like SIP,
Bernardos, et al. Expires January 3, 2008 [Page 30]
Internet-Draft MANET autoconf survey July 2007
proxies, and authentication entities.
Assumptions: It is assumed that at least one element must act as a
gateway between the MANET and the fixed network. This element is
called an Internet Gateway (IGW).
Approach description: EMAP allows MANET nodes to configure unique IP
local addresses and globally routable IP addresses. The local
configuration allows a MANET node to communicate with other nodes in
the same MANET. To configure a local address, the MANET node picks
an IP address and asks the network if it is already being used, thus
avoiding address duplication. In this process, a node generates a
pair of IP addresses: temporary and tentative ones. The temporary
address is used as the originator-address, where it can be a mobile
IP home address or another sort of highly likely unique address.
While the tentative address is the one which is being requested and
is used as the requested address in the DAD_REQ messages and the
originator-address in DAD_REP messages. Thanks to the proxy
functionality, intermediate nodes can also answer with a DAD_REP
message if they do not own the requested address but they do know
that it is being used by another node. If the MANET node sending the
DAD_REQ receives no DAD_REP messages, then it understands that there
is no address conflict and it considers that the tentative address is
its local address.
On the other hand, global configuration takes place through using the
Internet Gateway (IGW), which may be a fixed element belonging to
each network, or a mobile one which detects the presence of an
attachment point to the Internet (e.g. a wireless router). The
mobile node requesting a global address either waits for
advertisements sent by the IGW (mainly advertising its prefix) to
configure its global address or floods a global configuration request
(GC_REQ) message. When an IGW receives a GC_REQ message, it sends a
global configuration reply message (GC_REP) to the originator-address
through unicast. Thus, the originating node is able to auto-
configure a global address by substituting the first bits of the
requested local address by the prefix advertised by the IGW. When
there are multiple IGWs announcing their own information, the MANET
node selects one, and the selection rules are implementation-
dependent.
A given option in EMAP allows a MANET node to issue a query to find
DNS Server Advertisers, which provide IP addresses of available DNS
servers. This feature may be quite useful in situations where a high
degree of auto-configuration is desired.
Correspondence to the criteria described in Section 3:
Bernardos, et al. Expires January 3, 2008 [Page 31]
Internet-Draft MANET autoconf survey July 2007
o MANET scenario: This proposed solution is designed for isolated
MANETs and hybrid MANETs connected to the Internet.
* Gateway involvement: The proposed solution is based on the
existence of at least one gateway connected to the Internet.
The gateway may be a wireless mobile router capable of
detecting points of attachments to the Internet. Each gateway
advertises its prefix.
o Routing protocols' dependency: EMAP is envisioned to be integrated
with unicast routing protocols like DYMO or OLSRv2. It may be
implemented as a standalone daemon.
o DAD-based: The proposed solution uses DAD during the
autoconfiguration of MANET local addresses.
o Distributed/Centralised approach: The proposed solution is a
distributed solution in the sense of not being based on any DHCP
servers.
o Partitioning/Merging support: No special merging mechanisms are
explained in this solution. However, no in-service DAD is used
which makes the merging support not feasible.
o Prefix assignment support: This solution employs IPv6 prefixes,
where gateway nodes are responsible for advertising their
prefixes.
o Protocol overhead: 'medium' or 'high' depending on the network
size, the number of IGWs, and the applied option in global address
configuration. The resulting overhead in this solution mainly
concerns: flooding of the local address selected by each joining
node to verify its uniqueness through the DAD_REQ messages, prefix
advertisement by IGWs during global address configuration (this
has more impact on the overhead when the number of IGWs
increases), and flooding of GC_REQ messages by the node requesting
a global address (in case that no prefix advertisement is taking
place by the IGWs) where in this case GC_REP messages are sent by
IGWs through unicast. Furthermore, DAD_REPLY messages could take
place in case of address conflicts detection.
4.2.1.4. Global Connectivity for IPv6 Mobile Ad Hoc Networks (Wakikawa
et al.)
The solution described in [22] proposes how to provide Internet
connectivity with mobile ad hoc networks. It describes how to obtain
a globally routable IPv6 address from an Internet gateway. The
Internet access method is not dependent on a particular MANET
Bernardos, et al. Expires January 3, 2008 [Page 32]
Internet-Draft MANET autoconf survey July 2007
protocol.
Assumptions: The solution assumes that before configuring a global
IPv6 address, the node has configured a routable address (i.e.
MANET-local address or a Mobile IPv6 home address). The routable
address is used for initial configuration when a node boots up and
joins the MANET.
Approach description: This mechanism [22] is similar to [23] from the
point of view of how IPv6 addresses are configured. Global prefix
information is obtained from Internet gateways. Two methods are
proposed for the Internet gateway discovery: one method periodically
disseminates gateway advertisements to all nodes in the MANET; the
other method utilises solicitation and advertisement signalling
between a MANET node and the gateway. Extended router solicitation
and advertisements of the Neighbour Discovery Protocol (NDP) or
extended control message of each MANET routing protocol can be used
for this signalling. The proposed methods target all MANET protocols
regardless of whether they are reactive or proactive. Internet
gateways supply their own global prefix information and IPv6 global
address to MANET nodes somehow, either proactively or reactively. In
this way, the reactive and proactive route discovery features of each
MANET routing protocol are not disturbed. An advertisement from the
Internet gateway provides prefix information -- IP routing prefix and
prefix length -- and lifetime.
After accepting an advertisement from the Internet gateway inserts
the Internet gateway address as an Internet route and the MANET node
configures a global address from the prefix of the Internet gateway.
It uses the 64-bit interface ID in order to construct a valid address
with the acquired prefix. It is assumed that before configuring a
global IPv6 address, the node has configured a routable local address
(i.e. MANET-local address), and a DAD mechanism has been performed
for that routable local address (e.g. using the mechanism defined in
[5] and [24]), so it is assumed that the global address would be also
unique. If not, the node may perform another DAD mechanism for this
global address.
If the destination of a packet is inside the MANET even though a
global routable address is used as destination address, the gateway
prevents this packet from being forwarded to the Internet. It
returns the packet back to the MANET if it has a MANET route for the
destination. The source node receives an ICMP Redirect message from
the Internet Gateway warning that it should use a host route (MANET-
local address) instead of a default route (Internet route). To do
so, each Internet gateway may manage a list of IP addresses of all
the associated MANET nodes (mainly if a reactive ad hoc routing
protocol is being used). So, each MANET node must contact the
Bernardos, et al. Expires January 3, 2008 [Page 33]
Internet-Draft MANET autoconf survey July 2007
Internet gateway at least once it establishes an Internet route
through the Internet Gateway in order to communicate its global
routable address to the Internet Gateway.
Correspondence to the criteria described in Section 3:
o MANET scenario: the solution targets connected MANETs.
* Gateway involvement: each of the gateways present in the MANET
is able of assigning IP addresses to ad hoc nodes using a
stateless style. The proposed solution supports the existence
of multiple gateways.
o Routing protocols' dependency: Not restricted to any particular ad
hoc routing solution, and it is designed to work properly with
both proactive and reactive protocols.
o DAD-based: It is assumed that the global address would be also
unique. If not, the node may perform a DAD mechanism for this
global address. In any case the DAD mechanism is considered out
of scope.
o Distributed/centralised approach: The proposed solution uses a
distributed approach where nodes do not solicit any centralised
server for IP address assignment.
o Partitioning/Merging support: No special merging mechanisms are
discussed in this solution. Also, no in-service DAD is used which
makes the merging support not feasible.
o Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
o Protocol overhead: 'low or high' depending on the approach
followed. If extended control messages of the MANET routing
protocol -including global prefix information- are used the
solution introduces 'low' overhead, but if gateway advertisement
messages are periodically flooded (with the hop limit field set to
an appropriate value in the MANET) then the solution introduces
'high' overhead.
4.2.1.5. Multihop Radio Access Network (MRAN) Protocol Specification
(Hofmann)
This proposed solution [25] presents the Multihop Radio Access
Network (MRAN) protocol, which is an IPv6-based protocol for the
interconnection of ad hoc networks and the Internet. MRAN proposes
an approach that enables mobile ad hoc nodes to communicate with
Bernardos, et al. Expires January 3, 2008 [Page 34]
Internet-Draft MANET autoconf survey July 2007
correspondent nodes on the Internet. The application scenario of
this protocol is mainly when multiple gateways are available and
mobile nodes are frequently changing these gateways. The gateways
are supposed to be fixed and advertising different prefixes. MRAN
treats the gateways discovery and selection, the autoconfiguration of
global addresses, and the packet forwarding to/from the fixed
network.
Assumptions: It is assumed that mobile nodes (MNs) and Gateways (GWs)
use local addresses for communication within the MANET and that
routing is performed by a MANET routing protocol. It is also assumed
that a flooding protocol is used for broadcasting certain MRAN
control messages, where the flooding functionality may be provided by
the routing protocol.
Approach description: The operation of MRAN involves several
functions: GW discovery, GW selection, address autoconfiguration,
registration with the GW, packet forwarding and multi-hop handovers.
Three modes of GW discovery are proposed and the choice between them
depends on the application scenario. In proactive GW discovery, all
GWs periodically broadcast advertisement messages "GW_ADV", where MNs
in proactive mode requiring Internet access waits until they receive
such a message. The reactive mode discovery allows MNs to discover
the available GWs when needed through broadcasting a GW solicitation
message. A GW receiving such a message replies by unicast solicited
GW advertisement message "sol_GW_ADV" to the MN. Hybrid GW discovery
mode is a combination of both proactive and reactive discovery, where
the GW is in proactive mode and the MN is in reactive one. All GW
advertisement messages contain the GW globally valid prefix of 64
bits length. The GW selection process allows each MN to select the
closet GW with respect to the number of hops. Other additional
metrics may be included in the selection process. After the GW
selection, the MN uses the selected GW's prefix and its own EUI-64 to
autoconfigure the global address. It may subsequently perform a DAD.
Registration with the selected GW should take place, where the MN
sends a registration request message "MN_REG" to the selected GW. A
GW receiving this message replies by a registration acknowledgement
message "MN_REG_ACK" indicating the successful registration. The MN
then periodically repeats the registration process and the
registration may be used for other purposes as well (for instance the
AAA). To assure appropriate packet forwarding between each MN and
its selected GW, payload packets are tunnelled between MNs and GWs in
both directions. The tunnelling approach uses IP-in-IP encapsulation
thus allowing using local addresses for intra-MANET communication.
In the tunnel from the GW to the MN, the destination address of the
inner IP header is the MN global address and the destination address
of the outer header is the local address of the MN. On the other
hand, in the tunnel from the MN to the GW, the destination address of
Bernardos, et al. Expires January 3, 2008 [Page 35]
Internet-Draft MANET autoconf survey July 2007
the inner IP header is the CN global address, whereas the destination
address of the outer header is the local address of the GW. In the
case of MN's disconnection from its current GW while communicating
with a CN in the Internet, multihop handover takes place. Thus, the
MN has to discover, select and register with another GW. This is
called a "forced multihop handover". For optimisation reasons, the
MN may also select a new GW that could be more close than the current
GW. In this case, the MN performs the registration with the new GW
while it is connected to the current one. This is known as
"optimised multihop handover", and is much faster than the forced
one.
Maintenance takes place through creating two tables: i) GW table, and
ii) MN table. MNs maintain a GW table storing information about the
available GWs (local address, prefix, expiration time, registration
expiration). A table entry is created when the MN receives a GW_ADV
or Sol_GW_ADV messages. On the other hand, GWs maintain MN tables
storing information about mobile nodes having a valid registration,
where each entry in this table stores the following information on
MNs (local address, global address, registration expiration time).
Correspondence to the criteria described in Section 3:
o MANET scenario: This proposed solution targets connected MANET
scenarios enabling mobile nodes to communicate with correspondent
nodes in the Internet.
* Gateway involvement: The proposed solution is based on the
existence of multiple fixed gateways that advertise different
prefixes.
o Routing protocols' dependency: This proposed solution works
independent of the MANET routing protocol.
o DAD-based: The proposed solution may use a DAD mechanism, where a
mobile node configuring a global address may perform a DAD for
this address.
o Distributed/Centralised approach: The proposed solution uses a
distributed approach, where it does not solicit any centralised
server for IP address assignment.
o Partitioning/Merging support: No special merging mechanisms are
discussed in this solution. Also, no in-service DAD is used which
makes the merging support not feasible.
o Prefix assignment support: This proposed solution supports
prefixes assignment, where the different gateways are responsible
Bernardos, et al. Expires January 3, 2008 [Page 36]
Internet-Draft MANET autoconf survey July 2007
for IPv6 prefixes advertisements.
o Protocol overhead: 'high', since this solution integrates several
mechanisms and there is a number of flooding used to achieve the
proper mechanisms' functioning. The overhead in this solution
mainly lies in the assumption of an existing flooding protocol for
broadcasting certain MRAN control messages, and GWs periodical
broadcast of GW_ADV messages (containing the GW prefix) when
proactive GW discovery is applied. Also, GW_Solicitation messages
are broadcast on-demand when reactive GWs discovery is applied,
and periodical MN_REG messages are sent to the selected GWs by
each node requesting an IP address which is acknowledged by a
MN_REG_ACK by the selected GW. Furthermore, additional messages
are used for maintenance.
4.2.1.6. Automatic IP Address Configuration in VANETs (Fazio et al.)
Automatic IP address configuration is a challenging and still
unexplored issue in vehicular ad hoc networks (VANETs) environments,
where the vehicles' high mobility and variant density impede the
direct utilisation of traditional networking techniques and
protocols. Aiming at integrating VANETs within the Internet and
providing passengers with any kind of Internet applications, the IP
address represents the natural identifier in the system. This work
[26] proposes an IP autoconfiguration solution in VANETs environment,
exploiting the VANETs topology and an enhanced DHCP service with
dynamically elected leaders to provide a fast and reliable IP address
configuration.
Assumptions: It is assumed that the network topology is linear and
that a group of nodes move following a track with an internal
mobility with respect to each other. It is also assumed that the
relative speed between nodes is low.
Approach description: This work proposes a novel automatic IP address
configuration protocol named Vehicular Address Autoconfiguration
(VAC), that is characterised by a low configuration time. VAC
represents the first protocol for IP address configuration in VANETs.
It exploits the VANET topology and a distributed dynamic host
configuration protocol (DHCP) runs by dynamically elected leader
vehicles to quickly provide unique identifiers and reduce the
frequency of IP address re-configurations due to mobility. VAC
organises leaders in a connected chain such that every node (vehicle)
lies in the communication range of at least one leader. This
hierarchical organisation allows limiting the signal overhead for the
address management tasks. Only leaders communicate with each others
to maintain updated information on configured addresses in the
network. Leaders act as servers of a distributed DHCP protocol and
Bernardos, et al. Expires January 3, 2008 [Page 37]
Internet-Draft MANET autoconf survey July 2007
normal nodes ask leaders for a valid IP address whenever they need to
be configured.
VAC guarantees unique IP addresses within a defined SCOPE around the
leader, where the SCOPE of the leader A is the set of leaders whose
distance from A is less or equal to SCOPE hops. Considering the
normal node Y that received the IPy address from A, IPy will be
unique as long as Y moves within the SCOPE of A. If Y goes out of the
SCOPE of A, in order to still ensure the address uniqueness, Y has to
ask the new leader for another address. Considering that the
relative speed between the nodes is low, changes in the address
configuration due to having left the own leader's SCOPE are not
frequent.
Correspondence to the criteria described in Section 3:
o MANET scenario: The proposed solution targets connected MANET
scenarios, enabling mobile nodes (vehicles) to communicate with
correspondent nodes on the Internet.
* Gateway involvement: Although the proposed solution targets
connected MANET scenarios, no special gateway role is needed in
the IP address assignment process.
o Routing protocols' dependency: Apparently VAC does not depend on a
special routing protocol. However no clear definition is given on
how and what control messages are exchanged in order to configure
each node requiring an IP address.
o DAD-based: The proposed solution does not employ any DAD
mechanisms, however it guarantees address uniqueness for each
configured node.
o Distributed/Centralised approach: The proposed solution employs a
partially distributed approach, where distributed DHCP run by some
mobile nodes (vehicles)that are elected in a dynamic manner to
assign IP addresses to the requesting nodes.
o Partitioning/Merging support: No special merging mechanisms are
explained in this proposed solution, however it could support
merging. The SCOPE principle together with the distributed DHCP
permit the nodes to join/leave different SCOPES while acquiring a
new address from the SCOPE leader.
o Prefix assignment support: This proposed solution does not employ
any IPv6 prefix assignment to nodes.
Bernardos, et al. Expires January 3, 2008 [Page 38]
Internet-Draft MANET autoconf survey July 2007
o Protocol overhead: 'medium' or 'low' depending on the network size
and the nodes' speed. The hierarchical organisation in this
solution limits the signalling overhead and avoids flooding. The
overhead in this solution mainly concerns: the signalling messages
for communication between leaders nodes, the request messages sent
by mobile nodes requesting an IP address from their leaders (this
takes place in a limited scope), and the reply messages from the
leaders to the requesting mobile nodes for assigning IP addresses
(this also takes place in a limited scope). It is noticed that
this solution does not use DAD mechanisms due to the distributed
DHCP functionality among leader nodes, which helps in limiting the
signalling overhead.
4.2.2. Partitioning/merging support
4.2.2.1. Address Autoconfiguration in Optimized Link State Routing
Protocol (Adjih et al.)
This proposed solution [27] is based on the concept of conflict
detection. Each node periodically sends its address and an
identifier. The node identifier is a sequence of bits, of fixed
length (L), that is randomly generated. An address conflict is
detected when the identifier mismatches. This proposed solution is
suitable for OLSR routing protocol with a light increase of control
message overhead, however, it might be used with any MANET protocol.
Two issues are addressed in this solution, an IPv6 stateless
autoconfiguration mechanism and a mechanism promoting address
uniqueness in the situation where different ad hoc networks merge.
Assumptions: Two assumptions are mainly considered in this proposed
solution. Firstly, it is assumed that the identifier of each node is
globally unique in the network. Secondly, it is assumed that a MANET
may be isolated.
Approach description: In this proposed solution, a new mobile node
joining the network is assigned an IP address then it carries out a
conflict detection procedure through running a DAD mechanism. If
another node is detected to have the same address, the new joining
node selects a new address. The address assignment process takes
place as follows: i)consulting a neighbour node that should configure
an address for the new node. The neighbour node then selects an IP
address and sends it to the new node. This takes place by control
messages exchange. ii) picking up a random address inside a given
subnet with MANET_prefix either from a pool of allocated addresses or
through a set of addresses advertised by each MANET node and are
believed not used. In case of address pool existence, this pool
could be reserved by the IANA for local use only (i.e. not forwarded
outside MANET). In addition, in case of MANETs connected to the
Bernardos, et al. Expires January 3, 2008 [Page 39]
Internet-Draft MANET autoconf survey July 2007
Internet, nodes acting as gateways diffuse IPv6 router advertisement
messages. In this case each address in the pool would be a global
address that can be seen from the outside.
The DAD algorithm uses a single special control message to perform
conflict detection. Each node periodically diffuses to the entire
network a special message called MAD (Multiple Address Declaration).
This message contains the node address and a unique identifier for
the node. Several mechanisms are proposed for MAD messages
propagation. When using OLSR, propagation of MAD messages mainly
relies on the MPR flooding, where a number of MPR selection rules are
explained, presenting different options. If another routing protocol
is used, default pure flooding is used for MAD messages propagation.
In case of IP conflict discovery, this is resolved by the node with
the smaller identifier in each conflicting pair. This node should
change its IP, selecting a new IP at random (that is believed to be
free) following the same approach of IP address assignment.
When OLSR routing protocol is used, an additional proposed option is
using Passive Duplicate Detection. In this case, the topological
information diffused by the OLSR routing protocol is sufficient to
detect address conflict. However, some MPR selection mechanisms are
used to ensure that the control messages are properly propagated.
Correspondence to the criteria described in Section 3:
o MANET scenario: This proposed solution targets both pure and
connected MANETs scenarios.
* Gateway involvement: The proposed solution uses the principle
of gateways as an option, where it is possible that a MANET
node acting as a gateway and connected to the Internet carries
out router advertisements allowing IP address assignments for
requesting nodes. Each IP address in this case is a global
address that is seen from Outside MANET.
o Routing protocols' dependency: This proposed solution depends on
the underlying routing protocol.
o DAD-based: the proposed solution comprises a DAD mechanism. The
notion of passive duplicate detection is also used, where the
solution makes use of the routing protocol messages propagation to
detect the address conflicts.
o Distributed/Centralised approach: The proposed solution uses a
distributed approach in the sense of not communicating with a
centralised DHCP server to acquire IP addresses.
Bernardos, et al. Expires January 3, 2008 [Page 40]
Internet-Draft MANET autoconf survey July 2007
o Partitioning/Merging support: This proposed solution has a merge
support, since the conflict detection process is periodically
carried out by mobile nodes. Thus, this solution assures address
uniqueness in case of ad hoc networks merge.
o Prefix assignment support: This solution does not support IPv6
prefix assignment to nodes.
o Protocol overhead: 'low', since this solution benefits from the
OLSR routing protocol signalling and MPRs concept to verify the
address conflicts. The signalling in this solution is limited to
a single control message (MAD message) to perform conflicts
detection. If passive duplicate detection option is applied with
OLSR, the overhead is almost 'none', as the topological
information diffused by OLSR is sufficient to detect address
conflict. However, if another routing protocol is used (which is
an option), the MAD messages have to be flooded resulting in a
'medium' overhead since the flooding is limited to only one
message in this case.
4.2.2.2. Extended Support for Global Connectivity for IPv6 Mobile Ad
Hoc Networks (Cha et al.)
The solution described in [28] proposes a stateful global IP
autoconfiguration for MANETs with the goal of providing enhanced
Internet connectivity to mobile ad-hoc networks. This stateful
autoconfiguration is performed through the exchange of extended
control messages of MANET routing protocols. The protocol is devised
as an extension to AODV, but the concept may be applicable to
proactive routing protocols.
Assumptions: The solution assumes that each node has a
local_IP_address configured.
Approach description: The protocol basically consists in nodes
requesting global addresses to a gateway, which assigns a non-used
address to the requesting node. When an ad hoc node needs a global
IP address it sends an Internet-gateway solicitation message (GW_SOL
message). The Gateway uses an Internet-gateway advertisement(GW_ADV
message)to assign the solicited global IP address to the ad hoc node.
Given the event that an ad hoc node which has a Global IP address
(e.g., G-A1) assigned by a gateway (e.g., GW1) cannot reach GW1
anymore due to a partition in the MANET but this ad hoc node has
Internet connectivity through a different gateway (e.g.. GW2), the
ad hoc node gets another global IP address from GW2 (e.g., G-A2) and
it performs a Locator Registration Procedure with GW1. This locator
registration procedure is similar to Binding Updates in Mobile IPv6.
Bernardos, et al. Expires January 3, 2008 [Page 41]
Internet-Draft MANET autoconf survey July 2007
Using this procedure the ad hoc node registers G-A2 as CoA -- Care of
Address in Mobile IPv6 terminology -- of G-A1, so that ongoing
communications are kept.
More details can be found in [28].
Correspondence to the criteria described in Section 3:
o MANET scenario: the solution targets connected MANETs.
* Gateway involvement: each of the gateways present in the MANET
is able of assigning IP addresses to ad hoc nodes using a DHCP-
like style.
o Routing protocols' dependency: although the protocol is devised as
an extension to AODV, it could be applicable to proactive routing
protocols.
o DAD-based: since non-duplicate addresses are assigned to ad hoc
nodes, the proposed solution is DAD-free.
o Distributed/centralised approach: the solution makes use of
centralised servers (gateways) in order to assign IP global
addresses.
o Partitioning/Merging support: given that the proposed solution
assigns global IP addresses avoiding duplicates, merging is
supported. On the other hand it supports partitions through the
Locator Registration Procedure.
o Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
o Protocol overhead: 'medium', since the mechanism appends some
fields to AODV routing protocol (RREQ message) to ask for a global
IP address and gateway information, and the replay (GW-ADV
message) is unicast to the originator MANET node. The solution
includes the possibility of gratuitous GW_ADV broadcast
periodically.
4.2.2.3. Gateway and Address Autoconfiguration for IPv6 Adhoc Networks
(Jelger et al.)
This proposed solution [23] allows nodes in an ad hoc network to
proactively discover a gateway/prefix pair to be used in building an
IPv6 global address and to maintain a default route towards the
Internet. The core element of this proposed solution is the concept
of "Prefix Continuity". With prefix continuity, any node A that
Bernardos, et al. Expires January 3, 2008 [Page 42]
Internet-Draft MANET autoconf survey July 2007
selected a given prefix P has at least one neighbour with prefix P on
its path to the selected gateway G, thus assuring that each node on
the path between node A and the Gateway G uses the same prefix P.
Assumptions: It is assumed that each node can find a Gateway to
connect with and that each node can be assigned a global address
through this gateway. It is also assumed that one (or possibly more)
nodes of the ad hoc network should provide connectivity to the
Internet, thus acting as Gateways to other nodes.
Approach description: In this proposed solution, each Gateway (GW)
periodically sends a GW_INFO message notifying nodes in the ad hoc
network about its existence as well as the prefix it uses. Some
information in the GW_INFO message allows nodes to select the more
appropriate GW when more than one GW exist. Other information
contained in this message concerns: the GW global address, the length
of the prefix part of the address, and the distance to the gateway as
perceived by the node sending the message. The node receiving the
GW_INFO message forwards it to its 1-hop neighbourhood, where the
forwarder node is considered as the upstream node for each node that
receives the message. Among the transmitted GW-Info messages, each
mobile node selects (through a selection algorithm) only one
neighbour as its upstream neighbour and receives the GW_INFO messages
from this neighbour (i.e. consider this upstream as an intermediate
node to the gateway), then it forwards the message. A node must not
forward a GW_INFO message sent by a node that is not its upstream
neighbour. The destination address of the IPv6 header of the packet
containing the GW_INFO message must be FF02::1 (all nodes), while the
source address of such a packet must be the link local address of the
sender. Thanks to the prefix continuity, the routing via the GW can
be achieved without the need of an IPv6 routing header. Each mobile
node creates its IPv6 global address as follows: {Extended Unique
Identifier (EUI) of the interface from which the GW_INFO message is
received + prefix contained in the message}. No DAD is needed in
this approach, as there is a very little probability of address
duplication when EUI is used.
Correspondence to the criteria described in Section 3:
o MANET scenario: This proposed solution targets connected MANETs
scenarios.
* Gateway involvement: The proposed solution targets connected
MANETs and thus employs Gateways, typically multiple Gateways
can exist. Each gateway advertises the prefix that it uses.
Bernardos, et al. Expires January 3, 2008 [Page 43]
Internet-Draft MANET autoconf survey July 2007
o Routing protocols' dependency: This proposed solution is
independent (in terms of message semantics) of the underlying
routing protocol. Thus, it can be integrated in the operation of
the routing protocol or it can run as standalone daemon.
o DAD-based: The proposed solution does not depend on a DAD
procedure or mechanism.
o Distributed/Centralised approach: The proposed solution is
distributed in the sense of not employing any centralised DHCP
server.
o Partitioning/Merging support: Although no DAD mechanism is used,
this proposed solution supports networking partitioning and
merging as it is based on generating an IPv6 address for each node
based on the prefix advertisements.
o Prefix assignment support: This proposed solution is based on the
prefix continuity and is thus supporting prefix assignment. Each
gateway advertises the IPv6 prefix that it uses.
o Protocol overhead: 'low' or 'medium' depending on the network size
and the number of GWs. The main signalling in this solution
mainly concerns the GW_INFO messages that are periodically sent by
each GW notifying its existence as well as its prefix. Since no
DAD is needed in this solution, this helps in limiting the
signalling and hence the overhead.
4.2.2.4. MANET Autoconfiguration using DHCP (Templin et al.)
This draft [29] discusses about possible solution architectures to
provide MANET nodes with IP address autoconfiguration capabilities.
Basically, the solution proposes to connect nodes within a MANET by
means of virtual ethernets, which are imaginary shared links that
connects the MANET nodes. The nodes attach to the virtual ethernet
via an interface configured over underlying MANET interface(s).
Using this virtual ethernet, MANET nodes can configure global IPv6
addresses using for example DHCPv6.
Assumptions: It is assumed that a MANET Router (MR) embodies a router
entity linked to one or more host entities by virtual point-to-point
interfaces. It is also assumed that the router entity also connects
to an imaginary shared link (i.e., a "virtual ethernet") that
connects all MRs in the MANET.
MANETs are connected to other networks by means of MANET Border
Routers (MBRs). MBRs are assumed to have configured a DHCP relay
and/or a DHCP server.
Bernardos, et al. Expires January 3, 2008 [Page 44]
Internet-Draft MANET autoconf survey July 2007
Approach description: The proposed solution considers that MANET
Routers are attached to an imaginary shared link (called "virtual
ethernet") that connects all the MRs in the MANET. Two different
types of "virtual ethernets" are defined:
o An "enhanced" view of this virtual ethernet sees the MANET as a
fully-connected shared link that connects all MRs. With this
approach, the MR encapsulates each IP packet in an outer IP header
and then sends it on an underlying MANET interface such that the
HOP Limit in the inner IP header is not decremented as the packet
traverses the MANET. Therefore, with this view, all MRs are
neighbours and standard Neighbour Discovery works as-normal. In
[30], this particular approach is separately documented.
o An "unenhanced" view sees the MANET as a multilink site. With
this approach, the MR sends each IP packet on an underlying MANET
interface without further encapsulation, and therefore the Hop
Limit may be decremented as the packet traverses the MANET. With
this view, since there are multiple hops between MRs, a "site-
scoped" equivalent of ND is defined (called Extended Neighbour
Discovery, END). In [31], this particular approach is separately
documented.
The MANET Router autoconfiguration procedure works as follows: first,
each MR configures MANET Local Addresses (MLAs) on each MANET
interface. These MLAs should be unique within the MANET and are used
as an identifier for operating the routing protocol (can also be used
as a locator for packets forwarded within the scope of the MANET).
In IPv6, MLAs are typically generated using Unique Local Addresses
with interface identifiers that are either managed for uniqueness or
self-generated using a suitable random interface identifier
generation mechanism that is compatible with EUI-64 format.
In a second step, the MR engages in the routing protocol over its
MANET interfaces and discovers the list(s) of MBRs that identify the
MANET(s). There are multiple approaches that can be used to perform
this MBR discovery, such as the use of information contained in the
routing protocol, a DHCP option, etc.
For each MANET to which the MR attaches, it also configures a virtual
ethernet interface over the underlying MANET interfaces connected to
the MANET. After the MR configures the virtual ethernet interface,
it can verify the reachability of MBRs and discover prefixes
associated with the MANET's virtual ethernet. This is done by using
Router Solicitation/Router Advertisement exchanges, either using
normal IPv6 Neighbour Discovery -- in the case of "enhanced" view --
or Extended Neighbour Discovery -- for the "unenhanced" view. It is
also possible to use information conveyed in the routing protocol
Bernardos, et al. Expires January 3, 2008 [Page 45]
Internet-Draft MANET autoconf survey July 2007
itself, or through some other means associated with the particular
link technology.
After the MR discovers MBRs, it can configure addresses/prefixes
according to either DHCPv6 or IPv6 Stateless Address
AutoConfiguration (SLAAC). When the former method is used, the MR
sends a DHCPv6 request to the MBR(s) to get global address/prefix
delegations and then assigns addresses/prefixes to internal virtual
interfaces and/or downstream- attached physical interfaces. Once the
MR has obtained a global IPv6 address/prefix, it can send packets
with global source addresses using RFC4191 [1] router selection.
It should be noted that for the global addresses/prefixes [2]
obtained through DHCPv6, DAD is not needed, since DHCPv6 ensures the
uniqueness of the delegated addresses/prefixes. However, the MLAs
assigned to MANET interfaces should be statistically unique so MANET-
wide pre-service DAD is not needed. Alternatively, passive in-
service DAD mechanisms can be used to detect other MRs potentially
using the same MLA.
Correspondence to the criteria described in Section 3:
o MANET scenario: the solution targets connected MANETs.
* Gateway involvement: the solution considers the participation
of MANET Border Routers (i.e., Gateways) in the
autoconfiguration process, by acting as DHCPv6 relays and/or
servers for a MR's DHCPv6 requests/replies.
o Routing protocols' dependency: the solution is protocol
independent.
o DAD-based: the proposed solution does not define any DAD
mechanism. the uniqueness of MANET Local Addresses assigned to
MANET interfaces should be statistically ensured so MANET-wide
pre-service DAD is not needed. If this cannot be achieved,
passive in-service DAD mechanisms can be used to detect other MRs
potentially using the same MLA. The uniqueness of the global IPv6
assigned addresses/prefixes is ensured by DHCPv6.
o Distributed/centralised approach: the solution makes use of the
available DHCPv6 servers to assign global IPv6 addresses/prefixes,
although some hints about the use of IPv6 StateLess Address
AutoConfiguration (SLAAC) are also provided in Appendix B of [29].
o Partitioning/Merging support: the solution supports partitioning/
merging. Different mechanisms are proposed to deal with different
defined partitioning/merging scenarios.
Bernardos, et al. Expires January 3, 2008 [Page 46]
Internet-Draft MANET autoconf survey July 2007
o Prefix assignment support: the solution supports the assignment of
IPv6 prefixes to nodes.
o Protocol overhead: depending on the virtual ethernet approach
followed, it can be 'low' -- for the 'enhanced' view, where normal
IPv6 SLAAC or DHCPv6 can be used --, or 'medium' -- for the
'unenhanced' view, where an Extended Neighbour Discovery mechanism
(that makes use of site-scoped message flooding) is required.
Bernardos, et al. Expires January 3, 2008 [Page 47]
Internet-Draft MANET autoconf survey July 2007
5. Conclusions
This draft presents most of the previously proposed contributions for
the problem of IP address autoconfiguration. Also, a classification
is derived for these different contributions. The objective of this
draft is to provide a reference on existing works on this subject,
and thus gives some useful classification criteria for the solution
space taking into consideration the problem statement draft [3] as
well as the MANET architecture document [4].
Bernardos, et al. Expires January 3, 2008 [Page 48]
Internet-Draft MANET autoconf survey July 2007
6. Security Considerations
The open wireless environment of ad hoc networks makes the IP
autoconfiguration process susceptible to a number of attacks, which
can lead to improper functioning of autoconfiguration mechanisms.
The autoconfiguration problem statement draft [3] states some
security issues that worth consideration. Also, the security threats
for IPv6 networks in general are discussed in [32]. The solutions
described in this draft do not propose any mechanisms to secure the
address autoconfiguration process.
Indeed, in the design of autoconfiguration mechanisms, attacks in ad
hoc multi-hop environments should be considered. In order to assure
secure and hence correct functioning of autoconfiguration mechanisms,
it is important to have a trust relationship between each
communicating pair of nodes that are involved in the
autoconfiguration process. Trust relationship can differ in
standalone MANET compared to connected MANET, where a central
authority can play the role of a trusted third party that could help
in trust provision among the participating nodes. However, some
attacks are difficult to avoid as DoS attacks. Also, cooperation
between nodes is an important factor in order to assure the proper
message forwarding during the autoconfiguration process. In this
context, MANET nodes cooperation should be satisfied and also
gateways should be enough cooperative.
Bernardos, et al. Expires January 3, 2008 [Page 49]
Internet-Draft MANET autoconf survey July 2007
7. IANA Considerations
This document has no actions for IANA.
Bernardos, et al. Expires January 3, 2008 [Page 50]
Internet-Draft MANET autoconf survey July 2007
8. Acknowledgements
We would like to thank all the AUTOCONF ML people that provided
comments to the previous version of the I-D. We would also like to
thank Kilian Weniger for his useful review of this draft.
Bernardos, et al. Expires January 3, 2008 [Page 51]
Internet-Draft MANET autoconf survey July 2007
9. References
9.1. Normative References
[1] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", RFC 4191, November 2005.
[2] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
9.2. Informative References
[3] Baccelli, E., "Address Autoconfiguration for MANET: Terminology
and Problem Statement", draft-ietf-autoconf-statement-00 (work
in progress), June 2007.
[4] Chakeres, I., "Mobile Ad hoc Network Architecture",
draft-ietf-autoconf-manetarch-03 (work in progress), June 2007.
[5] Perkins, C., "IP Address Autoconfiguration for Ad Hoc
Networks", draft-perkins-manet-autoconf-01 (work in progress),
November 2001.
[6] Weniger, K. and M. Zitterbart, "IPv6 Autoconfiguration in Large
Scale Mobile Ad-Hoc Networks", European Wireless 2002 , 2002.
[7] Jeong, J., "Ad Hoc IP Address Autoconfiguration",
draft-jeong-adhoc-ip-addr-autoconf-06 (work in progress),
January 2006.
[8] Jeong, J., "Ad Hoc IP Address Autoconfiguration for AODV",
draft-jeong-manet-aodv-addr-autoconf-01 (work in progress),
July 2004.
[9] Vaidya, N., "Weak Duplicate Address Detection in Mobile Ad Hoc
Networks", MOBIHOC'02 , 2002.
[10] Mohsin, M. and R. Prakash, "IP Address Assignment in a Mobile
Ad Hoc Network", MILCOM 2002 , 2002.
[11] Tayal, A. and L. Patnaik, "An address assignment for the
automatic configuration of mobile ad hoc networks", Personal
Ubiquitous Computing , 2004.
[12] Mase, K. and C. Adjih, "No Overhead Autoconfiguration OLSR",
draft-mase-manet-autoconf-noaolsr-01 (work in progress),
April 2006.
Bernardos, et al. Expires January 3, 2008 [Page 52]
Internet-Draft MANET autoconf survey July 2007
[13] Weniger, K., "Passive Duplicate Address Detection in Mobile Ad
hoc Networks", IEEE Wireless Communications and Networking
Conference (WCNC) , 2003.
[14] 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.
[15] Mase, K. and K. Weniger, "PDAD-OLSR: Passive Duplicate Address
Detection for OLSR", draft-weniger-autoconf-pdad-olsr-01 (work
in progress), June 2006.
[16] Baccelli, E., "OLSR Passive Duplicate Address Detection",
draft-clausen-olsr-passive-dad-00 (work in progress),
July 2005.
[17] Jeong, H., "Passive Duplicate Address Detection for On-demand
Routing Protocols", draft-jeong-autoconf-pdad-on-demand-01
(work in progress), April 2007.
[18] Zhou, H., Ni, L., and M. Mutka, "Prophet Address Allocation for
Large Scale MANETs", Proceedings of INFOCOM 2003 , 2003.
[19] 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.
[20] Clausen, T. and E. Baccelli, "Simple MANET Address
Autoconfiguration", draft-clausen-manet-address-autoconf-00
(work in progress), February 2005.
[21] Ruiz, P. and F. Ros, "Extensible MANET Auto-configuration
Protocol (EMAP)", draft-ros-autoconf-emap-02 (work in
progress), March 2006.
[22] Wakikawa, R., "Global connectivity for IPv6 Mobile Ad Hoc
Networks", draft-wakikawa-manet-globalv6-05 (work in progress),
March 2006.
[23] Jelger, C., "Gateway and address autoconfiguration for IPv6
adhoc networks", draft-jelger-manet-gateway-autoconf-v6-02
(work in progress), April 2004.
[24] Suan, Y., Belding-Royer, E., and C. Perkins, "Internet
Connectivity for Ad hoc Mobile Networks", International Journal
of Wireless Information Networks special issue on 'Mobile Ad
Hoc Networks (MANETs): Standards, Research, Applications' ,
Bernardos, et al. Expires January 3, 2008 [Page 53]
Internet-Draft MANET autoconf survey July 2007
2002.
[25] Hofmann, P., "Multihop Radio Access Network (MRAN) Protocol
Specification", draft-hofmann-autoconf-mran-00 (work in
progress), March 2006.
[26] Fazio, F., Palazzi, C., Das, S., and M. Gerla, "Automatic IP
Address Configuration in VANETs", ACM VANET 2006 Workshop co-
located with Mobicom 2006 , 2006.
[27] Laouiti, A., "Address autoconfiguration in Optimized Link State
Routing Protocol", draft-laouiti-manet-olsr-address-autoconf-01
(work in progress), July 2005.
[28] Cha, H., Park, J., and H. Kim, "Extended Support for Global
Connectivity for IPv6 Mobile Ad Hoc Networks",
draft-cha-manet-extended-support-globalv6-00 (work in
progress), October 2003.
[29] Templin, F., "MANET Autoconfiguration",
draft-templin-autoconf-dhcp-07 (work in progress), March 2007.
[30] Templin, F., "MANET Autoconfiguration over Virtual Ethernets",
draft-templin-autoconf-virtual-00 (work in progress),
February 2007.
[31] Templin, F., "MANET Autoconfiguration over Multilink Sites",
draft-templin-autoconf-multilink-00 (work in progress),
February 2007.
[32] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
Bernardos, et al. Expires January 3, 2008 [Page 54]
Internet-Draft MANET autoconf survey July 2007
Appendix A. Change Log
Changes from -00 to -01:
o The structure of the I-D has modified, classifying the analysed
solutions according to a number of useful criteria, conforming to
the AUTOCONF problem statement draft and the MANET architecture
draft.
o More solutions have been added to the I-D.
o Adding of a security consideration section.
Bernardos, et al. Expires January 3, 2008 [Page 55]
Internet-Draft MANET autoconf survey July 2007
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
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 January 3, 2008 [Page 56]
Internet-Draft MANET autoconf survey July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Bernardos, et al. Expires January 3, 2008 [Page 57]