draft-ietf-dhc-fqdn-option-08.txt   draft-ietf-dhc-fqdn-option-09.txt 
DHC M. Stapp DHC M. Stapp
Internet-Draft B. Volz Internet-Draft B. Volz
Expires: June 23, 2005 Cisco Systems, Inc. Expires: July 28, 2005 Cisco Systems, Inc.
Y. Rekhter Y. Rekhter
Juniper Networks Juniper Networks
December 23, 2004 January 24, 2005
The DHCP Client FQDN Option The DHCP Client FQDN Option
<draft-ietf-dhc-fqdn-option-08.txt> <draft-ietf-dhc-fqdn-option-09.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.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 June 23, 2005. This Internet-Draft will expire on July 28, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies a DHCP for IPv4, DHCPv4, option which can be This document specifies a DHCP for IPv4, DHCPv4, option which can be
used to exchange information about a DHCPv4 client's fully-qualified used to exchange information about a DHCPv4 client's fully-qualified
domain name and about responsibility for updating the DNS RR related domain name and about responsibility for updating the DNS RR related
to the client's address assignment. to the client's address assignment.
Table of Contents Table of Contents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
3. The Client FQDN Option . . . . . . . . . . . . . . . . . . . . 4 3. The Client FQDN Option . . . . . . . . . . . . . . . . . . . . 4
3.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 3.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5
3.2 The RCODE Fields . . . . . . . . . . . . . . . . . . . . . 6 3.2 The RCODE Fields . . . . . . . . . . . . . . . . . . . . . 6
3.3 The Domain Name Field . . . . . . . . . . . . . . . . . . 6 3.3 The Domain Name Field . . . . . . . . . . . . . . . . . . 6
3.3.1 Deprecated ASCII Encoding . . . . . . . . . . . . . . 7 3.3.1 Deprecated ASCII Encoding . . . . . . . . . . . . . . 7
4. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 7 4. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 7
4.1 Interaction With Other Options . . . . . . . . . . . . . . 7 4.1 Interaction With Other Options . . . . . . . . . . . . . . 7
4.2 Client Desires to Update A RRs . . . . . . . . . . . . . . 8 4.2 Client Desires to Update A RRs . . . . . . . . . . . . . . 8
4.3 Client Desires Server to Do DNS Updates . . . . . . . . . 8 4.3 Client Desires Server to Do DNS Updates . . . . . . . . . 8
4.4 Client Desires No Server DNS Updates . . . . . . . . . . . 8 4.4 Client Desires No Server DNS Updates . . . . . . . . . . . 8
4.5 Domain Name and DNS Update Issues . . . . . . . . . . . . 9 4.5 Domain Name and DNS Update Issues . . . . . . . . . . . . 8
5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 9 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 9
5.1 When to Perform DNS Updates . . . . . . . . . . . . . . . 10 5.1 When to Perform DNS Updates . . . . . . . . . . . . . . . 10
6. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 11 6. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 10.1 Normative References . . . . . . . . . . . . . . . . . . . 13
10.2 Informative References . . . . . . . . . . . . . . . . . . . 13 10.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 15
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
2. Introduction 2. Introduction
skipping to change at page 4, line 43 skipping to change at page 4, line 43
To update the IP address to FQDN mapping a DHCP server needs to know To update the IP address to FQDN mapping a DHCP server needs to know
the FQDN of the client to which the server leases the address. To the FQDN of the client to which the server leases the address. To
allow the client to convey its FQDN to the server this document allow the client to convey its FQDN to the server this document
defines a new DHCP option, called "Client FQDN". The Client FQDN defines a new DHCP option, called "Client FQDN". The Client FQDN
option also contains Flags, which DHCP servers can use to convey option also contains Flags, which DHCP servers can use to convey
information about DNS updates to clients, and two deprecated RCODEs. information about DNS updates to clients, and two deprecated RCODEs.
Clients MAY send the Client FQDN option, setting appropriate Flags Clients MAY send the Client FQDN option, setting appropriate Flags
values, in both their DHCPDISCOVER and DHCPREQUEST messages. If a values, in both their DHCPDISCOVER and DHCPREQUEST messages. If a
client sends the Client FQDN option in its DHCPDISCOVER message, it client sends the Client FQDN option in its DHCPDISCOVER message, it
MUST send the option in subsequent DHCPREQUEST messages. MUST send the option in subsequent DHCPREQUEST messages though the
contents of the option MAY change.
Only one FQDN MAY appear in a message. As per [13], multiple Only one Client FQDN option MAY appear in a message.
instances of this option in a message SHOULD be concatentated.
The code for this option is 81. Its minimum length is 3. The code for this option is 81. Its minimum length is 3 (octets).
The Format of the Client FQDN Option is: The format of the Client FQDN option is:
Code Len Flags RCODE1 RCODE2 Domain Name Code Len Flags RCODE1 RCODE2 Domain Name
+------+------+------+------+------+------+-- +------+------+------+------+------+------+--
| 81 | n | | | | ... | 81 | n | | | | ...
+------+------+------+------+------+------+-- +------+------+------+------+------+------+--
The above figure follows the conventions of [8].
3.1 The Flags Field 3.1 The Flags Field
The Format of the Flags Field is: The format of the 1-octet Flags field is:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MBZ |N|E|O|S| | MBZ |N|E|O|S|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The "S" bit indicates whether the server SHOULD or SHOULD NOT perform The "S" bit indicates whether the server SHOULD or SHOULD NOT perform
the A RR (FQDN to address) DNS updates. A client sets the bit to 0 the A RR (FQDN to address) DNS updates. A client sets the bit to 0
to indicate the server SHOULD NOT perform the updates and 1 to to indicate the server SHOULD NOT perform the updates and 1 to
indicate the server SHOULD perform the updates. The state of the bit indicate the server SHOULD perform the updates. The state of the bit
skipping to change at page 5, line 38 skipping to change at page 5, line 40
The "O" bit indicates whether the server has overridden the client's The "O" bit indicates whether the server has overridden the client's
preference for the "S" bit. A client MUST set this bit to 0. A preference for the "S" bit. A client MUST set this bit to 0. A
server MUST set this bit to 1 if the "S" bit in its reply to the server MUST set this bit to 1 if the "S" bit in its reply to the
client does not match the "S" bit received from the client. client does not match the "S" bit received from the client.
The "N" bit indicates whether the server SHOULD NOT perform any DNS The "N" bit indicates whether the server SHOULD NOT perform any DNS
updates. A client sets this bit to 0 to request that the server updates. A client sets this bit to 0 to request that the server
SHOULD perform updates (the PTR RR and possibly the A RR based on the SHOULD perform updates (the PTR RR and possibly the A RR based on the
"S" bit) or to 1 to request that the server SHOULD NOT perform any "S" bit) or to 1 to request that the server SHOULD NOT perform any
DNS updates. A server sets the "N" bit to indicate whether it SHALL DNS updates. A server sets the "N" bit to indicate whether the
(0) or SHALL NOT (1) perform DNS updates. If the "N" bit is 1, the server SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N"
"S" bit MUST be 0. bit is 1, the "S" bit MUST be 0.
The "E" bit indicates the encoding of the Domain Name field. 1 The "E" bit indicates the encoding of the Domain Name field. 1
indicates DNS-style binary encoding, without compression, as indicates DNS-style binary encoding, without compression, as
described in RFC 1035 [3] and SHOULD be used by clients. 0 indicates described in RFC 1035 [3]. This encoding SHOULD be used by clients
a now deprecated ASCII encoding. Servers MUST use the same encoding and MUST be supported by servers. 0 indicates a now deprecated ASCII
as received from the client. Server implementers SHOULD note that encoding (see Section 3.3.1). A server MUST use the same encoding as
earlier draft versions of this specification permitted an ASCII that used by the client. A server that does not support the
encoding of the domain name and this encoding MUST be used if the "E" deprecated ASCII encoding MUST ignore Client FQDN options that use
bit is 0. Clients which implemented this encoding were deployed that encoding.
before this specification was completed. Server implementers which
need to support these clients need to see the section on the
deprecated ASCII encoding (Section 3.3.1).
The remaining bits in the Flags field are reserved for future The remaining bits in the Flags field are reserved for future
assignment. DHCP clients and servers which send the Client FQDN assignment. DHCP clients and servers which send the Client FQDN
option MUST clear the MBZ bits, and they MUST ignore these bits. option MUST clear the MBZ bits, and they MUST ignore these bits.
3.2 The RCODE Fields 3.2 The RCODE Fields
The RCODE1 and RCODE2 fields are deprecated. A client SHOULD set The RCODE1 and RCODE2 fields are deprecated. A client SHOULD set
these to 0 when sending the option and SHOULD ignore them on receipt. these to 0 when sending the option and SHOULD ignore them on receipt.
A server SHOULD set these to 255 when sending the option and MUST A server SHOULD set these to 255 when sending the option and MUST
skipping to change at page 7, line 15 skipping to change at page 7, line 13
To send a fully-qualified domain name, the Domain Name field is set To send a fully-qualified domain name, the Domain Name field is set
to the DNS encoded domain name including the terminating zero-length to the DNS encoded domain name including the terminating zero-length
label. To send a partial name, the Domain Name field is set to the label. To send a partial name, the Domain Name field is set to the
DNS encoded domain name without the terminating zero-length label. DNS encoded domain name without the terminating zero-length label.
A client MAY also leave the Domain Name field empty if it desires the A client MAY also leave the Domain Name field empty if it desires the
server to provide a name. server to provide a name.
3.3.1 Deprecated ASCII Encoding 3.3.1 Deprecated ASCII Encoding
The DNS encoding specified above MUST be supported by DHCP servers. A substantial population of clients implemented an earlier draft
However, a substantial population of clients implemented an earlier version of this specification, which permitted an ASCII encoding of
draft version of this specification, which permitted an ASCII the Domain Name field. Server implementations SHOULD be aware that
encoding of the Domain Name field. Server implementations SHOULD be clients which send the Client FQDN option with the "E" bit set to 0
aware that clients which send the Client FQDN option with the "E" bit are using an ASCII encoding of the Domain Name field. Servers MAY be
set to 0 are using an ASCII encoding of the Domain Name field. prepared to return an ASCII encoded version of the Domain Name field
Servers MAY be prepared to return an ASCII encoded version of the to such clients. Servers that are not prepared to return an ASCII
Domain Name field to such clients. Servers that are not prepared to encoded version MUST ignore the Client FQDN option if the "E" bit is
return an ASCII encoded version MUST ignore the Client FQDN option if 0. The use of ASCII encoding in this option SHOULD be considered
the "E" bit is 0. The use of ASCII encoding in this option SHOULD be deprecated.
considered deprecated.
A DHCP client which used ASCII encoding was permitted to suggest a A DHCP client which used ASCII encoding was permitted to suggest a
single label if it was not configured with a fully-qualified name. single label if it was not configured with a fully-qualified name.
Such clients send a single label as a series of ASCII characters in Such clients send a single label as a series of ASCII characters in
the Domain Name field, excluding the "." (dot) character. Such the Domain Name field, excluding the "." (dot) character.
clients SHOULD follow the character-set recommendations of RFC 1034
[2] and RFC 1035 [3].
Server implementers SHOULD also be aware that some client software Clients and servers SHOULD follow the character-set recommendations
could be using UTF-8 [9] character encoding. This information is of RFC 1034 [2] and RFC 1035 [3]. However, implementers SHOULD also
included for informational purposes only; this specification does not be aware that some client software could be using UTF-8 [9] character
require any support for UTF-8. encoding. This specification does not require any support for UTF-8.
4. DHCP Client Behavior 4. DHCP Client Behavior
The following describes the behavior of a DHCP client that implements The following describes the behavior of a DHCP client that implements
the Client FQDN option. the Client FQDN option.
4.1 Interaction With Other Options 4.1 Interaction With Other Options
Other DHCP options MAY carry data that is related to the Domain Name Other DHCP options MAY carry data that is related to the Domain Name
field of the Client FQDN option. The Host Name option [8], for field of the Client FQDN option. The Host Name option [8], for
skipping to change at page 13, line 26 skipping to change at page 13, line 20
Lewis, Michael Lewis, Josh Littlefield, Michael Patton, Jyrki Soini, Lewis, Michael Lewis, Josh Littlefield, Michael Patton, Jyrki Soini,
and Glenn Stump for their review and comments. and Glenn Stump for their review and comments.
10. References 10. References
10.1 Normative References 10.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", STD [2] Mockapetris, P., "Domain names - concepts and facilities",
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.
[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., "Dynamic Host Configuration Protocol", RFC 2131, [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
skipping to change at page 14, line 5 skipping to change at page 13, line 46
10.2 Informative References 10.2 Informative References
[7] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and [7] 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.
[8] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [8] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[9] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [9] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
2279, January 1998. RFC 2279, January 1998.
[10] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [10] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. August 1999.
[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] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", [12] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001. RFC 3118, June 2001.
[13] Lemon, T. and S. Cheshire, "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
November 2002.
Authors' Addresses Authors' Addresses
Mark Stapp Mark Stapp
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: 978.936.1535 Phone: 978.936.1535
EMail: mjs@cisco.com Email: mjs@cisco.com
Bernie Volz Bernie Volz
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: 978.936.0382 Phone: 978.936.0382
EMail: volz@cisco.com Email: volz@cisco.com
Yakov Rekhter Yakov Rekhter
Juniper Networks Juniper Networks
1194 North Mathilda Avenue 1194 North Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Phone: 408.745.2000 Phone: 408.745.2000
EMail: yakov@juniper.net Email: yakov@juniper.net
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
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 (2004). This document is subject Copyright (C) The Internet Society (2005). 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. 

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