One document matched: draft-jeong-name-generation-01.txt
Differences from draft-jeong-name-generation-00.txt
Individual Submission
Internet Draft Jae-Hoon Jeong
Jung-Soo Park
Hyoung-Jun Kim
<draft-jeong-name-generation-01.txt> 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]
| PAFTECH AB 2003-2026 | 2026-04-23 04:04:41 |