MANET Autoconfiguration (Autoconf)                     E. Baccelli (Ed.)
Internet-Draft                                                     INRIA
Expires: August 3, 28, 2008                                          K. Mase
                                                      Niigata University
                                                              S. Ruffino
                                                          Telecom Italia
                                                                S. Singh
                                                                 Samsung
                                                        January 31,                               February 25, 2008

 Address Autoconfiguration for MANET: Terminology and Problem Statement
                    draft-ietf-autoconf-statement-03
                    draft-ietf-autoconf-statement-04

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 August 3, 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document states the problems pertaining to automatic IPv6
   address configuration and prefix allocation in MANETs.

   This draft currently contains terminology, target scenarios and goals
   for MANET autoconfiguration.  Future versions of this document will
   also review the applicability of existing IPv6 address
   autoconfiguration and prefix allocation mechanisms, and security
   considerations.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  MANET Categories . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Subordinate MANET  . . . . . . . . . . . . . . . . . . . .  5
       3.1.1.  Scenarios of Subordinate MANETs  . . . . . . . . . . .  6
     3.2.  Autonomous MANET . . . . . . . . . . . . . . . . . . . . .  6
       3.2.1.  Scenarios of Autonomous MANETs . . . . . . . . . . . .  7
   4.  MANET Autoconfiguration Goals  . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  Applicability of standard configuration solutions  . . . . . .  9
     5.1.  Applicability of DHCP  . . . . . . . . . . . . . . . . . .  9
       5.1.1.  Issues with DHCP Fundamental Assumptions . . . . . . .  9
       5.1.2.  What DHCP Can and Cannot Do in MANETs  . . . . . . . . 10
     5.2.  Applicability of SLAAC/NDP . . . . . . . . . . . . . . . . 10
       5.2.1.  Issues with SLAAC/NDP Fundamental Assumptions  . . . . 10
       5.2.2.  What SLAAC/NDP Can and Cannot Do in MANETs . . . . . . 11
     5.3.  Applicability of DHCP-PD . . . . . . . . . . . . . . . . . 11
       5.3.1.  Issues with DHCP-PD Fundamental Assumptions  . . . . . 11
       5.3.2.  What DHCP-PD Can and Cannot Do in MANETs . . . . . . . 11
   6.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  Solutions Requirements . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7. 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1. 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2. 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11 17
   Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . 19
   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 . . 20
   Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 15 22

1.  Introduction

   As defined in [1], a MANET is a network composed of MANET routers,
   each of which has at least one MANET interface.  This document states
   the goals of autoconfiguration mechanism(s) for MANETs, with respect
   to the necessary parameters for basic IP identification.
   Specifically, this document thus states the requirements for:

   - autoconfiguring MANET interfaces with IPv6 addresses;

   - automatic allocation of IPv6 prefixes to MANET routers.

   This draft currently contains terminology, target scenarios and goals
   for MANET autoconfiguration.  Future versions of this document will
   also review the applicability of existing IPv6 address
   autoconfiguration and prefix allocation mechanisms, and security
   considerations.

2.  Terminology

2.  Terminology

   This document uses the terminology defined in [1], as well as the
   following terms :

   External Network  - a network connected to the MANET, through an
      interface that is not part of this MANET.

   Subordinate MANET  - a MANET, which is connected to one or more
      external network(s), and where such external network(s) are
      imposing an addressing hierarchy scheme on the MANET.

   Autonomous MANET  - a MANET upon which no external network imposes an
      addressing hierarchy.

   Address autoconfiguration  - the process of configuring an interface
      with a given address, using an automatic mechanism (contrary to
      manual configuration).

   Prefix allocation  - the process of providing a router with authority
      over an aggregatable pool of addresses (i.e. a prefix), for the
      purpose of configuring interfaces its interfaces, or other routers. nodes.

   Disjoint prefixes  - two prefixes are said to be disjoint if and only
      if their respective address ranges do not overlap.

   Network merging  - the process by which two or more previously
      disjoint
      disconnected MANETs get connected.

   Network partitioning  - the process by which a MANET splits into two
      or more disconnected MANETs.

3.  MANET Categories

   IP address autoconfiguration on MANET interfaces and prefix
   allocation for MANET routers may be used in a number of deployment
   scenarios.  This section outlines the different types of scenarios
   that are to be addressed by solutions for MANET autoconfiguration.

   Note that solutions should also aim at coping with special cases such
   as a MANET transiting from one type of scenario to an other, or such
   as routers pre-configured with IP addresses (or prefixes) joining the
   MANET.

3.1.  Subordinate MANET

   A subordinate MANET, as shown in Fig. 1, is a MANET which is
   connected to at least one external network N that imposes a specific
   addressing hierarchy on the MANET.  In a subordinate MANET, this
   addressing hierarchy yields the use of specific prefixes for
   communications between nodes in the MANET and nodes in or across
   network N. For instance, in Fig. 1, these prefixes need to be
   topologically correct, i.e. allocated from within a prefix p::, over
   which the point of attachment to network N has authority.

                   '.                           /
                    `.        Network N        /
                      `.                    _,'
                        `-.__           _,,'
                             `'-.,._,,''
                                 :         Topologically correct prefix
                               +-:-+       p:: with respect to network N
                               |MNR|
                               +-|-+
              +-+  +---+ /      /|\       \ +---+
              | |...MNR---       .-.      ---MNR|
              +-+  +---+ \    ,-(  _)-.   / +---+
                           .-(_ MANET  )-.
              Other       ( Communication )
              Nodes          `-(______)-'
              and         \|/             \|/
              Networks   +-|-+           +-|-+
                         |MNR|    \|/    |MNR|
                         +-:-+   +-|-+   +-:-+
                                 |MNR|     :
                                 +-:-+    +-+
                                          +-+

            Figure 1: Subordinate MANET. Imposed address
               hierarchy by external network N.

3.1.1.  Scenarios of Subordinate MANETs

   This section contains a non-exhaustive list of examples of MANETs
   falling in the subordinate category.

   A typical example of subordinate MANET is a MANET that is part of the
   Internet, which yields the use of topologically correct IP addresses
   in order to communicate over the Internet.  For instance public
   wireless mesh networks, i.e. scattered fixed WLAN access routers
   participating in a MANET of mobile users, and acting as border
   routers.

   Another typical example is the coverage extension of a fixed wide-
   area wireless network, where one or more MANET router(s) are
   connected to the Internet through technologies such as UMTS or WiMAX.

   Car-to-car

   Vehicle communication networks connected to an external
   infrastructure may also be understood as an instance of subordinate
   MANET.

3.2.  Autonomous MANET

   Autonomous MANETs are MANETs upon which no external network imposes
   an addressing hierarchy.  This is shown in Fig. 2, as opposed to the
   subordinate MANET category described in Section 3.1.

                               +---+
                               |MNR|
                               +-|-+
              +-+  +---+ /      /|\       \ +---+
              | |...MNR---       .-.      ---MNR|
              +-+  +---+ \    ,-(  _)-.   / +---+
                           .-(_ MANET  )-.
              Other       ( Communication )
              Nodes          `-(______)-'
              and         \|/             \|/
              Networks   +-|-+           +-|-+
                         |MNR|    \|/    |MNR|
                         +-:-+   +-|-+   +-:-+
                                 |MNR|     :
                                 +-:-+    +-+
                                          +-+

        Figure 2: Autonomous MANET. No subordination to an
         addressing scheme imposed by an external network.

3.2.1.  Scenarios of Autonomous MANETs

   This section contains a non-exhaustive list of instances of MANETs
   falling in the autonomous category.

   Typical examples of autonomous MANETs are networks set-up in areas
   where infrastructure is unavailable or inapproriate. inappropriate.  For instance,
   car-to-car communication for sharing traffic and safety-related
   information, on-site emergency communication among rescue team
   members for disaster recovery, file sharing in conference or class
   rooms.

4.  MANET Autoconfiguration Goals

   The goals of AUTOCONF is to provide autoconfiguration mechanisms
   which allow each MANET router to:

   1. configure IPv6 addresses that are unique within the MANET, on
   their MANET interface(s).

   2. be allocated IPv6 prefixes that are disjoint from prefixes
   allocated to other routers within the MANET.

   3. maintain, within the MANET, the uniqueness of configured addresses
   and the disjoint character of allocated prefixes (even in face case of
   network merging).

   4. be allocated topologically correct prefixes, in the subordinate
   MANET scenario.

5.  Security Considerations  Applicability of standard configuration solutions

   This document does not currently introduce security considerations
   beyond those captured section reviews the applicability of existing standard protocols
   for the purposes listed in Section 4.  Note that MANET routers are
   assumed to also run these standard protocols as usual over non-MANET
   interfaces, if any.

5.1.  Applicability of DHCP

   DHCP [4] enables automatic allocation of an IP address to a node by [1].

6.  IANA Considerations

   This document does not specify IANA considerations.

7.  References

7.1.  Normative References

   [1]   Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc
         Network Architecture", ID draft-ietf-autoconf-manetarch,
         February 2007.

7.2.  Informative References

   [2]   Macker, J. and S. Corson, "MANET Routing Protocol Performance
         Issues a
   DHCP server.  A node requiring an IP address contacts a DHCP server
   and Evaluation Considerations", RFC 2501, January 1999.

   [3]   Narten, T., Nordmark, E., Simpson, W., requests an address.  The DHCP server will dynamically assign an
   address from a certain pool of addresses, and H. Soliman,
         "Neighbor Discovery allocate a so called
   ''lease'' of that address to the client.  The client can then use the
   address for IPv6", RFC 4861, September 2007.

   [4]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
         Carney, "Dynamic Host Configuration Protocol a certain time.  If the client wants to keep the address
   for IPv6",
         RFC 3315, July 2003.

   [5]   Narten, T., Thomson, S., and T. Jinmei, "IPv6 Stateless Address
         Autoconfiguration", RFC 4862, September 2007.

   [6]   Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
         Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.

   [7]   Draves, R. and D. Thaler, a longer time, it has to prolong the lease.  If the DHCP server
   is not on the same link as the DHCP client, it is possible to use one
   or more DHCP relay agent to forward the messages to a different
   subnet.

5.1.1.  Issues with DHCP Fundamental Assumptions

   DHCP works on the basic assumption that every node in the MANET can
   directly communicate with either (i) the DHCP server, or (ii) a DHCP
   relay which can communicate with either the DHCP server or another
   relay.

   As described in [1], part (i) of this assumption is often wrong in a
   MANET, as each node may see a different set of neighboring MANET
   nodes.  On the other hand, part (ii) of this assumption relies on the
   guarantee that the recursion will end at some point (by reaching the
   root, i.e. the DHCP server).  Because of the dynamics in MANET
   topology and MANET membership described in [1], there is no such
   assurance in a MANET, as the DHCP server may be unreachable, or a
   loop may have appeared along the path.

   Moreover, DHCP works with the assumption that either (a) there is a
   unique DHCP server in the network, or (b) if there are several DHCP
   servers in the network, they are manually configured accordingly.
   Because of the dynamics in MANET membership described in [1], there
   is no such assurance in a MANET, as topology changes may produce a
   situation where several servers with conflicting configuration
   parameters (e.g. managing non-disjoint pools of local addresses)
   become part of the same MANET.  Servers may thus require dynamic
   (re)configuration.

   Similarly, DHCP works with the assumption that should there be DHCP
   relays, they benefit from appropriate manual configuration.  Because
   of the dynamics in MANET membership and topology described in [1],
   there is no such assurance in a MANET.  Configuration may not remain
   appropriate over time, and relays may thus require dynamic
   (re)configuration.

5.1.2.  What DHCP Can and Cannot Do in MANETs

   DHCP "as is" could be used to some extent for address configuration
   purposes (goal 1, listed in Section 4).  However DHCP's applicability
   in this context is limited.  Indeed, if the topology is or becomes
   such that a MANET router does not have access to a DHCP server
   directly nor through a relay, DHCP is not operational.

   DHCP "as is" could also be used to some extent for uniqueness
   maintenance purposes (goal 3, listed in Section 4).  However DHCP's
   applicability in this context is limited.  Since different DHCP
   servers will not automatically check the disjoint character of the
   pools of addresses they provide leases from, if the topology is or
   becomes such that several DHCP servers with conflicting configuration
   lease addresses in the same MANET, there is no guarantee that
   configured addresses will indeed be unique.

5.2.  Applicability of SLAAC/NDP

   Stateless Address Autoconfiguration (SLAAC [5]) enables automatic
   configuration of an IP address to a host without contacting any kind
   of server.  A host first constructs a tentative IPv6 address by
   attaching its host identifier (in most cases its MAC address) to the
   well-known link-local prefix.  It then operates duplicate address
   detection, that verifies that no other host on the link has the same
   address by broadcasting NDP messages [3].  If the address is not
   unique, the autoconfiguration process will abort.  Upon a successful
   address uniqueness test, a host may request a prefix from any router
   on the link by an exchange of NDP messages.  It will again attach its
   host identifier to that router prefix and repeats the address
   uniqueness test sequence.

5.2.1.  Issues with SLAAC/NDP Fundamental Assumptions

   SLAAC relies on NDP signalling, which works on the basic assumption
   that each node in the MANET can communicate directly with every other
   node in the MANET, i.e. all the nodes are connected to a single
   multicast-enabled link.  As described in [1], this assumption is
   often wrong in a MANET, as each node may see a different set of
   neighboring MANET nodes.

5.2.2.  What SLAAC/NDP Can and Cannot Do in MANETs

   SLAAC "as is" could be used to some extent for address configuration
   and uniqueness maintenance purposes (goal 1 and 3, listed in
   Section 4), for instance when no DHCP server is available.  However
   SLAAC's applicability in this context is limited, since NDP messages
   are not relayed beyond the ''link'' (or in MANET terms, beyond the
   first hop).  If topology is or becomes such that the MANET is not
   contained in a single hop, there is no guarantee that the configured
   addresses will indeed be unique, since signalling will not reach all
   the concerned nodes.

5.3.  Applicability of DHCP-PD

   DCHP-PD [17] is a DHCP option that enables automatic allocation of
   IPv6 prefixes to routers using DHCP.  A router may request a prefix
   allocation from a DHCP server by sending a DHCP request including the
   Prefix Delegation option.  The server may then delegate a sub-prefix
   (i.e. a subset of its address pool) to the router.  The DHCP message
   containing the Prefix Delegation option may be relayed through one or
   more DHCP relays, as per [4].

5.3.1.  Issues with DHCP-PD Fundamental Assumptions

   DHCP-PD is based on DHCP, and thus encounters the fundamental issues
   described in Section 5.1.1, with respect to server reachability, and
   dynamic (re)configuration of servers and relays.

5.3.2.  What DHCP-PD Can and Cannot Do in MANETs

   DHCP-PD "as is" could be used to some extent for prefix allocation
   purposes (goals 2 and 4 listed in Section 4) and for uniqueness
   maintenance purposes (goal 3, listed in Section 4).  However DHCP-
   PD's applicability in this context is limited.  If topology is or
   becomes such that the MANET router cannot communicate with a DHCP
   server, DHCP-PD is not operational.  Moreover, if topology is or
   becomes such that several servers with conflicting configuration
   become part of the same MANET, there are no automatic
   (re)configuration mechanisms available in order for servers to
   dynamically adapt to the situation.

6.  Problem Statement

   SLAAC, NDP, DHCP and DHCP-PD provide only a partial solution with
   respect to the goals listed in Section 4.  As explained in
   Section 5.1, Section 5.2, and Section 5.3, existing protocols "as is"
   cannot deal with the specific dynamic, multi-hop and distributed
   nature of MANETs.  Additional solutions are thus needed to complete
   the goals of MANET IPv6 autoconfiguration.

6.1.  Solutions Requirements

   The following list presents the requirements for potential IPv6
   address autoconfiguration solutions:

   R 01.  Solutions must configure MANET interfaces with IPv6 addresses
      that are unique within the MANET.

   R 02.  Solutions must configure routers within the same MANET with
      disjoint prefixes.

   R 03.  Solution must work even without a MANET routing protocol.
      However, solutions may leverage the presence of routing protocols,
      for optimization purposes.

   R 04.  Solutions must provide a mechanism to prevent and deal with
      address or prefix conflicts (due for instance to network merging,
      change in MANET membership, preconfiguration or misconfiguration).

   R 05.  Solutions must be designed taking into account the particular
      characteristics of MANETs [1], including their multi-hop nature,
      and the potential asymetry of links.

   R 06.  Solutions must achieve their goal(s) with low control
      overhead.

   R 07.  Solutions must achieve their goal(s) with low delay or
      convergence time.

   R 08.  Solutions must ensure backward compatibility with other
      standards defined by the IETF.

   R 09.  Solutions must not require modifications of existing protocols
      on non-MANET interfaces and non-MANET routers.

   R 10.  Solutions should address security threats considered in
      existing IPv6 autoconfiguration mechanisms.  In addition,
      solutions should address potential MANET-specific threats (see
      Section 7).

   R 11.  Solutions should work in MANETs connected to an external
      network via multiple border routers, as well as in MANETs
      connected to multiple external networks.

   R 12.  In the case of subordinate MANETs, solutions should have a
      minimal impact on the routing system of the external network(s) to
      which a MANET is connected.  In particular, this includes the
      following:

      R 12.1.  Solutions should not preclude prefix aggregation at the
         edge of the subordinate MANETs.

   R 13.  Solutions should support transitioning from one MANET scenario
      to another (e.g. from subordinate to autonomous or vice-versa).

   R 14.  Solutions may be designed in a modular way, each module
      addressing a specific subset of the requirements or scenarios.

7.  Security Considerations

   A significant security issue is that of maintaining the
   confidentiality and the integrity of some data being exchanged
   between communication end-points in the MANET (e.g. between a server
   and a client).  This task is equivalent to that of ensuring end-to-
   end security in other types of networks, and existing techniques are
   therefore applicable.

   An orthogonal issue with respect to securing MANET protocols is
   ensuring network integrity.  So far, MANET protocols in general allow
   any node to participate in the network - the assumption being that
   all nodes are well-behaving and welcome.  If that assumption fails,
   i.e. if the network may count malicious nodes, the integrity of the
   network may fail.  Specific malicious behaviour include, but are not
   limited to, jamming (resulting in DoS), incorrect traffic generation
   (e.g. server, router or address spoofing), incorrect traffic relaying
   (e.g. "man in the middle"), or replay attacks.  Most of these threats
   are already taken into account in RFC 3756, RFC 3971, and the
   security sections of RFC 4861 and RFC 3315.

   DoS attacks can highly penalize the operation of IP autoconfiguration
   solutions, through increasing the signalling overhead and hence
   harming the solutions' convergence time.  "Man-in-the-middle" attacks
   can cause (i) interception of the IP autoconfiguration messages and
   hence operation failure, (ii) messages' modifications leading for
   example to changing assigned IP addresses or prefixes during their
   transfer and hence causing address or prefix conflicts, (iii)
   impersonation, which allows a non-legitimate MANET router to
   participate in the IP autoconfiguration process in place of a
   legitimate node, and may lead to DoS.  On the other hand, IP spoofing
   can also lead to impersonation, whereby an IP address can be spoofed
   by a non-legitimate node during transfer.

   Existing security solutions usually protect network integrity through
   authentication guaranteed by a "higher" authority, trusted a priori,
   which typically issues the cryptographic keys used to authenticate.
   However, for instance in autonomous MANET scenarios, there may not be
   any "higher" authority, or if there is, it may not be trusted a
   priori by every node in the MANET.

   Encryption is thus essential to many existing security mechanisms.
   However it may affect convergence time or require a process that is
   too heavy in the context of MANETs, since a significant part of the
   nodes in a MANET may have limited resources.

   Another issue specific to MANETs is related to the potential
   selfishness behaviour of some MANET nodes, a.k.a. "the selfish node
   problem".  This behaviour can cause non-cooperation between MANET
   nodes during the IP autoconfiguration process, and hence affect the
   operation of autoconfiguration mechanisms.

   In the context of MANET IPv6 autoconfiguration, such MANET
   characteristics are to be considered in addition to general
   characteristics supported by existing IPv6 autoconfiguration
   solutions.

8.  IANA Considerations

   This document does not specify IANA considerations.

9.  References

9.1.  Normative References

   [1]   Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc
         Network Architecture", ID draft-ietf-autoconf-manetarch,
         February 2007.

9.2.  Informative References

   [2]   Macker, J. and S. Corson, "MANET Routing Protocol Performance
         Issues and Evaluation Considerations", RFC 2501, January 1999.

   [3]   Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
         "Neighbor Discovery for IPv6", RFC 4861, September 2007.

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

   [5]   Narten, T., Thomson, S., and T. Jinmei, "IPv6 Stateless Address
         Autoconfiguration", RFC 4862, September 2007.

   [6]   Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
         Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.

   [7]   Draves, R. and D. Thaler, "Default Router Preferences and More-
         Specific Routes", RFC 4191, 2005.

   [8]   Moy, J., "OSPF version 2", RFC 2328, 1998.

   [9]   Moy, J., Coltun, R., and D. Ferguson, "OSPF for IPv6",
         RFC 2740, 1999.

   [10]  Chakeres, I., "Internet Assigned Numbers Authority (IANA)
         Allocations for the  Mobile Ad hoc Networks (MANET) Working
         Group", ID draft-ietf-manet-iana, May 2007.

   [11]  Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
         2001.

   [12]  Narten, T. and R. Draves, "Privacy Extensions for Stateless
         Address Autoconfiguration in IPv6", RFC 3041, 2001.

   [13]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
         Neighbor Discovery (SEND)", RFC 3971, 2005.

   [14]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         RFC 3972, 2005.

   [15]  Moore, N., "Optimistic Duplicate Address Detection (DAD) for
         IPv6", RFC 4429, 2006.

   [16]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
         Addresses", RFC 4193, 2005.

   [17]  Thubert, P. and TJ. Kniveton, "Mobile Network Prefix
         Delegation", ID draft-ietf-nemo-prefix-delegation, August 2007.

   [18]  Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6",
         RFC 3633, 2003.

Contributors

   Shubhranshu Singh, Samsung.
   Email: Shubranshu@gmail.com

   Kenichi Mase, Niigata University.
   Email: Mase@ie.niigata-u.ac.jp

   Simone Ruffino, Telecom Italia.
   Email: Simone.Ruffino@telecomitalia.it

   Carlos J. Bernardos, Universidad Carlos III de Madrid.
   Email: cjbc@it.uc3m.es

   Hassnaa Moustafa, France Telecom.
   Email: Hassnaa.Moustafa@orange-ftgroup.com

   Emmanuel Baccelli, INRIA.
   Email: Emmanuel.Baccelli@inria.fr

   Thomas Heide Clausen, LIX, Ecole Polytechnique.
   Email: T.Clausen@computer.org

Acknowledgements

   This document is the result of joint efforts, including those of the
   following contributers, listed in alphabetical order: benefited from specific feedback, and helpful
   discussions with C. Adjih, C.
   Bernardos, T. Boot, T. Clausen, C. Dearlove, U. Herberg, G.
   Montenegro, H. Moustafa, C. Perkins, A. Petrescu, P. Ruiz, P. Stupar, F. Templin,
   D. Thaler, R. Wakikawa, K. Weniger.

Authors' Addresses

Editor's Address

   Emmanuel Baccelli
   INRIA

   Phone: +33 1 69 33 55 11
   Email: Emmanuel.Baccelli@inria.fr

   Kenichi Mase
   Niigata University

   Phone: +81 25 262 7446
   Email: Mase@ie.niigata-u.ac.jp

   Simone Ruffino
   Telecom Italia

   Phone: +39 011 228 7566
   Email: Simone.Ruffino@telecomitalia.it

   Shubhranshu Singh
   Samsung

   Phone: +82 31 280 9569
   Email: Shubranshu@gmail.com

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.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).