--- 1/draft-ietf-dhc-dhcpv6-fqdn-03.txt 2006-02-25 01:12:25.000000000 +0100 +++ 2/draft-ietf-dhc-dhcpv6-fqdn-04.txt 2006-02-25 01:12:25.000000000 +0100 @@ -1,17 +1,17 @@ DHC B. Volz Internet-Draft Cisco Systems, Inc. -Expires: March 28, 2006 September 24, 2005 +Expires: August 28, 2006 February 24, 2006 The DHCPv6 Client FQDN Option - draft-ietf-dhc-dhcpv6-fqdn-03.txt + draft-ietf-dhc-dhcpv6-fqdn-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -22,25 +22,25 @@ 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 March 28, 2006. + This Internet-Draft will expire on August 28, 2006. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). Abstract This document specifies a new Dynamic Host Configuration Protocol for IPv6, DHCPv6, option which can be used to exchange information about a DHCPv6 client's fully-qualified domain name and about responsibility for updating DNS RRs related to the client's address assignments. Table of Contents @@ -51,27 +51,28 @@ 4. The DHCPv6 Client FQDN Option . . . . . . . . . . . . . . . . 4 4.1. The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 4.2. The Domain Name Field . . . . . . . . . . . . . . . . . . 6 5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 6 5.1. Client Desires to Update AAAA RRs . . . . . . . . . . . . 7 5.2. Client Desires Server to Do DNS Updates . . . . . . . . . 7 5.3. Client Desires No Server DNS Updates . . . . . . . . . . . 7 5.4. Domain Name and DNS Update Issues . . . . . . . . . . . . 8 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 9 6.1. When to Perform DNS Updates . . . . . . . . . . . . . . . 9 - 7. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 10 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 + 7. DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 11 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 1. Introduction DNS ([2], [3]) maintains (among other things) the information about mapping between hosts' Fully Qualified Domain Names (FQDNs) [10] and IPv6 addresses assigned to the hosts. The information is maintained in two types of Resource Records (RRs): AAAA and PTR [12]. The DNS update specification ([4]) describes a mechanism that enables DNS @@ -362,46 +363,45 @@ message to which the server is responding. The server examines its configuration and the Flag bits in the client's Client FQDN option to determine how to respond: o The server sets to 0 the "S", "O", and "N" Flag bits in its copy of the option it will return to the client. o If the client's "N" bit is 1 and the server's configuration allows it to honor the client's request for no server initiated DNS updates, the server sets the "N" bit to 1. - o Otherwise, if the client's "S" bit is 1 and the servers's + o Otherwise, if the client's "S" bit is 1 and the server's configuration allows it to honor the client's request for the - server to initiate AAAA RR DNS updates and if it has the necessary - credentials, the server sets the "S" to 1. If the server's "S" - bit does not match the client's "S" bit, the server sets the "O" - bit to 1. + server to initiate AAAA RR DNS updates, the server sets the "S" to + 1. If the server's "S" bit does not match the client's "S" bit, + the server sets the "O" bit to 1. The server MAY be configured to use the name supplied in the client's Client FQDN option, or it MAY be configured to modify the supplied name, or substitute a different name. The server SHOULD send its notion of the complete FQDN for the client in the Domain Name field. The server MAY simply copy the Domain Name field from the Client FQDN option that the client sent to the server. 6.1. When to Perform DNS Updates The server SHOULD NOT perform any DNS updates if the "N" bit is 1 in the Flags field of the Client FQDN option in the REPLY messages (to be) sent to the client. However, the server SHOULD delete any RRs which it previously added via DNS updates for the client. The server MAY perform the PTR RR DNS update (unless the "N" bit is 1). The server MAY perform the AAAA RR DNS update if the "S" bit is 1 in - the Flags field of the Client FQDN option in the DHCPACK message (to + the Flags field of the Client FQDN option in the REPLY message (to be) sent to the client. The server MAY perform these updates even if the client's message did not carry the Client FQDN option. The server MUST NOT initiate DNS updates when responding with an ADVERTISE message to the client. The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR) before the server sends the REPLY message to the client. Alternatively, the server MAY send the REPLY message to the client without waiting for the update to be completed. Whether the DNS @@ -422,46 +422,81 @@ When a server receives a RELEASE or DECLINE for an address, detects that the valid lifetime on an address that the server bound to a client has expired, or terminates a binding on an address prior to the binding's expiration time (for instance, by sending a REPLY with a zero valid lifetime for an address), the server SHOULD delete any PTR RR which it associated with the address via DNS update. In addition, if the server took responsibility for AAAA RRs, the server SHOULD also delete the AAAA RR. -7. DNS Update Conflicts +7. DNS RR TTLs + + RRs associated with DHCP clients may be more volatile than statically + configured RRs. DHCP clients and servers that perform dynamic + updates should attempt to specify resource record TTLs which reflect + this volatility, in order to minimize the possibility that answers to + DNS queries will return records that refer to DHCP IP address + assignments that have expired or been released. + + The coupling among primary, secondary, and caching DNS servers is + 'loose'; that is a fundamental part of the design of the DNS. This + looseness makes it impossible to prevent all possible situations in + which a resolver may return a record reflecting a DHCP assigned IP + address that has expired or been released. In deployment, this + rarely, if ever, represents a significant problem. Most DHCP-managed + clients are infrequently looked-up by name in the DNS, and the + deployment of IXFR (RFC 1995 [13]) and NOTIFY (RFC 1996 [14]) can + reduce the latency between updates and their visibility at secondary + servers. + + We suggest these basic guidelines for implementers. In general, the + TTLs for RRs added as a result of DHCP IP address assignment activity + SHOULD be less than the initial lifetime. The RR TTL on a DNS record + added SHOULD NOT exceed 1/3 of the lifetime, and SHOULD be at least + 10 minutes. We recognize that individual administrators will have + varying requirements: DHCP servers and clients SHOULD allow + administrators to configure TTLs and upper and lower bounds on the + TTL values, either as an absolute time interval or as a percentage of + the lease lifetime. + + While clients and servers MAY update the TTL of the records as the + lifetime is about to expire, there is no requirement that they do so + as this puts additional load on the DNS system with likely little + benefit. + +8. DNS Update Conflicts This document does not resolve how a DHCPv6 client or server prevent name conflicts. This document addresses only how a DHCPv6 client and server negotiate the fully qualified domain name and who will perform the DNS updates. Implementers of this work will need to consider how name conflicts will be prevented. If a DNS updater needs a security token in order to successfully perform DNS updates on a specific name, name - conflicts can only occur if multiple clients are given a security + conflicts can only occur if multiple updaters are given a security token for that name. Or, if the fully qualified domains are based on the specific address bound to a client, conflicts will not occur. - Or, a name conflict resolution technique as described in "Resolving Name Conflicts" [8]) SHOULD be used. -8. IANA Considerations +9. IANA Considerations IANA is requested to assign a DHCPv6 option code for the Client FQDN option. -9. Security Considerations +10. Security Considerations Unauthenticated updates to the DNS can lead to tremendous confusion, through malicious attack or through inadvertent misconfiguration. + Administrators need to be wary of permitting unsecured DNS updates to zones which are exposed to the global Internet. Both DHCPv6 clients and servers SHOULD use some form of update request origin authentication procedure (e.g., Secure DNS Dynamic Update [11]) when performing DNS updates. Whether a DHCPv6 client is responsible for updating an FQDN to IPv6 address mapping or whether this is the responsibility of the DHCPv6 server is a site-local matter. The choice between the two alternatives is likely based on the security model that is used with @@ -471,37 +506,40 @@ Whether a DHCPv6 server is always responsible for updating the FQDN to IPv6 address mapping (in addition to updating the IPv6 to FQDN mapping), regardless of the wishes of an individual DHCPv6 client, is also a site-local matter. The choice between the two alternatives is likely based on the security model that is being used with DNS updates. In cases where a DHCPv6 server is performing DNS updates on behalf of a client, the DHCPv6 server SHOULD be sure of the DNS name to use for the client, and of the identity of the client. - Depending on the prescence of or type of authentication used with the + Depending on the presence of or type of authentication used with the Authentication option, a DHCPv6 server may not have much confidence in the identities of its clients. There are many ways for a DHCPv6 server to develop a DNS name to use for a client, but only in certain circumstances will the DHCPv6 server know for certain the identity of the client. -10. Acknowledgements + It is critical to implement proper conflict resolution, and the + security considerations of conflict resolution apply [8]. + +11. Acknowledgements Many thanks to Mark Stapp and Yakov Rekhter as this document is based on the DHCPv4 Client FQDN option (draft-ietf-dhc-fqdn-option [9]). - And, to Ted Lemon, Mark Stapp, Josh Littlefield, Kim Kinnear, and - Ralph Droms for discussions on this work. + And, to Ralph Droms, Ted Lemon, Josh Littlefield, Kim Kinnear, Pekka + Savola, and Mark Stapp for their review and comments. -11. References +12. References -11.1. Normative References +12.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [3] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. @@ -513,37 +551,43 @@ Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [8] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients - (draft-ietf-dhc-ddns-resolution-*.txt)", September 2005. + (draft-ietf-dhc-ddns-resolution-*.txt)", February 2006. -11.2. Informative References +12.2. Informative References [9] Stapp, M., Volz, B., and Y. Rekhter, "The DHCP Client FQDN - Option (draft-ietf-dhc-fqdn-option-*.txt)", September 2005. + Option (draft-ietf-dhc-fqdn-option-*.txt)", February 2006. [10] Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions", RFC 1594, March 1994. [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. + [13] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + August 1996. + + [14] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes + (DNS NOTIFY)", RFC 1996, August 1996. + Author's Address Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA Phone: +1 978 936 0382 Email: volz@cisco.com @@ -577,18 +621,18 @@ This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement - Copyright (C) The Internet Society (2005). This document is subject + Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.