Individual Submission Internet Draft Jae-Hoon Jeong Jung-Soo Park Hyoung-Jun Kim ETRI Expires: August 2003 February 2003 Unique DNS Name Generation Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted [1]. 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 This document describes a mechanism of generating a unique DNS name automatically. This mechanism is useful when a node wants to configure a unique domain name in its network interface automatically in the environment where there is no dedicated DNS name server, such as the unmanaged home-network and ad-hoc network. Conventions used in this document The key words "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 [2]. Table of Contents Jeong, Park, Kim Expires - August 2003 [Page 1] Unique DNS Name Generation February 2003 1. Introduction...................................................2 2. Mechanism of Unique DNS Name Generation........................2 3. DNS Name Generation in IPv6....................................3 4. DNS Name Generation in IPv4....................................4 5. Implementation Considerations..................................4 6. Security Considerations........................................4 7. References.....................................................4 8. Author's Addresses.............................................5 1. Introduction This document describes a simple mechanism which generates a unique domain name for a node in home-network or ad-hoc network where there is no network manager. This mechanism is useful when a node would like to configure a unique domain name per network interface of a node automatically in the environment where there is no dedicated DNS name server and network manager, such as the unmanaged home- network and ad-hoc network. 2. Mechanism of Unique DNS Name Generation The mechanism for DNS name generation makes a unique domain name with user-id, device-id (network device's address extended into EUI-64) and domain like Figure 1 [3]. ---------------------------------------------- | user-id | device-id | domain | ---------------------------------------------- Figure 1. Format of DNS name "user-id" is the user identifier selected by user and "device-id" is EUI-64 identifier derived from the network device's built-in 48-bit IEEE 802 address [3]. "domain" indicates the domain where a node is placed and SHOULD include "EUI-64" sub-domain which indicates that the domain name is based on EUI-64. The domain for ad-hoc network is defined as "EUI-64.ADHOC." and that for home-network as "EUI- 64.HOMENET.". For example, when user-id is "PAUL", device-id is "36-56-78-FF-FE- 9A-BC-DE", and domain is "EUI-64.ADHOC.", a unique domain name would be "PAUL.36-56-78-FF-FE-9A-BC-DE.EUI-64.ADHOC." [4]. The advantage of the above mechanism guarantees that no name conflict happens although users in other nodes use the same user-id. For example, like Figure 2, there are node A, B and C in the same subnet and they all use the same user-id, "PAUL". The domain where they are placed is "EUI- 64.ADHOC.". The domain name of each node is made like Table 1. The domain name "NAME1" is for node A, the domain name "NAME2" is for node B. When node C generates its domain name on the basis of its Jeong, Park, Kim Expires - August 2003 [Page 2] Unique DNS Name Generation February 2003 user-id "PAUL" and device-id derived "EUI64-3" from its network device address "MAC3". Though node C uses the same user-id as node A and B, it can configure a unique domain name owing to the difference of network device address without the procedure of verifying the uniqueness of domain name [5]. (NAME1: PAUL+MAC1) (NAME3: PAUL+MAC3) (NAME2: PAUL+MAC2) [Node A] [Node C] [Node B] | | | | | | --------------------------------------------------------- Figure 2. Network configuration regarding the generation of a unique DNS name Table 1 shows how nodes with the same user-id can configure a unique domain name with their different EUI-64 identifier derived from their own network device address. ------------------------------------------------------------ | || | | | | name || user-id | device-id | domain | | (node) || |(N/W device address)| | | || | | | ============================================================ | NAME1 || PAUL | EUI64-1 | EUI-64.ADHOC. | | (Node A) || | (MAC1) | | ------------------------------------------------------------ | NAME2 || PAUL | EUI64-2 | EUI-64.ADHOC. | | (Node B) || | (MAC2) | | ------------------------------------------------------------ | NAME3 || PAUL | EUI64-3 | EUI-64.ADHOC. | | (Node C) || | (MAC3) | | ------------------------------------------------------------ Table 1. Configuration of DNS names of the nodes in Figure 2 Thus, nodes can configure their unique domain name regardless of their user-id. 3. DNS Name Generation in IPv6 In most systems, because the manual configuration of network device address, i.e., MAC address, is allowed, the duplicate MAC address can exist in the network. In this case, the DNS names based on network device identifier can be duplicate in the network. Therefore, the verification of the uniqueness of generated DNS name is necessary. Jeong, Park, Kim Expires - August 2003 [Page 3] Unique DNS Name Generation February 2003 In IPv6 stateless address autoconfiguration, the low-order 64-bit interface identifier derived from network device identifier is verified through duplicate address detection (DAD) [6]. Therefore, IPv6 node generates a unique domain name per network interface by using the verified low-order 64 bits of the IPv6 unicast address that has been already configured in the network interface. 4. DNS Name Generation in IPv4 A unique IPv4 address can be autoconfigured through the dynamic configuration of IPv4 link-local address through in the zeroconf environment [7]. On an IPv4 address being configured in network interface, the uniqueness of the address is verified through duplicate detection mechanism. With this unique address, a unique DNS name can be generated. The 64-bit EUI-64 identifier for "device-id" of the unique DNS name is derived from an EUI-64 format having the embedded IPv4 address like ISATAP [8]. 5. Implementation Considerations user-id and domain are registered as options statement of the configuration file for DNS name server as follows; options { user-id "PAUL"; domain "EUI-64.ADHOC."; }; The DNS name automatically generated with the above information can be used in order to make DNS resource records for DNS service with the IP address (IPv4 or IPv6 address) which is associated with network interface. 6. Security Considerations As network device identifier (or MAC address) is exposed in DNS name, there would be security attack. To prevent the attack, we SHOULD use hash function that can hide the network device identifier. The binary string of the EUI-64 identifier for "device-id" is hashed through hash function, such as MD5 and HMAC [9][10]. 7. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Jeong, Park, Kim Expires - August 2003 [Page 4] Unique DNS Name Generation February 2003 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] "Guidelines For 64-bit Global Identifier (EUI-64)", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html [4] M. Crawford, "Transmission of IPv6 Packets over Ethernet Networks", RFC2464, December 1998. [5] Levon Esibov and Dave Thalor, "Linklocal Multicast Name Resolution (LLMNR)", I-D draft-ietf-dnsext-mdns-12, February 2003. [6] S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [7] Stuart Cheshire, Bernard Aboba and Erik Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", draft-ietf-zeroconf-ipv4-linklocal-07.txt, August 2002. [8] F. Templin, T. Gleeson, M. Talwar and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap-12.txt, January 24, 2003. [9] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [10] H. Krawczyk, M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. 8. Author's Addresses Jae-Hoon Jeong ETRI / PEC 161 Gajong-Dong, Yusong-Gu Daejon 305-350 Korea Phone: +82 42 860 1664 EMail: paul@etri.re.kr Jung-Soo Park ETRI / PEC 161 Gajong-Dong, Yusong-Gu Daejon 305-350 Korea Phone: +82 42 860 6514 EMail: pjs@etri.re.kr Jeong, Park, Kim Expires - August 2003 [Page 5] Unique DNS Name Generation February 2003 Hyoung-Jun Kim ETRI / PEC 161 Gajong-Dong, Yusong-Gu Daejon 305-350 Korea Phone: +82 42 860 6576 EMail: khj@etri.re.kr Jeong, Park, Kim Expires - August 2003 [Page 6]