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

Versions: 00 01 02

MANET Working Group                                       Ryuji Wakikawa
INTERNET DRAFT                                      Keio University/WIDE
Expires:12 Aug 2005                                       Antti Tuimonen
                                       Helsinki University of Technology
                                                          Thomas Clausen
                                                LIX, Ecole Polytechnique
                                                             12 Feb 2005

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


   Status of This Memo

   This document is a submission to the Mobile Ad-hoc Networks Working
   Group of the Internet Engineering Task Force (IETF). Comments should
   be submitted to the manet@ietf.org mailing list.

   Distribution of this memo is unlimited.

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

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

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

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

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


R. Wakikawa et.al.              Expires 12 Aug 2005             [Page 1]


Internet Draft                   IPv6 MANET                  12 Feb 2005


   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

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

 8. Changes                                                           10

Acknowledgments                                                       10

References                                                            10

Authors' Addresses                                                    12


R. Wakikawa et.al.              Expires 12 Aug 2005             [Page 1]


Internet Draft                   IPv6 MANET                  12 Feb 2005


   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 integration solution.  This means acquiring
   an address with global scope.  In an effort to alleviate problems
   related to address scopes [2], we first study applicability of each
   scope address to mobile ad hoc network 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.  IPv6 specification prohibits
   forwarding packets sent to/from a link local address over a link.

   In addition, a manet does not have a clear link definition in terms
   of multi-hop routing, there are two interpretation of ``link'' in the
   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 12 Aug 2005             [Page 2]


Internet Draft                   IPv6 MANET                  12 Feb 2005


   Considering fact that many IPv6 related protocols including 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-node multicast address (ff02::1) 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
   with careful operations.  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
   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 assign 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 be rejected and
   ignored these routes.  It is easier to exclude routes for unique


R. Wakikawa et.al.              Expires 12 Aug 2005             [Page 3]


Internet Draft                   IPv6 MANET                  12 Feb 2005


   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 the 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 IPv6 routing architecture.
   Detail 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 within each mobile ad-hoc network.  The unique
   local address is generated from locally assigned unique global


R. Wakikawa et.al.              Expires 12 Aug 2005             [Page 4]


Internet Draft                   IPv6 MANET                  12 Feb 2005


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

   Even if two manets are merged, or a manet is partitioned, they
   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 communicates 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 12 Aug 2005             [Page 5]


Internet Draft                   IPv6 MANET                  12 Feb 2005


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

   It is important to inherit original interpretation of link for NDP. A
   manet node is not always connected to manet, but it can be attached
   to 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 the 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 only


R. Wakikawa et.al.              Expires 12 Aug 2005             [Page 6]


Internet Draft                   IPv6 MANET                  12 Feb 2005


   the uniqueness of address within one-hop neighbors.  This is not
   useful because one-hop neighbors are often changed due to movements.
   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
       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 uses 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-node multicast address (ff02::1).  If the flooded
   packet is used to setup a route for the sender node (i.e.  reverse
   route), it should use higher than unique local address as a source
   address.  This is because routes for link local addresses are garbage
   on multihop networks.

   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
   be defined for unique local scope, too.  This is because all manet
   nodes do not always have global address.


R. Wakikawa et.al.              Expires 12 Aug 2005             [Page 7]


Internet Draft                   IPv6 MANET                  12 Feb 2005


   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 that is higher
   than link local address (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 only 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.

   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


R. Wakikawa et.al.              Expires 12 Aug 2005             [Page 8]


Internet Draft                   IPv6 MANET                  12 Feb 2005


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


R. Wakikawa et.al.              Expires 12 Aug 2005             [Page 9]


Internet Draft                   IPv6 MANET                  12 Feb 2005


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


   8. Changes

   This is the initial version of this specification.


   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 (work in progress,
        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 (work in progress).  Internet
        Draft (draft-ietf-ipv6-scoping-arch-02), Internet Engineering
        Task Force, August 2004.

    [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.  Request for
        comments (standards track), Internet Engineering Task Force,
        January 2005.

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

    [6] R. Droms and et al.  Dynamic Host Configuration Protocol for
        IPv6 (DHCPv6).  Request for Comments (Standards Track) 3315,
        Internet Engineering Task Force, July 2003.


R. Wakikawa et.al.             Expires 12 Aug 2005             [Page 10]


Internet Draft                   IPv6 MANET                  12 Feb 2005


    [7] R. Hinden and B. Haberman.  Unique Local IPv6 Unicast Addresses.
        Internet Draft (draft-ietf-ipv6-unique-local-addr-09), Internet
        Engineering Task Force, January 2005.

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

    [9] J. Manner and M. Kojo.  Mobility Related Terminology.  Request
        for Comments (Informational) 3753, Internet Engineering Task
        Force, June 2004.

   [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-03).
        Internet Draft, Internet Engineering Task Force, October 2003.


R. Wakikawa et.al.             Expires 12 Aug 2005             [Page 11]


Internet Draft                   IPv6 MANET                  12 Feb 2005


   Authors' Addresses


     Ryuji Wakikawa
     Keio University
     Graduate School of Media and Governance.
     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


   Copyright

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

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


R. Wakikawa et.al.             Expires 12 Aug 2005             [Page 12]


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