Internet DRAFT - draft-nhkim-name-based-autoconf
draft-nhkim-name-based-autoconf
IETF AUTOCONF(BOF) N. Kim
Internet-Draft Y. Lee
Expires: May 5, 2006 S. Kang
Information and Communications
University, Computer Networks Lab
B. Lee
Oregon State University
November 2005
Name-Based Autoconfiguration for MANET
draft-nhkim-name-based-autoconf-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on May 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In a mobile ad hoc network, difficulties exist in supporting address
autoconfiguration and naming resolution due to the lack of
centralized servers. This document presents a novel approach, called
Name-Based Autoconfiguration (NBA), which uses host names to
Kim, et al. Expires May 5, 2006 [Page 1]
Internet-Draft Name-Based Autoconfiguration for MANET November 2005
determine IP addresses and provides address autoconfiguration and
name resolution as a single protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Name-Based Autoconfiguration . . . . . . . . . . . . . . . . . 6
3.1. NBA Operation . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Enhanced NBA: NBA-LP and NBA-DH . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Consideration . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Kim, et al. Expires May 5, 2006 [Page 2]
Internet-Draft Name-Based Autoconfiguration for MANET November 2005
1. Introduction
Addressing configuration is a necessary step to facilitate
communications among hosts (or nodes), and naming service allows
users to conveniently use applications such as telnet, ftp, email,
http, SIP and file sharing. However, administration of these hosts
becomes difficult as the number of hosts grows in a network region.
This is especially the case for ubiquitous networks based on Mobile
Ad hoc Networks (MANETs) due to the lack of administrative
infrastructure such as DHCP and DNS servers. Thus, the process of
address configuration and naming service should be automated and
hidden from users.
In prior studies of address autoconfiguration for MANETs, some
researchers suggest mechanisms to avoid address conflicts before
joining a MANET [1] - [6]. For example, in the Strong Duplicated
Address Detection (DAD) scheme [1], a new node joining a MANET
randomly selects an IP address and then determines whether other
nodes in the MANET are currently using the selected address. If the
new node receives a message from another node indicating the address
is currently being used (i.e., NACK), the DAD process is repeated
until a unique address can be obtained. In MANETconf [2], an agent
node selected by the new node performs DAD and assigns the address to
the new node. MANETconf uses a modified DAD that utilizes ACKs as
well as NACKs, which may lead to the ACK explosion problem. In
addition, a conflict free allocation method [3] is suggested, and a
centralized method [4] where one node can act as a DHCP server is
also suggested. Other studies are not involved with address
configuration, but instead suggest solutions to detect and solve the
address conflicts caused by network merging using a special key or
rely on the aid of a routing protocol [5], [6].
Naming resolution schemes for MANETs are classified as either
distributed or partially distributed. In a distributed method, every
node acts a name server to resolve names. In a partially distributed
method, name brokers are distributed throughout the MANET and they
cache the names of surrounding nodes [7]. Existing naming resolution
schemes assume each node already has a unique address and name, but
they require time intensive procedure and consume considerable
bandwidth to guarantee uniqueness. As mobility increases, the
probability of address changes increases. This requires more
frequent name resolutions than for applications in infrastructure
mode. The existing distributed name resolution methods need to
broadcast, which causes considerable message overhead. Therefore, a
name resolution scheme without or minimum broadcast messages is
highly desirable in a MANET.
As discussed previously, prior studies on address configuration and
Kim, et al. Expires May 5, 2006 [Page 3]
Internet-Draft Name-Based Autoconfiguration for MANET November 2005
naming resolution have dealt with the two issues separately.
However, if users include host names with their applications, the
names must be resolved into IP addresses. That is, in order to allow
applications to use host names, the address and name must be binding.
Since IP address and host name are closely related in terms of the
applications, a novel autoconfiguration mechanism, called Name-Based
Autoconfiguration (NBA), is proposed to support both address
configuration and naming resolution as a single protocol. This is
achieved by allocating IP addresses based on hashed values of host
names rather randomly generated addresses, which eliminates the need
to perform naming service. This is in contrast to existing methods
[1] - [6] that must hire a separate name resolution scheme for naming
service. Therefore, NBA saves time required for configuration and
minimizes communication overhead.
Kim, et al. Expires May 5, 2006 [Page 4]
Internet-Draft Name-Based Autoconfiguration for MANET November 2005
2. Terminology
MANET Node/Host
- A device with one or more wireless network interface which is used
by the MANET routing protocol in use.
Mobile Ad hoc Networks(MANET)
- A spontaneous and arbitrary network that consists of a group of
mobile wireless devices; it lacks any fixed infrastructure or
administration, and possesses a network topology that may change
quickly and unexpectedly as a result of the mobility of nodes
Duplicate Address Detection(DAD)
- The process that a MANET node confirms the uniqueness of an
address. That is, DAD means that a simple mehod finding duplicated
addresses in a network.
MD5, SHA1
- MD5 and SHA1 are well known hash functions. They generate 128-bit
word, and usually use in electronic signitures.
name-to-address resolution
- The process that translates name to address; if a node wants to
communicate with another node in IP network, it must know the IP of
destination node. The node obtains the targer address using the
target name. This process is referred to name-to-address resolution.
In wired network, DNS is in charge of the resolution.
displacement
- When we make a hash table, an input value occupies the specific
location of hash table accodring to the hashed value. However, the
location is already occupied others, the input value must relocate
another location. In that time, the difference between original
location and new location is referred to displacement.
Kim, et al. Expires May 5, 2006 [Page 5]
Internet-Draft Name-Based Autoconfiguration for MANET November 2005
3. Name-Based Autoconfiguration
NBA focuses mainly on name-to-address resolution, because name-to-
address resolution is more popular than address-to-name resolution
for user applications. For address-to-name resolution, the proposed
scheme would require messages to be broadcasted just as in existing
name resolution schemes. In addition, all the nodes are assumed to
employ identical hash functions, such as MD5 [8].
3.1. NBA Operation
A new host can obtain the hashed value of its name, but this is only
a possible candidate of its address. The new host must then check
whether or not another host is already using the candidate address.
If the address is not being used in the network, the host can
configure itself based on the address. Otherwise, its host name is
changed, a new address is obtained, and the confirmation process is
retried with the new address. This is repeated until the host finds
a unique IP address.
3.2. Enhanced NBA: NBA-LP and NBA-DH
The major challenge with NBA is that the hashing function used, i.e.,
MD5, generates a 128-bit word while the address size in IPv4 or IPv6
is smaller. Thus, the number of bits in the hashed value must be
reduced to match the address size. If the limited address range
causes conflicts, the host name has to be changed. However, if the
name is unique, it is advantageous to use it rather than requiring
the host to alter its name. In order to eliminate the need to change
host names, the following two enhancements based on hashing
characteristics [9] have been incorporated into the basic NBA: (1)
NBA with Linear Probing (NBA-LP) and (2) NBA with Double Hashing
(NBA-DH).
The major difference between NBA and the two enhanced NBA schemes is
that the latter does not unnecessarily change the host name when
conflicts occur. In NBA-LP, if a new node causes an address
conflict, instead of changing its name, the confirmation process is
performed with another address, which is the previous address plus
one. If a conflict occurs again, the confirmation process is
repeated with the previous address plus one, and this process is
repeated until the node finds a unique address. This causes a
difference, which is referred to as displacement, between the
original address generated by the hash function and the final
configured address. Thus, an exact match between the address and the
hashed value of the name cannot be guaranteed.
Although NBA-LP avoids unnecessary host name changes, the IP address
Kim, et al. Expires May 5, 2006 [Page 6]
Internet-Draft Name-Based Autoconfiguration for MANET November 2005
resolution takes longer compared to NBA due to the displacement
problem. In comparison, NBA-DH employs two hash functions to reduce
the likelihood of conflicts, where the second hash function is
assumed to be SHA1 [8]. Therefore, if a new node encounters a
conflict during the addressing phase, the second hashed value of the
name is generated. Then, the first value is added to the second
value, and the result is adjusted to the fixed address size using a
modular function. Finally, the node performs the confirmation
process with the adjusted value. If the host encounters an address
conflict again, it simply defers to NBA-LP.
Kim, et al. Expires May 5, 2006 [Page 7]
Internet-Draft Name-Based Autoconfiguration for MANET November 2005
4. Discussion
The NBA scheme provides simultaneous address configuration and naming
service for a MANET. Thus, NBA reduces the total number of messages
and the average latency to perform address allocation and naming
resolution. Especially, users can conveniently use the naming
service due to early binding between the host name and IP address
without broadcasting messages. This document also discussed two
enhancements, NBA-LP and NBA-DH, for the case when a host name needs
to be changed even though the name is unique within the network.
However, NBA-LP and NBA-DH may incur some overhead to configure the
address and to perform name-to-address resolution due to
displacement. In terms of name resolution cost, NBA-DH may give
better performance due to lower displacement than NBA-LP.
Kim, et al. Expires May 5, 2006 [Page 8]
Internet-Draft Name-Based Autoconfiguration for MANET November 2005
5. Security Consideration
This document does not consider security issue.
6. References
[1] Perkins, C., Malinen, J., Wakikawa, R., Belding-Royer, E., and
Y. Sun, "IP Address Autoconfiguration for Ad Hoc Networks",
I-D draft-ietf-manetautoconf-01.txt, November 2001.
[2] Nesargi, S. and R. Prakash, "MANETconf: Configuration of Hosts
in a Mobile Ad Hoc Network", IEEE INFOCOM 2002 , June 2002.
[3] Zhou, H., Ni, L., and M. Mutka, "Prophet Address Allocation for
Large Scale MANETs", IEEE INFOCOM 2003 , March 2003.
[4] Gunes, M. and J. Reibel, "An IP address configuration Algorithm
for Zeroconf. Mobile Multi hop Ad hoc Networks", International
Workshop on Broadband Wireless Ad Hoc Networks and Services ,
September 2002.
[5] Vaidya, N., "Weak Duplicate Address Detection in Mobile Ad Hoc
Networks", ACM MobiHoc 2002 , June 2002.
[6] Weniger, K., "Passive Duplicate Address Detection in Mobile Ad
hoc Networks", IEEE WCNC 2003 , March 2003.
[7] Engelstad, P., Thanh, D., and T. Jonvik, "Name Resolution in
Mobile Ad hoc Networks", ICT 2003 , February 2003.
[8] Kaufman, C., Perlman, R., and M. Speciner, "Network Security,
Private Communication in a Public World", Prentice Hall , 2002.
[9] Knuth, Donald E., "Sorting and Searching", Addison Wesley, The
Art of Computer Programming, 1973.
Kim, et al. Expires May 5, 2006 [Page 9]
Internet-Draft Name-Based Autoconfiguration for MANET November 2005
Authors' Addresses
Namhoon Kim
Information and Communications University, Computer Networks Lab
Munji Ro 119
Daejeon, Yuseong Gu 305-732
Korea Rep.
Phone: +82 042 866 6251
Fax: +82 042 866 6222
Email: nhkim@icu.ac.kr
Younghee Lee
Information and Communications University, Computer Networks Lab
Munji Ro 119
Daejeon, Yuseong Gu 305-732
Korea Rep.
Phone: +82 042 866 6112
Fax: +82 042 866 6222
Email: yhlee@icu.ac.kr
Sae Hoon Kang
Information and Communications University, Computer Networks Lab
Munji Ro 119
Daejeon, Yuseong Gu 305-732
Korea Rep.
Phone: +82 042 866 6251
Fax: +82 042 866 6222
Email: kang@icu.ac.kr
Ben Lee
Oregon State University
Owen Hall 302, Corvallis
Oregon State, OR 97331
USA
Phone: +1 541 737 3148
Fax: +1 541 737 1300
Email: benl@eecs.oregonstate.edu
Kim, et al. Expires May 5, 2006 [Page 10]
Internet-Draft Name-Based Autoconfiguration for MANET November 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kim, et al. Expires May 5, 2006 [Page 11]
