Network Working Group R. Droms Internet-Draft Cisco Systems Expires: August 30, 2002 T. Narten IBM Corporation B. Aboba Microsoft Mar 2002 Using DHCPv6 for DNS Configuration in Hosts draft-droms-dnsconfig-dhcpv6-01.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 August 30, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract An IPv6 device can configure its addresses and locate neighboring routers through stateless address autoconfiguration (RFC2462) and router discovery (RFC2461). Most IPv6 devices will require information about DNS services to make use of the basic IPv6 connectivity. The current version of DHCPv6 already supports the features needed to provide a simple DNS configuration mechanism. DNS configuration requires only a small subset of the DHCPv6 protocol and can be provided through relatively simple client and server Droms, et al. Expires August 30, 2002 [Page 1] Internet-Draft Using DHCPv6 for DNS Configuration Mar 2002 implementations. 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 DNS [1]. Needed DNS configuration information can include 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. This document describes how to use DHCPv6 messages to obtain DNS configuration information without necessarily requiring a "stateful" DHCPv6 server to perform address assignment. 2. Terminology DHCP - Dynamic Host Configuration Protocol; unless otherwise qualified, "DHCP" refers to DHCP for IPv6 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. Droms, et al. Expires August 30, 2002 [Page 2] Internet-Draft Using DHCPv6 for DNS Configuration Mar 2002 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. Summary of DHCP operation DHCPv6 is conceptually similar to DHCP for IPv4 [7]. DHCPv6 can provide configuration that includes address assignment, where the DHCP server selects an address for each DHCP client and maintains state about the assignment of that address to the client. DHCPv6 also provides configuration parameters to clients that do not need to have an address assigned. This mode of operation is expected to be much more widely used than in IPv4 networks, because hosts can use stateless autoconfiguration to select IPv6 addresses rather than depending on a DHCP server or manual configuration. A host that has selected IPv6 addresses through stateless autoconfiguration uses a single message exchange with a DHCP server to obtain configuration information. As in DHCPv4, the host sends a message to a well-known multicast address to contact a DHCP server. The server may return the same configuration information to every client, or it may be configured with policies to return customized information to groups of hosts or even individual hosts. Each message exchange is independent of other message exchanges so that the server need not retain any dynamic state about each host. The DHCP 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 a 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. Because a DHCP server may be designed to respond only to Information- Request messages, it is possible to implement a DHCP server that is much less complex than a server that provides stateful address assignment. A DHCP server that provides only DNS configuration information is easier to set up during deployment and requires fewer computational resources. As discussed in Section 5.1, a DHCP server for DNS configuration information can be designed to be almost completely self-configuring. Similarly, a DHCP client that uses only Information-Request messages to obtain other configuration Droms, et al. Expires August 30, 2002 [Page 3] Internet-Draft Using DHCPv6 for DNS Configuration Mar 2002 information would be much simpler than a client that uses DHCP for address assignment. 4. Client Behavior for DNS Configuration through DHCP When a host boots, it starts by generating a link-local address and then soliciting a Router Advertisement. Use of DHCP 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 in this case, the host will obtain its DNS configuration (and, perhaps, other configuration information) through DHCP. In this case a host will perform the following steps: 1. Send a DHCP Information-Request message to a well-known multicast address requesting DNS configuration information. 2. Wait for the corresponding DHCP Reply message. 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 Information-Request 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 Information-Request 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. Droms, et al. Expires August 30, 2002 [Page 4] Internet-Draft Using DHCPv6 for DNS Configuration Mar 2002 5. DHCP service for DNS configuration To meet the requirements of a host using DHCP for DNS configuration, the DHCP service must return a Reply message in response to an Information-Request message 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 DHCP specification. As described in the previous section, a host uses the Information-Request message to request configuration information without stateful address assignment. The DHCP specification includes three options for carrying DNS configuration [8]: 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 following sections describe several scenarios in which the requirements for DHCP service in DNS configuration can be met through different configurations of DHCP servers. 5.1 Minimal DHCP servers for DNS configuration One obvious way to provide DHCP service is to place a DHCP server on every router. 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 Information-Request 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 small routers to provide NAT & DHCP services, requiring little or no 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 Droms, et al. Expires August 30, 2002 [Page 5] Internet-Draft Using DHCPv6 for DNS Configuration Mar 2002 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 any of several different ways. 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. 5.2 DHCP service provided by DNS servers Another deployment scenario is to provide DHCP server in a DNS server. In this scenario, the DNS server is extended with the capability to receive Information-Request messages and respond with Reply messages. DHCP would be used as the format to carry the configuration information obtained directly from the DNS server. In this scenario, a host uses the DHCP Information-Request message to poll for available DNS servers, and builds a list of DNS servers by merging the DNS server addresses in the responses. As described in Section 4, a client can use the Information-Request message to manage its list of available DNS servers dynamically. Providing DHCP service with DNS servers requires that DHCP Information-Request 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. 5.3 DHCP servers co-located with DNS servers A similar deployment scenario is to co-locate DHCP service with a DNS server. The DHCP service returns information about its associated Droms, et al. Expires August 30, 2002 [Page 6] Internet-Draft Using DHCPv6 for DNS Configuration Mar 2002 DNS server, and only responds to messages from hosts if the DNS server is available. 5.4 DHCP servers providing both address assignment and configuration information A site that is providing address assignment to some DHCP clients can use the same DHCP server to provide configuration information to hosts that use statless address autoconfiguration. The DHCP specification allows a server to be configured with policies that allow it to provide address assignment to some clients while providing DNS configuration information to other clients. Thus, the site need not have two different sets of DHCP servers for the two types of DHCP service. 6. Coexistence of DHCP servers 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 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 Information- Droms, et al. Expires August 30, 2002 [Page 7] Internet-Draft Using DHCPv6 for DNS Configuration Mar 2002 Request 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. 7. Open Issues There are three open issues for the DHCPv6 specification raised by this document: Site-scoped multicast: The most recent DHCPv6 specification only allows a client to send an Information-Request message to the link-scoped "All_DHCP_Agents" multicsat address or to a server's unicast address. To allow for discovery of DHCP servers without the use of relay agents, a client could use the site-scoped "All_DHCP_Servers" multicast address. DNS and DHCP on one computer: A DNS server providing DNS configuration through DHCP and a DHCP server will experience a conflict in the use of the well-known DHCP port numbers. Authentication: DHCP includes a framework for authentication of DHCP messages. Use of authentication with DNS configuration will be important because of the potentical spoofing attack that can be mounted through the DNS search path. It may be possible to improve on DHCP authentication through the use of IPSEC. 8. 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 Droms, et al. Expires August 30, 2002 [Page 8] Internet-Draft Using DHCPv6 for DNS Configuration Mar 2002 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 open issues are discussed in Section 7 of this document. 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. 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 (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 (work in progress), February 2002. [6] Hagino, J. and D. Thaler, "IPv6 Stateless DNS Discovery", draft- ietf-ipngwg-dns-discovery (work in progress), July 2001. [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [8] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms, "The DNS Configuration options for DHCPv6", draft-ietf- dhc-dhcpv6-opt-dnsconfig (work in progress), Jan 2002. Droms, et al. Expires August 30, 2002 [Page 9] Internet-Draft Using DHCPv6 for DNS Configuration Mar 2002 Authors' Addresses Ralph Droms Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 USA Phone: +1 978 497 4733 EMail: rdroms@cisco.com 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 Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA EMail: aboba@internaut.com Droms, et al. Expires August 30, 2002 [Page 10] Internet-Draft Using DHCPv6 for DNS Configuration Mar 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Droms, et al. Expires August 30, 2002 [Page 11]