draft-ietf-dhc-dhcpv6-fqdn-03.txt   draft-ietf-dhc-dhcpv6-fqdn-04.txt 
DHC B. Volz DHC B. Volz
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: March 28, 2006 September 24, 2005 Expires: August 28, 2006 February 24, 2006
The DHCPv6 Client FQDN Option The DHCPv6 Client FQDN Option
draft-ietf-dhc-dhcpv6-fqdn-03.txt draft-ietf-dhc-dhcpv6-fqdn-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies a new Dynamic Host Configuration Protocol for This document specifies a new Dynamic Host Configuration Protocol for
IPv6, DHCPv6, option which can be used to exchange information about IPv6, DHCPv6, option which can be used to exchange information about
a DHCPv6 client's fully-qualified domain name and about a DHCPv6 client's fully-qualified domain name and about
responsibility for updating DNS RRs related to the client's address responsibility for updating DNS RRs related to the client's address
assignments. assignments.
Table of Contents Table of Contents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
4. The DHCPv6 Client FQDN Option . . . . . . . . . . . . . . . . 4 4. The DHCPv6 Client FQDN Option . . . . . . . . . . . . . . . . 4
4.1. The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 4.1. The Flags Field . . . . . . . . . . . . . . . . . . . . . 5
4.2. The Domain Name Field . . . . . . . . . . . . . . . . . . 6 4.2. The Domain Name Field . . . . . . . . . . . . . . . . . . 6
5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 6 5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 6
5.1. Client Desires to Update AAAA RRs . . . . . . . . . . . . 7 5.1. Client Desires to Update AAAA RRs . . . . . . . . . . . . 7
5.2. Client Desires Server to Do DNS Updates . . . . . . . . . 7 5.2. Client Desires Server to Do DNS Updates . . . . . . . . . 7
5.3. Client Desires No Server DNS Updates . . . . . . . . . . . 7 5.3. Client Desires No Server DNS Updates . . . . . . . . . . . 7
5.4. Domain Name and DNS Update Issues . . . . . . . . . . . . 8 5.4. Domain Name and DNS Update Issues . . . . . . . . . . . . 8
6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 9 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 9
6.1. When to Perform DNS Updates . . . . . . . . . . . . . . . 9 6.1. When to Perform DNS Updates . . . . . . . . . . . . . . . 9
7. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 10 7. DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
DNS ([2], [3]) maintains (among other things) the information about DNS ([2], [3]) maintains (among other things) the information about
mapping between hosts' Fully Qualified Domain Names (FQDNs) [10] and mapping between hosts' Fully Qualified Domain Names (FQDNs) [10] and
IPv6 addresses assigned to the hosts. The information is maintained IPv6 addresses assigned to the hosts. The information is maintained
in two types of Resource Records (RRs): AAAA and PTR [12]. The DNS in two types of Resource Records (RRs): AAAA and PTR [12]. The DNS
update specification ([4]) describes a mechanism that enables DNS update specification ([4]) describes a mechanism that enables DNS
skipping to change at page 9, line 25 skipping to change at page 9, line 25
message to which the server is responding. message to which the server is responding.
The server examines its configuration and the Flag bits in the The server examines its configuration and the Flag bits in the
client's Client FQDN option to determine how to respond: 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 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. of the option it will return to the client.
o If the client's "N" bit is 1 and the server's configuration allows 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 it to honor the client's request for no server initiated DNS
updates, the server sets the "N" bit to 1. 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 configuration allows it to honor the client's request for the
server to initiate AAAA RR DNS updates and if it has the necessary server to initiate AAAA RR DNS updates, the server sets the "S" to
credentials, the server sets the "S" to 1. If the server's "S" 1. If the server's "S" bit does not match the client's "S" bit,
bit does not match the client's "S" bit, the server sets the "O" the server sets the "O" bit to 1.
bit to 1.
The server MAY be configured to use the name supplied in the client's 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 Client FQDN option, or it MAY be configured to modify the supplied
name, or substitute a different name. The server SHOULD send its name, or substitute a different name. The server SHOULD send its
notion of the complete FQDN for the client in the Domain Name field. 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 The server MAY simply copy the Domain Name field from the Client FQDN
option that the client sent to the server. option that the client sent to the server.
6.1. When to Perform DNS Updates 6.1. When to Perform DNS Updates
The server SHOULD NOT perform any DNS updates if the "N" bit is 1 in 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 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 be) sent to the client. However, the server SHOULD delete any RRs
which it previously added via DNS updates for the client. which it previously added via DNS updates for the client.
The server MAY perform the PTR RR DNS update (unless the "N" bit is The server MAY perform the PTR RR DNS update (unless the "N" bit is
1). 1).
The server MAY perform the AAAA RR DNS update if the "S" bit is 1 in 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. be) sent to the client.
The server MAY perform these updates even if the client's message did 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 not carry the Client FQDN option. The server MUST NOT initiate DNS
updates when responding with an ADVERTISE message to the client. updates when responding with an ADVERTISE message to the client.
The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR) The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR)
before the server sends the REPLY message to the client. before the server sends the REPLY message to the client.
Alternatively, the server MAY send 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 without waiting for the update to be completed. Whether the DNS
skipping to change at page 10, line 38 skipping to change at page 10, line 37
When a server receives a RELEASE or DECLINE for an address, detects 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 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 client has expired, or terminates a binding on an address prior to
the binding's expiration time (for instance, by sending a REPLY with the binding's expiration time (for instance, by sending a REPLY with
a zero valid lifetime for an address), the server SHOULD delete any a zero valid lifetime for an address), the server SHOULD delete any
PTR RR which it associated with the address via DNS update. In PTR RR which it associated with the address via DNS update. In
addition, if the server took responsibility for AAAA RRs, the server addition, if the server took responsibility for AAAA RRs, the server
SHOULD also delete the AAAA RR. 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 This document does not resolve how a DHCPv6 client or server prevent
name conflicts. This document addresses only how a DHCPv6 client and name conflicts. This document addresses only how a DHCPv6 client and
server negotiate the fully qualified domain name and who will perform server negotiate the fully qualified domain name and who will perform
the DNS updates. the DNS updates.
Implementers of this work will need to consider how name conflicts Implementers of this work will need to consider how name conflicts
will be prevented. If a DNS updater needs a security token in order will be prevented. If a DNS updater needs a security token in order
to successfully perform DNS updates on a specific name, name 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 token for that name. Or, if the fully qualified domains are based on
the specific address bound to a client, conflicts will not occur. the specific address bound to a client, conflicts will not occur.
Or, a name conflict resolution technique as described in "Resolving Or, a name conflict resolution technique as described in "Resolving
Name Conflicts" [8]) SHOULD be used. 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 IANA is requested to assign a DHCPv6 option code for the Client FQDN
option. option.
9. Security Considerations 10. Security Considerations
Unauthenticated updates to the DNS can lead to tremendous confusion, Unauthenticated updates to the DNS can lead to tremendous confusion,
through malicious attack or through inadvertent misconfiguration. through malicious attack or through inadvertent misconfiguration.
Administrators need to be wary of permitting unsecured DNS updates to Administrators need to be wary of permitting unsecured DNS updates to
zones which are exposed to the global Internet. Both DHCPv6 clients zones which are exposed to the global Internet. Both DHCPv6 clients
and servers SHOULD use some form of update request origin and servers SHOULD use some form of update request origin
authentication procedure (e.g., Secure DNS Dynamic Update [11]) when authentication procedure (e.g., Secure DNS Dynamic Update [11]) when
performing DNS updates. performing DNS updates.
Whether a DHCPv6 client is responsible for updating an FQDN to IPv6 Whether a DHCPv6 client is responsible for updating an FQDN to IPv6
address mapping or whether this is the responsibility of the DHCPv6 address mapping or whether this is the responsibility of the DHCPv6
server is a site-local matter. The choice between the two server is a site-local matter. The choice between the two
alternatives is likely based on the security model that is used with alternatives is likely based on the security model that is used with
skipping to change at page 11, line 40 skipping to change at page 12, line 28
Whether a DHCPv6 server is always responsible for updating the FQDN Whether a DHCPv6 server is always responsible for updating the FQDN
to IPv6 address mapping (in addition to updating the IPv6 to FQDN to IPv6 address mapping (in addition to updating the IPv6 to FQDN
mapping), regardless of the wishes of an individual DHCPv6 client, is mapping), regardless of the wishes of an individual DHCPv6 client, is
also a site-local matter. The choice between the two alternatives 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 likely based on the security model that is being used with DNS
updates. In cases where a DHCPv6 server is performing DNS updates on 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 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. 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 Authentication option, a DHCPv6 server may not have much confidence
in the identities of its clients. There are many ways for a DHCPv6 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 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 circumstances will the DHCPv6 server know for certain the identity of
the client. 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 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]). on the DHCPv4 Client FQDN option (draft-ietf-dhc-fqdn-option [9]).
And, to Ted Lemon, Mark Stapp, Josh Littlefield, Kim Kinnear, and And, to Ralph Droms, Ted Lemon, Josh Littlefield, Kim Kinnear, Pekka
Ralph Droms for discussions on this work. 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 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Mockapetris, P., "Domain names - concepts and facilities", [2] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[3] Mockapetris, P., "Domain names - implementation and [3] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
skipping to change at page 12, line 36 skipping to change at page 13, line 26
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003. RFC 3315, July 2003.
[6] Narten, T. and R. Draves, "Privacy Extensions for Stateless [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
[8] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients [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 [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 [10] Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions and
Answers - Answers to Commonly asked "New Internet User" Answers - Answers to Commonly asked "New Internet User"
Questions", RFC 1594, March 1994. Questions", RFC 1594, March 1994.
[11] Wellington, B., "Secure Domain Name System (DNS) Dynamic [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000. Update", RFC 3007, November 2000.
[12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS [12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
Extensions to Support IP Version 6", RFC 3596, October 2003. 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 Author's Address
Bernard Volz Bernard Volz
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 0382 Phone: +1 978 936 0382
Email: volz@cisco.com Email: volz@cisco.com
skipping to change at page 15, line 41 skipping to change at page 15, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement 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 to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 24 change blocks. 
32 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/