draft-ietf-dhc-dhcpv6-fqdn-01.txt   draft-ietf-dhc-dhcpv6-fqdn-02.txt 
DHC B. Volz DHC B. Volz
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: July 29, 2005 January 25, 2005 Expires: August 19, 2005 February 15, 2005
The DHCPv6 Client FQDN Option The DHCPv6 Client FQDN Option
draft-ietf-dhc-dhcpv6-fqdn-01.txt draft-ietf-dhc-dhcpv6-fqdn-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 July 29, 2005. This Internet-Draft will expire on August 19, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Models of Operation . . . . . . . . . . . . . . . . . . . . 3 3. Models of Operation . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . 8 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 Update Conflicts . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1 Normative References . . . . . . . . . . . . . . . . . . 11 11.1 Normative References . . . . . . . . . . . . . . . . . . 12
11.2 Informative References . . . . . . . . . . . . . . . . . 12 11.2 Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 14
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) [8] 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 [10]. 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
information to be updated over a network. information to be updated over a network.
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [5] The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [5]
provides a mechanism by which a host (a DHCPv6 client) can acquire provides a mechanism by which a host (a DHCPv6 client) can acquire
certain configuration information, along with its stateful IPv6 certain configuration information, along with its stateful IPv6
address(es). This document specifies a new DHCPv6 option, the Client address(es). This document specifies a new DHCPv6 option, the Client
FQDN option, which can be used by DHCPv6 clients and servers to FQDN option, which can be used by DHCPv6 clients and servers to
exchange information about the client's fully-qualified domain name exchange information about the client's fully-qualified domain name
and who has the responsibility for updating the DNS with the and who has the responsibility for updating the DNS with the
skipping to change at page 7, line 26 skipping to change at page 7, line 26
REBIND message originated by the client. A client MAY choose to REBIND message originated by the client. A client MAY choose to
include the Client FQDN option in its SOLICIT messages. The "S" bit include the Client FQDN option in its SOLICIT messages. The "S" bit
in the Flags field in the option MUST be 0. The "O" and "N" bits in the Flags field in the option MUST be 0. The "O" and "N" bits
MUST be 0. MUST be 0.
Once the client's DHCPv6 configuration is completed (the client Once the client's DHCPv6 configuration is completed (the client
receives a REPLY message and successfully completes a final check on receives a REPLY message and successfully completes a final check on
the parameters passed in the message), the client MAY originate an the parameters passed in the message), the client MAY originate an
update for the AAAA RRs (associated with the client's FQDN) unless update for the AAAA RRs (associated with the client's FQDN) unless
the server has set the "S" bit to 1. If the "S" is 1, the DHCPv6 the server has set the "S" bit to 1. If the "S" is 1, the DHCPv6
client MUST NOT initiate an update for the name in the Domain Name client SHOULD NOT initiate an update for the name in the server's
field. returned Client FQDN option Domain Name field. However, a DHCPv6
client that is explicitly configured with a FQDN MAY ignore the state
of the "S" bit if the server's returned name matches the client's
configured name.
5.2 Client Desires Server to Do DNS Updates 5.2 Client Desires Server to Do DNS Updates
A client can choose to delegate the responsibility for updating the A client can choose to delegate the responsibility for updating the
FQDN to IPv6 address mapping for the FQDN and address(es) used by the FQDN to IPv6 address mapping for the FQDN and address(es) used by the
client to the server. In order to inform the server of this choice, client to the server. In order to inform the server of this choice,
the client SHOULD include the Client FQDN option in its SOLICIT with the client SHOULD include the Client FQDN option in its SOLICIT with
Rapid Commit, REQUEST, RENEW, and REBIND message and MAY include the Rapid Commit, REQUEST, RENEW, and REBIND message and MAY include the
Client FQDN option in its SOLICIT. The "S" bit in the Flags field in Client FQDN option in its SOLICIT. The "S" bit in the Flags field in
the option MUST be 1. The "O" and "N" bits MUST be 0. the option MUST be 1. The "O" and "N" bits MUST be 0.
skipping to change at page 8, line 47 skipping to change at page 8, line 50
If a client releases an address prior to the expiration of the valid If a client releases an address prior to the expiration of the valid
lifetime and the client is responsible for updating its AAAA RR, the lifetime and the client is responsible for updating its AAAA RR, the
client SHOULD delete the AAAA RR associated with the address before client SHOULD delete the AAAA RR associated with the address before
sending a RELEASE message. Similarly, if a client is responsible for sending a RELEASE message. Similarly, if a client is responsible for
updating its AAAA RRs, but is unable to renew the lifetimes for an updating its AAAA RRs, but is unable to renew the lifetimes for an
address, the client SHOULD attempt to delete the AAAA RR before the address, the client SHOULD attempt to delete the AAAA RR before the
lifetime on the address is no longer valid. A DHCPv6 client which lifetime on the address is no longer valid. A DHCPv6 client which
has not been able to delete an AAAA RR which it added SHOULD attempt has not been able to delete an AAAA RR which it added SHOULD attempt
to notify its administrator, perhaps by emitting a log message. to notify its administrator, perhaps by emitting a log message.
A client SHOULD NOT perform DNS updates to AAAA RRs for its
non-Global Unicast addresses [7] or temporary addresses [6].
6. DHCPv6 Server Behavior 6. DHCPv6 Server Behavior
The following describes the behavior of a DHCPv6 server that The following describes the behavior of a DHCPv6 server that
implements the Client FQDN option when the client's message includes implements the Client FQDN option when the client's message includes
the Client FQDN option. the Client FQDN option.
Servers MUST only include a Client FQDN option in ADVERTISE and REPLY Servers MUST only include a Client FQDN option in ADVERTISE and REPLY
messages if the client included a Client FQDN option and the Client messages if the client included a Client FQDN option and the Client
FQDN option is requested by the Option Request Option in the client's FQDN option is requested by the Option Request Option in the client's
message to which the server is responding. message to which the server is responding.
skipping to change at page 10, line 13 skipping to change at page 10, line 19
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
update occurs before or after the REPLY is sent is entirely up to the update occurs before or after the REPLY is sent is entirely up to the
DHCPv6 server's configuration. DHCPv6 server's configuration.
If the server's AAAA RR DNS update does not complete until after the If the server's AAAA RR DNS update does not complete until after the
server has replied to the DHCPv6 client, the server's interaction server has replied to the DHCPv6 client, the server's interaction
with the DNS server MAY cause the DHCPv6 server to change the domain with the DNS server MAY cause the DHCPv6 server to change the domain
name that it associates with the client. This can occur, for name that it associates with the client. This can occur, for
example, if the server detects and resolves a domain-name conflict example, if the server detects and resolves a domain-name conflict
[6]. In such cases, the domain name that the server returns to the [8]. In such cases, the domain name that the server returns to the
DHCPv6 client would change between two DHCPv6 exchanges. DHCPv6 client would change between two DHCPv6 exchanges.
If the server previously performed DNS updates for the client and the If the server previously performed DNS updates for the client and the
client's information has not changed, the server MAY skip performing client's information has not changed, the server MAY skip performing
additional DNS updates. additional DNS updates.
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
skipping to change at page 10, line 41 skipping to change at page 10, line 47
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 clients 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 SHOULD 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" [6]) SHOULD be used. Name Conflicts" [8]) SHOULD be used.
8. IANA Considerations 8. 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 9. 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 [9]) 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
the DNS update protocol (e.g., only a client may have sufficient the DNS update protocol (e.g., only a client may have sufficient
credentials to perform updates to the FQDN to IPv6 address mapping credentials to perform updates to the FQDN to IPv6 address mapping
for its FQDN). for its FQDN).
skipping to change at page 11, line 42 skipping to change at page 11, line 47
Depending on the prescence of or type of authentication used with the Depending on the prescence 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 10. 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 [7]). 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 Ted Lemon, Mark Stapp, Josh Littlefield, Kim Kinnear, and
Ralph Droms for discussions on this work. Ralph Droms for discussions on this work.
11. References 11. References
11.1 Normative References 11.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.
skipping to change at page 12, line 19 skipping to change at page 12, line 26
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[4] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [4] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
1997. 1997.
[5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
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] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients [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 2004. (draft-ietf-dhc-ddns-resolution-*.txt)", September 2004.
11.2 Informative References 11.2 Informative References
[7] 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)", January 2005. Option (draft-ietf-dhc-fqdn-option-*.txt)", January 2005.
[8] 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.
[9] 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.
[10] 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.
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
 End of changes. 

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