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]