One document matched: draft-wakikawa-manet-globalv6-04.txt
Differences from draft-wakikawa-manet-globalv6-03.txt
Mobile Ad Hoc Networking Working Group Ryuji Wakikawa
INTERNET DRAFT Keio University
18 Jul 2005 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-04.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 December 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
R. Wakikawa et.al. Expires 18 Jan 2005 [Page i]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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. 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.
Contents
Status of This Memo i
Abstract ii
1. Introduction 2
2. Terminology 3
3. Overview 4
4. Conceptual Data Structures and Messages 5
4.1. Conceptual Data Structures . . . . . . . . . . . . . . . 5
4.2. Internet-Gateway Information . . . . . . . . . . . . . . 5
4.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3.1. Modified Router Solicitation . . . . . . . . . . 7
4.3.2. Modified Router Advertisement . . . . . . . . . . 8
4.3.3. Modified Routing Signaling . . . . . . . . . . . 8
4.3.4. Changing the ICMPv6 Redirect . . . . . . . . . . 8
5. Manet Node Operation 10
5.1. Receiving Internet-Gateway Advertisement . . . . . . . . 10
5.2. Address Autoconfiguration . . . . . . . . . . . . . . . . 10
5.3. Default Route Setup . . . . . . . . . . . . . . . . . . . 11
5.4. Source Address Selection . . . . . . . . . . . . . . . . 12
5.5. Receiving ICMPv6 Error Messages . . . . . . . . . . . . . 12
5.6. Use of Routing Header . . . . . . . . . . . . . . . . . . 13
5.7. Interaction with Mobility Protocols . . . . . . . . . . . 14
6. Reactive Manet Node Operation 16
6.1. Soliciting Internet-Gateway Advertisement (Optional) . . 16
6.2. Route Selection for reactive protocols . . . . . . . . . 16
7. Internet Gateway Operation 19
7.1. Joining a Mobile Ad-hoc Routing Domain . . . . . . . . . 19
7.2. Sending Internet-Gateway Advertisement . . . . . . . . . 19
R. Wakikawa et.al. Expires 18 Jan 2005 [Page ii]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
7.3. Receiving Internet-Gateway Solicitation . . . . . . . . . 20
7.4. Management of Manet Nodes on Internet-Gateway . . . . . . 20
7.5. Route Examination . . . . . . . . . . . . . . . . . . . . 21
8. Protocol Constants 23
9. Security Considerations 23
Acknowledgments 23
References 23
Appendices 25
Authors' Addresses 25
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 1]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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 AODV [10],
OLSR [2], DSR [6], and TBRPF [9].
Global connectivity is often required for manet routers desiring
communication with the fixed Internet. However, routing protocols
for manets typically 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 at the edge of the manet.
- Address assumption
All nodes in the manet must have or acquire a routable address,
perhaps usable as a Mobile IPv6 [7] home address. The routable
address is used for initial configuration when a node boots up
and joins the manet
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 2]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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 at the edge of
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.
internet-gateway solicitation
A message to solicit an internet-gateway advertisement.
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 18 Jan 2005 [Page 3]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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 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.
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 [10] and DSR[6]. 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) [8] 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 and 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 (Internet Route). A prefix which is distributed by an
internet-gateway can be used for configuring a (typically globally)
routable IPv6 [4] address for each manet node.
After accepting an advertisement from the internet-gateway, the
manet node configures a routable IP address from the prefix of
the gateway and inserts the 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.
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 4]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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)[8]. These structures
can be implemented using variety of techniques. An example to
implement these structures 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 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. Internet Gateway Prefix Flag
5. Number of advertised Internet Gateways
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
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 5]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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 an internet-gateway. The information which
a 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 [8].
1. Internet-gateway global address
The internet-gateway IPv6 global address, which can be used as a
route to the Internet on manet nodes.
2. 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.
3. Internet Gateway Prefix length
Prefix length of the network prefix address of an
internet-gateway.
4. Internet Gateway Prefix Preferred Lifetime
The addresses generated from the prefix via stateless address
autoconfiguration remain preferred [ADDRCONF]. A value of all
one bits (0xffffffff) represents infinity. See [ADDRCONF].
After expiration of the lifetime, the manet node MUST delete its
autoconfigured IPv6 global address.
5. Internet Gateway Lifetime
The lifetime of an internet-gateway. After expiration of the
lifetime, a manet node MUST NOT use the internet gateway as a
route toward the Internet. It SHOULD get fresh internet-gateway
information.
6. 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 two messages such as internet-gateway
solicitation and internet-gateway advertisement. The
internet-gateway solicitation can be implemented as either a
modified Route Solicitation or an extended message of routing
protocol (ex. a router request of DYMO [1]). Likewise, the
internet-gateway advertisement can be defined as either a modified
Router Advertisement or an extended message of routing protocol
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 6]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
such as a router reply of DYMO. In this specification, we introduce
extension of a router solicitation and a router advertisement.
The routing protocol messages must be modified to carry the
internet-gateway information defined in Section 4.2. DYMO has
already supported the global connectivity in their messages defined
in [1]. The similar extension can be used in the case of the other
routing protocols.
As we explained in [12], a router solicitation and a router
advertisement are not originally designed to route over multi-hop,
because NDP [8] 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 because IPv6 prohibits to
forward packets sent to an address of link-local scope. For doing
so, NDP packets must be modified.
4.3.1. Modified Router Solicitation
Router solicitation is extended to have a flag called ``Manet Router
Solicitation 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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Manet Router Solicitation Flag (M)
1-bit Manet Router Solicitation flag. The flag indicates
that the Router Solicitation can be sent over a multi-hop
network. The internet-gateways MUST NOT forward this
message to the nodes on the Internet.
Reserved
Reduced from a 32-bit field to a 31-bit field to account
for the addition of the Manet Router Solicitation (M)
flag.
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 7]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
4.3.2. Modified Router Advertisement
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. The flag 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 nodes
on 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.
The extended Router advertisement MUST have a prefix information
option defined in [8]. The prefix information option is not
modified. However, L flag must be unset and the Valid Lifetime field
MUST be set to zero for the modified router advertisement, since
on-link determination can not be used for Manet.
4.3.3. Modified Routing Signaling
DYMO specifies gateway concept in DYMO messages [1].
4.3.4. Changing the ICMPv6 Redirect
For global connectivity, an ICMPv6 Redirect message [8] 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 [8], 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 18 Jan 2005 [Page 8]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
address. In the target address field, the internet-gateway SHOULD
insert the wildcard IPv6 address (i.e. ::).
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 9]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
5. Manet Node Operation
For internet connectivity, each manet node needs to generate IPv6
global address and configure a route to the Internet.
5.1. Receiving Internet-Gateway Advertisement
When a manet node receives an extended router advertisement
as an internet-gateway advertisement, it first verifies the
message according to the NDP specification [8]. Except for this
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 N flag set. If the flag is unset, the
manet node MUST silently be discarded while it being inside a
manet. The manet node MAY keep the information of the route
advertisement and will use the information when it is away from
the manet.
- The message MUST have a correct prefix information option.
Otherwise, the message MUST silently be discarded. Each node
MUST verify following items.
* 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 Valid Lifetime MUST be set to zero
* L flag MUST be unset and A flag MUST be set
* Prefix Preferred Lifetime must be greater than zero.
After successful verifications, the manet node keeps the
internet-gateway information into the prefix list and the default
router list as described in Section 4.1.
5.2. Address Autoconfiguration
After the first internet-gateway advertisement has been received
from the internet-gateway(s), a manet node SHOULD generate a global
IPv6 address by using the internet-gateway information. The node
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 10]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
SHOULD use its EUI-64 in order to construct a valid address with the
acquired prefix. Since the manet node is assumed to already have
done Duplicate Address Detection (DAD), as defined in [11], 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 DAD is not yet completed, the manet node MAY perform another DAD
for this global address. How to operate DAD is not in the scope of
this documentation, but can be [11].
If the manet node used a temporary address generated by
MANET_INITIAL_PREFIX when requesting global information, this address
SHOULD be deleted. Further, all 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 in AODV6. Otherwise, those host routes MAY be left to
be deleted by timeouts.
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>
* If there are several internet-gateways, the manet node may insert
the multiple entries for the internet route.
** The internet route may be stored in IGW list and refered the
list whenever a manet node fails to search a manet route for a
destination.
*** Note that the host route is set according to each manet routing
protocol.
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. Note: The
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 11]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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
manet node to quickly discover all possible internet-gateways in the
manet.
5.4. Source Address Selection
Each manet node carefully select 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 located outside the manet, it MUST use its
global address. The global address can be home address.
- If a destination is 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 just stop sending packets to the destination. If
needed, the node can rediscover a route for the destination by each
manet routing protocol once. This exact behavior depends on the
manet routing protocol in use. If the node can not get any route for
the destination, the node SHOULD NOT operate any discovery operation
for 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
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 12]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
its method of learning a manet destination, e.g., by sending a route
requests for the destination.
5.6. Use of Routing Header
Each manet node sends data along an internet route when the
destination of transmission packets is located on the Internet. The
node has different way to transmit packets through the Internet
Gateway.
- Without IPv6 routing extension header
The sender 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 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.
When reactive 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 has this problem. Intermediate nodes of a manet route
only knows neighbor's information on its routing table. Intermediate
nodes do not know that the destination address is located on the
Internet until route discovery is operated. 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.
Assume the destination is 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
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 13]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
the ICMPv6 Redirect messages, the manet node can re-discover a manet
route for the destination.
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.
5.7. Interaction with Mobility Protocols
If a global address is a more permanent one on a manet node, it can
be used as a Mobile IPv6 [7] 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 extended router
advertisement to detect node's movement and to generate a globally
routable address (i.e. Care-of address). The same mechanism below
can be applied to the NEMO Basic Support protocol [5].
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. 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 [7], 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
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 14]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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 18 Jan 2005 [Page 15]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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.
When an internet-gateway uses the extended router solicitation as the
internet-gateway solicitation, following steps are required.
- It must set N flag in the router 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 [11]. 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:
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 16]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
- 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 MUST NOT be selected as a route
for the destination at this point.
- 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:
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>
Note that the host route is set according to each manet routing
protocol.
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.
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 17]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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 18 Jan 2005 [Page 18]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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 be 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 extended router advertisement is used, the `N' flag MUST be
set in the internet-gateway advertisements. It MUST carry a Prefix
Information Option [8, 7]. The internet-gateway contains its global
prefix in the prefix information option. The source address of the
router advertisement 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.
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 19]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
When the internet-gateway uses extended routing protocol signaling
messages instead of the router advertisement, it must follow the
specifications of each manet protocols.
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 a router solicitation having N flag set, the
internet-gateway must operate following verifications in addition to
the verification specified in [8].
- The router solicitation must have N flag. Otherwise, the
internet-gateway processes the router solicitation as specified
in [8].
- If the source address is link local address, it SHOULD drop the
router solicitation.
- If the hop limit field of the message is less than or 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 router
advertisement message as described in Section 7.2.
7.4. Management of Manet Nodes on Internet-Gateway
An internet-gateway SHOULD known 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 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 routing table.
On the other hand, most of reactive manet protocols only maintain
partial topology of manet nodes. However, 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
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 20]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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.
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, it just discards
the packet and returns an ICMP Unreachable message. The
internet-gateway cannot route the packet inside the manet.
- 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 the maintained manet
routes. If there is a manet route, it SHOULD route the
packet along the 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
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 21]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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 [3].
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 22]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
8. 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
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 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,
draft-ietf-manet-dymo-02.txt). Internet Draft, Internet
Engineering Task Force, June 2005.
[2] T. Clausen and P. Jacquet. Optimized Link State Routing
Protocol OLSR. Request for Comments (Experimental) 3561,
Internet Engineering Task Force, October 2003.
[3] 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 18 Jan 2005 [Page 23]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
[4] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6)
Specification. Request for Comments (Proposed Standard) 1883,
Internet Engineering Task Force, December 1995.
[5] 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.
[6] 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.
[7] D. Johnson, C. Perkins, and J. Arkko. Mobility support in
IPv6. Request for Comments (Proposed Standard) 3775, Internet
Engineering Task Force, June 2004.
[8] 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.
[9] R. Ogier, F. Templin, and M. Lewis. Topology Dissemination
Based on Reverse-Path Forwarding (TBRPF) (work in progress,
draft-ietf-manet-tbrpf-11.txt). Internet Draft, Internet
Engineering Task Force, October 2003.
[10] 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.
[11] 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.
[12] 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 18 Jan 2005 [Page 24]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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 18 Jan 2005 [Page 25]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005
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 (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
R. Wakikawa et.al. Expires 18 Jan 2005 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-23 04:27:26 |