[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                                            Thomas Clausen
IETF MANET Working Group                               Emmanuel Baccelli
Expiration: 31 July 2005                LIX, Ecole Polytechnique, France
                                                         31 January 2005

                 Simple MANET Address Autoconfiguration
              draft-clausen-manet-address-autoconf-00.txt

Status of this Memo

   This document is a submission to the Network Mobility Working Group
   of the Internet Engineering Task Force (IETF). Comments should be
   submitted to the nemo@ietf.org mailing list.

   Distribution of this memo is unlimited.

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   In this draft, a simple autoconfiguration mechanism for MANETs is
   developed. The mechanism aims at solving the simple, but common,
   problem of one or more new nodes emerging in an existing network. A
   solution is proposed, which allows these new nodes to acquire an
   address and participate in the network. The method is simple, both
   algorithmically and in the requirements to the network. While this is
   a partial solution to the general autoconfiguration problem, the



Clausen, Baccelli                                                 [Page 1]


INTERNET-DRAFT   Simple MANET Address Autoconfiguration  30 January 2005


   mechanism described in this draft can satisfy the requirements for a
   great number of real-world situations. Though examples are given with
   OLSR [1] [11] being the routing protocol in use, nothing prevents the
   described mechanisms to work along with other routing protocols.















































Clausen, Baccelli                                                 [Page 2]


INTERNET-DRAFT   Simple MANET Address Autoconfiguration   31 January 2005


Table of Contents

1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .   4
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . .   5
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . .   5
3. Simple Address Autoconfiguration Solution Overview  . . . . . . .   6
4. Local Beaconing . . . . . . . . . . . . . . . . . . . . . . . . .   7
5. Aquireing a Local Address . . . . . . . . . . . . . . . . . . . .   9
6. Global Address Assignment . . . . . . . . . . . . . . . . . . . .  10
7. Overhead Estimation . . . . . . . . . . . . . . . . . . . . . . .  11
8. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
9. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
11. Changes  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  14
13. Security Considerations  . . . . . . . . . . . . . . . . . . . .  14
14. Copyright  . . . . . . . . . . . . . . . . . . . . . . . . . . .  14

































Clausen, Baccelli                                                 [Page 3]


INTERNET-DRAFT   Simple MANET Address Autoconfiguration   31 January 2005


1.  Introduction

   A Mobile Ad-hoc NETwork (MANET) is a collection of nodes which are
   able to connect on a wireless medium forming an arbitrary and dynamic
   network, routing traffic through multi-hop-paths in order to ensure
   connectivity between any two nodes in the network. Implicitly herein
   is the ability for the network topology to change over time as links
   in the network appear and disappear.

   In order to enable communication between any two nodes in such a
   MANET, a routing protocol is employed. The abstract task of the rout-
   ing protocol is to discover the topology (and, as the the network is
   dynamic, continuing changes to the topology) to ensure that each node
   is able to acquire a recent image of the network topology for con-
   structing routes.

   An issue, complementary to that of routing, emerges with respect to
   bootstrapping of the network. Routing protocols accomplish the task
   of discovering paths in a MANET, however a prerequisite to the cor-
   rect functioning of routing protocols is that all nodes are identifi-
   able by an unique IP-address. Subsequently, a mechanism for assigning
   (unique) addresses to MANET nodes is required.

   A particularity of MANETs is, that the roles of ``terminal'' and
   ``network forming node'' (router) are not clearly separate. In prin-
   ciple, all nodes may act in both capacities simultaneously. An addi-
   tional constraint is, that no assumptions with respect to a preexist-
   ing infrastructure can be made. Traditional mechanisms for host auto-
   configuration, such as DHCP [7] or ZeroConf [10] or similar mecha-
   nisms all assume the presence of a ``server'', which can coordinate
   and assign addresses. Further, these mechanisms work on the assump-
   tion that direct communication between the ``server'' and all hosts
   in the local network is possible. Due to the multi-hop nature of
   MANETs, direct communication between an arbitrary host in the network
   and (any) server cannot be assumed.

   In order to ensure the true autonomy of MANETs, a specific mechanism
   -- or adaptation of mechanism -- for address autoconfiguration of
   MANETs is required. Such a mechanism is described in the following.


1.1.  Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [5].





Clausen, Baccelli                                                 [Page 4]


INTERNET-DRAFT   Simple MANET Address Autoconfiguration   31 January 2005


   Several references are made to the OLSR terminology as described and
   employed in [1]. This document uses the following terminology:


     -    Node:   a device capable of participating in a MANET.

     -    Neighbor Node:   A node X is a neighbor node of node Y if node
          Y can hear node X.

     -    Multipoint Relay (MPR):   A node which is selected by its
          neighbor, node X, to "re-transmit" all the broadcast messages
          that it receives from X, provided that the message is not a
          duplicate, and that the time to live field of the message is
          greater than one.

     -    Hello Messages:   An OLSR node periodically broadcasts a Hello
          Message listing its neighbors.  These messages are not for-
          warded, and serve the purpose of local neighborhood discovery
          and maintenance, as well as setting up Multipoint Relays.

     -    TC Messages:   An OLSR node periodically broadcasts a TC Mes-
          sage listing its neighborhood link status.  These messages are
          forwarded throughout the MANET, using MPR flooding, and serve
          the purpose of MANET topology discovery and maintenance.


1.2.  Applicability

   This document describes a simple address autoconfiguration mechanism
   aiming at solving a number of real-world situations with one or more
   new nodes emerging in an existing network. It is assumed that either
   at least one node in the network (typically, this might be a node
   providing Internet connectivity) is already configured or that,
   absent a previously configured node, an election can be undertaken to
   allow one node to self-configure and thereby initiate a network-wide
   autoconfiguration as described in this specification.

   Even though examples are given with OSLR [1] [11] being the routing
   protocol in use, nothing prevents the described mechanism to work
   along with other routing protocols.


2.  Problem Statement

   The issue of autoconfiguration in MANETs is complex since, for a com-
   plete solution, issues such as ensuring uniqueness of addresses in
   independent MANETs which later merge, must be addressed: independent
   MANET must somehow select non-overlapping address-spaces, duplicate



Clausen, Baccelli                                                 [Page 5]


INTERNET-DRAFT   Simple MANET Address Autoconfiguration   31 January 2005


   address detection, conflict resolution -- and the issue of how to
   deal with ongoing data streams without loosing data or the require-
   ment of specific application behavior.

   In this draft, we aim for a simple solution to a simple problem: the
   connected case. A common situation occurs, in which an efficient and
   simple address autoconfiguration mechanism is desirable and suffi-
   cient. This situation is, where a MANET acts as an edge-extension to
   the Internet. I.e., nodes are interested in maintaining connection to
   each other and to the Internet. The implication is also, that nodes
   join or leave the MANET, but do not migrate (alone or in groups)
   between different MANETs with the expectation of maintaining connec-
   tivity. The topic of nodes migrating between different MANETs may
   better be addressed through mechanisms such as NEMO [6].

   The mechanism, developed in this draft, is therefore targeted explic-
   itly at the connected case described above. While this is a particu-
   lar solution to a particular problem, there is indeed a need to
   develop a simple and light-weight mechanism efficient for these
   stated scenarios.

   The address autoconfiguration mechanism in this draft is specified as
   an extension to OLSR [1]. However, nothing prevents the mechanism to
   be work with other routing protocols as well.



3.  Simple Address Autoconfiguration Solution Overview

   This section will outline the functioning of the address autoconfigu-
   ration mechanism.

   The following two terms will be used for the remainder of this draft:
   a "new node" is a node which is not yet assigned an address, and thus
   not is part of a MANET. An "MANET node" is a node which is assigned
   an address and which is part of the network. A "configurating node"
   is an MANET node, which is currently assisting a new node in acquire-
   ing an address.


     -    MANET nodes behave as specified by the routing protocol in
          use, say OLSR [1]. Additionally, they emit ADDR_BEACON mes-
          sages, to signal to new nodes that they may act as configurat-
          ing nodes. This is detailed in the following section.

     -    New nodes do not participate with the routing protocol in use:
          for example with OLSR, they do not emit HELLO and TC messages.
          However they listen for ADDR_BEACON messages.



Clausen, Baccelli                                                 [Page 6]


INTERNET-DRAFT   Simple MANET Address Autoconfiguration   31 January 2005


     -    From among the MANET nodes emitting ADDR_BEACON messages, one
          configurating node is selected, and a request for address con-
          figuration is issued through an ADDR_CONFIG message. The goal
          is for the configurating node to provide the new node with
          first a temporary local address, then a permanent global
          address.

This process of acquiring a local, temporary address, and the task of
acquiring a global address are detailed in the following sections.
Packet formats are proposed in the case of OLSR.


4.  Local Beaconing

   Each MANET node, must ensure that it has the ability to provide tem-
   porary addresses from a private address space to new nodes. It is
   important that, within a region, these temporary addresses are
   unique, i.e. that no two new nodes within the same neighborhood are
   assigned the same temporary address. In order to ensure this, a pre-
   defined address space is allocated to use for ``temporary
   addresses''. The task is to ensure that this address space is
   divided, without overlap, between nodes in a region of the network:


     -    Each MANET node will, independently, select a continuous
          address sequence from the address space allocated for ``tempo-
          rary addresses''.

     -    Each MANET node will signal, with periodic ADDR_BEACON mes-
          sages, this selected sequence. ADDR_BEACON messages are trans-
          mitted to neighbor nodes only, i.e. are not forwarded.

     -    Each node will record the address sequences, selected by all
          its neighbor nodes.

If, upon receiving an ADDR_BEACON message, a node detects that there is
a conflicting address sequence selection, arbitration must happen. In
this case:


     -    If no nodes in the conflict are acting as configurating nodes,
          arbitration is carried out simply by having the conflicting
          node with the lowest ID (IP-address) select a new, unused
          address-sequence.

     -    If one or more conflicting nodes are acting as configurating
          node(s), arbitration must aim at allowing ongoing configura-
          tion sessions to complete.



Clausen, Baccelli                                                 [Page 7]


INTERNET-DRAFT   Simple MANET Address Autoconfiguration   31 January 2005


In order to accommodate this, all configuration nodes ``narrow'' their
selected address-sequence to contain only the address(es) which are cur-
rently assigned to new nodes. This is included in the next ADDR_BEACON.
Nodes which are not currently acting as configuration nodes, select non-
conflicting address sequences. If a conflict between two configurating
nodes remains, the node which has the lowest ID (IP address) must yield.

If OLSR is the routing protocol in use, the ADDR_BEACON message can use
the format specified in the following figure. [1] specifies the values
of Message Size, Originator Address, Message Sequence Number and Vtime.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  ADDR_BEACON  |     Vtime     |         Message Size          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Originator Address                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       1       |        0      |    Message Sequence Number    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Address Sequence Start                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Address Sequence Stop                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  :                    Currently Used Addresses                   :
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


In case of ``narrowing down'' the address-sequence to only currently
used addresses, the ``Address Sequence Start'' and ``Address Sequence
Stop'' are both set to zero.

Each node will periodically send ADDR_BEACON messages, listing both its
address sequence and the addresses which are currently in use. In case
of a conflict, a recipient node can detect if the node with which it is
conflicting is active as configurating node. If both nodes are active as
configurating nodes, the nodes can detect a conflict in the addresses
actually selected.

If OLSR is the routing protocol in use, ADDR_BEACON messages are trans-
mitted piggybacked in the same OLSR packet as OLSR HELLO messages.








Clausen, Baccelli                                                 [Page 8]


INTERNET-DRAFT   Simple MANET Address Autoconfiguration   31 January 2005


5.  Aquireing a Local Address

   The first task of a new node is to associate itself with a MANET
   node. Thus, the new node listens for ADDR_BEACON messages and selects
   one ``configurating node''. An ADDR_CONFIG message is then created
   and transmitted, in order to request address configuration from the
   selected configurating node. Absent an IP address, the MAC address of
   the new node must be included, in order to uniquely identify the new
   node.

   Upon receiving an ADDR_CONFIG message, the configurating node assigns
   a local address to the new node, and signals this assignment through
   another ADDR_CONFIG message. Additionally, the configurating node
   marks the assigned address as ``used'' in its ADDR_BEACON messages.

   Upon receiving a local address through an ADDR_CONFIG message, the
   new node can slowly start participating locally with the routing pro-
   tocol in use.  For example, if OLSR is used, it can start sending
   HELLO messages, including only the configurating node as neighbor.
   The goal is to allow the new and configurating node to track each
   other (i.e. it allows both nodes to ``reset'', should the link disap-
   pear before a global address was assigned to the new node), while not
   causing the new node to be advertised to the network. Advertising a
   node with a non-unique address might lead to data loss, routing loops
   etc.

   If a new node does not receive an ADDR_CONFIG reply, it may either
   (i) retransmit the ADDR_CONFIG to the same configurating node, or
   (ii) give up and select an alternative configuration node. Absent the
   local participation of the new node in the routing protocol (i.e.
   with OLSR, the HELLO message exchange described above) the configu-
   rating node may (i) retransmit its ADDR_CONFIG reply, or (ii) give
   up, in which case any temporarilly assigned addresses will be
   reclaimed.

   If OLSR is the routing protocol in use, the ADDR_CONFIG message can
   use the format specified in following figure.  [1] specifies the val-
   ues of Message Size, Originator Address, Message Sequence Number and
   Vtime.












Clausen, Baccelli                                                 [Page 9]


INTERNET-DRAFT   Simple MANET Address Autoconfiguration   31 January 2005


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  ADDR_CONFIG  |     Vtime     |         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       1       |        0      |    Message Sequence Number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Configurating Node Address                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                        MAC Addresses                          :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Assigned Local Address                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Assigned Global Address                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   If the ``Assigned Local Address'', ``Assigned Global Address'' and
   ``Originator Address'' fields are all set to zero, the ADDR_CONFIG
   message is a request to the ``Configurating Node'' to perform local
   address assignment.

   If the ``Assigned Local Address'' is non-zero (i.e. contains an
   actual address) and ``Originator Address'' is non-zero, but the
   ``Assigned Global Address'' field is set to zero, the ADDR_CONFIG
   message is an assignment of a temporary local address. I.e. this is
   the reply to a new node, generated by a configurating node.

   The ``Assigned Global Address'' field is discussed in the next sec-
   tion.



6.  Global Address Assignment

   When local participation of the new node in the routing protocol has
   started (i.e. with OLSR, the HELLO message exchange commences between
   the new and configurating node), local address assignment is com-
   pleted, and the task of acquireing a global address can commence. The
   configurating node is in charge of acting on behalf of the new node,
   with respect to acquireing this global address. Since the configurat-
   ing node is already part of the MANET, a multitude of different mech-
   anisms can be employed. One such mechanism for acquiring a global
   address would be for the configurating node to act as a modified DHCP



Clausen, Baccelli                                                [Page 10]


INTERNET-DRAFT   Simple MANET Address Autoconfiguration   31 January 2005


   proxy [8] and transmit a request to an existing DHCP server in the
   network.

   Another option would be to consult the nodes' topology table. This
   table (in a relatively stable state) contains all destinations (thus
   addresses) of the network. The configurating node can thus pick a
   non-used address and assign to the new node. In that case, in order
   to prevent duplicate address assignment, the configurating node
   advertises the selected address to the MANET. If a node detects that
   its address is being re-used, it can signal the conflict to the orig-
   inator of the ``offending'' advertisement.

   If OLSR is the routing protocol in use, the configurating node
   includes the selected address in a few TCs. If a node receives a TC
   containing its own address (or an address, which the node has claimed
   for a new node) AND if the originator of the message is not the node
   itself nor an MPR of the node, a duplicate address assignment is
   detected. The detecting node can then communicate this to the origi-
   nator of the offending TC, with the purpose of resolving the con-
   flict.

   Once the configurating node has acquired a globally unique address,
   it is assigned to the new node through an ADDR_CONFIG message, con-
   taining the same ``Assigned Local Address'' and ``Originator
   Address'' as before, but with a non-zero address in the ``Assigned
   Global Address'' field. This is then the ticket for the new node to
   participate fully in the MANET.

   The configurating node will continue to transmit this ADDR_CONFIG
   message periodically until it detects that the new node has taken it
   into account. With OLSR, thw configurating node can detect this
   either when the HELLO messages from the new node's assigned local
   address cease, or when an ADDR_CONFIG message from the new node is
   received, listing the new nodes global address in both the originator
   field and the ``Assigned Global Address'' field, the ``Assigned Local
   Address'' and the ``MAC address'' fields.



7.  Overhead Estimation

   The overhead incurring from the mechanism specified in this draft
   comes from primarily three sources: (i) periodic beaconing of
   ADDR_BEACON messages, (ii) address request/replies through ADDRmes-
   sages, and (iii) discovery of a globally unique address.

   ADDR_BEACON messages and ADDR_CONFIG messages are local, i.e. no
   flooding operations incur. ADDR_CONFIG messages are furthermore only



Clausen, Baccelli                                                [Page 11]


INTERNET-DRAFT   Simple MANET Address Autoconfiguration   31 January 2005


   transmitted while nodes are being configured, and are of limited size
   (24 bytes + size of MAC address). Each configuration cycle incurs 4
   messages. The overall overhead, incurred through this procedure, is
   therfore negligible.

   With OLSR, ADDR_BEACON messages are transmitted in the same OLSR
   packets as OLSR HELLO messages (MTU permitting), thus the number of
   transmissions required remains constant as compared to OLSR. Except
   when an node configuration is ongoing, the additional overhead
   incurred from ADDR_BEACON amounts to 20 bytes.

   on the other hand, the discovery of a globally unique message depends
   on the mechanism employed. Assuming a decentralized mechanism, where
   an unused address is picked from the topology table and is probed
   through including this address in a TC emission, the additional over-
   head per TC message for that node is 4 bytes. This is offset by the
   fact that if an address is assigned to the new node, topological
   information is already present in the network, allowing the node
   immediate participation.



8.  Acknowledgements

The authors would like to thank Hitachi Labs Europe for their support.

9.  Authors' Addresses


   Thomas Heide Clausen,
   Project PCRI
   Pole Commun de Recherche en Informatique du plateau de Saclay,
   CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
   Ecole polytechnique,
   Laboratoire d'informatique,
   91128 Palaiseau Cedex, France
   Phone: +33 1 69 33 40 73,
   Email: T.Clausen@computer.org


   Emmanuel Baccelli
   HITACHI Labs Europe/ Project PCRI,
   Pole Commun de Recherche en Informatique du plateau de Saclay,
   CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
   Ecole polytechnique,
   Laboratoire d'informatique,
   91128 Palaiseau Cedex, France
   Phone: +33 1 69 33 40 73,



Clausen, Baccelli                                                [Page 12]


INTERNET-DRAFT   Simple MANET Address Autoconfiguration   31 January 2005


   Email: Emmanuel.Baccelli@inria.fr

10.  References

[1] T. Clausen, P. Jacquet, Optimized Link State Routing Protocol.
     Request for Comments (Experimental) 3626, Internet Engineering Task
     Force, October 2003.

[2] T. Clausen, G. Hansen, L. Christensen, G. Behrmann, The Optimized
     Link State Routing Protocol - Evaluation Through Experiments and
     Simulation.  Proceedings of the Fourth Wireless Personal Multimedia
     Communications, September 2001.

[3] S. Bradner.  Key words for use in RFCs to Indicate Requirement Lev-
     els.  Request for Comments (Best Current Practice) 2119, Internet
     Engineering Task Force, March 1997.

[4] R. Wakikawa et al. Global Connectivity for IPv6 Mobile Ad Hoc Net-
     works (work in progress). Internet Draft (draft-wakikawa-manet-
     globalv6-03.txt), Internet Engineering Task Force, October 2003.

[5] T. Clausen, P. Jacquet, L. Viennot, Comparative study of routing
     protocols for mobile ad-hoc networks.  Proceedings of IFIP Med-Hoc-
     Net 2002, September 2002.

[6] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert.  Nemo
     Basic Support Protocol (work in progress).  Internet Draft (draft-
     ietf-nemo-basic-support-02), Internet Engineering Task Force,
     December 2003.

[7] R. Droms, Dynamic host configuration protocol, RFC 2131, Internet
     Engineering Task Force, March 1997.

[8] M. Patrick, Dhcp Relay Agent Information Option, RFC 3046, Internet
     Engineering Task Force, January 2001.

[9] A. Qayyum, L. Viennot, A. Laouiti, Multipoint relaying: An Efficient
     Technique for Flooding in Mobile
      Wireless Networks. INRIA Research Report RR-3898, Project Hiper-
     com, March 2000.

[10] A. Williams, Requirements for Automatic Configuration of IP Hosts.
     Internet Draft, draft-ietf-zeroconf-reqts-12.txt, September 2002,
     Work in progress.

[11] E. Baccelli, T. Clausen, A Simple Address Autoconfiguration Mecha-
     nism for OLSR, IEEE International Symposium on Circuits and Sys-
     tems, ISCAS 2005.



Clausen, Baccelli                                                [Page 13]

INTERNET-DRAFT   Simple MANET Address Autoconfiguration   31 January 2005


11.  Changes

   This is the initial version of this specification.

12.  IANA Considerations

   This document does currently not specify IANA considerations.

13.  Security Considerations

   This document does not specify any security considerations.

14.  Copyright
   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
   MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
   OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.