Mobile Ad Hoc Networking Working Group Charles E. Perkins INTERNET DRAFT Nokia Research Center 10 July 2000 Elizabeth M. Royer University of California, Santa Barbara Samir R. Das University of Cincinnati IP Address Autoconfiguration for Ad Hoc Networks draft-perkins-manet-autoconf-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 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, we specify 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. Perkins Expires 10 January 2001 [Page i] Internet Draft Ad Hoc Address Autoconfiguration 10 July 2000 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, we specify 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. 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, analogous to the way that Autonet allocations are done and as is proposed in the zeroconf working group [2]. 2. Applicability Statement The specifications in this document are only designed for use with ad hoc network protocols that offer a mechanism for ``route discovery'', as defined in section 3. Furthermore, these mechanisms 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. Note that any such specification would have to ensure that network healing is not accompanied by a broadcast storm of DAD messages. Note that this document is not a specification for new protocol messages. Instead, it is a specification for IP address autoconfiguration, using existing protocol messages from other routing protocols that offer the required features as indicated in the previous paragraph. 3. Terminology This protocol specification uses conventional meanings [1] for capitalized words such as MUST, SHOULD, etc., to indicate requirement levels for various protocol features. This section defines other terminology used with AODV that is not already defined in [3]. Perkins Expires 10 January 2001 [Page 1] Internet Draft Ad Hoc Address Autoconfiguration 10 July 2000 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 nodes 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. Route discovery The process by which a node in an ad hoc network discovers a route to a particular destination. Route request (RREQ) The message used during route discovery to request the route to the destination. Route reply (RREP) The message used during route discovery to supply the requested route to the destination. 4. Address Autoconfiguration Following the suggestions for Duplicate Address Detection (DAD) as with IPv6 Stateless Address Autoconfiguration [4] and zeroconf, the node first picks a random IP address in the range 2048-65534 from 169.254/16. Then, the node issues a RREQ for that randomly selected address. If no RREP is returned for the selected address within a timeout period, the node retries the RREQ up to RREQ_RETRIES times. If, after all retries, no RREP is still received, the node assumes that the address is not already in use, and assumes that the address can safely be taken for its own. Otherwise, the node randomly picks another address from the same range and begins the ad hoc DAD procedure again. In order for a return route to be built for a possible RREP, the node performing DAD has to have use of some temporary IP address. This temporary IP address is to be selected from the range 1-2047 of the class B network 169.254/16. No address in that range should ever be selected for permanent assignment by any node in the ad hoc network; all such addresses are only to be used for the purpose of targeting possible RREP messages produced during DAD. It is expected that this will provide enough addresses for the purpose, since each address would never be used for more than a few seconds or a few hundreds of milliseconds. Perkins Expires 10 January 2001 [Page 2] Internet Draft Ad Hoc Address Autoconfiguration 10 July 2000 The values for the timeout and RREQ_RETRIES parameters for the RREQ messages issued during DAD are the same as their usual values for regular RREQ messages in the base routing protocol. 5. 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 a route to any given IP address, so that another node would receive RREP 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. 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] E. Guttman and S. Cheshire (chairs). Zero Configuration Networking (zeroconf), June 1999. http://www.ietf.org/html.charters/zeroconf-charter.html. [3] Charles E. Perkins. Terminology for Ad-Hoc Networking (work in progress). draft-ietf-manet-terms-00.txt, November 1997. [4] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Engineering Task Force, December 1998. Perkins Expires 10 January 2001 [Page 3] Internet Draft Ad Hoc Address Autoconfiguration 10 July 2000 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 691 2170 (fax) charliep@iprg.nokia.com Elizabeth M. Royer Dept. of Electrical and Computer Engineering University of California, Santa Barbara Santa Barbara, CA 93106 +1 805 893 7788 +1 805 893 3262 (fax) eroyer@alpha.ece.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 Expires 10 January 2001 [Page 4]