Mobile Ad Hoc Networking Working Group Ryuji Wakikawa INTERNET DRAFT Keio University 01 July 2002 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-01.txt Status of This Memo This document is a submission to 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 , Manet node operation, and Internet-gateway operation. Once a Manet node obtains a global address from an Internet-gateway, it can start to send data to 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 01 Jan 2003 [Page i] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 2 3. Overview 2 4. Limitations and Assumptions 3 5. Changing Route Request of each Manet Protocol 4 6. Changed Neighbor Discovery Protocol Packet Formats for Address Resolution 4 6.1. Modified Router Solicitation . . . . . . . . . . . . . . 5 6.2. Modified Router Advertisement . . . . . . . . . . . . . . 6 6.3. Source Manet Address Option . . . . . . . . . . . . . . . 6 7. Changing the Operation of the ICMPv6 Redirect 7 8. Manet Node Operation 7 8.1. Sending a Global Address Resolution Request . . . . . . . 7 8.1.1. Sending Manet Protocol Route Request . . . . . . 8 8.1.2. Sending Manet Router Solicitation . . . . . . . . 8 8.2. Receiving Global Address Resolution Reply from Internet-Gateway . . . . . . . . . . . . . . . . . . . . . 9 8.3. Sending a Packet to an Internet Node . . . . . . . . . . 10 8.4. Receiving ICMPv6 Error Message . . . . . . . . . . . . . 12 8.4.1. ICMPv6 Destination Unreachable Message . . . . . 12 8.4.2. ICMPv6 Redirect message . . . . . . . . . . . . . 12 9. Internet-gateway Operation 12 9.1. Route Examination during communication . . . . . . . . . 12 9.2. Receiving Route Request for a Global Destination Address 13 9.3. Receiving Manet Router Solicitation . . . . . . . . . . . 13 9.4. Forwarding Packets in the Internet-gateway . . . . . . . 13 10. Intermediate Node Operation 14 11. Sending Packet to the Manet from the Internet 14 12. Protocol Constants 14 R. Wakikawa et.al. Expires 01 Jan 2003 [Page ii] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 13. Security Considerations 14 Acknowledgments 15 References 15 Appendices 16 A. Use of Routing header for transmission of packets along a default route 16 B. AODV6 Operation with Global Connectivity for IPv6 Manet 17 B.1. Additions to AODV6 specification . . . . . . . . . . . . 17 B.2. Global Address Resolution . . . . . . . . . . . . . . . . 18 C. DSR Operation with Global Connectivity for IPv6 Manet 20 C.1. Additions to DSR specification . . . . . . . . . . . . . 20 C.2. Global Address Resolution . . . . . . . . . . . . . . . . 20 C.3. Communication to the Internet . . . . . . . . . . . . . . 21 D. Mobile IPv6 Operation with Global Connectivity for IPv6 Manet 23 E. Changes from draft-wakikawa-manet-globalv6-00 25 Authors' Addresses 25 1. Introduction A mobile ad-hoc network (Manet) is created dynamically when a set of mobile routers form a mesh routing state for their connectivity management, typically over a wireless network. Many routing protocols have been proposed for routing within Manets by the IETF MANET working group. These protocols aims to maintain a route to a destination despite movement of intermediate nodes that causes the route path to change. Global connectivity is required for nodes desiring communication with the fixed Internet. However, routing protocols for Manet typically only maintain routes local within the reach of a Manet running the given protocol. This document specifies a method for obtaining global connectivity to the Internet and how Manet routing protocols can contribute to this. The method is used for acquiring a global address from a gateway and to communicate over the gateway. R. Wakikawa et.al. Expires 01 Jan 2003 [Page 1] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 2. Terminology Manet Mobile Ad-Hoc Network Internet-gateway Gateway that provides the Internet connectivity for nodes in the Manet. This router should be placed at the edge of Manet and have connection to both the Internet and the Manet. Manet Address Manet node's identity address in Manet. The address is used for ad-hoc routing. INTERNET_GATEWAYS multicast address Multicast address for all Internet-gateways in a Manet. The address is defined as ALL_MANET_GW_MULTICAST Manet network interface A network interface connected to the Manet in an Internet-gateway or in a regular Manet node. Manet Router Solicitation A router solicitation message modified for Manet operation. Manet Router Advertisement A router advertisement message modified for Manet operation. 3. Overview This document proposes two methods for discovering Internet-gateways. One method is to extend the route discovery messaging of an on-demand routing protocol. Another is to use extended router solicitation and advertisements of the Neighbor Discovery Protocol (NDP) [5]. This document also illustrates how to apply the first method to an existing Manet protocol using the Ad-hoc On-demand Distant Vector (AODV) Routing Protocol [8, 7] as an example. Whenever a node boots up in the Manet and needs to communicate over the Internet, the node discovers an Internet-gateway to get its global prefix information. The node may discover the gateway pro-actively R. Wakikawa et.al. Expires 01 Jan 2003 [Page 2] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 after boot-up before it needs to communicate over the Internet, or it may postpone this discovery to take place on demand when it needs to communicate over the Internet. A prefix which is distributed by Internet-gateway is used for configuring a routable IPv6 [2] address for the node. The discovery can also be used for learning addresses of Internet-gateways for setting up routes to the Internet through them. Internet-gateways SHOULD reply to a request with their own global prefix information and IPv6 address. A reply from the gateway provides prefix information and possibly a route to the gateway, inserted as a default route. If there are more than one Internet-gateways and intermediate nodes replying to the request, the requesting node can only obtain gateway information known to the intermediate nodes and miss the rest of the information, because intermediate nodes may not have all Internet-gateways information. After obtaining the information from Internet-gateways, the node configures a routable IP address from a prefix of a selected gateway and inserts the gateway address as a default route. Selection of the gateway is out of scope of this document. If the node sends packets to the Internet, the node SHOULD use a routing header to route packets through its Internet-gateway. If a packet is destined to the Internet-gateway first, intermediate nodes just forward packets to the same Internet-gateway and the Internet-gateway can then route the packet to its destination. Otherwise, each intermediate nodes need to discover the route to the destination address of the packets' IP header to route packets and each of them send the packet towards their Internet-gateway. Each Internet-gateway monitors any packet received from the Manet to prevent unnecessary packets from being forwarded to the Internet side and to know how to react to signaling. The destination of such a packet passing through the Internet-gateway with routing header is checked on the Internet-gateway. If the destination is inside the Manet, the Internet-gateway notifies the sender to change its route to a more optimal one, a direct route into the Manet. The node then receives a notification and sends a route request to discover the direct route to the destination. 4. Limitations and Assumptions For simplicity, we make the following assumptions in our draft: R. Wakikawa et.al. Expires 01 Jan 2003 [Page 3] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 Address Family This document assumes IPv6 address family support. The Manet routing protocol discussed in this document MUST be capable of supporting IPv6 routes. Topological assumption At least one Internet-gateway is at the edge of the Manet. Address assumption All nodes in Manet have a global address, routable or not with the Internet, for instance a Mobile IPv6 [4] home address. The global address is used for initial configuration when a node boots up and joins the Manet. If the node does not have any global address at its network interfaces the node should temporarily configure an address from the MANET_INITIAL_PREFIX as described in the IP Address Autoconfiguration for Ad Hoc Networks [6] 5. Changing Route Request of each Manet Protocol To support this method of global connectivity formation, route request and reply messages of each Manet protocol should be modified to carry global prefix information and the gateway's IPv6 address. When a node requests global information to Internet-gateways, the node broadcasts a route request to the INTERNET_GATEWAYS global multicast address. Once an Internet-gateway receives the request, it MUST reply with both the global prefix and its Internet-gateway address to this. Each Manet routing protocol need to support some scheme for route reply to distinguish whether the route reply carries the Internet-gateway information and address. For example, each Manet route reply message should have a flag which indicates an Internet-gateway information is included in the reply. 6. Changed Neighbor Discovery Protocol Packet Formats for Address Resolution This section describes how to handle NDP packets to sent out over multi-hop networks such as the Manet. Both router solicitation and router advertisement messages can not be sent over multi-hop networks, because the link-local scope is not well R. Wakikawa et.al. Expires 01 Jan 2003 [Page 4] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 defined for Manets. NDP assumes to use link-local scoped addresses as IPv6 destination and source address fields for router advertisement and router solicitation messages. Link-local address is not an appropriate address scope for multi-hop networks because IPv6 prohibits to forward packets sent to an address of link-local scope. For doing so, NDP packets must be modified. The following sections describe the modified "Router Solicitation" and "Router Advertisement" packet formats. 6.1. Modified Router Solicitation A host sends Manet Router Solicitations in order to prompt Internet-gateways to generate Manet Router Advertisements. The modified Manet Router Solicitations MUST have a new M flag set and they MUST include a Source Manet address option identifying the sender. The Hop Limit field in the IPv6 header SHOULD be set to an appropriate value. This can be the default constant usually inserted when unicasting packets, or chosen e.g., according to an expanding ring search technique for Manet Broadcasting. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Manet Router Solicitation Flag (M) A 1-bit Manet Router Solicitation flag. When set, it indicates that the Router Solicitation message can be sent over a multi-hop network. The Internet-gateways MUST NOT forward this message to the fixed Internet. Whenever the flag is set, a Source Manet address option is required. The Manet Address in the Source Manet Address sub-option is used for management Manet nodes at the Internet-gateway. Reserved Reduced from a 32-bit field to a 31-bit field to account for the addition of the Manet Router Solicitation (M) flag. Required Options: Source Manet address The Manet global address of the sender. This MUST be included even if the Source Address is the temporary address generated with MANET_INITIAL_PREFIX. R. Wakikawa et.al. Expires 01 Jan 2003 [Page 5] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 6.2. Modified Router Advertisement An Internet-gateway sends out a Manet Router Advertisement message response to a Manet Router Solicitation. The Internet-gateway SHOULD NOT send unsolicited Manet Router Advertisements. Sending them periodically would generate unnecessary packets in the Manet. The modified Manet Router Advertisement MUST have the 'N' flag set. The Hop Limit field in the IPv6 header SHOULD be set to an appropriate value if the expanding ring search algorithm in Manet Broadcasting is used. The `N' flag MUST be set in the Manet Router Advertisements and it MUST carry the address of the Internet-gateway and the global prefix information by the Prefix Information Option [5, 4]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|N|Reserved | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Manet Router Advertisement Flag (N) 1-bit Manet Router Advertisement flag. When set, indicates that the Router Advertisement message is only for Manet nodes and can be sent over multiple hop Manet nodes. The Internet-gateways MUST NOT forward this message to 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. 6.3. Source Manet Address Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Manet Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 10 Length 3 R. Wakikawa et.al. Expires 01 Jan 2003 [Page 6] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 The length of the option (including the type and length fields) in units of 8 octets. Manet Address The 128 bit IPv6 address for the original source of the packet. The Source Manet Address option contains the Manet address of the sender of the packet. It is used in Manet Router Solicitation, and Manet Router Advertisement packets. Since the source address field in the IPv6 header might be changed by intermediate nodes running a Manet routing protocol (i.e. AODV), this option can indicate the exact sender Manet address to receivers. These options MUST be silently ignored for other Neighbor Discovery messages. 7. Changing the Operation of the ICMPv6 Redirect An ICMPv6 [1] Redirect message sent to a Manet node MUST include the Source Manet address option and is used to notify that this destination address is located on this MANET. It is used by the Internet Gateway to novity a sending node that a destination is located on this MANET and instead should send packets to it using ordinary MANET routing. 8. Manet Node Operation 8.1. Sending a Global Address Resolution Request A node needs a globally routable address in order to be globally reachable and receive packets from the Internet. The node also needs to learn the location and address of the gateway that provide 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. One way of obtaining this information is by relying on advertisements distributed by the Internet Gateway as part of its Neighbor Discovery Protocol. A Manet Node could then send a Manet Router Solicitation for an Internet Gateway and receive a Manet Router Advertisement back in response from the Internet Gateway. In some cases, as mentioned above, the Internet Gateway might not be able to distribute the router advertisement through the Manet, because of link-local scope being not well defined in the Manet. R. Wakikawa et.al. Expires 01 Jan 2003 [Page 7] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 We will in this document describe three ways for requesting global routing information from an Internet Gateway: - sending Manet route request for a global destination address - sending Manet route request to the INTERNET_GATEWAYS multicast address - sending Manet Router Solicitation The IPv6 address used during any of these operations could be any arbitrary global-scope address, for example a Mobile IPv6 home address. If no such address is available ,the node SHOULD create a temporary global-scope address, generated from the well-known MANET_INITIAL_PREFIX [6]. This temporary address should be deleted after obtaining the globally routable IPv6 address from an Internet-gateway. 8.1.1. Sending Manet Protocol Route Request A node could rely route request and route reply messages of an on-demand manet routing protocol to obtain the global prefix and address of an Internet Gateway. The node sends a modified route request and receives a modified route reply in response from the Internet Gateway. For instance, the node propagates a Route Request (RREQ) message using AODV and waits for an Internet Gateways to return a reply, such as an AODV Route Reply (RREP). The address which we here request a route for in the route request messages could either be the INTERNET_GATEWAYS global multicast address or the global address of a destination node located on the Internet with whom we would like to communicate with. Both addresses would in this case indicate that we request a reply message specifying a global prefix and Internet Gateway address. 8.1.2. Sending Manet Router Solicitation A node can request a Manet Router Advertisement by an Internet Gateway by sending a Manet Router Solicitation to the INTERNET_GATEWAYS multicast address. The node MAY use an expanding ring search technique to broadcast the Router Solicitation message using appropriate Hop Limit values. A receiving node MUST be a member of the INTERNET_GATEWAYS group if it is an Internet Gateway and it SHOULD be a member if it is an ordinary non Gateway Manet node. If the receiving node is a Gateway, it replies with a Manet Router Advertisement message specifying its global prefix R. Wakikawa et.al. Expires 01 Jan 2003 [Page 8] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 information and Internet Gateway address. Otherwise, the node just propagates the Manet Router Advertisement message if the hop-limit allows this. In the latter case, intermediate nodes SHOULD not process this packet, but just forward it. However, Manet protocols need to setup a reverse route in order to propagate the response back. In such a case, mere forwarding of the packet will not introduce this reverse route and a response from an Internet Gateway will cause a search for the reverse route, e.g., in AODV6. It totally depends on the behavior of the MANET routing protocol whether it can use the INTERNET_GATEWAYS multicast address as the broadcast address in a MANET. If the receiving node is not an Internet Gateway and hop-limit allows it, the node MUST propagate the request ahead towards the INTERNET_GATEWAYS address. 8.2. Receiving Global Address Resolution Reply from Internet-Gateway After either of the above operations have taken place,the node should know a global prefix and the address of its related Internet Gateway. First, the node should generate a global IPv6 address by using the global prefix information. The node SHOULD use its 64-bit interface ID. Since the node assumingly has already done Duplicate Address Detection (DAD), as defined in [6], 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 the 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 AODV6. It MAY be left to be deleted by timeouts. In the routing table, the node should set the following two routes. We assume the global prefix is exclusively on the Manet side. Destination/prefix length Next-Hop --------------------------- ----------------------------- Default Route/0 Host Route/128 R. Wakikawa et.al. Expires 01 Jan 2003 [Page 9] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 These routing entries should be held until expiration of the lifetime which the Internet-gateway provides in the reply to the global address resolution request. Lifetime of default route entry and global prefix information is stored in either route reply or route advertisement messages which are sent by Internet Gateway. During active lifetime, the receiving node can use the global prefix and the Internet Gateway as default route entry. The Internet Gateway MUST hold or acquire the reverse route to the requesting node before expiration of the lifetime. During use of the Internet-gateway as a route path for communications, the node MUST keep re-requesting global prefix information to the Internet-gateway before the lifetime is expired. This refreshment SHOULD be done at GWINFO_REFRESH periods. The node can unicast the request to the respective Internet-gateway, or alternatively it can broadcast the request to all over the Manet network 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. 8.3. Sending a Packet to an Internet Node 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 found it sends the packet towards the destination. - If not, the node sends a route request for the destination node. 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 uses one of the two methods to obtain a default route. 3. If the node does not receive any route reply, 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 reply for the destination, it sets a host route for the destination, and sends packets according to this 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 SHOULD send a route request for the destination of the outgoing data packet using its Manet routing protocol. Then, if a default route exists, the node MAY wait for R. Wakikawa et.al. Expires 01 Jan 2003 [Page 10] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 the above route request. If no such request 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 route replies, 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. 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, some manet protocol (ex. DSR) does not support next hop forwarding, routing header SHOULD 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 it is 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 A. 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 an 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 below entries. Destination/prefix length Next-Hop --------------------------- ----------------------------- Default Route/0 Host Route/128 The node MUST send at least one route request for 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 01 Jan 2003 [Page 11] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 If the node gets a route reply, the node assumes the node is located within the ad hoc network, sets a host route for the destination, and sends packets normally according to this host route. 8.4. Receiving ICMPv6 Error Message A Manet node usually receives two types of ICMPv6 messages, 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.4.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 sending a route request again. This exact behavior depends on the Manet routing protocol in use. If the Manet node receives ICMPv6 Destination Unreachable messages after sending data packets to a destination using a default route entry, the node can send a single route request for the destination again. If the node does not receive any route reply, the node SHOULD NOT send any packets including route requests for the destination for a while. 8.4.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. 9. Internet-gateway Operation 9.1. Route Examination during communication An Internet Gateway SHOULD have reverse 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 the host route between the source and the destination node. Internet Gateway sends a kind of route R. Wakikawa et.al. Expires 01 Jan 2003 [Page 12] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 error messages to notify sender node to start a manet routing request operation in order to obtain the host route instead of the default route. 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. A host route to a Manet node should be maintained until the node re-requests global information with a NDP Manet Router Solicitation message or a Manet protocol route request. If the Internet-gateway does not get any re-request messages before the lifetime of the host route is expired, it discards the host route. 9.2. Receiving Route Request for a Global Destination Address When an Internet-gateway receives a Manet protocol route request destined to another address than the INTERNET_GATEWAYS global multicast address, it searches the address in its routing table. If the 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 a Manet protocol route reply with global connectivity information. This includes its own Manet address as route information used for the default route entry. If the Internet-gateway receives a route request for the INTERNET_GATEWAYS global multicast address, it MUST unicast back its global connectivity information, including its own IPv6 address. The Internet-gateway SHOULD also include the lifetime GWINFO_LIFETIME into its global connectivity information. Each time when receiving such a request, the Internet-gateway MUST update the reverse route of sender into its routing table. 9.3. Receiving Manet Router Solicitation If the Internet-gateway receives a Manet Router Solicitation, it SHOULD reply with its own prefix information in a Manet Router Advertisement messages by unicast. Each time when receiving such a request, the Internet-gateway MUST record the reverse route of sender into its routing table. 9.4. Forwarding Packets in the Internet-gateway An Internet-gateway always stores the sender's Manet address into an associated Manet nodes list and eventually a reverse route into its routing table. R. Wakikawa et.al. Expires 01 Jan 2003 [Page 13] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 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 discard 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. 10. Intermediate Node Operation If an intermediate Manet node receives a Manet protocol route request for address resolution or a NDP Manet Router Solicitation, it MUST not reply with global connectivity information and the Internet-gateway address, even if it knows this information. Otherwise the Manet gateway would not learn nodes in the network. The request MUST be propagated in the Manet towards Internet-gateways, instead. 11. Sending Packet to the Manet from the Internet Packets forwarded to a global address in the Manet get routed from the Internet to the Internet-gateway which advertised the prefix of the global destination address. The Internet-gateway then just resorts to its normal Manet protocol operation to forward the packet towards its destination in the Manet. 12. 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 13. 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 R. Wakikawa et.al. Expires 01 Jan 2003 [Page 14] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 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 also thank Thierry Ernst for his comments. References [1] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet protocol version 6 (ipv6). Request for Comments (Proposed Standard) 1885, Internet Engineering Task Force, December 1995. [2] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6) Specification. Request for Comments (Proposed Standard) 1883, Internet Engineering Task Force, December 1995. [3] D. Johnson, D. Maltz, Y. Hu, and J.G. Jetcheva. The dynamic source routing protocol for mobile ad hoc networks (work in progress). Internet Draft, Internet Engineering Task Force, February 2002. [4] D. Johnson, C. Perkins, and J. Arkko. Mobility support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, May 2002. [5] 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. [6] 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. [7] 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. [8] C. Perkins, E. Royer, and S. Das. Ad hoc on demand distance vector (AODV) routing (work in progress). Internet Draft, Internet Engineering Task Force, January 2002. R. Wakikawa et.al. Expires 01 Jan 2003 [Page 15] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 A. Use of Routing header for transmission of packets along a default route As described in section 8.3, each manet node have two way to send data along a default route when it decides to use of default route for transmission packet. The node SHOULD support both but select one depending on the base Manet protocol and network topology. - Without IPv6 routing extension header the sender sends the packet to the global IPv6 address and relies upon next hop routing in the other nodes. - With IPv6 routing extension header the sender uses the Internet-gateway address in the destination address of the IPv6 header and the real destination address in the routing header. This document recommends to use the second method for the following reason. Assume the destination is inside the Manet but the sender can not reach the destination via a host route. In such a case, if the node sends packets to the destination via the Internet-gateway without a routing header, an intermediate node who has a host route for the destination will route packets to it directly; but the sender node is not aware of this. The sender is never notified that packets is not passing through the Internet-gateway. If the sender always uses a routing header, every packet is undoubtedly routed through the Internet-gateway. If the Internet-gateway detects that the destination is located within the Manet, the internet gateway can send an ICMPv6 Redirect error message to the sender. After receiving the ICMP Redirect messages, the node can send a route request for the destination to learn the host route. Using a routing header is also preferable if there are more than two Internet-gateways, because the node then have the ability to decide which Internet-gateway is the best, by distance in hops, or by some other priority. By assign a priority number for each Internet-gateway, the route reply message and the Manet Router Advertisement messages could be extended to support a candidate Internet-gateway option in it. R. Wakikawa et.al. Expires 01 Jan 2003 [Page 16] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 B. AODV6 Operation with Global Connectivity for IPv6 Manet This section describes how to apply embedding of the Internet connectivity acquisition to an on-demand Manet routing protocol, AODV [8], more precisely, to its IPv6 variant [7]. All the operation except for a specific explanation in this section follow the descriptions presented earlier in this document. B.1. Additions to AODV6 specification The AODV6 protocol is used as is, except for the addition of one flag. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |J|R|G|I| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flooding ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the IPv6 Route Request message (RREQ) is illustrated above, and contains the same fields with the same functions as the RREQ message defined for IP version 6 (in [3]), except for the following: Internet-Global Address Resolution Flag (I) Internet-Global Information Flag: used for global address resolution. This flag indicates that the destination node requests global connectivity. R. Wakikawa et.al. Expires 01 Jan 2003 [Page 17] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|A|I| Reserved | Prefix Sz | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit Destination IP Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit Source IP Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the IPv6 Route Reply message (RREP) is illustrated above, and contains the same fields with the same functions as the RREP message defined for IP version 6 (in [3]), except for the following. Internet-Global Address Resolution Flag (I) Internet-Global Information Flag: used for global address resolution. This flag defines that this reply contains information about an internet gateway. B.2. Global Address Resolution This section describes how to obtain a globally routable IPv6 address from an Internet-gateway by sending an AODV6 Route Request (RREQ) to the INTERNET_GATEWAYS global multicast address. When a node sends a RREQ, requesting global address resolution, it can as IPv6 source address specify any arbitrary address with global scope currently in use by one of its interfaces. This could, for example, be its Mobile IPv6 home address or an address created temporary from the MANET_INITIAL_PREFIX. The node then broadcasts the RREQ using the 'I' flag and specifies the INTERNET_GATEWAYS global multicast address as the destination in the RREQ destination address field. When an Internet-gateway receives a RREQ with the `I' flag set, it checks its routing table for an entry towards the receiving network interface and updates it with an entry of for requesting node using the source address specified in the RREQ. The Internet-gateway then constructs a Route Reply (RREP with the 'I' flag set), and unicasts it to the requesting node. The IPv6 header fields should be built as in R. Wakikawa et.al. Expires 01 Jan 2003 [Page 18] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 normal AODV6 operation. The global prefix information can be derived using the responding gateway's IPv6 address and the prefix length specified in the RREP. In this way, the node will know both the address of the gateway and the globally routable prefix. After acquiring a topologically correct global IPv6 address, the node first deletes the temporary address from the MANET_INITIAL_PREFIX. If the node didn't create this temporary address, the node can continue using the arbitrary address, e.g. the Mobile IPv6 home address, used during communication with the gateway. The node then broadcasts a Route Error (RERR) with the temporary address to delete all the related host routes. This RERR could also create new reverse routes for the newly created global IPv6 address at intermediate nodes and Internet-gateways. It is, however, not permitted by the current AODV6 specification to setup reverse routes using RERR messages. Another RREQ can therefore be sent over the Manet to create these reverse routes at intermediate nodes. These reverse routes will become the route path to the Internet-gateway for the nodes newly created global address. The Internet-gateway should insert the nodes host route into its routing table. The old entry in the gateway related to the temporary address will be discarded after lifetime expiration. When the node sends packets to the internet, it MAY use any of the two methods specified in section 8.3 and appendix A. If the node chooses to send a packet to the Internet without using a routing header, some intermediate nodes may generate RERR message because they do not have an active route to the packet's destination, see the AODV specification [8] for more details about this. To avoid these unnecessary RERRs, a default route is defined as the active route in this document. This means that an intermediate node should have an active default route. If the intermediate node doesn't have a host route for a destination, it should route packets towards the default route. If the node instead uses a routing header, the address of the Internet-gateway should be specified in destination address field of the IPv6 header. All intermediate nodes on the route path to the internet-gateway will then have a host route to the destination address, ie. the internet-gateway address. The intermediate node cannot generate a RERR message for outgoing packets destined outside of the Manet. R. Wakikawa et.al. Expires 01 Jan 2003 [Page 19] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 C. DSR Operation with Global Connectivity for IPv6 Manet This section describes how to apply embedding of the Internet connectivity acquisition to an on-demand Manet routing protocol, Dynamic Source Routing protocol (DSR) [3]. All the operation except for a specific explanation in this section follow the descriptions presented earlier in this document. C.1. Additions to DSR specification Global address resolution option is newly defined for DSR since DSR does not have a flag field in Route Request Option and Route Reply Option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | Reserved | Prefix Sz | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Global Address Resolution Option is illustrated above. Option Type TBD Option Data Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Opt Data Len fields. Reserved MUST be sent as 0 and ignored on reception. Prefix Size The Prefix Size specifies the prefix size of the replying gateway's global address. The prefix size will be used for address generation with the gateway global address. C.2. Global Address Resolution This section describes how to obtain a globally routable IPv6 address from an Internet-gateway by sending an DSR Route Request to the INTERNET_GATEWAYS global multicast address. R. Wakikawa et.al. Expires 01 Jan 2003 [Page 20] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 When a node sends a Route Request, requesting global address resolution, it can as IPv6 source address specify any arbitrary address with global scope currently in use by one of its interfaces. This could, for example, be its Mobile IPv6 home address or an address created temporary from the MANET_INITIAL_PREFIX. The node then broadcasts the Route Request using the Global Address Resolution Option and specifies the INTERNET_GATEWAYS global multicast address as the target address destination in the Route Request. When an Internet-gateway receives a Route Request with the Global Address Resolution Option, it checks its routing table for an entry towards the receiving network interface and updates it with an entry of for requesting node using the source address specified in the IPv6 header field. The Internet-gateway then constructs a Route Reply with Global Address Resolution Option, , and unicasts it to the requesting node. The IPv6 header fields should be built as in normal DSR operation. The global prefix information can be derived using the responding gateway's IPv6 address and the prefix length specified in the Global Address Resolution Option. In this way, the node will know both the address of the gateway and the globally routable prefix. After acquiring a topologically correct global IPv6 address, the node first deletes the temporary address from the MANET_INITIAL_PREFIX. If the node didn't create this temporary address, the node can continue using the arbitrary address, e.g. the Mobile IPv6 home address, used during communication with the gateway. The node then broadcasts a Route Error with the temporary address to delete all the related host routes. The Route Error of DSR does not contain any address lists to create new reverse route for the newly created global IPv6 address at Internet-gateways. Route Request can therefore be sent over the Manet to create reverse routes at internet-gateways after previous Route Error operation. The reverse routes will become the route path to the Internet-gateway for the nodes newly created global address. The Internet-gateway should insert the nodes host route into its routing table. C.3. Communication to the Internet When the node communicates to a destination which is located in the internet, it can use same way as base DSR protocol. DSR uses the DSR Source Route Option to route packets to a destination. The DSR Source Route Option is extracted from the draft as below. R. Wakikawa et.al. Expires 01 Jan 2003 [Page 21] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len |F|L|Reservd|Salvage| Segs Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address[2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address[n] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a DSR node sends packets to the global destination, the DSR node set Last Hop External flag (L) in the Source Route Option and puts an internet-gateway address in Address[n-1] when address[n] is the destination address. The operations of routing packets with the Source Route Option are followed by DSR protocol. If a global node at the Internet sends packets to a DSR node which is located in DSR network, the global node set First Hop External flag and puts an internet-gateways address in Address[2]. Address[1] should be set the global address of the global node. The operations of routing packets with the Source Route Option are followed by DSR protocol as well. R. Wakikawa et.al. Expires 01 Jan 2003 [Page 22] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 D. Mobile IPv6 Operation with Global Connectivity for IPv6 Manet The global connectivity for Manet is defined for any global address configured to any Manet network interface of a Manet node, and it defines a method for configuring a globally routable address for such an interface. Once such address is available, global mobile-initiated sessions, such as web browsing or DNS queries, can be used. A topologically correct address in the IP header source field is sufficient for packets sent from the Manet node in such sessions. If the address is a more permanent one, it can be used as a Mobile IPv6 [4] home address, to provide an always-on reachability from the fixed Internet with a statically known address. In such a case, reachability can be provided even when the node moves between Manets and different points of the fixed network. A mobile node should use Mobile IPv6 when it is not on its home link. When arriving at a visited link in the fixed network, it uses neighbor discovery to detect movement. If it is not at home, it registers with its home agent using a globally routable address from the visited network. In Manet, Mobile IPv6 replaces the neighbor discovery part of its movement detection with globally routable address acquisition, as defined in this document. The movement detection can e.g. be bypassed by the routing daemon by it locally in the host passing a router advertisement to the Mobile IPv6 Neighbor Discovery -based movement detection algorithm. The mobile node then uses the globally routable address acquired from the Internet-gateway as its care-of-address when possibly performing a home registration. If no home registration is needed, the mobile node is at home in the Manet and the prefix of its home address belongs to its Internet-gateway. All Manet nodes MUST support minimal Mobile IPv6 Correspondent Node (CN) operation, 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 inserts 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 correspondent node, the possible routing header injected by Mobile IPv6 is modified by inserting the R. Wakikawa et.al. Expires 01 Jan 2003 [Page 23] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 entry for gateway prior to the entry for home address, and setting the segments left to two. R. Wakikawa et.al. Expires 01 Jan 2003 [Page 24] Internet Draft Global Connectivity for IPv6 Manets 01 July 2002 E. Changes from draft-wakikawa-manet-globalv6-00 - Added algorithm in section 8.3 whether the destination is early discovered by route request or not. It helps to prevent repeated redundant route requests. - Added DSR operation as an example in appendix. - Moved the use of routing header from section 8.3 to appendix A, since some base Manet protocol can forward packet to the Internet-gateway by next hop forwarding support (e.x. AODV). - Kept protocol parameters as TBD. Authors' Addresses Ryuji Wakikawa Charles Perkins Graduate School of Communications Systems Lab Media and Governance. Nokia Research Center Keio University 313 Fairchild Drive 5322 Endo Fujisawa Kanagawa Mountain View, California 252 JAPAN 94043 USA Phone: +81-466 49-1394 Phone: +1-650 625-2986 EMail: ryuji@sfc.wide.ad.jp EMail: charliep@iprg.nokia.com 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 Phone: +1-650 625-2355 Phone: +46 46-39 72 92 EMail: EMail: jmalinen@iprg.nokia.com anders.nilsson.024@student.lth.se Fax: +1 650 625-2502 Fax: +46 46-14 58 23 Antti J. Tuominen TM Laboratory Helsinki University of Technology P.O.Box 9700 02015 HUT Finland Phone: +358 9 EMail: ajtuomin@tml.hut.fi Fax: +358 9 R. Wakikawa et.al. Expires 01 Jan 2003 [Page 25]