One document matched: draft-wakikawa-manet-globalv6-02.txt
Differences from draft-wakikawa-manet-globalv6-01.txt
Mobile Ad Hoc Networking Working Group Ryuji Wakikawa
INTERNET DRAFT Keio University
03 Nov 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-02.txt
Status of This Memo
This document is a submission by 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 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.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page i]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 2
3. Limitations and Assumptions 4
4. Required Operations for Global Connectivity 5
4.1. Node Demands . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Routing Protocol Command Types . . . . . . . . . . . . . 5
4.2.1. AODV6: An Example of a Reactive Protocol . . . . 6
4.2.2. Example of OLSR (Proactive) . . . . . . . . . . . 7
4.3. Message Transport Demands . . . . . . . . . . . . . . . . 7
5. Internet-Gateway Discovery 8
5.1. Internet-Gateway Discovery Processing . . . . . . . . . . 8
5.2. Receiving Internet-Gateway Information . . . . . . . . . 9
5.3. Reactively Soliciting Internet-Gateway Information
(Optional) . . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. Reactive Manet Protocol Based Solicitation . . . 10
5.3.2. NDP based Solicitation . . . . . . . . . . . . . 11
5.4. Advertising Internet-Gateway Information . . . . . . . . 12
5.4.1. Manet Routing Protocol Based Advertisement . . . 13
5.4.2. NDP based Advertisement . . . . . . . . . . . . . 13
5.5. Management of Manet Nodes on Internet-Gateway . . . . . . 14
6. Address Resolution 15
6.1. Address Generation . . . . . . . . . . . . . . . . . . . 15
6.2. Default Route Setting . . . . . . . . . . . . . . . . . . 15
7. Route Examination 16
7.1. Route Examination at Manet Node in Reactive Manet
Protocols . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Route Examination at Internet-Gateway in Reactive Manet
Protocols . . . . . . . . . . . . . . . . . . . . . . 19
8. Error Handling 20
8.1. Receiving ICMPv6 Error Message . . . . . . . . . . . . . 20
8.1.1. ICMPv6 Destination Unreachable Message . . . . . 20
8.1.2. ICMPv6 Redirect message . . . . . . . . . . . . . 20
8.2. MANET Routing Protocol Repair Message . . . . . . . . . . 21
R. Wakikawa et.al. Expires 04 Apr 2003 [Page ii]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
9. Protocol Constants 21
10. Security Considerations 21
Acknowledgments 21
References 21
Appendices 23
A. ICMPv6 and Neighbor Discovery Protocol Extensions for MANET 23
A.1. Modified Router Solicitation . . . . . . . . . . . . . . 23
A.2. Modified Router Advertisement . . . . . . . . . . . . . . 24
A.3. Source Manet Address Option . . . . . . . . . . . . . . . 25
A.4. Changing the ICMPv6 Redirect . . . . . . . . . . . . . . 25
B. Mobile IPv6 Extensions for MANET 26
C. Use of Routing Header for Transmission of Packets along a Default
Route 27
D. AODV6 Operation with Global Connectivity for IPv6 MANET 28
D.1. Additions to AODV6 specification . . . . . . . . . . . . 28
D.2. Global Address Resolution . . . . . . . . . . . . . . . . 29
E. Changes from draft-wakikawa-manet-globalv6-01 31
Authors' Addresses 31
1. Introduction
A mobile ad-hoc network (manet) is built dynamically when a set
of mobile routers create 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 aim to maintain a route to a
destination despite movement of intermediate nodes that causes the
route path to change.
Global connectivity is often required for nodes 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.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 1]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
Two methods for internet gateway discovery are proposed: one method
periodically disseminates gateway advertisements to all nodes in
the manet; the other method utilizes solicitation and advertisement
signaling between a manet node and the gateway. Extended router
solicitation and advertisements of the Neighbor Discovery Protocol
(NDP) [5] or extended control message of each manet protocol can
be used for this signaling. The proposed methods target all manet
protocols regardless of whether they are reactive and proactive.
Internet-gateways have to supply their own global prefix information
and IPv6 global address to manet nodes somehow, either proactively or
reactively. In this way, the reactive and proactive route discovery
features of each manet routing protocol are not disturbed. An
advertisement from the internet-gateway provides prefix information,
and advertisement processing possibly resolves a route to the
gateway, inserted as a default route. A prefix which is distributed
by an internet-gateway can be used for configuring a (typically
globally) routable IPv6 [2] address for each manet node.
If the manet is operating proactively, the gateway periodically
broadcast its own global prefix and any global scope information.
Manet nodes then (proactively) maintain this information. On the
other hand, if the manet is operating reactively, a manet node
initiates a discovery to acquire global prefix and any global scope
information from the gateway. The discovery can be started on demand
when Internet connectivity is required.
After accepting an advertisement from an internet-gateway, the node
configures a routable IP address from the prefix of the gateway
and inserts the gateway address as a default route. Selecting one
of multiple gateways is out of scope of this document, but any
mechanisms for router selection which are proposed at IPv6 working
group at IETF can also be used for this selection [3].
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.
2. Terminology
manet Mobile Ad-Hoc Network
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 2]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
manet node A node located inside a manet
reactive manet protocol
A reactive manet protocol requires manet nodes to
discover or manage routes for destinations on-demand.
Typical reactve manet protocols are Ad-hoc On-demand
Distant Vector (AODV) Routing Protocol [8, 7] and
the Dynamic Source Routing Protocol for Mobile Ad Hoc
Networks (DSR) [1], etc.
proactive manet protocol
Using a proactive manet protocol, manet nodes maintain
routes for destinations all the time. Typical proactive
manet protocols are Optimized Link State Routing
Protocol (OLSR) and Topology Broadcast Based on
Reverse-Path Forwarding (TBRPF), etc.
manet address
A manet node's identity address in manet. The address is
used for ad-hoc routing.
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.
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-gateways multicast address (IGW_MCAST)
Specifically, ALL_MANET_GW_MULTICAST, the IPv6 global
multicast address for all internet-gateways in a manet.
manet network interface
A network interface supporting a link to a manet node.
internet-gateway information
The gateway's IP routing prefix, prefix length, and
lifetime.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 3]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
internet-GateWay Advertisement (GWADV)
A message to advertise internet-gateway information.
There are two types, GWADV_M and GWADV_N:
GWADV_M Extends the manet protocol; a control message is
specified for each particular protocol to advertise
internet-gateway information
GWADV_N Extends NDP to indicate that the advertisement
contains information about the internet-gateway
internet-GateWay Solicitation (GWSOL)
A message to solicit an internet-gateway advertisement.
There are two types, GWSOL_M and GWSOL_N.
GWSOL_M Extends the manet protocol; a control message is
specified for each particular protocol to solicit
internet-gateway information
GWSOL_N Extends NDP to solicit an internet-gateway
Advertisement.
3. Limitations and Assumptions
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 based on 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 [4] home
address. The routable address is used for initial
configuration when a node boots up and joins the manet
(see 6).
Manet routing protocol assumption
This document expects manet routing protocol to have
operations listed in section 4.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 4]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
4. Required Operations for Global Connectivity
This section lists features required by the proposed global
connectivity mechanism. These requirements are separated as follows:
'node demands' operations that the node and its operating system
must provide,
'routing protocol demands' operations required from the routing
protocol, and finally
'message transport demands' communications features that must be
provided.
4.1. Node Demands
The operations below describe basic management of a routing table.
Most routing protocol implementations supply these operations. It is
not necessary to implement or support the exact same functions (i.e.
this is not a specification for an API), but the same operations MUST
be supported by the manet implementation.
ADD_ROUTE(destination_address)
Adding a route for the destination_address into the
node's routing table.
DELETE_ROUTE(destination_address)
Deleting a route for the destination_address from the
node's routing table.
QUERY_ROUTE(destination_address)
Looking up a route for the destination_address from the
node's routing table.
4.2. Routing Protocol Command Types
The Command Types below control a route for some target_address at
one or more other manet nodes, namely the destination given as a
parameter to the command. Most routing protocols support operations
of these types. It is not necessary to implement or support the
exact same functions (i.e. this is not a specification for an API),
but compatible operations MUST be supported by the manet routing
protocol. If destination is a multicast address, then the operation
should be done on all nodes which belong to the multicast group.
REMOVE_ROUTE (destination, target_address)]
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 5]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
requests removing a route to target_address at
destination node(s)
INSERT_ROUTE (destination, target_address)]
requests adding a route to target_address at destination
node(s)
UPDATE_ROUTE (destination, target_address)]
requests updating a route to target_address at
destination node(s)
4.2.1. AODV6: An Example of a Reactive Protocol
ADD_ROUTE, DELETE_ROUTE, and QUERY_ROUTE are operating system's
operations, i.e. they have nothing to do with AODV6. This section
describes how to achieve the routing protocol command types in AODV6.
REMOVE_ROUTE
A node removes a route for a target address after
expiration of the lifetime. The lifetime is notified
with Route Reply (RREP). A node also removes the route
when it receives Route Error (RERR) for the target
address.
INSERT_ROUTE
A sender requests a route for a target address to manet
nodes by sending Route Request (RREQ), and will receive
RREP containing the route for the target address from the
target node or intermediate nodes who know the route for
the target address. AODV6 allows route insertion for
the target address according to the RREP that has been
received.
UPDATE_ROUTE
A node sends RREQ for a target address to manet nodes
again, and receiving RREP containing a fresh route for
the target address. AODV6 allows route updates for
the target address according to the RREP that has been
received.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 6]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
4.2.2. Example of OLSR (Proactive)
ADD_ROUTE, DELETE_ROUTE, and QUERY_ROUTE are, as in AODV6, operating
system functions. This section describes how to achieve the routing
protocol command types in OLSR.
REMOVE_ROUTE
A node removes a route for a target address through
rebuilding topological information with receiving flooded
Topology Control (TC) messages. In proactive manet
protocol, removing route indicates that the target node
is no longer active in manet.
INSERT_ROUTE
A node inserts a route for a target address through
rebuilding topological information with receiving flooded
TC messages. In proactive manet protocol, insert of
route indicates that the target node becomes active newly
active in manet.
UPDATE_ROUTE
A node updates a route for a target address through
rebuilding topological information with receiving flooded
TC messages. When a node detects both 1-hop and 2-hop
neighbors change, the node should update the neighbor
lists and should send HELLO messages if needed.
4.3. Message Transport Demands
The operations below are basic to the communication operation
of internet capable nodes. Most operating systems have these
operations. It is not necessary to implement or support the exact
same functions (i.e. API), but some compatible set of operations
MUST be supported by any platform running a manet routing protocol.
SEND_MESSAGE(dest_address(es), message)
Unicast or multicast a message to a dest_address.
FLOOD_MESSAGE(message)
Flooding a message to manet. Same as SEND_MESSAGE when
the dest_address is ALL_MANET_NODES.
RECEIVE_MESSAGE(source_address, dest_address, message)
Receive a message from a source_address to a
destination_address.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 7]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
5. Internet-Gateway Discovery
This section describes how to discover an internet-gateway in a
manet. Discovery is required to enable manet nodes to obtain a IPv6
global address allocation and set a route towards the Internet. The
discovery is given a different purpose from general route discovery
operation of any manet routing protocols.
5.1. Internet-Gateway Discovery Processing
A node needs a globally routable address in order to be globally
reachable, so that it can receive packets from the Internet. The
node needs to learn its topological location and an address of the
internet-gateway that provided the node with this access to the
Internet. The node therefore needs to somehow 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.
Internet-gateway global address
The internet-gateway IPv6 global address, which can be
used as a default route on manet nodes.
Network prefix address
The network prefix address which internet-gateway
is serving. The prefix MUST be valid address and
topologically correct address on the Internet.
Network prefix length
Prefix length of the network prefix address of an
internet-gateway.
Lifetime
The lifetime of internet-gateway information. After
expiration of the lifetime, a manet node SHOULD get
fresh global information from internet-gateways again.
Otherwise, the internet-gateway information is no
longer valid. Therefore, the node MUST delete own IPv6
global address if the address is generated from the
internet-gateway information.
Internet-gateway's manet address (option)
A manet address which can be used for internal
communication with an internet-gateway.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 8]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
A node discovers an internet-gateway by receiving a message (GWADV)
containing internet-gateway information. An internet-gateway
may distribute internet-gateway information periodically (i.e.
proactively) as part of manet routing protocol or Neighbor Discovery
Protocol (NDP). Periodic advertisements, however, are not typically
used with reactive manet protocols such as AODV [8, 7] and DSR. For
reactive manet protocols, a manet node sends a solicitation message
(GWSOL) of internet-gateway information to internet-gateway(s) when
it needs a route to the Internet, and receives a GWADV containing
internet-gateway information back in response. Otherwise, this
solicitation is an optional operation for proactive internet-gateway
discovery.
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 [6]. This temporary
address (MANET_TEMPORARY_ADDRESS) should be deallocated
after obtaining the globally routable IPv6 address from an
internet-gateway.
5.2. Receiving Internet-Gateway Information
The operation which is discussed in this section is RECEIVE_MESSAGE()
which contains the IP address of the internet-gateway as well as the
internet-gateway information. The internet-gateway information is
wrapped as GWADV_M or GWADV_N.
When a manet node receives GWADV, it starts an address resolution
operation and setting up a route as described in section 6.
Each manet node SHOULD manage internet-gateway information.
Whenever a manet node receives GWADV, it MUST update the related
internet-gateway information. If the lifetime of internet-gateway
information is expired, a manet node SHOULD delete internet-gateway
information. A manet node SHOULD update its internet-gateway
information before expiration of lifetime by receiving GWADV or
soliciting internet-gateway information by GWSOL described in next
section.
5.3. Reactively Soliciting Internet-Gateway Information (Optional)
There are several ways to solicit advertisement of internet-gateway
information (GWADV) from internet-gateways. This document explains
two scheme for soliciting such information.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 9]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
The solicitation can use control messages defined by each reactive
manet protocols as soliciting and advertising internet-gateway
information, because these reactive manet protocols operate
request-reply style transaction for general manet route management.
New control messages/options to handle internet-gateway information
without any obstacles and impacts on existing routing protocol.
Any manet routing protocol may use NDP router solicitation and router
advertisement messages [5] to obtain internet-gateway information.
Link-local address is not an appropriate address scope for multi-hop
networks because IPv6 prohibits forwarding packets sent to an
address of link-local scope. Unfortunately, NDP uses link-local
scoped addresses as IPv6 destination and source address fields for
router advertisement and router solicitation messages. For that
reason, the existing NDP router solicitation and router advertisement
messages cannot be sent over multi-hop networks. Therefore, it is
needed to adapt NDP for use in gateway discovery, but that could
be done with minimum extension. Detailed information can be found
at section A. This mechanism can be applied to any manet routing
protocol regardless of proactive style or reactive style.
5.3.1. Reactive Manet Protocol Based Solicitation
- SEND_MESSAGE (IGW_MCAST, GWSOL_M)
- SEND_MESSAGE (destination_node, GWSOL_M)
A node could rely on control messages of a reactive manet routing
protocol to obtain internet-gateway information from an Internet
Gateway. Most reactive routing protocols send a control message
to find fresh route to a destination when a manet node starts
communication. We call this control message a route request.
To support this method of global connectivity formation, the
route request of each manet protocol should be modified to carry
internet-gateway information. A route request for solicitation is
called GWSOL_M, and a control message (it will call route reply) for
advertisement is GWADV_M, described in section 5.4.1. For these two
messages, handling can be optimized independently within each manet
routing protocol.
The node sends GWSOL_M and receives an internet-gateway information
by GWADV_M in response from the internet-gateway . For instance, the
node propagates a Route Request (RREQ) message as GWSOL_M and waits
for an internet-gateways to return GWADV_M (for instance, Route Reply
(RREP)) containing global information.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 10]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
For modification of route requests, there are several ways to
indicate that the route request is GWSOL_M. A new option or flag can
be added to the control message for solicitation of internet-gateway
information. Such control messages are sent to IGW_MCAST. This kind
of modification is used when a manet node knows that it will need
internet-gateway information before communication. Typical situation
is that a manet node which has not configured any internet setting
yet starts to communicate with a node in the Internet, and it already
knows that the destination node is located in the Internet.
A manet node may not know whether a destination is an Internet node
or not before sending some packets to the destination. For this
situation, the manet node may first send a route request message
to the destination. Typically, an internet-gateway will receive
the message. The internet-gateway can determine whether or not
the destination node is located within manet. If any message
destined to an Internet node is received at an internet-gateway,
the internet-gateway may regard it as internet-gateway information
soliciting message, even if the requesting manet node already knows
internet-gateway information.
If an intermediate node receives any GWSOL_M for address resolution,
it MAY reply with internet-gateway information, if it knows
this information. However, in this case, the intermediate node
SHOULD supply the internet-gateway with information about the
requesting node, perhaps by using a gratuitous RREP sent to the
internet-gateway. If it is not possible to send the gratuitous RREP,
the intermediate node MUST NOT replay to the the solicitation.
5.3.2. NDP based Solicitation
This section describes the operation of a manet node enabling it
to send a solicitation message to the internet-gateways that are
available (SEND_MESSAGE(IGW_MCAST, GWSOL_N)). Extensions to NDP are
described in section A.
A manet node requests GWADV_N with by sending GWSOL_N to IGW_MCAST.
GWSOL_N is a router solicitation message extended to solicit
internet-gateway information on a manet. The node MAY use an
expanding ring search technique to broadcast GWSOL_N using
appropriate Hop Limit values.
A receiving node MUST be a member of IGW_MCAST group if it is an
internet-gateway. If the receiving node is an internet-gateway, it
replies with GWADV_N specifying its global prefix information and
internet-gateway address. Otherwise, the node just propagates the
manet router advertisement message if the hop-limit allows this.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 11]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
If an intermediate node receives any GWSOL_N for address resolution,
it MAY reply with internet-gateway information, if it knows
this information. However, in this case, the intermediate node
SHOULD supply the internet-gateway with information about the
requesting node, perhaps by using a gratuitous RREP sent to the
internet-gateway. If it is not possible to send the gratuitous RREP,
the intermediate node MUST NOT replay to the the solicitation.
It depends on the behavior of the manet routing protocol whether
it can use IGW_MCAST as the broadcast address in a manet. If the
receiving node is not an internet-gateway and hop-limit has not been
reached, the node propagates GWSOL_N ahead towards nodes having
IGW_MCAST.
5.4. Advertising Internet-Gateway Information
An internet-gateway MAY advertise internet-gateway information
periodically by sending GWADV. The propagation of the GWADV depends
on the manet routing protocol. This draft extends two types of
message, which are a manet control message and router advertisement
of NDP.
If a manet protocol permits to a manet node's soliciting
internet-gateway information, below algorithm SHOULD be applied.
This algorithm is commonly useful regardless of types of message.
if (RECEIVE_MESSAGE(requesting node, IGW_MCAST, GWSOL)) {
SEND_MESSAGE(requesting node, GWADV);
} else if (RECEIVE_MESSAGE(requesting node,
internet node's address, GWSOL_M)) {
route := QUERY_ROUTE(internet node's address);
if (route == null && route != default route)
SEND_MESSAGE(requesting node, GWADV);
}
First if an internet-gateway receives any GWSOL(s) which destined
to IGW_MCAST, the internet-gateway MUST return own internet-gateway
information to the requesting node.
If an internet-gateway receives GWSOL_M which destined to an
internet node's address, it MUST search the target address in own
routing table. If it found a route for the target address, it
MUST NOT return internet-gateway information. Instead, it MAY
return the route for the target address as part of general route
discovery mechanism, because GWSOL_M is requesting the route for the
target address as well. This is because GWSOL_M is an extending
control message of each manet routing protocol for route discovery.
If it does not find any route for the target, it SHOULD return
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 12]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
internet-gateway information as GWADV_M. If the route for the target
address can not be found in internet-gateway's routing table, it
indicates the target node non-exists in the manet, but exists in the
Internet.
5.4.1. Manet Routing Protocol Based Advertisement
This section describes the following two operations of a manet node.
- SEND_MESSAGE(requesting node, GWADV_M)
- FLOOD_MESSAGE(manet nodes, GWADV_M)
This section describes the first way which internet-gateway
information is piggy-backed somehow into control messages of each
manet protocols as GWADV_M by the below operation. It depends on
manet protocol how to piggy-back internet-gateway information into
control messages. Control messages are expected to reach all nodes
inside manet. For a reactive protocol, it may be route reply/notify
message. For a proactive protocol, it should be any periodically
flooded message. Any flooding mechanisms are allowed to disseminate
the GWADV. Optimized flooding mechanism such as Multipoint Relays
(MPR) is recommended.
An internet-gateway also generates GWADV_M whenever it receives
GWSOL_M described in section 5.3. There are two types of GWSOL_M.
If the internet-gateway receives GWSOL_M which is sent to IGW_MCAST,
it MUST unicast back its internet-gateway information by GWADV. The
internet-gateway SHOULD also include the lifetime GWINFO_LIFETIME
into its internet-gateway information.
If a target address of the route request is another global address
than IGW_MCAST, it searches the address in its routing table. If an
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 GWADV.
5.4.2. NDP based Advertisement
This section describes the following two operations of a manet node.
Extensions of NDP is described in section A.
- SEND_MESSAGE(requesting node, GWADV_N)
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 13]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
- FLOOD_MESSAGE(manet nodes, GWADV_N)
This section describes another way which internet-gateway information
is contained into a router advertisement message of NDP (GWADV_N).
GWADV_N is expected to reach all nodes inside manet. Any flooding
mechanisms are allowed to disseminate the GWADV_N. Since most routing
protocols has a message flooding scheme for message passing among
manet nodes, GWADV_N can be conveyed by the message flooding scheme.
However, optimized flooding mechanism such as Multipoint Relays (MPR)
is recommended.
For a reactive protocol, an internet-gateway generates GWADV_N
only when it receives GWSOL_N described in section 5.3. Then, the
internet-gateway SHOULD send GWADV_N to the requesting node by
unicasting, but it MAY broadcast GWADV_N whenever it receives request
of GWADV_N.
For a proactive protocol, GWADV_N SHOULD be disseminated periodically
by an internet-gateway irrespective of receiving GWSOL_N.
5.5. Management of Manet Nodes on Internet-Gateway
An internet-gateway needs to known all manet nodes which are
located in the internet-gateway managing manet. This manet nodes'
information is used when internet-gateway determines a route for
incoming packets described in section 7.
For proactive manet protocols, an internet-gateway manages a route
for all manet nodes by each manet routing protocol. Therefore, an
internet-gateway can know whether a node locates inside manet or not,
as soon as it checks its routing table. The management of fresh
routes for all manet nodes is a basic operation of each proactive
manet protocol.
Reactive manet protocols do not tell routes of all manet nodes
to internet-gateway. An internet-gateway MUST know all manet
nodes somehow and manage these information. One approach is that
an internet-gateway records a manet node information whenever
the manet node solicits internet-gateway information to the
internet-gateway. The manet node information can be recorded into
either internet-gateway's routing table or new database for this
purpose. This approach can be applied to most of reactive manet
protocol, but any mechanism can be selected to know all manet nodes
information.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 14]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
6. Address Resolution
6.1. Address Generation
After the initial information has been received from the
internet-gateway(s), following the procedure described above, a
node should know the global prefix of the manet and the address of
the related internet-gateways(s). First, the node SHOULD generate
a global IPv6 address by using the global prefix information. The
node SHOULD use its 64-bit interface ID in order to construct a
valid address with the acquired prefix. Since the node is assumed
to already have 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 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.
temporary_addr := MANET_TEMPORARY_ADDRESS;
new_addr := generate_globaladdr(internet-gateway information);
if (new_addr == null) {
/* internet-gateway discovery again */
} else { /* ASSERT DAD if needed */
ADD_ROUTE (new_addr);
#ifdef PROTOCOL IS PROACTIVE /* Not needed for reactive */
INSERT_ROUTE (ALL_MANET_NODES, new_addr);
#endif /* PROTOCOL IS PROACTIVE */
if (temporary_addr) {
DELETE_ROUTE (temporary_addr);
REMOVE_ROUTE (ALL_MANET_NODES, temporary_addr);
}
6.2. Default Route Setting
In the routing table, the node SHOULD set the following routes. We
assume the global prefix is exclusively on the manet side.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 15]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
Destination/prefix length Next-Hop
--------------------------- -----------------------------
Default Route/0
<Default> <internet-gateway address>
Host Route/128
*<internet-gateway address> <next-hop address>
* The host route is set accoding to each manet routing protocol
These routing entries should be held until expiration of the lifetime
which the internet-gateway provides either with GWADV or in the reply
to GWSOL. Lifetime of the default route entry and the global prefix
information is stored in either GWADV_M or GWADV_N which are sent by
internet-gateways. During active lifetime, the receiving node can
use the global prefix and the internet-gateway as the default route
entry.
During use of the internet-gateway as a route path for
communications, the node SHOULD update internet-gateway
information according to periodically advertised fresh GWADV.
On the other hand, the node MAY keep re-requesting internet-gateway
information to the internet-gateway before the lifetime is expired
on reactive manet protocol. This refreshment SHOULD be done at
GWINFO_REFRESH periods for reactive manet protocol. The node can
unicast GWSOL to the respective internet-gateway, or alternatively it
can broadcast GWSOL to all over the manet 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.
Some proactive manet protocols MAY have an additional routing entry
for global prefix (i.e. a network route). This is a optional entry.
Manet nodes treat the network route as same as a default route. If
the default route is deleted due to expiration of lifetime, the
network route MUST be deleted, too.
7. Route Examination
A manet node and an internet-gateway SHOULD examine a route for
packets sent from a manet node to an internet node, and vice versa.
Otherwise, all the packets may be routed to an internet-gateway by a
receiving manet node, because a default route is selected as a route
for the packets which destination is unknown for the manet node.
Route examination gives a mechanism to distinguish packets destined
to a manet node and packets destined to an internet node. After
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 16]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
distinguishment, a manet node and an internet-gateway decide either
the use of default route or an active host route for a destination.
For proactive manet protocols, each manet node and internet-gateways
maintain all the host routes for manet nodes in the manet and a
network route of the network prefix for the manet. It means that
manet nodes and internet-gateways need not operate any special
examinations, but they just follow general approach of route
reference for a destination. In general, a manet node first examines
a host route for a destination. If there is a match, a packet is
sent to the destination according to the host route. If there are no
host routes, but destination's prefix is equal to the network prefix
of the manet, the packet is just transmitted on the local manet
interface as if the node was a neighbor. Only if that rule does not
match, the default route is finally employed.
Route examination is specially important for reactive manet
protocols. Reactive protocols MUST discover a host route for a
destination whenever it communicates with some manet nodes, because
reactive manet protocols do not maintain all the host routes for
manet nodes in manet. In addition, an internet-gateway in reactive
manet protocols gives route/topological repair for a destination to a
sender by ICMP error message or any control messages of manet routing
protocols. Following sections describe how reactive manet protocols
can operate route examinations.
7.1. Route Examination at Manet Node in Reactive Manet Protocols
For reactive manet protocols, each manet nodes including
internet-gateways do not know all the host routes for manet nodes in
the manet. They MUST discover a host route for a destination as soon
as they start to communicate with the destination.
Therefore, whenever a node needs to send a packet it uses the
following routing algorithm:
- The node looks up its routing table for the destination node. If
found it sends the packet towards the destination.
- If not, the node MAY request a route 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 obtains a default
route as described in either section 5 or section 6.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 17]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
3. If the node does not get the route, 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 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 MAY send a route
request for the destination of the outgoing data packet using its
manet routing protocol. This operation is requested for reactive
manet protocols, but it is not really needed for proactive manet
protocols. If a default route exists, the node MAY wait for the
route discovery. If no such discovery 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
the route, 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, since some manet protocol (ex. DSR)
does not support next hop forwarding, a routing header MAY 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 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 C.
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 default
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 18]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
route as a next hop of the destination node . The routing table of
the node SHOULD be configured for the destination as shown below:
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> or
<internet-gateway address>
* The host route is set accoding 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.
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.
7.2. Route Examination at Internet-Gateway in Reactive Manet Protocols
An internet-gateway SHOULD have host 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 a host route
between the source and the destination node. The internet-gateway
sends a kind of route error messages to notify a sender node to retry
discovery a route for the destination in order to obtain the host
route instead of the default route. If the sender node believes the
internet-gateway is next to the destination node, it SHOULD ignore
the route error messages, and SHOULD not re-discover the host 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.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 19]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
Management of the host routes are basically operated by each manet
routing protocols. But internet-gateway can also learn the host
routes when it receives any GWSOL from manet nodes. For these host
routes, the internet-gateway discards the host routes, if it does not
get any GWSOL before the lifetime of the host route is expired.
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.
8. Error Handling
8.1. Receiving ICMPv6 Error Message
A manet node usually receives two types of ICMPv6 messages from
internet-gateways, 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.1.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
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.
8.1.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
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 20]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
its method of learning a manet destination, e.g., by sending a route
requests for the destination.
8.2. MANET Routing Protocol Repair Message
The manet node MUST process the control message according to the
original manet routing protocol. If manet is operated by a reactive
manet protocol, a manet node would often receive a control message of
each manet routing protocol to repair a route to a destination due to
the change of network topology.
9. 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
10. 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 also thank
Thierry Ernst for his comments. The authors thank Thomas Clausen for
his many improvements having to do with proactive routing protocols.
References
[1] J. Broch, D. Johnson, and D. Maltz. The dynamic source routing
protocol for mobile ad hoc networks (work in progress). Internet
Draft, Internet Engineering Task Force, February 2002.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 21]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
[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] R. Draves and R. Hinden. Default router preferences,
more-specific routes, and load sharing. (work in progress).
Internet Draft, Internet Engineering Task Force, June 2002.
[4] D. Johnson and C. Perkins. Mobility support in IPv6 (work in
progress). Internet Draft, Internet Engineering Task Force,
March 2001.
[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. Belding-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 2001.
[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, July 2002.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 22]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
A. ICMPv6 and Neighbor Discovery Protocol Extensions for MANET
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 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.
A.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 MAY 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
broadcasting/flooding scheme such as an expanding ring search
technique.
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 nodes on the 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.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 23]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
Reserved
Reduced from a 32-bit field to a 31-bit field to account
for the addition of the Manet Router Solicitation (M)
flag.
Options: Source Manet address
The Manet global address of the sender. This SHOULD be
included even if the Source Address is the temporary
address generated with MANET_INITIAL_PREFIX.
A.2. Modified Router Advertisement
An internet-gateway sends out a Manet Router Advertisement message
either periodically or response to a Manet Router Solicitation.
The internet-gateway allows to send unsolicited Manet Router
Advertisements, although 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 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.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 24]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
A.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
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 such as AODV, this option can indicate the
exact sender Manet address to receivers.
These options MUST be silently ignored for other Neighbor Discovery
messages.
A.4. Changing the ICMPv6 Redirect
An internet-gateway and manet nodes basically obey [5] except for
below changes.
In [5], gateway can specify only link-local address in a
source address field of IPv6 header. In manet situation, an
internet-gateway is allowed to specify manet global addressor global
address in a source and destination address fields of an IPv6 header.
An ICMPv6 Redirect message [5] sent to a Manet node MAY 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 notify a sending node that a destination is
located on this manet and instead should send packets to it using
ordinary manet routing.
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 25]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
B. Mobile IPv6 Extensions for 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 Mobile IPv6 Correspondent Node
(CN) requirements describe in [4], 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
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 26]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
home address option. If the node is a CN, the possible routing
header injected by Mobile IPv6 is modified by inserting the entry for
gateway prior to the entry for home address, and setting the segments
left to two.
C. Use of Routing Header for Transmission of Packets along a Default
Route
As described in section 7.1, 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 supports 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 explicitly routed through
the internet-gateway. If the internet-gateway detects that the
destination is located within the Manet, the internet gateway can
send an ICMPv6 Redirect error message to the sender. After receiving
the 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 04 Apr 2003 [Page 27]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
D. AODV6 Operation with Global Connectivity for IPv6 MANET
This section describes how to apply embedding of the Internet
connectivity acquisition to a reactive 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.
D.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 04 Apr 2003 [Page 28]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 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.
D.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
IGW_MCAST.
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 IGW_MCAST 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 u it to
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 29]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
the requesting node. The IPv6 header fields should be built as in
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 7.1 and appendix C.
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 04 Apr 2003 [Page 30]
Internet Draft Global Connectivity for IPv6 Manets 03 Nov 2002
E. Changes from draft-wakikawa-manet-globalv6-01
- many many
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: 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
E: ajtuomin@tml.hut.fi
Fax: +358 9
R. Wakikawa et.al. Expires 04 Apr 2003 [Page 31]
| PAFTECH AB 2003-2026 | 2026-04-22 06:01:19 |