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

Versions: 00 01 02 03 04 05

Mobile Ad Hoc Networking Working Group                    Ryuji Wakikawa
INTERNET DRAFT                                           Keio University
07 Mar 2006                                              Jari T. Malinen
                                                      Charles E. Perkins
                                                   Nokia Research Center
                                                          Anders Nilsson
                                                      University of Lund
                                                       Antti J. Tuominen
                                       Helsinki University of Technology

           Global connectivity for IPv6 Mobile Ad Hoc Networks
                  draft-wakikawa-manet-globalv6-05.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 i]


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   Abstract

   This document describes how to provide Internet connectivity with
   mobile ad-hoc networks.  It describes how to obtain a globally
   routable address and internet gateway operation.  Once a manet node
   obtains a global address from an internet gateway, it may exchange
   data with nodes on the Internet.  This Internet access method is not
   dependent on a particular manet protocol.  Further, use of global
   connectivity with Mobile IPv6 is specified.

                                  Contents


Status of This Memo                                                    i

Copyright Notice                                                       i

Abstract                                                              ii

 1. Introduction                                                       2

 2. Terminology                                                        3

 3. Overview                                                           5

 4. Conceptual Data Structures and Messages                            6
     4.1. Conceptual Data Structures  . . . . . . . . . . . . . . .    6
     4.2. Internet Gateway Information  . . . . . . . . . . . . . .    7
     4.3. Messages  . . . . . . . . . . . . . . . . . . . . . . . .    7
           4.3.1. IGWSOL-N  . . . . . . . . . . . . . . . . . . . .    8
           4.3.2. IGWADV-N  . . . . . . . . . . . . . . . . . . . .    8
           4.3.3. IGWCON-N  . . . . . . . . . . . . . . . . . . . .   10
           4.3.4. DYMO Modifications  . . . . . . . . . . . . . . .   10
           4.3.5. OLSRv2 Modifications  . . . . . . . . . . . . . .   12
     4.4. Changing the ICMPv6 Redirect  . . . . . . . . . . . . . .   12

 5. Manet Node Operation                                              14
     5.1. Receiving Internet Gateway Advertisement  . . . . . . . .   14
     5.2. Address Autoconfiguration . . . . . . . . . . . . . . . .   14
     5.3. Default Route Setup . . . . . . . . . . . . . . . . . . .   15
     5.4. Source Address Selection  . . . . . . . . . . . . . . . .   16
     5.5. Receiving ICMPv6 Error Messages . . . . . . . . . . . . .   16
     5.6. Interaction with Mobility Protocols . . . . . . . . . . .   16

 6. Reactive Manet Node Operation                                     18
     6.1. Soliciting Internet Gateway Advertisement (Optional)  . .   18
     6.2. Route Selection for Reactive Protocols  . . . . . . . . .   18
     6.3. Use of Routing Header . . . . . . . . . . . . . . . . . .   20


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


 7. Internet Gateway Operation                                        22
     7.1. Joining a Mobile Ad-hoc Routing Domain  . . . . . . . . .   22
     7.2. Sending Internet Gateway Advertisement  . . . . . . . . .   22
     7.3. Receiving Internet Gateway Solicitation . . . . . . . . .   23
     7.4. Management of Manet Nodes on Internet Gateway . . . . . .   23
     7.5. Route Examination . . . . . . . . . . . . . . . . . . . .   24

 8. Protocol Constants                                                26

 9. Security Considerations                                           26

Acknowledgments                                                       26

References                                                            26

Appendices                                                            28

Authors' Addresses                                                    28


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   1. Introduction

   A mobile ad-hoc network (manet) is built dynamically when a set
   of manet routers creates routing state for their connectivity
   management, typically over a wireless network.  Manet routing
   protocols aim to maintain a route to a destination despite movement
   of intermediate nodes that causes the route path to change.  There
   are routing protocols standardized at IETF such as DYMO [1],
   OLSRv2 [2], AODV [11], OLSR [3], DSR [7], and TBRPF [10].

   Global connectivity is often required for manet routers desiring
   communication with the fixed Internet.  However, routing protocols
   for manets only maintain routes locally within the reach of a manet
   running the given protocol.  This document specifies the method by
   which a node in the manet acquires a global address from a gateway,
   as well as how this node will communicate over the gateway.

   The following assumptions are made for simplicity and definiteness:

    -  Address Family
       This document assumes IPv6 address family support.  The manet
       routing protocol discussed in this document MUST be capable of
       routing for IPv6 addresses.

    -  Topological assumption
       There is at least one internet gateway somewhere in the manet.

    -  Address assumption
       All nodes in the manet must have or acquire a routable address,
       perhaps usable as a Mobile IPv6 [8] home address.  The routable
       address is used for initial configuration when a node boots up
       and joins the manet


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   2. Terminology

      manet node
               A node located inside a manet

      internet node
               A node located within the Internet (outside manet)

      internet gateway
               A router which provides Internet connectivity for nodes
               in the manet.  This router is located somewhere in a
               manet and has a connection to both the Internet and the
               manet.

      manet local address
               A manet node's identity address in manet.  The address is
               used for ad-hoc routing.

      global address
               A node's IPv6 address in the Internet, typically
               resolvable from a DNS name.  The address identifies
               the mobile node, and is used for communication to the
               Internet

      internet route
               A route to the Internet (i.e.  internet gateway).  It can
               be treated as a default route or a network route.

      manet route
               A route to other manet nodes.  It is typically host route
               in a manet.

      internet gateway information
               The gateway's IP routing prefix, prefix length, and
               lifetime.

      internet gateway advertisement
               A message to disseminate internet gateway information to
               a manet.

          IGWADV-M
                   Extends the manet protocol; a control message is
                   specified for each particular protocol to advertise
                   internet gateway information

          IGWADV-N
                   Extends NDP to indicate that the advertisement
                   contains information about the internet gateway


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


      internet gateway solicitation
               A message to solicit an internet gateway advertisement.

          IGWSOL-M
                   Extends the manet protocol; a control message is
                   specified for each particular protocol to solicit
                   internet gateway information

          IGWSOL-N
                   Extends NDP to solicit an internet gateway
                   Advertisement.

      internet gateway confirmation
               A message to confirm an IPv6 global address of a manet
               node.  This can be an IGWCON or a signaling of each manet
               routing protocol (ex.  RREP).

          IGWCON-M
                   Extends the manet protocol; a control message is
                   specified for each particular protocol for the
                   internet gateway confirmation.

          IGWCON-N
                   Extends NDP for the internet gateway confirmation.

      internet gateways multicast address (IGW_MCAST)
               Specifically, ALL_MANET_GW_MULTICAST, the IPv6 global
               multicast address for all internet gateways in a manet.


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   3. Overview

   The global connectivity for manet is defined for any global address
   configured to any manet network interface of a manet node, and it
   defines a method for configuring a globally routable address for
   such an interface.  Once such global address is available, global
   mobile-initiated sessions, such as web browsing or DNS queries, can
   be used.  A topologically correct address in the IP header's source
   field is sufficient for packets sent from the manet node in such
   sessions.

   A manet node discovers an internet gateway by receiving an internet
   gateway advertisement.  Each internet gateway MAY disseminate
   internet gateway advertisement proactively.  Periodic advertisements,
   however, are not typically used with reactive manet protocols such
   as DYMO [1], AODV [11] and DSR[7].  Thus, a manet node can solicit
   internet gateway advertisement when it needs a route to the Internet,
   and will receive internet gateway advertisements back in response.
   This solicitation is optional when an internet gateway periodically
   floods a internet gateway advertisement.  In this way, the reactive
   and proactive route discovery features of each manet routing protocol
   are not disturbed.

   For these internet gateway solicitation and advertisement, we
   introduce modifications to the Neighbor Discovery Protocol (NDP) [9]
   and each manet routing protocol.  Operators can use the preferred
   one to implement global connectivity.  The proposed method targets
   all manet protocols regardless of whether they are reactive or
   proactive.  An advertisement from the internet gateway provides
   prefix information, and advertisement processing possibly resolves a
   route to the gateway, inserted as a route toward the Internet (i.e.
   Internet Route).  A prefix which is distributed by internet gateways
   can be used for configuring a (typically globally) routable IPv6 [5]
   address for each manet node.

   After accepting an advertisement from the internet gateway, the
   manet node configures a global address from the prefix of the
   internet gateway and inserts the internet gateway address as an
   internet route.  Each internet gateway monitors packets received
   from the manet, to avoid unnecessarily forwarding the packet to the
   Internet when the destination is already present within the manet.
   The destination of a packet passing through the internet gateway
   is checked on the internet gateway.  If the manet is operating
   reactively, the internet gateway in this case may also supply an
   updated route to the sending node.  The sending node then receives
   a notification and sends a route request to discover the direct
   route to the destination.  To do so, each intenet-gateway MAY manage
   a roster of IP addresses of all the associated manet nodes.  The
   management is explained in Section 7.4.


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   4. Conceptual Data Structures and Messages

   4.1. Conceptual Data Structures

   This specification assumes that all manet nodes support the following
   data structures.  These structures are similar to the data structures
   defined in Neighbor Discovery Protocol (NDP)[9].  These structures
   can be implemented in several ways.  An example is extending the
   structures implemented for NDP.

    -  Internet Gateway List (IGW List)
       A list of available internet gateways to which packets may be
       sent.  In this list, the internet gateway information described
       later must be stored.  Each entry also has an associated
       invalidation timer value (extracted from internet gateway
       Advertisements) used to delete entries that are no longer
       advertised.  The entries are listed below:

        1. internet gateway global address

        2. internet gateway lifetime

        3. internet gateway manet-local address (optional)

    -  Internet Gateway Prefix List (Prefix List)
       A list of prefixes that are advertised by internet gateways.
       This Internet Gateway Prefix List entries are created from
       information received as internet gateway advertisements.  Each
       entry has an associated invalidation timer value (extracted from
       the internet gateway advertisement) used to expire prefixes when
       they become invalid.  The entries are listed below:

        1. internet gateway prefix address

        2. internet gateway prefix address length

        3. internet gateway prefix preferred lifetime

        4. the number of advertised internet gateways

    -  Associated MANET nodes list
       Each internet gateway manages an associated manet node list for
       all the manet nodes to which it supplies a global connectivity.
       The following information must be managed on each internet
       gateway.

        1. A global address of a manet node


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   4.2. Internet Gateway Information

   A manet node needs a globally routable address in order to be
   globally reachable, so that it can receive packets from the Internet.
   The manet node needs to learn its topological location and an address
   of the internet gateway that provided the node with this access to
   the Internet.  The node therefore needs to obtain a global prefix
   owned and distributed by internet gateways.  The information which a
   manet node needs to know for internet connectivity is listed below.
   An internet gateway advertises these items as its internet gateway
   information.  This internet gateway information is introduced to keep
   compatibility with NDP [9].

    -  internet gateway global address
       The internet gateway's global address, which can be used as a
       route to the Internet on manet nodes.

    -  Internet Gateway Prefix address
       The network prefix address which internet gateway is serving.
       The prefix MUST be valid address and topologically correct
       address on the Internet.

    -  Internet Gateway Prefix length
       Prefix length of the network prefix address of an internet
       gateway.

    -  Internet Gateway Prefix Preferred Lifetime
       The addresses generated from the prefix via stateless address
       autoconfiguration remain preferred [13].  A value of all one bits
       (0xffffffff) represents infinity.  See [13].  After expiration of
       the lifetime, the manet node MUST delete its autoconfigured IPv6
       global address.

    -  Internet Gateway Lifetime
       The lifetime of an internet gateway.  After expiration of
       the lifetime, a manet node MUST NOT use the internet gateway
       as an internet route.  It SHOULD get fresh internet gateway
       information.

    -  internet gateway's manet address (option)
       A manet address which can be used for internal communication with
       an internet gateway.


   4.3. Messages

   This specification defines three messages such as internet gateway
   solicitation, internet gateway advertisement and internet gateway


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   confirmation.  Those messages are implemented in two ways:  extension
   of NDP and extension of manet routing protocol's messages.

   As we explained in  [14], NDP messages such as a router solicitation,
   a router advertisement and a neighbor advertisement are not
   originally designed to route over multi-hop, because NDP [9] is
   operated between on-link nodes and routers.  NDP assumes to use
   link-local scoped addresses as the IPv6 destination and source
   address fields for router advertisement and router solicitation
   messages.  Link-local address is not an appropriate address scope for
   multi-hop networks since IPv6 prohibits to forward packets sent to an
   address of link-local scope.  For doing so, new NDP packets must be
   defined.

   In this section, we introduce three new NDP messages named IGWSOL-N,
   IGWADV-N, IGWCON-N and examples of routing signaling modifications
   (IGWSOL-M, IGWADV-M, IGWCON-M).


   4.3.1. IGWSOL-N

   The IGWSOL-N is same as the Route Solicitation message of NDP except
   for the Type value.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Reserved                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-

      TYPE
               TBA.


   4.3.2. IGWADV-N

   The IGWADV-N is similar to the Route Advertisement message of
   NDP. However, the internet gateways MUST NOT forward this message
   to internet nodes.  The sender MUST include a Prefix Information
   option [9] with a globally routable prefix.  The prefix information
   option is not modified for manet global connectivity.  However, L
   flag must be unset and the Valid Lifetime field MUST be set to zero
   for the IGWADV-N, since on-link determination can not be used for
   manet.  A Source Manet Address option may be required in order to


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   store a manet local address of the internet gateway, depending on the
   manet protocol.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Hop Limit     |A|O|  Reserved |       Router Lifetime         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-

      TYPE
              TBA.

      Code
              zero

      Checksum
              The ICMP checksum.

      Hop Limit
              The hop count between an Internet Gateway and a manet
              node.

      A
              1-bit ``Acknowledgment'' flag.  It requests Internet
              Gateway Confirmation to a manet node

      O
              1-bit ``Other stateful configuration'' flag.  When
              set, hosts use the administered (stateful) protocol for
              autoconfiguration of other (non-address) information.

      Router Lifetime
              16-bit unsigned integer.  The lifetime associated with the
              default router in units of seconds.  The maximum value
              corresponds to 18.2 hours.  A Lifetime of 0 indicates that
              the router is not a default router and SHOULD NOT appear
              on the internet gateway list.  The Router Lifetime applies
              only to the router's usefulness as a default router; it
              does not apply to information contained in other message
              fields or options.


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   4.3.3. IGWCON-N

   The IGWCON-N is sent only when an internet gateway requests
   acknowledgment (ex.  Set A flag in IGWADV-N). This message is used to
   manage an associated manet node list on the internet gateway.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       Target Address                          +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-

      TYPE
              TBA

      Code
              zero

      Checksum
              The ICMP checksum.

      Reserved
              zero

      Target Address
              The global address of the manet node.  This target address
              will be stored in a associated manet node list of an
              internet gateway.


   4.3.4. DYMO Modifications

   DYMO has already specified a gateway concept in the
   specification [1].  The internet gateway lifetime can be
   retrieved from the route entry's lifetime for the internet gateway.
   We defined a new global connectivity block as shown in below.  This
   global connectivity block is carried by RREP. We also introduces


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   a new C flag in the ``Reserved'' field of Routing Element (RE) to
   indicate an internet gateway confirmation message.  RREP can be
   recognized as the Internet Gateway Advertisement message, and RREQ is
   as the Internet Gateway Solicitation message.  The Internet Gateway
   Confirmation message can be RREP with C flag set.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |          Len          |    TTL    |I|A|S|C|Res|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                         TargetAddress                         .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          TargetSeqNum                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  THopCnt  |Res|                                               .
   +-+-+-+-+-+-+-+-+                                               .
   .                                                               .
   .                    Routing Block 1 (RBlock1)                  .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      C
              The C flag indicates requesting Internet Gateway
              Confirmation message.  A manet node must include its new
              global address in a routing block and unicasts it to the
              particular internet gateway.

   We also define a new DYMO Internet Gateway Prefix Block (IGWBlock) as
   follows.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |G|I|Prefix Length|R| Hop Count |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                  IGW Prefix (i.e. IGW global address)         .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                  IGW Seqno                                    .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              IGW Prefix Preferred Lifetime                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      I
              The I flag indicates Internet Gateway Prefix Block (IGW
              block) for RE.


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


      Prefix Length
              The length of IGW global Prefix

      R
              1 bit Reserved field

      Hop Count
              Same as the Hop Count of Routing Block (RBlock)

      IGW Prefix
              The global address of the internet gateway

      IGW Seqno
              The sequence number of the internet gateway

      IGW Prefix Preferred Lifetime
              The preferred lifetime of the IGW Prefix.


   4.3.5. OLSRv2 Modifications

   For OLSRv2, we define a new message TLV for global connectivity
   as illustrated in below.  The internet gateway lifetime is also
   retrieved from the route entry's lifetime for the internet gateway.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length     |L|  Reserved     |  IGWPrefix    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                     IGW Address                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                  IGW Prefix (IGW global address)              .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               IGW  Prefix Preferred Lifetime                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   4.4. Changing the ICMPv6 Redirect

   For global connectivity, an ICMPv6 Redirect message [9] is used by
   the internet gateway to notify a sending node that a destination is
   located on this manet and instead should send packets to it using
   ordinary manet routing.  According to [9], a gateway MUST send an
   ICMPv6 Redirect messages from only link-local address.  However,
   in manet situation, an internet gateway needs to send it from non
   link-local address due to multihop routing.  Thus, we relax this
   limitation in this specification.  An internet gateway can send
   the redirect message from either a manet local address or a global


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   address.  In the target address field, the internet gateway SHOULD
   insert the wildcard IPv6 address (i.e.  ::).


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   5. Manet Node Operation

   For internet connectivity, each manet node needs to generate a global
   address and configure a route to the Internet.


   5.1. Receiving Internet Gateway Advertisement

   Two different messages are possible for internet gateway
   advertisement:  IGWADV-N and IGWADV-M. When a manet node receives
   an internet gateway advertisement, it first verifies the message
   according to either the NDP specification [9] or each routing
   protocol specification.  In addition to the verification, the manet
   node MUST conduct additional check as follows:

    -  The source address MUST be non link-local address.  If the
       message is sent from a link-local address, the message MUST be
       silently discarded.

    -  The message MUST have a correct prefix information option.
       Otherwise, the message MUST silently be discarded.  Each node
       MUST verify following items for the prefix information option.

        *  The prefix address must be global routable prefix address

        *  The prefix length must be valid length.  (i.e.  shorter than
           128 and greater than 0).

        *  Prefix Preferred Lifetime must be greater than zero.

       For the NDP based Intenet Gateway advertisement message
       (IGWADV-N), the following checks is required.

        *  The Valid Lifetime MUST be set to zero

        *  L flag MUST be unset and A flag MUST be set

   After successful verifications, the manet node keeps the internet
   gateway information into the Internet Gateway List and Internet
   Gateway Prefix List as described in Section 4.1.


   5.2. Address Autoconfiguration

   After an internet gateway advertisement has been received from
   the internet gateway(s), a manet node SHOULD generate a global
   address by using the internet gateway information.  The node SHOULD
   use its EUI-64 in order to construct a valid address with the


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   acquired prefix.  The address generation is same as NDP Address
   Autoconfiguration [13] except for DAD. DAD operation is out of scope.


   5.3. Default Route Setup

   The manet node SHOULD set a route toward the Internet in the routing
   table.  An ``example'' of a routing table is as follows:

        Destination/prefix length    Next-Hop
        --------------------------   -----------------------------
    Internet Route *
        default (::) **                <internet gateway address-A>
        default (::)                   <internet gateway address-B>
           :                                   :

    Host Route/128 ***
       <internet gateway address>    <next-hop address>

   How to implement to hold a default route is up to manet routing
   protocols, implementations and operating systems.  Some operating
   system (ex.  Linux) are capable to keep multiple default routes and
   some (ex.  BSD) are not supporting multiple routes for the same
   destination.  It is possible to extend the BSD to hold multiple
   entries for a same destination.

   Even if a node does not hold multiple internet gateways in a routing
   table, it can still keep these information in the internet gateway
   list.  Thus it can refer the internet gateway list whenever it loses
   reachability to the default route which is set in a routing table.

   These routing entries MUST be held until expiration of the prefix
   lifetime.  The router lifetime of the default route entry and the
   global prefix information is the same with the prefix lifetime.
   During active lifetime, the receiving node can use the global prefix
   and the internet gateway as the default route entry.  The default
   route does not function as the general default route for reactive
   route protocols, because the default route MUST be used with the
   mechanism described in Section 7.5 in addition to the general route
   lookup mechanism.

   During active use of the internet gateway as a route path for
   communications, the manet node SHOULD update internet gateway
   information by receiving internet gateway advertisements.  If
   necessary, the manet node can unicast an internet gateway
   solicitation to the respective internet gateway, or alternatively it
   can broadcast an internet gateway solicitation to all over the manet
   again.  The former method can allow the manet node to update the
   current internet gateway status, while the latter method enables the


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   manet node to quickly discover all possible internet gateways in the
   manet.


   5.4. Source Address Selection

   Each manet node carefully selects a source address for outgoing
   communication.  For communication, the manet node MUST NOT use its
   link-local address.  The following decision MUST be made before
   sending packets.

    -  If a destination is an internet node, it MUST use its global
       address.  The global address can be home address.

    -  If a destination is a manet node located within the manet, it
       SHOULD use it manet-local address.  However the manet node MAY
       use its global address.


   5.5. Receiving ICMPv6 Error Messages

   If a manet node receives an ICMPv6 Destination Unreachable message
   after sending data packets along a manet route, the node MUST delete
   the manet route from the routing table.  On the other hand, if the
   manet node uses an internet route, it SHOULD NOT delete the internet
   route.  But it SHOULD stop sending packets to the destination.  The
   node, then, MAY re-discover the destination by routing requests if
   necessary.  Unless the node finds the destination node, it must give
   up communicating with the destination for a while.

   If the manet node receives an ICMPv6 Redirect message from an
   internet gateway, the manet node SHOULD use the host route instead
   of the default route.  Getting the host route, the manet node uses
   its method of learning a manet destination, e.g., by sending a route
   requests for the destination.


   5.6. Interaction with Mobility Protocols

   If a global address is more permanent one on a manet node, it can
   be used as a Mobile IPv6 [8] home address, to provide an always-on
   reachability from the fixed Internet with a statically known address.
   In such a case, reachability can be provided even when the node moves
   between manets and different points of the fixed network.  A mobile
   node should use Mobile IPv6 when it is not on its home link.  When
   arriving at a visited link in the fixed network, it will receive
   router advertisements to detect movement.  If it is not at home, it
   registers with its home agent using a globally routable address from
   the visited network.  In manet, Mobile IPv6 uses the internet gateway


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   advertisement to detect node's movement and to generate a globally
   routable address (i.e.  Care-of address).  The same mechanism can be
   applied to the NEMO Basic Support protocol [6].

   The mobile node uses the globally routable address acquired from the
   internet gateway as its care-of-address when possibly performing a
   home registration.  If no home registration is needed, the mobile
   node is at home in the manet and the prefix of its home address
   belongs to its internet gateway.  If the mobile node starts Return
   Routability procedure for route optimization, HoTI and CoTI are sent
   through its internet gateway and HoT and CoT are returned to the
   mobile node via the internet gateway.  There is no special operation
   for Return Routability on manet.

   All manet nodes SHOULD support Mobile IPv6 Correspondent Node
   (CN) requirements describe in [8], so that they understand the
   home address option.  Manet nodes using Mobile IPv6 with global
   connectivity support whatever Mobile IPv6 functionality they wish
   to use.  Manet mobile nodes SHOULD NOT use home address options and
   CN binding updates when exchanging routing information with other
   nodes in the manet.  This keeps control packets smaller and does
   not require manet nodes to support full CN functionality.  A manet
   mobile node MAY insert a routing header to an outgoing data packet
   for explicit gateway routing in addition to the possible home address
   option.  If the node is a CN, the possible routing header injected by
   Mobile IPv6 is modified by inserting the entry for gateway prior to
   the entry for home address, and setting the segments left to two.


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   6. Reactive Manet Node Operation

   This section introduces additional operations for manet nodes running
   reactive manet routing protocols.


   6.1. Soliciting Internet Gateway Advertisement (Optional)

   A manet node sends an internet gateway solicitation in order
   to prompt an internet gateway(s) to generate internet gateway
   advertisements.

   The following steps are required for sending the internet gateway
   solicitation.

    -  The source address of the message MUST NOT be a link local
       address.  The IPv6 address used during any of these operations
       could be any routable address, for example a Mobile IPv6 home
       address.  If no such address is available, the node SHOULD
       allocate a temporary global-scope address, generated from
       the well-known MANET_INITIAL_PREFIX [12].  This temporary
       address (MANET_TEMPORARY_ADDRESS) should be deallocated after
       obtaining the globally routable IPv6 address from an internet
       gateway.

    -  The manet node unicasts the router solicitation to an internet
       gateway if it has already known the address of the internet
       gateway.  Otherwise, it floods the message to a new all internet
       gateway multicast address (i.e.  ALL_MANET_GW_MULTICAST).

    -  The Hop Limit field in the IPv6 header SHOULD be set to an
       appropriate value.  This can be the default constant usually
       inserted when unicasting packets, or chosen e.g., according to
       broadcasting/flooding scheme such as an expanding ring search
       technique.


   6.2. Route Selection for Reactive Protocols

   In reactive manets, a manet node and an internet gateways do not know
   the complete topology of the manet which they belong to.  They MUST
   discover a host route for a destination as soon as they start to
   communicate.  Therefore, whenever a node needs to send a packet it
   uses the following routing algorithm:

    -  The node looks up its routing table for the destination node.
       If it found the discovered route, it sends the packet towards
       the destination.  The internet route SHOULD NOT be selected as a
       route for the destination at this point.


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


    -  If not, the node MAY request a route for the destination node.

        1. If an internet route exists, the node MAY wait for the above
           route request.

        2. If an internet route does not exist, the manet node obtains a
           default route.

        3. If the manet node does not get any route, the node sets an
           route entry into the routing table with the destination node
           pointing towards the internet route.  Then the manet node
           uses the route to transmit the packet through the internet
           route.

    -  If the manet node gets a route for the destination, it sets a
       host route for the destination, and sends packets according to
       this route (not the internet route).

   The node SHOULD know whether a route request was earlier sent for a
   destination whose route lookup found the default route.  To prevent
   repeated route requests for packets destined to the destination, the
   node MUST put a route entry for the destination with the internet
   route as a next hop of the destination node .  An ``example''
   routing table of the node SHOULD be configured for the destination as
   shown below.  As explained in Section 5.2, how to implement to hold
   these routes is up to manet routing protocols, implementations and
   operating systems.

        Destination/prefix length    Next-Hop
        --------------------------   -----------------------------
    Internet Route
        :: (default)                 <internet gateway address>
    Host Route/128
       <internet gateway address>    <next-hop address>
       <Destination address>         <internet gateway address>

   If the protocol allows, the node SHOULD send at least one request
   for a route of such a destination before sending data packets, even
   if it has already had a default route in its routing table.  If the
   routing protocol is using an expanding ring search, care should be
   taken so as not to let this affect the delay too much.  If the ring
   is expanded too far, unnecessary delay is introduced.  Simulations
   have shown that one route request is optimal in most cases.

   If the node gets a route for such a destination, the node assumes the
   destination node is located within manet, sets a host route for the
   destination, and sends packets normally according to this host route.


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   6.3. Use of Routing Header

   A manet node sends data along an internet route when a destination
   is an internet node.  The node has different way to transmit packets
   through an internet gateway.

    -  Without IPv6 routing extension header
       The manet node sends the packet to an IP address of an internet
       node and relies upon next hop routing in the other nodes.

    -  With IPv6 routing extension header
       The manet node uses the internet gateway address in the
       destination address of the IPv6 header and the real destination
       address in the routing header.

   When a reactive manet routing protocol is used, each node may know
   only partial topology or link.  In such case, if a packet meant for
   an internet node is sent without a routing header, each intermediate
   node will try to discover a manet route due to absence of the routing
   entry for the destination address.  For example, table driven routing
   protocol such as AODV may have this problem.  Intermediate nodes of
   a manet route only knows information of manet nodes on its routing
   table.  Intermediate nodes do not know that whether the destination
   address is located on the Internet until route discovery for the
   destination address is completed.  In addition, we can not assume
   that all manet nodes inside a manet acquire an internet route.  If
   an intermediate node who does not have an internet route receives a
   packet meant for an internet node, it will not be able to route the
   packets.  Therefore, if the packet is sent with a routing header, the
   destination address of the packet is the internet gateway while it is
   routed within the manet.  Therefore, the intermediate node can route
   the packet to the internet gateway without generating additional
   route discovery and even without an internet route.

   Assume the destination is located inside the manet but the sender
   can not reach the destination via a host route.  Such the case can
   be occurred when reactive manet routing protocol is used.  If the
   manet node sends packets to the destination via the internet gateway
   without a routing header, an intermediate node who has a host route
   for the destination will route packets to it directly, but the sender
   node is not aware of this.  The sender is never notified that packets
   is not passing through the internet gateway.  If the sender always
   uses a routing header, every packet is explicitly routed through
   the internet gateway.  If the internet gateway detects that the
   destination is located within the manet, the internet gateway can
   send an ICMPv6 Redirect error message to the sender.  After receiving
   the ICMPv6 Redirect messages, the manet node can re-discover a manet
   route for the destination.


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   Using a routing header is preferable when there are more than two
   internet gateways, because the node then have the ability to decide
   which internet gateway is the best, by distance in hops, or by some
   other priority.  By assign a priority number for each internet
   gateway, the route reply message and the manet router advertisement
   messages could be extended to support a candidate internet gateway
   option in it.


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   7. Internet Gateway Operation

   This section describes required operation for internet gateways.


   7.1. Joining a Mobile Ad-hoc Routing Domain

   An internet gateway joins a mobile ad-hoc network with a manet
   interface while it maintains the Internet connectivity with other
   interfaces.

   The internet gateway requires to listen routing messages in order to
   collect routing information.  However, it should not involve local
   manet routing with its manet interface so that route examination
   becomes much easier as described in Section 7.5.

   The internet gateway SHOULD NOT become an intermediate node of a
   manet route.  To achieve this, the internet gateway SHOULD NOT
   forward the flooded packets to its neighbors of the manet interface.
   For example, in AODV, the internet gateway SHOULD NOT propagate a
   RREQ message even if it receives the RREQ from neighbors.  In OLSR,
   the internet gateway SHOULD NOT generate TC message.  It can be done
   with the Willingness configuration set to NEVER.


   7.2. Sending Internet Gateway Advertisement

   An internet gateway sends out an internet gateway advertisement
   either periodically or response to an internet gateway solicitation.
   The internet gateway allows to send unsolicited internet gateway
   advertisements, although sending them periodically would generate
   unnecessary packets in the Manet.

   When an IGWADV-N is used, it MUST carry a Prefix Information
   Option [9, 8].  The internet gateway contains its global prefix in
   the prefix information option.  The source address of the IGWADV-N
   must be a global address of the internet gateway and MUST NOT use its
   link-local address.

   Although the NDP specification requires to set 255 to a hop limit
   field, the Hop Limit field in the IPv6 header SHOULD be set to an
   appropriate value in a MANET. The internet gateway can either flood
   or unicast the internet gateway advertisement.  An internet gateway
   SHOULD use optimized flooding mechanism such as the expanding ring
   search and multipoint relay flooding.

   When the internet gateway uses IGWADV-M, it must follow the
   specifications of each manet protocols.


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   7.3. Receiving Internet Gateway Solicitation

   When an internet gateway receives an internet gateway solicitation,
   it MUST unicast an internet gateway advertisement back to the
   originator of the solicitation.

   When it receives an IGWSOL-N, the internet gateway must operate
   following verifications in addition to the verification specified
   in [9].

    -  If the source address is link local address, it SHOULD drop the
       IGWSOL-N.

    -  If the hop limit field of the IGWSOL-N is equal to zero, the
       message MUST silently be discarded.

   After successful verification, the internet gateway keeps the
   originator's global address in its global manet node lists with
   INITIAL_GLOBAL_LIFE_TIME. It also unicasts back a IGWADV-N as
   described in Section 7.2.

   When a IGWSOL-M is received, the internet gateway must verify the
   packet and returns IGWADV-M if necessary.


   7.4. Management of Manet Nodes on Internet Gateway

   An internet gateway SHOULD manage an associated manet node list
   for all the manet nodes which acquire a global address from the
   internet gateway.  This knowledge is used when internet gateway
   determines a route for incoming packets described in section 7.5.
   It is recommended that the internet gateway supports this feature
   specially when reactive manet protocol is used.

   When using proactive manet protocols, an internet gateway can see
   entire topology of all the manet nodes.  Therefore, the internet
   gateway can know whether a node locates inside manet or not, as soon
   as it checks its topology map.  On the other hand, most of reactive
   manet protocols only maintain partial topology of manet nodes.  Each
   manet node MUST contact to the internet gateway at least once it
   establishes an internet route with the internet gateway.  During this
   operation, the internet gateway records the manet node's addresses
   into a routing table and SHOULD mark as a manet node who has global
   address.  This approach can be applied to most of reactive manet
   protocol, but any mechanism can be selected to know all manet nodes
   information.

   To acquire a global address of each manet node, an internet gateway
   confirmation message can be used.  After address autoconfiguration


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   on each manet node, the manet node notifies its global address by
   sending the internet gateway confirmation message.  The internet
   gateway ask a manet node to send a internet gateway confirmation
   message by setting a flag in an internet gateway advertisement
   message.  The internet gateway confirmation message will be unicasted
   to an internet gateway which a manet node receives the internet
   gateway information.

   When there are multiple internet gateways, the associated manet node
   list SHOULD be exchanged among internet gateways.  This exchange
   can be done in several way (ex.  running routing protocol between
   internet gateways, if internet gateways are connected each other by
   wired link)


   7.5. Route Examination

   When an internet gateway forwards a packet from a manet to the
   Internet , it must examine the packet's source address.  This
   examination prevents leaking unnecessary packets to the Internet.

   This examination is based on the following steps.

    1. The internet gateway first checks the destination address with
       its global prefix.  If the prefix of the destination address is
       matched with the global prefix, the internet gateway MUST NOT
       forward the packet to the Internet.  It returns the packet back
       to the manet if it has a manet route for the destination.  If the
       internet gateway does not have a manet route, it just discards
       the packet and returns an ICMP Unreachable message to the sender.

    2. If the prefix of the destination address is not matched with the
       global prefix, the internet gateway carefully examines the route
       for the destination.

        -  If the internet gateway can not be an intermediate node of
           manet routes as shown in Section 7.4, goes to Step-3 below.

        -  If the internet gateway can be an intermediate node and knows
           full topology of the manet , it searches its routing table
           for a manet route of the destination.  If the route is found,
           it routes the packet back to the manet.  The internet gateway
           SHOULD generate an ICMP6 Redirect Message to the source node.

        -  On the other hand, if the internet gateway can be an
           intermediate node and does not have full topology, it
           compares the destination address with manet nodes' global
           addresses maintained in the associated manet node list.  If
           there is a manet route, it SHOULD route the packet along the


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


           manet route.  The internet gateway SHOULD generate an ICMP6
           Redirect Message to the source node.

    3. The internet gateway compares the source address with its global
       prefix.  If the prefix part is not matched, this packet is sent
       from non-routable address in this manet.  Thus, the packet MUST
       NOT be routed to the Internet.  If there is no manet route for
       the destination, the packet MUST be silently discarded.  The
       internet gateway SHOULD return an ICMP6 Parameter Problem message
       to the source node.

    4. Otherwise, it can forward the packet to the Internet.

   Note that ICMP error messages are subject to rate limiting in the
   same manner as is done for ICMPv6 messages [4].


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   8. Protocol Constants
      Parameter Name           Value
      ----------------------   -----
      ALL_MANET_GW_MULTICAST   TBD (ff1e::xx/64 global-scope)


   9. Security Considerations

   This document does not define any method for secure operation
   of the protocol.  There is no widely accepted model for securing
   state-altering protocols in manet.  A reason for this is the lack of
   scalability in security association setup among manet nodes arriving
   from arbitrary domains.  Before well accepted SA setup methods exist,
   any node can pretend to be an internet gateway and result in other
   nodes setting their routing state in a way denying proper operation
   of this service.


   Acknowledgments

   The authors would like to thank Elizabeth Royer for her comments
   on streamlining some aspects of the design.  The authors thank
   Thierry Ernst and Fred Templin for his comments.  The authors thank
   Thomas Clausen for his many improvements having to do with proactive
   routing protocols.  The authors also thank Alex Hamidian for his
   contributions and improvements to section 7.2.


   References

    [1] I. Chakeres, E. Belding-Royer, and C. Perkins.  Dynamic MANET
        On-demand (DYMO) Routing (work in progress).  Internet Draft,
        Internet Engineering Task Force, October 2005.

    [2] T. Clausen.  The optimized link-state routing protocol version 2
        (work in progress).  Internet Draft, Internet Engineering Task
        Force, August 2005.

    [3] T. Clausen and P. Jacquet.  Optimized Link State Routing
        Protocol OLSR.  Request for Comments (Experimental) 3561,
        Internet Engineering Task Force, October 2003.

    [4] A. Conta and S. Deering.  Internet Control Message Protocol
        (ICMPv6) for the Internet protocol version 6 (ipv6)
        specification.  Request for Comments (Draft Standard) 2463,
        Internet Engineering Task Force, December 1998.


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


    [5] S. Deering and R. Hinden.  Internet Protocol, Version 6 (ipv6)
        Specification.  Request for Comments (Proposed Standard) 1883,
        Internet Engineering Task Force, December 1995.

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

    [7] D. Johnson, D. Maltz, and Y. C. Hu.  The Dynamic Source Routing
        Protocol for Mobile Ad Hoc Networks (DSR) (work in progress,
        draft-ietf-manet-dsr-09.txt).  Internet Draft, Internet
        Engineering Task Force, April 2003.

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

   [10] R. Ogier, , F. Templin, and M. Lewis.  Topology Dissemination
        Based on Reverse-Path Forwarding (TBRPF).  Request for Comments
        (Experimental) 3684, Internet Engineering Task Force, February
        2004.

   [11] C. Perkins, E. Belding-Royer, and S. Das.  Ad hoc On-Demand
        Distance Vector (AODV) Routing.  Request for Comments
        (Experimental) 3561, Internet Engineering Task Force, July 2003.

   [12] C. Perkins, J. Malinen, R. Wakikawa, E. Royer, and Y. Sun.
        IP address Autoconfiguration for Ad hoc Networks (expired,
        draft-ietf-manet-autoconf-01.txt).  Internet Draft, Internet
        Engineering Task Force, November 2001.

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

   [14] R. Wakikawa, A. Tuimonen, and T. Clausen.  Ipv6
        support on mobile ad-hoc network (work in progress,
        draft-wakikawa-manet-ipv6-00.txt).  Internet Draft, Internet
        Engineering Task Force, February 2005.


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


Internet Draft      Global Connectivity for IPv6 Manets      07 Mar 2006


   Authors' Addresses


     Ryuji Wakikawa                   Charles Perkins
     Dept.  of                        Communications Systems Lab
     Environmental Information        Nokia Research Center
     Keio University                  313 Fairchild Drive
     5322 Endo Fujisawa Kanagawa      Mountain View, California
     252 JAPAN                        94043 USA
     EMail:  ryuji@sfc.wide.ad.jp     EMail:  charliep@iprg.nokia.com
     Phone:  +81-466 49-1394          Phone:  +1-650 625-2986
     Fax:  +81 466 49-1395            Fax:  +1 650 625-2502

     Jari T. Malinen                  Anders Nilsson
     Communications Systems Lab       Dept.  of Communication Systems
     Nokia Research Center            Lund Institute of Technology
     313 Fairchild Drive              Box 118
     Mountain View, California        SE-221 00 Lund
     94043 USA                        Sweden
     EMail:  Jari.T.Malinen@nokia.com E: andersn@telecom.lth.se
     Phone:  +1-650 625-2355          Phone:  +46 46-39 72 92
     Fax:  +1 650 625-2502            Fax:  +46 46-14 58 23

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


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


Internet Draft      Global Connectivity for IPv6 Manets      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 29]


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