Mobile Ad Hoc Networking Working Group Ryuji Wakikawa INTERNET DRAFT Keio University 23 Oct 2003 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-03.txt Status of This Memo This document is a submission by the Mobile Ad Hoc Networking Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the manet@itd.nrl.navy.mil mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract This document describes how to provide Internet connectivity with mobile ad-hoc networks. It describes how to obtain a globally routable address and internet-gateway operation. Once a manet node obtains a global address from an internet-gateway, it may exchange data with nodes on the Internet. Data goes through the internet-gateway with a routing header specifying the gateway. This connectivity method is not dependent on a particular manet protocol. Further, use of global connectivity with Mobile IPv6 is specified. R. Wakikawa et.al. Expires 23 Jun 2003 [Page i]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 Contents Status of This Memo i Abstract i 1. Introduction 2 2. Terminology 4 3. Limitations and Assumptions 5 4. Required Operations for Global Connectivity 6 4.1. Node Demands . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Routing Protocol Command Types . . . . . . . . . . . . . 6 4.2.1. AODV6: An Example of a Reactive Protocol . . . . 7 4.2.2. Example of OLSR (Proactive) . . . . . . . . . . . 7 4.3. Message Transport Demands . . . . . . . . . . . . . . . . 8 5. Internet-Gateway Discovery 9 5.1. Internet-Gateway Discovery Processing . . . . . . . . . . 9 5.2. Receiving Internet-Gateway Information . . . . . . . . . 10 5.3. Reactively Soliciting Internet-Gateway Information (Optional) . . . . . . . . . . . . . . . . . . . . . . . 10 5.3.1. Reactive Manet Protocol Based Solicitation . . . 11 5.3.2. NDP based Solicitation . . . . . . . . . . . . . 12 5.4. Advertising Internet-Gateway Information . . . . . . . . 13 5.4.1. Manet Routing Protocol Based Advertisement . . . 13 5.4.2. NDP based Advertisement . . . . . . . . . . . . . 14 5.5. Management of Manet Nodes on Internet-Gateway . . . . . . 14 6. Address Resolution 16 6.1. Address Generation . . . . . . . . . . . . . . . . . . . 16 6.2. Default Route Setting . . . . . . . . . . . . . . . . . . 16 7. Route Examination 18 7.1. Route Examination at Manet Node in Reactive Manet Protocols 18 7.2. Route Examination at Internet-Gateway in Reactive Manet Protocols . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Error Handling 22 8.1. Receiving ICMPv6 Error Message . . . . . . . . . . . . . 22 8.1.1. ICMPv6 Destination Unreachable Message . . . . . 22 8.1.2. ICMPv6 Redirect message . . . . . . . . . . . . . 22 8.2. MANET Routing Protocol Repair Message . . . . . . . . . . 22 9. Protocol Constants 23 10. Security Considerations 23 R. Wakikawa et.al. Expires 23 Jun 2003 [Page ii]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 Acknowledgments 23 References 23 Appendices 25 A. ICMPv6 and Neighbor Discovery Protocol Extensions for MANET 25 A.1. Modified Router Solicitation . . . . . . . . . . . . . . 25 A.2. Modified Router Advertisement . . . . . . . . . . . . . . 26 A.3. Source Manet Address Option . . . . . . . . . . . . . . . 26 A.4. Changing the ICMPv6 Redirect . . . . . . . . . . . . . . 27 B. Mobile IPv6 Extensions for MANET 28 C. Use of Routing Header for Transmission of Packets along a Default Route 29 D. AODV6 Operation with Global Connectivity for IPv6 MANET 30 D.1. Additions to AODV6 specification . . . . . . . . . . . . 30 D.2. Global Address Resolution . . . . . . . . . . . . . . . . 31 E. Changes from draft-wakikawa-manet-globalv6-02 33 Authors' Addresses 33 R. Wakikawa et.al. Expires 23 Jun 2003 [Page 1]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 1. Introduction A mobile ad-hoc network (manet) is built dynamically when a set of mobile routers create routing state for their connectivity management, typically over a wireless network. Manet routing protocols aim to maintain a route to a destination despite movement of intermediate nodes that causes the route path to change. Two routing protocols [12] [2] were published as an experimental RFC and two routing protocols [6] [9] will be published as an experimental RFC as well. Global connectivity is often required for nodes desiring communication with the fixed Internet. However, routing protocols for manets typically only maintain routes locally within the reach of a manet running the given protocol. This document specifies the method by which a node in the manet acquires a global address from a gateway, as well as how this node will communicate over the gateway. Two methods for internet gateway discovery are proposed: one method periodically disseminates gateway advertisements to all nodes in the manet; the other method utilizes solicitation and advertisement signaling between a manet node and the gateway. Extended router solicitation and advertisements of the Neighbor Discovery Protocol (NDP) [8] or extended control message of each manet protocol can be used for this signaling. The proposed methods target all manet protocols regardless of whether they are reactive and proactive. Internet-gateways have to supply their own global prefix information and IPv6 global address to manet nodes somehow, either proactively or reactively. In this way, the reactive and proactive route discovery features of each manet routing protocol are not disturbed. An advertisement from the internet-gateway provides prefix information, and advertisement processing possibly resolves a route to the gateway, inserted as a default route. A prefix which is distributed by an internet-gateway can be used for configuring a (typically globally) routable IPv6 [4] address for each manet node. If the manet is operating proactively, the gateway periodically broadcast its own global prefix and any global scope information. Manet nodes then (proactively) maintain this information. On the other hand, if the manet is operating reactively, a manet node initiates a discovery to acquire global prefix and any global scope information from the gateway. The discovery can be started on demand when Internet connectivity is required. After accepting an advertisement from an internet-gateway, the node configures a routable IP address from the prefix of the gateway and inserts the gateway address as a default route. Selecting one of multiple gateways is out of scope of this document, but any mechanisms for router selection which are proposed at IPv6 working group at IETF can also be used for this selection [5]. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 2]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 Each internet-gateway monitors packets received from the manet, to avoid unnecessarily forwarding the packet to the Internet when the destination is already present within the manet. The destination of a packet passing through the internet-gateway is checked on the internet-gateway. If the manet is operating reactively, the internet-gateway in this case may also supply an updated route to the sending node. The sending node then receives a notification and sends a route request to discover the direct route to the destination. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 3]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 2. Terminology manet Mobile Ad-Hoc Network manet node A node located inside a manet reactive manet protocol A reactive manet protocol requires manet nodes to discover or manage routes for destinations on-demand. Typical reactve manet protocols are Ad-hoc On-demand Distant Vector (AODV) Routing Protocol [1, 11] and the Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR) [6], etc. proactive manet protocol Using a proactive manet protocol, manet nodes maintain routes for destinations all the time. Typical proactive manet protocols are Optimized Link State Routing Protocol (OLSR) [2] and Topology Broadcast Based on Reverse-Path Forwarding (TBRPF) [9], etc. manet address A manet node's identity address in manet. The address is used for ad-hoc routing. internet node A node located within the Internet (outside manet) internet-gateway A router which provides Internet connectivity for nodes in the manet. This router is located at the edge of manet and has a connection to both the Internet and the manet. global address A node's IPv6 address in the Internet, typically resolvable from a DNS name. The address identifies the mobile node, and is used for communication to the Internet internet-gateways multicast address (IGW_MCAST) Specifically, ALL_MANET_GW_MULTICAST, the IPv6 global multicast address for all internet-gateways in a manet. manet network interface A network interface supporting a link to a manet node. internet-gateway information The gateway's IP routing prefix, prefix length, and lifetime. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 4]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 internet-GateWay Advertisement (GWADV) A message to advertise internet-gateway information. There are two types, GWADV_M and GWADV_N: GWADV_M Extends the manet protocol; a control message is specified for each particular protocol to advertise internet-gateway information GWADV_N Extends NDP to indicate that the advertisement contains information about the internet-gateway internet-GateWay Solicitation (GWSOL) A message to solicit an internet-gateway advertisement. There are two types, GWSOL_M and GWSOL_N. GWSOL_M Extends the manet protocol; a control message is specified for each particular protocol to solicit internet-gateway information GWSOL_N Extends NDP to solicit an internet-gateway Advertisement. 3. Limitations and Assumptions The following assumptions are made for simplicity and definiteness: Address Family This document assumes IPv6 address family support. The manet routing protocol discussed in this document MUST be capable of routing based on IPv6 addresses. Topological assumption There is at least one internet-gateway at the edge of the manet. Address assumption All nodes in the manet must have or acquire a routable address, perhaps usable as a Mobile IPv6 [7] home address. The routable address is used for initial configuration when a node boots up and joins the manet (see 6). Manet routing protocol assumption This document expects manet routing protocol to have operations listed in section 4. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 5]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 4. Required Operations for Global Connectivity This section lists features required by the proposed global connectivity mechanism. These requirements are separated as follows: 'node demands' operations that the node and its operating system must provide, 'routing protocol demands' operations required from the routing protocol, and finally 'message transport demands' communications features that must be provided. 4.1. Node Demands The operations below describe basic management of a routing table. Most routing protocol implementations supply these operations. It is not necessary to implement or support the exact same functions (i.e. this is not a specification for an API), but the same operations MUST be supported by the manet implementation. ADD_ROUTE(destination_address) Adding a route for the destination_address into the node's routing table. DELETE_ROUTE(destination_address) Deleting a route for the destination_address from the node's routing table. QUERY_ROUTE(destination_address) Looking up a route for the destination_address from the node's routing table. 4.2. Routing Protocol Command Types The Command Types below control a route for some target_address at one or more other manet nodes, namely the destination given as a parameter to the command. Most routing protocols support operations of these types. It is not necessary to implement or support the exact same functions (i.e. this is not a specification for an API), but compatible operations MUST be supported by the manet routing protocol. If destination is a multicast address, then the operation should be done on all nodes which belong to the multicast group. REMOVE_ROUTE (destination, target_address) requests removing a route to target_address at destination node(s) R. Wakikawa et.al. Expires 23 Jun 2003 [Page 6]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 INSERT_ROUTE (destination, target_address) requests adding a route to target_address at destination node(s) UPDATE_ROUTE (destination, target_address) requests updating a route to target_address at destination node(s) 4.2.1. AODV6: An Example of a Reactive Protocol ADD_ROUTE, DELETE_ROUTE, and QUERY_ROUTE are operating system's operations, i.e. they have nothing to do with AODV6. This section describes how to achieve the routing protocol command types in AODV6. REMOVE_ROUTE A node removes a route for a target address after expiration of the lifetime. The lifetime is notified with Route Reply (RREP). A node also removes the route when it receives Route Error (RERR) for the target address. INSERT_ROUTE A sender requests a route for a target address to manet nodes by sending Route Request (RREQ), and will receive RREP containing the route for the target address from the target node or intermediate nodes who know the route for the target address. AODV6 allows route insertion for the target address according to the RREP that has been received. UPDATE_ROUTE A node sends RREQ for a target address to manet nodes again, and receiving RREP containing a fresh route for the target address. AODV6 allows route updates for the target address according to the RREP that has been received. 4.2.2. Example of OLSR (Proactive) ADD_ROUTE, DELETE_ROUTE, and QUERY_ROUTE are, as in AODV6, operating system functions. This section describes how to achieve the routing protocol command types in OLSR. REMOVE_ROUTE A node removes a route for a target address through rebuilding topological information with receiving flooded Topology Control (TC) messages. In proactive manet protocol, removing route indicates that the target node is no longer active in manet. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 7]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 INSERT_ROUTE A node inserts a route for a target address through rebuilding topological information with receiving flooded TC messages. In proactive manet protocol, insert of route indicates that the target node becomes active newly active in manet. UPDATE_ROUTE A node updates a route for a target address through rebuilding topological information with receiving flooded TC messages. When a node detects both 1-hop and 2-hop neighbors change, the node should update the neighbor lists and should send HELLO messages if needed. 4.3. Message Transport Demands The operations below are basic to the communication operation of internet capable nodes. Most operating systems have these operations. It is not necessary to implement or support the exact same functions (i.e. API), but some compatible set of operations MUST be supported by any platform running a manet routing protocol. SEND_MESSAGE(dest_address(es), message) Unicast or multicast a message to a dest_address. FLOOD_MESSAGE(message) Flooding a message to manet. Same as SEND_MESSAGE when the dest_address is the flooding address. RECEIVE_MESSAGE(source_address, dest_address, message) Receive a message from a source_address to a destination_address. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 8]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 5. Internet-Gateway Discovery This section describes how to discover an internet-gateway in a manet. Discovery is required to enable manet nodes to obtain a IPv6 global address allocation and set a route towards the Internet. The discovery is given a different purpose from general route discovery operation of any manet routing protocols. 5.1. Internet-Gateway Discovery Processing A node needs a globally routable address in order to be globally reachable, so that it can receive packets from the Internet. The node needs to learn its topological location and an address of the internet-gateway that provided the node with this access to the Internet. The node therefore needs to somehow obtain a global prefix owned and distributed by an internet-gateway. The information which a node needs to know for internet connectivity is listed below. An internet-gateway advertises these items as its internet-gateway information. Internet-gateway global address The internet-gateway IPv6 global address, which can be used as a default route on manet nodes. Network prefix address The network prefix address which internet-gateway is serving. The prefix MUST be valid address and topologically correct address on the Internet. Network prefix length Prefix length of the network prefix address of an internet-gateway. Lifetime The lifetime of internet-gateway information. After expiration of the lifetime, a manet node SHOULD get fresh global information from internet-gateways again. Otherwise, the internet-gateway information is no longer valid. Therefore, the node MUST delete own IPv6 global address if the address is generated from the internet-gateway information. Internet-gateway's manet address (option) A manet address which can be used for internal communication with an internet-gateway. A node discovers an internet-gateway by receiving a message (GWADV) containing internet-gateway information. An internet-gateway may distribute internet-gateway information periodically (i.e. proactively) as part of manet routing protocol or Neighbor Discovery R. Wakikawa et.al. Expires 23 Jun 2003 [Page 9]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 Protocol (NDP). Periodic advertisements, however, are not typically used with reactive manet protocols such as AODV [1, 11] and DSR. For reactive manet protocols, a manet node sends a solicitation message (GWSOL) of internet-gateway information to internet-gateway(s) when it needs a route to the Internet, and receives a GWADV containing internet-gateway information back in response. Otherwise, this solicitation is an optional operation for proactive internet-gateway discovery. The IPv6 address used during any of these operations could be any routable address, for example a Mobile IPv6 home address. If no such address is available, the node SHOULD allocate a temporary global-scope address, generated from the well-known MANET_INITIAL_PREFIX [10]. This temporary address (MANET_TEMPORARY_ADDRESS) should be deallocated after obtaining the globally routable IPv6 address from an internet-gateway. 5.2. Receiving Internet-Gateway Information The operation which is discussed in this section is RECEIVE_MESSAGE() which contains the IP address of the internet-gateway as well as the internet-gateway information. The internet-gateway information is wrapped as GWADV_M or GWADV_N. When a manet node receives GWADV, it starts an address resolution operation and setting up a route as described in section 6. Each manet node SHOULD manage internet-gateway information. Whenever a manet node receives GWADV, it MUST update the related internet-gateway information. If the lifetime of internet-gateway information is expired, a manet node SHOULD delete internet-gateway information. A manet node SHOULD update its internet-gateway information before expiration of lifetime by receiving GWADV or soliciting internet-gateway information by GWSOL described in next section. 5.3. Reactively Soliciting Internet-Gateway Information (Optional) There are several ways to solicit advertisement of internet-gateway information (GWADV) from internet-gateways. This document explains two scheme for soliciting such information. The solicitation can use control messages defined by each reactive manet protocols as soliciting and advertising internet-gateway information, because these reactive manet protocols operate request-reply style transaction for general manet route management. New control messages/options to handle internet-gateway information without any obstacles and impacts on existing routing protocol. Any manet routing protocol may use NDP router solicitation and router advertisement messages [8] to obtain internet-gateway information. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 10]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 Link-local address is not an appropriate address scope for multi-hop networks because IPv6 prohibits forwarding packets sent to an address of link-local scope. Unfortunately, NDP uses link-local scoped addresses as IPv6 destination and source address fields for router advertisement and router solicitation messages. For that reason, the existing NDP router solicitation and router advertisement messages cannot be sent over multi-hop networks. Therefore, it is needed to adapt NDP for use in gateway discovery, but that could be done with minimum extension. Detailed information can be found at section A. This mechanism can be applied to any manet routing protocol regardless of proactive style or reactive style. 5.3.1. Reactive Manet Protocol Based Solicitation - SEND_MESSAGE (IGW_MCAST, GWSOL_M) - SEND_MESSAGE (destination_node, GWSOL_M) A node could rely on control messages of a reactive manet routing protocol to obtain internet-gateway information from an Internet Gateway. Most reactive routing protocols send a control message to find fresh route to a destination when a manet node starts communication. We call this control message a route request. To support this method of global connectivity formation, the route request of each manet protocol should be modified to carry internet-gateway information. A route request for solicitation is called GWSOL_M, and a control message (it will call route reply) for advertisement is GWADV_M, described in section 5.4.1. For these two messages, handling can be optimized independently within each manet routing protocol. The node sends GWSOL_M and receives an internet-gateway information by GWADV_M in response from the internet-gateway . For instance, the node propagates a Route Request (RREQ) message as GWSOL_M and waits for an internet-gateways to return GWADV_M (for instance, Route Reply (RREP)) containing global information. For modification of route requests, there are several ways to indicate that the route request is GWSOL_M. A new option or flag can be added to the control message for solicitation of internet-gateway information. Such control messages are sent to IGW_MCAST. This kind of modification is used when a manet node knows that it will need internet-gateway information before communication. Typical situation is that a manet node which has not configured any internet setting yet starts to communicate with a node in the Internet, and it already knows that the destination node is located in the Internet. A manet node may not know whether a destination is an Internet node or not before sending some packets to the destination. For this R. Wakikawa et.al. Expires 23 Jun 2003 [Page 11]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 situation, the manet node may first send a route request message to the destination. Typically, an internet-gateway will receive the message. The internet-gateway can determine whether or not the destination node is located within manet. If any message destined to an Internet node is received at an internet-gateway, the internet-gateway may regard it as internet-gateway information soliciting message, even if the requesting manet node already knows internet-gateway information. If an intermediate node receives any GWSOL_M for address resolution, it MAY reply with internet-gateway information, if it knows this information. However, in this case, the intermediate node SHOULD supply the internet-gateway with information about the requesting node, perhaps by using a gratuitous RREP sent to the internet-gateway. If it is not possible to send the gratuitous RREP, the intermediate node MUST NOT replay to the the solicitation. 5.3.2. NDP based Solicitation This section describes the operation of a manet node enabling it to send a solicitation message to the internet-gateways that are available (SEND_MESSAGE(IGW_MCAST, GWSOL_N)). Extensions to NDP are described in section A. A manet node requests GWADV_N with by sending GWSOL_N to IGW_MCAST. GWSOL_N is a router solicitation message extended to solicit internet-gateway information on a manet. The node MAY use an expanding ring search technique to broadcast GWSOL_N using appropriate Hop Limit values. A receiving node MUST be a member of IGW_MCAST group if it is an internet-gateway. If the receiving node is an internet-gateway, it replies with GWADV_N specifying its global prefix information and internet-gateway address. Otherwise, the node just propagates the manet router advertisement message if the hop-limit allows this. If an intermediate node receives any GWSOL_N for address resolution, it MAY reply with internet-gateway information, if it knows this information. However, in this case, the intermediate node SHOULD supply the internet-gateway with information about the requesting node, perhaps by using a gratuitous RREP sent to the internet-gateway. If it is not possible to send the gratuitous RREP, the intermediate node MUST NOT replay to the the solicitation. It depends on the behavior of the manet routing protocol whether it can use IGW_MCAST as the broadcast address in a manet. If the receiving node is not an internet-gateway and hop-limit has not been reached, the node propagates GWSOL_N ahead towards nodes having IGW_MCAST. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 12]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 5.4. Advertising Internet-Gateway Information An internet-gateway MAY advertise internet-gateway information periodically by sending GWADV. The propagation of the GWADV depends on the manet routing protocol. This draft extends two types of message, which are a manet control message and router advertisement of NDP. If a manet protocol permits to a manet node's soliciting internet-gateway information, below algorithm SHOULD be applied. This algorithm is commonly useful regardless of types of message. if (RECEIVE_MESSAGE(requesting node, IGW_MCAST, GWSOL)) { SEND_MESSAGE(requesting node, GWADV); } else if (RECEIVE_MESSAGE(requesting node, internet node's address, GWSOL_M)) { route := QUERY_ROUTE(internet node's address); if (route == null && route != default route) SEND_MESSAGE(requesting node, GWADV); } First if an internet-gateway receives any GWSOL(s) which destined to IGW_MCAST, the internet-gateway MUST return own internet-gateway information to the requesting node. If an internet-gateway receives GWSOL_M which destined to an internet node's address, it MUST search the target address in own routing table. If it found a route for the target address, it MUST NOT return internet-gateway information. Instead, it MAY return the route for the target address as part of general route discovery mechanism, because GWSOL_M is requesting the route for the target address as well. This is because GWSOL_M is an extending control message of each manet routing protocol for route discovery. If it does not find any route for the target, it SHOULD return internet-gateway information as GWADV_M. If the route for the target address can not be found in internet-gateway's routing table, it indicates the target node non-exists in the manet, but exists in the Internet. 5.4.1. Manet Routing Protocol Based Advertisement This section describes the following two operations of a manet node. - SEND_MESSAGE(requesting node, GWADV_M) - FLOOD_MESSAGE(manet nodes, GWADV_M) This section describes the first way which internet-gateway information is piggy-backed somehow into control messages of each manet protocols as GWADV_M by the below operation. It depends on manet protocol how to piggy-back internet-gateway information into control messages. Control messages are expected to reach all nodes inside manet. For a reactive protocol, it may be route reply/notify R. Wakikawa et.al. Expires 23 Jun 2003 [Page 13]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 message. For a proactive protocol, it should be any periodically flooded message. Any flooding mechanisms are allowed to disseminate the GWADV. Optimized flooding mechanism such as Multipoint Relays (MPR) is recommended. An internet-gateway also generates GWADV_M whenever it receives GWSOL_M described in section 5.3. There are two types of GWSOL_M. If the internet-gateway receives GWSOL_M which is sent to IGW_MCAST, it MUST unicast back its internet-gateway information by GWADV. The internet-gateway SHOULD also include the lifetime GWINFO_LIFETIME into its internet-gateway information. If a target address of the route request is another global address than IGW_MCAST, it searches the address in its routing table. If an internet-gateway finds the host route, it SHOULD NOT return a manet protocol route reply augmented with global connectivity information because the destination is then assumed to be inside the manet. If the address was not found in the routing table, the internet-gateway returns GWADV. 5.4.2. NDP based Advertisement This section describes the following two operations of a manet node. Extensions of NDP is described in section A. - SEND_MESSAGE(requesting node, GWADV_N) - FLOOD_MESSAGE(manet nodes, GWADV_N) This section describes another way which internet-gateway information is contained into a router advertisement message of NDP (GWADV_N). GWADV_N is expected to reach all nodes inside manet. Any flooding mechanisms are allowed to disseminate the GWADV_N. Since most routing protocols has a message flooding scheme for message passing among manet nodes, GWADV_N can be conveyed by the message flooding scheme. However, optimized flooding mechanism such as Multipoint Relays (MPR) is recommended. For a reactive protocol, an internet-gateway generates GWADV_N only when it receives GWSOL_N described in section 5.3. Then, the internet-gateway SHOULD send GWADV_N to the requesting node by unicasting, but it MAY broadcast GWADV_N whenever it receives request of GWADV_N. For a proactive protocol, GWADV_N SHOULD be disseminated periodically by an internet-gateway irrespective of receiving GWSOL_N. 5.5. Management of Manet Nodes on Internet-Gateway An internet-gateway needs to known all manet nodes which are located R. Wakikawa et.al. Expires 23 Jun 2003 [Page 14]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 in the internet-gateway managing manet. This manet nodes' information is used when internet-gateway determines a route for incoming packets described in section 7. For proactive manet protocols, an internet-gateway manages a route for all manet nodes by each manet routing protocol. Therefore, an internet-gateway can know whether a node locates inside manet or not, as soon as it checks its routing table. The management of fresh routes for all manet nodes is a basic operation of each proactive manet protocol. Reactive manet protocols do not tell routes of all manet nodes to internet-gateway. An internet-gateway MUST know all manet nodes somehow and manage these information. One approach is that an internet-gateway records a manet node information whenever the manet node solicits internet-gateway information to the internet-gateway. The manet node information can be recorded into either internet-gateway's routing table or new database for this purpose. This approach can be applied to most of reactive manet protocol, but any mechanism can be selected to know all manet nodes information. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 15]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 6. Address Resolution 6.1. Address Generation After the initial information has been received from the internet-gateway(s), following the procedure described above, a node should know the global prefix of the manet and the address of the related internet-gateways(s). First, the node SHOULD generate a global IPv6 address by using the global prefix information. The node SHOULD use its 64-bit interface ID in order to construct a valid address with the acquired prefix. Since the node is assumed to already have done Duplicate Address Detection (DAD), as defined in [10], for the link-local address before setting up the global address, a global address with host number from this link-local address is also unique if this rule is followed. If not, the node MAY perform another DAD for this global address. If the node used a temporary address generated by MANET_INITIAL_PREFIX when requesting global information, this address SHOULD now be deleted Further, all host routes for this temporary address SHOULD be deleted in intermediate nodes and internet-gateway . This is achieved by using some route maintenance operation defined in manet routing protocol, for example, the Route Error (RERR) message used in AODV6. Otherwise, those host routes MAY be left to be deleted by timeouts. temporary_addr := MANET_TEMPORARY_ADDRESS; new_addr := generate_globaladdr(internet-gateway information); if (new_addr == null) { /* internet-gateway discovery again */ } else { /* ASSERT DAD if needed */ ADD_ROUTE (new_addr); #ifdef PROTOCOL IS PROACTIVE /* Not needed for reactive */ INSERT_ROUTE (ALL_MANET_NODES, new_addr); #endif /* PROTOCOL IS PROACTIVE */ if (temporary_addr) { DELETE_ROUTE (temporary_addr); REMOVE_ROUTE (ALL_MANET_NODES, temporary_addr); } 6.2. Default Route Setting In the routing table, the node SHOULD set the following routes. We assume the global prefix is exclusively on the manet side. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 16]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 Destination/prefix length Next-Hop --------------------------- ----------------------------- Default Route/0 <Default> <internet-gateway address> Host Route/128 *<internet-gateway address> <next-hop address> * The host route is set accoding to each manet routing protocol. These routing entries should be held until expiration of the lifetime which the internet-gateway provides either with GWADV or in the reply to GWSOL. Lifetime of the default route entry and the global prefix information is stored in either GWADV_M or GWADV_N which are sent by internet-gateways. During active lifetime, the receiving node can use the global prefix and the internet-gateway as the default route entry. Note: The default route does not function as the general default route for reactive route protocols, because the default route MUST be used with the mechanism described in Section 7 in conjunction with the general route lookup mechanism. During use of the internet-gateway as a route path for communications, the node SHOULD update internet-gateway information according to periodically advertised fresh GWADV. On the other hand, the node MAY keep re-requesting internet-gateway information to the internet-gateway before the lifetime is expired on reactive manet protocol. This refreshment SHOULD be done at GWINFO_REFRESH periods for reactive manet protocol. The node can unicast GWSOL to the respective internet-gateway, or alternatively it can broadcast GWSOL to all over the manet again. The former method can allow the manet node to update the current internet-gateway status, the latter method enables the manet node to quickly discover all possible internet-gateways in the manet. Some proactive manet protocols MAY have an additional routing entry for global prefix (i.e. a network route). This is a optional entry. Manet nodes treat the network route as same as a default route. If the default route is deleted due to expiration of lifetime, the network route MUST be deleted, too. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 17]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 7. Route Examination A manet node and an internet-gateway SHOULD examine a route for packets sent from a manet node to an internet node, and vice versa. Otherwise, all the packets may be routed to an internet-gateway by a receiving manet node, because a default route is selected as a route for the packets which destination is unknown for the manet node. Route examination gives a mechanism to distinguish packets destined to a manet node and packets destined to an internet node. After distinguishment, a manet node and an internet-gateway decide either the use of default route or an active host route for a destination. For proactive manet protocols, each manet node and internet-gateways maintain all the host routes for manet nodes in the manet and a network route of the network prefix for the manet. It means that manet nodes and internet-gateways need not operate any special examinations, but they just follow general approach of route reference for a destination. In general, a manet node first examines a host route for a destination. If there is a match, a packet is sent to the destination according to the host route. If there are no host routes, but destination's prefix is equal to the network prefix of the manet, the packet is just transmitted on the local manet interface as if the node was a neighbor. Only if that rule does not match, the default route is finally employed. Route examination is specially important for reactive manet protocols. Reactive protocols MUST discover a host route for a destination whenever it communicates with some manet nodes, because reactive manet protocols do not maintain all the host routes for manet nodes in manet. In addition, an internet-gateway in reactive manet protocols gives route/topological repair for a destination to a sender by ICMPv6 error message or any control messages of manet routing protocols. Following sections describe how reactive manet protocols can operate route examinations. 7.1. Route Examination at Manet Node in Reactive Manet Protocols For reactive manet protocols, each manet nodes including internet-gateways does not know all the host routes for manet nodes in the manet. They MUST discover a host route for a destination as soon as they start to communicate with the destination. Therefore, whenever a node needs to send a packet it uses the following routing algorithm: - The node looks up its routing table for the destination node. If it found the discovered route, it sends the packet towards the destination. The default route MUST NOT be selected as a route for the destination at this point. - If not, the node MAY request a route for the destination node. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 18]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 1. If a default route exists, the node MAY wait for the above route request. 2. If a default route doesn't exist, the node obtains a default route as described in either section 5 or section 6. 3. If the node does not get the route, the node sets an route entry into the routing table with the destination node pointing towards the default route. Then the node uses the route to transmit the packet through the default route. - If the node gets a route for the destination, it sets a host route for the destination, and sends packets according to this route (not default route). First, a node looks up a route for the destination of a packet from its routing table. If the node finds a host route, it sends the packet to its destination. Otherwise, the node MAY send a route request for the destination of the outgoing data packet using its manet routing protocol. This operation is requested for reactive manet protocols, but it is not really needed for proactive manet protocols. If a default route exists, the node MAY wait for the route discovery. If no such discovery is pending and the node doesn't have default route, it uses one of the methods described in this document to obtain a default route. If the node requested a route for the destination but does not get the route, the node assumes the destination node is located on the internet and sends the packet using the default route. Sending packets towards the default route is operated by each base manet protocol. Alternatively, if there are no host routes, but destination's prefix is equal to the network prefix of the manet, the node SHOULD request a route for the destination by sending a route request. Here it depends on whether packet forwarding associated with the used manet protocol supports next hop forwarding or not. If that is the case, each intermediate node could independently decide the best route for packet out of the manet, and towards the destination. The node does not need to take care of the explicit route to the internet-gateway. However, since some manet protocol (ex. DSR) does not support next hop forwarding, a routing header MAY be used specifying the internet-gateway's address as an intermediate routing point towards the destination. The use of routing header also provides optimization and control for forwarding packet to internet-gateway. Each intermediate node does not need to decide the best route for packet (i.e. default route or host route if available), instead it simply uses a host route of the internet-gateway to forward packet to the internet-gateway. Control of forwarding route path can be relevant approach when multiple internet-gateways are placed in a manet. The minute details are described in appendix C. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 19]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 The node SHOULD know whether a route request was earlier sent for a destination whose route lookup found the default route. To prevent repeated route requests for packets destined to the destination, the node MUST put a route entry for the destination with the default route as a next hop of the destination node . The routing table of the node SHOULD be configured for the destination as shown below: Destination/prefix length Next-Hop --------------------------- ----------------------------- Default Route/0 <Default> <internet-gateway address> Host Route/128 *<internet-gateway address> <neighbor forwarding the reply> <Destination address> <Default> or <internet-gateway address> * The host route is set according to each manet routing protocol If the protocol allows, the node SHOULD send at least one request for a route of such a destination before sending data packets, even if it has already had a default route in its routing table. If the routing protocol is using an expanding ring search, care should be taken so as not to let this affect the delay too much. If the ring is expanded too far, unnecessary delay is introduced. Simulations have shown that one route request is optimal in most cases. If the node gets a route for such a destination, the node assumes the destination node is located within manet, sets a host route for the destination, and sends packets normally according to this host route. 7.2. Route Examination at Internet-Gateway in Reactive Manet Protocols An internet-gateway SHOULD have host routes for all the manet nodes which exists in its manet network. Whenever the internet-gateway receives the packets sent by manet nodes and forwards them, it examines the route path for the packets' destination address. If the internet-gateway finds the host route towards the manet interface for the destination, it indicates the destination node must be at same manet network and it is possible to have a host route between the source and the destination node. The internet-gateway sends a control messages such as route error message to notify a sender node to retry discovery a route for the destination in order to obtain the host route instead of the default route. These control messages are subject to rate limiting in the same manner as is done for ICMPv6 messages [3]. If the sender node believes the internet-gateway is next to the destination node (i.e. intermediate node), it SHOULD ignore the route error messages, and SHOULD not re-discover the host route. If a node always knows that it is intermediate node for a particular destination by something like R. Wakikawa et.al. Expires 23 Jun 2003 [Page 20]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 precursor list, the internet-gateway MAY determine whether it sends route error message or not with the precursor list. On the other hand, if the internet-gateway finds an appropriate route path, which is not the host route towards the manet interfaces, it routes the packets to the destination on the route. Management of the host routes are basically operated by each manet routing protocols. But internet-gateway can also learn the host routes when it receives any GWSOL from manet nodes. For these host routes, the internet-gateway discards the host routes, if it does not get any GWSOL before the lifetime of the host route is expired. When the internet-gateway receives a packet from the manet network interface, it searches a host route for the destination address from its routing table . If it finds the host route, it MUST route the packet and return an ICMPv6 Redirect Message or a route error message to the sending manet node. If it does not find the address from the list it forwards the packet to the Internet. When the internet-gateway receives a packet from the Internet, destined to a manet node, it forwards the packet towards the manet node by using a host route generated by the manet protocol. If such a route does not exist, it is normally requested by the manet protocol. Hence, no internet-gateway specific action is needed for a packet going from the Internet to the manet. If a manet node leaves the manet, the internet-gateway MUST detect the leaving of the manet node and MUST delete the host route for that manet node. This can be triggered by receiving route error messages from other manet nodes detecting topology changes by managing HELLO messages. Even if the internet-gateway keeps the invalid host route for the manet node due to lack of route error messages, the host route SHOULD be deleted at the lifetime expiration of the route. After deletion of the host route, the internet-gateway MUST operate the following procedure. If the destination address of the host route was configured by the internet-gateway's prefix, the address of the manet node is no longer valid on the Internet because of leaving of the manet node. Therefore, the internet-gateway MUST send ICMP Unreachable message for packets destined to the manet node. On the other hand, if the destination address of the host route is a Mobile IPv6 home address, the internet-gateway MUST route packets to the home agent according to its routing table and MUST NOT send ICMP Unreachable message for the packets. This way, communication sessions binded with the home address of the manet node will not be interfered by receiving the ICMP Unreachable message. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 21]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 8. Error Handling 8.1. Receiving ICMPv6 Error Message A manet node usually receives two types of ICMPv6 messages from internet-gateways, the ICMPv6 Destination Unreachable Message and the ICMPv6 Redirect message. These messages are propagated over the manet and their use is the same as for any other IP network. 8.1.1. ICMPv6 Destination Unreachable Message If a manet node receives an ICMPv6 Destination Unreachable message after sending data packets using a host route, the node MUST delete this entry in the routing table. If needed, the node can rediscover a route for the destination by each manet routing protocol once. This exact behavior depends on the manet routing protocol in use. If the node can not get any route for the destination, the node SHOULD NOT operate any discovery operation for the destination for a while. 8.1.2. ICMPv6 Redirect message If the manet node receives an ICMPv6 Redirect message from an internet-gateway, the manet node SHOULD use the host route instead of the default route. Getting the host route, the manet node uses its method of learning a manet destination, e.g., by sending a route requests for the destination. 8.2. MANET Routing Protocol Repair Message The manet node MUST process the control message according to the original manet routing protocol. If manet is operated by a reactive manet protocol, a manet node would often receive a control message of each manet routing protocol to repair a route to a destination due to the change of network topology. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 22]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 9. Protocol Constants Parameter Name Value ---------------------- ----- ALL_MANET_GW_MULTICAST TBD (ff1e::xx/64 global-scope) GWINFO_LIFETIME TBD (10 seconds) GWINFO_REFRESH GWINFO_LIFETIME * 0.8 10. Security Considerations This document does not define any method for secure operation of the protocol. There is no widely accepted model for securing state-altering protocols in manet. A reason for this is the lack of scalability in security association setup among manet nodes arriving from arbitrary domains. Before well accepted SA setup methods exist, any node can pretend to be an internet-gateway and result in other nodes setting their routing state in a way denying proper operation of this service. Acknowledgments The authors would like to thank Elizabeth Royer for her comments on streamlining some aspects of the design. The authors thank Thierry Ernst for his comments. The authors thank Thomas Clausen for his many improvements having to do with proactive routing protocols. The authors also thank Alex Hamidian for his contributions and improvements to section 7.2. References [1] R. Alter. ARPA Network Control Center. Request for Comments 356, Internet Engineering Task Force, June 1972. [2] T. Cluasen and P. Jacquet. Optimized link state routing protocol. Request for Comments (Experimental) 3561, Internet Engineering Task Force, October 2003. [3] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet protocol version 6 (ipv6) specification. Request for Comments (Draft Standard) 2463, Internet Engineering Task Force, December 1998. [4] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6) Specification. Request for Comments (Proposed Standard) 1883, Internet Engineering Task Force, December 1995. [5] R. Draves and R. Hinden. Default Router Preferences, More-Specific Routes, and Load Sharing. Internet Draft, Internet Engineering Task Force, June 2002. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 23]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 [6] D. Johnson, D. Maltz, and Y. Hu. The dynamic source routing protocol for mobile ad hoc networks (work in progress). Internet Draft, Internet Engineering Task Force, April 2003. [7] D. Johnson, C. Perkins, and J. Arkko. Mobility support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, June 2003. [8] 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. [9] R. Ogier, , F. Templin, and M. Lewis. Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) (work in progress). Internet Draft, Internet Engineering Task Force, April 2003. [10] 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. [11] 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. [12] C. Perkins, E. Royer, and S. Das. Ad hoc on demand distance vector (AODV) routing. Request for Comments (Experimental) 3561, Internet Engineering Task Force, July 2003. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 24]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 A. ICMPv6 and Neighbor Discovery Protocol Extensions for MANET This section describes how to handle NDP packets to sent out over multi-hop networks such as the manet. Both router solicitation and router advertisement messages can not be sent over multi-hop networks, because the link-local scope is not well defined for manets. NDP assumes to use link-local scoped addresses as IPv6 destination and source address fields for router advertisement and router solicitation messages. Link-local address is not an appropriate address scope for multi-hop networks because IPv6 prohibits to forward packets sent to an address of link-local scope. For doing so, NDP packets must be modified. The following sections describe the modified "Router Solicitation" and "Router Advertisement" packet formats. A.1. Modified Router Solicitation A host sends manet Router Solicitations in order to prompt internet-gateways to generate manet Router Advertisements. The modified manet Router Solicitations MUST have a new M flag set and they MAY include a Source manet address option identifying the sender. The Hop Limit field in the IPv6 header SHOULD be set to an appropriate value. This can be the default constant usually inserted when unicasting packets, or chosen e.g., according to broadcasting/flooding scheme such as an expanding ring search technique. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Manet Router Solicitation Flag (M) A 1-bit Manet Router Solicitation flag. When set, it indicates that the Router Solicitation message can be sent over a multi-hop network. The internet-gateways MUST NOT forward this message to the nodes on the Internet. Whenever the flag is set, a Source Manet address option is required. The Manet Address in the Source Manet Address sub-option is used for management Manet nodes at the internet-gateway. Reserved Reduced from a 32-bit field to a 31-bit field to account for the addition of the Manet Router Solicitation (M) flag. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 25]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 Options: Source Manet address The Manet global address of the sender. This SHOULD be included even if the Source Address is the temporary address generated with MANET_INITIAL_PREFIX. A.2. Modified Router Advertisement An internet-gateway sends out a Manet Router Advertisement message either periodically or response to a Manet Router Solicitation. The internet-gateway allows to send unsolicited Manet Router Advertisements, although sending them periodically would generate unnecessary packets in the Manet. The modified Manet Router Advertisement MUST have the 'N' flag set. The Hop Limit field in the IPv6 header SHOULD be set to an appropriate value if the expanding ring search algorithm in Manet Broadcasting is used. The `N' flag MUST be set in the Manet Router Advertisements and it MUST carry the address of the internet-gateway and the global prefix information by the Prefix Information Option [8, 7]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|N|Reserved | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Manet Router Advertisement Flag (N) 1-bit Manet Router Advertisement flag. When set, indicates that the Router Advertisement message is only for Manet nodes and can be sent over multiple hop Manet nodes. The internet-gateways MUST NOT forward this message to nodes on the Internet. Whenever the flag is set, the sender MUST include a Prefix Information option with a globally routable prefix. A Source Manet Address option may be required, depending on the Manet protocol. A.3. Source Manet Address Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Manet Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R. Wakikawa et.al. Expires 23 Jun 2003 [Page 26]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 Type 10 Length 3 The length of the option (including the type and length fields) in units of 8 octets. Manet Address The 128 bit IPv6 address for the original source of the packet. The Source Manet Address option contains the Manet address of the sender of the packet. It is used in Manet Router Solicitation, and Manet Router Advertisement packets. Since the source address field in the IPv6 header might be changed by intermediate nodes running a Manet routing protocol such as AODV, this option can indicate the exact sender Manet address to receivers. These options MUST be silently ignored for other Neighbor Discovery messages. A.4. Changing the ICMPv6 Redirect An internet-gateway and manet nodes basically obey [8] except for below changes. In [8], gateway can specify only link-local address in a source address field of IPv6 header. In manet situation, an internet-gateway is allowed to specify manet global addressor global address in a source and destination address fields of an IPv6 header. An ICMPv6 Redirect message [8] sent to a Manet node MAY include the Source Manet address option and is used to notify that this destination address is located on this manet. It is used by the internet-gateway to notify a sending node that a destination is located on this manet and instead should send packets to it using ordinary manet routing. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 27]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 B. Mobile IPv6 Extensions for MANET The global connectivity for manet is defined for any global address configured to any manet network interface of a manet node, and it defines a method for configuring a globally routable address for such an interface. Once such address is available, global mobile-initiated sessions, such as web browsing or DNS queries, can be used. A topologically correct address in the IP header source field is sufficient for packets sent from the manet node in such sessions. If the address is a more permanent one, it can be used as a Mobile IPv6 [7] home address, to provide an always-on reachability from the fixed Internet with a statically known address. In such a case, reachability can be provided even when the node moves between manets and different points of the fixed network. A mobile node should use Mobile IPv6 when it is not on its home link. When arriving at a visited link in the fixed network, it uses neighbor discovery to detect movement. If it is not at home, it registers with its home agent using a globally routable address from the visited network. In manet, Mobile IPv6 replaces the neighbor discovery part of its movement detection with globally routable address acquisition, as defined in this document. The movement detection can e.g. be bypassed by the routing daemon by it locally in the host passing a router advertisement to the Mobile IPv6 Neighbor Discovery -based movement detection algorithm. The mobile node then uses the globally routable address acquired from the internet-gateway as its care-of-address when possibly performing a home registration. If no home registration is needed, the mobile node is at home in the manet and the prefix of its home address belongs to its internet-gateway. If the mobile node starts Return Routability procedure for route optimization, HoTI and CoTI are sent through its internet-gateway and HoT and CoT are returned to the mobile node via the internet-gateway. There is no special operation for Return Routability on manet. All manet nodes SHOULD support Mobile IPv6 Correspondent Node (CN) requirements describe in [7], so that they understand the home address option. Manet nodes using Mobile IPv6 with global connectivity support whatever Mobile IPv6 functionality they wish to use. Manet mobile nodes SHOULD NOT use home address options and CN binding updates when exchanging routing information with other nodes in the manet. This keeps control packets smaller and does not require manet nodes to support full CN functionality. A manet mobile node MAY insert a routing header to an outgoing data packet for explicit gateway routing in addition to the possible home R. Wakikawa et.al. Expires 23 Jun 2003 [Page 28]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 address option. If the node is a CN, the possible routing header injected by Mobile IPv6 is modified by inserting the entry for gateway prior to the entry for home address, and setting the segments left to two. C. Use of Routing Header for Transmission of Packets along a Default Route As described in section 7.1, each manet node have two way to send data along a default route when it decides to use of default route for transmission packet. The node supports both but select one depending on the base Manet protocol and network topology. - Without IPv6 routing extension header the sender sends the packet to the global IPv6 address and relies upon next hop routing in the other nodes. - With IPv6 routing extension header the sender uses the internet-gateway address in the destination address of the IPv6 header and the real destination address in the routing header. This document recommends to use the second method for the following reason. Assume the destination is inside the Manet but the sender can not reach the destination via a host route. In such a case, if the node sends packets to the destination via the internet-gateway without a routing header, an intermediate node who has a host route for the destination will route packets to it directly; but the sender node is not aware of this. The sender is never notified that packets is not passing through the internet-gateway. If the sender always uses a routing header, every packet is explicitly routed through the internet-gateway. If the internet-gateway detects that the destination is located within the Manet, the internet gateway can send an ICMPv6 Redirect error message to the sender. After receiving the ICMP Redirect messages, the node can send a route request for the destination to learn the host route. Using a routing header is also preferable if there are more than two internet-gateways, because the node then have the ability to decide which internet-gateway is the best, by distance in hops, or by some other priority. By assign a priority number for each internet-gateway, the route reply message and the Manet Router Advertisement messages could be extended to support a candidate internet-gateway option in it. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 29]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 D. AODV6 Operation with Global Connectivity for IPv6 MANET This section describes how to apply embedding of the Internet connectivity acquisition to a reactive manet routing protocol, AODV [12], more precisely, to its IPv6 variant [11]. All the operation except for a specific explanation in this section follow the descriptions presented earlier in this document. D.1. Additions to AODV6 specification The AODV6 protocol is used as is, except for the addition of one flag. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |J|R|G|D|U|I| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RREQ ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination IP Address (128-bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Originator IP Address (128-bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 IP version 6 (in [3]), except for the following: Internet-Global Address Resolution Flag (I) Internet-Global Information Flag: used for global address resolution. This flag indicates that the destination node requests global connectivity. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 30]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination IP address (128-bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Originator IP address (128-bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the IPv6 Route Reply message (RREP) is illustrated above, and contains the same fields with the same functions as the RREP message defined for IP version 6 (in [3]), except for the following. Internet-Global Address Resolution Flag (I) Internet-Global Information Flag: used for global address resolution. This flag defines that this reply contains information about an internet gateway. D.2. Global Address Resolution This section describes how to obtain a globally routable IPv6 address from an internet-gateway by sending an AODV6 Route Request (RREQ) to IGW_MCAST. When a node sends a RREQ, requesting global address resolution, it can as IPv6 source address specify any arbitrary address with global scope currently in use by one of its interfaces. This could, for example, be its Mobile IPv6 home address or an address created temporary from the MANET_INITIAL_PREFIX. The node then broadcasts the RREQ using the 'I' flag and specifies IGW_MCAST as the destination in the RREQ destination address field. When an internet-gateway receives a RREQ with the `I' flag set, it checks its routing table for an entry towards the receiving network interface and updates it with an entry of for requesting node using the source address specified in the RREQ. The internet-gateway then constructs a Route Reply (RREP with the 'I' flag set), and u it to the requesting node. The IPv6 header fields should be built as in normal AODV6 operation. The global prefix information can be derived using the responding gateway's IPv6 address and the prefix length specified in the RREP. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 31]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 In this way, the node will know both the address of the gateway and the globally routable prefix. After acquiring a topologically correct global IPv6 address, the node first deletes the temporary address from the MANET_INITIAL_PREFIX. If the node didn't create this temporary address, the node can continue using the arbitrary address, e.g. the Mobile IPv6 home address, used during communication with the gateway. The node then broadcasts a Route Error (RERR) with the temporary address to delete all the related host routes. This RERR could also create new reverse routes for the newly created global IPv6 address at intermediate nodes and internet-gateways. It is, however, not permitted by the current AODV6 specification to setup reverse routes using RERR messages. Another RREQ can therefore be sent over the manet to create these reverse routes at intermediate nodes. These reverse routes will become the route path to the internet-gateway for the nodes newly created global address. The internet-gateway should insert the nodes host route into its routing table. The old entry in the gateway related to the temporary address will be discarded after lifetime expiration. When the node sends packets to the internet, it MAY use any of the two methods specified in section 7.1 and appendix C. If the node chooses to send a packet to the Internet without using a routing header, some intermediate nodes may generate RERR message because they do not have an active route to the packet's destination, see the AODV specification [12] for more details about this. To avoid these unnecessary RERRs, a default route is defined as the active route in this document. This means that an intermediate node should have an active default route. If the intermediate node doesn't have a host route for a destination, it should route packets towards the default route. If the node instead uses a routing header, the address of the internet-gateway should be specified in destination address field of the IPv6 header. All intermediate nodes on the route path to the internet-gateway will then have a host route to the destination address, ie. the internet-gateway address. The intermediate node cannot generate a RERR message for outgoing packets destined outside of the manet. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 32]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 E. Changes from draft-wakikawa-manet-globalv6-02 - Editorial updates - Section 7.2: add the operation of an internet-gateway when a manet node leaves the internet-gateway's manet. - Section 7.2: change the operation of ICMP Redirect message for an internet-gateway. The internet-gateway MUST route original packets to the destination while sending ICMP Redirect messages. - update AODV packet format. 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 EMail: ryuji@sfc.wide.ad.jp EMail: charliep@iprg.nokia.com Phone: +81-466 49-1394 Phone: +1-650 625-2986 Fax: +81 466 49-1395 Fax: +1 650 625-2502 Jari T. Malinen Anders Nilsson Communications Systems Lab Dept. of Communication Systems Nokia Research Center Lund Institute of Technology 313 Fairchild Drive Box 118 Mountain View, California SE-221 00 Lund 94043 USA Sweden EMail: Jari.T.Malinen@nokia.com E: anders.nilsson.024@student.lth.se Phone: +1-650 625-2355 Phone: +46 46-39 72 92 Fax: +1 650 625-2502 Fax: +46 46-14 58 23 Antti J. Tuominen Theoretical Computer Science Lab Helsinki University of Technology P.O.Box 9201 FIN-02015 HUT Finland Email: anttit@tcs.hut.fi Phone: +358 9 451 5136 Fax: +358 9 451 5351 R. Wakikawa et.al. Expires 23 Jun 2003 [Page 33]
Internet Draft Global Connectivity for IPv6 Manets 23 Oct 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. R. Wakikawa et.al. Expires 23 Jun 2003 [Page 34]