draft-ietf-dnsext-dhcid-rr-08.txt   draft-ietf-dnsext-dhcid-rr-09.txt 
DNSEXT M. Stapp DNSEXT M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: January 14, 2005 T. Lemon Expires: August 13, 2005 T. Lemon
A. Gustafsson A. Gustafsson
Nominum, Inc. Nominum, Inc.
July 16, 2004 February 9, 2005
A DNS RR for Encoding DHCP Information (DHCID RR) A DNS RR for Encoding DHCP Information (DHCID RR)
<draft-ietf-dnsext-dhcid-rr-08.txt> <draft-ietf-dnsext-dhcid-rr-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.
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 http:// The list of current Internet-Drafts can be accessed at
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 January 14, 2005. This Internet-Draft will expire on August 13, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
It is possible for multiple DHCP clients to attempt to update the It is possible for multiple DHCP clients to attempt to update the
same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
the clients themselves perform the DNS updates, conflicts can arise. the clients themselves perform the DNS updates, conflicts can arise.
To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
proposes storing client identifiers in the DNS to unambiguously proposes storing client identifiers in the DNS to unambiguously
associate domain names with the DHCP clients to which they refer. associate domain names with the DHCP clients to which they refer.
This memo defines a distinct RR type for this purpose for use by DHCP This memo defines a distinct RR type for this purpose for use by DHCP
skipping to change at page 2, line 26 skipping to change at page 2, line 27
3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . 4 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . 4
3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 6 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 6
3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 6 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 6
4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 6 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 6
5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8
9.2 Informative References . . . . . . . . . . . . . . . . . . . 8 9.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 10
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 [2]. document are to be interpreted as described in RFC 2119 [2].
2. Introduction 2. Introduction
skipping to change at page 6, line 13 skipping to change at page 6, line 13
3.5 Examples 3.5 Examples
3.5.1 Example 1 3.5.1 Example 1
A DHCP server allocating the IPv4 address 10.0.0.1 to a client with A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
Ethernet MAC address 01:02:03:04:05:06 using domain name Ethernet MAC address 01:02:03:04:05:06 using domain name
"client.example.com" uses the client's link-layer address to identify "client.example.com" uses the client's link-layer address to identify
the client. The DHCID RDATA is composed by setting the two type the client. The DHCID RDATA is composed by setting the two type
bytes to zero, and performing an MD5 hash computation across a buffer bytes to zero, and performing an MD5 hash computation across a buffer
containing the Ethernet MAC type byte, 0x01, the six bytes of MAC containing the Ethernet MAC type byte, 0x01, the six bytes of MAC
address, and the domain name (represented as specified in Section address, and the domain name (represented as specified in
3.4). Section 3.4).
client.example.com. A 10.0.0.1 client.example.com. A 10.0.0.1
client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU
3.5.2 Example 2 3.5.2 Example 2
A DHCP server allocates the IPv4 address 10.0.12.99 to a client which A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
in its DHCP request. The server updates the name "chi.example.com" in its DHCP request. The server updates the name "chi.example.com"
on the client's behalf, and uses the DHCP client identifier option on the client's behalf, and uses the DHCP client identifier option
data as input in forming a DHCID RR. The DHCID RDATA is formed by data as input in forming a DHCID RR. The DHCID RDATA is formed by
setting the two type bytes to the value 0x0001, and performing an MD5 setting the two type bytes to the value 0x0001, and performing an MD5
hash computation across a buffer containing the seven bytes from the hash computation across a buffer containing the seven bytes from the
client-id option and the FQDN (represented as specified in Section client-id option and the FQDN (represented as specified in
3.4). Section 3.4).
chi.example.com. A 10.0.12.99 chi.example.com. A 10.0.12.99
chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012 chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012
4. Use of the DHCID RR 4. Use of the DHCID RR
This RR MUST NOT be used for any purpose other than that detailed in This RR MUST NOT be used for any purpose other than that detailed in
"Resolution of DNS Name Conflicts" [1]. Although this RR contains "Resolution of DNS Name Conflicts" [1]. Although this RR contains
data that is opaque to DNS servers, the data must be consistent data that is opaque to DNS servers, the data must be consistent
across all entities that update and interpret this record. across all entities that update and interpret this record.
skipping to change at page 8, line 15 skipping to change at page 8, line 15
9. References 9. References
9.1 Normative References 9.1 Normative References
[1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004. DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] 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.
[3] Mockapetris, P., "Domain names - concepts and facilities", STD [3] Mockapetris, P., "Domain names - concepts and facilities",
13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[4] Mockapetris, P., "Domain names - implementation and [4] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992. 1992.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
9.2 Informative References 9.2 Informative References
[7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[8] Eastlake, D., "Domain Name System Security Extensions", RFC [8] Eastlake, D., "Domain Name System Security Extensions",
2535, March 1999. RFC 2535, March 1999.
[9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC "Secret Key Transaction Authentication for DNS (TSIG)",
2845, May 2000. RFC 2845, May 2000.
[12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers [12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers
for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004. for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004.
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
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
950 Charter St. 950 Charter St.
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
EMail: mellon@nominum.com Email: mellon@nominum.com
Andreas Gustafsson Andreas Gustafsson
Nominum, Inc. Nominum, Inc.
950 Charter St. 950 Charter St.
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
EMail: gson@nominum.com Email: gson@nominum.com
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 10, line 41 skipping to change at page 10, 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/