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]