draft-ietf-dhc-host-option-considerations-01.txt   draft-ietf-dhc-host-option-considerations-02.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 November 2002 Updates: RFC 2132 March 2003
Expires May 2003 Expires September 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-01.txt> <draft-ietf-dhc-host-option-considerations-02.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
skipping to change at page 4, line 27 skipping to change at page 4, line 27
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
implicitly relying on DHCP servers to associate the clients with the implicitly relying on DHCP servers to associate the clients with the
appropriate zone before issuing any updates to DNS. A DHCP client in appropriate zones before issuing any updates to DNS. A DHCP client
INIT state SHOULD fill in the requested host name in the DHCPDISCOVER in INIT state SHOULD fill in the requested host name in the DHCPDIS-
packet. It MUST do so in its subsequent DHCPREQUEST packet. COVER packet. It MUST do so in its subsequent DHCPREQUEST packet.
Clients in states other than INIT SHOULD avoid ambiguity in their Clients in states other than INIT SHOULD avoid ambiguity in their
requests by supplying the same Host Name option value on subsequent requests by supplying the same Host Name option value on subsequent
DHCPREQUESTs as was supplied on their original (INIT state) DHCPRE- DHCPREQUESTs as was supplied on their original (INIT state) DHCPRE-
QUEST. QUEST.
A client that wishes to change its host name MAY request it by sup- A client that wishes to change its host name MAY request it by sup-
plying a Host Name option with the new name in a subsequent RENEW plying a Host Name option with the new name in a subsequent RENEW
request. As with the initial request, a client MUST NOT use the request. As with the initial request, a client MUST NOT use the
newly-requested name until it has verified that it is now valid. newly-requested name until it has verified that it is now valid.
skipping to change at page 6, line 18 skipping to change at page 6, line 18
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. Because clients that expect DNS updates to apply for the ation. Because clients that expect DNS updates to apply for the
duration of a lease may not send a Host Name option when RENEWing, duration of their leases may not send Host Name options when RENEW-
servers SHOULD NOT interpret the absence of the option as a request ing, servers should be cautious when interpreting the absence of the
for deletion of the association. option as a request for deletion of the association; if they choose
such behavior, servers SHOULD offer an administrative facility for
The manner in which the client might express its desire to have the disabling it. Servers that do not normally operate in this manner
association destroyed is currently under discussion. Two methods MAY similarly choose to offer an administrative facility to enable
have been suggested: a zero-length Host Name option and an addi- it.
tional (``remove'') bit in the FQDN option. WG discussion at Min-
neapolis did not lead to concensus.
5. Security Considerations 5. Security Considerations
Use of the Host Name option to petition DHCP servers to do proxy DNS 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 updates is undeniably convenient for the clients but it also opens
the door for denial of service attacks and identity impersonation. the door for denial of service attacks and identity impersonation.
Administrators MUST carefully evaluate the balance between offering Administrators MUST carefully evaluate the balance between offering
the convenience of proxy DNS updates and the attendant risks. the convenience of proxy DNS updates and the attendant risks.
Clients using the Host Name option to request a DNS update will Clients using the Host Name option to request a DNS update will
skipping to change at page 7, line 5 skipping to change at page 7, line 5
as previous authentication to a network access server via PPP or as previous authentication to a network access server via PPP or
proprietary controls such as exist in many broadband cable systems, proprietary controls such as exist in many broadband cable systems,
may be available. may be available.
A DHCP server must be prepared to arbitrate between multiple clients A DHCP server must be prepared to arbitrate between multiple clients
that all claim the same fully-qualified name. It SHOULD give prefer- 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 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 use the method described in [9] to ensure that an association made on
behalf of one client is not inadvertently changed by another. behalf of one client is not inadvertently changed by another.
6. References 6. Normative 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
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-04.txt, June 2002. ietf-dhc-fqdn-option-05.txt, November 2002.
[8] Droms, R. and Arbaugh, W., "Authentication for DHCP Messages", [8] Droms, R. and Arbaugh, W., "Authentication for DHCP Messages",
RFC 3118, June 2001. RFC 3118, June 2001.
[9] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients", [9] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients",
draft-ietf-dhc-ddns-resolution-04.txt, June 2002. draft-ietf-dhc-ddns-resolution-05.txt, November 2002.
6. Author Information 7. Informative References
[5] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
1034, November 1987.
8. 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 9. Expiration
This document will expire on May 6, 2003. This document will expire on September 3, 2003.
8. Full Copyright Statement 10. 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
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
 End of changes. 

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