Mobile Ad Hoc Networking Working Group Charles E. Perkins INTERNET DRAFT Jari T. Malinen 14 November 2001 Ryuji Wakikawa Nokia Research Center Elizabeth M. Belding-Royer Yuan Sun University of California, Santa Barbara IP Address Autoconfiguration for Ad Hoc Networks draft-ietf-manet-autoconf-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 If a node lacks an IP address, it cannot yet participate in ad hoc networks as currently designed, because the connectivity in an ad hoc network is typically determined by mechanisms that depend upon using the IP address as the identifier for the nodes in the ad hoc network. In this document, a mechanism by which a node in an ad hoc network may autoconfigure an IP address which is unique throughout the connected portion of the ad hoc network is specified. Specifically, mechanisms for both IPv4 and IPv6 networks, which are isolated from Internet connectivity, are described. Perkins, et. al. Expires 14 May 2002 [Page i] Internet Draft Ad Hoc Address Autoconfiguration 14 November 2001 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Applicability Statement 2 3. Terminology 2 4. Overview 3 5. Packet Formats 3 5.1. IPv4 Address Request . . . . . . . . . . . . . . . . . . 3 5.2. IPv4 Address Reply . . . . . . . . . . . . . . . . . . . 4 5.3. IPv6 Address Request . . . . . . . . . . . . . . . . . . 5 5.4. IPv6 Address Reply . . . . . . . . . . . . . . . . . . . 6 6. IPv4 Address Autoconfiguration 7 6.1. Address Request (AREQ) . . . . . . . . . . . . . . . . . 7 6.2. Address Request Processing . . . . . . . . . . . . . . . 7 6.3. Address Reply Processing . . . . . . . . . . . . . . . . 8 7. IPv6 Address Autoconfiguration 9 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Address Request and Reply . . . . . . . . . . . . . . . . 9 8. Security Considerations 10 9. Configuration Parameters 10 1. Introduction If a node lacks an IP address, it cannot yet participate in ad hoc networks as currently designed, because the connectivity in an ad hoc network is typically determined by mechanisms that depend upon using the IP address as the identifier for the nodes in the ad hoc network. In this document, a mechanism by which a node in an ad hoc network may autoconfigure an IP address which is unique throughout the connected portion of the ad hoc network is specified. Mechanisms for configuring both IPv4 and IPv6 addresses, as appropriate, are specified. Perkins, et. al. Expires 14 May 2002 [Page 1] Internet Draft Ad Hoc Address Autoconfiguration 14 November 2001 When a node in an ad hoc network wishes to obtain an IP address, it may be difficult or impossible to contact any address allocation agency in the network. In such cases, according to the specifications given in this document, the node attempts to select a random address (on network 169.254/16 in case of IPv4, or on prefix MANET_INITIAL_PREFIX in case of IPv6). This is analogous to the way that Autonet allocations are done, and as is proposed in the zeroconf working group [3]. 2. Applicability Statement The mechanisms described in this document do not guarantee uniqueness in disconnected networks. If a network is disconnected, the process for Duplicate Address Detection (DAD) would need to be performed again when the network partition heals. This document does not specify any method for detecting when the network partition heals, nor any procedure by which such detection would cause new attempts at DAD. Any such specification would have to ensure that network healing is not accompanied by a broadcast storm of DAD messages. The mechanisms designed in this document are designed to work independently of the protocols (i.e., routing or MAC) utilized within the protocol stack. 3. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. This section defines other terminology used with AODV that is not already defined in [2]. Duplicate Address Detection (DAD) The process by which a node, which lacks an IP address, determines whether a candidate address it has selected is available. A node already equipped with an IP address participates in DAD in order to protect its IP address from being accidentally misappropriated for use by another node. Address Discovery The process by which a node in an ad hoc network discovers whether an address is already claimed within an ad hoc network. Perkins, et. al. Expires 14 May 2002 [Page 2] Internet Draft Ad Hoc Address Autoconfiguration 14 November 2001 Address Request (AREQ) The message used during address discovery to request the address. Address Reply (AREP) The message used during address discovery to indicate the requested address is already utilized. 4. Overview This protocol specifies how an IPv4 or IPv6 Manet node autoconfigures itself an address and executes a protocol exchange to check for uniqueness of this address within the reachable Manet. The protocol specifies address ranges for IPv4, and IPv6 from which to locally select the address and a message exchange for the uniqueness test of the selected address. A Manet node performing the autoconfiguration picks two addresses, a temporary address and the actual address to use. The former is used only once in the uniqueness check to minimize the possiblity for it to be non-unique. The uniqueness check is based on sending an Address Request (AREQ) and expecting an Address Reply (AREP) back in case the address is not unique. In case no AREP is received, the uniqueness check is passed. For IPv4, the messages are ICMP [5] packets. For IPv6, on the other hand, the AREQ is a modified Neighbor Solicitation and the AREP is a modified Neighbor Advertisement, as specified below and in the Neighbor Discovery Protocol [4, 6]. 5. Packet Formats 5.1. IPv4 Address Request 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator's IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Perkins, et. al. Expires 14 May 2002 [Page 3] Internet Draft Ad Hoc Address Autoconfiguration 14 November 2001 The format of the Address Request message is illustrated above, and contains the following fields: Type 1 Reserved Sent as 0; ignored upon reception. Originator's IPv4 Address The randomly selected temporary IP address used by the orginator of the flooded AREQ message. Requested IPv4 Address The randomly selected IPv4 address that is being requested by the node issuing the address request. This address may lie in the range FIRST_PERM_ADDR - 65534 from 169.254/16. 5.2. IPv4 Address Reply 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Address Reply message is illustrated above, and contains the following fields: Type 2 Reserved Sent as 0; ignored upon reception. Requested IPv4 Address The randomly selected IPv4 address that is being requested by the node issuing the address request. This address may lie in the range FIRST_PERM_ADDR - 65534 from 169.254/16. Perkins, et. al. Expires 14 May 2002 [Page 4] Internet Draft Ad Hoc Address Autoconfiguration 14 November 2001 5.3. IPv6 Address Request 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Requested IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- The format of the IPv6 Address Request message is illustrated above, it being a modified Neighbor Solicitation as defined in RFC 2461 [4] and used in RFC 2462 [6]. It contains the following modifications to NDP: Manet Neighbor Solicitation Flag (M) When set, this flag indicates that this Neighbor Solicitation message should be sent over a multi-hop network. It indicates that the packet is used with a Manet Duplicate Address Detection over the Manet instead of only sending it one hop to the immediate neighbors. Requested IPv6 Address The locally selected IPv6 address that is being requested by the node issuing the address request. This address may be chosen by selecting e.g., at random a host number from a suitable prefix, by default from a site-local prefix MANET_PREFIX. IP Fields: Hop Limit This field SHOULD be set to NET_DIAMETER to allow for the modified NDP packet to traverse multiple hops up to the edge of the Manet. Source Address This is a site-local, short-lived temporary address Perkins, et. al. Expires 14 May 2002 [Page 5] Internet Draft Ad Hoc Address Autoconfiguration 14 November 2001 from the site-local prefix MANET_INITIAL_PREFIX, with a host number randomly picked by the sender of this AREQ, used only once in the address uniqueness messages. This address is also used as the IPv6 UID. Destination Address This is the all-nodes multicast address, 0xffQQ::QQQQ. 5.4. IPv6 Address Reply 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|O|M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Requested IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- The format of the IPv6 Address Reply message is illustrated above. It is a modified Neighbor Advertisement as defined in RFC 2461 [4] and used in RFC 2462 [6]. It contains the following modifications to NDP: Manet Neighbor Advertisement Flag (M) When set, this flag indicates that this Neighbor Advertisement message should be sent over a multi-hop network. It indicates that the packet is used with a Manet Duplicate Address Detection over the Manet instead of only sending it one hop to the immediate neighbors. Requested IPv6 Address The IPv6 address that is being requested by the node issuing the address request. This address was chosen by the sender of the AREQ selecting e.g., at random a host number from a suitable prefix, by default from a site-local prefix MANET_PREFIX. Perkins, et. al. Expires 14 May 2002 [Page 6] Internet Draft Ad Hoc Address Autoconfiguration 14 November 2001 IP Fields: Hop Limit This field SHOULD be set to NET_DIAMETER to allow for the modified NDP packet to traverse multiple hops up to the edge of the Manet. Source Address This address is not link-local and belongs to the sender of the AREP. It SHOULD BE the same as the Requested IPv6 Address. Destination Address This is the site-local, short-lived temporary address from the site-local prefix MANET_INITIAL_PREFIX, with a host number randomly picked by the sender of the AREQ, used only once in the address uniqueness messages. This address is also used as the IPv6 UID. 6. IPv4 Address Autoconfiguration 6.1. Address Request (AREQ) Following the suggestions for DAD as with IPv6 Stateless Address Autoconfiguration [6] and zeroconf [3], the node first picks a random IP address in the range FIRST_PERM_ADDR - 65534 from 169.254/16. This is the IP address for which it will issue the address request. The node then selects a random, temporary IP address in the range 0 - LAST_TMP_ADDR. This ID will serve as a source IP address for the short period while the node performs the address discovery. Then, the node issues an Address Request (AREQ) for that randomly selected address. The packet format for the AREQ is given in section 5. The node places its randomly selected source IP address in the the Originator's IPv4 Address field. The node then broadcasts this request to its neighbors. It then sets a timer for ADDRESS_DISCOVERY milliseconds, and proceeds as described in section 6.3. 6.2. Address Request Processing When a node receives an AREQ message, the node first notes the Requested_IP_Address and Originator's IPv4 Address. It checks its buffered list of AREQ message identifiers to determine whether it has seen this request before. If it has already seen this request, it discards the packet. Otherwise, the node enters the values of these fields into a temporary buffer. These two values serve to uniquely identify the request. If the node receives this request again as the packet is rebroadcast by its neighbors, it will note that it Perkins, et. al. Expires 14 May 2002 [Page 7] Internet Draft Ad Hoc Address Autoconfiguration 14 November 2001 has already received the request, and hence will not reprocess the packet. Next, the node creates a reverse route entry for the node indicated by the Originator's IPv4 Address field. It enters this destination address in its route table, and uses the node from which it received the AREQ as the next hop towards the source node. The node enters a lifetime for this route of REVERSE_ROUTE_LIFETIME. In this way, if the node later receives an AREP, the node will have a current route to the source node. Hence it will be able to forward the AREP towards the source node. The node then checks whether its own IP address matches the requested address in the AREQ. If the node's IP address does not match the requested address, it rebroadcasts the packet to its neighbors. On the other hand, if the node has the same IP address as that in the AREQ, the node MUST reply to the packet. To do so, it creates an Address Reply (AREP) packet. The packet format for the AREP is given in section 5. It copies the Requested_IP_Address from the AREQ message, and places them in the AREP. It then unicasts this packet to the source node, as indicated by the source IP address in the IP header of the received AREQ message. The reverse route that was created by the AREQ broadcast is used to route the AREP back to the source node. 6.3. Address Reply Processing When a node originates an AREQ, it sets a timer for ADDRESS_DISCOVERY milliseconds. During that time, it waits for the reception of an AREP. If no AREP is returned for the selected address within a timeout period, the node retries the AREQ up to AREQ_RETRIES times. If, after all retries, no AREP is still received, the node assumes that the address is not already in use, and that the address can safely be taken for its own. On the other hand, if the node does receive an AREP within the discovery period, and if the Requested_IP_Address match its recorded values, then this indicates that another node within the ad hoc network is currently using that Requested_IP_Address. In this case, the node randomly picks another address from the same FIRST_PERM_ADDR - 65534 range and begins the ad hoc DAD procedure again. Perkins, et. al. Expires 14 May 2002 [Page 8] Internet Draft Ad Hoc Address Autoconfiguration 14 November 2001 7. IPv6 Address Autoconfiguration 7.1. Overview This section describes the steps specific to an IPv6 Manet node taken when autoconfiguring an address to its interface. The steps described here adhere to the principles in IPv6 stateless Address Autoconfiguration [6], but with changes as specified below. When an IPv6 node performs Manet address autoconfiguration, it first obtains a non-link-local prefix from which to configure an address. The prefix cannot have link-local scope because the address is valid over a multiple hop distance, not only to the immediate neighbors. The method to obtain a globally routable prefix may be the Internet Gateway Discovery, as described in Global Connectivity for Mobile Ad Hoc Networks [7]. In case the node does not know any suitable prefix, it uses the MANET_PREFIX, with prefix length 64, reserved for this purpose. The node also acquires another temporary address for the sole use of an AREQ-AREP protocol message exchange for the uniqueness check of the chosen address. This second, temporary address is chosen from the MANET_INITIAL_PREFIX. The non-temporary actual address to configure is from the part of the MANET_PREFIX not overlapping with MANET_INITIAL_PREFIX. Hence, unlike in NDP, stateless Manet autoconfiguration occurs whether Manet router advertisements are present or not. The node selects a host number as in IPv6 stateless address autoconfiguration and concatenates this to the prefix. After this, the node performs a uniqueness check to this address, as specified below. 7.2. Address Request and Reply To check for address uniqueness, the node sends an Address Request (AREQ) and expects to receive an Address Reply (AREP) if the tentative address is already in use within the reachable Manet. The AREQ is a modified Neighbor Solicitation containing the tentative address. The AREP is a modified Neighbor Advertisement response to the request. Message formats for IPv6 AREQ and AREP are given in section 5. The IPv6 node broadcasts the AREQ to the all-nodes multicast address as the destination address in the IPv6 header. The source address is a temporary one. It MUST be picked at random from the Perkins, et. al. Expires 14 May 2002 [Page 9] Internet Draft Ad Hoc Address Autoconfiguration 14 November 2001 MANET_INITIAL_PREFIX. This address is only used in this message exchange and discarded thereafter. Uniqueness of this address is based on its short lifetime. A node does the uniqueness check only once for an address and the domain for these short-lived addresses is as large as the IPv4 address space. After sending the AREQ the node then sets a timer to ADDRESS_DISCOVERY milliseconds, and proceeds as described in section 6.3. An AREP is a unicast sent back to the originator of the AREQ in case the tentative address was in use by sender of the AREP. In case no AREP was received within the timer wait, the tentative address is considered valid. Address Request and Reply Processing follow the logic for the processing of the corresponding IPv4 messages. In the case of IPv6, the node unicasts the AREP ADDRESS_RETRIES times, to increase robustness, back to the originator. The return path for AREP unicast MAY be the short lived state of AREQ source IPv6 address, link-layer source address, originating interface triplet which was stored in the intermediate nodes when forwarding the AREQ. When this state exists, a node forwarding a data packet first looks for the IP destination from that state. If found, the node forwards the packet to the respective link using the stored link layer address. 8. Security Considerations This document does not define any method for secure operation of the autoconfiguration protocol. The danger exists that a malicious node may pretend to have any given IP address, so that another node would receive AREP messages apparently denying it the use of whatever address it might choose. This lack of security is problematic for many approaches to IP address autoconfiguration. It is symptomatic of the basic conflict between security, and operation in any mode where preconfigured information (including security association data) is not available. 9. Configuration Parameters This section gives default values for some important values associated with address discovery protocol operations. Perkins, et. al. Expires 14 May 2002 [Page 10] Internet Draft Ad Hoc Address Autoconfiguration 14 November 2001 Parameter Name Value ---------------------- ----- ALL_MANET_NODES ff05:ffff::/64 ADDRESS_DISCOVERY 3 * NODE_TRAVERSAL_TIME * NET_DIAMETER / 2 REVERSE_ROUTE_LIFETIME ADDRESS_DISCOVERY * 2 ADDRESS_RETRIES 3 FIRST_PERM_ADDR 2048 LAST_TMP_ADDR FIRST_PERM_ADDR - 1 MANET_INITIAL_PREFIX fec0:0:0:ffff::/96 MANET_PREFIX fec0:0:0:ffff::/64 NET_DIAMETER 10 NODE_TRAVERSAL_TIME 40 UID_TIMEOUT 2 * ADDRESS_DISCOVERY Perkins, et. al. Expires 14 May 2002 [Page 11] Internet Draft Ad Hoc Address Autoconfiguration 14 November 2001 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] J. Manner et al. Mobility Related Terminology (work in progress). draft-manner-seamoby-terms-02.txt, July 2001. [3] E. Guttman and S. Cheshire (chairs). Zero Configuration Networking (zeroconf), June 1999. http://www.ietf.org/html.charters/zeroconf-charter.html. [4] 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. [5] J. Postel. Internet Control Message Protocol. Request for Comments (Standard) 792, Internet Engineering Task Force, September 1981. [6] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Engineering Task Force, December 1998. [7] R. Wakikawa, J. Malinen, C. Perkins, A. Nilsson, and A. Tuominen. Global connectivity for Mobile Ad Hoc Networks (work in progress). Internet Draft, Internet Engineering Task Force, 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 Perkins, et. al. Expires 14 May 2002 [Page 12] Internet Draft Ad Hoc Address Autoconfiguration 14 November 2001 Ryuji Wakikawa Communications Systems Laboratory Nokia Research Center 313 Fairchild Drive Mountain View, CA 94303 USA +1 650 625 2000 +1 650 625 2502 (fax) rwakikaw@iprg.nokia.com Jari T. Malinen Communications Systems Laboratory Nokia Research Center 313 Fairchild Drive Mountain View, CA 94303 USA +1 650 625 2355 +1 650 625 2502 (fax) jmalinen@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) eroyer@cs.ucsb.edu Yuan Sun Dept. of Computer Science University of California, Santa Barbara Santa Barbara, CA 93106 +1 805 893 8981 +1 805 893 8553 (fax) suny@cs.ucsb.edu Perkins, et. al. Expires 14 May 2002 [Page 13]