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]