idnits 2.17.00 (12 Aug 2021) /tmp/idnits46746/draft-droms-dnsconfig-dhcpv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Mar 2002) is 7365 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 423, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '3') (Obsoleted by RFC 4862) -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: draft-ietf-dhc-dhcpv6 has been published as RFC 3315 -- No information found for draft-ietf-ipngwg-dns-discovery - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: draft-ietf-dhc-dhcpv6-opt-dnsconfig has been published as RFC 3646 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Droms 3 Internet-Draft Cisco Systems 4 Expires: August 30, 2002 T. Narten 5 IBM Corporation 6 B. Aboba 7 Microsoft 8 Mar 2002 10 Using DHCPv6 for DNS Configuration in Hosts 11 draft-droms-dnsconfig-dhcpv6-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 30, 2002. 36 Copyright Notice 38 Copyright (C) The Internet Society (2002). All Rights Reserved. 40 Abstract 42 An IPv6 device can configure its addresses and locate neighboring 43 routers through stateless address autoconfiguration (RFC2462) and 44 router discovery (RFC2461). Most IPv6 devices will require 45 information about DNS services to make use of the basic IPv6 46 connectivity. The current version of DHCPv6 already supports the 47 features needed to provide a simple DNS configuration mechanism. DNS 48 configuration requires only a small subset of the DHCPv6 protocol and 49 can be provided through relatively simple client and server 50 implementations. 52 1. Introduction 54 An IPv6 device configures its IPv6 addresses through stateless 55 address autoconfiguration [3] and/or through DHCP [5]. In addition, 56 Neighbor Discovery [2] provides an IPv6 device with a set of 57 neighboring routers it can use. With addresses and a list of 58 neighboring routers, a node has IP-level connectivity to the 59 Internet. 61 In many cases, packet-level connectivity is not enough. Devices 62 typically also need to be configured to be able to use DNS [1]. 63 Needed DNS configuration information can include the address of one 64 or more DNS servers, the DNS name of the device itself, a list of DNS 65 domain names to append to queries to make them fully qualified, etc. 66 Specifically, Section 2 of the DNS Discovery team report [4], defines 67 the information for DNS name resolution to be: 69 o One or more addresses of DNS servers. If a list is obtained, a 70 client need only rediscover DNS servers if all addresses in the 71 list are unreachable. However, if a list is obtained from a 72 single point, such as one of the DNS servers, then a requirement 73 exists that the list of servers be up-to-date and easily 74 maintainable. 76 o Domain name 78 o Search path. It is currently common practice, for the search path 79 to be computed by a device based on its domain name obtained. 80 However, a DHCPv6 option [5] is being proposed in the DHC WG, and 81 so search path configuration is likely to be a requirement in 82 general. 84 This document describes how to use DHCPv6 messages to obtain DNS 85 configuration information without necessarily requiring a "stateful" 86 DHCPv6 server to perform address assignment. 88 2. Terminology 90 DHCP - Dynamic Host Configuration Protocol; unless otherwise 91 qualified, "DHCP" refers to DHCP for IPv6 93 DHCP option - A component of a DHCP message that carries 94 configuration information for a DHCP client 96 Configuration information - Information used by the host to configure 97 its IP stack, DNS name resolver, etc. 99 DNS configuration information - Configuration information used 100 specifically to configure a DNS name resolver, including the 101 addresses of DNS servers, the host's domain name and a search list 102 for name resolution 104 3. Summary of DHCP operation 106 DHCPv6 is conceptually similar to DHCP for IPv4 [7]. DHCPv6 can 107 provide configuration that includes address assignment, where the 108 DHCP server selects an address for each DHCP client and maintains 109 state about the assignment of that address to the client. 111 DHCPv6 also provides configuration parameters to clients that do not 112 need to have an address assigned. This mode of operation is expected 113 to be much more widely used than in IPv4 networks, because hosts can 114 use stateless autoconfiguration to select IPv6 addresses rather than 115 depending on a DHCP server or manual configuration. 117 A host that has selected IPv6 addresses through stateless 118 autoconfiguration uses a single message exchange with a DHCP server 119 to obtain configuration information. As in DHCPv4, the host sends a 120 message to a well-known multicast address to contact a DHCP server. 121 The server may return the same configuration information to every 122 client, or it may be configured with policies to return customized 123 information to groups of hosts or even individual hosts. Each 124 message exchange is independent of other message exchanges so that 125 the server need not retain any dynamic state about each host. 127 The DHCP specification allows for the coexistence of clients using 128 DHCP for stateful address assignment and clients using DHCP for 129 obtaining configuration information. DHCP clients use different 130 messages for configuration and for stateful address assignment, and a 131 server that receives a stateful configuration request does not 132 respond if it is not configured for stateful configuration. Thus, 133 even if DHCP messages are multicast to all DHCP servers, only those 134 servers performing stateful address assignment will respond to 135 requests for address assignment through DHCP. 137 Because a DHCP server may be designed to respond only to Information- 138 Request messages, it is possible to implement a DHCP server that is 139 much less complex than a server that provides stateful address 140 assignment. A DHCP server that provides only DNS configuration 141 information is easier to set up during deployment and requires fewer 142 computational resources. As discussed in Section 5.1, a DHCP server 143 for DNS configuration information can be designed to be almost 144 completely self-configuring. Similarly, a DHCP client that uses only 145 Information-Request messages to obtain other configuration 146 information would be much simpler than a client that uses DHCP for 147 address assignment. 149 4. Client Behavior for DNS Configuration through DHCP 151 When a host boots, it starts by generating a link-local address and 152 then soliciting a Router Advertisement. Use of DHCP by IPv6 hosts is 153 controlled through two flags in Router Advertisements: 155 M - if TRUE, the host invokes stateful autoconfiguration (DHCP) to 156 configure additional addresses. (It may have already configured 157 some address through stateless address autoconfiguration.) 159 O - if TRUE, the host obtains other configuration (e.g, non-address) 160 information through DHCP 162 If the 'M' bit is set TRUE, the host obtains its address through 163 stateful address assignment using DHCP. The host will also obtain 164 other configuration through the same message exchange with the DHCP 165 service. Thus, if the 'M' bit is TRUE, the host will always obtain 166 all of its configuration through DHCP. 168 If the 'M' bit is set FALSE, the host uses stateless address 169 autoconfiguration exclusively for address assignment. If the 'O' bit 170 is set TRUE in this case, the host will obtain its DNS configuration 171 (and, perhaps, other configuration information) through DHCP. In 172 this case a host will perform the following steps: 174 1. Send a DHCP Information-Request message to a well-known multicast 175 address requesting DNS configuration information. 177 2. Wait for the corresponding DHCP Reply message. 179 3. Extract the DNS configuration information from the Reply message 180 and use it to configure local host behavior with regards to DNS 181 resolution. 183 If the host is using DHCP for DNS configuration, the DHCP 184 specification allows the host to send DHCP Information-Request 185 messages at times other than just once at boot time. For example, a 186 host may poll the DHCP service periodically to obtain a more up-to- 187 date list of DNS servers. Alternatively, if no servers in the host's 188 current list of DNS servers is responding, the host may choose to 189 send a DHCP Information-Request message to refresh its list of 190 servers to find one that is available. The point here is that DHCP 191 already provides mechanisms to obtain DNS configuration, the 192 mechanism involves a single request/response message, and can be 193 invoked as needed to refresh a client's configuration information. 195 5. DHCP service for DNS configuration 197 To meet the requirements of a host using DHCP for DNS configuration, 198 the DHCP service must return a Reply message in response to an 199 Information-Request message received from the client. The Reply 200 message will contain just the options supplying DNS configuration 201 information. 203 The capability to carry DNS configuration information already exists 204 in the DHCP specification. As described in the previous section, a 205 host uses the Information-Request message to request configuration 206 information without stateful address assignment. The DHCP 207 specification includes three options for carrying DNS configuration 208 [8]: 210 Domain Name Server option: provides a list of Domain Name System that 211 a client name resolver can use to access DNS services 213 Domain Name option: informs the DHCP client of its domain name 215 Domain Search option: provides a list of domain names a client 216 can use to resolve DNS names 218 The following sections describe several scenarios in which the 219 requirements for DHCP service in DNS configuration can be met through 220 different configurations of DHCP servers. 222 5.1 Minimal DHCP servers for DNS configuration 224 One obvious way to provide DHCP service is to place a DHCP server on 225 every router. Except in the case of a network composed of a single 226 link, every link has at least one router that is already providing 227 router advertisement service in addition to forwarding packets. 229 Adding DHCP service for DNS configuration to a router does not add 230 unreasonable complexity in terms of implementation or performance, 231 especially for a reduced functionality server that only supplies DNS 232 configuration information. Responding to an Information-Request 233 message requires only the formation and transmission of a Reply 234 message. The contents of every Reply message is the same and 235 contains just the DNS configuration information. 237 Note that the market in IPv4 has already demonstrated the feasibility 238 of this approach. It is common now for off-the-shelf small routers 239 to provide NAT & DHCP services, requiring little or no configuration 240 by end users. There is no reason to believe that this would be 241 different in IPv6 with DHCPv6, especially considering that the IPv4 242 implementations are fully functional DHCP servers doing stateful 243 address assignment. 245 One question is how would the router determine what DNS configuration 246 information it should advertise through DHCP. The answer is it can 247 determine this in any of several different ways. In the strictly 248 zeroconf manner, this information might come from an upstream ISP. 249 But that ISP can provide the information to the router through DHCP, 250 or whatever mechanism it uses to provide configuration information to 251 the router. (After all, the router needs, for example, a public IP 252 address on the ISP side.) Thus, there is no special problem here 253 that wouldn't also exist in any protocol the provides DNS 254 configuration, and there are a number of ways this could be done 255 without requiring end-user configuration. 257 5.2 DHCP service provided by DNS servers 259 Another deployment scenario is to provide DHCP server in a DNS 260 server. In this scenario, the DNS server is extended with the 261 capability to receive Information-Request messages and respond with 262 Reply messages. DHCP would be used as the format to carry the 263 configuration information obtained directly from the DNS server. 265 In this scenario, a host uses the DHCP Information-Request message to 266 poll for available DNS servers, and builds a list of DNS servers by 267 merging the DNS server addresses in the responses. As described in 268 Section 4, a client can use the Information-Request message to manage 269 its list of available DNS servers dynamically. 271 Providing DHCP service with DNS servers requires that DHCP 272 Information-Request messages be forwarded across multiple links from 273 the host to the server. The DHCPv6 specification defines a DHCP 274 Relay Agent that receives DHCP messages sent to a link-local 275 multicast address and forwards those messages to DHCP servers. Relay 276 Agents usually reside in routers and are therefore readily available 277 on every link. 279 DHCP Relay Agents must be deployed and managed so that they are 280 configured with the addresses of DHCP servers. To avoid the overhead 281 of managing DHCP Relay Agents on every link, a host that has used 282 stateless autoconfiguration to determine addresses with site or 283 global scope can use the site local "All DHCP Servers" multicast 284 address to send a DHCP Inform message to DHCP servers without using a 285 local DHCP Relay Agent. 287 5.3 DHCP servers co-located with DNS servers 289 A similar deployment scenario is to co-locate DHCP service with a DNS 290 server. The DHCP service returns information about its associated 291 DNS server, and only responds to messages from hosts if the DNS 292 server is available. 294 5.4 DHCP servers providing both address assignment and configuration 295 information 297 A site that is providing address assignment to some DHCP clients can 298 use the same DHCP server to provide configuration information to 299 hosts that use statless address autoconfiguration. The DHCP 300 specification allows a server to be configured with policies that 301 allow it to provide address assignment to some clients while 302 providing DNS configuration information to other clients. Thus, the 303 site need not have two different sets of DHCP servers for the two 304 types of DHCP service. 306 6. Coexistence of DHCP servers 308 A site may have a mix of hosts using DHCP in three different ways: 309 address assignment; DNS configuration; configuration information 310 including DNS configuration and other parameters. The DHCP service 311 Infrastructure may be mixed, with DNS-only servers in some routers or 312 DNS servers as well as DHCP servers providing address assignment and 313 other parameters. Further, because of DHCP relay agent configuration 314 or use of multicast, a message from any client may be delivered to 315 any server. From the point of view of the host, these servers co- 316 exist as follows: 318 Address assignment: Hosts requesting address assignment use DHCP 319 Solicit, Request, Renew, and Rebind messages. The DHCP 320 specification requires that servers that do not assign addresses - 321 in particular, DHCP servers doing just DNS configuration - ignore 322 these messages. Routers that have both a relay agent and a DHCP 323 DNS configuration server forward address assignment messages to 324 full DHCP servers. These servers then respond, so clients asking 325 for address assignment receive responses only from configuring 326 servers. 328 Full configuration: Hosts asking for configuration information 329 specify a list of the information of interest. Any server with 330 corresponding information may respond. Servers providing only DNS 331 configuration won't have all of the requested information and may 332 choose not to respond. If a server providing only DNS 333 configuration does respond, the host has the option to ignore the 334 reply and choose another response from a DHCP server that supplies 335 more complete information. 337 DNS-only configuration: A host requesting only DNS configuration will 338 identify those DNS configuration options in the Information- 339 Request message it sends. Any server configured to respond to 340 this host will do so. If the server sends back additional 341 information, clients may choose to ignore the extra information. 343 7. Open Issues 345 There are three open issues for the DHCPv6 specification raised by 346 this document: 348 Site-scoped multicast: The most recent DHCPv6 specification only 349 allows a client to send an Information-Request message to the 350 link-scoped "All_DHCP_Agents" multicsat address or to a server's 351 unicast address. To allow for discovery of DHCP servers without 352 the use of relay agents, a client could use the site-scoped 353 "All_DHCP_Servers" multicast address. 355 DNS and DHCP on one computer: A DNS server providing DNS 356 configuration through DHCP and a DHCP server will experience a 357 conflict in the use of the well-known DHCP port numbers. 359 Authentication: DHCP includes a framework for 360 authentication of DHCP messages. Use of authentication with DNS 361 configuration will be important because of the potentical spoofing 362 attack that can be mounted through the DNS search path. It may be 363 possible to improve on DHCP authentication through the use of 364 IPSEC. 366 8. Conclusion and Recommendations 368 DHCP can be used for DNS configuration of hosts. The stateless 369 version of DHCP, in which a host can obtain DNS configuration from a 370 server with a two message exchange, imposes minimal implementation 371 overhead. The configuration of a DHCP server providing DNS 372 configuration information can be automated to minimize deployment and 373 management overhead. 375 Using an existing protocol has several advantages over designing and 376 deploying a special-purpose protocol for DNS configuration of hosts. 377 Using DHCP will minimize deployment complexity, allowing a site to 378 reuse a single protocol infrastructure for host configuration that 379 will likely be deployed at most sites. Sites with both protocols 380 deployed will have to carefully coordinate the administration of the 381 two protocols to avoid giving conflicting information to hosts. If a 382 second protocol is available, sites will have to decide which to 383 deploy and how to upgrade to DHCP if necessary. Specifying a new 384 protocol for DNS configuration will require analysis of interactions 385 between the new protocol and DHCP, as well as careful specification 386 of client behavior in the case both sources of DNS configuration 387 information are available. 389 Almost all of the functions required for using DHCP for DNS 390 configuration are already specified in the latest version of the DHCP 391 document [5]. The open issues are discussed in Section 7 of this 392 document. 394 Because DHCP can meet the requirements for DNS configuration of 395 hosts,, and because the deployment and management of DHCP for this 396 purpose can be accomplished with minimum overhead, we recommend that 397 DHCP be adopted as standard mechanism for DNS configuration. This 398 recommendation should be documented, along with recommended 399 implementations and deployment strategies, in an Applicability 400 Statement or BCP document. 402 References 404 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 405 13, RFC 1034, November 1987. 407 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 408 IP Version 6 (IPv6)", RFC 2461, December 1998. 410 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 411 Autoconfiguration", RFC 2462, December 1998. 413 [4] Aboba, B., Bound, J., Deering, S., Guttman, E., HAGINO, J., 414 Hinden, R., JINMEI, T., Onoe, A., Soliman, H. and D. Thaler, 415 "Analysis of DNS Server Discovery Mechanisms for IPv6", draft- 416 ietf-ipngwg-dns-discovery-analysis (work in progress), July 417 2001. 419 [5] Bound, J., Carney, M., Perkins, C. and R. Droms (ed.), "Dynamic 420 Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc- 421 dhcpv6 (work in progress), February 2002. 423 [6] Hagino, J. and D. Thaler, "IPv6 Stateless DNS Discovery", draft- 424 ietf-ipngwg-dns-discovery (work in progress), July 2001. 426 [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 427 March 1997. 429 [8] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. 430 Droms, "The DNS Configuration options for DHCPv6", draft-ietf- 431 dhc-dhcpv6-opt-dnsconfig (work in progress), Jan 2002. 433 Authors' Addresses 435 Ralph Droms 436 Cisco Systems 437 250 Apollo Drive 438 Chelmsford, MA 01824 439 USA 441 Phone: +1 978 497 4733 442 EMail: rdroms@cisco.com 444 Thomas Narten 445 IBM Corporation 446 P.O. Box 12195 447 Research Triangle Park, NC 27709-2195 448 USA 450 Phone: +1 919 254 7798 451 EMail: narten@us.ibm.com 453 Bernard Aboba 454 Microsoft 455 One Microsoft Way 456 Redmond, WA 98052 457 USA 459 EMail: aboba@internaut.com 461 Full Copyright Statement 463 Copyright (C) The Internet Society (2002). All Rights Reserved. 465 This document and translations of it may be copied and furnished to 466 others, and derivative works that comment on or otherwise explain it 467 or assist in its implementation may be prepared, copied, published 468 and distributed, in whole or in part, without restriction of any 469 kind, provided that the above copyright notice and this paragraph are 470 included on all such copies and derivative works. However, this 471 document itself may not be modified in any way, such as by removing 472 the copyright notice or references to the Internet Society or other 473 Internet organizations, except as needed for the purpose of 474 developing Internet standards in which case the procedures for 475 copyrights defined in the Internet Standards process must be 476 followed, or as required to translate it into languages other than 477 English. 479 The limited permissions granted above are perpetual and will not be 480 revoked by the Internet Society or its successors or assigns. 482 This document and the information contained herein is provided on an 483 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 484 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 485 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 486 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 487 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 489 Acknowledgement 491 Funding for the RFC Editor function is currently provided by the 492 Internet Society.