Individual Submission Internet Draft Jaehoon Paul Jeong ETRI Soohong Daniel Park SAMSUNG Electronics Luc Beloeil France Telecom R&D Syam Madanapalli SAMSUNG ISO draft-jeong-dnsop-ipv6-dns-discovery-00.txt Expires: January 2004 21 July 2003 IPv6 DNS Discovery based on Router Advertisement 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 DNS information, such as the address of recursive DNS server and DNS zone suffix. 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]. Jeong, et al. Expires - January 2004 [Page 1] Internet-Draft IPv6 DNS Discovery based on RA July 2003 Table of Contents 1. Terminology...................................................2 2. Introduction..................................................2 3. Overview......................................................3 4. Neighbor Discovery Extension..................................3 4.1 DNS Server Option........................................3 4.2 DNS Zone Suffix Option...................................4 5. Procedure of DNS Discovery....................................5 6. Autoconfiguration of DNS Information..........................6 6.1 RDNSS Configuration and Selection........................6 6.2 DNS Zone Suffix Configuration............................7 7. Applicability Statements......................................7 8. Open Issues...................................................8 9. Security Considerations.......................................8 10. Copyright....................................................8 11. Normative References.........................................9 12. Informative References.......................................9 13. Authors' Addresses..........................................10 1. Terminology This memo uses the terminology described in [3][4]. In addition, a new term is defined below: 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 provides a way to autoconfigure either fixed or mobile nodes with one or more IPv6 addresses, default routes and some other parameters [3][4]. For the support of the various services in the Internet, such as web service, not only the configuration of IP address for network interface, but also that of at least one recursive DNS server for DNS name resolution is necessary. This document defines the process of DNS discovery based on IPv6 Router Advertisement (RA) to find out DNS information, such as the address of recursive DNS server and DNS zone suffix within the local network. Jeong, et al. Expires - January 2004 [Page 2] Internet-Draft IPv6 DNS Discovery based on RA July 2003 3. Overview An IPv6 host can autoconfigure DNS information via RA message sent periodically by router [5]-[7]. Namely, an IPv6 host can autoconfigure the IPv6 address of RDNSS for DNS name resolution through DNS Server option included in RA message. Also, through DNS Zone Suffix option in RA message, the IPv6 host can acquire the DNS zone suffix within the local network. 4. Neighbor Discovery Extension The DNS discovery mechanism in this document needs two new RA options in Neighbor Discovery; (1) DNS Server option and (2) DNS Zone Suffix option that will introduce 4.1 and 4.2 sections. 4.1 DNS Server Option DNS Server option contains the IPv6 address of the recursive DNS server. When advertising more than one DNS Server option, as many DNS Server options as DNS servers are included in an RA message. Figure 1 shows the format of DNS Server option. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address of DNS Server + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. DNS Server Option Format Fields: Type 8-bit identifier of the option type (TBD: IANA) Option Name Type DNS Server (TBD) Jeong, et al. Expires - January 2004 [Page 3] Internet-Draft IPv6 DNS Discovery based on RA July 2003 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. The field can be used for load balancing of DNS queries with multiple RDNSSes according to local policy. Valid Lifetime 32-bit unsigned integer. The maximum time, in seconds, over which this DNS server is used for name resolution. Hosts should contact the source of this information, router, before expiry of this time interval. A value of all one bits (0xffffffff) represents infinity. IPv6 Address of DNS Server Recursive DNS Server's address for DNS name resolution. "Pref"=0 SHOULD require a "Valid Lifetime"=0 because the corresponding DNS server SHOULD not be used any more. 4.2 DNS Zone Suffix Option DNS Zone Suffix option contains the suffix of the DNS zone where the subnet is placed. When advertising more than one DNS Zone Suffix option, as many DNS Zone Suffix options as DNS zones are included in an RA message. Figure 2 shows the format of DNS Zone Suffix option. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ DNS Zone Suffix ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. DNS Zone Suffix Option Format Jeong, et al. Expires - January 2004 [Page 4] Internet-Draft IPv6 DNS Discovery based on RA July 2003 Fields: Type 8-bit identifier of the option type (TBD: IANA) Option Name Type DNS Zone Suffix (TBD) Length 8-bit unsigned integer. The length of the option in units of 8 octets. Pref The preference of a DNS zone suffix. A 4 bit unsigned integer. A decimal value of 15 indicates the highest preference. A decimal value of 0 indicates that the DNS zone suffix can not be used. The field can be used for arranging DNS zone suffix according to local policy. Valid Lifetime 32-bit unsigned integer. The maximum time, in seconds, over which this DNS zone suffix is valid. Hosts should contact the source of this information, router, before expiry of this time interval. A value of all one bits (0xffffffff) represents infinity. 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. 5. Procedure of DNS Discovery IPv6 Host Router | global | (a)|(-------------RS-------------->)| (b)|<------RA w/ DNS options--------| (c)| Processing of RA | (d)| Address Autoconfiguration | (e)|(Stateful DNS Autoconfiguration)| | | Figure 3. Procedure of DNS Discovery Jeong, et al. Expires - January 2004 [Page 5] Internet-Draft IPv6 DNS Discovery based on RA July 2003 Figure 3 shows the procedure of DNS Discovery on the basis of IPv6 RA message. The procedure consists of the following steps. Step (a) : IPv6 Host sends RS (Router Solicitation) message to get RA message. It is optional. Step (b) : For the RS message received from IPv6 Host, Router sends RA message, which contains prefix information option for the stateless address autoconfiguration and MAY contain DNS options for DNS information, namely the address of DNS server and DNS zone suffix. For DNS Zone Suffix option to be contained, DNS Server option SHOULD be contained ahead. Step (c) : If there are DNS options, IPv6 Host processes the options and stores them in its DNS configuration file or database. Step (d) : Through stateless or stateful address autoconfiguration, a unique global IPv6 address is autoconfigured in the network interface of the IPv6 Host. Step (e) : Unless DNS information is configured through RA message, the IPv6 Host MAY try to get DNS information through stateful mechanism, such as DHCPv6. In order to allow stateful protocol used for DNS discovery, O-bit (Other stateful configuration flag) within RA message SHOULD be set. When DNS information has been delivered through RA message, the DNS discovery by stateful protocol is skipped. 6. Autoconfiguration of DNS Information 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. The newly discovered DNS information, the RDNSS's address and DNS zone suffix, are stored in the configuration file for DNS resolver; i.e., /etc/resolv.conf in UNIX. 6.1 RDNSS Configuration and Selection When an IPv6 host perceives multiple RDNSSes through RA message, it stores the RDNSS addresses in order into the configuration file which the resolver on the host uses for DNS name resolution on the basis of the value of "Pref" field in the DNS Server option. The following algorithm is simply based on the rule of selecting an RDNSS in the order from the most preferred RDNSS, provided that its preference value is not zero. The processing of the DNS Server option received in RA message by an IPv6 host is as follows: Jeong, et al. Expires - January 2004 [Page 6] Internet-Draft IPv6 DNS Discovery based on RA July 2003 The IPv6 host's operation is like below for each DNS Server option: Step (a) : Receive and parse all DNS Server options. Step (b) : Arrange the addresses of RDNSSes in a descending order, starting with the biggest value of "Pref" field of the DNS Server option and store them in the configuration file used by resolver for DNS name Resolution (DNS configuration). Step (c) : For each DNS Server option, check the following: If the Value of "Pref" or "Valid Lifetime" field is set to zero, exclude the corresponding RDNSS entry from the list of RDNSSes of DNS configuration in order to let the RDNSS not used any more. Whenever the resolver on the host performs the name resolution, it refers to the address of RDNSS in order from the first RDNSS stored in DNS configuration. In case that there are several routers advertising DNS information in a subnet, "Pref" field is used to arrange the information. 6.2 DNS Zone Suffix Configuration DNS zone suffix is delivered as DNS Zone Suffix option via RA message from router. The processing of the DNS Zone Suffix option received in RA message by an IPv6 host is as follows: Step (a) : Receive and parse all DNS Zone Suffix options. Step (b) : Arrange the DNS zone suffix in a descending order, starting with the biggest value of "Pref" field of the DNS Zone Suffix option and store them in DNS configuration. Step (c) : For each DNS Zone Suffix option, check the following: If the value of "Pref" or "Valid Lifetime" field is set to zero, exclude the corresponding DNS zone suffix from the list of DNS zone suffixes of DNS configuration in order to let the DNS zone suffix not used any more. This DNS zone suffix MAY be used for forming IPv6 host's DNS name. 7. Applicability Statements RA-based DNS discovery is efficient in many kinds of wireless networks where IPv6 address is autoconfigured by IPv6 stateless address autoconfiguration, such as SOHO, home network, HMIPv6 [8], Jeong, et al. Expires - January 2004 [Page 7] Internet-Draft IPv6 DNS Discovery based on RA July 2003 NEMO and MANET connected to the Internet. Especially, in the environments where DHCPv6 is difficult to adapt, RA-based DNS discovery is recommended. 8. Open Issues There might be some issues regarding RA-based DNS discovery as follows: o How to optimize bandwidth on the link? o How to implement RA-based DNS discovery? o What about the use of "Pref" or "Valid Lifetime" field? o How to interact with stateful mechanism? o What about several routers on the same link that could advertise distinct parameters? (Multihoming considerations) 9. Security Considerations This security is essentially related to Neighbor Discovery protocol security [3]. If someone wants to hijack correct RS message, they could send an RA message with incorrect DNS Server options and DNS Zone Suffix options to the originated host and they would take incorrect RA message through the above mechanism, which is unsafe processing. As described in [3], an IPv6 host can check the validity of NDP messages. If the NDP message includes an IP Authentication Header, the message can be authenticated. Security issues regarding the Neighbor Discovery protocol are being discussed in IETF SEND (Securing Neighbor Discovery) working group [9]. 10. Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the applicable copyright for this document. Copyright (C) The Internet Society July 12, 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Jeong, et al. Expires - January 2004 [Page 8] Internet-Draft IPv6 DNS Discovery based on RA July 2003 Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 11. Normative 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] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for IP version 6", RFC 2461, December 1998. [4] S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC2462, December 1998. 12. Informative References [5] Jaehoon Paul Jeong, Byungyeob Kim, Jungsoo Park and Hyoungjun Kim, "IPv6 Router Advertisement based DNS Autoconfiguration", draft- jeong-ipv6-ra-dns-autoconf-00.txt, April 2003. [6] Luc Beloeil, "IPv6 Router Advertisement DNS resolver Option", draft-beloeil-ipv6-dns-resolver-option-01.txt, January 2003. [7] Soohong Daniel Park and Syam Madanapalli, "IPv6 Extensions for DNS Plug and Play", draft-park-ipv6-extensions-dns-pnp-00.txt, April 2003. [8] Jaehoon Paul Jeong, Jungsoo Park, Kyeongjin Lee and Hyoungjun Kim, "The Autoconfiguration of Recursive DNS Server and the Optimization of DNS Name Resolution in Hierarchical Mobile IPv6", draft-jeong-hmipv6-dns-optimization-01.txt, June 2003. Jeong, et al. Expires - January 2004 [Page 9] Internet-Draft IPv6 DNS Discovery based on RA July 2003 [9] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ipsec-01.txt, June 2003. 13. Authors' Addresses Jaehoon Paul Jeong ETRI / PEC 161 Gajong-Dong, Yusong-Gu Daejon 305-350 Korea Phone: +82-42-860-1664 EMail: paul@etri.re.kr Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics Korea Phone: +82-31-200-3728 EMail: soohong.park@samsung.com Luc Beloeil France Telecom R&D 42, rue des coutures BP 6243 14066 CAEN Cedex 4 France Phone: +33-02-3175-9391 EMail: luc.beloeil@francetelecom.com Syam Madanapalli Network Systems Division, SAMSUNG India Software Operations India Phone: +91-80-555-0555 EMail: syam@samsung.com Jeong, et al. Expires - January 2004 [Page 10]