<?xml version="1.0" encoding="UTF-8"?>

<!-- XXXX TO DO -->
<!-- XXXX -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
    <!ENTITY rfc2119 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY I-D.bernardos-autoconf-evaluation-considerations PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bernardos-autoconf-evaluation-considerations.xml'>
    <!ENTITY I-D.perkins-manet-autoconf PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.perkins-manet-autoconf.xml'>
    <!ENTITY I-D.jelger-manet-gateway-autoconf-v6 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jelger-manet-gateway-autoconf-v6.xml'>
    <!ENTITY I-D.clausen-manet-address-autoconf PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.clausen-manet-address-autoconf.xml'>
    <!ENTITY I-D.jeong-adhoc-ip-addr-autoconf PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jeong-adhoc-ip-addr-autoconf.xml'>
    <!ENTITY I-D.jeong-manet-aodv-addr-autoconf PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jeong-manet-aodv-addr-autoconf.xml'>
    <!ENTITY I-D.laouiti-manet-olsr-address-autoconf PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.laouiti-manet-olsr-address-autoconf.xml'>
    <!ENTITY I-D.cha-manet-extended-support-globalv6 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cha-manet-extended-support-globalv6.xml'>
    <!ENTITY I-D.wakikawa-manet-globalv6 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wakikawa-manet-globalv6.xml'>
    <!ENTITY I-D.ruffino-manet-autoconf-multigw PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ruffino-manet-autoconf-multigw.xml'>
    <!ENTITY I-D.ros-autoconf-emap PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ros-autoconf-emap.xml'>
    <!ENTITY I-D.hofmann-autoconf-mran PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hofmann-autoconf-mran.xml'>
    <!ENTITY I-D.templin-autoconf-multilink PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.templin-autoconf-multilink.xml'>
    <!ENTITY I-D.templin-autoconf-virtual PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.templin-autoconf-virtual.xml'>
    <!ENTITY I-D.mase-manet-autoconf-noaolsr PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mase-manet-autoconf-noaolsr.xml'>
    <!ENTITY I-D.jeong-autoconf-pdad-on-demand PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jeong-autoconf-pdad-on-demand.xml'>
    <!ENTITY I-D.weniger-autoconf-pdad-olsr PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.weniger-autoconf-pdad-olsr.xml'>
    <!ENTITY I-D.clausen-olsr-passive-dad PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.clausen-olsr-passive-dad.xml'>
    <!ENTITY I-D.ahn-autoconf-addresspool PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ahn-autoconf-addresspool.xml'>
    <!ENTITY I-D.jaehwoon-autoconf-mmbr PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jaehwoon-autoconf-mmbr.xml'>
    <!ENTITY I-D.boot-autoconf-brdp PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.boot-autoconf-brdp.xml'>
    <!ENTITY I-D.thubert-tree-discovery PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thubert-tree-discovery.xml'>
    <!ENTITY I-D.boot-brdp-based-routing PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.boot-brdp-based-routing.xml'>
    <!ENTITY rfc5558 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5558.xml'>
    <!ENTITY rfc5320 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5320.xml'>
    <!ENTITY rfc5720 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5720.xml'>
    <!ENTITY I-D.ietf-autoconf-adhoc-addr-model PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-autoconf-adhoc-addr-model.xml'>

]>


<?rfc toc="yes" ?>
<?rfc tocdepth="4" ?>
<?rfc symrefs="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>

<rfc category="std" ipr="pre5378Trust200902" category="info"
  docName="draft-bernardos-manet-autoconf-survey-05">

<!------------------------------------------------>
<!--  Front Section                             -->
<!------------------------------------------------>

  <front>
    <title abbrev="MANET autoconf survey">Survey of IP address
autoconfiguration mechanisms for MANETs</title>

    <!-- AUTHORS -->

    <author initials="CJ."
            surname="Bernardos"
            fullname="Carlos J. Bernardos">
      <organization abbrev="UC3M">
        Universidad Carlos III de Madrid
      </organization>
      <address>
        <postal>
          <street>Av. Universidad, 30</street>
          <city>Leganes, Madrid</city>
          <code>28911</code>
          <country>Spain</country>
        </postal>
        <phone>+34 91624 6236</phone>
        <email>cjbc@it.uc3m.es</email>
        <uri>http://www.it.uc3m.es/cjbc/</uri>
      </address>
    </author>

    <author initials="M.C." surname="Calderon" fullname="Maria Calder<F3>n">
        <organization abbrev="UC3M">
                Universidad Carlos III de Madrid
        </organization>
        <address>
                <postal>
                        <street>Av. Universidad, 30</street>
                        <city>Leganes, Madrid</city>
                        <code>28911</code>
                        <country>Spain</country>
                </postal>
                <phone>+34 91624 8780</phone>
                <email>maria@it.uc3m.es</email>
        </address>
    </author>

    <author initials="H.M." surname="Moustafa" fullname="Hassnaa Moustafa">
        <organization abbrev="France Telecom">
                France Telecom 
        </organization>
        <address>
                <postal>
                        <street>38-40 rue du General Leclerc</street>
                        <city>Issy Les Moulineaux</city>
                        <code>92794 Cedex 9</code>
                        <country>France</country>
                </postal>
                <phone>+33 145296389</phone>
                <email>hassnaa.moustafa@orange-ftgroup.com</email>
        </address>
   </author>
    
    <date month="June" year="2010"/>
    <area>Internet</area>
    <workgroup>Adh-Hoc Network Autoconfiguration (AUTOCONF)</workgroup>

    <abstract>
      <t>
This Internet Draft provides a detailed description of most of the
existing IP autoconfiguration solutions proposed so far. The main aim
of this document is to serve as a general reference for the AUTOCONF
solution space. We present most of the previously proposed IP AUTOCONF
mechanisms in MANETs, showing their key characteristics. Furthermore,
each solution is analysed based on a number of evaluation
considerations.
      </t> 
    </abstract>

  </front>

<!------------------------------------------------>
<!--  Middle Section                            -->
<!------------------------------------------------>

  <middle>

<!------------------------------------------------>
<!--  SECTION 1: INTRODUCTION AND MOTIVATION    -->
<!------------------------------------------------>

    <section title="Introduction and motivation">
	
	<t>
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. In order to
allow wide 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.
      </t>

      <t>
Ad hoc networks present particular characteristics that should be
taken into account when designing address auto-configuration
protocols. Since existing solutions for IP infrastructure-based
networks (e.g., RFCs 4861, 4862, 3315 etc.) were designed for a
different scope that MANETs, there are several issues that need
to be tackled, mainly (but not
only) the following: 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.
      </t>

      <t>
The first (and so far unique) goal of the AUTOCONF WG has been to
describe a practical addressing model for ad hoc networks and how
nodes in these networks configure their IP addresses
<xref target="I-D.ietf-autoconf-adhoc-addr-model" />. Now it is the
time to start working on solutions (the WG is currently considering
to re-charter to work on actual solutions). In previous discussions, the
group has identified two possible scenarios of MANET where IP address
auto-configuration is required:

      <list style="symbols">

	  <t>
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.
       </t>

	  <t>
Connected 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.
        </t>

      </list>

      </t>

      <t>
This draft aims at providing a survey on most of the previously
proposed IP autoconfiguration solutions, trying to serve as a useful
reference for the AUTOCONF WG during the problem space analysis and
solution design phases.
      </t>

	<t>
In the following section, we provide a description of several existing
AUTOCONF solution proposals. 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. Note that
this is just one of the many possible solution classifications that could
have been followed. In order to provide additional information, we
evaluate each of the analysed solutions against some of the evaluation
considerations proposed in <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />.
      </t>

    </section>


<!------------------------------------------------>
<!--  SECTION 2: IP ADDRESS AUTOCONF PROTOCOLS  -->
<!------------------------------------------------>

    <section anchor="sec:autoconf_protocols" title="IP address
	auto-configuration protocols">

      <t>
In this section we briefly describe some of the existing proposals for
IP address autoconfiguration, classifying them according to some of
the evaluation considerations introduced in <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />.
      </t>


<!------------------------------------------------>
<!--  SECTION 2.1: STANDALONE solutions         -->
<!------------------------------------------------>

	 <section title="Solutions for Standalone MANET scenarios">


<!------------------------------------------------>
<!--  SECTION 2.1.1: WITHOUT Merging support    -->
<!------------------------------------------------>

	  <section title="No merging support">

<!------------------------------------------------>
<!--  SECTION 2.1.1.1: PERKINS et al.           -->
<!------------------------------------------------>

	   <section title="IP address Autoconfiguration for Ad Hoc
	     Networks (Perkins et al.)">

	    <t>
This address autoconfiguration mechanism -- proposed in <xref
target="I-D.perkins-manet-autoconf" /> -- 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.
          </t>

	    <t>
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.
          </t>

	    <t>
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 Non-unique Address Detection 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,
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.
          </t>

	    <t>
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 Non-unique Address Detection procedure
is performed only when the node initially chooses the tentative IPv6
address to use, this mechanism does not support merging of MANETs.
          </t>

	    <t>
AREQ and AREP are a modification of the standard ICMPv6 Neighbour
Advertisement and Neighbour Solicitation messages, respectively.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">
	        <t>
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.
              </t>

		  <t>
Routing protocols' dependency: the solution is routing protocol
independent.
              </t>

		  <t>
Address uniqueness: the proposed solution makes use of Non-unique
Address Detection in the initial address assignment phase.
              </t>

		  <t>
Distributed/centralised approach: the solution does not make use of
any centralised server.
              </t>

		  <t>
Merging support: the solution does not support merging.
              </t>

		  <t>
Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
              </t>

		  <t>
Protocol overhead: the solution requires additional message flooding
(AREQ messages) to verify if an IP address is being used in the
MANET.
              </t>

	      </list>

          </t>

	   </section>


	  </section>


<!------------------------------------------------>
<!--  SECTION 2.1.2: WITH Merging support       -->
<!------------------------------------------------>

	  <section title="Merging support">

<!------------------------------------------------>
<!--  SECTION 2.1.2.1: WENIGER et al.           -->
<!------------------------------------------------>

	   <section title="IPv6 Autoconfiguration in Large Scale Mobile
	     Ad-Hoc Networks (Weniger et al.)">

	    <t>
The solution described in <xref target="WZ+02" /> extends the
Neighbour Discovery and IPv6 Stateless Address Autoconfiguration
mechanisms to work in multi-hop wireless networks.
          </t>

	    <t>
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.
          </t>

	    <t>
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:

            <list style="symbols">

		  <t>
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.
              </t>

	        <t>
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 Non-unique Address Detection has to be
performed between the leader nodes within the entire Ad hoc
network. An algorithm is provided for the election of leader nodes.
              </t>

	      </list>

          </t>

	    <t>
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.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">
	        <t>
MANET scenario: the solution targets standalone MANETs,
although it could be possible to extend it to support the assignment
of global IPv6 addresses.
              </t>

		  <t>
Routing protocols' dependency: the solution does not depend on any
particular ad-hoc routing protocol, but it may be advantageous the
routing protocol 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.
              </t>

		  <t>
Address uniqueness: the proposed solution makes use of a periodic
Non-unique Address Detection 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.
              </t>

		  <t>
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.
              </t>

		  <t>
Merging support: the solution support merging, by leader nodes
performing periodic Non-unique Address Detection that ensures the
uniqueness of Subnet IDs.
              </t>

		  <t>
Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
              </t>

		  <t>
Protocol overhead: the solution requires additional message flooding
within a bounded area of radius r_s hops.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.1.2.2: JEONG et al.             -->
<!------------------------------------------------>

	   <section title="Ad Hoc IP Address Autoconfiguration (Jeong et
	     al.)">

	    <t>
The solution described in <xref
target="I-D.jeong-adhoc-ip-addr-autoconf" /> proposes two Non-unique
Address Detection mechanisms. The first one -- called "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
Non-unique Address Detection mechanism -- called "weak DAD" -- is
always executed by nodes taking part in ad hoc routing in order to
prevent any address conflicts due to mergers.
          </t>

	    <t>
Assumptions:

The solution assumes that initially a random address is selected by ad
hoc nodes using the reserved IPv6 prefix MANET_PREFIX.
          </t>

	    <t>
Approach description:

This approach includes two different Non-unique Address Detection
mechanisms:

            <list style="symbols">

		  <t>
Strong DAD: based on <xref target="I-D.perkins-manet-autoconf"
/>. Strong DAD is done initially after an ad hoc node has chosen
randomly an IP address and it is trying to 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. <xref target="I-D.jeong-adhoc-ip-addr-autoconf" /> describes
the message format, using ICMPv6 messages (new types are
defined). <xref target="I-D.jeong-manet-aodv-addr-autoconf" />
describes the message format for AODV.
              </t>

	        <t>
Weak DAD: based on <xref target="Vai02" />. 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.
              </t>

	      </list>

          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">
	        <t>
MANET scenario: the solution targets standalone MANETs.
              </t>

		  <t>
Routing protocols' dependency: the solution does not depend on any
particular ad-hoc routing protocol.
              </t>

		  <t>
Address uniqueness: the proposed solution makes use of two different
Non-unique Address Detection mechanisms.
              </t>

		  <t>
Distributed/centralised approach: the solution is distributed. It does
not make use of either any centralised servers or special nodes.
              </t>

		  <t>
Merging support: the solution supports merging by looking for
duplicate addresses on an ongoing basis.
              </t>

		  <t>
Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
              </t>

		  <t>
Protocol overhead: The Strong DAD mechanism requires additional
message flooding (AREQ messages) to find out whether there is a
duplication conflict or not. The Weak DAD mechanism introduces also
some protocol overhead since the Key extension (20 bytes) is appended
to each control packet of the ad hoc routing protocol.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.1.2.3: Moshin et al.            -->
<!------------------------------------------------>

	   <section title="IP Address Assignment in a Mobile Ad Hoc
	     Network (Mohsin et al.)">

	    <t>
This proposed solution <xref target="MP+02" /> 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.
          </t>

	    <t>
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.
          </t>

	    <t>
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.
          </t>

	    <t>
Nodes synchronise the IP blocks which they store to keep track of the
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.
          </t>

	    <t>
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.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: This proposed solution targets standalone MANETs.
              </t>

		  <t>
Routing protocols' dependency: This proposed solution is independent
of the underlying routing protocol.
              </t>

		  <t>
Address uniqueness: The proposed solution does not use any Non-unique
Address Detection mechanism.
              </t>

		  <t>
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.
              </t>

		  <t>
Merging support: Thanks to employing the buddy systems, the proposed
solution supports merging. In case of merging, the process of buddies
splitting allows the merging node to be assigned an IP address and an
IP pool.
              </t>

		  <t>
Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
              </t>

		  <t>
Protocol overhead: 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.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.1.2.4: Tayal et al.             -->
<!------------------------------------------------>

	   <section title="An Address Assignment for the Automatic
	     Configuration of Mobile Ad Hoc Networks (Tayal et al.)">

	    <t>
The solution described in <xref target="TP+04" /> is very similar to
the previous one (<xref target="MP+02" />), sharing the idea (also
used by others) of nodes assignment of half of their address pools to
newly arrived nodes that request IP addresses.
          </t>

	    <t>		
In a more recent work <xref target="chen" /> it has been proposed a
different way of managing the address pool. The authors propose to
take advantage of node mobility and make the system achieve roughly
even distribution of the free addresses amongs all nodes in the
MANET. In order to achieve this goal a redistribution is performed
everytime there is a process of address allocation, the new joining
node redistributes evenly among its neighbors and itself the free 
addresses that were previously held by its neighbors.
          </t>

	    <t>
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.
          </t>

	    <t>
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.
          </t>

	    <t>
This solution defines mechanisms to handle different scenarios, such
as network partitioning and merging, message loss, etc. More details
can be found in <xref target="TP+04" />.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: This proposed solution targets standalone scenarios.
              </t>

		  <t>
Routing protocols' dependency: This proposed solution is independent
of the underlying routing protocol.
              </t>

		  <t>
Address uniqueness: The proposed solution does not use any Non-unique
Address Detection mechanism, since the uniqueness of the solution is
based on the split of the initially available IP address pool.
              </t>

		  <t>
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.
              </t>

		  <t>
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.
              </t>

		  <t>
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.
              </t>

		  <t>
Protocol overhead: the solution requires some message flooding to
search nodes that have an address pool available.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.1.2.5: NOAOLSR                  -->
<!------------------------------------------------>

	  <section title="No Overhead Autoconfiguration OLSR (Mase et al.)">

	    <t>
This solution <xref target="I-D.mase-manet-autoconf-noaolsr" />
proposes some passive Non-unique Address Detection techniques to be
used in MANETs running the OLSR protocol. It utilises the Passive
Duplicate Address Detection concept <xref target="Wen03" />, <xref
target="Wen05" />, 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.
          </t>

	    <t>
This is one of the multiple drafts proposing the use of PDAD for OLSR
<xref target="I-D.weniger-autoconf-pdad-olsr" />, <xref
target="I-D.clausen-olsr-passive-dad" />.
          </t>

	    <t>
Assumptions:

The protocol assumes the existence of a Non-unique Address
Detection-based IP address generation mechanism.
          </t>

	    <t>
Approach description:

The solution proposes an ongoing duplicate address detection
mechanism, checking for inconsistencies in the 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).
          </t>

	    <t>
Different Non-unique Address Detection 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.
          </t>

	    <t>
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.
         </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: This Non-unique Address Detection technique is to be
used in standalone MANETs.
              </t>

		  <t>
Routing protocols' dependency: this mechanism depends on OLSR, since
the Non-unique Address Detection technique is designed for MANETs
running the OLSR protocol.
              </t>

		  <t>
Address uniqueness: The proposed mechanism assumes the existence of a
Non-unique Address Detection-based address assignment mechanism.
              </t>

		  <t>
Distributed/centralised approach: the proposed solution follows a
distributed approach given that all nodes have the same responsibility
detecting address conflicts.
              </t>

		  <t>
Merging support: The proposed solution supports merging, enabling
nodes to continuously detect duplicate addresses by analysing received
routing protocol messages.
              </t>

		  <t>
Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
              </t>

		  <t>
Protocol overhead: the proposed mechanism does not add any additional
messages but it checks for inconsistencies in the routing protocol
messages to diagnose duplicate address detection.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.1.2.6: PDAD-OLSR                -->
<!------------------------------------------------>

	   <section title="PDAD-OLSR: Passive Duplicate Address
	     Detection for OLSR (Weniger et al.)">

	    <t>
This solution <xref target="I-D.weniger-autoconf-pdad-olsr" />
proposes a passive Non-unique Address Detection mechanism for
configured address uniqueness maintenance in MANETs running the OLSR
protocol.
          </t>

	    <t>
Assumptions:

The protocol assumes the existence of a Non-unique Address
Detection-based address generation mechanism.
          </t>

	    <t>
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.
          </t>

	    <t>
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).
          </t>

	    <t>
The solution proposes eight different algorithms for conflict detection:
            <list style="symbols">

	        <t>
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.
	        </t>

	        <t>
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 address is
detected.  This mechanism allows to detect conflicts between nodes
that are any number of hops away from each other.
	        </t>

	        <t>
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.
	        </t>

	        <t>
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.
	        </t>

	        <t>
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.
	        </t>

	        <t>
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.
	        </t>

	        <t>
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.
	        </t>

	        <t>
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 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.
	        </t>

            </list>

          </t>

	    <t>
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.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: The solution targets standalone MANETs. Although it
proposes a Non-unique Address Detection 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.
              </t>

		  <t>
Routing protocols' dependency: this solution requires OLSR, since the
set of proposed techniques are applicable to MANETs running the OLSR
protocol.

              </t>

		  <t>
Address uniqueness: The proposed mechanism assume the existence of an
address assignment mechanism which may assign duplicate addresses.
              </t>

		  <t>
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.
              </t>

		  <t>
Merging support: The proposed solution supports merging given that it
enables nodes to continuously detect duplicate addresses in the
network by analysing received routing protocol messages.
              </t>

		  <t>
Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
              </t>

		  <t>
Protocol overhead: the solution enables nodes to passively detect
duplicate addresses in the network by analysing received routing
protocol messages and thus does not cause any overhead.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.1.2.7: PDAD on demand           -->
<!------------------------------------------------>

	   <section title="Passive Duplicate Address Detection for
	     On-demand Routing Protocols (Jeong et al.)">

	    <t>
This solution <xref
target="I-D.jeong-autoconf-pdad-on-demand" /> proposes a set of
Non-unique Address Detection 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.
          </t>

	    <t>
Assumptions:

The protocol assumes the existence of an on-demand routing protocol
and a Non-unique Address Detection-based IP address configuration
mechanism.
          </t>

	    <t>
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.
          </t>

	    <t>
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).
          </t>

	    <t>
The authors propose different mechanisms for detecting address
conflicts:

            <list style="symbols">

	        <t>
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.
              </t>

	        <t>
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.
              </t>

	        <t>
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.
              </t>

	        <t>
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.
              </t>

	        <t>
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.
              </t>

            </list>

          </t>

	    <t>
The document does not include how to perform address conflict
resolution.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: The solution targets standalone MANETs. Although the
proposed Non-unique Address Detection 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.
              </t>

		  <t>
Routing protocols' dependency: The set of proposed techniques supposes
the existence of an on-demand ad-hoc routing protocol.
              </t>

		  <t>
Address uniqueness: The proposed mechanism assumes the existence of a
Non-unique Address Detection-based address assignment mechanism.
              </t>

		  <t>
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.
              </t>

		  <t>
Merging support: The proposed solution supports merging given that it
enables nodes to continuously detect duplicate addresses in the
network by analysing received routing protocol messages.
              </t>

		  <t>
Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
              </t>

		  <t>
Protocol overhead: the solution enables nodes to passively detect
duplicate addresses in the network by analysing received routing
protocol messages and thus does not cause any overhead.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.1.2.8: ZHOU et al.              -->
<!------------------------------------------------>

	   <section title="Prophet Address Allocation for Large Scale
	     MANETs (Zhou et al.)">

	    <t>
The mechanism defined in <xref target="ZNM+03" /> 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
the use of a Non-unique Address Detection mechanism can be avoided.
          </t>

          <t>
Another proposal sharing the idea of avoiding duplication is
presented in <xref target="pongpaibool" /> where to avoid address
duplication it is assumed that the IPv6 address of a node includes 
its Home Subnet identifier (i.e., a subnet where the node
originally belongs to) as part of the 64-bit Host identifier.
This is because "at home administration" guarantees that nodes
belonging to the same home subnet have different Host identifier.
          </t>

	    <t>
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:

            <list style="symbols">

		  <t>
The interval between two occurrences of the same number in a sequence
is extremely long.
              </t>

	        <t>
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.
              </t>

	      </list>

These properties may be satisfied if the space of available addresses
is large, so it is relatively easy to achieve in IPv6.
          </t>

	    <t>
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.
          </t>

	    <t>
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.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: the solution targets standalone MANETs.
              </t>

		  <t>
Routing protocols' dependency: the solution is routing protocol
independent.
              </t>

		  <t>
Address uniqueness: the proposed solution does not define any
Non-unique Address Detection mechanism. The address uniqueness is
ensured by using a "prophet" allocation with a very low probability of
collision.
              </t>

		  <t>
Distributed/centralised approach: the solution does not make use of
any centralised server.
              </t>

		  <t>
Merging support: the solution proposes different mechanisms to support
merging.
              </t>

		  <t>
Prefix assignment support: the solution supports the assignment of
IPv6 prefixes to nodes, by using the DHCP prefix delegation.
              </t>

		  <t>
Protocol overhead: only few additional messages are required to assign
addresses to new nodes.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.1.2.9: Nesargi et al.           -->
<!------------------------------------------------>

	   <section title="MANETconf: Configuration of Hosts in a Mobile
Ad Hoc Network (Nesargi et al.)">

	    <t>
In this autoconfiguration mechanism -- proposed in
<xref target="nesargi" /> -- each node maintains a list of all IP
addresses in use in the network and a new node (i.e., requester)
obtains a candidate IP address through an existing node in the
network (i.e., initiator). If the proposal is accepted by all
the nodes that are part of the MANET, the proposed address is
assigned to the newly arrived node. Otherwise, another
candidate IP address is chosen and the process is
repeated (for a finite number of times).
          </t>

	    <t>
Assumptions:

It assumes that the MANET starts with a single node initiating
the configuration process.
          </t>

	    <t>
Approach description:

This solution basically works as follows: 

Each node maintains a list of all the addresses in use in the
network. When a node joins the system, it requests an address
through one of its neighbours that have joined the system. This
neighbour (i.e., the initiator) chooses an address that is
free according to its address list and query through the network
for the permission to assign the chosen address. If at least one
response is negative, another address is selected and another
query is distributed. The assignment is granted only if a positive 
ack is received from all known nodes. The initiator makes this
allocation permanent by flooding a second message sent once it
has received confirmation from all known nodes. So, IP address
allocation is similar to a two-phase commit.
          </t>

	    <t>
In order to detect partitions and merges every node remember
its address and its MANET (i.e., partition) identifier. A network
partition is detected when a initiator fails to obtain permission
for an address assignment for a new node from all the other nodes
in the network (i.e., one or more nodes do not answer). After the 
detection, every node in each partition cleans up the addresses in
other partitions. The nodes then agree on a new partition
identifier. 
          </t>

	    <t>
This partition identifier is used to detect merges when two
previously distant nodes come within communication range of each
other and exchanger their partition identities. When partitions
merge, nodes in different partitions are required to exchange
their set of allocated addresses so that duplicates can be
detected. 
            </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">
	        <t>
MANET scenario: the solution targets standalone MANETs.
              </t>

		  <t>
Routing protocols' dependency: the solution assume the existence
of a proactive routing protocol to handle network partitions and
merges.
              </t>

		  <t>
Address uniqueness: the proposed solution makes use of
Non-unique Address Detection every time a new address is
assigned to a node.
              </t>

		  <t>
Distributed/centralised approach: the solution does not make
use of any centralised server.
              </t>

		  <t>
Merging support: nodes detect merges by receiving messages
from nodes with a different partition identifier. 
              </t>

		  <t>
Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
              </t>

		  <t>
Protocol overhead: the solution requires at least flooding
two messages along the address assignment process. One asking
if a candidate address is perceived as unallocated by the rest
of the nodes, and a second one making the assignation permanent.

              </t>

	      </list>

          </t>

	   </section>

	  </section>

	 </section>


<!------------------------------------------------>
<!--  SECTION 2.2: CONNECTED solutions          -->
<!------------------------------------------------>

	 <section title="Solutions for Connected MANET scenarios">


<!------------------------------------------------>
<!--  SECTION 2.2.1: WITHOUT Merging support    -->
<!------------------------------------------------>

	  <section title="No merging support">

<!------------------------------------------------>
<!--  SECTION 2.2.1.1: RUFFINO et al.           -->
<!------------------------------------------------>

	   <section title="Automatic Configuration of IPv6 Addresses for
	     Nodes in a MANET with Multiple Gateways (Ruffino et al.)">

	    <t>
This proposed solution <xref
target="I-D.ruffino-manet-autoconf-multigw" /> 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.
          </t>

	    <t>
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 Non-unique Address Detection
method. Neither the procedure followed to obtain this address, nor the
Non-unique Address Detection method used to check its uniqueness, are
defined in this solution.
          </t>

	    <t>
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).
          </t>

	    <t>
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 Non-unique Address Detection mechanism, while
it is suggested to use a generic MANET Non-unique Address Detection
procedure, such as <xref target="I-D.perkins-manet-autoconf"/>, to
verify the uniqueness of MANET-local and global addresses.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: the solution targets connected MANETs.
              </t>

		  <t>
Routing protocols' dependency: the solution requires OLSR to be run in
the network.
              </t>

		  <t>
Address uniqueness: the proposed solution does not define any
Non-unique Address Detection mechanism, although requires some generic
one to be used to ensure the uniqueness of MANET-local and global
addresses.
              </t>

		  <t>
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.
              </t>

		  <t>
Merging support: the solution partially supports merging, since the
scenario in which new gateways join the network as a result of a
merger is considered. However, since no Non-unique Address Detection
mechanism is defined, the solution does not describe how to deal with
IPv6 address duplication after merging of different MANETs.
              </t>

		  <t>
Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
              </t>

		  <t>
Protocol overhead: the solution adds some overhead. Since Gateways
broadcast prefix information.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.2.1.2: Clausen et al.           -->
<!------------------------------------------------>

	   <section title="Simple MANET Address Autoconfiguration
	     (Clausen et al.)">

	    <t>
This proposed solution <xref
target="I-D.clausen-manet-address-autoconf" /> 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.
          </t> 

	    <t>
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.
          </t>

	    <t>
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 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.
          </t>

	    <t>
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.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: This proposed solution targets connected MANET
scenarios.
              </t>

	        <t>
Routing protocols' dependency: This proposed solution uses OLSR,
typically extending OLSR messages, however it is not dependent on the
routing protocol. Although the proposed solution is open to any
routing protocol, the fact that periodical beacons are used requires a
proactive routing protocol.
              </t>

	        <t>
Address uniqueness: The proposed solution uses a Non-unique Address
Detection mechanism to avoid conflicts in IP address assignment. In
global address allocation, using a Non-unique Address Detection
mechanism is an option but the proposed solution can function without
a Non-unique Address Detection mechanism if the modified DHCP proxy
approach is followed. While in temporary address allocation, a limited
Non-unique Address Detection mechanism is used with the neighbourhood
to resolve any conflict when assigning temporary addresses sequences
to MANET nodes.
              </t>

	        <t>
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.
              </t>

	        <t>
Merging support: This proposed solution has no merging support. 
              </t>

	        <t>
Prefix assignment support: The proposed solution allows prefix
assignment through using DHCP.
              </t>

	        <t>
Protocol overhead: 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.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.2.1.3: EMAP                     -->
<!------------------------------------------------>

	   <section title="Extensible MANET Auto-configuration Protocol
	     (EMAP) (Ros et al.)">

	    <t>
The Extensible MANET Auto-configuration Protocol (EMAP) <xref
target="I-D.ros-autoconf-emap" /> 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, proxies, and
authentication entities.
          </t>

	    <t>
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).
          </t>

	    <t>
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.
          </t>

	    <t>
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.
          </t>

	    <t>
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.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: This proposed solution is designed for standalone
MANETs and connected MANETs.
              </t>

		  <t>
Routing protocols' dependency: Although EMAP is envisioned to be
integrated with unicast routing protocols like DYMO or OLSRv2, it may
be implemented as a standalone daemon.
              </t>

		  <t>
Address uniqueness: The proposed solution uses a Non-unique Address
Detection mechanism during the autoconfiguration of MANET local
addresses.
              </t>

		  <t>
Distributed/Centralised approach: The proposed solution is a
distributed solution in the sense of not being based on any DHCP
servers.
              </t>

		  <t>
Merging support: No special merging mechanisms are explained in this
solution. However, no in-service Non-unique Address Detection is used
which makes the merging support not feasible.
              </t>

		  <t>
Prefix assignment support: This solution employs IPv6 prefixes, where
gateway nodes are responsible for advertising their prefixes.
              </t>

		  <t>
Protocol overhead: the solution adds certain overhead, 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.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.2.1.4: WAKIKAWA et al.          -->
<!------------------------------------------------>

	   <section title="Global Connectivity for IPv6 Mobile Ad Hoc
	     Networks (Wakikawa et al.)">

	    <t>
The solution described in <xref target="I-D.wakikawa-manet-globalv6"
/> 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 routing protocol.
          </t>

	    <t>
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.
          </t>

	    <t>
Approach description:

This mechanism <xref target="I-D.wakikawa-manet-globalv6" /> is
similar to <xref target="I-D.jelger-manet-gateway-autoconf-v6" /> 
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.
          </t>

	    <t>
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 Non-unique Address
Detection mechanism has been performed for that routable local address
(e.g. using the mechanism defined in <xref
target="I-D.perkins-manet-autoconf" /> and <xref target="SBP+02" />),
so it is assumed that the global address would be also unique.  If
not, the node may perform another Non-unique Address Detection
mechanism for this global address.
          </t>

	    <t>
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 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.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

		    <t>
MANET scenario: the solution targets connected MANETs.
              </t>

		  <t>
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.
              </t>

		  <t>
Address uniqueness: It is assumed that the global address would be
also unique. If not, the node may perform a Non-unique Address
Detection mechanism for this global address. In any case the
Non-unique Address Detection mechanism is considered out of scope.

              </t>

		  <t>
Distributed/centralised approach: The proposed solution uses a
distributed approach where nodes do not solicit any centralised server
for IP address assignment.
              </t>

		  <t>
Merging support: No special merging mechanisms are discussed in this
solution. Also, no in-service Non-unique Address Detection is used
which makes the merging support not feasible.
              </t>

		  <t>
Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
              </t>

		  <t>
Protocol overhead: depends on the approach utilised. 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.
              </t>

	      </list>

          </t>

	  </section>

<!------------------------------------------------>
<!--  SECTION 2.2.1.5: MRAN                     -->
<!------------------------------------------------>

	   <section title="Multihop Radio Access Network (MRAN) Protocol
	     Specification (Hofmann)">

	    <t>
This proposed solution <xref target="I-D.hofmann-autoconf-mran" />
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 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.
          </t>

	    <t>
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.
          </t>

	    <t>
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 Non-unique Address Detection. 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 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.

          </t>

	    <t>
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).
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: This proposed solution targets connected MANET
scenarios enabling mobile nodes to communicate with correspondent
nodes in the Internet.
              </t>

		  <t>
Routing protocols' dependency: This proposed solution works
independent of the MANET routing protocol.
              </t>

		  <t>
Address uniqueness: The proposed solution may use a Non-unique Address
Detection mechanism.
              </t>

		  <t>
Distributed/Centralised approach: The proposed solution uses a
distributed approach, where it does not solicit any centralised server
for IP address assignment.
              </t>

		  <t>
Merging support: No special merging mechanisms are discussed in this
solution. Also, no in-service Non-unique Address Detection is used
which makes the merging support not feasible.
              </t>

		  <t>
Prefix assignment support: This proposed solution supports prefixes
assignment, where the different gateways are responsible for IPv6
prefixes advertisements.
              </t>

		  <t>
Protocol overhead: the 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.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.2.1.6: VANET autoconf           -->
<!------------------------------------------------>

	   <section title="Automatic IP Address Configuration in VANETs
	     (Fazio et al.) ">

	    <t>
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 <xref target="FPD+06" />
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.
          </t>

	    <t>
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.
          </t>

	    <t>
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
normal nodes ask leaders for a valid IP address whenever they need to
be configured.
          </t>

	    <t>
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.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: The proposed solution targets connected MANET
scenarios, enabling mobile nodes (vehicles) to communicate with
correspondent nodes on the Internet.
              </t>

		  <t>
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.
              </t>

		  <t>
Address uniqueness: The proposed solution does not employ any
Non-unique Address Detection mechanisms, however it guarantees address
uniqueness for each configured node.
              </t>

		  <t>
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.
              </t>

		  <t>
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.
              </t>

		  <t>
Prefix assignment support: This proposed solution does not employ any
IPv6 prefix assignment to nodes.
              </t>

		  <t>
Protocol overhead: 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 Non-unique Address Detection mechanisms due to the distributed
DHCP functionality among leader nodes, which helps in limiting the
signalling overhead.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.2.1.7: Ahn et al.               -->
<!------------------------------------------------>

	   <section title="Address Configuration Using Address
		Pool (Ahn et al.)">

	    <t>
This address autoconfiguration mechanism -- proposed in
<xref target="I-D.ahn-autoconf-addresspool" /> -- is based on the
concept of address pool allocation in connected MANETs scenarios.
This mechanism allows stable and fast global IP address
configuration based on the DHCP.
          </t>

	    <t>
Assumptions:

It is assumed that the Internet gateway acts a DHCP server having
the pool of IP addresses and assigning a part of this IP address
pool to each node requesting an IP address. It is also assumed
that each node having an address pool could assign a part of this
address pool to other IP address requesting nodes. Each node then
plays the role of a DHCP server. The lifetime of the address pool
is assumed to be infinite.
          </t>

	    <t>
Approach description:

This solution basically works as follows: the Internet gateway
periodically broadcasts Router Advertisement (RA) messages to the
entire MANET and each MANET node receiving the RA message can
request for IP addresses through sending a unicast DHCP_Request
message to the Internet gateway. When the Internet gateway received
the DHCP_Request message, it allocates a part of its address pool
and sends it to the address requesting node in a DHCP_Reply message.
At the same time, any intermediate node receiving the DHCP_Request
message and having a big address pool intercepts the message and
allocates a part of its address pool instead of the Internet
gateway and sends it to the address requesting node in a
DHCP_Reply message. Each node with the allocated address pool
assigns one address to its interface and keeps the rest of the
address pool for later allocation to other MANET nodes requesting
addresses.
          </t>

	    <t>
No renewal takes place for the allocated address pool, as the
valid-lifetime field in the DHCP_Reply message is set to an
infinite value reflecting an infinite use of the address pool.
However, the Internet gateway broadcasts to the entire MANET an
Address Pool Release Request (APRR) message when the size of its
address pool arrives below a pre-defined threshold. Each node
receiving the APRR message replies by an Address Pool Release
Reply (APRP) message allowing the Internet gateway to know which
addresses are being used or assigned.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: the solution targets connected MANETs, however,
it could be applied to standalone MANETs if some dedicated nodes
are previously allocated address pools in order to allocate part
of these pools to other IP requesting nodes in a standalone MANET.
              </t>

		  <t>
Routing protocols' dependency: the solution is routing protocol
independent.
              </t>

		  <t>
Address uniqueness: the proposed solution guarantees address
uniqueness since each node is assigned an address from an address
pool allocated from a global address pool.
              </t>

		  <t>
Distributed/Centralised approach: the solution is partially
distributed, where it relies on a centralised DHCP server and at
the same time each node plays the role of a DHCP server.
              </t>

		  <t>
Merging support: the solution does not support merging.
              </t>

		  <t>
Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes.
              </t>

		  <t>
Protocol overhead: the solution requires additional messages
flooding by the Internet gateway for announcing its address pool
and to get information on the different address pools assignment.
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.2.1.8: Lee et al.               -->
<!------------------------------------------------>

	   <section title="Address Autoconfiguration for MANET
		with Multiple MBRs (Lee et al.)">

	    <t>
This address autoconfiguration mechanism -- proposed in
<xref target="I-D.jaehwoon-autoconf-mmbr" /> -- is based on PMIPv6
(Proxy Mobile IPv6) mechanism in which a Local Mobility Anchor
(LMA) is located and acts as a Home Agent (HA) while multiple MBRs
(MANET Border Router) are used for scalable and reliable
communication between each MANET node and the external network.
The proposed solution prevents against the session termination or
the non-optimal paths use during packet transmission when the MANET
node changes the MBR. 
          </t>

	    <t>
Assumptions:

It is assumed that all MBRs advertise the same network prefix in
the connected MANET, and that each node configures its IP address
using the stateless address autoconfiguration mechanism making
use of the advertised network prefix.
          </t>

	    <t>
Approach description:

This solution basically works as follows: since all MBRs advertise
the same network prefix, when a node moves it can still use its
pre-configured address. This allows for maintaining the existing
sessions even with node movement and allows for finding an
optimised path by the node without changing the IP address. Each
MBR periodically advertises Scope-Extended Router Advertisement
(SERA) messages to the entire MANET. This message includes the
network prefix assigned to the MANET and the address of the MBR
originating the message. A MANET node connecting for the first
time receives the SERA message and configures the IPv6 address
of its MANET interface using the stateless address
autoconfiguration mechanism based on the node MAC address, the
obtained network prefix and the network prefix length. Then the
node sets the originating MBR as its default gateway and stores
in its routing table the distance from this MBR as well as the
next-hop to this MBR (which is extracted from the source IP
address field of the received message). The node then sends a
Registration Request (RR) message to this MBR, where this
latter sends a Proxy Binding Update (PBU) message with the
MANET node to the LMA. After that, a tunnel between the LMA
and MBR is established for the MANET node.
          </t>

	    <t>
Since SERA messages are periodically advertised by each MBR, a
node can receive multiple SERA messages advertised by the same
MBR but through more optimal paths or advertised by new MBR
than the default one. In the former case, the node could update
the next-hop to its default MBR with no need to change the node
address. In the latter case, the node can update its default
MBR without changing its IP address since all MBRs advertise
the same network prefix. The node only needs to send an RR
message to the new MBR for the binding with this it following
the same binding process explained above.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: the solution targets connected MANETs.
              </t>

		  <t>
Routing protocols' dependency: the solution is routing protocol
independent, however the routing table is used to store
information about the default gateway, the distance from it
and the next hop to it.
              </t>

		  <t>
Address uniqueness: the proposed solution guarantees address
uniqueness since each node constitutes its IP address using the
stateless IP autoconfiguration approach, employing its MAC
address, the network prefix, and the prefix length.
              </t>

		  <t>
Distributed/Centralised approach: the solution does not make
use of any centralised server, however distributed gateways
are involved.
              </t>

		  <t>
Merging support: the solution does not support merging.
              </t>

		  <t>
Prefix assignment support: the solution allows the assignment of
IPv6 prefixes, where the same IPv6 prefix is broadcast by the
different gateway nodes (MBRs).
              </t>

		  <t>
Protocol overhead: the solution requires additional messages
flooding by MBRs nodes (Scope Extended Router Advertisement
‘SERA’ message).
              </t>

	      </list>

          </t>

	   </section>

<!------------------------------------------------>
<!--  SECTION 2.2.1.9: Boot et al.               -->
<!------------------------------------------------>

	   <section title="Border Router Discovery Protocol (BRDP)
based Address Autoconfiguration (Boot et al.)">

	    <t>
This address autoconfiguration mechanism -- proposed in
<xref target="I-D.boot-autoconf-brdp" /> -- describes a solution
for configuring valid global IPv6 addresses for ad hoc nodes. It
is based on the discovery of MANET Border Routers (MBRs), which
are responsible of advertising topologically valid IPv6 prefixes,
which can then be used by the ad hoc nodes.
          </t>

	    <t>
Assumptions:

It is assumed that there is at least one MBR advertising a valid
global IPv6 address. The Border Router Discovery Protocol (BRDP)
is defined for Border Router discovery. For standalone MANETs,
the solution derives in the use of Unique Local Addresses (ULAs)
generated by the individual MANET routers.
          </t>

	    <t>
Approach description:

This solution basically uses two phases: a) the initial discovery
of one or more Border Routers, and b) the selection of a Border
Router and address autoconfiguration of globally routable IPv6
addresses to be used in conjunction with that Border Router. The BRDP
is a simple distance vector protocol that distributes Border Router
information, where each MANET router selects one or more Border Routers
and forwards the Border Router information in the MANET. It basically
extends the IPv6 Neighbor Discovery Protocol (NDP) to make it carry the
required information (e.g., prefix information).
           </t>

           <t>
BRDP is a derivative of Tree Discovery
<xref target="I-D.thubert-tree-discovery" />. BRDP uses ICMP Router
Advertisement (RA) messages in NDP to distribute Border Router
information by extending it with the Border Router Information Option
(BRIO). BRDP allows MANET Routers to advertise Border Router
reachability, including information for selecting a preferred Border
Router.  A MANET Router selects at least one BRIO from its cache,
for dissemination in the MANET.
           </t>

           <t>
The address generated has a /128 prefix. It is constructed from a
64-bit Interface Identifier -- which is assumed to be unique (it is
not specified how the MANET router generates this identifier,
although several alternative approaches are proposed) --  and a 64-bit
prefix (advertise in the BRIO). The generated 128-bit address is
advertised in the MANET routing system.
           </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: the solution targets connected MANETs.
              </t>

		  <t>
Routing protocols' dependency: the solution is routing protocol
independent. A companion document
<xref target="I-D.boot-brdp-based-routing" /> can be used in a
multi-homed scenario (i.e. multiple MBRs available) to replace
the default route mechanism.
              </t>

		  <t>
Address uniqueness: address uniqueness is assured by the IPv6
address generation mechanisms used. However, details on how to
handle a duplicate address condition are stated as out-of-scope
for the document describing this solution.
              </t>

		  <t>
Distributed/Centralised approach: the solution does not make
use of any centralised server, however distributed gateways
are involved.
              </t>

		  <t>
Merging support: the solution does not support merging (as it
is not specified how to handle duplicate addresses).
              </t>

		  <t>
Prefix assignment support: the solution does not allow
the assignment of IPv6 prefixes.
              </t>

		  <t>
Protocol overhead: the solution requires additional messages
flooding by MBRs nodes (BRIOs).
              </t>

	      </list>

          </t>

	   </section>


	 </section>


<!------------------------------------------------>
<!--  SECTION 2.2.2: WITH Merging support       -->
<!------------------------------------------------>

	 <section title="Merging support">


<!------------------------------------------------>
<!--  SECTION 2.2.2.1: ADJIH et al.             -->
<!------------------------------------------------>

	   <section title="Address Autoconfiguration in Optimized Link
	     State Routing Protocol (Adjih et al.)">

	    <t>
This proposed solution <xref
target="I-D.laouiti-manet-olsr-address-autoconf" /> 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.
          </t>

	    <t>
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.

          </t>

	    <t>
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 Non-unique Address Detection 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 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.
          </t>

	    <t>
The Non-unique Address Detection 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.
          </t>

	    <t>
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.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: This proposed solution targets both standalone and
connected MANETs scenarios.
              </t>

		  <t>
Routing protocols' dependency: This proposed solution depends on the
underlying routing protocol.
              </t>

		  <t>
Address uniqueness: the proposed solution comprises a Non-unique
Address Detection 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.
              </t>

		  <t>
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.
              </t>

		  <t>
Merging support: This proposed solution has a merging 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.
              </t>

		  <t>
Prefix assignment support: This solution does not support IPv6 prefix
assignment to nodes.
              </t>

		  <t>
Protocol overhead: the solution adds low protocol overhead, 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.
              </t>

	      </list>

          </t>

	  </section>

<!------------------------------------------------>
<!--  SECTION 2.2.2.2: CHA et al.               -->
<!------------------------------------------------>

	   <section title="Extended Support for Global Connectivity for
	     IPv6 Mobile Ad Hoc Networks (Cha et al.)">

	    <t>
The solution described in <xref
target="I-D.cha-manet-extended-support-globalv6" /> 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.
          </t>

	    <t>
Assumptions:

The solution assumes that each node has a local_IP_address
configured.
          </t>

	    <t>
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.
          </t>

	    <t>
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. 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.
          </t>

	    <t>
More details can be found in <xref
target="I-D.cha-manet-extended-support-globalv6" />.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: the solution targets connected MANETs.
              </t>

		  <t>
Routing protocols' dependency: although the protocol is devised as an
extension to AODV, it could be applicable to proactive routing
protocols.

              </t>

		  <t>
Address uniqueness: since non-duplicate addresses are assigned to ad
hoc nodes, the proposed solution is Non-unique Address
Detection-free.
              </t>

		  <t>
Distributed/centralised approach: the solution makes use of
centralised servers (gateways) in order to assign IP global
addresses.

              </t>

		  <t>
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.

              </t>

		  <t>
Prefix assignment support: the solution does not support the
assignment of IPv6 prefixes to nodes.
              </t>

		  <t>
Protocol overhead: the solution adds certain protocol overhead, 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.
              </t>

	      </list>

          </t>

	  </section>

<!------------------------------------------------>
<!--  SECTION 2.2.2.3: Jelger et al.            -->
<!------------------------------------------------>

	   <section title="Gateway and Address Autoconfiguration for
	     IPv6 Adhoc Networks (Jelger et al.)">

	    <t>
This proposed solution <xref
target="I-D.jelger-manet-gateway-autoconf-v6" /> 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 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.
          </t>

	    <t>
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.
          </t>

	    <t>
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
Non-unique Address Detection mechanism is needed in this approach, as
there is a very little probability of address duplication when EUI is
used.
          </t>

          <t>
More details can be found in <xref target="jelger2005" />.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: This proposed solution targets connected MANETs
scenarios.
              </t>

	        <t>
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.
              </t>

	        <t>
Address uniqueness: The proposed solution does not depend on a
Non-unique Address Detection procedure or mechanism.
              </t>

	        <t>
Distributed/Centralised approach: The proposed solution is distributed
in the sense of not employing any centralised DHCP server.
              </t>

	        <t>
Merging support: Although no Non-unique Address Detection 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.
              </t>

	        <t>
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.
              </t>

	        <t>
Protocol overhead: depends 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 Non-unique Address Detection mechanism
is needed in this solution, this helps in limiting the signalling and
hence the overhead.
              </t>

            </list>

          </t>

	  </section>

<!------------------------------------------------>
<!--  SECTION 2.2.2.4: Templin                  -->
<!------------------------------------------------>

	   <section title="VET, SEAL, RANGER (Templin
	     et al.)">

            <t>
NOTE from authors: this section needs further revision to catch
up with all the updates of Templin proposals.
            </t>

	    <t>
Here we refer to a set of different documents that provide
functionalities that can be used to enable IPv6 address
autoconfiguration in MANETs. RFC5558 <xref target="RFC5558" />
specifies a Virtual Enterprise Traversal (VET) abstraction for
autoconfiguration and operation of routers in enterprise networks.
Enterprise networks connect routers over various link types. Since
certain MANETs can be considered as a challenging example of an
enterprise network, the mechanisms described in this document can
be applied to provide MANETs with IP address autoconfiguration
capabilities. This document has evolved a lot from its previous
versions (and companion documents, such as
<xref target="I-D.templin-autoconf-multilink" /> and <xref
target="I-D.templin-autoconf-virtual" />, in which the author started
to define an architecture in which MANET Routers were attached to an
imaginary shared link (called "virtual ethernet") that connected all
the MRs in the MANET. Other documents that complement VET are SEAL
<xref target="RFC5320" /> and RANGER <xref target="RFC5720" />.
          </t>

	    <t>
Assumptions:

It is assumed the existence of Enterprise Border Gateways (EBRs), that
are routers that connect the enterprise network to provider networks
and can delegate addresses/prefixes to other EBRs within the
enterprise.
          </t>

          <t>
Approach description: 

Regarding the applicability of the document to MANETs, it defines
the Virtual Enterprise Traversal (VET), which is an abstraction that
uses IP-in-IP encapsulation to span a multi-link enterprise in a
single (inner) IP hop. VET interfaces are Non-Broadcast, Multiple
Access interface used for VET, which encapsulate each inner IP packet
in any mid-layer headers plus an outer IP header then forwards it on
an underlying interface such that the TTL/Hop Limit in the inner
header is not decremented as the packet traverses the enterprise
network. In this way, the VET interface presents an automatic
tunnelling abstraction that represents the enterprise as a single IP
hop.
          </t>


	    <t>
In order to autoconfigure a VET interface, the interface is first
initialised (a link-local address is configured on the interface), then
border routers (Enterprise Border Gateways, EBGs) are discovered, and
last, IPv6 SLAAC is run on top of the VET. EBGs plays the role of
access routers (i.e., send Router Advertisements), so standard IPv6
SLAAC mechanisms can be used to configure VET interfaces. DHCPv6
prefix delegation can also be used to configure a VET interface.
          </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">

	        <t>
MANET scenario: the solution targets connected MANETs.
              </t>

		  <t>
Routing protocols' dependency: the solution is routing protocol
independent.
              </t>

		  <t>
Address uniqueness: the proposed solution reuses SLAAC and DHCP
mechanisms, by providing an abstraction that represents the enterprise
network as a single IP hop.
              </t>

		  <t>
Distributed/centralised approach: the solution makes use of border
routers (EBRs) in a similar way that routers sending Router
Advertisements are used by SLAAC, or DHCPv6 servers are used when DHCPv6
prefix delegation is used.
              </t>

		  <t>
Merging support: the solution supports merging.
              </t>

		  <t>
Prefix assignment support: the solution supports the assignment of
IPv6 prefixes to nodes. 
              </t>

		  <t>
Protocol overhead: it does not add much overhead compared with SLAAC
and DHCPv6. It adds some overhead in terms of tunneling headers due to
the VET approach.
              </t>

	      </list>

          </t>

	  </section>

<!------------------------------------------------>
<!--  SECTION 2.2.2.5: Bernardos et al.           -->
<!------------------------------------------------>

	   <section title="A DHCP-based IP address autoconfiguration
		for MANETs (Bernardos et al.)">

	    <t>
In this autoconfiguration mechanism -- proposed in
<xref target="bernardos" /> -- the first node that falls into the
radio coverage of an access network uses DHCPv6 to get a global
IPv6 prefix to be shared in the MANET. 
         </t>

	    <t>
Assumptions:

It assumes the existence of a DHCP server in the access router
giving access to the Internet.
          </t>

	    <t>
Approach description:

This solution basically works as follows: 
The first step is obtaining a global IPv6 prefix to be shared
in the MANET (i.e., the MANET prefix). This task is done by the
first node in the coverage of an access network (i.e., the
initiator), using DHCPv6. The initiator node gets from this MANET
prefix a /64 for itself and starts sending routers advertisements
through its ad hoc interface. Each RA contains a new option
(MANET DHCP Prefix Delegation Information) that indicates to the
receivers that the sender of the RA is able to delegate prefixes
using DHCPv6.
          </t>

	<t>
Receivers of these RAs, that is, new arriving nodes, may then
configure an IPv6 address from the prefix contained in the RA
(i.e., performing normal IPv6 stateless address
auto-configuration). These nodes may then request an IPv6
prefix for themselves using, using DHCPv6. The initiator node
delegates each of them a /64 prefix, keeping track of how
many /64 prefixes from the MANET preix are still available
for distribution.
	</t>

	<t>
These MANET nodes configure their interfaces with addresses
from the prefix they have just obtained and start sending RAs
containing this prefix. This enables other nodes that are within
the radio coverage of these MANET nodes to obtain IPv6 addresses
and request IPv6 prefixes. When a MANET node, other than the
initiator node, receives a DHCPv6 prefix request, it generates a
new request and sends it to one node capable of delegating
prefixes. In this way requests are recursively generated until
they reach the initiator node, which then generates a DHCPv6
reply with the delegated prefix. Again, replies are recursively
sent backwards until they reach the unconfigured nodes that
requested the prefixes.
        </t>

	    <t>
Based on <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />, this
solution has the following key features:

            <list style="symbols">
	        <t>
MANET scenario: the solution targets connected MANETs.
              </t>

		  <t>
Routing protocols' dependency: the solution is routing independent.
             </t>

		  <t>
Address uniqueness: The solution reuses SLAAC and DHCP mechanisms.
             </t>

		  <t>
Distributed/centralised approach: the MANET does not make use of
any centralised server, but all the nodes have the potential to
ask for a prefix to the DHCP server on the infrastructure, and
becomes a router sending Router Advertisements are used by SLAAC.
              </t>

		  <t>
Merging support: given that the proposed solution assigns global
IP addresses avoiding duplicates, merging is supported. 
              </t>

		  <t>
Prefix assignment support: the solution support the assignment
of IPv6 prefixes to nodes.
              </t>

		  <t>
Protocol overhead: it does not add much overhead compared with
SLAAC and DHCPv6. RAs include a new option that indicates to
receivers that the sender of the RA is able to delegate
prefixes using DHCPv6.
              </t>

	      </list>

          </t>

	   </section>


	 </section>

      </section>

    </section>


<!------------------------------------------------>
<!--  SECTION 3: Security Considerations        -->
<!------------------------------------------------>

    <section title="Security Considerations">

      <t>
Due to the open wireless environment of ad hoc networks, IP
autoconfiguration mechanisms are susceptible to a number of
attacks.
      </t>

    </section>

<!------------------------------------------------>
<!--  SECTION 4: IANA Considerations            -->
<!------------------------------------------------>

    <section title="IANA Considerations">

      <t>
This document has no actions for IANA.
      </t>

    </section>

<!------------------------------------------------>
<!--  SECTION 5: ACKNOWLEDGEMENTS               -->
<!------------------------------------------------>

    <section anchor="sec:acknowledgements" title="Acknowledgements">

        <t>
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, and Thomas
Clausen for his review and support on the continuity of this draft in
another shape.
      </t>

      <t>
The work of Carlos J. Bernardos and Maria Calderon has been partially
supported by the Ministry of Science and Innovation of Spain under
the QUARTET project (TIN2009-13992-C02-01).
      </t>

	<t>
The work of Carlos J. Bernardos has also been
partially supported by the EU through the ICT FP7 European Project
CARMEN (INFSO-ICT-214994). Apart from this, the European Commission
has no responsibility for the content of this Internet-Draft. The
information in this document is provided as is and no guarantee or
warranty is given that the information is fit for any particular
purpose. The user thereof uses the information at its sole risk and
liability.
      </t>

    </section>

  </middle>

<!------------------------------------------------>
<!--  Back Section                              -->
<!------------------------------------------------>

  <back>

<!-------------------------------------------------------->
<!--    REFERENCES                                      -->
<!-------------------------------------------------------->

    <references title="Normative References">

	&I-D.bernardos-autoconf-evaluation-considerations;

    </references>

    <references title="Informative References">

	<!-- I-D references -->

	&I-D.perkins-manet-autoconf;
	&I-D.jelger-manet-gateway-autoconf-v6;
	&I-D.clausen-manet-address-autoconf;
	&I-D.jeong-adhoc-ip-addr-autoconf;
	&I-D.jeong-manet-aodv-addr-autoconf;
	&I-D.laouiti-manet-olsr-address-autoconf;
	&I-D.cha-manet-extended-support-globalv6;
	&I-D.wakikawa-manet-globalv6;
	&I-D.ruffino-manet-autoconf-multigw;
        &I-D.ros-autoconf-emap;
      	&I-D.hofmann-autoconf-mran;
        &I-D.templin-autoconf-multilink;
        &I-D.templin-autoconf-virtual;
        &I-D.mase-manet-autoconf-noaolsr;
        &I-D.jeong-autoconf-pdad-on-demand;
        &I-D.weniger-autoconf-pdad-olsr;
        &I-D.clausen-olsr-passive-dad;
	&I-D.ahn-autoconf-addresspool;
	&I-D.jaehwoon-autoconf-mmbr;
	&I-D.boot-autoconf-brdp;
	&I-D.thubert-tree-discovery;
	&I-D.boot-brdp-based-routing;
        &rfc5558;
        &rfc5320;
        &rfc5720;
	&I-D.ietf-autoconf-adhoc-addr-model;

	<!-- non I-D references -->

      <reference anchor="SBP+02">
	<front>
	  <title>Internet Connectivity for Ad hoc Mobile Networks</title>
	  <author initials="Y." surname="Sun" fullname="Yuan Sun">
	    <organization>University of California, Santa Barbara</organization>
	  </author>
	  <author initials="E. M." surname="Belding-Royer" fullname="Elizabeth M. Belding-Royer">
	    <organization>University of California, Santa Barbara</organization>
	  </author>
	  <author initials="C. E." surname="Perkins" fullname="Charles
	    E. Perkins">
	    <organization>Nokia Research Center</organization>
	  </author>
	  <date year="2002"/>
	</front>

	<seriesInfo name="International Journal of Wireless
	  Information Networks special issue on 'Mobile Ad Hoc
	  Networks (MANETs): Standards, Research, Applications'" value=""/>

      </reference>

      <reference anchor="WZ+02">
	<front>
	  <title>IPv6 Autoconfiguration in Large Scale Mobile Ad-Hoc Networks</title>
	  <author initials="K." surname="Weniger" fullname="K. Weniger">
	    <organization></organization>
	  </author>
	  <author initials="M." surname="Zitterbart" fullname="M. Zitterbart">
	    <organization></organization>
	  </author>
	  <date year="2002"/>
	</front>

	<seriesInfo name="European Wireless 2002" value=""/>

      </reference>

      <reference anchor="Vai02">
	<front>
	  <title>Weak Duplicate Address Detection in Mobile Ad Hoc Networks</title>
	  <author initials="N. H." surname="Vaidya" fullname="Nitin H. Vaidya">
	    <organization></organization>
	  </author>
	  <date year="2002"/>
	</front>

	<seriesInfo name="MOBIHOC'02" value=""/>

      </reference>

      <reference anchor="MP+02">
	<front>
	  <title>IP Address Assignment in a Mobile Ad Hoc Network</title>
	  <author initials="M." surname="Mohsin" fullname="M. Mohsin">
	    <organization></organization>
	  </author>
	  <author initials="R." surname="Prakash" fullname="R. Prakash">
	    <organization></organization>
	  </author>
	  <date year="2002"/>
	</front>

	<seriesInfo name="MILCOM 2002" value=""/>

      </reference>

      <reference anchor="TP+04">
	<front>
	  <title>An address assignment for the automatic configuration
of mobile ad hoc networks</title>
	  <author initials="A. P." surname="Tayal" fullname="A. P. Tayal">
	    <organization></organization>
	  </author>
	  <author initials="L. M." surname="Patnaik" fullname="L. M. Patnaik">
	    <organization></organization>
	  </author>
	  <date year="2004"/>
	</front>

	<seriesInfo name="Personal Ubiquitous Computing" value=""/>

      </reference>

      <reference anchor="ZNM+03">
	<front>
	  <title>Prophet Address Allocation for Large Scale MANETs</title>
	  <author initials="H." surname="Zhou" fullname="H. Zhou">
	    <organization></organization>
	  </author>
	  <author initials="L. M." surname="Ni" fullname="L. M. Ni">
	    <organization></organization>
	  </author>
	  <author initials="M. W." surname="Mutka" fullname="M. W. Mutka">
	    <organization></organization>
	  </author>
	  <date year="2003"/>
	</front>

	<seriesInfo name="Proceedings of INFOCOM 2003" value=""/>

      </reference>

      <reference anchor="FPD+06">
	<front>
	  <title>Automatic IP Address Configuration in VANETs</title>
	  <author initials="F." surname="Fazio" fullname="F. Fazio">
	    <organization></organization>
	  </author>
	  <author initials="C." surname="Palazzi" fullname="C. Palazzi">
	    <organization></organization>
	  </author>
	  <author initials="S." surname="Das" fullname="S. Das">
	    <organization></organization>
	  </author>
	  <author initials="M." surname="Gerla" fullname="M. Gerla">
	    <organization></organization>
	  </author>
	  <date year="2006"/>
	</front>

	<seriesInfo name="ACM VANET 2006 Workshop co-located with Mobicom 2006" value=""/>

      </reference>

      <reference anchor="Wen03">
	<front>
	  <title>Passive Duplicate Address Detection in Mobile Ad hoc
Networks</title>
	  <author initials="K." surname="Weniger" fullname="K. Weniger">
	    <organization></organization>
	  </author>
	  <date year="2003"/>
	</front>

	<seriesInfo name="IEEE Wireless Communications and Networking
	  Conference (WCNC)" value=""/>

      </reference>

      <reference anchor="Wen05">
	<front>
	  <title>PACMAN: Passive autoconfiguration for mobile ad hoc
networks</title>
	  <author initials="K." surname="Weniger" fullname="K. Weniger">
	    <organization></organization>
	  </author>
	  <date year="2005"/>
	</front>

	<seriesInfo name="IEEE Journal on Selected Areas in
	  Communications, vol. 23, no. 3, Mar 2005  pp. 507-519"
	  value=""/>

      </reference>

      <reference anchor="chen">
	<front>
	  <title>Scalable Address Allocation Protocol for Mobile
Ad Hoc Networks</title>
	  <author initials="Y." surname="Chen" fullname="Y. Chen">
	    <organization></organization>
	  </author>
	  <author initials="E." surname="Fleury" fullname="E. Fleury">
	    <organization></organization>
	  </author>
	  <author initials="T." surname="Razanfindralambo" fullname="T. Razanfindralambo">
	    <organization></organization>
	  </author>
	  <date year="2009"/>
	</front>

	<seriesInfo name="Fifth International Conference on Mobile
Ad-hoc and Sensor Networks"
	  value=""/>

      </reference>

      <reference anchor="nesargi">
	<front>
	  <title>MANETconf: configuration of hosts in a mobile
ad hoc network</title>
	  <author initials="S." surname="Nesargi" fullname="S. Nesargi">
	    <organization></organization>
	  </author>
	  <author initials="R." surname="Prakash" fullname="R. Prakash">
	    <organization></organization>
	  </author>
	  <date year="2002"/>
	</front>

	<seriesInfo name="INFOCOM 2002. Twenty-First Annual Joint
Conference of the IEEE Computer and Communications Societies.
Proceedings. IEEE, Volume: 2 Page(s): 1059 - 1068 vol.2. 2002"
	  value=""/>

      </reference>

      <reference anchor="jelger2005">
	<front>
	  <title>Prefix Continuity and Global Address Autoconfiguration 
in IPv6 Ad Hoc Networks</title>
	  <author initials="C." surname="Jelger" fullname="C. Jelger">
	    <organization></organization>
	  </author>
	  <author initials="T." surname="Noel" fullname="T. Noel">
	    <organization></organization>
	  </author>
	  <date year="2005"/>
	</front>

	<seriesInfo name="Proceedings of the 4th Mediterranean
Ad Hoc Networking Workshop (MedHocNet'05), June 2005,
Porquerolles, France"
	  value=""/>

      </reference>

      <reference anchor="pongpaibool">
	<front>
	  <title>Rapid IPv6 Address Autoconfiguration for
Heterogeneous Mobile Technologies</title>
	  <author initials="P." surname="Pongpaibool" fullname="P. Pongpaibool">
	    <organization></organization>
	  </author>
	  <author initials="K." surname="Siriwong Na Ayutaya" fullname="K. Siriwong Na Ayutaya">
	    <organization></organization>
	  </author>
	  <author initials="K." surname="Kanchanasut" fullname="K. Kanchanasut">
	    <organization></organization>
	  </author>
	  <author initials="H." surname="Tazaki" fullname="H. Tazaki">
	    <organization></organization>
	  </author>
	  <date year="2008"/>
	</front>

	<seriesInfo name="Proceedings of the 8th International
Conference of ITS Telecommunications (ITST 2008), Phuket, Thailand"
	  value=""/>

      </reference>

      <reference anchor="bernardos">
	<front>
	  <title>A DHCP-based IP address autoconfiguration for MANETs</title>
	  <author initials="C. J." surname="Bernardos" fullname="C. J. Bernardos">
	    <organization></organization>
	  </author>
	  <author initials="M." surname="Calderon" fullname="M. Calderon">
	    <organization></organization>
	  </author>
	  <date year="2006"/>
	</front>

	<seriesInfo name="I International Conference on Ubiquitous
Computing: Applications, Technology and Social Issues (ICUC 2006),
Alcalá de Henares, Spain"
	  value=""/>

      </reference>


    </references>

 <!------------------------------------------------>
 <!--  APPENDIX A: CHANGELOG                     -->
 <!------------------------------------------------>

    <section anchor="app:changelog" title="Change Log">

      <t>
Changes from -04 to -05:

        <list style="symbols">

          <t>
Removal of references to old autoconf problem statement draft and
MANET architecture drafts.
          </t>

          <t>
Update of the document, adding new solutions.
          </t>

        </list>

      </t>

      <t>
Changes from -03 to -04:

        <list style="symbols">

          <t>
New release to keep the document alive.
          </t>

          <t>
Update of some references and the associated solution description.
          </t>

        </list>

      </t>

      <t>
Changes from -02 to -03:

        <list style="symbols">

          <t>
New release to keep the document alive.
          </t>

          <t>
Update of some references.
          </t>

        </list>

      </t>

      <t>
Changes from -01 to -02:

        <list style="symbols">

          <t>
The classification criteria section has been removed, since it is now
part of the evaluation considerations in <xref
target="I-D.bernardos-autoconf-evaluation-considerations"
/>. Solutions are now analysed conforming to some of these evaluation
considerations in <xref
target="I-D.bernardos-autoconf-evaluation-considerations" />.
          </t>

          <t>
The Conclusions section has been removed.
          </t>

          <t>
The Terminology section has been removed.
          </t>

          <t>
The term "DAD" has been removed in the document (when possible), using
Non-unique Address Detection instead.
          </t>

          <t>
Many editorial changes.
          </t>

        </list>

      </t>

      <t>
Changes from -00 to -01:

        <list style="symbols">

          <t>
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.
          </t>

          <t>
More solutions have been added to the I-D.
          </t>

          <t>
Adding of a security consideration section.
          </t>

        </list>

      </t>

    </section>

  </back>

</rfc>
