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]
Contents Status of This Memo Abstract i 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]
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]
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]
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]
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-gateway Advertisement (GWADV) A message to advertise internet-gateway information. There are two types, GWADV_M and GWADV_N: GWADV_M GWADV_N Extends the manet protocol; a control message is specified for each particular protocol to advertise internet-gateway information 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 GWSOL_N Extends the manet protocol; a control message is specified for each particular protocol to solicit internet-gateway information 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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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> Host Route/128 *<internet-gateway address> <Destination address> <internet-gateway address> <neighbor forwarding the reply> <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]
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]
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]
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]
[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]