Draft Wakikawa Manet Globalv6 01

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]


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]


3/27


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]


4/27


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



5/27


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:



6/27


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



7/27


8/27


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



9/27


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.



10/27


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



11/27


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



12/27


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



13/27


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.



14/27


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



15/27


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.



16/27


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



17/27


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.



18/27


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.



19/27


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.



20/27


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



21/27


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.



22/27


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.



23/27


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.



24/27


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.



25/27


26/27


entry for gateway prior to the entry for home address, and setting the

segments left to two.



27/27


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


Date post:	06-Apr-2018
Category:	Documents
Upload:	pham-thuy
View:	218 times
Download:	0 times

Draft Wakikawa Manet Globalv6 01

Documents