Mobile Ad Hoc Networking Working Group Ryuji Wakikawa INTERNET DRAFT Keio University 18 Jul 2005 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-04.txt Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on December 18, 2005. Copyright Notice Copyright (C) The Internet Society (2005). R. Wakikawa et.al. Expires 18 Jan 2005 [Page i]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 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. Contents Status of This Memo i Abstract ii 1. Introduction 2 2. Terminology 3 3. Overview 4 4. Conceptual Data Structures and Messages 5 4.1. Conceptual Data Structures . . . . . . . . . . . . . . . 5 4.2. Internet-Gateway Information . . . . . . . . . . . . . . 5 4.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3.1. Modified Router Solicitation . . . . . . . . . . 7 4.3.2. Modified Router Advertisement . . . . . . . . . . 8 4.3.3. Modified Routing Signaling . . . . . . . . . . . 8 4.3.4. Changing the ICMPv6 Redirect . . . . . . . . . . 8 5. Manet Node Operation 10 5.1. Receiving Internet-Gateway Advertisement . . . . . . . . 10 5.2. Address Autoconfiguration . . . . . . . . . . . . . . . . 10 5.3. Default Route Setup . . . . . . . . . . . . . . . . . . . 11 5.4. Source Address Selection . . . . . . . . . . . . . . . . 12 5.5. Receiving ICMPv6 Error Messages . . . . . . . . . . . . . 12 5.6. Use of Routing Header . . . . . . . . . . . . . . . . . . 13 5.7. Interaction with Mobility Protocols . . . . . . . . . . . 14 6. Reactive Manet Node Operation 16 6.1. Soliciting Internet-Gateway Advertisement (Optional) . . 16 6.2. Route Selection for reactive protocols . . . . . . . . . 16 7. Internet Gateway Operation 19 7.1. Joining a Mobile Ad-hoc Routing Domain . . . . . . . . . 19 7.2. Sending Internet-Gateway Advertisement . . . . . . . . . 19 R. Wakikawa et.al. Expires 18 Jan 2005 [Page ii]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 7.3. Receiving Internet-Gateway Solicitation . . . . . . . . . 20 7.4. Management of Manet Nodes on Internet-Gateway . . . . . . 20 7.5. Route Examination . . . . . . . . . . . . . . . . . . . . 21 8. Protocol Constants 23 9. Security Considerations 23 Acknowledgments 23 References 23 Appendices 25 Authors' Addresses 25 R. Wakikawa et.al. Expires 18 Jan 2005 [Page 1]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 1. Introduction A mobile ad-hoc network (manet) is built dynamically when a set of manet routers creates 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. There are routing protocols standardized at IETF such as AODV [10], OLSR [2], DSR [6], and TBRPF [9]. Global connectivity is often required for manet routers 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. 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 for 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 R. Wakikawa et.al. Expires 18 Jan 2005 [Page 2]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 2. Terminology manet node A node located inside a manet 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. manet local address A manet node's identity address in manet. The address is used for ad-hoc routing. 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 route A route to the Internet (i.e. internet-gateway). It can be treated as a default route or a network route. manet route A route to other manet nodes. It is typically host route in a manet. internet-gateway information The gateway's IP routing prefix, prefix length, and lifetime. internet-gateway advertisement A message to disseminate internet-gateway information to a manet. internet-gateway solicitation A message to solicit an internet-gateway advertisement. internet-gateways multicast address (IGW_MCAST) Specifically, ALL_MANET_GW_MULTICAST, the IPv6 global multicast address for all internet-gateways in a manet. R. Wakikawa et.al. Expires 18 Jan 2005 [Page 3]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 3. Overview 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. A manet node discovers an internet-gateway by receiving an internet-gateway advertisement. Each internet-gateway MAY disseminate internet-gateway advertisement proactively. Periodic advertisements, however, are not typically used with reactive manet protocols such as DYMO [1], AODV [10] and DSR[6]. Thus, a manet node can solicit internet-gateway advertisement when it needs a route to the Internet, and will receive internet-gateway advertisements back in response. This solicitation is optional when an internet-gateway periodically floods a internet-gateway advertisement. In this way, the reactive and proactive route discovery features of each manet routing protocol are not disturbed. For these internet-gateway solicitation and advertisement, we introduce modifications to the Neighbor Discovery Protocol (NDP) [8] and each manet routing protocol. Operators can use the preferred one to implement global connectivity. The proposed method targets all manet protocols regardless of whether they are reactive and proactive. An advertisement from the internet-gateway provides prefix information, and advertisement processing possibly resolves a route to the gateway, inserted as a route toward the Internet (Internet 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. After accepting an advertisement from the internet-gateway, the manet node configures a routable IP address from the prefix of the gateway and inserts the gateway address as an internet route. 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 18 Jan 2005 [Page 4]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 4. Conceptual Data Structures and Messages 4.1. Conceptual Data Structures This specification assumes that all manet nodes support the following data structures. These structures are similar to the data structures defined in Neighbor Discovery Protocol (NDP)[8]. These structures can be implemented using variety of techniques. An example to implement these structures is extending the structures implemented for NDP. - Internet Gateway List (IGW List) A list of available internet-gateways to which packets may be sent. In this list, the internet-gateway information described later must be stored. Each entry also has an associated invalidation timer value (extracted from internet-gateway Advertisements) used to delete entries that are no longer advertised. The entries are listed below: 1. Internet Gateway Global Address 2. Internet Gateway Lifetime 3. Internet Gateway manet-local Address (optional) - Internet Gateway Prefix List (Prefix List) A list of prefixes that are advertised by internet-gateways. This Prefix List entries are created from information received as Internet-Gateway Advertisements. Each entry has an associated invalidation timer value (extracted from the internet-gateway advertisement) used to expire prefixes when they become invalid. The entries are listed below: 1. Internet Gateway Prefix Address 2. Internet Gateway Prefix Address Length 3. Internet Gateway Prefix Preferred Lifetime 4. Internet Gateway Prefix Flag 5. Number of advertised Internet Gateways 4.2. Internet-Gateway Information A manet node needs a globally routable address in order to be globally reachable, so that it can receive packets from the Internet. The manet node needs to learn its topological location and an address R. Wakikawa et.al. Expires 18 Jan 2005 [Page 5]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 of the internet-gateway that provided the node with this access to the Internet. The node therefore needs to 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. This internet-gateway information is introduced to keep compatibility with NDP [8]. 1. Internet-gateway global address The internet-gateway IPv6 global address, which can be used as a route to the Internet on manet nodes. 2. Internet Gateway Prefix address The network prefix address which internet-gateway is serving. The prefix MUST be valid address and topologically correct address on the Internet. 3. Internet Gateway Prefix length Prefix length of the network prefix address of an internet-gateway. 4. Internet Gateway Prefix Preferred Lifetime The addresses generated from the prefix via stateless address autoconfiguration remain preferred [ADDRCONF]. A value of all one bits (0xffffffff) represents infinity. See [ADDRCONF]. After expiration of the lifetime, the manet node MUST delete its autoconfigured IPv6 global address. 5. Internet Gateway Lifetime The lifetime of an internet-gateway. After expiration of the lifetime, a manet node MUST NOT use the internet gateway as a route toward the Internet. It SHOULD get fresh internet-gateway information. 6. Internet-gateway's manet address (option) A manet address which can be used for internal communication with an internet-gateway. 4.3. Messages This specification defines two messages such as internet-gateway solicitation and internet-gateway advertisement. The internet-gateway solicitation can be implemented as either a modified Route Solicitation or an extended message of routing protocol (ex. a router request of DYMO [1]). Likewise, the internet-gateway advertisement can be defined as either a modified Router Advertisement or an extended message of routing protocol R. Wakikawa et.al. Expires 18 Jan 2005 [Page 6]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 such as a router reply of DYMO. In this specification, we introduce extension of a router solicitation and a router advertisement. The routing protocol messages must be modified to carry the internet-gateway information defined in Section 4.2. DYMO has already supported the global connectivity in their messages defined in [1]. The similar extension can be used in the case of the other routing protocols. As we explained in [12], a router solicitation and a router advertisement are not originally designed to route over multi-hop, because NDP [8] is operated between on-link nodes and routers. NDP assumes to use link-local scoped addresses as the 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. 4.3.1. Modified Router Solicitation Router solicitation is extended to have a flag called ``Manet Router Solicitation 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Manet Router Solicitation Flag (M) 1-bit Manet Router Solicitation flag. The flag indicates that the Router Solicitation can be sent over a multi-hop network. The internet-gateways MUST NOT forward this message to the nodes on the Internet. 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 18 Jan 2005 [Page 7]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 4.3.2. Modified Router Advertisement 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. The flag 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. The extended Router advertisement MUST have a prefix information option defined in [8]. The prefix information option is not modified. However, L flag must be unset and the Valid Lifetime field MUST be set to zero for the modified router advertisement, since on-link determination can not be used for Manet. 4.3.3. Modified Routing Signaling DYMO specifies gateway concept in DYMO messages [1]. 4.3.4. Changing the ICMPv6 Redirect For global connectivity, an ICMPv6 Redirect message [8] 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. According to [8], a gateway MUST send an ICMPv6 Redirect messages from only link-local address. However, in manet situation, an internet-gateway needs to send it from non link-local address due to multihop routing. Thus, we relax this limitation in this specification. An internet-gateway can send the redirect message from either a manet local address or a global R. Wakikawa et.al. Expires 18 Jan 2005 [Page 8]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 address. In the target address field, the internet-gateway SHOULD insert the wildcard IPv6 address (i.e. ::). R. Wakikawa et.al. Expires 18 Jan 2005 [Page 9]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 5. Manet Node Operation For internet connectivity, each manet node needs to generate IPv6 global address and configure a route to the Internet. 5.1. Receiving Internet-Gateway Advertisement When a manet node receives an extended router advertisement as an internet-gateway advertisement, it first verifies the message according to the NDP specification [8]. Except for this verification, the manet node MUST conduct additional check as follows: - The source address MUST be non link-local address. If the message is sent from a link-local address, the message MUST be silently discarded. - The message MUST have N flag set. If the flag is unset, the manet node MUST silently be discarded while it being inside a manet. The manet node MAY keep the information of the route advertisement and will use the information when it is away from the manet. - The message MUST have a correct prefix information option. Otherwise, the message MUST silently be discarded. Each node MUST verify following items. * The prefix address must be global routable prefix address * The prefix length must be valid length. (i.e. shorter than 128 and greater than 0). * Prefix Valid Lifetime MUST be set to zero * L flag MUST be unset and A flag MUST be set * Prefix Preferred Lifetime must be greater than zero. After successful verifications, the manet node keeps the internet-gateway information into the prefix list and the default router list as described in Section 4.1. 5.2. Address Autoconfiguration After the first internet-gateway advertisement has been received from the internet-gateway(s), a manet node SHOULD generate a global IPv6 address by using the internet-gateway information. The node R. Wakikawa et.al. Expires 18 Jan 2005 [Page 10]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 SHOULD use its EUI-64 in order to construct a valid address with the acquired prefix. Since the manet node is assumed to already have done Duplicate Address Detection (DAD), as defined in [11], 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 DAD is not yet completed, the manet node MAY perform another DAD for this global address. How to operate DAD is not in the scope of this documentation, but can be [11]. If the manet node used a temporary address generated by MANET_INITIAL_PREFIX when requesting global information, this address SHOULD 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. 5.3. Default Route Setup The manet node SHOULD set a route toward the Internet in the routing table. An example of a routing table is as follows: Destination/prefix length Next-Hop -------------------------- ----------------------------- Internet Route * default (::) ** <internet-gateway address-A> default (::) <internet-gateway address-B> : : Host Route/128 *** <internet-gateway address> <next-hop address> * If there are several internet-gateways, the manet node may insert the multiple entries for the internet route. ** The internet route may be stored in IGW list and refered the list whenever a manet node fails to search a manet route for a destination. *** Note that the host route is set according to each manet routing protocol. These routing entries MUST be held until expiration of the Prefix lifetime. The Router lifetime of the default route entry and the global prefix information is the same with the prefix lifetime. During active lifetime, the receiving node can use the global prefix and the internet-gateway as the default route entry. Note: The R. Wakikawa et.al. Expires 18 Jan 2005 [Page 11]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 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.5 in addition to the general route lookup mechanism. During active use of the internet-gateway as a route path for communications, the manet node SHOULD update internet-gateway information by receiving internet-gateway advertisements. If necessary, the manet node can unicast an internet-gateway solicitation to the respective internet-gateway, or alternatively it can broadcast an internet-gateway solicitation to all over the manet again. The former method can allow the manet node to update the current internet-gateway status, while the latter method enables the manet node to quickly discover all possible internet-gateways in the manet. 5.4. Source Address Selection Each manet node carefully select a source address for outgoing communication. For communication, the manet node MUST NOT use its link-local address. The following decision MUST be made before sending packets. - If a destination is located outside the manet, it MUST use its global address. The global address can be home address. - If a destination is located within the manet, it SHOULD use it manet-local address. However the manet node MAY use its global address. 5.5. Receiving ICMPv6 Error Messages If a manet node receives an ICMPv6 Destination Unreachable message after sending data packets along a manet route, the node MUST delete the manet route from the routing table. On the other hand, if the manet node uses an internet route, it SHOULD NOT delete the internet route. But it just stop sending packets to the destination. 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. 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 R. Wakikawa et.al. Expires 18 Jan 2005 [Page 12]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 its method of learning a manet destination, e.g., by sending a route requests for the destination. 5.6. Use of Routing Header Each manet node sends data along an internet route when the destination of transmission packets is located on the Internet. The node has different way to transmit packets through the Internet Gateway. - Without IPv6 routing extension header The sender sends the packet to an IP address of an internet node 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. When reactive protocol is used, each node may know only partial topology or link. In such case, if a packet meant for an internet node is sent without a routing header, each intermediate node will try to discover a manet route due to absence of the routing entry for the destination address. For example, table driven routing protocol such as AODV has this problem. Intermediate nodes of a manet route only knows neighbor's information on its routing table. Intermediate nodes do not know that the destination address is located on the Internet until route discovery is operated. If the packet is sent with a routing header, the destination address of the packet is the internet-gateway while it is routed within the manet. Therefore, the intermediate node can route the packet to the internet-gateway without generating additional route discovery. Assume the destination is inside the manet but the sender can not reach the destination via a host route. Such the case can be occurred when reactive manet routing protocol is used. If the manet 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 R. Wakikawa et.al. Expires 18 Jan 2005 [Page 13]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 the ICMPv6 Redirect messages, the manet node can re-discover a manet route for the destination. 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. 5.7. Interaction with Mobility Protocols If a global address is a more permanent one on a manet node, 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 will receive router advertisements 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 uses the extended router advertisement to detect node's movement and to generate a globally routable address (i.e. Care-of address). The same mechanism below can be applied to the NEMO Basic Support protocol [5]. 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 address option. If the node is a CN, the possible routing header injected by R. Wakikawa et.al. Expires 18 Jan 2005 [Page 14]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 Mobile IPv6 is modified by inserting the entry for gateway prior to the entry for home address, and setting the segments left to two. R. Wakikawa et.al. Expires 18 Jan 2005 [Page 15]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 6. Reactive Manet Node Operation This section introduces additional operations for manet nodes running reactive manet routing protocols. 6.1. Soliciting Internet-Gateway Advertisement (Optional) A manet node sends an internet-gateway solicitation in order to prompt an internet-gateway(s) to generate internet-gateway advertisements. When an internet-gateway uses the extended router solicitation as the internet-gateway solicitation, following steps are required. - It must set N flag in the router solicitation. - The source address of the message MUST NOT be a link local address. 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 [11]. This temporary address (MANET_TEMPORARY_ADDRESS) should be deallocated after obtaining the globally routable IPv6 address from an internet-gateway. - The manet node unicasts the router solicitation to an internet-gateway if it has already known the address of the internet-gateway. Otherwise, it floods the message to a new all internet-gateway multicast address (i.e. ALL_MANET_GW_MULTICAST). - 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. 6.2. Route Selection for reactive protocols In reactive manets, a manet node and an internet-gateways do not know the complete topology of the manet which they belong to. They MUST discover a host route for a destination as soon as they start to communicate. Therefore, whenever a node needs to send a packet it uses the following routing algorithm: R. Wakikawa et.al. Expires 18 Jan 2005 [Page 16]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 - 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 internet 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. 1. If an internet route exists, the node MAY wait for the above route request. 2. If an internet route does not exist, the manet node obtains a default route. 3. If the manet node does not get any route, the node sets an route entry into the routing table with the destination node pointing towards the internet route. Then the manet node uses the route to transmit the packet through the internet route. - If the manet node gets a route for the destination, it sets a host route for the destination, and sends packets according to this route (not the internet route). 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 internet route as a next hop of the destination node . An example routing table of the node SHOULD be configured for the destination as shown below: Destination/prefix length Next-Hop -------------------------- ----------------------------- Internet Route :: (default) <internet-gateway address> Host Route/128 <internet-gateway address> <next-hop address> <Destination address> <internet-gateway address> Note that 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. R. Wakikawa et.al. Expires 18 Jan 2005 [Page 17]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 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. R. Wakikawa et.al. Expires 18 Jan 2005 [Page 18]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 7. Internet Gateway Operation This section describes required operation for internet-gateways. 7.1. Joining a Mobile Ad-hoc Routing Domain An internet-gateway joins a mobile ad-hoc network with a manet interface while it maintains the Internet connectivity with other interfaces. The internet-gateway requires to listen routing messages in order to collect routing information. However, it should not involve local manet routing with its manet interface so that route examination becomes much easier as described in Section 7.5. The internet-gateway SHOULD NOT be an intermediate node of a manet route. To achieve this, the internet-gateway SHOULD NOT forward the flooded packets to its neighbors of the manet interface. For example, in AODV, the internet-gateway SHOULD NOT propagate a RREQ message even if it receives the RREQ from neighbors. In OLSR, the internet-gateway SHOULD NOT generate TC message. It can be done with the Willingness configuration set to NEVER. 7.2. Sending Internet-Gateway Advertisement An internet-gateway sends out an internet-gateway Advertisement either periodically or response to an internet-gateway Solicitation. The internet-gateway allows to send unsolicited internet-gateway Advertisements, although sending them periodically would generate unnecessary packets in the Manet. When an extended router advertisement is used, the `N' flag MUST be set in the internet-gateway advertisements. It MUST carry a Prefix Information Option [8, 7]. The internet-gateway contains its global prefix in the prefix information option. The source address of the router advertisement must be a global address of the internet-gateway and MUST NOT use its link-local address. Although the NDP specification requires to set 255 to a hop limit field, the Hop Limit field in the IPv6 header SHOULD be set to an appropriate value in a MANET. The internet-gateway can either flood or unicast the internet-gateway advertisement. An internet-gateway SHOULD use optimized flooding mechanism such as the expanding ring search and multipoint relay flooding. R. Wakikawa et.al. Expires 18 Jan 2005 [Page 19]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 When the internet-gateway uses extended routing protocol signaling messages instead of the router advertisement, it must follow the specifications of each manet protocols. 7.3. Receiving Internet-Gateway Solicitation When an internet-gateway receives an internet-gateway solicitation, it MUST unicast an internet-gateway advertisement back to the originator of the solicitation. When it receives a router solicitation having N flag set, the internet-gateway must operate following verifications in addition to the verification specified in [8]. - The router solicitation must have N flag. Otherwise, the internet-gateway processes the router solicitation as specified in [8]. - If the source address is link local address, it SHOULD drop the router solicitation. - If the hop limit field of the message is less than or equal to zero, the message MUST silently be discarded. After successful verification, the internet-gateway keeps the originator's global address in its global manet node lists with INITIAL_GLOBAL_LIFE_TIME. It also unicasts back a router advertisement message as described in Section 7.2. 7.4. Management of Manet Nodes on Internet-Gateway An internet-gateway SHOULD known all the manet nodes which acquire a global address from the internet-gateway. This knowledge is used when internet-gateway determines a route for incoming packets described in section 7.5. It is recommended that the internet-gateway supports this feature when reactive manet protocol is used. When using proactive manet protocols, an internet-gateway can see entire topology of all the manet nodes. Therefore, the internet-gateway can know whether a node locates inside manet or not, as soon as it checks its routing table. On the other hand, most of reactive manet protocols only maintain partial topology of manet nodes. However, each manet node MUST contact to the internet-gateway at least once it establishes an internet route with the internet-gateway. During this operation, the R. Wakikawa et.al. Expires 18 Jan 2005 [Page 20]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 internet-gateway records the manet node's addresses into a routing table and SHOULD mark as a manet node who has global address. This approach can be applied to most of reactive manet protocol, but any mechanism can be selected to know all manet nodes information. 7.5. Route Examination When an internet-gateway forwards a packet from a manet to the Internet , it must examine the packet's source address. This examination prevents leaking unnecessary packets to the Internet. This examination is based on the following steps. 1. The internet-gateway first checks the destination address with its global prefix. If the prefix of the destination address is matched with the global prefix, the internet-gateway MUST NOT forward the packet to the Internet. It returns the packet back to the manet if it has a manet route for the destination. If the internet-gateway does not have a manet route, it just discards the packet and returns an ICMP Unreachable message to the sender. 2. If the prefix of the destination address is not matched with the global prefix, the internet-gateway carefully examines the route for the destination. - If the internet-gateway can not be an intermediate node of manet routes as shown in Section 7.4, it just discards the packet and returns an ICMP Unreachable message. The internet-gateway cannot route the packet inside the manet. - If the internet-gateway can be an intermediate node and knows full topology of the manet , it searches its routing table for a manet route of the destination. If the route is found, it routes the packet back to the manet. The internet-gateway SHOULD generate an ICMP6 Redirect Message to the source node. - On the other hand, if the internet-gateway can be an intermediate node and does not have full topology, it compares the destination address with the maintained manet routes. If there is a manet route, it SHOULD route the packet along the manet route. The internet-gateway SHOULD generate an ICMP6 Redirect Message to the source node. 3. The internet-gateway compares the source address with its global prefix. If the prefix part is not matched, this packet is sent from non-routable address in this manet. Thus, the packet MUST NOT be routed to the Internet. If there is no manet route for the destination, the packet MUST be silently discarded. The R. Wakikawa et.al. Expires 18 Jan 2005 [Page 21]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 internet-gateway SHOULD return an ICMP6 Parameter Problem message to the source node. 4. Otherwise, it can forward the packet to the Internet. Note that ICMP error messages are subject to rate limiting in the same manner as is done for ICMPv6 messages [3]. R. Wakikawa et.al. Expires 18 Jan 2005 [Page 22]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 8. 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 9. 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] I. Chakeres, E. Belding-Royer, and C. Perkins. Dynamic MANET On-demand (DYMO) Routing (work in progress, draft-ietf-manet-dymo-02.txt). Internet Draft, Internet Engineering Task Force, June 2005. [2] T. Clausen and P. Jacquet. Optimized Link State Routing Protocol OLSR. 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. R. Wakikawa et.al. Expires 18 Jan 2005 [Page 23]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 [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] V. Devaraplli, R. Wakikawa, A. Petrescu, and P. Thubert. Network Mobility (NEMO) Basic Support Protocol (proposed standard). Request for Comments 3963, Internet Engineering Task Force, January 2005. [6] D. Johnson, D. Maltz, and Y. C. Hu. The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR) (work in progress, draft-ietf-manet-dsr-09.txt). Internet Draft, Internet Engineering Task Force, April 2003. [7] D. Johnson, C. Perkins, and J. Arkko. Mobility support in IPv6. Request for Comments (Proposed Standard) 3775, Internet Engineering Task Force, June 2004. [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, draft-ietf-manet-tbrpf-11.txt). Internet Draft, Internet Engineering Task Force, October 2003. [10] C. Perkins, E. Belding-Royer, and S. Das. Ad hoc On-Demand Distance Vector (AODV) Routing. Request for Comments (Experimental) 3561, Internet Engineering Task Force, July 2003. [11] C. Perkins, J. Malinen, R. Wakikawa, E. Royer, and Y. Sun. IP address Autoconfiguration for Ad hoc Networks (expired, draft-ietf-manet-autoconf-01.txt). Internet Draft, Internet Engineering Task Force, November 2001. [12] R. Wakikawa, A. Tuimonen, and T. Clausen. Ipv6 support on mobile ad-hoc network (work in progress, draft-wakikawa-manet-ipv6-00.txt). Internet Draft, Internet Engineering Task Force, February 2005. R. Wakikawa et.al. Expires 18 Jan 2005 [Page 24]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 Authors' Addresses Ryuji Wakikawa Charles Perkins Dept. of Communications Systems Lab Environmental Information 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: andersn@telecom.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 18 Jan 2005 [Page 25]
Internet Draft Global Connectivity for IPv6 Manets 18 Jul 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. R. Wakikawa et.al. Expires 18 Jan 2005 [Page 26]