Internet Engineering Task Force Renxiang Yan Internet Draft Yinglan Jiang Expiration: April 2005 Luoning Gui File: draft-yan-dhc-dhcpv6-opt-dnszone-01.txt Alcatel Shanghai Bell DNS zone suffix option for DHCPv6 <Draft-yan-dhc-dhcpv6-opt-dnszone-01.txt> October 12, 2004 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The DNS Zone Suffix option provides a mechanism for automated assignment of DNS zone suffix using DHCPv6. This mechanism is Yan, et. al. [Page 1]
Internet-Draft DNS zone suffix option for DHCPv6 October 2004 intended to assign a DNS zone suffix from DHCPv6 server to a client. The client then uses this suffix to configure its domain name. 1.0 Introduction The introduction of 128-bit address of IPv6 makes it very difficult for the user to identify the device by means of its IP address. The use of DNS (Domain Name Service) becomes a necessity. With the help of DNS, a user only needs to remember the relatively simple domain name instead of long IPv6 address. Currently, there exist several methods to register domain name for an IPv6 terminal: (1) manually add the DNS resource record into DNS server database; (2) use FQDN option and register domain name automatically either by DHCP client or by DHCP server [6]; (3) configure a DNS zone suffix information in the router, and use the RA-based DNS auto-registration mechanism [5]. Method (1) is not effective for large number of IPv6 devices. Method (3) requires that the every terminal get the address and FQDN using DHCP mechanism. Thus every terminal needs a DHCP client. Method (2) will only be suitable in the case where a router is presented in the network, and the DNS zone suffix has been configured correctly. In IPv6 access network where CPE may work as an IPv6 router which links some IPv6 terminals to form a home network, it will be better to define an automatic mechanism to configure the DNS zone suffix. This document describes a new option for DHCP, named DNS zone suffix option. Using this option, a DHCPv6 client can get a DNS zone suffix from DHCPv6 server. It will provide an enhancement for method (2) to automatically update domain name for IPv6 terminals, especially in access network environment. 1.1 Conventions 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 [1]. 2.0 DNS Zone Suffix Option Definition The DNS zone suffix option is used to carry a DNS zone suffix to the DHCPv6 client, which will use it to construct and register a domain name. The format of the DNS zone suffix option is: Yan, et. al. [Page 2]
Internet-Draft DNS zone suffix option for DHCPv6 October 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DNS_Zone_suffix | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ DNS zone suffix ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_DNS_Zone_suffix (TBD) option-length: Length of the "DNS zone suffix" field in octets. DNS zone suffix: A string of DNS zone suffix. It 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. 2.1 Appearance of the option The DNS zone suffix option MUST NOT appear in any other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply. 3.0 Example and applicability +------+ | Node +--+ +------+ | | +------+ | | Node +--+ +--------------- +------+ | | : +-----+ : +---------+ | | +--+ Router +------| ISP | Internet : +---------+ | | : +-----+ +------+ | | | Node +--+ +--------------- +------+ \____________ ___________/ \____________ ___________/ \/ \/ Subscriber network ISP network Yan, et. al. [Page 3]
Internet-Draft DNS zone suffix option for DHCPv6 October 2004 The above figure shows a typical usage of the option. In this model, ISP has the ISP level domain name suffix (e.g. shtele.com). The procedure may follow as: 1. The router in the subscriber network initiate DHCP request with the DNS zone suffix option to get ISP's suffix (i.e. shetele.com). 2. The router passes this suffix to the IPv6 nodes in local subnet, through an embedded stateless DHCPv6 server or RA-based mechanism described in [5]. Since nodes on different subscriber networks may produce the same domain name, to avoid frequent uniqueness verification, the router is suggested to extend DNS zone suffix. For example, the DNS zone suffix of two subscriber networks under "shtele.com" maybe "john.shtele.com" and "smith.shtele.com". 3. An IPv6 node creates FQDN for its global address by adding a hostname to the DNS zone suffix, and registers the IP to FQDN mapping and FQDN to IP mapping in the domain name server. This procedure can be realized either by itself using DNS update or through DHCPv6 server [6]. For example, an IPv6 set-top-boxes will hold a domain name "stb.john.shtele.com" in the DNS server. The DNS zone suffix option can be used in conjunction with other DHCP options carrying other configuration information to the router. For example, the router may obtain the addresses of the DNS servers and IPv6 prefix from the ISP's DHCP server, and then passes that configuration information on to the subscriber nodes through a DHCP server in the router. The use of DNS zone suffix option are not limited in access. It can be commonly used in case that IPv6 node needs to configure its domain name in DNS server. 4.0 Security Considerations Security considerations in DHCP are described in section 23, "Security Considerations" of RFC 3315. A rogue DHCP server can issue bogus zone suffix to a client. This may cause wrong domain name registration. A malicious client may be able to mount a denial of service attack by repeated DHCP requests for zone suffix, thus exhausts the DHCP server's resource. Currently, it is difficult for DHCP servers to develop much confidence in the identities of its clients, given the absence of entity authentication from the DHCP protocol itself. To guard against Yan, et. al. [Page 4]
Internet-Draft DNS zone suffix option for DHCPv6 October 2004 attack, DHCP Authentication as described in section 21 of RFC 3315 can be used. To restrict unsecured DNS updates to zones which are exposed to the global Internet, IPv6 terminals SHOULD use some form of update request origin authentication procedure (e.g., Secure DNS Dynamic Update [7]) when performing DNS updates. In access network, an extra method to ensure the secure DNS updates is to add an IP spoofing filter in access node. Copyright notice Copyright (C) The Internet Society (2004). 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. 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. References [1] Deering, S. and R. Hiden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998. [2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, May 2003. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] P. Vixie, S. Thomson, Y. Rekhter and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC2136, April 1997. [5] Jae-Hoon, J., Byung-Yeob, K., Jung-Soo, P. and Hyong-Jun K., "IPv6 Router Advertisement based DNS Autocofiguration", draft- jeong-ipv6-ra-dns-autoconf-00.txt, 17 April, 2003. [6] M.Stapp, Y. Rekhter, "The DHCPv6 Client FQDN Option", draft- volz-dhc-dhcpv6-fqdn-00.txt, July, 2004. Yan, et. al. [Page 5]
Internet-Draft DNS zone suffix option for DHCPv6 October 2004 [7] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [8] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. Author Information: Renxiang Yan Yinglan Jiang Luoning Gui Research & Innovation Center Alcatel Shanghai Bell Co., Ltd. 388#, NingQiao Road, Pudong Jinqiao Shanghai 201206 P.R. China Phone: +86 (21) 5854-1240 Email: renxiang.yan@alcatel-sbell.com.cn Yinglan.jiang@alcatel-sbell.com.cn Luoning.gui@alcatel-sbell.com.cn Yan, et. al. [Page 6]