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]