draft-ietf-dhc-host-option-considerations-00.txt   draft-ietf-dhc-host-option-considerations-01.txt 
DHC Working Group Carl Smith DHC Working Group Carl Smith
Internet Draft Sun Microsystems, Inc. Internet Draft Sun Microsystems, Inc.
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
Updates: RFC 2132 February 2002 Updates: RFC 2132 November 2002
Expires August 2002 Expires May 2003
Considerations for the use of the Host Name option Considerations for the use of the Host Name option
<draft-ietf-dhc-host-option-considerations-00.txt> <draft-ietf-dhc-host-option-considerations-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 To view the entire list of current Internet-Drafts, please check the
http://www.ietf.org/1id-abstracts.html 1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
The list of Internet-Draft Shadow Directories can be accessed at Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim),
http://www.ietf.org/shadow.html ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
This document clarifies the use of the DHCP Host Name option. The This document clarifies the use of the DHCP Host Name option. The
primary point of this clarification addresses the use of the option primary point of this clarification addresses the use of the option
by clients to request proxy DNS updates by DHCP servers. by clients to request proxy DNS updates by DHCP servers.
1. Introduction 1. Introduction
The initial concept of the Host Name option, as documented in RFC The initial concept of the Host Name option, as documented in RFC
skipping to change at page 2, line 36 skipping to change at page 2, line 36
A DHCP server or "server" is an Internet host that returns A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients. configuration parameters to DHCP clients.
"FQDN" "FQDN"
A fully-qualified name, including the host part and Domain Name A fully-qualified name, including the host part and Domain Name
system domain. system domain.
3. Interactions with Name Services 3. Interactions with Name Services
A DHCP client's use of the Host Name option should be fairly RFC 2132 [2] indicates that the value supplied in the Host Name
straightforward, but users report problems, particularly with the option may or may not be fully-qualified, suggesting the use of the
interactions between it and Domain Name option and between the DNS Domain Name option to retrieve the domain name. This, plus the
(RFC 1034 [5] and RFC 1035 [6]) and other naming services so we possibility of interactions between DNS (RFC 1034 [5] and RFC 1035
reiterate and expand the description of the expected behavior: [6]) and other naming services motivates us to clarify and expand the
description of the expected behavior:
if a DHCP server supplies both Host Name and Domain Name options if a DHCP server supplies both Host Name and Domain Name options
to a client, the host name SHOULD NOT be fully-qualified to a client, the host name SHOULD NOT be fully-qualified
if a DHCP server supplies only a Host Name option, the host name if a DHCP server supplies only a Host Name option, the host name
SHOULD be fully qualified; the server MUST append only DNS domain SHOULD be fully qualified; the server MUST append only DNS domain
names in forming a fully-qualified name names in forming a fully-qualified name
a client MUST check to see whether a Host Name option contains a a client MUST check to see whether a Host Name option contains a
fully-qualified name and if so, MUST NOT append the value of the fully-qualified name and if so, MUST NOT append the value of the
skipping to change at page 3, line 14 skipping to change at page 3, line 15
domain name domain name
since a Host Name option's value may be fully-qualified only by since a Host Name option's value may be fully-qualified only by
supplying the DNS domain name, a client that receives a fully- supplying the DNS domain name, a client that receives a fully-
qualified name in the Host Name option MAY infer the DNS domain qualified name in the Host Name option MAY infer the DNS domain
name from the suffix of the supplied host name. This inference name from the suffix of the supplied host name. This inference
remains valid even in the presence of client configuration infor- remains valid even in the presence of client configuration infor-
mation or policies that prefer other name services in favor of, or mation or policies that prefer other name services in favor of, or
in place of, DNS. in place of, DNS.
In summary,
Host Name Host Name
not fully-qualifled fully-qualified
_____________________________________________
Domain Name | no derivable FQDN | infer Domain Name |
option absent | | from Host Name suffix |
|____________________|________________________|
Domain Name | derive FQDN by | Domain Name MUST be a |
option present | Host and Domain | suffix of Host Name |
| Name concatenation | |
|____________________|________________________|
4. DNS Updates for DHCP Clients 4. DNS Updates for DHCP Clients
DNS maintains Resource Records (RRs) for mapping between IP addresses DNS maintains Resource Records (RRs) for mapping between IP addresses
FQDNs. Specifically, A records map FQDNs to IP addresses and PTR FQDNs. Specifically, A records map FQDNs to IP addresses and PTR
records map IP addresses to FQDNs. Several options are available to records map IP addresses to FQDNs. Several options are available to
DHCP clients interested in updating A and PTR records: DHCP clients interested in updating A and PTR records:
issuing direct updates to DNS issuing direct updates to DNS
using the DHCP client FQDN option [7] using the DHCP client FQDN option [7]
using the DHCP Host Name option using the DHCP Host Name option
Either of the first two methods has the advantage of offering the Either of the first two methods has the advantage of offering the
client a number of approaches for fine-tuning DNS update requests as client a number of approaches for fine-tuning DNS update requests as
well as direct feedback on the success or failure of the intended well as direct feedback on the success or failure of the intended
operations. Both are to be preferred over the latter: use of the operations. Both are to be preferred over the latter: use of the
Host Name option does not even guarantee that the DHCP server will Host Name option does not even guarantee that the DHCP server will
attempt any DNS updates on a client's behalf. Nevertheless, support attempt any DNS updates on a client's behalf. It should be con-
for this method of requesting proxy DNS updates is widespread and it sidered deprecated. Nevertheless, support for this method of
may be viewed as appropriate for situations in which there are no requesting proxy DNS updates is widespread and it may be viewed as
requirements for other finely-tunable methods. appropriate for situations in which there are no requirements for
other finely-tunable methods.
4.1 DHCP Client Considerations and Behavior 4.1 DHCP Client Considerations and Behavior
A DHCP client that uses the Host Name option to request a DNS update A DHCP client that uses the Host Name option to request a DNS update
MUST be prepared to independently verify the success or failure of MUST be prepared to independently verify the success or failure of
the request before using the name in a manner that would imply its the request before using the name in a manner that would imply its
validity. If a DHCP server returns the requested name in the validity. If a DHCP server returns the requested name in the
DHCPACK's Host Name option, the client MAY infer that the server has DHCPACK's Host Name option, the client MAY infer that the server has
honored its request. honored its request.
There are a number of reasons that a DHCP server may fail to return a There are a number of reasons that a DHCP server may fail to return a
Host Name option, so nothing should be inferred from the option's Host Name option; nothing should be inferred from the option's
absence in the DHCPACK. The client MAY supply the option on subse- absence in the DHCPACK. The client MAY supply the option on subse-
quent RENEW operations as a method of retrying the request. However, quent RENEW operations as a method of retrying the request. However,
if the Host Name option is absent in the DHCPACK, the client MUST NOT if the Host Name option is absent in the DHCPACK, the client MUST NOT
use the requested name until it has verified the validity of the use the requested name until it has verified the validity of the
association between it and the IP address supplied in the yiaddr association between it and the IP address supplied in the yiaddr
field. Moreover, if the name returned in the DHCPACK is different field. Moreover, if the name returned in the DHCPACK is different
from the one requested, the client MUST use the new name. from the one requested, the client MUST use the new name.
A DHCP client MAY send either an unqualified or fully-qualified name A DHCP client MAY send either an unqualified or fully-qualified name
in the Host Name option. Clients sending unqualified names are in the Host Name option. Clients sending unqualified names are
skipping to change at page 5, line 35 skipping to change at page 5, line 50
and may need to be recovered when the server is restarted. and may need to be recovered when the server is restarted.
When a lease expires, a DHCP server MAY use this stored information When a lease expires, a DHCP server MAY use this stored information
to expunge the name-to-address association it created on the client's to expunge the name-to-address association it created on the client's
behalf. Because the use of the Host Name option cedes the ownership behalf. Because the use of the Host Name option cedes the ownership
of the name to the server, a server MAY instead choose to allow the of the name to the server, a server MAY instead choose to allow the
association to continue, saving itself work now and possibly sparing association to continue, saving itself work now and possibly sparing
the need for a future update. the need for a future update.
A server MAY choose to reevaluate the Host Name option each time a A server SHOULD reevaluate the Host Name option each time a client
client sends a RENEW request via a DHCPREQUEST, or the server MAY sends a RENEW request via a DHCPREQUEST, or the server MAY choose to
choose to view the update request as an action to be taken once, upon view the update request as an action to be taken once, upon initial
initial lease of an address. Servers that take the former view offer lease of an address. Servers that take the former view offer their
their clients the possibility of changing the name associated with a clients the possibility of changing the name associated with a
currently valid lease, but may incur additional processing costs currently valid lease, but may incur additional processing costs
because of it. Servers taking the latter view do not afford clients because of it. Servers taking the latter view do not afford clients
the opportunity to change names, but more importantly do not allow the opportunity to change names, but more importantly do not allow
them to retry failed requests, possibly even with different host them to retry failed requests, possibly even with different host
names. For this reason, the former behavior is preferred: servers names. For this reason, the former behavior is preferred: servers
SHOULD reevaluate the Host Name option on each RENEW. SHOULD reevaluate the Host Name option on each RENEW.
Some servers interpret a Host Name option on the initial DHCPREQUEST, Some servers interpret a Host Name option on the initial DHCPREQUEST,
followed by the absence of the option on subsequent RENEW DHCPRE- followed by the absence of the option on subsequent RENEW DHCPRE-
QUESTs as a request by the client to delete a name-to-address associ- QUESTs as a request by the client to delete a name-to-address associ-
ation. Here we invoke the principle of least surprise: it is more ation. Because clients that expect DNS updates to apply for the
reasonable for a client to expect that DNS updates apply for the duration of a lease may not send a Host Name option when RENEWing,
duration of a lease than it is to expect that a client will wish to servers SHOULD NOT interpret the absence of the option as a request
delete an update but retain the lease. Because clients that expect for deletion of the association.
DNS updates to apply for the duration of a lease may not send a Host
Name option when RENEWing, servers SHOULD NOT interpret the absence
of the option as a request for deletion of the association.
5. References The manner in which the client might express its desire to have the
association destroyed is currently under discussion. Two methods
have been suggested: a zero-length Host Name option and an addi-
tional (``remove'') bit in the FQDN option. WG discussion at Min-
neapolis did not lead to concensus.
5. Security Considerations
Use of the Host Name option to petition DHCP servers to do proxy DNS
updates is undeniably convenient for the clients but it also opens
the door for denial of service attacks and identity impersonation.
Administrators MUST carefully evaluate the balance between offering
the convenience of proxy DNS updates and the attendant risks.
Clients using the Host Name option to request a DNS update will
likely lack a means of authenticating themselves (otherwise, they
might have dealt directly, and securely, with DNS). DHCP servers
SHOULD use all means at their disposal to verify the requests. Use
of DHCP Authentication ([8]) is far from common but other means, such
as previous authentication to a network access server via PPP or
proprietary controls such as exist in many broadband cable systems,
may be available.
A DHCP server must be prepared to arbitrate between multiple clients
that all claim the same fully-qualified name. It SHOULD give prefer-
ence to a client whose identity it can verify. Failing that, it MUST
use the method described in [9] to ensure that an association made on
behalf of one client is not inadvertently changed by another.
6. References
[1] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor [1] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 1533, October 1993. Extensions", RFC 1533, October 1993.
[2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[3] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates [3] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates
in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[4] Bradner, S., "Key words for use in RFCs to indicate requirement [4] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997. levels", RFC 2119, March 1997.
[5] Mockapetris, P., "Domain names - Concepts and Facilities", RFC [5] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
1034, November 1987. 1034, November 1987.
[6] Mockapetris, P., "Domain names - Implementation and Specifica- [6] Mockapetris, P., "Domain names - Implementation and Specifica-
tion", RFC 1035, November 1987. tion", RFC 1035, November 1987.
[7] Stapp, M. and Rekhter, Y., "The DHCP Client FQDN Option", draft- [7] Stapp, M. and Rekhter, Y., "The DHCP Client FQDN Option", draft-
ietf-dhc-fqdn-option-03.txt, November 2001. ietf-dhc-fqdn-option-04.txt, June 2002.
[8] Droms, R. and Arbaugh, W., "Authentication for DHCP Messages",
RFC 3118, June 2001.
[9] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients",
draft-ietf-dhc-ddns-resolution-04.txt, June 2002.
6. Author Information 6. Author Information
Carl Smith Carl Smith
Sun Microsystems, Inc. Sun Microsystems, Inc.
901 San Antonio Road 901 San Antonio Road
Palo Alto, CA 94043 Palo Alto, CA 94043
USA USA
email: cs@Eng.Sun.COM email: cs@Eng.Sun.COM
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
950 Charter Street 950 Charter Street
Redwood City, CA 94043 Redwood City, CA 94043
USA USA
email: Ted.Lemon@nominum.com email: Ted.Lemon@nominum.com
7. Expiration 7. Expiration
This document will expire on August 22, 2002. This document will expire on May 6, 2003.
8. Full Copyright Statement 8. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

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