-DNSEXT M. Stapp
-Internet-Draft Cisco Systems, Inc.
-Expires: September 1, 2006 T. Lemon
+
+
+Network Working Group M. Stapp
+Request for Comments: 4701 Cisco Systems, Inc.
+Category: Standards Track T. Lemon
Nominum, Inc.
A. Gustafsson
Araneus Information Systems Oy
- February 28, 2006
+ October 2006
- A DNS RR for Encoding DHCP Information (DHCID RR)
- <draft-ietf-dnsext-dhcid-rr-12.txt>
+ A DNS Resource Record (RR) for Encoding
+ Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
-Status of this Memo
+Status of This Memo
- By submitting this Internet-Draft, each 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 becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
+Copyright Notice
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
+ Copyright (C) The Internet Society (2006).
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
+Abstract
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
+ It is possible for Dynamic Host Configuration Protocol (DHCP) clients
+ to attempt to update the same DNS Fully Qualified Domain Name (FQDN)
+ or to update a DNS FQDN that has been added to the DNS for another
+ purpose as they obtain DHCP leases. Whether the DHCP server or the
+ clients themselves perform the DNS updates, conflicts can arise. To
+ resolve such conflicts, RFC 4703 proposes storing client identifiers
+ in the DNS to unambiguously associate domain names with the DHCP
+ clients to which they refer. This memo defines a distinct Resource
+ Record (RR) type for this purpose for use by DHCP clients and
+ servers: the "DHCID" RR.
- This Internet-Draft will expire on September 1, 2006.
-Copyright Notice
- Copyright (C) The Internet Society (2006).
-Abstract
- It is possible for DHCP clients to attempt to update the same DNS
- FQDN or attempt to update a DNS FQDN that has been added to the DNS
- for another purpose as they obtain DHCP leases. Whether the DHCP
- server or the clients themselves perform the DNS updates, conflicts
- can arise. To resolve such conflicts, "Resolution of DNS Name
-Stapp, et al. Expires September 1, 2006 [Page 1]
-\f
-Internet-Draft The DHCID RR February 2006
- Conflicts" [1] proposes storing client identifiers in the DNS to
- unambiguously 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 clients and servers, the "DHCID" RR.
+
+
+
+
+
+Stapp, et al. Standards Track [Page 1]
+\f
+RFC 4701 The DHCID RR October 2006
Table of Contents
- 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.1. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 3
- 3.2. DHCID Presentation Format . . . . . . . . . . . . . . . . 4
- 3.3. The DHCID RR Identifier Type Codes . . . . . . . . . . . . 4
- 3.4. The DHCID RR Digest Type Code . . . . . . . . . . . . . . 4
- 3.5. Computation of the RDATA . . . . . . . . . . . . . . . . . 5
- 3.5.1. Using the Client's DUID . . . . . . . . . . . . . . . 5
- 3.5.2. Using the Client Identifier Option . . . . . . . . . . 5
- 3.5.3. Using the Client's htype and chaddr . . . . . . . . . 6
- 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 6
- 3.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 6
- 3.6.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 7
- 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 7
- 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 8
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
- Intellectual Property and Copyright Statements . . . . . . . . . . 12
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................3
+ 3. The DHCID RR ....................................................3
+ 3.1. DHCID RDATA Format .........................................3
+ 3.2. DHCID Presentation Format ..................................4
+ 3.3. The DHCID RR Identifier Type Codes .........................4
+ 3.4. The DHCID RR Digest Type Code ..............................4
+ 3.5. Computation of the RDATA ...................................5
+ 3.5.1. Using the Client's DUID .............................5
+ 3.5.2. Using the Client Identifier Option ..................6
+ 3.5.3. Using the Client's htype and chaddr .................6
+ 3.6. Examples ...................................................6
+ 3.6.1. Example 1 ...........................................6
+ 3.6.2. Example 2 ...........................................7
+ 3.6.3. Example 3 ...........................................7
+ 4. Use of the DHCID RR .............................................8
+ 5. Updater Behavior ................................................8
+ 6. Security Considerations .........................................8
+ 7. IANA Considerations .............................................9
+ 8. Acknowledgements ................................................9
+ 9. References ......................................................9
+ 9.1. Normative References .......................................9
+ 9.2. Informative References ....................................10
+
+
-Stapp, et al. Expires September 1, 2006 [Page 2]
-\f
-Internet-Draft The DHCID RR February 2006
-1. Terminology
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [2].
-2. Introduction
- A set of procedures to allow DHCP [6] [10] clients and servers to
- automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
- in "Resolution of DNS Name Conflicts" [1].
+Stapp, et al. Standards Track [Page 2]
+\f
+RFC 4701 The DHCID RR October 2006
+
+
+1. Introduction
+
+ A set of procedures to allow DHCP [7] [11] clients and servers to
+ automatically update the DNS ([3], [4]) is proposed in [1].
Conflicts can arise if multiple DHCP clients wish to use the same DNS
name or a DHCP client attempts to use a name added for another
- purpose. To resolve such conflicts, "Resolution of DNS Name
- Conflicts" [1] proposes storing client identifiers in the DNS to
- unambiguously associate domain names with the DHCP clients using
- them. In the interest of clarity, it is preferable for this DHCP
- information to use a distinct RR type. This memo defines a distinct
- RR for this purpose for use by DHCP clients or servers, the "DHCID"
- RR.
+ purpose. To resolve such conflicts, [1] proposes storing client
+ identifiers in the DNS to unambiguously associate domain names with
+ the DHCP clients using them. In the interest of clarity, it is
+ preferable for this DHCP information to use a distinct RR type. This
+ memo defines a distinct RR for this purpose for use by DHCP clients
+ or servers: the "DHCID" RR.
In order to obscure potentially sensitive client identifying
information, the data stored is the result of a one-way SHA-256 hash
time with more than one name. This makes it difficult to 'track' a
client as it is associated with various domain names.
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [2].
3. The DHCID RR
- The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The
+ The DHCID RR is defined with mnemonic DHCID and type code 49. The
DHCID RR is only defined in the IN class. DHCID RRs cause no
- additional section processing. The DHCID RR is not a singleton type.
+ additional section processing.
-3.1. DHCID RDATA format
+3.1. DHCID RDATA Format
The RDATA section of a DHCID RR in transmission contains RDLENGTH
octets of binary data. The format of this data and its
DNS software should consider the RDATA section to be opaque. DHCP
clients or servers use the DHCID RR to associate a DHCP client's
+ identity with a DNS name, so that multiple DHCP clients and servers
+ may deterministically perform dynamic DNS updates to the same zone.
+ From the updater's perspective, the DHCID resource record RDATA
+ consists of a 2-octet identifier type, in network byte order,
-Stapp, et al. Expires September 1, 2006 [Page 3]
+Stapp, et al. Standards Track [Page 3]
\f
-Internet-Draft The DHCID RR February 2006
+RFC 4701 The DHCID RR October 2006
- identity with a DNS name, so that multiple DHCP clients and servers
- may deterministically perform dynamic DNS updates to the same zone.
- From the updater's perspective, the DHCID resource record RDATA
- consists of a 2-octet identifier type, in network byte order,
followed by a 1-octet digest type, followed by one or more octets
representing the actual identifier:
3.2. DHCID Presentation Format
In DNS master files, the RDATA is represented as a single block in
- base 64 encoding identical to that used for representing binary data
- in RFC 3548 [7]. The data may be divided up into any number of white
- space separated substrings, down to single base 64 digits, which are
- concatenated to form the complete RDATA. These substrings can span
- lines using the standard parentheses.
+ base-64 encoding identical to that used for representing binary data
+ in [8], Section 3. The data may be divided up into any number of
+ white-space-separated substrings, down to single base-64 digits,
+ which are concatenated to form the complete RDATA. These substrings
+ can span lines using the standard parentheses.
3.3. The DHCID RR Identifier Type Codes
client's request was used as input into the hash function. The
identifier type codes are defined in a registry maintained by IANA,
as specified in Section 7. The initial list of assigned values for
- the identifier type code is:
-
- 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [6].
- 0x0001 = The data octets (i.e., the Type and Client-Identifier
- fields) from a DHCPv4 client's Client Identifier option [9].
- 0x0002 = The client's DUID (i.e., the data octets of a DHCPv6
- client's Client Identifier option [10] or the DUID field from a
- DHCPv4 client's Client Identifier option [12]).
-
- 0x0003 - 0xfffe = Available to be assigned by IANA.
-
- 0xffff = RESERVED
+ the identifier type code and that type's identifier is:
+
+
+ +------------------+------------------------------------------------+
+ | Identifier Type | Identifier |
+ | Code | |
+ +------------------+------------------------------------------------+
+ | 0x0000 | The 1-octet 'htype' followed by 'hlen' octets |
+ | | of 'chaddr' from a DHCPv4 client's DHCPREQUEST |
+ | | [7]. |
+ | 0x0001 | The data octets (i.e., the Type and |
+ | | Client-Identifier fields) from a DHCPv4 |
+ | | client's Client Identifier option [10]. |
+ | 0x0002 | The client's DUID (i.e., the data octets of a |
+ | | DHCPv6 client's Client Identifier option [11] |
+ | | or the DUID field from a DHCPv4 client's |
+ | | Client Identifier option [6]). |
+ | 0x0003 - 0xfffe | Undefined; available to be assigned by IANA. |
+ | 0xffff | Undefined; RESERVED. |
+ +------------------+------------------------------------------------+
3.4. The DHCID RR Digest Type Code
algorithm used. The digest is calculated over an identifier and the
canonical FQDN as described in the next section.
- The digest type codes are defined in a registry maintained by IANA,
- as specified in Section 7. The initial list of assigned values for
- the digest type codes is: value 0 is reserved and value 1 is SHA-256.
-
-Stapp, et al. Expires September 1, 2006 [Page 4]
+Stapp, et al. Standards Track [Page 4]
\f
-Internet-Draft The DHCID RR February 2006
+RFC 4701 The DHCID RR October 2006
- Reserving other types requires IETF standards action. Defining new
- values will also require IETF standards action to document how DNS
- updaters are to deal with multiple digest types.
+ The digest type codes are defined in a registry maintained by IANA,
+ as specified in Section 7. The initial list of assigned values for
+ the digest type codes is: value 0 is reserved, and value 1 is
+ SHA-256. Reserving other types requires IETF standards action.
+ Defining new values will also require IETF standards action to
+ document how DNS updaters are to deal with multiple digest types.
3.5. Computation of the RDATA
digest = SHA-256(< identifier > < FQDN >)
- The FQDN is represented in the buffer in unambiguous canonical form
- as described in RFC 4034 [8], section 6.1. The identifier type code
- and the identifier are related as specified in Section 3.3: the
- identifier type code describes the source of the identifier.
+ The FQDN is represented in the buffer in the canonical wire format as
+ described in [9], Section 6.2. The identifier type code and the
+ identifier are related as specified in Section 3.3: the identifier
+ type code describes the source of the identifier.
A DHCPv4 updater uses the 0x0002 type code if a Client Identifier
option is present in the DHCPv4 messages and it is encoded as
- specified in [12]. Otherwise, the updater uses 0x0001 if a Client
- Identifier option is present and 0x0000 if not.
+ specified in [6]. Otherwise, the updater uses 0x0001 if a Client
+ Identifier option is present, and 0x0000 if not.
A DHCPv6 updater always uses the 0x0002 type code.
When the updater is using the Client's DUID (either from a DHCPv6
Client Identifier option or from a portion of the DHCPv4 Client
- Identifier option encoded as specified in [12]), the first two octets
+ Identifier option encoded as specified in [6]), the first two octets
of the DHCID RR MUST be 0x0002, in network byte order. The third
octet is the digest type code (1 for SHA-256). The rest of the DHCID
RR MUST contain the results of computing the SHA-256 hash across the
octets of the DUID followed by the FQDN.
-3.5.2. Using the Client Identifier Option
- When the updater is using the DHCPv4 Client Identifier option sent by
- the client in its DHCPREQUEST message, the first two octets of the
- DHCID RR MUST be 0x0001, in network byte order. The third octet is
- the digest type code (1 for SHA-256). The rest of the DHCID RR MUST
-Stapp, et al. Expires September 1, 2006 [Page 5]
+
+
+Stapp, et al. Standards Track [Page 5]
\f
-Internet-Draft The DHCID RR February 2006
+RFC 4701 The DHCID RR October 2006
+
+3.5.2. Using the Client Identifier Option
+ When the updater is using the DHCPv4 Client Identifier option sent by
+ the client in its DHCPREQUEST message, the first two octets of the
+ DHCID RR MUST be 0x0001, in network byte order. The third octet is
+ the digest type code (1 for SHA-256). The rest of the DHCID RR MUST
contain the results of computing the SHA-256 hash across the data
octets (i.e., the Type and Client-Identifier fields) of the option,
followed by the FQDN.
3.6.1. Example 1
- 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
- "client.example.com" uses the client's link-layer address to identify
- the client. The DHCID RDATA is composed by setting the two type
- octets to zero, the 1-octet digest type to 1 for SHA-256, and
- performing an SHA-256 hash computation across a buffer containing the
- Ethernet MAC type octet, 0x01, the six octets of MAC address, and the
- domain name (represented as specified in Section 3.5).
+ A DHCP server allocates the IPv6 address 2001:DB8::1234:5678 to a
+ client that included the DHCPv6 client-identifier option data 00:01:
+ 00:06:41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request. The
+ server updates the name "chi6.example.com" 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 setting the two type octets
+ to the value 0x0002, the 1-octet digest type to 1 for SHA-256, and
+ performing a SHA-256 hash computation across a buffer containing the
+ 14 octets from the client-id option and the FQDN (represented as
+ specified in Section 3.5).
- client.example.com. A 10.0.0.1
- client.example.com. DHCID ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
- ytcKD//7es/deY= )
+ chi6.example.com. AAAA 2001:DB8::1234:5678
+ chi6.example.com. DHCID ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
+ OjxfNuVAA2kjEA= )
If the DHCID RR type is not supported, the RDATA would be encoded
[13] as:
- \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
- fffedeb3f75e6 )
-
-3.6.2. Example 2
- 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
+Stapp, et al. Standards Track [Page 6]
+\f
+RFC 4701 The DHCID RR October 2006
-Stapp, et al. Expires September 1, 2006 [Page 6]
-\f
-Internet-Draft The DHCID RR February 2006
+ \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
+ b95000da48c40 )
+3.6.2. Example 2
+ A DHCP server allocates the IPv4 address 192.0.2.2 to a client that
+ 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"
- 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
setting the two type octets to the value 0x0001, the 1-octet digest
type to 1 for SHA-256, and performing a SHA-256 hash computation
across a buffer containing the seven octets from the client-id option
and the FQDN (represented as specified in Section 3.5).
- chi.example.com. A 10.0.12.99
+ chi.example.com. A 192.0.2.2
chi.example.com. DHCID ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
L3b/NaiUDlW2No= )
3.6.3. Example 3
- A DHCP server allocates the IPv6 address 2000::1234:5678 to a client
- which included the DHCPv6 client-identifier option data 00:01:00:06:
- 41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request. The server
- updates the name "chi6.example.com" 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 setting the two type octets to the
- value 0x0002, the 1-octet digest type to 1 for SHA-256, and
- performing a SHA-256 hash computation across a buffer containing the
- 14 octets from the client-id option and the FQDN (represented as
+ A DHCP server allocating the IPv4 address 192.0.2.3 to a client with
+ the Ethernet MAC address 01:02:03:04:05:06 using domain name
+ "client.example.com" uses the client's link-layer address to identify
+ the client. The DHCID RDATA is composed by setting the two type
+ octets to zero, the 1-octet digest type to 1 for SHA-256, and
+ performing an SHA-256 hash computation across a buffer containing the
+ 1-octet 'htype' value for Ethernet, 0x01, followed by the six octets
+ of the Ethernet MAC address, and the domain name (represented as
specified in Section 3.5).
- chi6.example.com. AAAA 2000::1234:5678
- chi6.example.com. DHCID ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
- OjxfNuVAA2kjEA= )
+ client.example.com. A 192.0.2.3
+ client.example.com. DHCID ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
+ ytcKD//7es/deY= )
If the DHCID RR type is not supported, the RDATA would be encoded
[13] as:
- \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
- b95000da48c40 )
+ \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
+ fffedeb3f75e6 )
-4. Use of the DHCID RR
- This RR MUST NOT be used for any purpose other than that detailed in
- "Resolution of DNS Name Conflicts" [1]. Although this RR contains
- data that is opaque to DNS servers, the data must be consistent
- across all entities that update and interpret this record.
-
-Stapp, et al. Expires September 1, 2006 [Page 7]
+Stapp, et al. Standards Track [Page 7]
\f
-Internet-Draft The DHCID RR February 2006
+RFC 4701 The DHCID RR October 2006
- Therefore, new data formats may only be defined through actions of
- the DHC Working Group, as a result of revising [1].
+4. Use of the DHCID RR
+ This RR MUST NOT be used for any purpose other than that detailed in
+ [1]. Although this RR contains data that is opaque to DNS servers,
+ the data must be consistent across all entities that update and
+ interpret this record. Therefore, new data formats may only be
+ defined through actions of the DHC Working Group, as a result of
+ revising [1].
5. Updater Behavior
policy. That policy might dictate that a different name be selected,
or it might permit the updater to continue.
-
6. Security Considerations
The DHCID record as such does not introduce any new security problems
into the DNS. In order to obscure the client's identity information,
- a one-way hash is used. And, in order to make it difficult to
+ a one-way hash is used. Further, in order to make it difficult to
'track' a client by examining the names associated with a particular
hash value, the FQDN is included in the hash computation. Thus, the
RDATA is dependent on both the DHCP client identification data and on
Administrators should be wary of permitting unsecured DNS updates to
zones, whether or not they are exposed to the global Internet. Both
DHCP clients and servers SHOULD use some form of update
- authentication (e.g., TSIG [11]) when performing DNS updates.
-
-
-7. IANA Considerations
-
+ authentication (e.g., [12]) when performing DNS updates.
-Stapp, et al. Expires September 1, 2006 [Page 8]
+Stapp, et al. Standards Track [Page 8]
\f
-Internet-Draft The DHCID RR February 2006
+RFC 4701 The DHCID RR October 2006
- IANA is requested to allocate a DNS RR type number for the DHCID
- record type.
+7. IANA Considerations
+
+ IANA has allocated a DNS RR type number for the DHCID record type.
This specification defines a new number-space for the 2-octet
- identifier type codes associated with the DHCID RR. IANA is
- requested to establish a registry of the values for this number-
- space. Three initial values are assigned in Section 3.3, and the
- value 0xFFFF is reserved for future use. New DHCID RR identifier
- type codes are assigned through Standards Action, as defined in RFC
- 2434 [5].
+ identifier type codes associated with the DHCID RR. IANA has
+ established a registry of the values for this number-space. Three
+ initial values are assigned in Section 3.3, and the value 0xFFFF is
+ reserved for future use. New DHCID RR identifier type codes are
+ assigned through Standards Action, as defined in [5].
This specification defines a new number-space for the 1-octet digest
- type codes associated with the DHCID RR. IANA is requested to
- establish a registry of the values for this number-space. Two
- initial values are assigned in Section 3.4. New DHCID RR digest type
- codes are assigned through Standards Action, as defined in RFC 2434
- [5].
-
+ type codes associated with the DHCID RR. IANA has established a
+ registry of the values for this number-space. Two initial values are
+ assigned in Section 3.4. New DHCID RR digest type codes are assigned
+ through Standards Action, as defined in [5].
8. Acknowledgements
Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie
Volz for their review and suggestions.
-
9. References
9.1. Normative References
- [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
- DHCP Clients (draft-ietf-dhc-dns-resolution-*)", February 2006.
+ [1] Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain
+ Name (FQDN) Conflicts among Dynamic Host Configuration Protocol
+ (DHCP) Clients", RFC 4703, October 2006.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+ [6] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
+ for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
+ RFC 4361, February 2006.
-
-Stapp, et al. Expires September 1, 2006 [Page 9]
+Stapp, et al. Standards Track [Page 9]
\f
-Internet-Draft The DHCID RR February 2006
+RFC 4701 The DHCID RR October 2006
9.2. Informative References
- [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
- [7] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+ [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
- [8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
- [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+ [10] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
- [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
+ [11] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
- [11] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
+ [12] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000.
- [12] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
- for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
- RFC 4361, February 2006.
-
[13] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
Types", RFC 3597, September 2003.
-Stapp, et al. Expires September 1, 2006 [Page 10]
+
+
+
+
+Stapp, et al. Standards Track [Page 10]
\f
-Internet-Draft The DHCID RR February 2006
+RFC 4701 The DHCID RR October 2006
Authors' Addresses
USA
Phone: 978.936.1535
- Email: mjs@cisco.com
+ EMail: mjs@cisco.com
Ted Lemon
Redwood City, CA 94063
USA
- Email: mellon@nominum.com
+ EMail: mellon@nominum.com
Andreas Gustafsson
02320 Espoo
Finland
- Email: gson@araneus.fi
+ EMail: gson@araneus.fi
-Stapp, et al. Expires September 1, 2006 [Page 11]
+Stapp, et al. Standards Track [Page 11]
\f
-Internet-Draft The DHCID RR February 2006
+RFC 4701 The DHCID RR October 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-Intellectual Property Statement
+Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
+Acknowledgement
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
-Copyright Statement
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-Acknowledgment
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 12]
+Stapp, et al. Standards Track [Page 12]
\f
-
projects / thirdparty / bind9.git / commitdiff
