Mobile Ad Hoc Networking Working Group Ryuji Wakikawa INTERNET DRAFT Jari T. Malinen 14 November 2001 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-00.txt Status of This Memo This document is a submission by the Mobile Ad Hoc Networking Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the manet@itd.nrl.navy.mil mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract This document describes how to provide Internet connectivity with mobile ad-hoc networks. It describes globally routable address resolution, 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. The data goes through the Internet-gateway with a routing header which includes an address of the gateway. The connectivity method is not dependent on a particular Manet protocol. Also, use of global connectivity with Mobile IPv6 is specified. R. Wakikawa et.al. Expires 14 May 2002 [Page i]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 1 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 . . . . . . . . . . . . . . 4 6.2. Modified Router Advertisement . . . . . . . . . . . . . . 5 6.3. Source Manet Address Option . . . . . . . . . . . . . . . 6 7. Changing ICMP Redirect Operation 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 ICMP Error Message . . . . . . . . . . . . . . 11 8.4.1. ICMP Destination Unreachable Message . . . . . . 11 8.4.2. ICMP Redirect message . . . . . . . . . . . . . . 11 9. Internet-gateway Operation 12 9.1. Route Examination during communication . . . . . . . . . 12 9.2. Receiving Route Request for a Global Destination Address 12 9.3. Receiving Manet Router Solicitation . . . . . . . . . . . 13 9.4. Forwarding Packets in the Internet-gateway . . . . . . . 13 10. Intermediate Node Operation 13 11. Sending Packet to the Manet from the Internet 13 12. Protocol Constants 14 R. Wakikawa et.al. Expires 14 May 2002 [Page ii]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 13. Security Considerations 14 Acknowledgements 14 References 14 Appendices 16 A. AODV6 Operation with Global Connectivity for IPv6 Manet 16 A.1. Additions to AODV6 specification . . . . . . . . . . . . 16 A.2. Global Address Resolution . . . . . . . . . . . . . . . . 17 B. Mobile IPv6 Operation with Global Connectivity for IPv6 Manet 19 Authors' Addresses 20 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 Manet routing. These protocols maintain a route to a destination despite route path changes due to movement of intermediate nodes in the Manet. Global connectivity is required for nodes capable of communicating with the fixed Internet. However, routing protocols for Manet typically only maintain routes over local connectivity within the reach of a Manet running the given protocol. This document specifies a method for global connectivity to the Internet to be used with Manet routing protocols. The method can be used for acquiring a global address from a gateway and to communicate over the gateway. 2. Terminology Manet Mobile Ad-Hoc Network Internet-gateway Gateway that provides the Internet connectivity for nodes in Manet. This router should be placed at the edge of Manet and have connection to both the Internet and the Manet. R. Wakikawa et.al. Expires 14 May 2002 [Page 1]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 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 in [6]. 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 to discover Internet-gateways. One is to extend the route discovery messaging of an on-demand routing protocol. Another it to use an extended router solicitation and advertisement of the Neighbor Discovery Protocol (NDP) [2]. 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 [5, 4] 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 proactively 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. The prefix is used for configuring a routable IPv6 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. Intermediate nodes can not reply to the request sent by a node. If there are more than one Internet-gateways and intermediate nodes replying to the request, the requesting node can R. Wakikawa et.al. Expires 14 May 2002 [Page 2]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 only obtain gateway information known to the intermediate nodes and miss the rest of the information. After obtaining the information from Internet-gateways, the node configures a routable IP address from a prefix of a selected gateway. Selection of the gateway is out of scope of this document. A reply from the gateway provides prefix information and possibly a route to the gateway, inserted as a default route. 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: 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 [1] 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 R. Wakikawa et.al. Expires 14 May 2002 [Page 3]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 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 [3] 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 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 the reply includes Internet-gateway information. 6. Changed Neighbor Discovery Protocol Packet Formats for Address Resolution Both router solicitation and router advertisement message can not be sent over multi-hop networks, because the link-local scope is not well defined for Manets. NDP assumes to use link-local scoped address as IPv6 destination and source address field 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. This section describes how to handle NDP packets to sent out over multi-hop networks such as the Manet. 6.1. Modified Router Solicitation A host sends Manet Router Solicitations in order to prompt Internet-gateways to generate Manet Router Advertisements. The NDP router discovery packet format is modified for new Manet operation. 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 R. Wakikawa et.al. Expires 14 May 2002 [Page 4]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 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, an 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. 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 packet format is modified for new Manet Router Advertisement `N' flag. 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 [2, 1]. R. Wakikawa et.al. Expires 14 May 2002 [Page 5]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 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. An 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 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 R. Wakikawa et.al. Expires 14 May 2002 [Page 6]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 in the IPv6 header might be changed by intermediate nodes running a Manet routing protocol, this option can indicate the exact sender Manet address to receivers. These options MUST be silently ignored for other Neighbor Discovery messages. 7. Changing ICMP Redirect Operation ICMP Redirect message sent to a Manet node MUST include the Source Manet address option and be set as the same address found in the Target Address field and the ICMP Destination Address field. It indicates the destination is on the same Manet as the IPv6 source address of the packet prompting the ICMP Redirect message. 8. Manet Node Operation 8.1. Sending a Global Address Resolution Request A node needs a globally routable address when sending packets to the Internet. The node should learn a global prefix owned and distributed by an Internet-gateway. The Internet-gateway distributes router advertisements as a part of its Neighbor Discovery Protocol operation. These advertisements are responses to solicitation sent by Manet nodes. A Manet Node requests a router advertisement by the modified router solicitation and gets the modified router advertisement back as in general neighbor discovery protocol operation. In some cases, as mentioned before, the Internet-gateway can not distribute the router advertisement in the Manet, because of link-local scope being not well defined in the Manet. There are three ways for requesting router information of the 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 An IPv6 address for this operation should be an arbitrary globally scoped address such as a Mobile IPv6 home address, otherwise the node uses a temporary globally scoped address, generated from the well-known MANET_INITIAL_PREFIX [3]. This temporary address should R. Wakikawa et.al. Expires 14 May 2002 [Page 7]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 be deleted after obtaining the globally routable IPv6 address from an Internet-gateway. 8.1.1. Sending Manet Protocol Route Request A node can use a route request message of a on-demand manet routing protocol to obtain global prefix and an address of an Internet Gateway. The node send a modified route request. For instance, the node propagates a Route Request (RREQ) message using AODV. After sending the route request, the node should wait until the Internet-gateways returns a reply, such as an AODV Route Reply (RREP), for the request. The requested address in each route request message could be either the INTERNET_GATEWAYS global multicast address or a global address of a Internet node. Both addresses as requested address in route request indicates its request message for global prefix information and Internet Gateway addresses. 8.1.2. Sending Manet Router Solicitation A node can also request a Manet Router Advertisement to the Internet-gateways 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 to the INTERNET_GATEWAYS address using appropriate Hop Limit values. The receiving node MUST be a member of the INTERNET_GATEWAYS group if it is a gateway and it SHOULD be a member if it is an ordinary Manet node. If it is a gateway, it replies with a Manet Router Advertisement message including its global prefix information and its 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 do not process this packet, they just forward it. However, Manet protocols need to know a reverse route in order to propagate a 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 Manet protocol behavior whether Manet protocol can use the INTERNET_GATEWAYS multicast address as a 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 to the INTERNET_GATEWAYS address. R. Wakikawa et.al. Expires 14 May 2002 [Page 8]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 8.2. Receiving Global Address Resolution Reply from Internet-Gateway After either of the above operation, the node knows a global prefix and its Internet-gateway address in the Manet. 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 has already done Duplicate Address Detection (DAD), as defined in [3], 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 when all follow this rule. If not, the node MAY perform another DAD for this global address. If the node uses temporary address generated by MANET_INITIAL_PREFIX for requesting global information, it SHOULD be deleted after generating the routable global address. All the host routes for the temporary address SHOULD be deleted from intermediate nodes and the Internet-gateways by using some route maintenance operation of Manet protocols, for example Route Error Request in AODV6 case. They MAY be left to be deleted by timeouts. In the routing table, the node should set following two routes. We assume the global prefix is exclusively on the Manet side. Destination/prefix length Next-Hop --------------------------- ----------------------------- Default Route/0 <Default> <Internet-gateway address> Host Route/128 <Internet-gateway address> <neighbor forwarding the reply> 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 message 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. Before the lifetime is expired, the node should re-request global prefix information to the Internet-gateway. 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. R. Wakikawa et.al. Expires 14 May 2002 [Page 9]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 8.3. Sending a Packet to an Internet Node 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 the above route request. If no such request is pending, it uses one of the methods described in this document to obtain a default route. If the node requests a route for the destination and does not get any route replies, the node can start to use default route entry for the destination. The node should know whether a route request was earlier sent for a destination whose route lookup found the default route. The node MUST send at least one route request for such a destination before sending data packets, even if it has already had default gateway in its routing table. If the node gets a route reply, the node sets a host route for the destination and sends packets according to this host route. When the node sends a packet to its default route, the node should decide between following two methods. The node SHOULD support both but select one depending on the Manet protocol and network topology. - With IPv6 routing header option the sender uses the Internet-gateway address in the destination address of the IPv6 header and the real destination address in the routing header. - Without IPv6 routing header option the sender sends the packet to the global IPv6 address and relies upon next hop routing in the other nodes. This document recommends to use the first method for the following reason. Assume the destination is inside the Manet but 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 routing header, an intermediate node who knows the host route for the destination routes packets to it directly, while the sender node does not learn that. The sender does not know that packets do not go through the Internet-gateway. If the sender node always uses routing header, every packets undoubtedly are routed to its Internet-gateway. If the Internet-gateway detects that the destination locates inside the Manet, the Internet gateway can send an ICMP 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 routing header is also useful if there is more than two Internet-gateways, because the node can decide the best Internet-gateway R. Wakikawa et.al. Expires 14 May 2002 [Page 10]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 by their distance in hops, or by some other priority. To assign a priority number for each Internet-gateway, the route reply message and the Manet Router Advertisement message could be extended to support a candidate Internet-gateway option in it. With the second method, the node does not need to take care of the explicit route to the Internet-gateway, depending on whether packet forwarding associated with the used Manet protocol supports next hop forwarding. In such a case, each intermediate node could independently decide on how to best route the packet out of the Manet. 8.4. Receiving ICMP Error Message A Manet node usually could receives two types of ICMP messages, the ICMP Destination Unreachable Message and the ICMP Redirect message. These messages are propagated over the Manet and their meaning is the same as usually. 8.4.1. ICMP Destination Unreachable Message If a Manet node receives an ICMP Destination Unreachable messages after sending data packets to a destination based on a host route entry, the node MUST delete this route entry. If needed, the node can then discover the route for the destination by sending out route request again, depending on the used Manet protocol. When the Manet node receives the ICMP Destination Unreachable messages after sending data packets to a destination based on a default route entry, the node can send 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. ICMP Redirect message If the Manet node receives an ICMP 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. R. Wakikawa et.al. Expires 14 May 2002 [Page 11]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 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 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. R. Wakikawa et.al. Expires 14 May 2002 [Page 12]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 9.3. Receiving Manet Router Solicitation If the Internet-gateway receives a Manet Router Solicitation, it SHOULD reply 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 eventually a reverse route into its routing table. When the Internet-gateway receives a packet from the Manet network interface, it searches a host route of the destination address from its routing table . If it finds the host route, it MUST discard the packet and return an ICMP 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. This is because otherwise the Manet gateway would not learn nodes in the network. The request propagates in the Manet towards Internet-gateways, instead. If an intermediate node receives a data packet not destined to it, it then normally forwards such a packet towards its destination. 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. R. Wakikawa et.al. Expires 14 May 2002 [Page 13]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 12. Protocol Constants Parameter Name Value ---------------------- ----- ALL_MANET_GW_MULTICAST ff1e::xx/64 global GWINFO_LIFETIME 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 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. Acknowledgements The authors would like to thank Elizabeth Royer for her comments on streamlining some aspects of the design. References [1] D. Johnson and C. Perkins. Mobility support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, November 2000. [2] 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. [3] 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. [4] 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. [5] C. Perkins, E. Royer, and S. Das. Ad hoc on demand distance vector (AODV) routing (work in progress). Internet Draft, Internet Engineering Task Force, March 2000. R. Wakikawa et.al. Expires 14 May 2002 [Page 14]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 [6] C. Perkins, E. Royer, and S. Das. IP broadcast in ad hoc mobile networks (work in progress). Internet Draft, Internet Engineering Task Force, November 2001. R. Wakikawa et.al. Expires 14 May 2002 [Page 15]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 A. 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 [5], more precisely, to its IPv6 variant [4]. All the operation except for a specific explanation in this section follow the descriptions presented earlier in this document. A.1. Additions to AODV6 specification 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 R. Wakikawa et.al. Expires 14 May 2002 [Page 16]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 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 A.2. Global Address Resolution This section describes how to get 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 RREQ for global address resolution, it can use an arbitrary global scoped address from its interfaces as the IPv6 source address. This can be, e.g., its Mobile IPv6 home address or a temporary address from the MANET_INITIAL_PREFIX, created for this purpose. It broadcasts the RREQ with the INTERNET_GATEWAYS global multicast address as the destination address field in the routing protocol message and sets the `I' flag. When an Internet-gateway receives a RREQ with the `I' flag set, it checks its routing entry towards to the receiving network interface and updates the entry of the node using the source address in the RREQ. The Internet-gateway constructs a Route Reply (RREP), as defined below, and unicasts it to the requesting node. The IPv6 header field should be built as in normal AODV6 operation. The global prefix information is derived from the responding IPv6 address and its prefix length is that R. Wakikawa et.al. Expires 14 May 2002 [Page 17]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 in the Internet-gateway for the responding address. The `I' flag is set in the RREP. After acquiring a a topologically correct global IPv6 address, the node first deletes the temporary address from the MANET_INITIAL_PREFIX, but not the arbitrary address. And the node broadcasts a Route Error (RERR) with the temporary address to delete all the related host routes. This RERR also creates new reverse routes for the global IPv6 address at intermeditate nodes and Internet-gateways, even though AODV6 specification can not permit to set reverse route from RERR. Another RREQ can be sent over the Manet to create the reverse route at the intermediate nodes. These reverse routes become the route path to the Internet-gateway with the global address. The Internet-gateway should insert the host route of the node into its routing table. The old entry related to the temporary address will be discarded after lifetime expiration. If the node sends a packet to the Internet without a routing header, some intermediate nodes generate RERR message because they do not have an active route to the packet's destination according to AODV specification [5]. To avoid this unnecessary RERR, a default route is defined as the active route in this document. The intermediate node has an active default route. If it does not know the host route to the destination, it routes the packet to the default route. If the node uses a routing header, the destination address in IPv6 header should be the Internet-gateway IPv6 address. All the intermediate nodes on the route path to the Internet-gateway have the 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 14 May 2002 [Page 18]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 B. 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 [1] 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 entry for R. Wakikawa et.al. Expires 14 May 2002 [Page 19]
Internet Draft Global Connectivity for IPv6 Manets 14 November 2001 gateway prior to the entry for home address, and setting the segments left to two. Authors' Addresses Ryuji Wakikawa Charles Perkins Graduate School Communications Systems Lab of Media and Governance Nokia Research Center Keio University 313 Fairchild Drive 5322 Endo Fujisawa Kanagawa 252 Mountain View, California 94043 JAPAN 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 94043 SF-221 00 Lund USA Sweden Phone: +1-650 625-2355 Phone:+46-46-222-03-67 EMail: jmalinen@iprg.nokia.com EMail: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 14 May 2002 [Page 20]