Mobile Ad Hoc Networking Working Group Charles E. Perkins INTERNET DRAFT Nokia Research Center 10 November 2000 Elizabeth M. Royer University of California, Santa Barbara Samir R. Das University of Cincinnati Ad hoc On-Demand Distance Vector (AODV) Routing for IP version 6 draft-perkins-aodv6-01.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 The Ad Hoc On-Demand Distance Vector (AODV) routing protocol has been proposed for use with IPv4 as a network-layer protocol linking together mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes between sources and destinations. It uses destination sequence numbers to ensure loop freedom at all times. In this specification, we detail the necessary modifications to the messages given in the IPv4 specification so that AODV will be able to work for nodes using IPv6 addresses. Perkins, Royer, Das Expires 10 April 2001 [Page i]
Internet Draft AODV for IPv6 10 November 2000 Contents Status of This Memo i Abstract i 1. Introduction 1 2. AODV Terminology 2 3. Route Request (RREQ) Message Format 2 4. Route Reply (RREP) Message Format 3 5. Route Error (RERR) Message Format 4 6. Route Reply Acknowledgment (RREP-ACK) Message Format 4 7. AODV for IPv6 Operation 5 8. Extensions 5 9. Configuration Parameters 5 10. Flooding Data to a Specific Destination 5 10.1. Flood Data Option . . . . . . . . . . . . . . . . . . . . 6 10.2. Flood Data Reply Option . . . . . . . . . . . . . . . . . 6 11. Security Considerations 7 1. Introduction The operation of AODV for IP version 6 (IPv6) is intended to mirror the operation of AODV for IP version 4 [4], with changes necessary to allow for transmission of 128-bit addresses in use with IPv6 instead of the more traditional 32-bit addresses. The reader is referred to [4] for most of the terminology, and the specification of the following protocol operations: - Route discovery - Sequence number maintenance - Maintaining local connectivity - Notifying precursors about broken routes - Route expiry and deletion - Actions after reboot Perkins, Royer, Das Expires 10 April 2001 [Page 1]
Internet Draft AODV for IPv6 10 November 2000 Transmission to all nodes in the ad-hoc network is handled in AODV for IPv6 as specified in [5]. 2. AODV Terminology This protocol specification uses conventional meanings [1] for capitalized words such as MUST, SHOULD, etc., to indicate requirement levels for various protocol features. 3. Route Request (RREQ) Message Format 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| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Flooded Packet ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Source Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Destination IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Source IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 4 (in [4]), except as follows: Type 16 Destination IP Address The 128-bit IPv6 address of destination for which a route is desired. Source IP Address The 128-bit IPv6 address of the node which originated the Route Request. Note also that the order of the fields has been changed to enable alignment along 128-bit boundaries. Perkins, Royer, Das Expires 10 April 2001 [Page 2]
Internet Draft AODV for IPv6 10 November 2000 4. Route Reply (RREP) Message Format 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| Reserved | Prefix Size | 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 4 (in [4]), except as follows: Type 17 Prefix Size The Prefix Size is 7 bits instead of 5, to account for the 128-bit IPv6 address space. Destination Sequence Number The destination sequence number associated to the route. Destination IP Address The 128-bit IP address of the destination for which a route is supplied. Source IP Address The 128-bit IP address of the source node which issued the RREQ for which the route is supplied. Note also that the order of the fields has been changed for better alignment. Perkins, Royer, Das Expires 10 April 2001 [Page 3]
Internet Draft AODV for IPv6 10 November 2000 5. Route Error (RERR) Message Format 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 |N| Reserved | DestCount | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreachable Destination Sequence Number (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | : Unreachable Destination IPv6 Address (1) (128 bits) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Additional Unreachable Destination Sequence Numbers (if needed)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Additional Unreachable Destination IPv6 Addresses (if needed) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD The format of the Route Error message is illustrated above, and is identical to the format for the IPv4 RERR message except that the IP addresses are 128 bits, not 32 bits, and the Type is TBD. The order of the fields for the IPv6 addresses and the associated sequence numbers has been changed to enable alignment along 64-bit boundaries. 6. Route Reply Acknowledgment (RREP-ACK) Message Format 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 19 Reserved Sent as 0; ignored on reception. The RREP-ACK message is used to acknowledge receipt of an RREP message. It is used in cases where the link over which the RREP message is sent may be unreliable. It is identical in format to the RREP-ACK message for IPv4, except that the type is 19. Perkins, Royer, Das Expires 10 April 2001 [Page 4]
Internet Draft AODV for IPv6 10 November 2000 7. AODV for IPv6 Operation The handling of AODV for IPv6 messages in sections 3,4,5,6 is analogous to the operation of AODV for IPv4 [4], except that the RREQ, RREP, RERR, and RREP-ACK messages in this document are to be used instead; these messages have the formats appropriate for use with 128-bit IPv6 addresses. Whenever AODV for IPv4 specifies use of ICMP, the operation for IPv6 requires that the analogous messages from ICMPv6 [2] are to be used instead. 8. Extensions RREQ and RREP messages for IPv6 use extensions with the same numbers and format as those extensions defined for IPv4. 9. Configuration Parameters The configuration parameters and default values used by AODV for IPv6 are the same as those used by AODV for IPv4. The Hop Limit field of the IPv6 header MUST be set to a value no greater than NET_DIAMETER for each AODV message. 10. Flooding Data to a Specific Destination For situations in which a message has to be transmitted to a particular destination, the RREQ/RREP route discovery cycle may require a round trip across the entire ad hoc network and back before any data can be delivered. In many circumstances, this represents a significant and unwanted delay. The fewer packets that need to be transmitted to the destination, the more unwelcome the initial delay may be. This first round trip delay appears as an especially large fraction of the total transaction time between endpoints when only a few bytes of data have to be delivered, which could all fit within a single flooded packet. To avoid this problem, a Flood Data hop-by-hop option is specified that allows a packet to be targeted to a particular destination even when the source does not have a route to that destination. AODV furthermore specifies that this hop-by-hop option starts the route discovery process. Then the route request can be satisfied at an intermediate node after it unicasts the data packet towards the destination. Perkins, Royer, Das Expires 10 April 2001 [Page 5]
Internet Draft AODV for IPv6 10 November 2000 When the destination responds to such flooded data packets, it typically needs to stabilize the reverse path back to the source. It does so by inserting a Route Reply hop-by-hop option into the return data packet. 10.1. Flood Data Option The format of the Flood Data Option is as follows: 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 | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |J|R|G| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Flooding ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Source Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- The fields of this hop-by-hop option are defined as for the RREQ message (see section 3), except that there is no longer any need to have the source IPv6 address in the option data. That fields are available in the IPv6 header. The destination IPv6 address in the IP header is set to be the ``All Nodes Address'' lnk-local multicast address (FF02:0:0:0:0:0:0:1) [3], which cannot be forwarded. The Hop Limit field of the IPv6 header is set to a value no greater than NET_DIAMETER [4], with smaller values often preferred in order to limit the dissemination of the RREQ to nearby nodes only. The rules for setting up reverse path route entries to the source IPv6 node are the same as for the RREQ message, which are the same as the rules for the analogous IPv4 messages [4]. Just as with the analogous IPv4 message, the Flooding-ID field is used to avoid extraneous retransmissions for flooded packets. 10.2. Flood Data Reply Option The Flood Data Reply hop-by-hop option is used to return data to the source of a data packet containing the Flood Data hop-by-hop option. Perkins, Royer, Das Expires 10 April 2001 [Page 6]
Internet Draft AODV for IPv6 10 November 2000 The format of the Flood Data Reply Option is as follows: 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 | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|A| Reserved | Prefix Size | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- The fields of this option are defined in the same way as for the Route Reply (RREP) message (see section 4). The rules for setting up forward path route entries to the destination IPv6 node are the same as for the RREP message, which are the same as the rules for the analogous IPv4 messages [4]. 11. Security Considerations Currently, AODV does not specify any special security measures. Route protocols, however, are prime targets for impersonation attacks, and must be protected by use of authentication techniques involving generation of unforgeable and cryptographically strong message digests or digital signatures. It is expected that, in environments where security is an issue, that IPSec authentication headers will be deployed along with the necessary key management to distribute keys to the members of the ad hoc network using AODV. References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. Request for Comments (Draft Standard) 2463, Internet Engineering Task Force, December 1998. [3] R. Hinden and S. Deering. IPv6 Multicast Address Assignments. Request for Comments (Informational) 2375, Internet Engineering Task Force, July 1998. Perkins, Royer, Das Expires 10 April 2001 [Page 7]
Internet Draft AODV for IPv6 10 November 2000 [4] C. Perkins, E. Royer, and S. Das. Ad Hoc On Demand Distance Vector (AODV) Routing (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-manet--aodv-09.txt, November 2001. [5] Charles E. Perkins, Elizabeth M. Royer, and Samir R. Das. IP Broadcast in Ad hoc Networks (work in progress). draft-ietf-manet-bcast-02.txt, November 2001. Author's Addresses Questions about this memo can be directed to: Charles E. Perkins Communications Systems Laboratory Nokia Research Center 313 Fairchild Drive Mountain View, CA 94303 USA +1 650 625 2986 +1 650 625 2502 (fax) charliep@iprg.nokia.com Elizabeth M. Belding-Royer Dept. of Computer Science University of California, Santa Barbara Santa Barbara, CA 93106 +1 805 893 3411 +1 805 893 8553 (fax) ebelding@cs.ucsb.edu Samir R. Das Department of Electrical and Computer Engineering & Computer Science University of Cincinnati Cincinnati, OH 45221-0030 +1 513 556 2594 +1 513 556 7326 (fax) sdas@ececs.uc.edu Perkins, Royer, Das Expires 10 April 2001 [Page 8]