Mobile Ad Hoc Networking Working Group                    Ryuji Wakikawa
INTERNET DRAFT                                           Keio University
01 July 2002                                             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-01.txt


Status of This Memo

   This document is a submission to the Mobile Ad Hoc Networking Working
Group of the Internet Engineering Task Force (IETF). Comments should be
submitted to the manet@itd.nrl.navy.mil mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.  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.


Abstract

   This document describes how to provide Internet connectivity with
mobile ad-hoc networks.  It describes how to obtain a globally routable
address , Manet node operation, and Internet-gateway operation.  Once
a Manet node obtains a global address from an Internet-gateway,
it can start to send data to the Internet.  Data goes through the
Internet-gateway with a routing header specifying the gateway.  This
connectivity method is not dependent on a particular Manet protocol.
Further, use of global connectivity with Mobile IPv6 is specified.


R. Wakikawa et.al.              Expires 01 Jan 2003             [Page i]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


                                Contents


Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. Terminology                                                        2

 3. Overview                                                           2

 4. Limitations and Assumptions                                        3

 5. Changing Route Request of each Manet Protocol                      4

 6. Changed Neighbor Discovery Protocol Packet Formats for Address
   Resolution                                                          4
     6.1. Modified Router Solicitation  . . . . . . . . . . . . . .    5
     6.2. Modified Router Advertisement . . . . . . . . . . . . . .    6
     6.3. Source Manet Address Option . . . . . . . . . . . . . . .    6

 7. Changing the Operation of the ICMPv6 Redirect                      7

 8. Manet Node Operation                                               7
     8.1. Sending a Global Address Resolution Request . . . . . . .    7
           8.1.1. Sending Manet Protocol Route Request  . . . . . .    8
           8.1.2. Sending Manet Router Solicitation . . . . . . . .    8
     8.2. Receiving Global Address Resolution Reply from
         Internet-Gateway . . . . . . . . . . . . . . . . . . . . .    9
     8.3. Sending a Packet to an Internet Node  . . . . . . . . . .   10
     8.4. Receiving ICMPv6 Error Message  . . . . . . . . . . . . .   12
           8.4.1. ICMPv6 Destination Unreachable Message  . . . . .   12
           8.4.2. ICMPv6 Redirect message . . . . . . . . . . . . .   12

 9. Internet-gateway Operation                                        12
     9.1. Route Examination during communication  . . . . . . . . .   12
     9.2. Receiving Route Request for a Global Destination Address    13
     9.3. Receiving Manet Router Solicitation . . . . . . . . . . .   13
     9.4. Forwarding Packets in the Internet-gateway  . . . . . . .   13

10. Intermediate Node Operation                                       14

11. Sending Packet to the Manet from the Internet                     14

12. Protocol Constants                                                14


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page ii]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


13. Security Considerations                                           14

Acknowledgments                                                       15

References                                                            15

Appendices                                                            16

 A. Use of Routing header for transmission of packets along a default
   route                                                              16

 B. AODV6 Operation with Global Connectivity for IPv6 Manet           17
     B.1. Additions to AODV6 specification  . . . . . . . . . . . .   17
     B.2. Global Address Resolution . . . . . . . . . . . . . . . .   18

 C. DSR Operation with Global Connectivity for IPv6 Manet             20
     C.1. Additions to DSR specification  . . . . . . . . . . . . .   20
     C.2. Global Address Resolution . . . . . . . . . . . . . . . .   20
     C.3. Communication to the Internet . . . . . . . . . . . . . .   21

 D. Mobile IPv6 Operation with Global Connectivity for IPv6 Manet     23

 E. Changes from draft-wakikawa-manet-globalv6-00                     25

Authors' Addresses                                                    25


1. Introduction

   A mobile ad-hoc network (Manet) is created dynamically when a set
of mobile routers form a mesh routing state for their connectivity
management, typically over a wireless network.  Many routing protocols
have been proposed for routing within Manets by the IETF MANET working
group.  These protocols aims to maintain a route to a destination
despite movement of intermediate nodes that causes the route path to
change.

   Global connectivity is required for nodes desiring communication with
the fixed Internet.  However, routing protocols for Manet typically only
maintain routes local within the reach of a Manet running the given
protocol.

   This document specifies a method for obtaining global connectivity
to the Internet and how Manet routing protocols can contribute to this.
The method is used for acquiring a global address from a gateway and to
communicate over the gateway.


R. Wakikawa et.al.              Expires 01 Jan 2003             [Page 1]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


2. Terminology

      Manet

         Mobile Ad-Hoc Network

      Internet-gateway

         Gateway that provides the Internet connectivity for nodes in
         the Manet.  This router should be placed at the edge of Manet
         and have connection to both the Internet and the Manet.

      Manet Address

         Manet node's identity address in Manet.  The address is used
         for ad-hoc routing.

      INTERNET_GATEWAYS multicast address

         Multicast address for all Internet-gateways in a Manet.  The
         address is defined as ALL_MANET_GW_MULTICAST

      Manet network interface

         A network interface connected to the Manet in an
         Internet-gateway or in a regular Manet node.

      Manet Router Solicitation

         A router solicitation message modified for Manet operation.

      Manet Router Advertisement

         A router advertisement message modified for Manet operation.


3. Overview

   This document proposes two methods for discovering Internet-gateways.
One method is to extend the route discovery messaging of an on-demand
routing protocol.  Another is to use extended router solicitation and
advertisements of the Neighbor Discovery Protocol (NDP) [5].  This
document also illustrates how to apply the first method to an existing
Manet protocol using the Ad-hoc On-demand Distant Vector (AODV) Routing
Protocol [8, 7] as an example.

   Whenever a node boots up in the Manet and needs to communicate over
the Internet, the node discovers an Internet-gateway to get its global
prefix information.  The node may discover the gateway pro-actively


R. Wakikawa et.al.              Expires 01 Jan 2003             [Page 2]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


after boot-up before it needs to communicate over the Internet, or
it may postpone this discovery to take place on demand when it needs
to communicate over the Internet.  A prefix which is distributed by
Internet-gateway is used for configuring a routable IPv6 [2] address
for the node.  The discovery can also be used for learning addresses of
Internet-gateways for setting up routes to the Internet through them.

   Internet-gateways SHOULD reply to a request with their own global
prefix information and IPv6 address.  A reply from the gateway provides
prefix information and possibly a route to the gateway, inserted as
a default route.  If there are more than one Internet-gateways and
intermediate nodes replying to the request, the requesting node can only
obtain gateway information known to the intermediate nodes and miss the
rest of the information, because intermediate nodes may not have all
Internet-gateways information.

   After obtaining the information from Internet-gateways, the node
configures a routable IP address from a prefix of a selected gateway
and inserts the gateway address as a default route.  Selection of the
gateway is out of scope of this document.

   If the node sends packets to the Internet, the node SHOULD use a
routing header to route packets through its Internet-gateway.  If
a packet is destined to the Internet-gateway first, intermediate
nodes just forward packets to the same Internet-gateway and the
Internet-gateway can then route the packet to its destination.
Otherwise, each intermediate nodes need to discover the route to the
destination address of the packets' IP header to route packets and each
of them send the packet towards their Internet-gateway.

   Each Internet-gateway monitors any packet received from the Manet to
prevent unnecessary packets from being forwarded to the Internet side
and to know how to react to signaling.  The destination of such a packet
passing through the Internet-gateway with routing header is checked
on the Internet-gateway.  If the destination is inside the Manet, the
Internet-gateway notifies the sender to change its route to a more
optimal one, a direct route into the Manet.  The node then receives a
notification and sends a route request to discover the direct route to
the destination.


4. Limitations and Assumptions

   For simplicity, we make the following assumptions in our draft:


R. Wakikawa et.al.              Expires 01 Jan 2003             [Page 3]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


      Address Family

         This document assumes IPv6 address family support.  The Manet
         routing protocol discussed in this document MUST be capable of
         supporting IPv6 routes.

      Topological assumption

         At least one Internet-gateway is at the edge of the Manet.

      Address assumption

         All nodes in Manet have a global address, routable or not with
         the Internet, for instance a Mobile IPv6 [4] home address.
         The global address is used for initial configuration when a
         node boots up and joins the Manet.  If the node does not have
         any global address at its network interfaces the node should
         temporarily configure an address from the MANET_INITIAL_PREFIX
         as described in the IP Address Autoconfiguration for Ad Hoc
         Networks [6]


5. Changing Route Request of each Manet Protocol

   To support this method of global connectivity formation, route
request and reply messages of each Manet protocol should be modified to
carry global prefix information and the gateway's IPv6 address.

   When a node requests global information to Internet-gateways,
the node broadcasts a route request to the INTERNET_GATEWAYS global
multicast address.

   Once an Internet-gateway receives the request, it MUST reply with
both the global prefix and its Internet-gateway address to this.  Each
Manet routing protocol need to support some scheme for route reply
to distinguish whether the route reply carries the Internet-gateway
information and address.  For example, each Manet route reply message
should have a flag which indicates an Internet-gateway information is
included in the reply.


6. Changed Neighbor Discovery Protocol Packet Formats for Address
   Resolution

   This section describes how to handle NDP packets to sent out over
multi-hop networks such as the Manet.

   Both router solicitation and router advertisement messages can not be
sent over multi-hop networks, because the link-local scope is not well


R. Wakikawa et.al.              Expires 01 Jan 2003             [Page 4]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


defined for Manets.  NDP assumes to use link-local scoped addresses as
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 because IPv6 prohibits to forward
packets sent to an address of link-local scope.  For doing so, NDP
packets must be modified.  The following sections describe the modified
"Router Solicitation" and "Router Advertisement" packet formats.


6.1. Modified Router Solicitation

   A host sends Manet Router Solicitations in order to prompt
Internet-gateways to generate Manet Router Advertisements.  The modified
Manet Router Solicitations MUST have a new M flag set and they MUST
include a Source Manet address option identifying the sender.  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 an expanding ring search technique
for Manet Broadcasting.

      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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |M|                          Reserved                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

      Manet Router Solicitation Flag (M)
              A 1-bit Manet Router Solicitation flag.  When set, it
              indicates that the Router Solicitation message can be
              sent over a multi-hop network.  The Internet-gateways
              MUST NOT forward this message to the fixed Internet.
              Whenever the flag is set, a Source Manet address option is
              required.  The Manet Address in the Source Manet Address
              sub-option is used for management Manet nodes at the
              Internet-gateway.

      Reserved
              Reduced from a 32-bit field to a 31-bit field to account
              for the addition of the Manet Router Solicitation (M)
              flag.

      Required Options:  Source Manet address
              The Manet global address of the sender.  This MUST be
              included even if the Source Address is the temporary
              address generated with MANET_INITIAL_PREFIX.


R. Wakikawa et.al.              Expires 01 Jan 2003             [Page 5]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


6.2. Modified Router Advertisement

   An Internet-gateway sends out a Manet Router Advertisement message
response to a Manet Router Solicitation.  The Internet-gateway SHOULD
NOT send unsolicited Manet Router Advertisements.  Sending them
periodically would generate unnecessary packets in the Manet.  The
modified Manet Router Advertisement MUST have the 'N' flag set.  The
Hop Limit field in the IPv6 header SHOULD be set to an appropriate
value if the expanding ring search algorithm in Manet Broadcasting is
used.  The `N' flag MUST be set in the Manet Router Advertisements and
it MUST carry the address of the Internet-gateway and the global prefix
information by the Prefix Information Option [5, 4].

      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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Cur Hop Limit |M|O|N|Reserved |       Router Lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Reachable Time                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Retrans Timer                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

      Manet Router Advertisement Flag (N)
              1-bit Manet Router Advertisement flag.  When set,
              indicates that the Router Advertisement message is only
              for Manet nodes and can be sent over multiple hop Manet
              nodes.  The Internet-gateways MUST NOT forward this
              message to the Internet.  Whenever the flag is set, the
              sender MUST include a Prefix Information option with a
              globally routable prefix.  A Source Manet Address option
              may be required, depending on the Manet protocol.


6.3. Source Manet Address Option

      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     |    Manet Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type       10

      Length     3


R. Wakikawa et.al.              Expires 01 Jan 2003             [Page 6]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


                 The length of the option (including the type and length
                 fields) in units of 8 octets.

      Manet Address
                 The 128 bit IPv6 address for the original source of the
                 packet.

   The Source Manet Address option contains the Manet address of the
sender of the packet.  It is used in Manet Router Solicitation, and
Manet Router Advertisement packets.  Since the source address field in
the IPv6 header might be changed by intermediate nodes running a Manet
routing protocol (i.e.  AODV), this option can indicate the exact sender
Manet address to receivers.

   These options MUST be silently ignored for other Neighbor Discovery
messages.


7. Changing the Operation of the ICMPv6 Redirect

   An ICMPv6 [1] Redirect message sent to a Manet node MUST include the
Source Manet address option and is used to notify that this destination
address is located on this MANET. It is used by the Internet Gateway to
novity a sending node that a destination is located on this MANET and
instead should send packets to it using ordinary MANET routing.


8. Manet Node Operation

8.1. Sending a Global Address Resolution Request

   A node needs a globally routable address in order to be globally
reachable and receive packets from the Internet.  The node also needs to
learn the location and address of the gateway that provide the node with
this access to the Internet.

   The node therefore needs to somehow obtain a global prefix owned
and distributed by an Internet-gateway.  One way of obtaining this
information is by relying on advertisements distributed by the Internet
Gateway as part of its Neighbor Discovery Protocol.  A Manet Node could
then send a Manet Router Solicitation for an Internet Gateway and
receive a Manet Router Advertisement back in response from the Internet
Gateway.

   In some cases, as mentioned above, the Internet Gateway might not be
able to distribute the router advertisement through the Manet, because
of link-local scope being not well defined in the Manet.


R. Wakikawa et.al.              Expires 01 Jan 2003             [Page 7]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


   We will in this document describe three ways for requesting global
routing information from an Internet Gateway:

    -  sending Manet route request for a global destination address

    -  sending Manet route request to the INTERNET_GATEWAYS multicast
       address

    -  sending Manet Router Solicitation

   The IPv6 address used during any of these operations could be
any arbitrary global-scope address, for example a Mobile IPv6 home
address.  If no such address is available ,the node SHOULD create
a temporary global-scope address, generated from the well-known
MANET_INITIAL_PREFIX [6].  This temporary address should be
deleted after obtaining the globally routable IPv6 address from an
Internet-gateway.


8.1.1. Sending Manet Protocol Route Request

   A node could rely route request and route reply messages of an
on-demand manet routing protocol to obtain the global prefix and address
of an Internet Gateway.  The node sends a modified route request and
receives a modified route reply in response from the Internet Gateway.
For instance, the node propagates a Route Request (RREQ) message using
AODV and waits for an Internet Gateways to return a reply, such as an
AODV Route Reply (RREP).

   The address which we here request a route for in the route request
messages could either be the INTERNET_GATEWAYS global multicast address
or the global address of a destination node located on the Internet with
whom we would like to communicate with.  Both addresses would in this
case indicate that we request a reply message specifying a global prefix
and Internet Gateway address.


8.1.2. Sending Manet Router Solicitation

   A node can request a Manet Router Advertisement by an Internet
Gateway by sending a Manet Router Solicitation to the INTERNET_GATEWAYS
multicast address.  The node MAY use an expanding ring search technique
to broadcast the Router Solicitation message using appropriate Hop Limit
values.

   A receiving node MUST be a member of the INTERNET_GATEWAYS group if
it is an Internet Gateway and it SHOULD be a member if it is an ordinary
non Gateway Manet node.  If the receiving node is a Gateway, it replies
with a Manet Router Advertisement message specifying its global prefix


R. Wakikawa et.al.              Expires 01 Jan 2003             [Page 8]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


information and Internet Gateway address.  Otherwise, the node just
propagates the Manet Router Advertisement message if the hop-limit
allows this.

   In the latter case, intermediate nodes SHOULD not process this
packet, but just forward it.  However, Manet protocols need to setup a
reverse route in order to propagate the response back.  In such a case,
mere forwarding of the packet will not introduce this reverse route and
a response from an Internet Gateway will cause a search for the reverse
route, e.g., in AODV6.

   It totally depends on the behavior of the MANET routing protocol
whether it can use the INTERNET_GATEWAYS multicast address as the
broadcast address in a MANET. If the receiving node is not an Internet
Gateway and hop-limit allows it, the node MUST propagate the request
ahead towards the INTERNET_GATEWAYS address.


8.2. Receiving Global Address Resolution Reply from Internet-Gateway

   After either of the above operations have taken place,the node should
know a global prefix and the address of its related Internet Gateway.
First, the node should generate a global IPv6 address by using the
global prefix information.  The node SHOULD use its 64-bit interface ID.
Since the node assumingly has already done Duplicate Address Detection
(DAD), as defined in [6], for the link-local address before setting
up the global address, a global address with host number from this
link-local address is also unique if this rule is followed.  If not, the
node MAY perform another DAD for this global address.  If the node used
a temporary address generated by MANET_INITIAL_PREFIX when requesting
global information, this address SHOULD now be deleted.  Further,
all the host routes for this temporary address SHOULD be deleted in
intermediate nodes and Internet-gateway.  This is achieved by using
some route maintenance operation defined in MANET routing protocol, for
example, the Route Error (RERR) message used AODV6.  It MAY be left to
be deleted by timeouts.

   In the routing table, the node should set the following two routes.
We assume the global prefix is exclusively on the Manet side.

        Destination/prefix length       Next-Hop
        ---------------------------     -----------------------------

  Default Route/0
        <Default>                       <Internet-gateway address>
  Host Route/128
        <Internet-gateway address>      <neighbor forwarding the reply>


R. Wakikawa et.al.              Expires 01 Jan 2003             [Page 9]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


   These routing entries should be held until expiration of the lifetime
which the Internet-gateway provides in the reply to the global address
resolution request.  Lifetime of default route entry and global prefix
information is stored in either route reply or route advertisement
messages which are sent by Internet Gateway.  During active lifetime,
the receiving node can use the global prefix and the Internet Gateway
as default route entry.  The Internet Gateway MUST hold or acquire the
reverse route to the requesting node before expiration of the lifetime.
During use of the Internet-gateway as a route path for communications,
the node MUST keep re-requesting global prefix information to the
Internet-gateway before the lifetime is expired.  This refreshment
SHOULD be done at GWINFO_REFRESH periods.  The node can unicast the
request to the respective Internet-gateway, or alternatively it can
broadcast the request to all over the Manet network again.  The former
method can allow the Manet node to update the current Internet-gateway
status, the latter method enables the Manet node to quickly discover all
possible Internet-gateways in the Manet.


8.3. Sending a Packet to an Internet Node

   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
       found it sends the packet towards the destination.

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

        1. If a default route exists, the node MAY wait for the above
           route request.

        2. If a default route doesn't exist, the node uses one of the
           two methods to obtain a default route.

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

    -  If the node gets a route reply for the destination, it sets a
       host route for the destination, and sends packets according to
       this route.

   First, a node looks up a route for the destination of a packet from
its routing table.  If the node finds a host route, it sends the packet
to its destination.  Otherwise, the node SHOULD send a route request
for the destination of the outgoing data packet using its Manet routing
protocol.  Then, if a default route exists, the node MAY wait for


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 10]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


the above route request.  If no such request is pending and the node
doesn't have default route, it uses one of the methods described in this
document to obtain a default route.

   If the node requested a route for the destination but does not get
route replies, the node assumes the destination node is located on the
internet and sends the packet using the default route.  Sending packets
towards the default route is operated by each base manet protocol.  Here
it depends on whether packet forwarding associated with the used manet
protocol supports next hop forwarding or not.  If that is the case, each
intermediate node could independently decide the best route for packet
out of the Manet, and towards the destination.  The node does not need
to take care of the explicit route to the Internet-gateway.  However,
some manet protocol (ex.  DSR) does not support next hop forwarding,
routing header SHOULD be used specifying the Internet-gateway's address
as an intermediate routing point towards the destination.

   The use of routing header also provides optimization and control for
forwarding packet to Internet-gateway.  Each intermediate node does
not need to decide the best route for packet (i.e.  default route or
host route if it is available), instead it simply uses a host route
of the Internet-gateway to forward packet to the Internet-gateway.
Control of forwarding route path can be relevant approach when multiple
Internet-gateways are placed in a manet.  The minute details are
described in appendix A.

   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 an route entry for the destination with the default route
as a next hop of the destination node .  The routing table of the node
SHOULD be configured for the destination as below entries.

        Destination/prefix length       Next-Hop
        ---------------------------     -----------------------------

  Default Route/0
        <Default>                       <Internet-gateway address>
  Host Route/128
        <Internet-gateway address>      <neighbor forwarding the reply>
        <Destination address>           <Default>

   The node MUST send at least one route request for 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.


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 11]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


   If the node gets a route reply, the node assumes the node is located
within the ad hoc network, sets a host route for the destination, and
sends packets normally according to this host route.


8.4. Receiving ICMPv6 Error Message

   A Manet node usually receives two types of ICMPv6 messages, the
ICMPv6 Destination Unreachable Message and the ICMPv6 Redirect message.
These messages are propagated over the Manet and their use is the same
as for any other IP network.


8.4.1. ICMPv6 Destination Unreachable Message

   If a Manet node receives an ICMPv6 Destination Unreachable message
after sending data packets using a host route, the node MUST delete
this entry in the routing table.  If needed, the node can rediscover a
route for the destination by sending a route request again.  This exact
behavior depends on the Manet routing protocol in use.

   If the Manet node receives ICMPv6 Destination Unreachable messages
after sending data packets to a destination using a default route entry,
the node can send a single route request for the destination again.  If
the node does not receive any route reply, the node SHOULD NOT send any
packets including route requests for the destination for a while.


8.4.2. ICMPv6 Redirect message

   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.


9. Internet-gateway Operation

9.1. Route Examination during communication

   An Internet Gateway SHOULD have reverse routes for all the manet
nodes which exists in its manet network.  Whenever the Internet Gateway
receives the packets sent by manet nodes and forwards them, it examines
the route path for the packets' destination address.  If the Internet
Gateway finds the host route towards the manet interface for the
destination, it indicates the destination node must be at same manet
network and it is possible to have the host route between the source
and the destination node.  Internet Gateway sends a kind of route


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 12]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


error messages to notify sender node to start a manet routing request
operation in order to obtain the host route instead of the default
route.  On the other hand, if the Internet Gateway finds an appropriate
route path, which is not the host route towards the manet interfaces, it
routes the packets to the destination on the route.

   A host route to a Manet node should be maintained until the node
re-requests global information with a NDP Manet Router Solicitation
message or a Manet protocol route request.  If the Internet-gateway does
not get any re-request messages before the lifetime of the host route is
expired, it discards the host route.


9.2. Receiving Route Request for a Global Destination Address

   When an Internet-gateway receives a Manet protocol route request
destined to another address than the INTERNET_GATEWAYS global multicast
address, it searches the address in its routing table.  If the
Internet-gateway finds the host route, it SHOULD NOT return a Manet
protocol route reply augmented with global connectivity information
because the destination is then assumed to be inside the Manet.  If the
address was not found in the routing table, the Internet-gateway returns
a Manet protocol route reply with global connectivity information.  This
includes its own Manet address as route information used for the default
route entry.

   If the Internet-gateway receives a route request for the
INTERNET_GATEWAYS global multicast address, it MUST unicast back its
global connectivity information, including its own IPv6 address.  The
Internet-gateway SHOULD also include the lifetime GWINFO_LIFETIME into
its global connectivity information.  Each time when receiving such a
request, the Internet-gateway MUST update the reverse route of sender
into its routing table.


9.3. Receiving Manet Router Solicitation

   If the Internet-gateway receives a Manet Router Solicitation,
it SHOULD reply with its own prefix information in a Manet Router
Advertisement messages by unicast.  Each time when receiving such a
request, the Internet-gateway MUST record the reverse route of sender
into its routing table.


9.4. Forwarding Packets in the Internet-gateway

   An Internet-gateway always stores the sender's Manet address into
an associated Manet nodes list and eventually a reverse route into its
routing table.


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 13]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


   When the Internet-gateway receives a packet from the Manet network
interface, it searches a host route for the destination address from its
routing table .  If it finds the host route, it MUST discard the packet
and return an ICMPv6 Redirect Message or a route error message to the
sending Manet node.  If it does not find the address from the list it
forwards the packet to the Internet.

   When the Internet-gateway receives a packet from the Internet,
destined to a Manet node, it forwards the packet towards the Manet node
by using a host route generated by the Manet protocol.  If such a route
does not exist, it is normally requested by the Manet protocol.  Hence,
no Internet-gateway specific action is needed for a packet going from
the Internet to the Manet.


10. Intermediate Node Operation

   If an intermediate Manet node receives a Manet protocol route request
for address resolution or a NDP Manet Router Solicitation, it MUST not
reply with global connectivity information and the Internet-gateway
address, even if it knows this information.  Otherwise the Manet gateway
would not learn nodes in the network.  The request MUST be propagated in
the Manet towards Internet-gateways, instead.


11. Sending Packet to the Manet from the Internet

   Packets forwarded to a global address in the Manet get routed from
the Internet to the Internet-gateway which advertised the prefix of the
global destination address.  The Internet-gateway then just resorts to
its normal Manet protocol operation to forward the packet towards its
destination in the Manet.


12. Protocol Constants
      Parameter Name           Value
      ----------------------   -----
      ALL_MANET_GW_MULTICAST   TBD (ff1e::xx/64 global-scope)
      GWINFO_LIFETIME          TBD (10 seconds)
      GWINFO_REFRESH           GWINFO_LIFETIME * 0.8


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


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 14]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


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 also thank Thierry
Ernst for his comments.


References

   [1] A. Conta and S. Deering.  Internet Control Message Protocol
       (ICMPv6) for the Internet protocol version 6 (ipv6).  Request
       for Comments (Proposed Standard) 1885, Internet Engineering Task
       Force, December 1995.

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

   [3] D. Johnson, D. Maltz, Y. Hu, and J.G. Jetcheva.  The dynamic
       source routing protocol for mobile ad hoc networks (work in
       progress).  Internet Draft, Internet Engineering Task Force,
       February 2002.

   [4] D. Johnson, C. Perkins, and J. Arkko.  Mobility support in IPv6
       (work in progress).  Internet Draft, Internet Engineering Task
       Force, May 2002.

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

   [6] C. Perkins, J. Malinen, R. Wakikawa, E. Royer, and Y. Sun.  IP
       address autoconfiguration for ad hoc networks (work in progress).
       Internet Draft, Internet Engineering Task Force, November 2001.

   [7] C. Perkins, E. Royer, and S. Das.  Ad hoc on demand distance
       vector (AODV) routing for IP version 6 ( work in progress).
       Internet Draft, Internet Engineering Task Force, November 2000.

   [8] C. Perkins, E. Royer, and S. Das.  Ad hoc on demand distance
       vector (AODV) routing (work in progress).  Internet Draft,
       Internet Engineering Task Force, January 2002.


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 15]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


A. Use of Routing header for transmission of packets along a default
   route

   As described in section 8.3, each manet node have two way to send
data along a default route when it decides to use of default route
for transmission packet.  The node SHOULD support both but select one
depending on the base Manet protocol and network topology.

    -  Without IPv6 routing extension header the sender sends the packet
       to the global IPv6 address and relies upon next hop routing in
       the other nodes.

    -  With IPv6 routing extension header the sender uses the
       Internet-gateway address in the destination address of the IPv6
       header and the real destination address in the routing header.

   This document recommends to use the second method for the following
reason.  Assume the destination is inside the Manet but the sender
can not reach the destination via a host route.  In such a case, if
the 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 undoubtedly 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 ICMP Redirect
messages, the node can send a route request for the destination to learn
the host route.

   Using a routing header is also preferable if 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 01 Jan 2003             [Page 16]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


B. AODV6 Operation with Global Connectivity for IPv6 Manet

   This section describes how to apply embedding of the Internet
connectivity acquisition to an on-demand Manet routing protocol,
AODV [8], more precisely, to its IPv6 variant [7].

   All the operation except for a specific explanation in this section
follow the descriptions presented earlier in this document.


B.1. Additions to AODV6 specification

   The AODV6 protocol is used as is, except for the addition of one
flag.

    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      |J|R|G|I|     Reserved          |   Hop Count   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Flooding ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination IP Address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Destination Sequence Number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source IP Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Source Sequence Number                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of the IPv6 Route Request message (RREQ) is illustrated
above, and contains the same fields with the same functions as the RREQ
message defined for IP version 6 (in [3]), except for the following:

      Internet-Global Address Resolution Flag (I)
             Internet-Global Information Flag:  used for global address
             resolution.  This flag indicates that the destination node
             requests global connectivity.


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 17]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


    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      |R|A|I| Reserved  |  Prefix Sz  |   Hop Count   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              32-bit Destination Sequence Number               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                128-bit Destination IP Address                 |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                   128-bit Source IP Address                   |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Lifetime                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of the IPv6 Route Reply message (RREP) is illustrated
above, and contains the same fields with the same functions as the RREP
message defined for IP version 6 (in [3]), except for the following.

      Internet-Global Address Resolution Flag (I)
             Internet-Global Information Flag:  used for global address
             resolution.  This flag defines that this reply contains
             information about an internet gateway.


B.2. Global Address Resolution

   This section describes how to obtain a globally routable IPv6 address
from an Internet-gateway by sending an AODV6 Route Request (RREQ) to the
INTERNET_GATEWAYS global multicast address.

   When a node sends a RREQ, requesting global address resolution, it
can as IPv6 source address specify any arbitrary address with global
scope currently in use by one of its interfaces.  This could, for
example, be its Mobile IPv6 home address or an address created temporary
from the MANET_INITIAL_PREFIX. The node then broadcasts the RREQ using
the 'I' flag and specifies the INTERNET_GATEWAYS global multicast
address as the destination in the RREQ destination address field.

   When an Internet-gateway receives a RREQ with the `I' flag set, it
checks its routing table for an entry towards the receiving network
interface and updates it with an entry of for requesting node using
the source address specified in the RREQ. The Internet-gateway then
constructs a Route Reply (RREP with the 'I' flag set), and unicasts it
to the requesting node.  The IPv6 header fields should be built as in


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 18]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


normal AODV6 operation.  The global prefix information can be derived
using the responding gateway's IPv6 address and the prefix length
specified in the RREP. In this way, the node will know both the address
of the gateway and the globally routable prefix.

   After acquiring a topologically correct global IPv6 address, the node
first deletes the temporary address from the MANET_INITIAL_PREFIX. If
the node didn't create this temporary address, the node can continue
using the arbitrary address, e.g.  the Mobile IPv6 home address,
used during communication with the gateway.  The node then broadcasts
a Route Error (RERR) with the temporary address to delete all the
related host routes.  This RERR could also create new reverse routes
for the newly created global IPv6 address at intermediate nodes and
Internet-gateways.  It is, however, not permitted by the current AODV6
specification to setup reverse routes using RERR messages.  Another RREQ
can therefore be sent over the Manet to create these reverse routes at
intermediate nodes.  These reverse routes will become the route path to
the Internet-gateway for the nodes newly created global address.  The
Internet-gateway should insert the nodes host route into its routing
table.  The old entry in the gateway related to the temporary address
will be discarded after lifetime expiration.

   When the node sends packets to the internet, it MAY use any of the
two methods specified in section 8.3 and appendix A.

   If the node chooses to send a packet to the Internet without using
a routing header, some intermediate nodes may generate RERR message
because they do not have an active route to the packet's destination,
see the AODV specification [8] for more details about this.  To avoid
these unnecessary RERRs, a default route is defined as the active route
in this document.  This means that an intermediate node should have an
active default route.  If the intermediate node doesn't have a host
route for a destination, it should route packets towards the default
route.

   If the node instead uses a routing header, the address of the
Internet-gateway should be specified in destination address field of
the IPv6 header.  All intermediate nodes on the route path to the
internet-gateway will then have a host route to the destination address,
ie. the internet-gateway address.  The intermediate node cannot generate
a RERR message for outgoing packets destined outside of the Manet.


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 19]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


C. DSR Operation with Global Connectivity for IPv6 Manet

   This section describes how to apply embedding of the Internet
connectivity acquisition to an on-demand Manet routing protocol, Dynamic
Source Routing protocol (DSR) [3].

   All the operation except for a specific explanation in this section
follow the descriptions presented earlier in this document.


C.1. Additions to DSR specification

   Global address resolution option is newly defined for DSR since DSR
does not have a flag field in Route Request Option and Route Reply
Option.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |    Reserved   |   Prefix Sz   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The format of the Global Address Resolution Option is illustrated
above.

      Option Type
             TBD

      Option Data Length
             8-bit unsigned integer.  Length of the option, in octets,
             excluding the Option Type and Opt Data Len fields.

      Reserved
             MUST be sent as 0 and ignored on reception.

      Prefix Size
             The Prefix Size specifies the prefix size of the replying
             gateway's global address.  The prefix size will be used for
             address generation with the gateway global address.


C.2. Global Address Resolution

   This section describes how to obtain a globally routable IPv6
address from an Internet-gateway by sending an DSR Route Request to the
INTERNET_GATEWAYS global multicast address.


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 20]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


   When a node sends a Route Request, requesting global address
resolution, it can as IPv6 source address specify any arbitrary address
with global scope currently in use by one of its interfaces.  This
could, for example, be its Mobile IPv6 home address or an address
created temporary from the MANET_INITIAL_PREFIX. The node then
broadcasts the Route Request using the Global Address Resolution Option
and specifies the INTERNET_GATEWAYS global multicast address as the
target address destination in the Route Request.

   When an Internet-gateway receives a Route Request with the Global
Address Resolution Option, it checks its routing table for an entry
towards the receiving network interface and updates it with an entry
of for requesting node using the source address specified in the
IPv6 header field.  The Internet-gateway then constructs a Route
Reply with Global Address Resolution Option, , and unicasts it to the
requesting node.  The IPv6 header fields should be built as in normal
DSR operation.  The global prefix information can be derived using the
responding gateway's IPv6 address and the prefix length specified in the
Global Address Resolution Option.  In this way, the node will know both
the address of the gateway and the globally routable prefix.

   After acquiring a topologically correct global IPv6 address, the node
first deletes the temporary address from the MANET_INITIAL_PREFIX. If
the node didn't create this temporary address, the node can continue
using the arbitrary address, e.g.  the Mobile IPv6 home address, used
during communication with the gateway.  The node then broadcasts a
Route Error with the temporary address to delete all the related host
routes.  The Route Error of DSR does not contain any address lists to
create new reverse route for the newly created global IPv6 address at
Internet-gateways.  Route Request can therefore be sent over the Manet
to create reverse routes at internet-gateways after previous Route
Error operation.  The reverse routes will become the route path to
the Internet-gateway for the nodes newly created global address.  The
Internet-gateway should insert the nodes host route into its routing
table.


C.3. Communication to the Internet

   When the node communicates to a destination which is located in the
internet, it can use same way as base DSR protocol.  DSR uses the DSR
Source Route Option to route packets to a destination.  The DSR Source
Route Option is extracted from the draft as below.


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 21]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |F|L|Reservd|Salvage| Segs Left |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[1]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[2]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[n]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   If a DSR node sends packets to the global destination, the DSR node
set Last Hop External flag (L) in the Source Route Option and puts
an internet-gateway address in Address[n-1] when address[n] is the
destination address.  The operations of routing packets with the Source
Route Option are followed by DSR protocol.

   If a global node at the Internet sends packets to a DSR node which is
located in DSR network, the global node set First Hop External flag and
puts an internet-gateways address in Address[2].  Address[1] should be
set the global address of the global node.  The operations of routing
packets with the Source Route Option are followed by DSR protocol as
well.


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 22]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


D. Mobile IPv6 Operation with Global Connectivity for IPv6 Manet

   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 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 source field is
sufficient for packets sent from the Manet node in such sessions.

   If the address is a more permanent one, it can be used as a Mobile
IPv6 [4] 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 uses neighbor
discovery 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 replaces the neighbor discovery part of its
movement detection with globally routable address acquisition, as
defined in this document.  The movement detection can e.g. be bypassed
by the routing daemon by it locally in the host passing a router
advertisement to the Mobile IPv6 Neighbor Discovery -based movement
detection algorithm.

   The mobile node then 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.

   All Manet nodes MUST support minimal Mobile IPv6 Correspondent Node
(CN) operation, 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 inserts 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 correspondent node, the possible
routing header injected by Mobile IPv6 is modified by inserting the


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 23]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


entry for gateway prior to the entry for home address, and setting the
segments left to two.


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 24]


Internet Draft      Global Connectivity for IPv6 Manets     01 July 2002


E. Changes from draft-wakikawa-manet-globalv6-00

    -  Added algorithm in section 8.3 whether the destination is early
       discovered by route request or not.  It helps to prevent repeated
       redundant route requests.

    -  Added DSR operation as an example in appendix.

    -  Moved the use of routing header from section 8.3 to appendix A,
       since some base Manet protocol can forward packet to the
       Internet-gateway by next hop forwarding support (e.x.  AODV).

    -  Kept protocol parameters as TBD.


Authors' Addresses


        Ryuji Wakikawa               Charles Perkins
        Graduate School of           Communications Systems Lab
        Media and Governance.        Nokia Research Center
        Keio University              313 Fairchild Drive
        5322 Endo Fujisawa Kanagawa  Mountain View, California
        252 JAPAN                    94043 USA
        Phone:  +81-466 49-1394      Phone:  +1-650 625-2986
        EMail:  ryuji@sfc.wide.ad.jp EMail:  charliep@iprg.nokia.com
        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
        Phone:  +1-650 625-2355      Phone:  +46 46-39 72 92
        EMail:                       EMail:
        jmalinen@iprg.nokia.com      anders.nilsson.024@student.lth.se
        Fax:  +1 650 625-2502        Fax:  +46 46-14 58 23

        Antti J. Tuominen
        TM Laboratory
        Helsinki University of Technology
        P.O.Box 9700
        02015 HUT
        Finland
        Phone:  +358 9
        EMail:  ajtuomin@tml.hut.fi
        Fax:  +358 9


R. Wakikawa et.al.             Expires 01 Jan 2003             [Page 25]