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

Versions: 00 01 02

MANET Working Group                                       Ryuji Wakikawa
INTERNET DRAFT                                      Keio University/WIDE
Expires:07 Sep 2006                                       Antti Tuimonen
                                       Helsinki University of Technology
                                                          Thomas Clausen
                                                LIX, Ecole Polytechnique
                                                             07 Mar 2006

                  IPv6 Support on Mobile Ad-hoc Network
                draft-wakikawa-manet-ipv6-support-02.txt


   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 30, 2006.


   Copyright Notice

   Copyright (C) The Internet Society (2006).


R. Wakikawa et.al.              Expires 07 Sep 2006             [Page 1]


Internet Draft                   IPv6 MANET                  07 Mar 2006


   Abstract

   This draft defines the IPv6 addressing architecture for Mobile Ad-hoc
   Network.  This document includes problem statements when manet using
   IPv6, IPv6 addressing model, IPv6 manet node's required addresses.
   Note that this document does not discuss how an IPv6 address is
   allocated to each manet node.

                                  Contents


Status of This Memo                                                    1

Copyright Notice                                                       1

Abstract                                                               1

 1. Introduction                                                       2

 2. IPv6 Addressing for MANET                                          2
     2.1. Link Local Unicast Address  . . . . . . . . . . . . . . .    2
     2.2. Unique Local Unicast Address  . . . . . . . . . . . . . .    3
     2.3. Global Unicast Address  . . . . . . . . . . . . . . . . .    4

 3. Manet node requirements                                            4
     3.1. General node's required Address . . . . . . . . . . . . .    4
     3.2. Optional required address for global communication  . . .    5

 4. Source Address Selection                                           5

 5. Neighbor Discovery Protocol for MANET                              5
     5.1. Neighbor Cache Resolution . . . . . . . . . . . . . . . .    6
     5.2. Address Auto-configuration  . . . . . . . . . . . . . . .    6
     5.3. Duplicate Address Detection . . . . . . . . . . . . . . .    6

 6. MANET Routing Protocols                                            7
     6.1. Message Flooding  . . . . . . . . . . . . . . . . . . . .    7
     6.2. Neighbor Sensing  . . . . . . . . . . . . . . . . . . . .    8
     6.3. Consideration of Longer IPv6 Address  . . . . . . . . . .    8

 7. Running Mobility Protocols                                         8
     7.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . .    8
     7.2. Network Mobility  . . . . . . . . . . . . . . . . . . . .    9

References                                                            10

Authors' Addresses                                                    12


R. Wakikawa et.al.              Expires 07 Sep 2006             [Page 1]


Internet Draft                   IPv6 MANET                  07 Mar 2006


   1. Introduction

   This document investigates issues when IPv6 [3] is operated with
   mobile ad hoc networks.  In general, routing protocols disregard
   differences between IPv4 and IPv6, and suggest both can be supported
   if routing messages for both protocols are defined.  However, there
   are some differences which may well affect how the routing protocols
   should work with IPv6.

   In addition there are several issues that may or may not be covered
   in other documents.  This document tries to provide information about
   implementing and deploying IPv6 mobile ad hoc networks.  Addressing
   in mobile ad hoc networks is a problem for both IPv4 and IPv6.  When
   manet connects to the global Internet, IPv4 might do NAT, but in IPv6
   we want to have a more integrated solution.  This means potentially
   acquiring an address with global scope.  In an effort to alleviate
   problems related to address scopes [2], we first study applicability
   of each scope of addresses to mobile ad hoc networks and give
   guidelines for IPv6 address assignment.  After defining address
   assignment, we briefly discuss the Neighbor Discovery Protocol [10]
   operations and manet operations on IPv6 mobile ad hoc networks.


   2. IPv6 Addressing for MANET

   IPv6 has a notion of ``scope'' to control validity of each IPv6
   address.  In a manet, a link-local scope is used to identify a
   physical link and an edge of a manet is identified by a unique-local
   scope.  A global scope is used for global communication to the
   Internet.


   2.1. Link Local Unicast Address

   A link local unicast address is designed to use with on-link
   neighbors, but not over multi-hop.  The IPv6 specification prohibits
   forwarding packets sent to/from a link local address over a link.

   A manet does not have a clear link definition in terms of multi-hop
   routing.  Indeed, there are two interpretations of ``on-link'' in
   manet observation.

    -  physical medium [9]
       The link local address is valid only with one-hop neighbors.

    -  manet wide (till an edge of a manet)
       The link local address is valid over multi-hop.  However it
       breaks the original definition of link local address.


R. Wakikawa et.al.              Expires 07 Sep 2006             [Page 2]


Internet Draft                   IPv6 MANET                  07 Mar 2006


   Considering fact that many IPv6 related protocol including the
   Neighbor Discovery Protocol have already been operated with the
   legacy link local address definition, it is reasonable to inherit
   the original interpretation of ``link'' for manets.  Otherwise, it
   could break interoperability between a manet node and a node on the
   Internet.  It is possible that a node visits both an IPv6 network and
   a manet.

   The link local address is used only for communication with
   1-hop neighbors.  This address is also used for the Neighbor
   Discovery Protocol.  The link-local all-manet-node multicast
   address (ff02::TBD) is used for application flooding described in
   Section 6.1.

   Routes for link local addresses MUST NOT be exchanged over multi-hop
   neighbors by manet routing protocols.  A node may exchange routes
   for link local address with 1-hop neighbors, but this should be done
   carefully.  This is because whenever a manet node moves and a set of
   1-hop neighbors is changed, the route becomes invalid.  Thus, each
   manet node must carefully maintain routes for link local address.


   2.2. Unique Local Unicast Address

   A unique local unicast address is not routable on the global
   Internet, however it can be used for local communication within
   limited area such as site and manet.  More characteristics
   are described in [7].  A unique local unicast address is not
   automatically generated, but it is assigned through address
   auto-configuration [12], DHCPv6 [6], static, etc in an IPv6 network.
   The locally assigned unique local prefix is generated randomly
   by each network and assigned it without any verification of its
   uniqueness.  Even when a unique local prefix is duplicated, the
   damage of this duplication is kept in minimum, because the duplicated
   prefix is valid within each limited area and is not used for global
   communication.  Unless two networks are merged, they cannot know of
   duplication of the unique local prefix.

   IPv6 enabled mobile ad-hoc networks can be treated as a limited area
   due to its different routing approaches from the Internet (IGP, BGP,
   etc).  A unique Local Unicast address is expected to be assigned to
   all manet nodes.  The unique local unicast address is used only for
   local communication within manets.

   Routes for unique local address should be advertised and exchanged
   within a manet.  These routes MUST NOT be leaked out to the Internet.
   Even if some routes for unique local addresses are leaked out, the
   backbone routers located to the Internet would often reject and
   ignored these routes.  It is easier to exclude routes for unique


R. Wakikawa et.al.              Expires 07 Sep 2006             [Page 3]


Internet Draft                   IPv6 MANET                  07 Mar 2006


   local addresses from the global Internet in terms of different
   address scope.


   2.3. Global Unicast Address

   A global unicast address is routable on the global Internet and
   used for communications on the Internet.  A global unicast address
   must be unique on the Internet.  Having a global unicast address
   is not mandated to all manet nodes, but only to manet nodes which
   need global Internet connectivity.  The notion of global unicast
   address is applied without any changes to manets.  Only manet nodes
   which want global connectivity acquires a global unicast address
   through some mechanism.  A global unicast address can be used for
   both local communication within a manet and global communication to
   the Internet.

   Routes for topologically correct global address can be advertised
   to the Internet.  However, these routes MUST be aggregated.
   Un-aggregated routes, like host routes often used within a
   manet, SHOULD NOT be re-distributed to outside the manet without
   aggregation.

   On the other hand, some manet nodes may have a home address of
   Mobile IPv6 [8] and a mobile network prefix of the NEMO basic
   support protocol [4].  The routes for a home address and a mobile
   network prefix SHOULD NOT be leaked to the Internet because of
   topologically incorrectness.  Otherwise, it will disrupt the IPv6
   routing architecture.  Detailed operations can be found in Section 7


   3. Manet node requirements

   This section describes required address(es) for each manet
   node.  There are two classification, General required address and
   extra-required address for Connected manet ( [11])


   3.1. General node's required Address

   An isolated manet is a network formed dynamically with wireless manet
   nodes, but which is disconnected from the global Internet.  This is
   defined in  [11].

   Each manet node MUST generate a link local address according to the
   IPv6 specification [3] and MUST also obtain a unique local address.
   A unique local prefix, used for the generation of the unique local
   address, is identical to all nodes within each mobile ad-hoc network.
   The unique local address is generated from locally assigned unique


R. Wakikawa et.al.              Expires 07 Sep 2006             [Page 4]


Internet Draft                   IPv6 MANET                  07 Mar 2006


   global ID [7].  How to auto-configure an unique local address is out
   of scope for this specification.

   Even if two manets are merged, or if a manet is partitioned, the
   nodes should keep the originally assigned unique local prefix.
   When two manets are merged, they can exchange routes of two unique
   local prefixes within the merged manet, and can communicate between
   different unique local prefixes.  This can avoid address conflicts
   and prevents storm of duplicate address detection when manets are
   merged.  When a manet is partitioned, two networks now share the
   same unique local prefix.  However, these prefixes are not routed in
   the global Internet.  Thus, this is not problematic unless the two
   manets re-merge.  Each manet may re-assign a new unique local prefix
   for merged/separated scenarios.  However, this completely depends on
   address configuration mechanism and its operation.


   3.2. Optional required address for global communication

   A connected mobile ad-hoc network is a wireless multi-hop network
   that has global connectivity to the Internet by using Internet
   Gateway [13] or OSPF extensions.

   Each manet node acquires a global unicast address for global
   communication.  The assignment of global unicast address is needed
   for connected mobile ad-hoc network.  Whenever a manet node detects
   that the global address is not topologically correct in a foreign
   network, it MUST release the invalid global address and obtain
   topologically correct address.

   Note that manet routes for global addresses should not be leaked to
   the Internet without aggregation.


   4. Source Address Selection

   RFC3484 [5] specifies the source/destination address selection
   algorithm.  There is no special treatment for manets and each manet
   node uses the proposed default algorithm defined in [5].


   5. Neighbor Discovery Protocol for MANET

   Neighbor Discovery Protocol (NDP) assumes to be run on a link.
   However a manet does not have clear definition of ``link'' as
   described in Section 2.  A manet is wireless multi-hop network and
   all manet nodes inside a manet is expected to be a router.  Thus,
   this section discuss how NDP can be made fit for manets.


R. Wakikawa et.al.              Expires 07 Sep 2006             [Page 5]


Internet Draft                   IPv6 MANET                  07 Mar 2006


   Similar to the current NDP protocol, the IPv6 Hop Limit field of
   both Router Solicitation (RS), Router Advertisement (RA), Neighbor
   Solicitation (NS), Neighbor Advertisement (NA), and Redirect message
   must be set to '255' all the time.  The IP Hop Limit field set to 255
   indicates, that the packet should not be forwarded by a router.


   5.1. Neighbor Cache Resolution

   Although a manet does not have the clear definition of link, a manet
   node can resolve a neighbor cache (i.e.  MAC address) of one-hop
   neighbors by using NS and NA messages sent to and from link-local
   addressed.  It is enough for manet nodes to resolve neighbor caches
   of one-hop neighbors, because manet nodes do not share the physical
   link with two-hop neighbors.

   Even if a manet node can resolve a neighbor cache of two-hop
   neighbors, it can not send packets directly to the two-hop neighbors
   due to lack of L2 routing mechanisms.  Each manet node manages
   neighbor caches for one-hop neighbors and confirms manet node's
   reachability for one-hop neighbors by using NS and NA (i.e.  NDP).
   Neighbor nodes, located more than one-hop away, are confirmed by the
   manet routing protocol governing the network.

   It is important to inherit original interpretation of link for NDP. A
   manet node is not always connected to a manet, but it can be attached
   to an IPv6 link.  In such case, a manet node does not need to change
   the operation of NDP, while there is no mechanism to detect whether
   attached network is a manet or a normal IPv6 network.


   5.2. Address Auto-configuration

   IPv6 has an address auto-configuration scheme based on exchange of RS
   and RA. However, the address auto-configuration is not designed for
   wireless multi-hop networks (i.e.  manets).  A manet needs to extend
   or re-invent address auto-configuration schemes for global addresses
   and unique local addresses.  For global addresses, it is required
   that the addresses must be topologically correct and routable.
   [13].


   5.3. Duplicate Address Detection

   Duplicate Address Detection (DAD) can guarantee the uniqueness of any
   scope of addresses by sending a NS for a target address.  If a NA
   is detected in response to the NS, the address is duplicated.  DAD
   only defends addresses on a physical link due to link-local scope
   limitation of NS and NA. Thus, DAD can be conducted to guarantee


R. Wakikawa et.al.              Expires 07 Sep 2006             [Page 6]


Internet Draft                   IPv6 MANET                  07 Mar 2006


   only the uniqueness of addresses within one-hop neighbors.  (Note
   that even if there is no duplication within on-hop neighbors, it
   is possible that two-hop neighbors may have a duplicated address.)
   This is not useful because one-hop neighbors are often changed due
   to node mobility.  Once neighbors are changed, the uniqueness is not
   guaranteed.  Each manet node SHOULD stop using DAD and use another
   duplication address detection mechanism specially tuned for manet.


   6. MANET Routing Protocols

   6.1. Message Flooding

   There are two different forwarding engines for message flooding for
   manet routing protocols such as ``application forwarding'' and ``IP
   forwarding''.

    -  Application Forwarding:
       For application forwarding, it is required that each application
       (ex.  routing daemon) must send a flooded packet with single
       hop-limit to all neighbors.  The recipient processes the
       flooded packet and will re-send it to all its neighbors if
       necessary.  The flooded packets are thus repeatedly forwarded
       by an application until it has reached all nodes inside mobile
       ad-hoc network.  Most of manet routing protocol use application
       flooding for protocol message exchanges.

    -  IP Forwarding
       Flooded packets can be forwarded by IP layer.  The forwarding is
       totally blind from applications.  If a destination is multicast
       address, an application on each manet node receive the flooded
       packet, but the flooded packet is forwarded to next neighbors at
       IP layer at the same time.  The application should not need to
       re-send the flooded packet.

   For application flooding, each manet node sends a flooded packet to
   the link-local all-manet-node multicast address (ff02::TBD). If the
   flooded packet is used to setup a route for the sender node (i.e.
   reverse route), it should use the address except for link-local
   address as a source address.  This is because routes for link local
   addresses are garbage on multihop networks.  Otherwise, the source
   address should be set to a link-local address due to one hoplimit
   packets.

   For IP forwarding, each manet node needs to send a flooded
   packet from either global address or unique local address to an
   all-manet-multicast address that is currently undefined.  The
   all-manet-multicast address can be defined for global scope, but must


R. Wakikawa et.al.              Expires 07 Sep 2006             [Page 7]


Internet Draft                   IPv6 MANET                  07 Mar 2006


   be defined for unique local scope, too.  This is because all manet
   nodes do not always have global address.


   6.2. Neighbor Sensing

   Most manet routing protocols uses hello message to sense 1-hop
   neighbors.  IPv6 permits allocating multiple addresses to a single
   interface.  For example, a manet node may have 3 addresses (such as
   a link-local address, a unique local address, and a global address).
   In that case, each manet node SHOULD contain addresses except for
   link local addresses (i.e.  the unique local and global address).
   Even if the link local address is included in hello messages, the
   route for the link local address SHOULD not be maintained on each
   manet node.  The link local address SHOULD be used to send NS and NA
   for Neighbor Cache resolution.


   6.3. Consideration of Longer IPv6 Address

   The length of IPv6 address is 128-bit which is 4 times longer than
   IPv4 address.  Therefore, protocol messages including IPv6 routes are
   tend to be longer than the IPv4 counterparts.  Specially in proactive
   routing protocols, as a number of manet nodes are increased, routing
   messages could be longer.  If routing messages becomes larger than
   the link MTU, the messages are fragmented by IP layer.  This should
   be avoided since one piece of fragmented packets can be dropped due
   to unstable manet path (depending on topology change speed).  Each
   manet node SHOULD avoid IP fragmentation of each routing messages by
   divided the routing messages into multiple messages at higher than IP
   layer (i.e., applications).  In alternative way, routing messages can
   be shorten by any header or data compression mechanisms.


   7. Running Mobility Protocols

   7.1. Mobile IPv6

   In Mobile IPv6 [8], a mobile host has a permanent global scope
   address called its ``home address''.  When a mobile host roams into a
   manet, it can still use the home address as a source or destination
   address of communications.

   Although a mobile host can exchange routes for its home address
   (global scope) within manet by using the appropriate manet routing
   protocol, these routes should not be leaked to the Internet (i.e.
   IGP) as described in Section 2.3.  This is because a home address is
   not topologically correct global address and leaking topologically
   incorrect routes disturbs the IPv6 routing architecture.


R. Wakikawa et.al.              Expires 07 Sep 2006             [Page 8]


Internet Draft                   IPv6 MANET                  07 Mar 2006


   When a manet is an isolated manet, a mobile host can not acquire a
   global address and can not form a care-of address so that it will
   give up sending a binding update to its home agent.  Although Mobile
   IPv6 does not explicitly prohibit using unique-local address as a
   care-of address, but there is no specification for that.  A mobile
   host can keep using its home address in a visiting manet by exchange
   a manet route of its home address.  In such case, the mobile host
   does not use a bi-directional tunnel between it and home agent, but
   it sends packets along to manet routes.

   On the other hand, when a manet is connected manet, a mobile host
   can acquire a global address and register the care-of address to
   its home agent.  The mobile host can communicate with either a home
   address and a care-of address in a manet by route exchanges.  When
   the mobile host communicates with a destination located in the same
   manet, it may have a host route toward the destination and can skip
   using bi-directional tunnel for the destination.  If a destination
   is outside manet, the mobile host must encapsulate packets to its
   home agent as Mobile IPv6 does [8].  The mobile host may use route
   optimization for a destination located in either manet or the
   Internet.


   7.2. Network Mobility

   In the NEMO Basic Support protocol (NEMO) [4], a mobile router has
   a permanent global scope prefix called ``mobile network prefix''.
   A mobile router may also roam into manet with its mobile network
   prefix.

   A mobile router can exchange a route of its home address (global
   scope) and its mobile network prefix within manet by using manet
   routing protocols.  However these routes should not be leaked to
   the Internet (i.e.  IGP) as described in Sectionglobal, too.  It
   is because a home address and a mobile network prefix are not
   topologically correct global address at the visiting manet and
   leaking topologically incorrect routes disturbs the IPv6 routing
   architecture.

   When a mobile router, which is NEMO mobile router but not manet node,
   roams into an isolated manet, it can not acquire a care-of address
   and will give up home registration to its home agent.  However,
   the mobile router can exchange manet route for its mobile network
   prefix and use the manet route for communications from/to its mobile
   network.  The mobile router should not try to use a bi-directional
   tunnel as NEMO does.

   On the other hand, when a manet is connected manet, a mobile router
   can acquire a global address and register the care-of address to its


R. Wakikawa et.al.              Expires 07 Sep 2006             [Page 9]


Internet Draft                   IPv6 MANET                  07 Mar 2006


   home agent.  The mobile router also exchange manet route for its
   mobile network prefix.  When the mobile route finds that a manet
   route of a destination is in its routing table (i.e.  destination
   is located within the same manet), it can bypass all procedure of
   NEMO (i.e.  tunneling to home agent, etc) and will forward packets
   along the manet route.  If not, the mobile router process packets and
   tunnel them to its home agent according to binding information.  NEMO
   does not specify any route optimization scheme.

   Note that some issues related NEMO might be solved by using
   manet [1].


   Acknowledgments

   The authors would like to thank all the participants of OLSR
   workshop@San Diego.


   References

    [1] T. Clausen, E. Baccelli, and R. Wakikawa.  NEMO
        Route Optimisation Problem Statement (expired,
        draft-clausen-nemo-ro-problem-statement-00.txt).  Internet
        Draft, Internet Engineering Task Force, October 2004.

    [2] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, and B. Zill.
        IPv6 Scoped Address Architecture.  Request for Comments
        (Standards Track) 4007, Internet Engineering Task Force, March
        2005.

    [3] S. Deering and R. Hinden.  Internet Protocol, Version 6 (ipv6)
        Specification.  Request for Comments (Draft Standard) 2460,
        Internet Engineering Task Force, December 1998.

    [4] V. Devaraplli, R. Wakikawa, A. Petrescu, and P. Thubert.
        Network Mobility (NEMO) Basic Support Protocol (proposed
        standard).  Request for Comments 3963, Internet Engineering Task
        Force, January 2005.

    [5] R. Draves.  Default Address Selection for Internet Protocol
        (IPv6).  Request for Comments (Standards Track) 3484, Internet
        Engineering Task Force, February 2003.

    [6] R. Droms, J. Bound, B. Volz, and T. Lemon.  Dynamic Host
        Configuration Protocol for IPv6 (DHCPv6).  Request for Comments
        (Best Current Practice) 3315, Internet Engineering Task Force,
        July 2003.


R. Wakikawa et.al.             Expires 07 Sep 2006             [Page 10]


Internet Draft                   IPv6 MANET                  07 Mar 2006


    [7] R. Hinden and B. Haberman.  IPv6 Scoped Address Architecture.
        Request for Comments (Standards Track) 4193, Internet
        Engineering Task Force, October 2005.

    [8] D. Johnson, C. Perkins, and J. Arkko.  Mobility support in
        IPv6.  Request for Comments (Proposed Standard) 3775, Internet
        Engineering Task Force, June 2004.

    [9] J. Manner and M. Kojo.  Mobility related terminology.  Request
        for Comments 3753, Internet Engineering Task Force, June 2003.

   [10] T. Narten, E. Nordmark, and W. Simpson.  Neighbor Discovery for
        IP Version 6 (ipv6).  Request for Comments (Draft Standard)
        2461, Internet Engineering Task Force, December 1998.

   [11] S. Ruffino, P. Stupar, and T. Clausen.  Autoconfiguration in a
        MANET: connectivity scenarios and technical issues.  Internet
        Draft (draft-ruffino-manet-autoconf-scenarios-00) , Internet
        Engineering Task Force, October 2004.

   [12] S. Thomson and T. Narten.  IPv6 Stateless Address
        Autoconfiguration.  Request for Comments (Draft Standard) 2462,
        Internet Engineering Task Force, December 1998.

   [13] R. Wakikawa, J. Malinen, C. Perkins, A. Nilsson, and
        A. Tuominen.  Global Connectivity for IPv6 Mobile Ad Hoc
        Networks (work in progress, draft-wakikawa-manet-globalv6-05).
        Internet Draft, Internet Engineering Task Force, March 2005.


R. Wakikawa et.al.             Expires 07 Sep 2006             [Page 11]


Internet Draft                   IPv6 MANET                  07 Mar 2006


   Authors' Addresses


     Ryuji Wakikawa
     Keio University
     Dept.  of Environmental Information
     5322 Endo Fujisawa Kanagawa
     252, JAPAN
     Phone:  +81-466 49-1394
     EMail:  ryuji@sfc.wide.ad.jp

     Antti J. Tuominen
     Helsinki University of Technology
     Laboratory for Theoretical Computer Science
     P.O. Box 9201
     HUT FIN-02015, Finland
     Phone:  +358 9 451 5136
     Fax:  +358 9 451 5351
     EMail:  anttit@tcs.hut.fi

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


R. Wakikawa et.al.             Expires 07 Sep 2006             [Page 12]


Internet Draft                   IPv6 MANET                  07 Mar 2006


   Intellectual Property Statement

   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.


   Disclaimer of Validity

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


   Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


   Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


R. Wakikawa et.al.             Expires 07 Sep 2006             [Page 13]


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