8/3/2019 Draft Wakikawa Manet Globalv6 01
1/27
Mobile Ad Hoc Networking Working Group Ryuji Wakikawa
INTERNET DRAFT Keio University
01 July 2002 Jari T. Malinen
Charles E. Perkins
Nokia Research Center
Anders Nilsson
University of Lund
Antti J. Tuominen
Helsinki University of Technology
Global connectivity for IPv6 Mobile Ad Hoc Networks
draft-wakikawa-manet-globalv6-01.txt
Status of This Memo
This document is a submission to the Mobile Ad Hoc Networking Working
Group of the Internet Engineering Task Force (IETF). Comments should besubmitted to the [email protected] mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
This document describes how to provide Internet connectivity with
mobile ad-hoc networks. It describes how to obtain a globally routable
address , Manet node operation, and Internet-gateway operation. Once
a Manet node obtains a global address from an Internet-gateway,it can start to send data to the Internet. Data goes through the
Internet-gateway with a routing header specifying the gateway. This
connectivity method is not dependent on a particular Manet protocol.
Further, use of global connectivity with Mobile IPv6 is specified.
R. Wakikawa et.al. Expires 01 Jan 2003 [Page i]
8/3/2019 Draft Wakikawa Manet Globalv6 01
2/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 2
3. Overview 2
4. Limitations and Assumptions 3
5. Changing Route Request of each Manet Protocol 4
6. Changed Neighbor Discovery Protocol Packet Formats for Address
Resolution 4
6.1. Modified Router Solicitation . . . . . . . . . . . . . . 5
6.2. Modified Router Advertisement . . . . . . . . . . . . . . 6
6.3. Source Manet Address Option . . . . . . . . . . . . . . . 6
7. Changing the Operation of the ICMPv6 Redirect 7
8. Manet Node Operation 7
8.1. Sending a Global Address Resolution Request . . . . . . . 7
8.1.1. Sending Manet Protocol Route Request . . . . . . 8
8.1.2. Sending Manet Router Solicitation . . . . . . . . 8
8.2. Receiving Global Address Resolution Reply fromInternet-Gateway . . . . . . . . . . . . . . . . . . . . . 9
8.3. Sending a Packet to an Internet Node . . . . . . . . . . 10
8.4. Receiving ICMPv6 Error Message . . . . . . . . . . . . . 12
8.4.1. ICMPv6 Destination Unreachable Message . . . . . 12
8.4.2. ICMPv6 Redirect message . . . . . . . . . . . . . 12
9. Internet-gateway Operation 12
9.1. Route Examination during communication . . . . . . . . . 12
9.2. Receiving Route Request for a Global Destination Address 13
9.3. Receiving Manet Router Solicitation . . . . . . . . . . . 13
9.4. Forwarding Packets in the Internet-gateway . . . . . . . 13
10. Intermediate Node Operation 14
11. Sending Packet to the Manet from the Internet 14
12. Protocol Constants 14
R. Wakikawa et.al. Expires 01 Jan 2003 [Page ii]
8/3/2019 Draft Wakikawa Manet Globalv6 01
3/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
13. Security Considerations 14
Acknowledgments 15
References 15
Appendices 16
A. Use of Routing header for transmission of packets along a default
route 16
B. AODV6 Operation with Global Connectivity for IPv6 Manet 17
B.1. Additions to AODV6 specification . . . . . . . . . . . . 17
B.2. Global Address Resolution . . . . . . . . . . . . . . . . 18
C. DSR Operation with Global Connectivity for IPv6 Manet 20C.1. Additions to DSR specification . . . . . . . . . . . . . 20
C.2. Global Address Resolution . . . . . . . . . . . . . . . . 20
C.3. Communication to the Internet . . . . . . . . . . . . . . 21
D. Mobile IPv6 Operation with Global Connectivity for IPv6 Manet 23
E. Changes from draft-wakikawa-manet-globalv6-00 25
Authors Addresses 25
1. Introduction
A mobile ad-hoc network (Manet) is created dynamically when a setof mobile routers form a mesh routing state for their connectivity
management, typically over a wireless network. Many routing protocols
have been proposed for routing within Manets by the IETF MANET working
group. These protocols aims to maintain a route to a destination
despite movement of intermediate nodes that causes the route path to
change.
Global connectivity is required for nodes desiring communication with
the fixed Internet. However, routing protocols for Manet typically only
maintain routes local within the reach of a Manet running the given
protocol.
This document specifies a method for obtaining global connectivityto the Internet and how Manet routing protocols can contribute to this.
The method is used for acquiring a global address from a gateway and to
communicate over the gateway.
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 1]
8/3/2019 Draft Wakikawa Manet Globalv6 01
4/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
2. Terminology
Manet
Mobile Ad-Hoc Network
Internet-gateway
Gateway that provides the Internet connectivity for nodes in
the Manet. This router should be placed at the edge of Manet
and have connection to both the Internet and the Manet.
Manet Address
Manet nodes identity address in Manet. The address is used
for ad-hoc routing.
INTERNET_GATEWAYS multicast address
Multicast address for all Internet-gateways in a Manet. The
address is defined as ALL_MANET_GW_MULTICAST
Manet network interface
A network interface connected to the Manet in an
Internet-gateway or in a regular Manet node.
Manet Router Solicitation
A router solicitation message modified for Manet operation.
Manet Router Advertisement
A router advertisement message modified for Manet operation.
3. Overview
This document proposes two methods for discovering Internet-gateways.
One method is to extend the route discovery messaging of an on-demand
routing protocol. Another is to use extended router solicitation and
advertisements of the Neighbor Discovery Protocol (NDP) [5]. This
document also illustrates how to apply the first method to an existingManet protocol using the Ad-hoc On-demand Distant Vector (AODV) Routing
Protocol [8, 7] as an example.
Whenever a node boots up in the Manet and needs to communicate over
the Internet, the node discovers an Internet-gateway to get its global
prefix information. The node may discover the gateway pro-actively
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 2]
8/3/2019 Draft Wakikawa Manet Globalv6 01
5/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
after boot-up before it needs to communicate over the Internet, or
it may postpone this discovery to take place on demand when it needs
to communicate over the Internet. A prefix which is distributed byInternet-gateway is used for configuring a routable IPv6 [2] address
for the node. The discovery can also be used for learning addresses of
Internet-gateways for setting up routes to the Internet through them.
Internet-gateways SHOULD reply to a request with their own global
prefix information and IPv6 address. A reply from the gateway provides
prefix information and possibly a route to the gateway, inserted as
a default route. If there are more than one Internet-gateways and
intermediate nodes replying to the request, the requesting node can only
obtain gateway information known to the intermediate nodes and miss the
rest of the information, because intermediate nodes may not have all
Internet-gateways information.
After obtaining the information from Internet-gateways, the node
configures a routable IP address from a prefix of a selected gateway
and inserts the gateway address as a default route. Selection of the
gateway is out of scope of this document.
If the node sends packets to the Internet, the node SHOULD use a
routing header to route packets through its Internet-gateway. If
a packet is destined to the Internet-gateway first, intermediate
nodes just forward packets to the same Internet-gateway and the
Internet-gateway can then route the packet to its destination.
Otherwise, each intermediate nodes need to discover the route to the
destination address of the packets IP header to route packets and each
of them send the packet towards their Internet-gateway.
Each Internet-gateway monitors any packet received from the Manet to
prevent unnecessary packets from being forwarded to the Internet side
and to know how to react to signaling. The destination of such a packet
passing through the Internet-gateway with routing header is checked
on the Internet-gateway. If the destination is inside the Manet, the
Internet-gateway notifies the sender to change its route to a more
optimal one, a direct route into the Manet. The node then receives a
notification and sends a route request to discover the direct route to
the destination.
4. Limitations and Assumptions
For simplicity, we make the following assumptions in our draft:
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 3]
8/3/2019 Draft Wakikawa Manet Globalv6 01
6/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
Address Family
This document assumes IPv6 address family support. The Manetrouting protocol discussed in this document MUST be capable of
supporting IPv6 routes.
Topological assumption
At least one Internet-gateway is at the edge of the Manet.
Address assumption
All nodes in Manet have a global address, routable or not with
the Internet, for instance a Mobile IPv6 [4] home address.
The global address is used for initial configuration when a
node boots up and joins the Manet. If the node does not haveany global address at its network interfaces the node should
temporarily configure an address from the MANET_INITIAL_PREFIX
as described in the IP Address Autoconfiguration for Ad Hoc
Networks [6]
5. Changing Route Request of each Manet Protocol
To support this method of global connectivity formation, route
request and reply messages of each Manet protocol should be modified to
carry global prefix information and the gateways IPv6 address.
When a node requests global information to Internet-gateways,
the node broadcasts a route request to the INTERNET_GATEWAYS globalmulticast address.
Once an Internet-gateway receives the request, it MUST reply with
both the global prefix and its Internet-gateway address to this. Each
Manet routing protocol need to support some scheme for route reply
to distinguish whether the route reply carries the Internet-gateway
information and address. For example, each Manet route reply message
should have a flag which indicates an Internet-gateway information is
included in the reply.
6. Changed Neighbor Discovery Protocol Packet Formats for Address
Resolution
This section describes how to handle NDP packets to sent out over
multi-hop networks such as the Manet.
Both router solicitation and router advertisement messages can not be
sent over multi-hop networks, because the link-local scope is not well
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 4]
8/3/2019 Draft Wakikawa Manet Globalv6 01
7/27
8/3/2019 Draft Wakikawa Manet Globalv6 01
8/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
6.2. Modified Router Advertisement
An Internet-gateway sends out a Manet Router Advertisement messageresponse to a Manet Router Solicitation. The Internet-gateway SHOULD
NOT send unsolicited Manet Router Advertisements. Sending them
periodically would generate unnecessary packets in the Manet. The
modified Manet Router Advertisement MUST have the N flag set. The
Hop Limit field in the IPv6 header SHOULD be set to an appropriate
value if the expanding ring search algorithm in Manet Broadcasting is
used. The N flag MUST be set in the Manet Router Advertisements and
it MUST carry the address of the Internet-gateway and the global prefix
information by the Prefix Information Option [5, 4].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|N|Reserved | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Manet Router Advertisement Flag (N)
1-bit Manet Router Advertisement flag. When set,
indicates that the Router Advertisement message is onlyfor Manet nodes and can be sent over multiple hop Manet
nodes. The Internet-gateways MUST NOT forward this
message to the Internet. Whenever the flag is set, the
sender MUST include a Prefix Information option with a
globally routable prefix. A Source Manet Address option
may be required, depending on the Manet protocol.
6.3. Source Manet Address Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Length | Manet Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 10
Length 3
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 6]
8/3/2019 Draft Wakikawa Manet Globalv6 01
9/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
The length of the option (including the type and length
fields) in units of 8 octets.
Manet Address
The 128 bit IPv6 address for the original source of the
packet.
The Source Manet Address option contains the Manet address of the
sender of the packet. It is used in Manet Router Solicitation, and
Manet Router Advertisement packets. Since the source address field in
the IPv6 header might be changed by intermediate nodes running a Manet
routing protocol (i.e. AODV), this option can indicate the exact sender
Manet address to receivers.
These options MUST be silently ignored for other Neighbor Discovery
messages.
7. Changing the Operation of the ICMPv6 Redirect
An ICMPv6 [1] Redirect message sent to a Manet node MUST include the
Source Manet address option and is used to notify that this destination
address is located on this MANET. It is used by the Internet Gateway to
novity a sending node that a destination is located on this MANET and
instead should send packets to it using ordinary MANET routing.
8. Manet Node Operation
8.1. Sending a Global Address Resolution Request
A node needs a globally routable address in order to be globally
reachable and receive packets from the Internet. The node also needs to
learn the location and address of the gateway that provide the node with
this access to the Internet.
The node therefore needs to somehow obtain a global prefix owned
and distributed by an Internet-gateway. One way of obtaining this
information is by relying on advertisements distributed by the Internet
Gateway as part of its Neighbor Discovery Protocol. A Manet Node could
then send a Manet Router Solicitation for an Internet Gateway and
receive a Manet Router Advertisement back in response from the Internet
Gateway.
In some cases, as mentioned above, the Internet Gateway might not be
able to distribute the router advertisement through the Manet, because
of link-local scope being not well defined in the Manet.
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 7]
8/3/2019 Draft Wakikawa Manet Globalv6 01
10/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
We will in this document describe three ways for requesting global
routing information from an Internet Gateway:
- sending Manet route request for a global destination address
- sending Manet route request to the INTERNET_GATEWAYS multicast
address
- sending Manet Router Solicitation
The IPv6 address used during any of these operations could be
any arbitrary global-scope address, for example a Mobile IPv6 home
address. If no such address is available ,the node SHOULD create
a temporary global-scope address, generated from the well-known
MANET_INITIAL_PREFIX [6]. This temporary address should be
deleted after obtaining the globally routable IPv6 address from anInternet-gateway.
8.1.1. Sending Manet Protocol Route Request
A node could rely route request and route reply messages of an
on-demand manet routing protocol to obtain the global prefix and address
of an Internet Gateway. The node sends a modified route request and
receives a modified route reply in response from the Internet Gateway.
For instance, the node propagates a Route Request (RREQ) message using
AODV and waits for an Internet Gateways to return a reply, such as an
AODV Route Reply (RREP).
The address which we here request a route for in the route requestmessages could either be the INTERNET_GATEWAYS global multicast address
or the global address of a destination node located on the Internet with
whom we would like to communicate with. Both addresses would in this
case indicate that we request a reply message specifying a global prefix
and Internet Gateway address.
8.1.2. Sending Manet Router Solicitation
A node can request a Manet Router Advertisement by an Internet
Gateway by sending a Manet Router Solicitation to the INTERNET_GATEWAYS
multicast address. The node MAY use an expanding ring search technique
to broadcast the Router Solicitation message using appropriate Hop Limitvalues.
A receiving node MUST be a member of the INTERNET_GATEWAYS group if
it is an Internet Gateway and it SHOULD be a member if it is an ordinary
non Gateway Manet node. If the receiving node is a Gateway, it replies
with a Manet Router Advertisement message specifying its global prefix
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 8]
8/3/2019 Draft Wakikawa Manet Globalv6 01
11/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
information and Internet Gateway address. Otherwise, the node just
propagates the Manet Router Advertisement message if the hop-limit
allows this.
In the latter case, intermediate nodes SHOULD not process this
packet, but just forward it. However, Manet protocols need to setup a
reverse route in order to propagate the response back. In such a case,
mere forwarding of the packet will not introduce this reverse route and
a response from an Internet Gateway will cause a search for the reverse
route, e.g., in AODV6.
It totally depends on the behavior of the MANET routing protocol
whether it can use the INTERNET_GATEWAYS multicast address as the
broadcast address in a MANET. If the receiving node is not an Internet
Gateway and hop-limit allows it, the node MUST propagate the request
ahead towards the INTERNET_GATEWAYS address.
8.2. Receiving Global Address Resolution Reply from Internet-Gateway
After either of the above operations have taken place,the node should
know a global prefix and the address of its related Internet Gateway.
First, the node should generate a global IPv6 address by using the
global prefix information. The node SHOULD use its 64-bit interface ID.
Since the node assumingly has already done Duplicate Address Detection
(DAD), as defined in [6], for the link-local address before setting
up the global address, a global address with host number from this
link-local address is also unique if this rule is followed. If not, the
node MAY perform another DAD for this global address. If the node used
a temporary address generated by MANET_INITIAL_PREFIX when requestingglobal information, this address SHOULD now be deleted. Further,
all the host routes for this temporary address SHOULD be deleted in
intermediate nodes and Internet-gateway. This is achieved by using
some route maintenance operation defined in MANET routing protocol, for
example, the Route Error (RERR) message used AODV6. It MAY be left to
be deleted by timeouts.
In the routing table, the node should set the following two routes.
We assume the global prefix is exclusively on the Manet side.
Destination/prefix length Next-Hop
--------------------------- -----------------------------
Default Route/0
Host Route/128
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 9]
8/3/2019 Draft Wakikawa Manet Globalv6 01
12/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
These routing entries should be held until expiration of the lifetime
which the Internet-gateway provides in the reply to the global address
resolution request. Lifetime of default route entry and global prefixinformation is stored in either route reply or route advertisement
messages which are sent by Internet Gateway. During active lifetime,
the receiving node can use the global prefix and the Internet Gateway
as default route entry. The Internet Gateway MUST hold or acquire the
reverse route to the requesting node before expiration of the lifetime.
During use of the Internet-gateway as a route path for communications,
the node MUST keep re-requesting global prefix information to the
Internet-gateway before the lifetime is expired. This refreshment
SHOULD be done at GWINFO_REFRESH periods. The node can unicast the
request to the respective Internet-gateway, or alternatively it can
broadcast the request to all over the Manet network again. The former
method can allow the Manet node to update the current Internet-gateway
status, the latter method enables the Manet node to quickly discover allpossible Internet-gateways in the Manet.
8.3. Sending a Packet to an Internet Node
Whenever a node needs to send a packet it uses the following routing
algorithm:
- The node looks up its routing table for the destination node. If
found it sends the packet towards the destination.
- If not, the node sends a route request for the destination node.
1. If a default route exists, the node MAY wait for the aboveroute request.
2. If a default route doesnt exist, the node uses one of the
two methods to obtain a default route.
3. If the node does not receive any route reply, the node sets
an route entry into the routing table with the destination
node pointing towards the default route. Then the node uses
the route to transmit the packet through the default route.
- If the node gets a route reply for the destination, it sets a
host route for the destination, and sends packets according to
this route.
First, a node looks up a route for the destination of a packet from
its routing table. If the node finds a host route, it sends the packet
to its destination. Otherwise, the node SHOULD send a route request
for the destination of the outgoing data packet using its Manet routing
protocol. Then, if a default route exists, the node MAY wait for
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 10]
8/3/2019 Draft Wakikawa Manet Globalv6 01
13/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
the above route request. If no such request is pending and the node
doesnt have default route, it uses one of the methods described in this
document to obtain a default route.
If the node requested a route for the destination but does not get
route replies, the node assumes the destination node is located on the
internet and sends the packet using the default route. Sending packets
towards the default route is operated by each base manet protocol. Here
it depends on whether packet forwarding associated with the used manet
protocol supports next hop forwarding or not. If that is the case, each
intermediate node could independently decide the best route for packet
out of the Manet, and towards the destination. The node does not need
to take care of the explicit route to the Internet-gateway. However,
some manet protocol (ex. DSR) does not support next hop forwarding,
routing header SHOULD be used specifying the Internet-gateways address
as an intermediate routing point towards the destination.
The use of routing header also provides optimization and control for
forwarding packet to Internet-gateway. Each intermediate node does
not need to decide the best route for packet (i.e. default route or
host route if it is available), instead it simply uses a host route
of the Internet-gateway to forward packet to the Internet-gateway.
Control of forwarding route path can be relevant approach when multiple
Internet-gateways are placed in a manet. The minute details are
described in appendix A.
The node SHOULD know whether a route request was earlier sent for
a destination whose route lookup found the default route. To prevent
repeated route requests for packets destined to the destination, the
node MUST put an route entry for the destination with the default routeas a next hop of the destination node . The routing table of the node
SHOULD be configured for the destination as below entries.
Destination/prefix length Next-Hop
--------------------------- -----------------------------
Default Route/0
Host Route/128
The node MUST send at least one route request for such a destinationbefore sending data packets, even if it has already had a default route
in its routing table. If the routing protocol is using an expanding
ring search, care should be taken so as not to let this affect the
delay too much. If the ring is expanded too far, unnecessary delay is
introduced. Simulations have shown that one route request is optimal in
most cases.
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 11]
8/3/2019 Draft Wakikawa Manet Globalv6 01
14/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
If the node gets a route reply, the node assumes the node is located
within the ad hoc network, sets a host route for the destination, and
sends packets normally according to this host route.
8.4. Receiving ICMPv6 Error Message
A Manet node usually receives two types of ICMPv6 messages, the
ICMPv6 Destination Unreachable Message and the ICMPv6 Redirect message.
These messages are propagated over the Manet and their use is the same
as for any other IP network.
8.4.1. ICMPv6 Destination Unreachable Message
If a Manet node receives an ICMPv6 Destination Unreachable messageafter sending data packets using a host route, the node MUST delete
this entry in the routing table. If needed, the node can rediscover a
route for the destination by sending a route request again. This exact
behavior depends on the Manet routing protocol in use.
If the Manet node receives ICMPv6 Destination Unreachable messages
after sending data packets to a destination using a default route entry,
the node can send a single route request for the destination again. If
the node does not receive any route reply, the node SHOULD NOT send any
packets including route requests for the destination for a while.
8.4.2. ICMPv6 Redirect message
If the Manet node receives an ICMPv6 Redirect message from an
Internet-gateway, the Manet node SHOULD use the host route instead
of the default route. Getting the host route, the Manet node uses
its method of learning a Manet destination, e.g., by sending a route
requests for the destination.
9. Internet-gateway Operation
9.1. Route Examination during communication
An Internet Gateway SHOULD have reverse routes for all the manet
nodes which exists in its manet network. Whenever the Internet Gatewayreceives the packets sent by manet nodes and forwards them, it examines
the route path for the packets destination address. If the Internet
Gateway finds the host route towards the manet interface for the
destination, it indicates the destination node must be at same manet
network and it is possible to have the host route between the source
and the destination node. Internet Gateway sends a kind of route
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 12]
8/3/2019 Draft Wakikawa Manet Globalv6 01
15/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
error messages to notify sender node to start a manet routing request
operation in order to obtain the host route instead of the default
route. On the other hand, if the Internet Gateway finds an appropriateroute path, which is not the host route towards the manet interfaces, it
routes the packets to the destination on the route.
A host route to a Manet node should be maintained until the node
re-requests global information with a NDP Manet Router Solicitation
message or a Manet protocol route request. If the Internet-gateway does
not get any re-request messages before the lifetime of the host route is
expired, it discards the host route.
9.2. Receiving Route Request for a Global Destination Address
When an Internet-gateway receives a Manet protocol route requestdestined to another address than the INTERNET_GATEWAYS global multicast
address, it searches the address in its routing table. If the
Internet-gateway finds the host route, it SHOULD NOT return a Manet
protocol route reply augmented with global connectivity information
because the destination is then assumed to be inside the Manet. If the
address was not found in the routing table, the Internet-gateway returns
a Manet protocol route reply with global connectivity information. This
includes its own Manet address as route information used for the default
route entry.
If the Internet-gateway receives a route request for the
INTERNET_GATEWAYS global multicast address, it MUST unicast back its
global connectivity information, including its own IPv6 address. The
Internet-gateway SHOULD also include the lifetime GWINFO_LIFETIME intoits global connectivity information. Each time when receiving such a
request, the Internet-gateway MUST update the reverse route of sender
into its routing table.
9.3. Receiving Manet Router Solicitation
If the Internet-gateway receives a Manet Router Solicitation,
it SHOULD reply with its own prefix information in a Manet Router
Advertisement messages by unicast. Each time when receiving such a
request, the Internet-gateway MUST record the reverse route of sender
into its routing table.
9.4. Forwarding Packets in the Internet-gateway
An Internet-gateway always stores the senders Manet address into
an associated Manet nodes list and eventually a reverse route into its
routing table.
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 13]
8/3/2019 Draft Wakikawa Manet Globalv6 01
16/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
When the Internet-gateway receives a packet from the Manet network
interface, it searches a host route for the destination address from its
routing table . If it finds the host route, it MUST discard the packetand return an ICMPv6 Redirect Message or a route error message to the
sending Manet node. If it does not find the address from the list it
forwards the packet to the Internet.
When the Internet-gateway receives a packet from the Internet,
destined to a Manet node, it forwards the packet towards the Manet node
by using a host route generated by the Manet protocol. If such a route
does not exist, it is normally requested by the Manet protocol. Hence,
no Internet-gateway specific action is needed for a packet going from
the Internet to the Manet.
10. Intermediate Node Operation
If an intermediate Manet node receives a Manet protocol route request
for address resolution or a NDP Manet Router Solicitation, it MUST not
reply with global connectivity information and the Internet-gateway
address, even if it knows this information. Otherwise the Manet gateway
would not learn nodes in the network. The request MUST be propagated in
the Manet towards Internet-gateways, instead.
11. Sending Packet to the Manet from the Internet
Packets forwarded to a global address in the Manet get routed from
the Internet to the Internet-gateway which advertised the prefix of the
global destination address. The Internet-gateway then just resorts toits normal Manet protocol operation to forward the packet towards its
destination in the Manet.
12. Protocol Constants
Parameter Name Value
---------------------- -----
ALL_MANET_GW_MULTICAST TBD (ff1e::xx/64 global-scope)
GWINFO_LIFETIME TBD (10 seconds)
GWINFO_REFRESH GWINFO_LIFETIME * 0.8
13. Security Considerations
This document does not define any method for secure operation of the
protocol. There is no widely accepted model for securing state-altering
protocols in Manet. A reason for this is the lack of scalability in
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 14]
8/3/2019 Draft Wakikawa Manet Globalv6 01
17/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
security association setup among Manet nodes arriving from arbitrary
domains. Before well accepted SA setup methods exist, any node can
pretend to be an Internet gateway and result in other nodes settingtheir routing state in a way denying proper operation of this service.
Acknowledgments
The authors would like to thank Elizabeth Royer for her comments on
streamlining some aspects of the design. The authors also thank Thierry
Ernst for his comments.
References
[1] A. Conta and S. Deering. Internet Control Message Protocol(ICMPv6) for the Internet protocol version 6 (ipv6). Request
for Comments (Proposed Standard) 1885, Internet Engineering Task
Force, December 1995.
[2] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6)
Specification. Request for Comments (Proposed Standard) 1883,
Internet Engineering Task Force, December 1995.
[3] D. Johnson, D. Maltz, Y. Hu, and J.G. Jetcheva. The dynamic
source routing protocol for mobile ad hoc networks (work in
progress). Internet Draft, Internet Engineering Task Force,
February 2002.
[4] D. Johnson, C. Perkins, and J. Arkko. Mobility support in IPv6(work in progress). Internet Draft, Internet Engineering Task
Force, May 2002.
[5] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (ipv6). Request for Comments (Draft Standard) 2461,
Internet Engineering Task Force, December 1998.
[6] C. Perkins, J. Malinen, R. Wakikawa, E. Royer, and Y. Sun. IP
address autoconfiguration for ad hoc networks (work in progress).
Internet Draft, Internet Engineering Task Force, November 2001.
[7] C. Perkins, E. Royer, and S. Das. Ad hoc on demand distance
vector (AODV) routing for IP version 6 ( work in progress).Internet Draft, Internet Engineering Task Force, November 2000.
[8] C. Perkins, E. Royer, and S. Das. Ad hoc on demand distance
vector (AODV) routing (work in progress). Internet Draft,
Internet Engineering Task Force, January 2002.
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 15]
8/3/2019 Draft Wakikawa Manet Globalv6 01
18/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
A. Use of Routing header for transmission of packets along a default
route
As described in section 8.3, each manet node have two way to send
data along a default route when it decides to use of default route
for transmission packet. The node SHOULD support both but select one
depending on the base Manet protocol and network topology.
- Without IPv6 routing extension header the sender sends the packet
to the global IPv6 address and relies upon next hop routing in
the other nodes.
- With IPv6 routing extension header the sender uses the
Internet-gateway address in the destination address of the IPv6
header and the real destination address in the routing header.
This document recommends to use the second method for the following
reason. Assume the destination is inside the Manet but the sender
can not reach the destination via a host route. In such a case, if
the node sends packets to the destination via the Internet-gateway
without a routing header, an intermediate node who has a host route
for the destination will route packets to it directly; but the sender
node is not aware of this. The sender is never notified that packets
is not passing through the Internet-gateway. If the sender always
uses a routing header, every packet is undoubtedly routed through the
Internet-gateway. If the Internet-gateway detects that the destination
is located within the Manet, the internet gateway can send an ICMPv6
Redirect error message to the sender. After receiving the ICMP Redirect
messages, the node can send a route request for the destination to learn
the host route.
Using a routing header is also preferable if there are more than two
Internet-gateways, because the node then have the ability to decide
which Internet-gateway is the best, by distance in hops, or by some
other priority. By assign a priority number for each Internet-gateway,
the route reply message and the Manet Router Advertisement messages
could be extended to support a candidate Internet-gateway option in it.
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 16]
8/3/2019 Draft Wakikawa Manet Globalv6 01
19/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
B. AODV6 Operation with Global Connectivity for IPv6 Manet
This section describes how to apply embedding of the Internetconnectivity acquisition to an on-demand Manet routing protocol,
AODV [8], more precisely, to its IPv6 variant [7].
All the operation except for a specific explanation in this section
follow the descriptions presented earlier in this document.
B.1. Additions to AODV6 specification
The AODV6 protocol is used as is, except for the addition of one
flag.
0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |J|R|G|I| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flooding ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 Route Request message (RREQ) is illustrated
above, and contains the same fields with the same functions as the RREQ
message defined for IP version 6 (in [3]), except for the following:
Internet-Global Address Resolution Flag (I)
Internet-Global Information Flag: used for global address
resolution. This flag indicates that the destination node
requests global connectivity.
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 17]
8/3/2019 Draft Wakikawa Manet Globalv6 01
20/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type |R|A|I| Reserved | Prefix Sz | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 128-bit Destination IP Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 128-bit Source IP Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 Route Reply message (RREP) is illustrated
above, and contains the same fields with the same functions as the RREP
message defined for IP version 6 (in [3]), except for the following.
Internet-Global Address Resolution Flag (I)
Internet-Global Information Flag: used for global address
resolution. This flag defines that this reply contains
information about an internet gateway.
B.2. Global Address Resolution
This section describes how to obtain a globally routable IPv6 address
from an Internet-gateway by sending an AODV6 Route Request (RREQ) to the
INTERNET_GATEWAYS global multicast address.
When a node sends a RREQ, requesting global address resolution, it
can as IPv6 source address specify any arbitrary address with global
scope currently in use by one of its interfaces. This could, for
example, be its Mobile IPv6 home address or an address created temporary
from the MANET_INITIAL_PREFIX. The node then broadcasts the RREQ using
the I flag and specifies the INTERNET_GATEWAYS global multicast
address as the destination in the RREQ destination address field.
When an Internet-gateway receives a RREQ with the I flag set, itchecks its routing table for an entry towards the receiving network
interface and updates it with an entry of for requesting node using
the source address specified in the RREQ. The Internet-gateway then
constructs a Route Reply (RREP with the I flag set), and unicasts it
to the requesting node. The IPv6 header fields should be built as in
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 18]
8/3/2019 Draft Wakikawa Manet Globalv6 01
21/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
normal AODV6 operation. The global prefix information can be derived
using the responding gateways IPv6 address and the prefix length
specified in the RREP. In this way, the node will know both the addressof 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 didnt 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 atintermediate nodes. These reverse routes will become the route path to
the Internet-gateway for the nodes newly created global address. The
Internet-gateway should insert the nodes host route into its routing
table. The old entry in the gateway related to the temporary address
will be discarded after lifetime expiration.
When the node sends packets to the internet, it MAY use any of the
two methods specified in section 8.3 and appendix A.
If the node chooses to send a packet to the Internet without using
a routing header, some intermediate nodes may generate RERR message
because they do not have an active route to the packets destination,
see the AODV specification [8] for more details about this. To avoid
these unnecessary RERRs, a default route is defined as the active routein this document. This means that an intermediate node should have an
active default route. If the intermediate node doesnt have a host
route for a destination, it should route packets towards the default
route.
If the node instead uses a routing header, the address of the
Internet-gateway should be specified in destination address field of
the IPv6 header. All intermediate nodes on the route path to the
internet-gateway will then have a host route to the destination address,
ie. the internet-gateway address. The intermediate node cannot generate
a RERR message for outgoing packets destined outside of the Manet.
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 19]
8/3/2019 Draft Wakikawa Manet Globalv6 01
22/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
C. DSR Operation with Global Connectivity for IPv6 Manet
This section describes how to apply embedding of the Internetconnectivity acquisition to an on-demand Manet routing protocol, Dynamic
Source Routing protocol (DSR) [3].
All the operation except for a specific explanation in this section
follow the descriptions presented earlier in this document.
C.1. Additions to DSR specification
Global address resolution option is newly defined for DSR since DSR
does not have a flag field in Route Request Option and Route Reply
Option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Reserved | Prefix Sz |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Global Address Resolution Option is illustrated
above.
Option Type
TBD
Option Data Length8-bit unsigned integer. Length of the option, in octets,
excluding the Option Type and Opt Data Len fields.
Reserved
MUST be sent as 0 and ignored on reception.
Prefix Size
The Prefix Size specifies the prefix size of the replying
gateways global address. The prefix size will be used for
address generation with the gateway global address.
C.2. Global Address Resolution
This section describes how to obtain a globally routable IPv6
address from an Internet-gateway by sending an DSR Route Request to the
INTERNET_GATEWAYS global multicast address.
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 20]
8/3/2019 Draft Wakikawa Manet Globalv6 01
23/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
When a node sends a Route Request, requesting global address
resolution, it can as IPv6 source address specify any arbitrary address
with global scope currently in use by one of its interfaces. Thiscould, for example, be its Mobile IPv6 home address or an address
created temporary from the MANET_INITIAL_PREFIX. The node then
broadcasts the Route Request using the Global Address Resolution Option
and specifies the INTERNET_GATEWAYS global multicast address as the
target address destination in the Route Request.
When an Internet-gateway receives a Route Request with the Global
Address Resolution Option, it checks its routing table for an entry
towards the receiving network interface and updates it with an entry
of for requesting node using the source address specified in the
IPv6 header field. The Internet-gateway then constructs a Route
Reply with Global Address Resolution Option, , and unicasts it to the
requesting node. The IPv6 header fields should be built as in normalDSR operation. The global prefix information can be derived using the
responding gateways IPv6 address and the prefix length specified in the
Global Address Resolution Option. In this way, the node will know both
the address of the gateway and the globally routable prefix.
After acquiring a topologically correct global IPv6 address, the node
first deletes the temporary address from the MANET_INITIAL_PREFIX. If
the node didnt create this temporary address, the node can continue
using the arbitrary address, e.g. the Mobile IPv6 home address, used
during communication with the gateway. The node then broadcasts a
Route Error with the temporary address to delete all the related host
routes. The Route Error of DSR does not contain any address lists to
create new reverse route for the newly created global IPv6 address at
Internet-gateways. Route Request can therefore be sent over the Manetto create reverse routes at internet-gateways after previous Route
Error operation. The reverse routes will become the route path to
the Internet-gateway for the nodes newly created global address. The
Internet-gateway should insert the nodes host route into its routing
table.
C.3. Communication to the Internet
When the node communicates to a destination which is located in the
internet, it can use same way as base DSR protocol. DSR uses the DSR
Source Route Option to route packets to a destination. The DSR Source
Route Option is extracted from the draft as below.
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 21]
8/3/2019 Draft Wakikawa Manet Globalv6 01
24/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Option Type | Opt Data Len |F|L|Reservd|Salvage| Segs Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If a DSR node sends packets to the global destination, the DSR nodeset Last Hop External flag (L) in the Source Route Option and puts
an internet-gateway address in Address[n-1] when address[n] is the
destination address. The operations of routing packets with the Source
Route Option are followed by DSR protocol.
If a global node at the Internet sends packets to a DSR node which is
located in DSR network, the global node set First Hop External flag and
puts an internet-gateways address in Address[2]. Address[1] should be
set the global address of the global node. The operations of routing
packets with the Source Route Option are followed by DSR protocol as
well.
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 22]
8/3/2019 Draft Wakikawa Manet Globalv6 01
25/27
8/3/2019 Draft Wakikawa Manet Globalv6 01
26/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
entry for gateway prior to the entry for home address, and setting the
segments left to two.
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 24]
8/3/2019 Draft Wakikawa Manet Globalv6 01
27/27
Internet Draft Global Connectivity for IPv6 Manets 01 July 2002
E. Changes from draft-wakikawa-manet-globalv6-00
- Added algorithm in section 8.3 whether the destination is earlydiscovered by route request or not. It helps to prevent repeated
redundant route requests.
- Added DSR operation as an example in appendix.
- Moved the use of routing header from section 8.3 to appendix A,
since some base Manet protocol can forward packet to the
Internet-gateway by next hop forwarding support (e.x. AODV).
- Kept protocol parameters as TBD.
Authors Addresses
Ryuji Wakikawa Charles Perkins
Graduate School of Communications Systems Lab
Media and Governance. Nokia Research Center
Keio University 313 Fairchild Drive
5322 Endo Fujisawa Kanagawa Mountain View, California
252 JAPAN 94043 USA
Phone: +81-466 49-1394 Phone: +1-650 625-2986
EMail: [email protected] EMail: [email protected]
Fax: +81 466 49-1395 Fax: +1 650 625-2502
Jari T. Malinen Anders Nilsson
Communications Systems Lab Dept. of Communication SystemsNokia Research Center Lund Institute of Technology
313 Fairchild Drive Box 118
Mountain View, California SE-221 00 Lund
94043 USA Sweden
Phone: +1-650 625-2355 Phone: +46 46-39 72 92
EMail: EMail:
[email protected] [email protected]
Fax: +1 650 625-2502 Fax: +46 46-14 58 23
Antti J. Tuominen
TM Laboratory
Helsinki University of Technology
P.O.Box 970002015 HUT
Finland
Phone: +358 9
EMail: [email protected]
Fax: +358 9
R. Wakikawa et.al. Expires 01 Jan 2003 [Page 25]