[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

MANET Autoconfiguration (AUTOCONF)                           H. Moustafa
Internet-Draft                                            France Telecom
Intended status: Informational                              C. Bernardos
Expires: May 6, 2009                                         M. Calderon
                                                                    UC3M
                                                        November 2, 2008


Evaluation Considerations for IP Autoconfiguration Mechanisms in MANETs
         draft-bernardos-autoconf-evaluation-considerations-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

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

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

   This Internet-Draft will expire on May 6, 2009.

Abstract

   This Internet Draft aims at providing general guidelines for the
   AUTOCONF solution space, through providing a set of evaluation
   considerations for IP autoconfiguration mechanisms in MANETs.  These
   evaluation considerations conform to the AUTOCONF problem statement
   draft and the MANET architecture draft.  The main objective of this
   draft is to illustrate some key features and highlight some important
   behaviours for the different autoconf mechanisms, and thus aiming to
   help solution developers during mechanisms' design and to help
   implementers in the choice of the autoconf mechanism that fits better
   their particular requirements, taking into consideration a number of



Moustafa, et al.           Expires May 6, 2009                  [Page 1]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


   important factors that are discussed in this draft.


Table of Contents

   1.  Introduction and motivation  . . . . . . . . . . . . . . . . .  3
   2.  Evaluation Considerations  . . . . . . . . . . . . . . . . . .  3
     2.1.  Node/Network Characteristics . . . . . . . . . . . . . . .  3
       2.1.1.  MANET Scenarios  . . . . . . . . . . . . . . . . . . .  4
       2.1.2.  Mobility type  . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Functional Characteristics . . . . . . . . . . . . . . . .  5
       2.2.1.  Address Uniqueness . . . . . . . . . . . . . . . . . .  5
       2.2.2.  Merging support  . . . . . . . . . . . . . . . . . . .  6
       2.2.3.  Partitioning support . . . . . . . . . . . . . . . . .  6
       2.2.4.  Prefix delegation support  . . . . . . . . . . . . . .  6
     2.3.  Performance Characteristics  . . . . . . . . . . . . . . .  7
       2.3.1.  Protocol overhead  . . . . . . . . . . . . . . . . . .  7
       2.3.2.  Robustness . . . . . . . . . . . . . . . . . . . . . .  7
       2.3.3.  Convergence time . . . . . . . . . . . . . . . . . . .  8
       2.3.4.  Scalability  . . . . . . . . . . . . . . . . . . . . .  8
       2.3.5.  Address space utilisation  . . . . . . . . . . . . . .  9
     2.4.  Nodes' Behaviour Characteristics . . . . . . . . . . . . .  9
       2.4.1.  Distributed/Centralised approach . . . . . . . . . . .  9
       2.4.2.  Trust and Security . . . . . . . . . . . . . . . . . . 10
     2.5.  Architectural Characteristics  . . . . . . . . . . . . . . 10
       2.5.1.  Integration with standard IPv6 nodes . . . . . . . . . 10
       2.5.2.  Gateway involvement  . . . . . . . . . . . . . . . . . 11
     2.6.  Usability Characteristics  . . . . . . . . . . . . . . . . 11
       2.6.1.  Routing Protocol Dependency  . . . . . . . . . . . . . 11
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 15













Moustafa, et al.           Expires May 6, 2009                  [Page 2]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


1.  Introduction and motivation

   Ad hoc networks present particular characteristics that should be
   taken into account when designing address auto-configuration
   protocols.  These unique characteristics make existing solutions for
   IP infrastructure-based networks (e.g., RFCs 2461, 2462, 3315 etc.)
   difficult to be applied, as is, in MANETs.  Some limitations of these
   existing solutions are stated in [1] and they mainly concern: the
   lack of multi-hop support, the lack of dynamic topology support, the
   lack of network merging support and the lack of network partitioning
   support.

   The AUTOCONF WG is working to develop and standardise IP
   autoconfiguration mechanisms for MANETs.  The dynamic and random
   nature of MANETs together with the different environmental behaviour,
   results in different autoconfiguration mechanisms functionalities and
   characteristics.  The problem statement draft [1] highlights the
   importance of some solution considerations that should be taken in
   mind, mainly focusing on low overhead, low delay, different link
   type's applicability, interaction with the existing protocols and
   security issues.  In this context, this document discusses some
   evaluation considerations for IP autoconfiguration mechanisms in
   MANETs, giving a useful reference for the solutions' space as well as
   guidelines for solution developers during mechanisms' design and
   implementers in the choice of the autoconf mechanism.  These
   considerations will help to decide which of the available autoconf
   mechanisms fits better a particular scenario.

   The evaluation considerations developed in this draft refer to the
   previous study, carried out in [3], in which an analysis of several
   evaluation criteria for MANET autoconf mechanisms is done.  The
   evaluation considerations presented in this draft are generally
   classified according to a number of characteristics, namely: node/
   network characteristics, nodes' behaviour characteristics, functional
   characteristics, performance characteristics, and usability
   characteristics.


2.  Evaluation Considerations

2.1.  Node/Network Characteristics

   The node/network characteristics basically deal with the special
   features and constraints that a MANET environment might have.  This
   includes the applicability scenarios as well as some nodes'
   characteristics, like the type of mobility.





Moustafa, et al.           Expires May 6, 2009                  [Page 3]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


2.1.1.  MANET Scenarios

   This characteristic concerns the MANET environment.  In this context,
   two possible scenarios of MANET are identified in [1]:
   1.  Standalone MANETs, which are autonomous ad hoc networks that 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 standalone MANET scenarios, nodes
       may join or leave randomly.  Most likely, there is neither pre-
       established nor reliable address or prefix allocation agency is
       present in such type of networks.
   2.  Connected MANETs, which are ad hoc networks having connectivity
       to one or more external networks, typically the Internet, by
       means of one or more gateways.  It is noticed that these networks
       may be connected to the Internet in a permanent fashion or an
       intermittent fashion.

   This characteristic is an important and basic one that should be
   considered during the design phase of any autoconfiguration
   mechanism.  Different mechanisms functionalities will be required
   according to the scenario type, where for example, solutions designed
   for connected MANET scenarios have to deal with the issue of getting
   global IPv6 addresses that allow nodes to get Internet connectivity.
   In fact, contributions designated for connected MANETs can mostly be
   general for both types of scenarios.  Indeed, an autoconfiguration
   mechanism should take into account the case of scenario transition,
   where a connected MANET can converge to a standalone MANET if it
   loses its attachment with the infrastructure, or a partially
   standalone manner if sub-network(s) exist(s) due to partitioning.

2.1.2.  Mobility type

   This characteristic concerns the nodes behaviour in MANETs.  In fact,
   nodes' mobility type depends on the MANET application type.  It is
   also noticed that MANET nodes (or some of them) could be fixed or
   present low mobility patterns in certain applications (e.g. mesh
   networks).

   This characteristic impacts the performance of autoconfiguration
   mechanisms.  Particularly, the transmission reliability of
   autoconfiguration messages differs from low to high mobility
   scenarios.  It is noticed that this characteristic impacts the
   autoconfiguration mechanisms performance, especially the convergence
   time and the scalability.  Indeed, high mobility can lead to frequent
   subnet change by mobile nodes and hence requires a change in the
   nodes' address.  The design of any autoconfiguration mechanism should
   take into account the nodes mobility type, where employing periodic



Moustafa, et al.           Expires May 6, 2009                  [Page 4]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


   functionalities is more suitable for high nodes' mobility scenarios.
   Furthermore, the size of messages' exchange should adapt to the
   mobility types of nodes.  A complex problem under this issue is the
   co-existence of different mobility types within the same MANET, where
   we can have different types of mobility ranging from low to high
   among the communicating nodes in a given MANET.

   An additional issue, related to network partitioning and merging, is
   the movement detection, that is specially relevant in high mobility
   scenarios.  Additionally, movement detection can be hard to achieve
   in MANET scenarios and therefore should also be taken into account
   when analysing a particular autoconf solution.

2.2.  Functional Characteristics

   The functional characteristics describe the functionalities that a
   mechanism must aim at featuring [3].  An autoconfiguration mechanism
   can implement one or several of these functionalities.  Such
   functionalities can vary according to the MANET environment and the
   autoconfiguration approach.  There should be a trade-off between the
   number of functionalities that an autoconfiguration mechanism
   implements and the network performance.  The increase in the number
   of functionalities, provided that they are correctly designed, should
   not harm the network performance.

2.2.1.  Address Uniqueness

   The Address Uniqueness characteristic concerns two points: i)
   Duplicate Address Avoidance, and ii) Non-unique Address Detection.
   Duplicate address avoidance is a mandatory characteristic in any
   autoconfiguration mechanism.  It consists in making all
   autoconfiguration mechanisms' functionalities assign addresses only
   after checking their uniqueness.  Hence, this principle must be the
   core of any design of an autoconfiguration mechanism [3].  On the
   other hand, Non-unique Address Detection is the process used to
   detect address collisions and resolve them.  This might be a heavy
   process in any MANET IP autoconfiguration mechanism, requiring a
   considerable number of control messages.

   The Duplicate Address Avoidance is the only mandatory functionality
   in an autoconfiguration mechanism, as it reflects the assumption of
   uniqueness upon which the routing protocol is based [1].

   As for Non-unique Address Detection, most of the existing
   contributions employ such a procedure, whether through developing a
   Non-unique Address Detection mechanism or through using an existing
   one.  Due to MANETs' merging and separation, this process should take
   place in a continuous manner before the IP assignment (Pre-service)



Moustafa, et al.           Expires May 6, 2009                  [Page 5]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


   as well as after the IP assignment (In-service) [2].  However, there
   are some contributions that are Non-unique Address Detection-free,
   which do not use any of such mechanisms while being capable of
   assuring the IP address uniqueness.  Employing a Non-unique Address
   Detection mechanism adds overhead to the autoconfiguration mechanism
   and has an impact on its scalability.

2.2.2.  Merging support

   The merging characteristic presents the ability of the
   autoconfiguration mechanism to detect MANETs' merging and provide
   functionalities to avoid IP address conflicts and connectivity
   problems in such case.

   Merging support is important in the case where two previously
   disjoint ad hoc networks get connected, since there might be nodes
   with duplicated address in the merged network, and therefore it is
   needed to make some nodes change the IP addresses they are using to
   avoid the conflict (this can be achieved for example by using in-
   service Non-unique Address Detection mechanisms).

2.2.3.  Partitioning support

   The partitioning characteristic presents the ability of the
   autoconfiguration mechanism to detect MANETs' partitioning and
   provide functionalities to avoid IP address conflicts and
   connectivity problems in such case.

   Partitioning support is important, especially in connected scenarios,
   in which as a result of a network split, some nodes of the ad hoc
   network might lose the connectivity to the node that they were using
   as gateway to the fixed infrastructure and to the Internet.
   Additionally, it is also important to analyse how an autoconf
   solution deal with the issue of re-use or re-claiming of resources
   (such as IP addresses) once a node has left a particular network.

2.2.4.  Prefix delegation support

   The MANET architecture document [2] considers nodes of a MANET as
   routers (MANET Routers) that can have attached "traditional" hosts,
   and that therefore need to acquire IPv6 prefixes instead of just
   single addresses.

   It is important to analyse if a particular AUTOCONF solution supports
   the delegation of IPv6 prefixes to nodes.






Moustafa, et al.           Expires May 6, 2009                  [Page 6]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


2.3.  Performance Characteristics

   Performance is always a critical issue in communication protocols.
   In the case of autoconf, performance might be specially relevant in
   certain scenarios (for example, in constrained devices).  The
   performance of an autoconfiguration mechanism can be evaluated
   through a number of characteristics, as mentioned below.

2.3.1.  Protocol overhead

   This characteristic concerns the additional signalling required by
   the autoconfiguration mechanism.  Such signalling is considered as
   protocol overhead that might have a significant performance impact.

   Several cases may be are considered:
   o  The IP autoconfiguration mechanism (not the ad-hoc routing
      protocol) requires additional message flooding.  This message
      flooding may be optimised using existing techniques.
   o  The IP address autoconfiguration mechanism requires some protocol
      messages (besides the normal routing protocol messages) to be
      exchanged locally or it modifies existing routing protocol
      messages to add (piggybacking) some information (e.g., prefix or
      GW information).  The size of the added information and how often
      this information is sent can vary depending on the particular
      autoconf solution and the applicability scenario.
   o  The IP address autoconfiguration mechanism does not require any
      special signalling to function (that is, it works in a passive
      way).

   This characteristic might have an impact on the convergence time and
   thus the scalability of the autoconfiguration mechanism.

2.3.2.  Robustness

   One important characteristic/property of an autoconf mechanism is its
   robustness.  Given the particular multi-hop characteristics of MANET
   scenarios, it might be important to analyse the underlying
   assumptions that an autoconf mechanism might make.

   For example, certain autoconf solutions may assume that the
   underlying physical layer is reliable and messages are never lost,
   while another autoconf mechanism may need to provide additional
   mechanisms that deal with the reliability of the message
   transmission.  Obviously, in certain scenarios the former assumption
   makes no sense, and therefore, autoconf solutions may need to
   implement some procedures to ensure that a certain protocol message
   -- needed for the correct operation of the autoconf mechanism -- has
   actually reached its intended destination(s).  Additionally, an



Moustafa, et al.           Expires May 6, 2009                  [Page 7]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


   autoconf solution may be designed in such a way that certain message
   loos are supported without disrupting the correct operation of the
   autoconf mechanism.

   The same kind of reasoning than above can be applied for solutions
   that assume an ordered delivery of signalling messages or the
   integrity of the received messages .

2.3.3.  Convergence time

   Another important characteristic, that can be related to the
   robustness as well, is the convergence time of an autoconf solution.
   Depending on the scenario and/or the application, we may define the
   convergence time as the time required by a single node to get a
   usable (and unique) IPv6 address or as the time required by the whole
   network to have all its nodes configured with correct addresses.  For
   several scenarios, it might not be important for an autoconf solution
   to take a long time to finish its operation (e.g., several minutes),
   for example because the autoconf mechanism is only run once and then
   the nodes remain stable.  However, for other scenarios, it might be
   required that the autoconf solution should take less to converge than
   a given amount of time.

   In relation to the convergence time, it might be also important for
   an autoconf mechanism not to assume at any time an upper limit on the
   time required for a certain message to reach any node of the MANET,
   since this may have an impact on the global convergence time.
   Besides, this kind of assumptions might lead to a solution not to
   work properly in a particular scenario (where the time required for a
   message sent from a node A to reach a node B is longer than the
   assumed upper limit).

2.3.4.  Scalability

   An important issue to deal with during autoconfiguration mechanisms
   design is the scalability of mechanisms to different networks sizes.
   The MANET Architecture I-D [2] defines as Small a MANET composed of
   2-30 peer MANET routers, Moderate a MANET composed of 30-100 peer
   MANET routers, Large a MANET composed of 100-1000 peer MANET routers,
   and Very Large those MANETs larger than 1000 peer MANET routers.

   An autoconfiguration mechanism, in its own, generates signalling
   overhead that may be high, thus impacting scalability.  As mentioned
   in [3], information diffusion also suffers from a large size as the
   diffusion delay can increase such that information arrives at a node
   from distant parts of the network with a long delay.

   Scalability is a very important characteristic that deserves



Moustafa, et al.           Expires May 6, 2009                  [Page 8]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


   consideration.  An autoconfiguration mechanism is not scalable, if
   its performance degrades significantly when the network size
   increases.  This characteristic would be highly dependant on the
   particular usability scenario, since for example there might be an
   autoconf solution designed for a specific moderate-MANET application
   that works great for that particular MANET but this might not be the
   case when the same solution is used for very large network.

2.3.5.  Address space utilisation

   This characteristic basically analyses how an autoconf solution makes
   use of the available address space.  For example, there are solutions
   that split the address space into ranges delegated to different
   nodes, that are responsible of the assignment of addresses from those
   ranges, whereas there are other solutions that keep the available
   address space common for all the MANET nodes.  Obviously, the former
   approach might be more inefficient in terms of address space
   utilisation, compared to the latter.  However, the first approach may
   present additional advantages that may make it better for certain
   scenarios.

   This characteristic is important in networks that are assigned a
   short range of addresses, as well as in large and dense networks.  If
   too many addresses are wasted by the autoconfiguration mechanism,
   such that all idle and accessible addresses are in use, an incoming
   node cannot be granted an address.  This invalidates many of the
   functionalities [3].

2.4.  Nodes' Behaviour Characteristics

   The nodes' behaviour is an important point to be considered during
   autoconfiguration mechanisms design.  It describes how the
   communicating nodes behave during the autoconfiguration process.
   Actually, nodes may behave in a distributed or centralised manner
   which affects the address assignment approach.  In addition, trust is
   a pre-requisite behaviour among nodes and has a great impact on the
   correct functionalities of any autoconfiguration mechanism.

2.4.1.  Distributed/Centralised approach

   There are different possible approaches that an IP autoconfiguration
   mechanism might follow to assign IP addresses to all the nodes of a
   MANET.  One possibility is to deploy a centralised server that is in
   charge of the IP address assignment (e.g., DHCPv6).  The opposite
   approach is not to make use of any server, but to share the IP
   address assignment task among all the participant nodes.  Between
   these two extreme cases, intermediate approaches can be found, for
   example those that deploy several distributed servers within the



Moustafa, et al.           Expires May 6, 2009                  [Page 9]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


   MANET and therefore can be considered as distributed solutions in one
   sense, while they can also be considered as centralised in a certain
   level, since they still make use of servers.

   This characteristic has a direct impact on the performance of any
   autoconfiguration mechanism and is somewhat related to the MANET
   scenario, where, for example, a totally centralised approach is not
   suitable in a standalone MANET.

2.4.2.  Trust and Security

   A very important issue concerns securing communication, or assuring
   secure links existence, between the communicating nodes during the
   autoconfiguration process.  So far, this issue is not considered
   within the ongoing mechanisms.  To assure reliable messages'
   transmission and hence correct mechanisms functionalities, secure
   communication should exist between nodes.  The main difficulty is
   mainly concerning the multi-hop environment.

   In the design of autoconfiguration mechanisms, attacks in ad hoc
   multi-hop environments should be considered.  Further, it is
   important to have a trust relationship between each communicating
   pair of nodes that are involved in the autoconfiguration process.
   This could assure secure and hence correct functioning of
   autoconfiguration mechanisms.  Trust relationship can differ in
   standalone MANET compared to connected MANET, where a central
   authority can play the role of a trusted third party that could help
   in trust provision among the participating nodes.  Also, cooperation
   between nodes is an important factor in order to assure the proper
   message forwarding during the autoconfiguration process.  In this
   context, MANET nodes cooperation should be satisfied and also
   gateways should be enough cooperative.

2.5.  Architectural Characteristics

   The architectural characteristics concern the nodes architecture
   (especially, the interfaces architecture) as well as the topological
   architecture and network deployment, concerning special elements/
   entities (such as gateways).

2.5.1.  Integration with standard IPv6 nodes

   One characteristic that can be considered important in certain
   scenarios is the integration of the autoconf solution with standard
   IPv6 nodes.  For example, certain autoconf mechanisms may allow/be
   compatible to support IPv6 nodes to get addresses using standard
   mechanisms defined in IPv6, while others may be totally incompatible
   with today's IPv6 nodes, therefore preventing these nodes to inter-



Moustafa, et al.           Expires May 6, 2009                 [Page 10]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


   operate with these autoconf solutions, unless the IPv6 nodes are
   properly modified to support them.

2.5.2.  Gateway involvement

   This characteristic concerns the role that Internet gateways could
   have in the IP address autoconfiguration process for incoming nodes.
   Indeed, in connected scenarios, Internet gateways are considered to
   provide the MANET with connectivity to the fixed infrastructure.
   However, these gateways might also have a role/involvement in the IP
   address assignment procedure (e.g., in some solutions, the gateway
   might only be responsible of forwarding packets to the
   infrastructure, while in other solutions it may also be involved in
   the task of providing nodes with addresses/prefixes).

   This characteristic is interesting to be studied for each IP
   autoconfiguration mechanism and need to be considered during the
   mechanisms' design.  Actually, gateway involvement depends somehow on
   whether the used approach is centralised or distributed.  It can be
   also related to the address space usage.

2.6.  Usability Characteristics

   The usability characteristics describe how and under which
   circumstances an autoconf mechanism is able to be used.  This means
   the adaptability to the whole environment including users and other
   protocols [3].

2.6.1.  Routing Protocol Dependency

   Typically, IP autoconfiguration mechanisms require special signalling
   and thus control overhead in order to assign a unique IP address for
   each MANET node and, in a many cases, to verify the uniqueness of
   each assigned address.  Consequently, some of the proposed IP
   autoconfiguration mechanisms are routing protocols dependent; making
   use of the ad hoc routing protocol in transmitting their own signals,
   especially benefiting from the routing discovery phase in the ad hoc
   routing protocol.

   In this context, autoconfiguration mechanisms may be dependent on
   routing protocols and could not function without them (e.g.,
   autoconfiguration mechanisms can be tailored for specific ad hoc
   routing protocols, because the use of the signalling of the routing
   protocol or because they make use of any kind of information provided
   by the routing protocol).  On the other hand, autoconfiguration
   mechanisms can be routing protocols independent, not requiring the
   existence of any particular routing protocol to function.  In
   between, autoconfiguration mechanisms may need a routing protocol,



Moustafa, et al.           Expires May 6, 2009                 [Page 11]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


   where if a routing protocol exist this will optimise the mechanisms
   operation and if no routing protocol exist, the mechanism could also
   work.


3.  Security Considerations

   Due to the open wireless environment of ad hoc networks, IP
   autoconfiguration mechanisms are susceptible to a number of attacks.
   The autoconfiguration problem statement draft [1] states some
   security issues that worth consideration.


4.  IANA Considerations

   This document has no actions for IANA.


5.  Acknowledgements

   The authors would like to thank Charles Perkins and Joe Macker for
   their comments and suggestions during 69th IETF.  We also like to
   thank Shubhranshu Singh and Thomas Clausen for their very valuable
   comments and suggestions on the content of this draft.

   Authors also want to point out that some useful content of [3] has
   been used in several ways in the present draft.

   The work of Carlos J. Bernardos and Maria Calderon has been partially
   supported by the Spanish Government under the POSEIDON (TSI2006-
   12507-C03-01) project.

   The work of Carlos J. Bernardos and Maria Calderon has also been
   partially funded 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.


6.  References

6.1.  Normative References

   [1]  Baccelli, E., Mase, K., Ruffino, S., and S. Singh, "Address
        Autoconfiguration for MANET: Terminology and Problem Statement",



Moustafa, et al.           Expires May 6, 2009                 [Page 12]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


        draft-ietf-autoconf-statement-04 (work in progress),
        February 2008.

   [2]  Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc Network
        Architecture", draft-ietf-autoconf-manetarch-07 (work in
        progress), November 2007.

6.2.  Informative References

   [3]  Clausen, T., "Evaluation Criteria for MANET Autoconf
        Mechanisms", draft-clausen-autoconf-criteria-00 (work in
        progress), July 2005.


Appendix A.  Change Log

   Changes from -02 to -03:
   o  New release to keep the document alive.

   Changes from -01 to -02:
   o  New release to keep the document alive.
   o  Update of some references.

   Changes from -00 to -01:
   o  Mainly editorial changes.


Authors' Addresses

   Hassnaa Moustafa
   France Telecom
   38-40 rue du General Leclerc
   Issy Les Moulineaux  92794 Cedex 9
   France

   Phone: +33 145296389
   Email: hassnaa.moustafa@orange-ftgroup.com


   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 6236
   Email: cjbc@it.uc3m.es




Moustafa, et al.           Expires May 6, 2009                 [Page 13]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


   Maria Calderon
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 8780
   Email: maria@it.uc3m.es











































Moustafa, et al.           Expires May 6, 2009                 [Page 14]


Internet-Draft     AUTOCONF evaluation considerations      November 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Moustafa, et al.           Expires May 6, 2009                 [Page 15]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/