[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                         U. Herberg
Internet-Draft                                                T. Clausen
Intended status: Informational                  LIX, Ecole Polytechnique
Expires: January 6, 2011                                    July 5, 2010


    Yet Another Autoconf Proposal (YAAP) for Mobile Ad hoc NETworks
                     draft-herberg-autoconf-yaap-00

Abstract

   This document describes automatic configuration of MANET router
   interfaces, as well as prefix delegation to MANET routers.  This
   autoconfiguration protocol is characterized by (i) adhering strictly
   to the Internet addressing architecture, (ii) being able to configure
   both MANET interface addresses and handle prefix delegation, and
   (iii) being able to configure both stand-alone MANETs, as well as
   MANETs connected to an infrastructure providing, e.g., globally
   scoped addresses/prefixes for use within the MANET.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 6, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Herberg & Clausen        Expires January 6, 2011                [Page 1]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  5
   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  5
   5.  Protocol Parameters and Constants  . . . . . . . . . . . . . .  6
     5.1.  Protocol and Port Numbers  . . . . . . . . . . . . . . . .  6
     5.2.  Multicast Address  . . . . . . . . . . . . . . . . . . . .  6
     5.3.  IP Header  . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.4.  Hold Times . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.5.  Time Granularity . . . . . . . . . . . . . . . . . . . . .  7
     5.6.  Message Intervals and Timeouts . . . . . . . . . . . . . .  7
     5.7.  Jitter . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Information Sets . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Neighbor Set . . . . . . . . . . . . . . . . . . . . . . .  8
     6.2.  Initiator Selector Set . . . . . . . . . . . . . . . . . .  9
     6.3.  Forwarded Set  . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Unique Identifiers . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Packets and Messages . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Prefix Solicitation (PS) Message . . . . . . . . . . . . . 10
       8.1.1.  PS Message Specification . . . . . . . . . . . . . . . 10
       8.1.2.  PS Message Generation  . . . . . . . . . . . . . . . . 11
       8.1.3.  PS Message Jitter  . . . . . . . . . . . . . . . . . . 11
       8.1.4.  PS Message Processing  . . . . . . . . . . . . . . . . 11
     8.2.  Prefix Advertisement (PA) Message  . . . . . . . . . . . . 11
       8.2.1.  PA Message Specification . . . . . . . . . . . . . . . 11
       8.2.2.  PA Message Generation  . . . . . . . . . . . . . . . . 12
       8.2.3.  PA Message Jitter  . . . . . . . . . . . . . . . . . . 12
       8.2.4.  PA Message Processing  . . . . . . . . . . . . . . . . 12
     8.3.  Router Solicitation (RS) Message . . . . . . . . . . . . . 13
       8.3.1.  Local RS Message from Configuring Router to
               Initiator Router . . . . . . . . . . . . . . . . . . . 13
       8.3.2.  MANET-wide RS Message from Initiator Router  . . . . . 16
     8.4.  Router Advertisement (RA) Message  . . . . . . . . . . . . 17
       8.4.1.  MANET-wide RA Message from Defensive Router  . . . . . 17
       8.4.2.  Local RA Message from Initiator Router to
               Configuring Router . . . . . . . . . . . . . . . . . . 18
     8.5.  Acknowledgement (AC) Message . . . . . . . . . . . . . . . 19
       8.5.1.  AC Message Specification . . . . . . . . . . . . . . . 19
       8.5.2.  AC Message Generation  . . . . . . . . . . . . . . . . 19
       8.5.3.  AC Message Jitter  . . . . . . . . . . . . . . . . . . 19
       8.5.4.  AC Message Processing  . . . . . . . . . . . . . . . . 20



Herberg & Clausen        Expires January 6, 2011                [Page 2]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


   9.  Message Considered for Forwarding  . . . . . . . . . . . . . . 20
   10. Router States  . . . . . . . . . . . . . . . . . . . . . . . . 21
     10.1. State Change . . . . . . . . . . . . . . . . . . . . . . . 21
       10.1.1. From Configuring State to Defensive State  . . . . . . 21
       10.1.2. From Defensive State to Configuring State  . . . . . . 21
   11. Initiator Selection  . . . . . . . . . . . . . . . . . . . . . 22
   12. Prefix Conflict  . . . . . . . . . . . . . . . . . . . . . . . 22
   13. Protocol Optimizations . . . . . . . . . . . . . . . . . . . . 22
     13.1. Proxying . . . . . . . . . . . . . . . . . . . . . . . . . 22
     13.2. Unicast RA Messages  . . . . . . . . . . . . . . . . . . . 22
     13.3. Optimized Broadcasting . . . . . . . . . . . . . . . . . . 22
   14. Additional Considerations  . . . . . . . . . . . . . . . . . . 23
     14.1. Duplicate UUIDs  . . . . . . . . . . . . . . . . . . . . . 23
     14.2. No initiator router exist  . . . . . . . . . . . . . . . . 23
     14.3. Initiator Proxying . . . . . . . . . . . . . . . . . . . . 23
   15. Proposed Values for Parameters and Constants . . . . . . . . . 23
   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
     16.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 23
     16.2. Message Types  . . . . . . . . . . . . . . . . . . . . . . 23
     16.3. Message TLV Types  . . . . . . . . . . . . . . . . . . . . 24
     16.4. Address Block TLV Types  . . . . . . . . . . . . . . . . . 25
   17. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   18. Normative References . . . . . . . . . . . . . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27



























Herberg & Clausen        Expires January 6, 2011                [Page 3]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


1.  Introduction

   This document adheres to the address architecture specified in
   [RFC5889], i.e.:

   o  IP addresses configured on an interface are unique, at least
      within the routing domain, and,

   o  No on-link subnet prefix is configured on this interface .

   This specification allows to configure MANET-local and global
   prefixes to MANET routers.  A router using the specified mechanism
   (i) acquires a MANET-wide unique prefix, and (ii) configures
   addresses from within this prefix for its interfaces as well as hosts
   attached to these routers (using any mechanism, such as SLAAC
   [RFC4861] or DHCPv6 [RFC3315]).  This document does not stipulate how
   to configure link-local addresses or link-local prefixes.


2.  Terminology

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

   This document uses the terminology and notation defined in [RFC5444].
   Additionally, it defines the following terminology:

   o  Configuring Router

         A Configuring Router is a router which has not yet configured a
         prefix, and which uses the protocol specified in this document
         in order to acquire a prefix.

   o  Initiator Router

         A Configuring Router selects one Initiator Router in the
         process of acquiring a prefix, which assists in validating the
         uniqueness of the chosen tentative prefix.

   o  Defensive Router

         A Defensive Router is a router which has already configured a
         prefix, and which can assist other, unconfigured routers (i.e.
         Configuring Routers) and thereby become an Initiator Router for
         unconfigured routers.




Herberg & Clausen        Expires January 6, 2011                [Page 4]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


3.  Applicability Statement

   This autoconfiguration mechanism is applicable for MANET routers.
   The mechanism allows to configure MANET-wide and globally unique
   prefixes on a router, adhering to the address architecture specified
   in [RFC5889].

   This mechanism is applicable for IPv6.


4.  Protocol Overview and Functioning

   Each MANET router will acquire a prefix, constructed as d:p:s:: with
   d being a prefix (possibly of size 0), common for the whole site
   (e.g., a global prefix assigned administratively to a given site, or
   provided by an Internet gateway), p being common for all routers in
   this MANET, and s being unique to a specific router.

   The task for a router, appearing in a MANET, can thus be summarized
   as:

   o  Acquiring d and p from the network;

   o  Selecting s, unique within the MANET;

   o  Configuring own MANET interfaces with addresses from within
      d:p:s:: (and with a prefix length of /128).

   A router, appearing in a network and wishing to be configured, is
   denoted a "Configuring router".  Through a Prefix Solicitation (PS) /
   Prefix Advertisement (PA) message exchange, the router learns of the
   (already configured) routers in its vicinity, and selects one as
   initiator - the router which will assist in acquiring a valid
   configuration.  The Configuring router extracts d and p from the PA
   received from the selected initiator, generates a tentative prefix
   d:p:s:: (s being generated locally by the Configuring router, e.g.,
   by a pseudorandom generator) and, by way of a Router Solicitation
   (RS) message requests from its initiator that this tentative prefix
   be verified unique within the MANET.  The initiator then issues an RS
   to the entire MANET, containing the tentative address of its
   Configuring router, through the MANET.  If the initiator does not
   (after due delay and retransmissions) receive a Router Advertisement
   (RA) indicating that the prefix is already in use, it will transmit
   an Autoconfiguration Confirmation (AC) message to the Configuring
   router, confirming that the Configuring router now "owns" d:p:s:: and
   can become a Defensive router.  If the initiator receives an RA
   indicating that the tentative prefix is already in use, it informs
   the Configuring router by issuing an RA.



Herberg & Clausen        Expires January 6, 2011                [Page 5]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


   A Defensive router has two tasks.  First, if receiving a RS
   containing its own d:p:s::, it must respond by issuing an RA.
   Second, if receiving a PS, it must respond by a PA, thus accept
   becoming initiator and act as described above.

   The initiator and Configuring routers communicate using link-local
   multicast to LL-MANET-Routers [RFC5498], with the configuring router
   using the Unspecified Address as source [RFC3513].  These two routers
   identify traffic destined to each other by way of UUIDsS.  [RFC4122],
   embedded in all messages exchanged between them.  UUIDs are 16 octets
   long, and as they are exchanged in messages only between neighboring
   routers, they need only be locally unique.  Network-wide messages
   (RS/RA) are "proxyed" by the initiator, which is already configured
   and which thereby has a MANET-wide unique address.


5.  Protocol Parameters and Constants

   This specification uses the parameters and constants described in
   this section.

5.1.  Protocol and Port Numbers

   This protocol specifies PS, PA, RS, RA, and AC messages, which are
   included in packets as defined by [RFC5444].  These packets may be
   sent either using the "manet" protocol number or the "manet" well-
   known UDP port number, as specified in [RFC5498].

5.2.  Multicast Address

   The packets (as defined by [RFC5444]) which contain the messages
   specified by this document may be locally transmitted using LL-MANET-
   Routers, as specified in [RFC5498].

5.3.  IP Header

   If the router is in the Configuring state, the source address in the
   IP header containing control messages is set to the Unspecified
   Address, as specified in [RFC3513].  For a router in any other state,
   the source address is set to any (non link-local) IP address of the
   interface transmitting the packet.

5.4.  Hold Times

   o  N_HOLD_TIME - determines how long a Neighbor Tuple is kept in the
      Neighbor Set in milliseconds.





Herberg & Clausen        Expires January 6, 2011                [Page 6]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


   o  I_HOLD_TIME - determines the maximum time duration that a
      Initiator Selector Tuple is kept in the Initiator Selector Set in
      milliseconds.

   o  F_HOLD_TIME - is the period after receipt of a message that is
      forwarded by this router for which that information is recorded,
      in order that the message is not forwarded again if received
      again.

   The following constraints applies to these router parameters:

   o  N_HOLD_TIME >= 0

   o  I_HOLD_TIME >= 0

   o  F_HOLD_TIME >= 0

5.5.  Time Granularity

   The constant C (time granularity) is used as specified in [RFC5497].

5.6.  Message Intervals and Timeouts

   o  PS_INTERVAL - specifies the time interval between two successive
      PS messages in milliseconds.

   o  PS_TIMEOUT - specifies the maximum time, in milliseconds, after
      the first transmitted PS which a router waits for an incoming PA
      message.  If no PA message has been received, this router switches
      from Configuring State to Defensive state as described in
      Section 10.1.1.

   o  RS_INTERVAL - specifies the time interval between two successive
      local RS messages in milliseconds.

   o  RS_TIMEOUT - specifies the maximum time, in milliseconds, after
      the first transmitted local RS message which a router waits for an
      incoming RA or AC message.  If no such message has been received,
      this router switches from Configuring State to Defensive state.

   o  RA_INTERVAL - specifies the time interval between two successive
      RA messages in milliseconds.

   o  RA_TIMEOUT - specifies the maximum time, in milliseconds, after
      the first transmitted RA during which this router transmits RA
      messages.





Herberg & Clausen        Expires January 6, 2011                [Page 7]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


   o  AC_INTERVAL - specifies the time interval between two successive
      AC messages in milliseconds.

   o  AC_TIMEOUT - specifies the maximum time, in milliseconds, after
      the first transmitted AC during which this router transmits AC
      messages.

5.7.  Jitter

   o  PS_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
      for generated PS messages on this MANET interface.

   o  PA_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
      for generated PA messages on this MANET interface.

   o  F_MAXJITTER - represents the default value of MAXJITTER used in
      [RFC5148] for messages forwarded by this router.


6.  Information Sets

6.1.  Neighbor Set

   A router's Neighbor Set records site prefixes and MANET prefixes of
   each of its 1-hop Defensive neighbor routers.  It consists of
   Neighbor Tuples, each representing a single such 1-hop neighbor:

   (N_UUID, N_is_initiator, N_site_prefix, N_site_prefix_length,
   N_manet_prefix, N_manet_prefix_length, N_iface, N_time)

   where:

   N_UUID - is the unique identifier of the neighbor, as received in a
   PA message.

   N_is_initiator - is a boolean flag that determines whether this
   neighbor is selected as initiator.

   N_site_prefix - is the site prefix d as indicated by a PA message.

   N_site_prefix_length - is the length of N_site_prefix in number of
   bits.

   N_manet_prefix - is the MANET prefix p as indicated by a PA message.

   N_manet_prefix_length - is the length of N_manet_prefix in number of
   bits.




Herberg & Clausen        Expires January 6, 2011                [Page 8]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


   N_iface - is the identifier of the network interface on which the
   neighbor can be reached.

   N_time - specifies when this Tuple expires and MUST be removed.

6.2.  Initiator Selector Set

   A router's Initiator Selector Set records UUIDs and tentative
   prefixes of each 1-hop Configuring neighbor router, which has
   selected this router as its initiator.  It consists of Initiator
   Selector Tuples, each representing a single 1-hop neighbor:

   (I_UUID, I_prefix, I_prefix_length, I_iface, I_time)

   where:

   I_UUID - is the unique identifier of the initiator selector, as
   received in a local RS message.

   I_prefix - is the tentative prefix s as indicated by the initiator
   selector in an RS message.

   I_prefix_length - is the length of I_prefix in number of bits.

   I_iface - is the identifier of the network interface on which the
   neighbor can be reached.

   I_time - specifies when this Tuple expires and MUST be removed.

6.3.  Forwarded Set

   A router has a single Forwarded Set which records signatures of
   messages which have been forwarded by the router.  It consists of
   Forwarded Tuples:

   (F_type, F_orig_addr, F_seq_number, F_time)

   where:

   F_type - is the forwarded Message Type;

   F_orig_addr - is the originator address of the forwarded message;

   F_seq_number - is the message sequence number of the forwarded
   message;

   F_time - specifies the time at which this Tuple expires and MUST be
   removed.



Herberg & Clausen        Expires January 6, 2011                [Page 9]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


7.  Unique Identifiers

   Throughout this document, it is supposed that routers have a unique
   identifier (UUID) of length of 16 octets, according to [RFC4122].
   This identifier can be created by a pseudo-random number generator or
   any other means (such as calculated from the MAC address of a network
   interface).  The identifier serves to discern routers without
   configured IP addresses in a 1-hop neighborhood.  They SHOULD be
   unique within a link-local scope.  If they are not unique within this
   scope, the mechanism will still work, however, as described in
   Section 14.1.


8.  Packets and Messages

   The packet and message format used by this protocol is defined in
   [RFC5444], which is used with the following considerations:

   o  This protocol specifies five Message Types, the Prefix
      Solicitation (PS) message, the Prefix Advertisement (PA) message,
      the Router Solicitation (RS) message, the Router Advertisement
      (RA) message, and the Acknowledgment (AC) message.

   o  PS, PA, and AC messages MUST NOT be forwarded, i.e., a <msg-hop-
      limit>, if present, MUST have the value 1.

   o  All five message types MAY be included in multi-message packets as
      specified in [RFC5444].

   o  Received messages MUST be parsed in accordance with [RFC5444].  A
      message which is not in conformance with [RFC5444] MUST be
      discarded without being processed.

   o  This protocol specifies two Address Block TLVs.  These TLV Types
      are all defined only with Type Extension = 0.  TLVs of other
      types, and of these types but without Type Extension = 0, are
      ignored by this protocol.

8.1.  Prefix Solicitation (PS) Message

   A PS message is broadcast by a Configuring router to its 1-hop
   neighbors in order to discover already configured routers, and if
   such exist, to acquire their site prefix and MANET prefix.

8.1.1.  PS Message Specification

   The <msg-addr-length> field is set to 15.  The PS message MUST not
   contain a <msg-orig-addr> header field. <msg-hop-limit> SHOULD be set



Herberg & Clausen        Expires January 6, 2011               [Page 10]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


   to 1.

   The PS message does not contain any addresses, Address Block TLVs, or
   Message TLVs (but MAY so by an extension of this protocol).

8.1.2.  PS Message Generation

   A PS message is generated per router and sent over all MANET
   interfaces when the router is not yet configured and desires to
   acquire a MANET-wide unique prefix.

   If no PA message has been received on any interface after
   PS_INTERVAL, the router generates a new PS message.

   If no PA message has been received within PS_TIMEOUT after the first
   generated PS message, the router assumes that it is the first router
   of the MANET and switches to the "Defensive state" (as described in
   Section 10.1.1).

8.1.3.  PS Message Jitter

   If using data link and physical layers which are subject to packet
   loss due to collisions, PS messages SHOULD be jittered as described
   in [RFC5148].  PS messages MUST NOT be forwarded, and thus message
   forwarding jitter does not apply to PS messages.  Each form of jitter
   described in [RFC5148] requires a parameter MAXJITTER.  These
   parameters may be dynamic, and are specified by PS_MAXJITTER.

8.1.4.  PS Message Processing

   A router in Configuring state MUST ignore incoming PS messages.

   A router in the Defensive state MAY trigger a PA message upon
   reception of an incoming PS message.  The PA message is transmitted
   on the same interface the PS message has been received as described
   in Section 8.2.

8.2.  Prefix Advertisement (PA) Message

   A PA message is broadcast by a Defensive router to its 1-hop
   neighbors, as a response to an incoming PS message.

8.2.1.  PA Message Specification

   The <msg-addr-length> field is set 15. <msg-hop-limit> SHOULD be set
   to 1.

   The PA message MUST contain a UUID Message TLV with the router's



Herberg & Clausen        Expires January 6, 2011               [Page 11]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


   Unique identifier (UUID) as TLV value and length 16 and type
   extension 1 (which indicates that it is a source UUID).

   The PA message MUST contain the MANET prefix, contained in an Address
   Block and associated with a MANET_PREFIX TLV.  The type extension of
   the MANET_PREFIX TLV determines the length of the prefix in number of
   bits.

   The PA message MAY contain the site prefix, contained in an Address
   Block and associated with a SITE_PREFIX TLV.  The type extension of
   the SITE_PREFIX TLV determines the length of the prefix in number of
   bits.

8.2.2.  PA Message Generation

   A PA message is generated by a Defensive router as a response to a
   received PS message, and transmitted over the same interface as the
   one on which the PS message was received.

8.2.3.  PA Message Jitter

   If using data link and physical layers which are subject to packet
   loss due to collisions, PA messages SHOULD be jittered as described
   in [RFC5148].  PA messages MUST NOT be forwarded, and thus message
   forwarding jitter does not apply to PA messages.  Each form of jitter
   described in [RFC5148] requires a parameter MAXJITTER.  These
   parameters may be dynamic, and are specified by PA_MAXJITTER.

8.2.4.  PA Message Processing

   If the router is in the Configuring state, the message is processed,
   otherwise it MUST be ignored.

   If the message is processed, the following steps MUST be performed:

   1.  Find the Neighbor Tuple which corresponds to the UUID contained
       in the UUID Message TLV of the message (henceforth current
       tuple).

   2.  If no such tuple exists, create a new one (henceforth current
       tuple) and add it to the Neighbor Set.

   3.  The values of the current tuple are set to:

       *  N_UUID: the unique identifier of the neighbor, as acquired
          from the UUID Message TLV in the PA message.





Herberg & Clausen        Expires January 6, 2011               [Page 12]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


       *  N_is_initiator: false

       *  N_site_prefix: is set to the prefix associated with the
          SITE_PREFIX Address Block TLV in the previously received PS
          message that triggered this PA transmission; this value may be
          NULL if no such TLV has been contained in the PS message.

       *  N_site_prefix: is set to the length of the N_site_prefix in
          number of bits, as acquired from the type extension of the
          SITE_PREFIX TLV or 0 if no SITE_PREFIX TLV has been contained
          in the PS message.

       *  N_manet_prefix: is set to the MANET prefix associated with the
          MANET_PREFIX Address Block TLV in the previously received PS
          message that triggered this PA transmission.

       *  N_manet_prefix_length: is set to the length of N_manet_prefix
          in number of bits, as acquired from the type extension of the
          MANET_PREFIX Address Block TLV.

       *  N_iface: is set to the interface identifier on which the PA
          message has been received.

       *  N_time: current time + N_HOLD_TIME (both in milliseconds)

8.3.  Router Solicitation (RS) Message

   A Configuring router sends a local Router Solicitation (RS) Message
   to its initiator (using link-local multicast and the UUID of the
   initiator in a Message TLV).  Upon reception of this local RS, the
   initiator broadcasts a Router Solicitation (RS) Message throughout
   the MANET, on behalf of the Configuring router.  In the following,
   these two different cases (RS between Configuring router and
   initiator router, and RS flooded by the initiator) are discerned.  In
   both cases, the same message type (RS) is used, as only the link-
   local RS contains the UUID TLV, which allows to differentiate between
   the two different message scopes.

8.3.1.  Local RS Message from Configuring Router to Initiator Router

8.3.1.1.  Local RS Message Specification

   The <msg-addr-length> field is set to 15.  The local RS message MUST
   NOT contain a <msg-orig-addr> header field. <msg-hop-limit> SHOULD be
   set to 1.

   The local RS message MUST contain a UUID Message TLV with the UUID of
   the router's selected initiator as value and type extension 0 (i.e.



Herberg & Clausen        Expires January 6, 2011               [Page 13]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


   indicating a destination UUID).

   The local RS message MUST contain a UUID Message TLV with this
   router's UUID as value and type extension 1 (i.e. indicating a source
   UUID).

   The local RS message MUST contain a TIMEOUT Message TLV with the
   value being:

      time_of_first_sent_RS - current_time + RS_TIMEOUT.

   where

   o  time_of_first_sent_RS is the time of the first RS that has been
      sent for the tentative prefix, or the current time if this message
      is the first one.

   The value is encoded using the format specified in [RFC5497].

   The local RS message MUST contain the tentative router prefix s in an
   address block associated with a TENTATIVE_PREFIX Address Block TLV
   with the value hereof being the length of the prefix in number of
   bits.

8.3.1.2.  Local RS Message Generation

   An RS message is generated after the router has selected an initiator
   (as specified in Section 11).  The message is sent to the MANET
   interface on which the initiator can be reached (determined from
   N_iface in the Neighbor Set).

   If no RA or AC message has been received on the N_iface interface
   from the selected initiator (determined from the Neighbor Tuple of
   the initiator) after RS_INTERVAL milliseconds, the router generates a
   new local RS message.  This process is repeated until an RA or AC
   message has been received, or otherwise RS_TIMEOUT milliseconds have
   passed since the first generated local RS message for this prefix.

   If then still no RA or AC message has been received, the router
   SHOULD restart the autoconfiguration process and start transmitting
   PS messages again (refer to Section 8.1) or select a new initiator
   router.

8.3.1.3.  Local RS Message Jitter

   No jitter is required for local RS messages, since only one router -
   the selected initiator - will process them.




Herberg & Clausen        Expires January 6, 2011               [Page 14]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


8.3.1.4.  Local RS Message Processing

   If the message does not contain any UUID Message TLVs, it is
   considered a MANET-wide RS Message and processed accordingly (refer
   to Section 8.3.2).

   If the router receiving an RS is in Configuring state, the message
   MUST be ignored.

   If the message does not contains a UUID Message TLV with type
   extension 0, it MUST be ignored.  Otherwise, if the value of that
   UUID Message TLV does not correspond to this router's UUID, the
   message MUST be ignored.

   If the message does not contain an address associated with a
   TENTATIVE_PREFIX Address Block TLV, the message MUST be ignored.

   If a prefix conflict between the router's prefix s and the address
   associated with a TENTATIVE_PREFIX Address Block TLV has been
   detected, a local RA message MUST be triggered (as specified in
   Section 8.4.2).

   If the message is not ignored, the following steps MUST be performed:

   1.  If no Initiator Selector Tuple exists, which corresponds to the
       UUID contained in the UUID Message TLV with type extension 0 in
       the message, create a new tuple and add it to the Initiator
       Selector Set. The values of the newly created tuple are:

       *  I_UUID: the unique identifier of the neighbor, as acquired
          from the UUID Message TLV in the RS message.

       *  I_prefix: is the prefix associated with the TENTATIVE_PREFIX
          Address Block TLV in the RS message.

       *  I_prefix_length is the length of the I_prefix in number of
          bits, as acquired from the value of the TENTATIVE_PREFIX
          Address Block TLV.

       *  I_iface: is set to the interface identifier on which the RS
          message has been received.

       *  I_time: current_time + max(I_HOLD_TIME,
          value_of_the_TIMEOUT_Message_TLV) # in milliseconds

   2.  A MANET-wide RS message is generated (refer to Section 8.3.2.2).





Herberg & Clausen        Expires January 6, 2011               [Page 15]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


8.3.2.  MANET-wide RS Message from Initiator Router

8.3.2.1.  MANET-wide RS Message Specification

   The <msg-addr-length> field is set to 15.  The MANET-wide RS message
   MUST contain a <msg-orig-addr> header field, which contains the
   prefix s of this router. <msg-hop-limit> SHOULD set to 255.  The
   MANET-wide RS message MUST contain a <msg-seq-num> field.

   The MANET-wide RS message MUST NOT contain any UUID Message TLVs.

   The MANET-wide RS message MUST contain the tentative prefix in an
   address block associated with a TENTATIVE_PREFIX Address Block TLV
   with the value being the length of the prefix in number of bits.  The
   prefix is acquired from the I_prefix field in the Initiator Selector
   Tuple that corresponds to the initiator selector that has sent the
   local RS message, which triggered this MANET-wide RS message.

8.3.2.2.  MANET-wide RS Message Generation

   Whenever a router has received a local RS message from a router that
   has selected it as its initiator (i.e. for which a corresponding
   Initiator Selector tuple exists), it generates a MANET-wide RS
   message and sends it to all MANET interfaces.

8.3.2.3.  MANET-wide RS Message Jitter

   No jitter is required for generating MANET-wide RS messages.
   However, for forwarded RS messages, jitter considerations as
   specified in Section 9 apply.

8.3.2.4.  MANET-wide RS Message Processing

   If the message contains a UUID Message TLV, it is considered as local
   RS Message and processed accordingly (refer to Section 8.3.1.4).

   If this router is in the Configuring state, the message MUST be
   ignored.

   If the message does not contain an address associated with a
   TENTATIVE_PREFIX Address Block TLV, the message MUST be ignored.

   If a prefix conflict between the router's prefix s and the address
   associated with a TENTATIVE_PREFIX Address Block TLV has been
   detected, a MANET-wide RA message MUST be generated, specified in
   Section 8.4.1.

   If no conflict has occurred, the message is considered for forwarding



Herberg & Clausen        Expires January 6, 2011               [Page 16]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


   as specified in Section 9.

8.4.  Router Advertisement (RA) Message

   A Defensive router floods a MANET-wide Router Advertisement (RA)
   Message throughout the MANET if it has detected a conflicting prefix
   (as specified in Section 12) advertised in an RS message.  When the
   initiator router for the conflicting prefix receives this RA, it
   generates a local RA message to its initiator selector (using link-
   local multicast and the UUID of the initiator in a Message TLV).  In
   the following, these two different cases (RA flooded by the
   conflicting router, and RA between initiator router and Configuring
   router) are discerned.  In both cases, the same message type (RA) is
   used, as only the link-local RA contains the UUID TLV, which allows
   to differentiate between the two different message scopes.

8.4.1.  MANET-wide RA Message from Defensive Router

8.4.1.1.  MANET-wide RA Message Specification

   The <msg-addr-length> field is set to 15.  The MANET-wide RA message
   MUST contain a <msg-orig-addr> header field. <msg-hop-limit> SHOULD
   be set to 255.  The MANET-wide RA message MUST contain a <msg-seq-
   num> field.

   The MANET-wide RA message MUST NOT contain a UUID Message TLV.

   The MANET-wide RA message MUST put its prefix (i.e. the prefix which
   is conflicting) in an address block and associate with a
   TENTATIVE_PREFIX Address Block TLV.

8.4.1.2.  MANET-wide RA Message Generation

   A MANET-wide RA message is generated as a response to an incoming
   MANET-wide RS message if a prefix conflict has been detected (as
   specified in Section 12).  The message is sent to all MANET
   interfaces.

   The router generates a new RA message RA_INTERVAL milliseconds after
   the last generated RA message.  This process is repeated until
   RA_TIMEOUT milliseconds have passed since the first generated RA
   message for this prefix.

8.4.1.3.  MANET-wide RA Message Jitter

   No jitter is applied to generated RA messages.  When forwarding an RA
   message, jitter is applied as specified in Section 9.




Herberg & Clausen        Expires January 6, 2011               [Page 17]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


8.4.1.4.  MANET-wide RA Message Processing

   If the message contains a UUID TLV, then:

   o  if this router is a Configuring router, the message is considered
      as local RA Message and processed accordingly (refer to
      Section 8.4.2).

   o  or otherwise the message MUST be ignored.

   If the message does not contain a UUID TLV, then:

   o  if the message contains an address associated with a
      TENTATIVE_PREFIX TLV, and the address is contained in the I_prefix
      field of an Initiator Selector Tuple, then the router generates a
      local RA as specified in Section 8.4.2.

   o  otherwise, the message is considered for forwarding as specified
      in Section 9.

8.4.2.  Local RA Message from Initiator Router to Configuring Router

8.4.2.1.  Local RA Message Specification

   The <msg-addr-length> field is set to 15. <msg-hop-limit> SHOULD be
   set to 1.

   The local RA message MUST contain a UUID Message TLV with type
   extension 0 with the value being the UUID of the initiator selector.
   The UUID is determined from the I_UUID field of the Initiator
   Selector Tuple whose I_prefix is equivalent to the address of the
   MANET-wide RA which is associated with an TENTATIVE_PREFIX Address
   Block TLV.

8.4.2.2.  Local RA Message Generation

   A local RA message is generated as a response to an incoming MANET-
   wide RA message, if the message contains a tentative prefix, which is
   equivalent to an I_prefix entry of an Initiator Selector Tuple.  The
   message is sent to the I_iface interface of the initiator selector.

8.4.2.3.  Local RA Message Jitter

   No jitter is applied.







Herberg & Clausen        Expires January 6, 2011               [Page 18]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


8.4.2.4.  Local RA Message Processing

   If the message does not contain a UUID Message TLV, then the message
   is processed as specified in Section 8.4.1.4.

   If the message contains a UUID TLV, then:

   o  if this router is a Configuring router and if the TLV value from
      the UUID Message TLV corresponds to this router's UUID, then this
      router MUST:

      *  Choose another tentative prefix s, and

      *  Restart the autoconfiguration process by generating RS messages
         with this new tentative prefix.

   o  or otherwise the message MUST be ignored.

8.5.  Acknowledgement (AC) Message

8.5.1.  AC Message Specification

   The <msg-addr-length> field is set to 15. <msg-hop-limit> SHOULD be
   set to 1.

   The AC message MUST contain a UUID Message TLV with type extension 0
   with the UUID of the Configuring router as TLV value.

   The AC message MUST contain the tentative prefix in an address block
   associated with an TENTATIVE_PREFIX Address Block TLV with the length
   of the prefix in number of bits as TLV value.

   The AC message MAY contain any other TLV as specified by extensions
   to this protocol.

8.5.2.  AC Message Generation

   An AC message is generated on a Defensive router when no RA message
   has been received for a tentative prefix of an initiator at the time
   the Initiator Selector Tuple expires (i.e. at I_time).  The message
   is sent to the I_iface interface of the initiator selector.

8.5.3.  AC Message Jitter

   No jitter is applied.






Herberg & Clausen        Expires January 6, 2011               [Page 19]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


8.5.4.  AC Message Processing

   If the receiving router is not a Configuring router, then the message
   MUST be ignored.

   Otherwise, if:

   o  the message contains a UUID TLV and the value from the UUID
      Message TLV corresponds to this router's UUID and

   o  the message contains an address associated with a TENTATIVE_PREFIX
      Address Block TLV, and the address is equivalent to this router's
      tentative prefix, then this router MUST:

      *  Select this prefix as permanent.

      *  Switch in the Defensive state (as specified in Section 10.1.1

   o  or otherwise the message MUST be ignored.


9.  Message Considered for Forwarding

   If a message (the "current message") is considered for forwarding,
   then the following tasks MUST be performed:

   1.  If a Forwarded Tuple exists with:

       *  F_type = the Message Type of the current message, AND;

       *  F_orig_addr = the originator address of the current message,
          AND;

       *  F_seq_number = the sequence number of the current message.

       then the current message MUST be silently discarded.

   2.  Otherwise:

       1.  The Message Header of the current message is modified by:

           +  if present, decrement <msg-hop-limit> in the Message
              Header by 1, AND;

           +  if present, increment <msg-hop-count> in the Message
              Header by 1.





Herberg & Clausen        Expires January 6, 2011               [Page 20]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


       2.  The message is transmitted over all interfaces.

   If using data link and physical layers which are subject to packet
   loss due to collisions, forwarded messages SHOULD be jittered as
   described in [RFC5148].  PS messages MUST NOT be forwarded, and thus
   message forwarding jitter does not apply to PS messages.  Each form
   of jitter described in [RFC5148] requires a parameter MAXJITTER.
   These parameters may be dynamic, and are specified by F_MAXJITTER.


10.  Router States

   A router is in either of the following states:

   o  Configuring

   o  Defensive

10.1.  State Change

10.1.1.  From Configuring State to Defensive State

   A router can change from Configuring state to Defensive state (i.e.
   complete the autoconfiguration process) in two different ways:

   1.  If no PA message has been received within PS_TIMEOUT milliseconds
       after the first generated PS message of a Configuring router, the
       router assumes that it is the first router of the MANET.  It then
       uses a predefined site-local prefix part "d", creates a random
       MANET prefix part "p" of length PREFIX_LENGTH using a pseudo-
       random number generator and concatenates a random router prefix
       part "s".  The Neighbor Set can be cleared (i.e. all Neighbor
       Tuples deleted).  The router switches to the "Defensive state".

   2.  If the Configuring router receives an AC message from its
       initiator router for the tentative prefix, the Configuring router
       uses a predefined site-local prefix part "d" and the MANET prefix
       part "p" that is has acquired by PA messages from the Initiator.
       It then concatenates a the tentative router prefix part "s",
       which it has verified to be unique within the MANET.  The
       Neighbor Set can be cleared (i.e. all Neighbor Tuples deleted).
       The router switches to the "Defensive state".

10.1.2.  From Defensive State to Configuring State

   TBD: Router releases the prefix and needs a new prefix.





Herberg & Clausen        Expires January 6, 2011               [Page 21]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


11.  Initiator Selection

   After a Configuring router has received at least one PA message, it
   may at any time select its initiator router among the neighbors from
   which it has received a PA message.  As soon as it has selected the
   initiator router, it can start generating RS messages.  This document
   does not specify how to select the initiator router.  For example, a
   router could select the first router that from which it has received
   a PA message.  PA messages MAY also include additional information by
   means of TLVs that can be used to determine the best initiator
   router.

   Examples of such information may be:

   o  number of routers in the MANET;

   o  density of the routers in the MANET;

   o  distance to an Internet gateway;

   o  distance to a certain address prefix.


12.  Prefix Conflict

   A prefix conflict occurs when a requested prefix (by means of an RS
   message) is equivalent to the router prefix of this router.

   TBD


13.  Protocol Optimizations

   The following protocol optimizations MAY be applied to the base
   protocol in order to increase performance.

13.1.  Proxying

   TBD

13.2.  Unicast RA Messages

   TBD

13.3.  Optimized Broadcasting

   TBD




Herberg & Clausen        Expires January 6, 2011               [Page 22]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


14.  Additional Considerations

14.1.  Duplicate UUIDs

   TBD

14.2.  No initiator router exist

   TBD

14.3.  Initiator Proxying

   TBD


15.  Proposed Values for Parameters and Constants

   TBD


16.  IANA Considerations

   This specification defines five Message Types, which must be
   allocated from the "Message Types" repository of [RFC5444], four
   Message TLV Types, which must be allocated from the "Message TLV
   Types" repository of [RFC5444], and one Address Block TLV Type, which
   must be allocated from the "Address Block TLV Types" repository of
   [RFC5444]

16.1.  Expert Review: Evaluation Guidelines

   For the registries where an Expert Review is required, the designated
   expert SHOULD take the same general recommendations into
   consideration as are specified by [RFC5444].

16.2.  Message Types

   This specification defines five Message Types, to be allocated from
   the 0-223 range of the "Message Types" namespace defined in
   [RFC5444], as specified in Table 1.











Herberg & Clausen        Expires January 6, 2011               [Page 23]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


                +------+----------------------------------+
                | Type |            Description           |
                +------+----------------------------------+
                | TBD1 |  PS: Prefix Solicitation message |
                | TBD2 | PA: Prefix Advertisement message |
                | TBD3 |  RS: Router Solicitation message |
                | TBD4 | RA: Router Advertisement message |
                | TBD5 |    AC: Acknowledgment message    |
                +------+----------------------------------+

                     Table 1: Message Type Assignment

16.3.  Message TLV Types

   This specification defines four Message TLV Types, which must be
   allocated from the "Message TLV Types" namespace defined in
   [RFC5444].  IANA is requested to make allocations in the 0-127 range
   for these types.  This will create four new Type Extension registries
   with assignments as specified in Table 2, Table 3, Table 4, and
   Table 5.  Specifications of these TLVs are in Section xxx and Section
   xxx, respectively.  Each of these TLVs MUST NOT be included more than
   once in a Message TLV Block.

   +------+------+-----------+----------------------------+------------+
   | Name | Type |    Type   |         Description        | Allocation |
   |      |      | Extension |                            |   Policy   |
   +------+------+-----------+----------------------------+------------+
   | UUID | TBD6 |     0     |  Specifies the destination |            |
   |      |      |           |  UUID of a neighbor router |            |
   | UUID | TBD7 |     1     |  Specifies the source UUID |            |
   |      |      |           |       of this router       |            |
   | UUID | TBD8 |   2-255   |         Unassigned         |   Expert   |
   |      |      |           |                            |   Review   |
   +------+------+-----------+----------------------------+------------+

                Table 2: Message TLV Type assignment: UUID

   +--------------+-------+-----------+-------------------+------------+
   |     Name     |  Type |    Type   |    Description    | Allocation |
   |              |       | Extension |                   |   Policy   |
   +--------------+-------+-----------+-------------------+------------+
   | MANET_PREFIX |  TBD9 |   0-128   |   Specifies the   |            |
   |              |       |           | MANET prefix part |            |
   |              |       |           |   with the type   |            |
   |              |       |           |  extension being  |            |
   |              |       |           | the length of the |            |
   |              |       |           |  prefix in number |            |
   |              |       |           |      of bits.     |            |



Herberg & Clausen        Expires January 6, 2011               [Page 24]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


   | MANET_PREFIX | TBD10 |   1-255   |     Unassigned    |   Expert   |
   |              |       |           |                   |   Review   |
   +--------------+-------+-----------+-------------------+------------+

            Table 3: Message TLV Type assignment: MANET_PREFIX

   +-------------+-------+-----------+--------------------+------------+
   |     Name    |  Type |    Type   |     Description    | Allocation |
   |             |       | Extension |                    |   Policy   |
   +-------------+-------+-----------+--------------------+------------+
   | SITE_PREFIX | TBD11 |   0-128   | Specifies the SITE |            |
   |             |       |           |  prefix part with  |            |
   |             |       |           | the type extension |            |
   |             |       |           |  being the length  |            |
   |             |       |           |  of the prefix in  |            |
   |             |       |           |   number of bits.  |            |
   | SITE_PREFIX | TBD12 |  129-255  |     Unassigned     |   Expert   |
   |             |       |           |                    |   Review   |
   +-------------+-------+-----------+--------------------+------------+

             Table 4: Message TLV Type assignment: SITE_PREFIX

   +---------+-------+-----------+------------------------+------------+
   |   Name  |  Type |    Type   |       Description      | Allocation |
   |         |       | Extension |                        |   Policy   |
   +---------+-------+-----------+------------------------+------------+
   | TIMEOUT | TBD13 |     0     |  Specifies the timeout |            |
   |         |       |           |   of the Configuring   |            |
   |         |       |           |    router which are    |            |
   |         |       |           |  waiting for AC or RA  |            |
   |         |       |           |        messages.       |            |
   | TIMEOUT | TBD14 |   1-255   |       Unassigned       |   Expert   |
   |         |       |           |                        |   Review   |
   +---------+-------+-----------+------------------------+------------+

               Table 5: Message TLV Type assignment: TIMEOUT

16.4.  Address Block TLV Types

   This specification defines one Address Block TLV Type, which must be
   allocated from the "Address Block TLV Types" namespace defined in
   [RFC5444].  IANA are requested to make allocations in the 8-127 range
   for this type.  This will create a new Type Extension registry with
   assignments as specified in Table 6.  Specification of this TLV is in
   Section xxx.






Herberg & Clausen        Expires January 6, 2011               [Page 25]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


   +------------------+-------+-----------+---------------+------------+
   |       Name       |  Type |    Type   |  Description  | Allocation |
   |                  |       | Extension |               |   Policy   |
   +------------------+-------+-----------+---------------+------------+
   | TENTATIVE_PREFIX | TBD15 |     0     | Specifies the |            |
   |                  |       |           |   tentative   |            |
   |                  |       |           |  prefix that  |            |
   |                  |       |           |   is checked  |            |
   |                  |       |           |      for      |            |
   |                  |       |           |  uniqueness.  |            |
   | TENTATIVE_PREFIX | TBD16 |   1-255   |   Unassigned  |   Expert   |
   |                  |       |           |               |   Review   |
   +------------------+-------+-----------+---------------+------------+

       Table 6: Address Block TLV Type assignment: TENTATIVE_PREFIX


17.  Security Considerations

   TBD


18.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              July 2005.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC5148]  Clausen, T., Dearlove, C., and B. Brian, "Jitter
              Considerations in Mobile Ad Hoc Networks (MANETs)",
              RFC 5148, February 2008.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized MANET Packet/Message Format", RFC 5444,



Herberg & Clausen        Expires January 6, 2011               [Page 26]


Internet-Draft       MANET Autoconf Proposal (YAAP)            July 2010


              February 2009.

   [RFC5497]  Clausen, T. and C. Dearlove, "Representing multi-value
              time in MANETs", RFC 5497, March 2009.

   [RFC5498]  Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
              (MANET) Protocols", RFC 5498, March 2009.

   [RFC5889]  Baccelli, E. and M. Townsley, "IP Addressing Model in Ad
              Hoc Networks", RFC 5889, July 2010.


Authors' Addresses

   Ulrich Herberg
   LIX, Ecole Polytechnique
   91128 Palaiseau Cedex,
   France

   Phone: +33-1-6933-4126
   Email: ulrich@herberg.name
   URI:   http://www.herberg.name/


   Thomas Clausen
   LIX, Ecole Polytechnique
   91128 Palaiseau Cedex,
   France

   Phone: +33-6-6058-9349
   Email: T.Clausen@computer.org
   URI:   http://www.thomasclausen.org



















Herberg & Clausen        Expires January 6, 2011               [Page 27]