One document matched: draft-jeong-ipv6-ra-dns-autoconf-00.txt
Individual Submission
Internet Draft Jae-Hoon Jeong
Byung-Yeob Kim
Jung-Soo Park
Hyoung-Jun Kim
<draft-jeong-ipv6-ra-dns-autoconf-00.txt> ETRI
Expires: October 2003 17 April 2003
IPv6 Router Advertisement based DNS Autoconfiguration
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 specifies the steps a node takes in deciding how to
autoconfigure its domain name per interface in IP version 6 and the
address of recursive DNS server. The autoconfiguration process
includes a node's creating a domain name for its global address,
verifying the uniqueness of the name in the domain where it is placed
and registering both the regular domain name and inverse domain name
information of the node with DNS server automatically. Also, it
autoconfigures the address of recursive DNS server for DNS name
resolution.
Conventions used in this document
Jeong, Kim, Park, Kim Expires - October 2003 [Page 1]
Internet-Draft IPv6 RA-based DNS Autoconfiguration April 2003
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
1. Terminology....................................................2
2. Introduction...................................................2
3. Overview.......................................................3
4. Neighbor Discovery Extension - DNS Option Message Format.......3
5. Autoconfiguration of Domain Name...............................5
5.1 Generation of Domain Name..................................7
5.2 Verification of the Uniqueness of Domain Name..............7
5.3 Registration of Domain Name................................7
6. Autoconfiguration of Recursive DNS Server......................7
6.1 RDNSS Selection by IPv6 Node...............................8
6.2 Detection of RDNSS Failure.................................8
7. Security Considerations........................................9
8. References.....................................................9
9. Authors' Addresses............................................10
1. Terminology
This memo uses the terminology described in [3][4]. In addition, two
new terms are defined below:
Duplicate Name Detection (DND) A mechanism to verify the uniqueness
of a domain name through DNS dynamic
update.
Recursive DNS Server (RDNSS) A Recursive DNS Server is a name
server that offers the recursive
service of DNS name resolution.
2. Introduction
IPv6 stateless address autoconfiguration [5] provides a way to
autoconfigure either fixed or mobile nodes with one or more IPv6
addresses and default routes.
For the support of the various services in the Internet, such as web
service, not only the configuration of IP address in network
interface, but also that of the recursive DNS server for DNS name
resolution are necessary [6][7][8]. Also, via the IPv6
autoconfiguration facility, the domain name for the autoconfigured
IPv6 address needs to be autoconfigured in the node and registered
with DNS server managing the domain where the node is placed.
Jeong, Kim, Park, Kim Expires - October 2003 [Page 2]
Internet-Draft IPv6 RA-based DNS Autoconfiguration April 2003
This document defines the process for generating a domain name,
verifying the uniqueness of the name through DND [3][9] and
registering the domain name information with DNS server managing the
zone of the domain through DNS dynamic update [3]. Also, it
specifies the autoconfiguration of the IPv6 address(es) of recursive
DNS server for DNS name resolution.
3. Overview
An IPv6 node can autoconfigure its domain name via IPv6 Router
Advertisement (RA) based domain name autoconfiguration [4]. This
automatic mechanism allows a node to generate its own domain name
using a combination of locally available information and information
advertised by routers. A router sends RA message advertising DNS
zone suffix that includes the subnet(s) associated with a link and
the address of DNS server managing the DNS zone. When a node
receives RA message, it selects one of user identifiers configured
within itself and then makes its domain name by combining its
selected user identifier and the DNS zone suffix within RA message.
The node SHOULD verify the uniqueness of the name through DND. If
there is no duplication, the node registers the domain name
information consisting of regular domain name and inverse domain name
information with DNS server managing the zone of the domain through
DNS dynamic update. Otherwise, it tries to make a new name with one
of the other candidates of configured user identifiers and DNS zone
suffix and then configure the name through the procedure of verifying
the uniqueness of the name through DND again. In the absence of
routers, a node can generate only local domain name with local zone
".local" [10] and verifies the uniqueness of the name through DND
[3][9]. If the name is unique, the node configures the name as its
domain name. Otherwise, it tries to make a new name and configure
the name through the procedure of verifying the uniqueness of the
name again.
Also, a node can autoconfigure the IPv6 address of RDNSS for DNS name
resolution through DNS option included in RA message.
4. Neighbor Discovery Extension - DNS Option Message Format
The DNS autoconfiguration mechanism in this document needs a new RA
option in Neighbor Discovery like Figure 1 [4].
Jeong, Kim, Park, Kim Expires - October 2003 [Page 3]
Internet-Draft IPv6 RA-based DNS Autoconfiguration April 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pref |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address of DNS Server +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ DNS Zone Suffix ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. DNS Option Message Format
Fields:
Type 8-bit identifier of the type of option.
Option Name Type
Source Link-Layer Address 1
Link-Layer Address 2
Prefix Information 3
Redirected Header 4
MTU 5
. .
. .
DNS Information (TBD)
Length 8-bit unsigned integer. The length of the
option (including the type and length fields)
in units of 8 octets. The value 0 is invalid.
Nodes MUST silently discard an ND packet that
contains an option with length zero.
Pref The preference of a DNS server. A 4 bit unsigned
integer. A decimal value of 15 indicates the
highest preference. A decimal value of 0
indicates that the DNS server can not be used.
Jeong, Kim, Park, Kim Expires - October 2003 [Page 4]
Internet-Draft IPv6 RA-based DNS Autoconfiguration April 2003
A 1-bit autonomous DNS configuration flag.
When set indicates that this DNS zone suffix can
be used for stateless domain name
autoconfiguration.
IPv6 Address of DNS Server
The IPv6 address of DNS server managing the
domain which the DNS zone suffix indicates. The
scope of the address SHOULD be global.
The prefix of the address is /64.
This address can be used as recursive DNS
server's address for DNS name resolution.
DNS Zone Suffix
The DNS zone suffix of the domain where the
subnet is placed. This field is comprised of
a sequence of labels, where each label consists
of a length octet followed by that number of
octets. The suffix terminates with the zero
length octet for the null label of the root.
This field SHOULD be padded with zeroes to be
the multiple of 8 octets.
When advertising more than one DNS option, as many DNS options as DNS
servers are included in an RA message.
5. Autoconfiguration of Domain Name
IPv6 Node Router DNS Server
| global | |
(a)|(----RS--->)| |
(b)|<----RA-----| |
(c)|---DAD NS---> |
(d)| no NA | |
(e)|------------------------>|
(f)|<------------------------|
| | |
(g)|------------------------>|
(h)|<------------------------|
(i)|------------------------>|
(j)|<------------------------|
| |
Figure 2. Procedure of IPv6 Address and Domain Name
Autoconfiguration
Jeong, Kim, Park, Kim Expires - October 2003 [Page 5]
Internet-Draft IPv6 RA-based DNS Autoconfiguration April 2003
Figure 2 shows the procedure of autoconfiguring a domain name as well
as an IPv6 address in an IPv6 node [11][12]. The procedure consists
of two phases. The first phase is the address autoconfiguration (step
(a) through step (d)) and the second is the domain name
autoconfiguration (step (e) through step (j)) as follows;
Step (a) : IPv6 Node sends RS (Router Solicitation) message to get RA
(Router Advertisement) message. It is optional.
Step (b) : For the RS message received from IPv6 Node, router sends
RA message, which contains prefix option for the stateless address
autoconfiguration and DNS option informing IPv6 nodes of the address
of DNS server and DNS zone suffix.
Step (c) : After making an IPv6 address, the IPv6 Node sends NS
(Neighbor Solicitation) message for duplicate address detection (DAD).
Step (d) : If there is no NA (Neighbor Advertisement) message for the
NS message, the tentative address is unique in the subnet and it can
be used as the IPv6 node's address.
Step (e) : After autoconfiguring an IPv6 address, IPv6 Node makes a
unique domain name with one of the candidates of user id and the DNS
zone suffix announced by DNS option message. It sends DNS Server a
dynamic update request message for verifying the uniqueness of the
domain name through DNS dynamic update [3][9].
Step (f) : DNS Server sends the IPv6 Node a dynamic update response
message. If the response indicates the verified domain name is
unique, the IPv6 Node performs the following step (g). Otherwise, It
performs the previous step (e) again.
Step (g) : IPv6 Node sends DNS Server a dynamic update request
message for registering regular domain name information.
Step (h) : DNS Server sends IPv6 Node a dynamic update response
message indicating the successful registration of regular domain name
information.
Step (i) : IPv6 Node sends DNS Server a dynamic update request
message for registering inverse domain name information.
Step (j) : DNS Server sends IPv6 Node a dynamic update response
message indicating the successful registration of inverse domain name
information.
Jeong, Kim, Park, Kim Expires - October 2003 [Page 6]
Internet-Draft IPv6 RA-based DNS Autoconfiguration April 2003
Some parts of the above steps MIGHT be tied together. Step (g) and
step (i) can be merged in a single step. Also, step (h) and step (j)
can be performed together.
5.1 Generation of Domain Name
The generation of domain name depends on the local policy. This
document suggests an example of the naming schemes for the domain
name generation.
The following procedure is based on user preferred identifiers, such
as foo, foo1, foo2, etc. These user identifiers are stored in the
configuration file for domain name autoconfiguration.
Step (a) : Node selects one unused user identifier in order from the
list of user identifiers.
Step (b) : Node combines the user identifier with the advertised DNS
zone suffix. When multiple DNS zone suffixes and DNS servers are
known, node selects one unused DNS zone suffix in the descending
order of "Pref" field from the list of DNS zone suffixes. When
verifying and registering the domain name, node uses the DNS server
corresponding to the DNS zone suffix.
As another example of generating a unique domain name, a domain name
can be made with user identifier and a part of uniqueness-verified IP
address [13].
5.2 Verification of the Uniqueness of Domain Name
Node verifies the uniqueness of a generated domain name through DND
with the advertised DNS server. If there is a name conflict, the
node generates a new domain name with unused user identifier and DNS
zone suffix and then verifies the uniqueness of the name again.
Otherwise, it registers the domain name information.
5.3 Registration of Domain Name
For the unique domain name, the node registers both the regular
domain name and inverse domain name information of the node with DNS
server sequentially as described in Figure 2.
6. Autoconfiguration of Recursive DNS Server
The addresses of DNS servers are announced by DNS options in RA
message. These addresses can be used for recursive DNS service
providing DNS name resolution. For the autoconfiguration of the
domain name and recursive DNS server, the DNS zone suffix and RDNSS's
Jeong, Kim, Park, Kim Expires - October 2003 [Page 7]
Internet-Draft IPv6 RA-based DNS Autoconfiguration April 2003
address are stored in the configuration file for DNS resolver; i.e.,
/etc/resolv.conf in UNIX.
6.1 RDNSS Selection by IPv6 Node
When an IPv6 node perceives multiple RDNSSes through RA message, it
stores the RDNSS addresses in order into the configuration which the
resolver on the node uses for DNS name resolution on the basis of the
value of "Pref" field and the prefix of "IPv6 Address of DNS Server"
field in the DNS option. The following algorithm is simply based on
the rule of selecting the nearest possible RDNSS from the node by hop
count between the node and RDNSS, provided that its preference value
did not reach the maximum value of 15. When the distances are the
same, this algorithm uses the preference value to arrange the RDNSSes.
The IPv6 node operation is shown below:
Step (a) : Receive and parse all DNS options
Step (b) : Arrange the addresses of RDNSSes in an ascending order,
starting with the nearest RDNSS and store them in the configuration
for DNS name resolution used by resolver. (i.e., the longest prefix
matching between the "IPv6 Address of DNS Server" field and the
node's IPv6 address MAY be used to decide the distance between the
node and RDNSS, how far away the node is from the RDNSS.)
Step (c) : For each RDNSS entry, check the following; If the value of
"Pref" field is set to zero, exclude the RDNSS entry from the list of
RDNSSes of the configuration for DNS name resolution.
Whenever the resolver on the node performs the name resolution, it
refers to the address of RDNSS in order from the first RDNSS in the
configuration for name resolution.
6.2 Detection of RDNSS Failure
Router advertising DNS option message checks periodically if the
RDNSSes registered with the router are alive. The dynamic detection
of RDNSS failure in a router can be done by simply pinging the RDNSS
periodically (e.g., every ten seconds). If no response is received,
the router MAY try to aggressively ping the RDNSS for a short period
of time (e.g., once every 5 seconds for 15 seconds). Whenever the
router detects a failure of any RDNSS, it advertises the failure with
a new RA message including a DNS option of which "Pref" field has
zero for the RDNSS. When an IPv6 node receives the RA message, it
perceives that the RDNSS is out of work or the path to the RDNSS is
broken and excludes the RDNSS from the configuration for name
resolution. Also, If the node has its domain name associated with
the DNS zone suffix managed by the failed RDNSS, it MAY generate a
Jeong, Kim, Park, Kim Expires - October 2003 [Page 8]
Internet-Draft IPv6 RA-based DNS Autoconfiguration April 2003
new domain name with DNS zone suffix managed by another live RDNSS
and register the domain name information with the RDNSS.
7. Security Considerations
Ordinary DNS servers accept DNS dynamic update messages only from
trusted nodes. In the current DNS, which lacks public-key
infrastructure (PKI), the user of a host cannot be identified. In
order to support the autoconfiguration of an unidentifiable host's
domain name, DNS dynamic update SHOULD allow the registration of not
only the DNS resource record of "AAAA" type, but also that of "PTR"
type for any host [14]. The former is for the regular domain name
information and the latter for inverse domain name information.
Basically, since there is no mechanism to prevent denial-of-service
(DoS) attack in DNS, the number of issued dynamic update messages
from IPv6 nodes cannot be controlled by DNS server [14][15]. In
order to minimize the effects of malicious or misconfigured
registration requests, it is necessary for DNS server to control them.
In Mobile IPv6, a correspondent node may silently discard some or all
binding update messages when it is flooded with the messages [16].
Like this, DNS server MAY discard some or all DNS messages when being
filled with the messages.
8. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] P. Vixie, S. Thomson, Y. Rekhter and J. Bound, "Dynamic Updates
in the Domain Name System (DNS UPDATE) ", RFC2136, April 1997.
[4] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for
IP version 6", RFC 2461.
[5] S. Thomson and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462.
[6] A. Durand, J. itojun and D. Thaler, "Well known site local
unicast addresses to communicate with recursive DNS servers",
draft-ietf-ipv6-dns-discovery-07.txt, October 25 2002.
[7] Luc Beloeil, "IPv6 Router Advertisement DNS resolver Option",
draft-beloeil-ipv6-dns-resolver-option-01.txt, January 2003.
Jeong, Kim, Park, Kim Expires - October 2003 [Page 9]
Internet-Draft IPv6 RA-based DNS Autoconfiguration April 2003
[8] Jae-Hoon Jeong, Jung-Soo Park, Kyeong-Jin Lee and Hyoung-Jun Kim,
"The Autoconfiguration of Recursive DNS Server and the
Optimization of DNS Name Resolution in Hierarchical Mobile IPv6",
draft-jeong-hmipv6-dns-optimization-00.txt, February 2003.
[9] Levon Esibov and Dave Thaler, "Linklocal Multicast Name
Resolution (LLMNR)", draft-ietf-dnsext-mdns-13, November 2002.
[10] Akira Kato and Paul Vixie, "Operational Guidelines for "local"
zones in the DNS", draft-kato-dnsop-local-zones-00.txt, February
2003.
[11] H. Kitamura, "Domain Name Auto-Registration for Plugged-in IPv6
Nodes", draft-ietf-dnsext-ipv6-name-auto-reg-00.txt, December
2002.
[12] Soohong Daniel Park, "IPv6 Domain Name Auto-Registration
(6DNAR)", draft-park-6dnar-01.txt, March 2003.
[13] Jae-Hoon Jeong, Jung-Soo Park and Hyoung-Jun Kim, "Unique DNS
Name Generation", draft-jeong-name-generation-01, February 2003.
[14] B. Wellington, "Secure Domain Name System (DNS) Dynamic Update",
RFC 3007, November 2000.
[15] B. Wellington, "Domain Name System Security (DNSSEC) Signing
Authority," RFC3008, November 2000.
[16] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-21.txt, February 26, 2003.
9. Authors' 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
Byung-Yeob Kim
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350
Korea
Jeong, Kim, Park, Kim Expires - October 2003 [Page 10]
Internet-Draft IPv6 RA-based DNS Autoconfiguration April 2003
Phone: +82 42 860 6627
EMail: skylane@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
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, Kim, Park, Kim Expires - October 2003 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 06:13:41 |