Network Working Group B. Aboba Internet-Draft Microsoft Expires: May 2, 2002 R. Droms Cisco Systems T. Narten IBM Corporation Nov 2001 Using DHCPv6 for DNS Configuration in Hosts draft-droms-dnsconfig-dhcpv6-00.txt Status of this Memo 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. This Internet-Draft will expire on May 2, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract An IPv6 device can configure its addresses and locate neighboring routers through stateless address autoconfiguration (RFC2462) and router discovery (RFC2461). However, there is no current way (other than through DHCPv6) to learn DNS configuration information, such as the address of DNS servers or what the domain search path should be. It has been asserted that DHCP is "too complex" for providing DNS configuration in some (simple) environments, and an alternate mechanism is needed. This document argues that there is no need for Aboba, et al. Expires May 2, 2002 [Page 1] Internet-Draft Using DHCPv6 for DNS Configuration Nov 2001 an alternate protocol. First, arguments against using DHC for this purpose are not compelling. Second, development of a specialized protocol that addresses just the "DNS Discovery" problem will lead to more, not less complexity, in terms of implementations and operations. A new protocol will not replace the need for the DHCPv6 and will likely result in deployment of both, even in the same environment. Finally, we show how the current version of DHCPv6 already supports the features needed to provide a simple DNS Discovery mechanism. 1. Introduction An IPv6 device configures its IPv6 addresses through stateless address autoconfiguration [3] and/or through DHCP [5]. In addition, Neighbor Discovery [2] provides an IPv6 device with a set of neighboring routers it can use. With addresses and a list of neighboring routers, a node has IP-level connectivity to the Internet. In many cases, packet-level connectivity is not enough. Devices typically also need to be configured to be able to use the DNS [1]. Needed DNS configuration information can include knowing the address of one or more DNS servers, the DNS name of the device itself, a list of DNS domain names to append to queries to make them fully qualified, etc. Specifically, Section 2 of the DNS Discovery team report [4], defines the information for DNS name resolution to be: o One or more addresses of DNS servers. If a list is obtained, a client need only rediscover DNS servers if all addresses in the list are unreachable. However, if a list is obtained from a single point, such as one of the DNS servers, then a requirement exists that the list of servers be up-to-date and easily maintainable. o Domain name o Search path. It is currently common practice, for the search path to be computed by a device based on its domain name obtained. However, a DHCPv6 option [5] is being proposed in the DHC WG, and so search path configuration is likely to be a requirement in general. Currently, the only defined configuration mechanism to obtain information about the DNS is DHCP. However, there is a view in some parts of the community that DHCP is somehow unfit or inappropriate to supply such configuration information in some (simpler) environments. For example, it is argued that a home user cannot be expected to setup and maintain a DHCP server for this purpose. Section 2 of the Aboba, et al. Expires May 2, 2002 [Page 2] Internet-Draft Using DHCPv6 for DNS Configuration Nov 2001 DNS DNS Discovery team report [4] goes so far as to state: It is a further requirement that the above information be obtained without using a DHCP server. However, there is little specific discussion about why DHCP is inappropriate, what the requirements are for a solution, and why a DHCP-based solution fails to meet those requirements. This document describes how to use DHCPv6 messages to obtain DNS configuration information without necessarily requiring a "stateful" DHCPv6 server to perform address assignment. Moreover, we argue that the oft-made assertion that DHCP is "too complex" is simply not true. For simple configurations (e.g., a home network), DHCP servers can (and will) be widely implemented in routers, will be self-configuring and can solve the DNS discovery problem without the need for a yet another specialized protocol. Indeed, developing a new protocol, one that is narrowly focused on solving one small part of the host configuration space, will likely result in increased complexity, because it will be another way of providing the same information and will not replace the need to implement and deploy DHCP in most environments anyway. There is a common misconception that DHCPv6 is unnecessarily complex as a solution to meet the requirements for DNS Discovery. For example, some claim that because DHCPv6 is a "stateful" service it is inherently complicated to implement, deploy and manage; something "simpler" is needed, to go along with stateless address autoconfiguration. In practice, however, there are three kinds of configuration information that a client can obtain via DHCP, and the label "stateful" applies to only the first of them: o Per-client information that is dynamically generated initially, but is retained on a per-client basis from that point on. Such information cannot be regenerated again at a future time to produce the same information unless per-client history concerning previous requests is also maintained. The only current example of such information maintained by DHCP is IP addresses. When a client requests addresses, one or more is selected from a pool of available addresses, but from that point on those addresses are associated with a specific client (until the lease expires). o Per-client information that is generated according to a more general policy, but can be regenerated again in an idempotent manner when future requests are received. There is no need to retain per-client state information for such parameters. When the same client requests the information at a later time, the response parameters are derived again from the general policy. Examples Aboba, et al. Expires May 2, 2002 [Page 3] Internet-Draft Using DHCPv6 for DNS Configuration Nov 2001 here include the "User Class" option, which allows clients belonging to a particular organization or group to learn information relevant only to that particular group (e.g., local printers). Another example is the "Vendor Class" option, which identifies the type of hardware/software a client is running, so that the server can return information of use only to a particular platform. o General information that is given to each client, and does not vary from client to client. Examples here might include information about proxy HTTP servers, local time servers, DNS configuration, etc. Because there are different categories of information that DHCP can provide, calling DHCP "stateful" and then labeling such a capability as inappropriate for a service like "DNS discovery" is misleading. In particular, "DNS discovery" falls into one of the latter two of the above categories, and most likely falls into the last class. Building a DHCP server that provides the third kind of configuration information is substantially less complex than building a server of the first category. There are three components to a system that provides configuration information to clients: o The configuration information itself must be collected and synthesized. In the case of DNS, some of this information may be readily available from the DNS servers themselves o The configuration information must be encoded into some sort of protocol object or on-the-wire format that both the client and server understand. o The configuration info must then be communicated to the client via some on-the-wire protocol. From a complexity perspective, the actual encoding for the protocol object is somewhat arbitrary, so long as the format isn't some horribly poor choice. I.e., whether encoded in a DNS RR or a DHCP option doesn't substantially change the implementation complexity of the client or server. From a complexity perspective, the choice of the actual protocol to use is more important, but probably matters little, so long as it is not horribly complex or inefficient. We argue that the following factors are also important and necessary to consider: o Two protocols are inherently more complex to implement, manage and Aboba, et al. Expires May 2, 2002 [Page 4] Internet-Draft Using DHCPv6 for DNS Configuration Nov 2001 operate than one. Reusing existing technology is generally preferable to inventing something new. If something new is needed, the engineering trade off must first be made weighing the cost (both implementation and operational) of something new versus the benefits of just reusing something that already exists, or will likely become widely deployed anyway. o In practice, when multiple standard protocols for performing a specific function exist, and there is little difference in the functionality or complexity between the two, market forces tend to force all implementations (especially on the server side) to implement both. This leads to little savings in terms of implementations. Is a "simple" protocol really simpler if the "more complex" protocol needs to be implemented anyway? o In practice, some implementations may implement one while others will chose to implement the other (this is more typical on the client side). This may lead to some savings in terms of a particular client implementation, but can easily lead to interoperability issues and an increase in operational complexity in heterogeneous deployments where both protocols have to operate simultaneously. o If the client implements both methods, there needs to be clear guidance on when to use one method over the other, since there is now the possibility that different methods will result in conflicting configuration information being learned. This raises additional complexity issues that don't exist if only one mechanism exists. o When there are multiple ways of doing the same thing, and both will need to operate side-by-side (e.g., if some clients implement one method, others another, sites will be forced to operate both) unexpected interactions can take place. The interactions between the two protocols needs to be understood and documented. In practice, having just one protocol tends to simplify or eliminate such interactions. o Any new protocol will need to be securable. In the case of DNS Discovery, for instance, a client may need to be able to authenticate configuration information prior to using it. Reusing an existing protocol that already has an appropriate security framework has obvious advantages over a new protocol that has a different (or will need a new) security framework. o Because it is anticipated that many DHCP server will provide both DHCPv4 and DHCPv6 service, sites that already have DHCPv4 in place will be able to deploy a DHCPv6 service by upgrading the existing Aboba, et al. Expires May 2, 2002 [Page 5] Internet-Draft Using DHCPv6 for DNS Configuration Nov 2001 DHCP server and using the existing management infrastructure rather than deploying a new service in parallel with the existing DHCP service. The authors expect that if a new protocol is developed, the likely situation is that all servers will need to implement both methods. In the case of clients, they are likely to implement DHCP exclusively, or implement both. Because DNS Discovery does not provide other types of configuration information, it is unlikely that clients would implement only DNS Discovery. As an example, consider a proposal to put DNS discovery information into the DNS, and then develop special protocols for locating appropriate DNS servers (e.g., using anycast) [6]. This kind of service corresponds to the third category of DHCP service, i.e., everyone learns the same configuration information. One argument for this model is that the DNS server already has the DNS Configuration information. While true, this does not imply that the protocol or encoding format also needs to be DNS based. In particular, in environments where DHCP may also be being used, the DNS servers will need to know when they should respond to DNS Discovery requests as opposed to letting DHCP service such requests. Thus, the DNS server will need to implement sufficient functionality that it can interact with the DHCP entities on its networks. Consequently, a DNS-centric DNS Discovery protocol does not imply that such servers will not need to implement some part of DHCP. If they must implement some aspect of DHCP anyway, it may be just as easier (or easier) to just implement the functionality of a mini-DHCP server. From the client perspective, it would be advantageous if there was exactly one way to learn configuration information, and that the network took care of providing that information in a transparent manner. For example, DNS servers could dynamically determine whether a DHCP server is active, and if so, defer to it to provide DNS configuration service. If no DHCP server were active, it could make itself a "mini-DHCP" server that provides only information about DNS configuration. Keeping the client implementation simple and well- defined has the advantage that optimizations on how to provide configuration information to clients can evolve with strictly server- side changes, rather than requiring changes in client implementations. 2. Terminology DHCP - Dynamic Host Configuration Protocol; unless otherwise qualified, "DHCP" refers to DHCP for IPv6 Aboba, et al. Expires May 2, 2002 [Page 6] Internet-Draft Using DHCPv6 for DNS Configuration Nov 2001 DHCP option - A component of a DHCP message that carries configuration information for a DHCP client Configuration information - Information used by the host to configure its IP stack, DNS name resolver, etc. DNS configuration information - Configuration information used specifically to configure a DNS name resolver, including the addresses of DNS servers, the host's domain name and a search list for name resolution 3. DNS Configuration through DHCP When a host boots, it starts by generating a link-local address and then soliciting a Router Advertisement. Use of DHCPv6 by IPv6 hosts is controlled through two flags in Router Advertisements: M - if TRUE, the host invokes stateful autoconfiguration (DHCP) to configure additional addresses. (It may have already configured some address through stateless address autoconfiguration.) O - if TRUE, the host obtains other configuration (e.g, non-address) information through DHCP If the 'M' bit is set TRUE, the host obtains its address through stateful address assignment using DHCP. The host will also obtain other configuration through the same message exchange with the DHCP service. Thus, if the 'M' bit is TRUE, the host will always obtain all of its configuration through DHCP. If the 'M' bit is set FALSE, the host uses stateless address autoconfiguration exclusively for address assignment. If the 'O' bit is set TRUE, however, the host will obtain DNS configuration through DHCP. In this case a host will perform the following steps: 1. Multicast a DHCPv6 Inform message to a well-known multicast address requesting DNS configuration information, including: * IPv6 addresses of DNS server(s) * Domain name * Domain search list (domain names to search during name resolution) 2. Wait for the corresponding DHCPv6 Reply message. Aboba, et al. Expires May 2, 2002 [Page 7] Internet-Draft Using DHCPv6 for DNS Configuration Nov 2001 3. Extract the DNS configuration information from the Reply message and use it to configure local host behavior with regards to DNS resolution. If the host is using DHCP for DNS configuration, the DHCP specification allows the host to send DHCP Inform messages at times other than just once at boot time. For example, A host may poll the DHCP service periodically to obtain a more up-to-date list of DNS servers. Alternatively, if no servers in the host's current list of DNS servers is responding, the host may choose to send a DHCP Inform message to refresh its list of servers to find one that is available. The point here is that DHCP already provides mechanisms to obtain DNS configuration, the mechanism involves a single request/response message, and can be invoked as needed to refresh a client's configuration information. 4. DHCPv6 service for DNS configuration To meet the configuration requirements of hosts using DHCPv6 for DNS configuration, the DHCPv6 service must return a Reply message in response to an Inform request received from the client. The Reply message will contain just the options supplying DNS configuration information. The capability to carry DNS configuration information already exists in the DHCPv6 specification. A host uses the Inform message to request configuration information without stateful address assignment. In the Inform message, the client can explicitly request DNS configuration information. The DHCPv6 specification already includes three options for carrying DNS configuration: Domain Name Server option - provides a list of Domain Name System that a client name resolver can use to access DNS services Domain Name option - informs the DHCP client of its domain name Domain Search option - provides a list of domain names a client can use to resolve DNS names The DHCPv6 specification allows for the coexistence of clients using DHCP for stateful address assignment and clients using DHCP for obtaining configuration information. DHCP clients use different messages for configuration and for stateful address assignment, and a server that receives stateful configuration request does not respond if it is not configured for stateful configuration. Thus, even if DHCP messages are multicast to all DHCP servers, only those servers performing stateful address assignment will respond to requests for address assignment through DHCP. Aboba, et al. Expires May 2, 2002 [Page 8] Internet-Draft Using DHCPv6 for DNS Configuration Nov 2001 The following sections describe four scenarios in which the requirements for DHCP service in DNS configuration can be met through different configurations of DHCP servers. 4.1 Zero configuration stateless DHCP servers One obvious way to provide DHCP service is to place a DHCP server an every routers. Except in the case of a network composed of a single link, every link has at least one router that is already providing router advertisement service in addition to forwarding packets. Adding DHCP service for DNS configuration to a router does not add unreasonable complexity in terms of implementation or performance, especially for a reduced functionality server that only supplies DNS configuration information. Responding to an Inform message requires only the formation and transmission of a Reply message. The contents of every Reply message is the same and contains just the DNS configuration information. Note that the market in IPv4 has already demonstrated the feasibility of this approach. It is common now for off-the-shelf home routers to provide NAT & DHCP services in low-end boxes, all without requiring configuration by end users. There is no reason to believe that this would be different in IPv6 with DHCPv6, especially considering that the IPv4 implementations are fully functional DHCP servers doing stateful address assignment. One question is how would the router determine what DNS configuration information it should advertise through DHCP. The answer is it can determine this in a number of manners. In the strictly zeroconf manner, this information might come from an upstream ISP. But that ISP can provide the information to the router through DHCP, or whatever mechanism it uses to provide configuration information to the router. (After all, the router needs, for example, a public IP address on the ISP side.) Thus, there is no special problem here that wouldn't also exist in any protocol the provides DNS configuration, and there are a number of ways this could be done without requiring end-user configuration. 4.2 Stateless DHCP servers co-located with DNS servers Another deployment scenario is to co-locate DHCP service with a DNS server. The DHCP service returns information about its associated DNS server, and only responds to messages from hosts if the DNS server is available. In this scenario, a host uses the DHCP Inform message to poll for available DNS server, and builds a list of DNS servers by merging the DNS server addresses in the responses. As described in Section 3, a client can use the Inform message to manage Aboba, et al. Expires May 2, 2002 [Page 9] Internet-Draft Using DHCPv6 for DNS Configuration Nov 2001 its list of available DNS servers dynamically. The DHCP service in this scenario can be implemented either as a part of the process providing DNS service or as a separate process that monitors the operation of the DNS service. Co-locating DHCP service with DNS servers requires that DHCP Inform messages be forwarded across multiple links from the host to the server. The DHCPv6 specification defines a DHCP Relay Agent that receives DHCP messages sent to a link-local multicast address and forwards those messages to DHCP servers. Relay Agents usually reside in routers and are therefore readily available on every link. DHCP Relay Agents must be deployed and managed so that they are configured with the addresses of DHCP servers. To avoid the overhead of managing DHCP Relay Agents on every link, a host that has used stateless autoconfiguration to determine addresses with site or global scope can use the site local "All DHCP Servers" multicast address to send a DHCP Inform message to DHCP servers without using a local DHCP Relay Agent. 4.3 Coexistence of stateless DHCP servers and DHCP address assignment A site may have a mix of hosts using DHCP in three different ways: address assignment; DNS configuration; configuration information including DNS configuration and other parameters. The DHCP service Infrastructure may be mixed, with DNS-only servers in some routers or DNS servers as well as DHCP servers providing address assignment and other parameters. Further, because of DHCP relay agent configuration or use of multicast, a message from any client may be delivered to any server. From the point of view of the host, these servers co- exist as follows: Address assignment - Hosts requesting address assignment use DHCP Solicit, Request, Renew, and Rebind messages. The DHCP specification requires that servers that do not assign addresses - in particular, DHCP servers doing just DNS configuration - ignore these messages. Routers that have both a relay agent and a DHCP DNS configuration server forward address assignment messages to full DHCP servers. These servers then respond, so clients asking for address assignment receive responses only from configuring servers. Full configuration - Hosts asking for configuration information specify a list of the information of interest. Any server with corresponding information may respond. Servers providing only DNS configuration won't have all of the requested information and may choose not to respond. If a server providing only DNS Aboba, et al. Expires May 2, 2002 [Page 10] Internet-Draft Using DHCPv6 for DNS Configuration Nov 2001 configuration does respond, the host has the option to ignore the reply and choose another response from a DHCP server that supplies more complete information. DNS-only configuration - A host requesting only DNS configuration will identify those DNS configuration options in the Inform message it sends. Any server configured to respond to this host will do so. If the server sends back additional information, clients may choose to ignore the extra information. 5. Conclusion and Recommendations DHCP can be used for DNS configuration of hosts. The stateless version of DHCP, in which a host can obtain DNS configuration from a server with a two message exchange, imposes minimal implementation overhead. The configuration of a DHCP server providing DNS configuration information can be automated to minimize deployment and management overhead. Using an existing protocol has several advantages over designing and deploying a special-purpose protocol for DNS configuration of hosts. Using DHCP will minimize deployment complexity, allowing a site to reuse a single protocol infrastructure for host configuration that will likely be deployed at most sites. Sites with both protocols deployed will have to carefully coordinate the administration of the two protocols to avoid giving conflicting information to hosts. If a second protocol is available, sites will have to decide which to deploy and how to upgrade to DHCP if necessary. Specifying a new protocol for DNS configuration will require analysis of interactions between the new protocol and DHCP, as well as careful specification of client behavior in the case both sources of DNS configuration information are available. Almost all of the functions required for using DHCP for DNS configuration are already specified in the latest version of the DHCP document [5]. The only missing piece is the use of the All DHCP Servers (which is already defined in DHCPv6) for Inform messages, which can be added in a couple of sentences in the next revision of the DHCPv6 specification. Because DHCP can meet the requirements for DNS configuration of hosts,, and because the deployment and management of DHCP for this purpose can be accomplished with minimum overhead, we recommend that DHCP be adopted as standard mechanism for DNS configuration. This recommendation should be documented, along with recommended implementations and deployment strategies, in an Applicability Statement or BCP document. Aboba, et al. Expires May 2, 2002 [Page 11] Internet-Draft Using DHCPv6 for DNS Configuration Nov 2001 References [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [3] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [4] Aboba, B., Bound, J., Deering, S., Guttman, E., HAGINO, J., Hinden, R., JINMEI, T., Onoe, A., Soliman, H. and D. Thaler, "Analysis of DNS Server Discovery Mechanisms for IPv6", draft- ietf-ipngwg-dns-discovery-analysis-00 (work in progress), July 2001. [5] Bound, J., Carney, M., Perkins, C. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc- dhcpv6-20 (work in progress), October 2001. [6] Hagino, J. and D. Thaler, "IPv6 Stateless DNS Discovery", draft- ietf-ipngwg-dns-discovery-02 (work in progress), July 2001. Authors' Addresses Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA EMail: aboba@internaut.com Ralph Droms Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 USA Phone: +1 978 497 4733 EMail: rdroms@cisco.com Aboba, et al. Expires May 2, 2002 [Page 12] Internet-Draft Using DHCPv6 for DNS Configuration Nov 2001 Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA Phone: +1 919 254 7798 EMail: narten@us.ibm.com Aboba, et al. Expires May 2, 2002 [Page 13] Internet-Draft Using DHCPv6 for DNS Configuration Nov 2001 Full Copyright Statement Copyright (C) The Internet Society (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 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 assigns. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Aboba, et al. Expires May 2, 2002 [Page 14]