One document matched: draft-cha-manet-extended-support-globalv6-00.txt
Mobile Ad Hoc Networking Working Group Hyun-Wook Cha
Internet Draft Jung-Soo Park
Document: draft-cha-manet-extended-support- Hyoung-Jun Kim
globalv6-00.txt
PEC, ETRI
Expires: April 2004 October 2003
Extended Support for Global Connectivity
for IPv6 Mobile Ad Hoc Networks
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [i].
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 enhanced Internet connectivity
to mobile ad hoc networks. To achieve this goal, we borrow the
concept of Mobile IPv6[6] and make the most use of available multiple
gateways. Specifically, our scheme makes a global address being used
by Upper layer reachable by peer Internet node by registering another
global address as a locator with corresponding gateway for the
address being cared while the gateway can not obtain host route
information for the cared address because of frequent partitions.
We introduce stateful auto-configuration for acquisition of global
address in mobile ad-hoc networks because it can avoid duplicate
address problem and help prevent traffics from going outside a manet
or unnecessary control traffic by route discovery of reactive routing
protocols from being issued. In addition, it can support for our
scheme since our scheme requires some security guarantee to register
a locator with a gateway as Mobile IPv6 requires for Binding Updates.
Cha, et. al. Expires April 2004 [Page 1]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
Basically, our extended support and stateful configuration of global
address are devised to extend AODV[1], but the concept is also
applicable for proactive routing protocols such as OLSR[2], TBRPF[3].
Further, our extended support can be useful for a mobile node(MN) in
Mobile IPv6 to maintain its reachability from the Internet by
utilizing multi-hop manet extension as a virtual link since it can
help determine intelligently when current CoA should be changed and
Binding Update with new CoA be performed while it can make the
current CoA reachable from Internet even when the GW which assigned
the CoA is not reachable from the manet node any more.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [ii].
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................4
3. Formats of Extened AODV Control Messages for Extended Support for
Internet Connectivity for IPv6 Manets.............................5
3.1 Format of the GW_SOL message...............................5
3.2 Format of the GW_ADV message...............................6
3.3 Format of the LOC_UPDATE message...........................8
3.4 Format of the LOC_UPDATE_REPLY message.....................9
4. Detailed Procedure of Extended Support for Internet Connectivity
for IPv6 Manets..................................................11
4.1 Stateful Global IP Auto-configuration for Manets..........11
4.2 Extended Support for Internet Connectivity for Manets.....12
5. Security Considerations.......................................14
References.......................................................15
Author's Addresses...............................................15
Cha, et. al. Expires April 2004 [Page 2]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
1. Introduction
Mobile ad-hoc networking originally aims for mobile nodes to
communicate each other through wireless interfaces under
circumstances without infrastructure. However, to support global
Internet connectivity for mobile ad-hoc networks(manet) is also
useful because nodes inside a manet may want to communicate nodes
outside the manet which are located in somewhere Internet.
This can be achieved in many ways as [5] describes. Especially
approach to extend existing routing protocols is attractive because
it can support global connectivity for a manet efficiently with
minimal overhead and does not require any modification to existing
IPv6 standards such as NDP[7] or DHCPv6[8]. Although [5] proposes
basic framework for extension of routing protocols, the authors do
not consider that enhanced Internet connectivity can be provisioned
for a manet by using multiple gateways.
In this document, we introduce stateful auto-configuration for
acquisition of global address in mobile ad-hoc networks because it
can avoid duplicate address problem and help prevent traffics from
going outside manets or unnecessary control traffic by route
discovery of reactive routing protocols from being issued. In
addition, it can support for our scheme since our scheme requires
some security guarantee to register a locator with a gateway as
Mobile IPv6 requires for home registration. Then, we describe how to
provide enhanced Internet connectivity to mobile ad hoc networks. To
achieve this goal, we borrow the concept of Mobile IPv6[6] and make
the most use of available multiple gateways. Specifically, our scheme
makes a global address being used by Upper layer reachable by peer
Internet node by registering another global address as a locator with
corresponding gateway for the address being cared while the gateway
can not obtain host route information for the cared address because
of frequent partitions.
Basically, our extended support and stateful configuration of global
address are devised to extend AODV[1], but the concept is also
applicable to proactive routing protocols such as OLSR[2], TBRPF[3].
Further, our extended support can be useful for a mobile node(MN) in
Mobile IPv6 to maintain its reachability from the Internet by
utilizing multi-hop manet extension as a virtual link since it can
help determine intelligently when its current CoA should be changed
and Binding Update be performed while it can make a cared address
chosen as current CoA reachable from Internet even when the GW which
assigned the cared address is not reachable from the manet node any
more. In addition, it can reduce signaling overhead of Binding
Updates by hiding frequent topology change of a manet from Mobile
IPv6.
Cha, et. al. Expires April 2004 [Page 3]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
2. Terminology
a manet node Is a non-gateway node in a manet.
manet prefix Is the prefix for manets.
internet-gateway(GW)
A router which provides extended support for Internet connectivity
for manet nodes. This router is located at the edge of manet and has
a connection to both Internet and the manet.
internet-gateway multicast address(MANET_GW)
The IPv6 global multicast address for all internet gateways in a
manet.
internet-gateway information(GW_INFO)
The gateway’s IP, prefix length and lifetime
resolved_addr Is auto-configured global IP for a manet node. This
addr is assigned by GW in stateful manner, or resolved through
stateless configuration.
internet-gateway solicitation(GW_SOL)_
A message to solicit GW_INFO(s) to single(multiple) gateway(s)
when a global address needs to be refreshed.
internet-gateway advertisement(GW_ADV)
A message to advertise GW_INFO, route information for the GW
and resolved_addr assigned for a requesting manet node through GW_SOL
by the GW
cared address Is one of resolved addrs which belongs to a manet node.
This address is being used as source address of current active
transport layer sessions.
locator Is one of resolved addrs which belongs to a manet node. This
address is used to provide a cared address with extended reachability
as CoA(Care of Address) in MobileIPv6 does.
locator registration Is to register a global address of a manet node
as locator for cared address with the GW which assigned the cared
address. This is similar to Binding Updates in MobileIPv6.
LOC_UPDATE Is sent to corresponding GW for the locator registration.
LOC_UPDATE_REPLY Is sent to the manet node which sent a LOC_UPDATE to
notify that new locator in the LOC_UPDATE is registered successfully.
Cha, et. al. Expires April 2004 [Page 4]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
3. Formats of Extened AODV Messages for Extended Support for Internet
Connectivity for IPv6 Manets
3.1 Format of the GW_SOL message
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 |I|S|J|R|G|D|U| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Destination IP Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Originator IP Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator 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 IPv6 in [1], except for the following:
Type 1(same as one of RREQ in [1]).
Internet-Global Address Resolution Flag (I)
This flag is used for global address resolution as [5] defines and
indicates that originator node requests global connectivity.
Type of Auto-configuration for Global Address Flag (S)
This flag indicates that originator of this message requests
stateful/stateless auto-configuration for a global address if this
flag is set to 1/0. In addition, originator must set I flag to 1 to
resolve its global address.
Originator IP Address Is a IP address with manet prefix of a
manet node.
Cha, et. al. Expires April 2004 [Page 5]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
3.2 Format of the GW_ADV message
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 |I|S|A| Reserved | Prefix Sz | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GWADV ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Gateway IP Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RT_INFO Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RT_INFO Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GW_INFO Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GW_INFO Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Resolved IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of GW_ADV is illustrated above, and contains two group of
fields except for Type, Flags, Reserved fields and GWADV_ID : one for
route information and the other for GW_INFO of a GW.
The first group includes Prefix Sz, Hop Count, Gateway IP Address,
RT_INFO Sequence Number, RT_INFO Lifetime and the second one includes
Prefix Sz, Gateway IP Address, GW_INFO Sequence Number, GW_INFO
Lifetime, Resolved IP Address. Specific explanation about each field
is as follows.
Type 16
Internet-Global Address Resolution Flag (I)
This flag is used for global address resolution as [5] defines,
and notifies that this message contains GW_INFO and resolved IP
address.
Type of Auto-configuration for Global Address Flag (S)
This flag indicates that originator of this message replies a
GW_SOL for stateful/stateless auto-configuration for a global address
if this flag is set to 1/0. Gratuitous GW_ADV may be broadcast
periodically. In this case, this flag must be 0.
Cha, et. al. Expires April 2004 [Page 6]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
A Acknowledgment required as sections 5.4 and 6.7 in [1]
describes.
Reserved Sent as 0; ignored on reception.
Prefix Size
If nonzero, the 7-bit Prefix Size is defined to resolve the prefix
of GW_INFO contained in this message and to be used for the same
purpose of same field of RREP in [1].
Hop Count The number of hops from the Originator IP Address to
the Destination IP Address.
Gateway IP Address
The IP address of the GW whose GW_INFO and route information are
supplied.
RT_INFO Sequence Number
The destination sequence number associated to the route.
RT_INFO Lifetime
The time in milliseconds for which nodes receiving the GW_ADV
consider the route to be valid.
GW_INFO Sequence Number
The sequence number associated to the GW_INFO.
GW_INFO Lifetime
The time in milliseconds for which nodes receiving the GW_ADV
consider the GW_INFO to be valid.
Resolved IP Address Is an address which originator of this message
assigns to a requesting manet node through GW_SOL. The S flag must be
set to 1.
Cha, et. al. Expires April 2004 [Page 7]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
3.3 Format of the LOC_UPDATE message
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Originator Manet IP Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Locator |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Target Gateway IP Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of LOC_UPDATE is illustrated above, and each field is
defined as follows.
Type 17
Reserved Sent as 0; ignored on reception.
Originator Manet IP Address manet local address of originator.
Locator Is one of resolved addresses which belongs to originator.
This address is used to provide a cared address with extended
reachability as CoA(Care of Address) in MobileIPv6 does.
Target Gateway IP Address Is an address of the GW which is final
destination of this message.
Sequence Number indicates the freshness of this message.
TimeStamp Is the time when originator sent this message.
Cha, et. al. Expires April 2004 [Page 8]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
3.4 Format of the LOC_UPDATE_REPLY message
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 | Reserved | Prefix Sz |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Originator Manet IP Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Locator |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Gateway IP Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GW_INFO Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GW_INFO Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Resolved IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of LOC_UPDATE_REPLY is illustrated above, and this
message specifies that registration through LOC_UPDATE message
replied by this message is done successfully and includes GW_INFO of
the originator.
Type 17
Reserved Sent as 0; ignored on reception.
Originator Manet IP Address manet local address of originator.
Cha, et. al. Expires April 2004 [Page 9]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
Locator Is one of resolved addresses which belongs to originator.
This address is used to provide a cared address with extended
reachability as CoA(Care of Address) in MobileIPv6 does.
Sequence Number indicates the freshness of this message.
TimeStamp Is the time when originator sent this message.
4. Conceptual Data Structures
4.1 Internet Gateway
A GW maintains "manet_node_cache" for manet nodes to whom the GW has
assigned global addresses. Eache entry called "node_entry" contains
the following basic fields.
O local_IP_address which is with manet prefix and owned by a manet
node for which global_IP_address has been assigned.
O global_IP_address which has been assigned to a manet node with
local_IP_address.
O addr_expire when global_IP_address is expired.
And, additional fields for the extended support are defined in the
node_entry.
O locator which indicates one of global addresses owned by a manet
node with local_IP_address. This address is set by LOC_UDPATE
messages sent by the manet node.
O loc_last_seqno which is the sequence number which was contained in
the last accepted LOC_UDPATE message.
O loc_expire when locator is expired
O loc_service_expire when global_IP_address is not used as a locator
for another global address owned by a manet node with
local_IP_address any more.
4.2 Manet Node
A manet node maintains a "loc_update_list" per one cared address for
LOC_UDPATE messages which were issued for same cared address at the
same time. When it receives a LOC_UDPATE_REPLY message, it determines
that this message is replied to one of last LOC_UDPATE messages
correctly by referring this list. It contains following fields.
O locator_list which consist of global addresses owned by the manet
which were used as locator for last trial of the locator registration.
O loc_update_last_req_time when the last LOC_UPDATE messages were
sent.
Cha, et. al. Expires April 2004 [Page 10]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
O loc_update_req_timeout. Until this time, trial of locator
registration is delayed.
O loc_update_last_seqno which is used as sequence number in
LOC_UPDATE messages issued at the last trial of locator registration.
O loc_update_completed which indicates whether the last trial of
locator registration is successfully accepted.
O loc_update_expire when last successful locator registration is
considered as invalid.
O loc_update_time_to_refresh when registered locator needs to be
refreshed.
In addition, a manet node maintains the cache "loc_update_rtt" for
history of round trip times for recent location registions. This
cache is used to calculate loc_update_req_timeout in the
loc_update_list. It contains last_seqno field which indicates maximum
sequence number in the received LOC_UDPATE_REPLY messages.
5. Detailed Procedure of Extended Support for Internet Connectivity for
IPv6 Manets
5.1 Stateful Global IP Auto-configuration for Manets
We introduce new stateful global IP auto-configuration for manets.
This stateful auto-configuration is performed efficiently through the
exchange of extended control messages of manet routing protocols
without DHCPv6.
Detailed procedure is as follows.
When a manet node starts to communicate with an Internet node which
is not inside the manet, it needs to configure global address to use
as source address for this session. Even when no global addresses are
available, the manet node can resolve global addresses through RREQ
with I flag set to 1 and S flag to 1 during route discovery for the
destination as in [5].
When a GW receives above message or a GW_SOL with S flag set to 1, it
looks up its "manet_node_cache" to find corresponding entry with
originator IP address field which is with the manet prefix in
received message. If a corresponding entry does not exist in the
cache, the GW creates new node_entry for the originator node and set
global_IP field as newly assigned address with the prefix advertised
by itself, addr_expire field as current time plus GLOBAL_IP_LIFETIME.
Otherwise, it only updates addr_expire field in the entry as current
time plus GLOBAL_IP_LIFETIME. After that, the GW replies through a
GW_ADV message which contains rt_info as well as GW_INFO including
resolved_addr which indicates a global IP assigned for the requesting
manet node.
Cha, et. al. Expires April 2004 [Page 11]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
When the manet node receives the GW_ADV, it can configure its global
address with resolved_addr in the GW_ADV and communicate Internet
nodes. When an auto-configured address is to be refreshed, a manet
node issues GW_SOL message with I flag, S flag set as 1 and
Destination IP Address field set as MANET_GW. At this time, if
originator has valid route information of the GW which assigned the
global address, this message can be sent as a unicast packet with
Destination Address field of IPv6 header as the GW. Otherwise, this
message is broadcasted. For GW_ADV message which is sent to reply the
GW_SOL message can be dropped in fly to the originator of the GW_SOL
because of the nature of manet although the GW has updated node_entry
for the manet node, implicit acks through received packets can be
helpful.
This auto-configuration scheme has several advantages.
Firstly, this scheme can perform the duplicate address detection(DAD)
between manet nodes as well as manet nodes to normal mobile nodes
which are not manet nodes efficiently. Since a GW can make use of any
schemes which is devised for DAD inside a manet, it does not assign
global address for duplicate manet address. For between manet nodes
to non-manet ones, a GW can behave as neighbor discovery proxy for a
manet node for which the GW has valid entry in the manet_node_cache.
Secondly, this can help prevent traffics from going outside manets or
unnecessary control traffic by route discovery of reactive routing
protocols from being issued since a GW can determine that destination
IP address in IPv6 header of a packet is being used by a manet node
or not. In addition, it can support for our extended support for
Internet connectivity for manets since our scheme requires some
security guarantee to register a locator with a GW as Mobile IPv6
requires for home registration.
5.2 Extended Support for Internet Connectivity for Manets
Our scheme makes a global address being used by Upper layer reachable
by peer Internet node by registering another global address as a
locator with corresponding gateway for the address being cared while
the gateway can not obtain host route information for the cared
address because of frequent partitions to provide enhanced Internet
connectivity to mobile ad hoc networks.
Detailed procedure is as follows.
When a manet node has a packet to send to an Internet node which is
not inside the manet, it can not obtain host route information for
the destination and forwards the packet toward the GW which has
assigned source address of the packet. If it does not have the valid
route information for the GW, it inserts the packet into a special
queue called "gw_rqueue" and performs route discovery for the GW.
Cha, et. al. Expires April 2004 [Page 12]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
At this time, the locator registration is triggered in our extended
support if the cared address is not being used as a locator for
another cared address. This constraint is for preventing iterative
de-tourings through locator registrations. For a global address to be
used as a locator, the address should be valid and corresponding GW
for the address should be reachable by the manet node, and the
address should not be being cared through previous locator
registration. Last condition is also for preventing iterative de-
tourings through locator registrations. Thus, if multiple GWs are
available, a manet node can use multiple global addresses as locator
candidates. A LOC_UPDATE message contains locator field set as a
chosen address as a locator, sequence number field as its valid one,
and time_stamp as the time when it is issued. For the LOC_UPDATE,
source/destination address of IPv6 header are set to
locator/corresponding GW for locator respectively. When the
corresponding GW for locator receives this message, if the locator is
not being cared by another locator, it updates loc_service_expire as
current time plus LOC_SERVICE_LIFETIME. If so, this message is
discarded silently for preventing iterative de-tourings through
locator registrations. After that, it modifies destination address of
IPv6 header same as "target gateway IP address" field and forwards it
without referring its manet routing table. After the GW which
assigned the cared address receives the LOC_UPDATE, it checks by
referring information related locator in corresponding node_entry in
the manet_node_cache if the cared address is being used as a locator
for another cared address or not. If so, this message being discarded
silently for preventing iterative de-tourings through locator
registrations. Otherwise, it compares sequence number field in the
LOC_UPDATE message with loc_last_seqno in the node_entry which was
updated by the last LOC_UPDATE through which location registration
was successfully done. If sequence number field in the LOC_UPDATE
message is bigger than the recorded one, the GW accepts the locator
registration and updates locator and related information including
loc_expire in the entry.
As long as registered locator is valid, the GW can de-tour a packet
destined to the cared address through IPv6-in-IPv6 tunneling using
the locator as destination address in outer IPv6 header although it
does not obtain host route information for the cared address. If not,
this message is discarded silently. When the GW accepts the
LOC_UDPATE message, it replies through the LOC_UPDATE_REPLY message
which contains copied fields from the LOC_UPDATE message and fields
for its GW_INFO. When the manet node which has sent the LOC_UDPATE
message receives the LOC_UPDATE_REPLY, it determines whether this
message is replied to one of last LOC_UDPATE messages correctly by
comparing sequence number in LOC_UPDATE_REPLY message with
loc_udpate_last_reqno for the cared address and searching
corresponding entry for locator in the LOC_UPDATE_REPLY message in
loc_update_list for the cared address. If the LOC_UPDATE_REPLY
Cha, et. al. Expires April 2004 [Page 13]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
indicates that the locator registration is accepted successfully, the
mobile node updates the loc_udpate_cache for the cared address to
specify the success of the registration and update loc_update_expire
and loc_expire_time_to_refresh in the cache correctly. If not, the
manet node discards the LOC_UPDAT_REPLY message silently. A manet
node maintains the cache "loc_update_rtt" for history of round trip
times for recent location registrations which is used to calculate
loc_update_req_timeout. The reason why this cache is introduced is
that manet nodes can estimate and adjust reasonable
loc_update_req_timeout value through this cache. When a manet node
receives a LOC_UPDATE_REPLY message, it can insert a rtt time which
is calculated by subtracting time_stamp in the message from current
time into its loc_update_rtt cache if the sequence number in the
LOC_UDPATE_REPLY is bigger than the "last_seqno" in the
loc_update_rtt cache.
After a manet node finishes above procedure for successful locator
registration, it can forward a packet destined to an Internet node
using IPv6-in-IPv6 tunneling although it does not yet obtain host
route for the GW which has assigned the source address in IPv6 header
of the packet. At this time, source/destination address in the outer
IPv6 header is locator/inner destination address in the inner IPv6
header.
For a LOC_UDPATE_REPLY message which is sent to reply a LOC_UDPATE
message can be dropped in fly to the originator of the LOC_UPDATE
message because of the nature of manet although the GW has updated
node_entry for the manet node, implicit acks through received packets
tunneled from the GW can be helpful.
If a GW receives ICMPv6 Destination Unreachable message, it resets
registered locators of corresponding entries with the unreachable
destination as locator in the manet_node_cache.
Our extended support can be useful for a MN in Mobile IPv6 to
maintain its reachability from the Internet by utilizing multi-hop
manet extension as a virtual link since it can help determine
intelligently when its CoA should be changed and Binding Update be
performed while it can make a cared address chosen as current CoA
reachable from Internet even when the GW which assigned the cared
address is not reachable from the manet node any more.
In addition, it can reduce signaling overhead of Binding Updates in
Mobile IPv6 by hiding frequent topology change of a manet from Mobile
IPv6.
6. Security Considerations
So far, security requirements for manet routing protocols is not
defined clearly by IETF Mobile Ad-hoc Networks working group. However,
Cha, et. al. Expires April 2004 [Page 14]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
we believe that our proposed idea can be supported by any security
mechanism for ad-hoc routing protocols sufficiently because
authentication for a manet address to be used for basic operation of
routing protocols can be utilized for authorization of a LOC_UDPATE
message.
In revised version, we will describe the analysis about possible
security threats and efficient solutions applicable to achieve our
goal without support of security mechanism for ad-hoc routing
protocols. One of solutions is to establish a shared secret between a
mobile node and a GW through the exchange of a GW_SOL and a GW_ADV
messages, and use the secret to authorize a LOC_UDPATE message.
References
[1] Perkins, et. al., " Ad hoc On-Demand Distance Vector(AODV)
Routing", RFC 3561, July 2003.
[2] Clausen, Jacquet, "Optimized Link State Routing Protocol(OLSR)",
RFC 3626, October 2003.
[3] Ogier, et al., "Topology Dissemination Based on Reverse-Path
Forwarding (TBRPF)", I-D draft-ietf-manet-tbrpf-11.txt, October
2003.
[4] Johnson, et al., "The Dynamic Source Routing Protocol for Mobile
Ad Hoc networks(DSR)", I-D draft-ietf-manet-dsr-09.txt, April 2003.
[5] Wakikawa, et al., "Global Connectivity for IPv6 Mobile Ad Hoc
Networks", I-D draft-wakikawa-manet-globalv6-02.txt, November 2002.
[6] Johnson, et al., "Mobility Support in IPv6", I-D draft-ietf-
mobileip-ipv6-24.txt, June 2003.
[7] Narten, et. al., "Neighbor Discovery for IP Version 6", RFC 2461,
December 1998.
[8] Droms, et al., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
Author's Addresses
Hyun-Wook Cha
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350, Korea
Cha, et. al. Expires April 2004 [Page 15]
Internet Draft Extended Support for Global Connectivity Oct 2003
for IPv6 MANETs
Phone: +82 42 860 1076
EMail: jafy@etri.re.kr
Jung-Soo Park
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350, Korea
Phone: +82 42 860 6514
EMail: pjs@etri.re.kr
Hyoung-Jun Kim
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350, Korea
Phone: +82 42 860 6576
EMail: khj@etri.re.kr
Cha, et. al. Expires April 2004 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-22 22:38:43 |