idnits 2.17.1 draft-ietf-dhc-ddns-resolution-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 557. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 24, 2006) is 6629 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-dnsext-dhcid-rr- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 3315 (ref. '5') (Obsoleted by RFC 8415) -- No information found for draft-ietf-dhc-fqdn-option- - is the name correct? -- No information found for draft-ietf-dhc-dhcpv6-fqdn- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '11') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '14') (Obsoleted by RFC 8945) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration M. Stapp 3 Internet-Draft B. Volz 4 Expires: August 28, 2006 Cisco Systems, Inc. 5 February 24, 2006 7 Resolution of FQDN Conflicts among DHCP Clients 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 28, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 DHCP provides a mechanism for host configuration that includes 42 dynamic assignment of IP addresses and fully qualified domain names. 43 To maintain accurate name to IP address and IP address to name 44 mappings in the DNS, these dynamically assigned addresses and fully 45 qualified domain names require updates to the DNS. This document 46 identifies situations in which conflicts in the use of fully 47 qualified domain names may arise among DHCP clients and servers, and 48 describes a strategy for the use of the DHCID DNS resource record in 49 resolving those conflicts. 51 Table of Contents 53 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Issues with DNS Update in DHCP Environments . . . . . . . . . 3 56 3.1. Client Misconfiguration . . . . . . . . . . . . . . . . . 4 57 3.2. Multiple DHCP Servers . . . . . . . . . . . . . . . . . . 5 58 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 5 59 5. Procedures for Performing DNS Updates . . . . . . . . . . . . 6 60 5.1. Error Return Codes . . . . . . . . . . . . . . . . . . . . 6 61 5.2. Dual IPv4/IPv6 Client Considerations . . . . . . . . . . . 6 62 5.3. Adding A and/or AAAA RRs to DNS . . . . . . . . . . . . . 7 63 5.3.1. Initial DHCID RR Query . . . . . . . . . . . . . . . . 7 64 5.3.2. DNS UPDATE When FQDN in Use . . . . . . . . . . . . . 7 65 5.3.3. FQDN in Use by another Client . . . . . . . . . . . . 8 66 5.4. Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . 8 67 5.5. Removing Entries from DNS . . . . . . . . . . . . . . . . 9 68 5.6. Updating Other RRs . . . . . . . . . . . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 75 Intellectual Property and Copyright Statements . . . . . . . . . . 14 77 1. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [1]. 83 This document assumes familiarity with DNS terminology defined in RFC 84 1035 [6] and DHCP terminology defined in RFC 2131 [4] and RFC 3315 85 [5]. 87 FQDN, or Fully Qualified Domain Name, is the full name of a system, 88 rather than just its hostname. For example, "venera" is a hostname 89 and "venera.isi.edu" is an FQDN. See RFC 1983 [7]. 91 DOCSIS, or Data-Over-Cable Service Interface Specifications, is 92 defined by CableLabs (www.cablelabs.com). 94 2. Introduction 96 "The Client FQDN Option" [8] includes a description of the operation 97 of DHCPv4 [4] clients and servers that use the DHCPv4 client FQDN 98 option. And, "The DHCPv6 Client FQDN Option" [9] includes a 99 description of the operation of DHCPv6 [5] clients and servers that 100 use the DHCPv6 client FQDN option. Through the use of the client 101 FQDN option, DHCP clients and servers can negotiate the client's FQDN 102 and the allocation of responsibility for updating the DHCP client's A 103 and/or AAAA RRs. This document identifies situations in which 104 conflicts in the use of FQDNs may arise among DHCP clients and 105 servers, and describes a strategy for the use of the DHCID DNS 106 resource record [2] in resolving those conflicts. 108 In any case, whether a site permits all, some, or no DHCP servers and 109 clients to perform DNS updates (RFC 2136 [3], RFC 3007 [10]) into the 110 zones that it controls is entirely a matter of local administrative 111 policy. This document does not require any specific administrative 112 policy, and does not propose one. The range of possible policies is 113 very broad, from sites where only the DHCP servers have been given 114 credentials that the DNS servers will accept, to sites where each 115 individual DHCP client has been configured with credentials that 116 allow the client to modify its own FQDN. Compliant implementations 117 MAY support some or all of these possibilities. Furthermore, this 118 specification applies only to DHCP client and server processes; it 119 does not apply to other processes that initiate DNS updates. 121 3. Issues with DNS Update in DHCP Environments 122 There are two DNS update situations that require special 123 consideration in DHCP environments: cases where more than one DHCP 124 client has been configured with the same FQDN and cases where more 125 than one DHCP server has been given authority to perform DNS updates 126 in a zone. In these cases, it is possible for DNS records to be 127 modified in inconsistent ways unless the updaters have a mechanism 128 that allows them to detect anomalous situations. If DNS updaters can 129 detect these situations, site administrators can configure the 130 updaters' behavior so that the site's policies can be enforced. This 131 specification describes a mechanism designed to allow updaters to 132 detect these situations, and suggests that DHCP implementations use 133 this mechanism by default. 135 3.1. Client Misconfiguration 137 Administrators may wish to maintain a one-to-one relationship between 138 active DHCP clients and FQDNs, and to maintain consistency between a 139 client's A, AAAA, and PTR RRs. Clients that are not represented in 140 the DNS, or clients that inadvertently share an FQDN with another 141 client may encounter inconsistent behavior or may not be able to 142 obtain access to network resources. Whether each DHCP client is 143 configured with a FQDN by its administrator or whether the DHCP 144 server is configured to distribute the clients' FQDN, the consistency 145 of the DNS data is entirely dependent on the accuracy of the 146 configuration procedure. Sites that deploy Secure DNS [11] may 147 configure credentials for each client and its assigned FQDN in a way 148 that is more error-resistant, as both the FQDN and credentials must 149 match. 151 Consider an example in which two DHCP clients in the "example.com" 152 network are both configured with the hostname "foo". The clients are 153 permitted to perform their own DNS updates. The first client, client 154 A, is configured via DHCP. It adds an A RR to "foo.example.com", and 155 its DHCP server adds a PTR RR corresponding to its assigned IP 156 address. When the second client, client B, boots, it is also 157 configured via DHCP, and it also begins to update "foo.example.com". 159 At this point, the "example.com" administrators may wish to establish 160 some policy about DHCP clients' FQDNs. If the policy is that each 161 client that boots should replace any existing A RR that matches its 162 FQDN, Client B can proceed, though Client A may encounter problems. 163 In this example, Client B replaces the A RR associated with 164 "foo.example.com". Client A must have some way to recognize that the 165 RR associated with "foo.example.com" now contains information for 166 Client B, so that it can avoid modifying the RR. When Client A's 167 assigned IP address expires, for example, it should not remove a RR 168 that reflects Client B's DHCP assigned IP address. 170 If the policy is that the first DHCP client with a given FQDN should 171 be the only client associated with that FQDN, Client B needs to be 172 able to determine if it is not the client associated with 173 "foo.example.com". It could be that Client A booted first, and that 174 Client B should choose another FQDN. Or it could be that B has 175 booted on a new subnet, and received a new IP address assignment, in 176 which case B should update the DNS with its new IP address. It must 177 either retain persistent state about the last IP address it was 178 assigned (in addition to its current IP address) or it must have some 179 other way to detect that it was the last updater of "foo.example.com" 180 in order to implement the site's policy. 182 3.2. Multiple DHCP Servers 184 It is possible to arrange for DHCP servers to perform A and/or AAAA 185 RR updates on behalf of their clients. If a single DHCP server 186 manages all of the DHCP clients at a site, it can maintain a database 187 of the FQDNs in use, and can check that database before assigning a 188 FQDN to a client. Such a database is necessarily proprietary, 189 however, and the approach does not work once more than one DHCP 190 server is deployed. 192 When multiple DHCP servers are deployed, the servers require a way to 193 coordinate the identities of DHCP clients. Consider an example in 194 which DHCPv4 Client A boots, obtains an IP address from Server S1, 195 presenting the hostname "foo" in a Client FQDN option [8] in its 196 DHCPREQUEST message. Server S1 updates the FQDN "foo.example.com", 197 adding an A RR containing the IP address assigned to A. The client 198 then moves to another subnet, served by Server S2. When Client A 199 boots on the new subnet, Server S2 will assign it a new IP address, 200 and will attempt to add an A RR containing the newly assigned IP 201 address to the FQDN "foo.example.com". At this point, without some 202 communication mechanism which S2 can use to ask S1 (and every other 203 DHCP server that updates the zone) about the client, S2 has no way to 204 know whether Client A is currently associated with the FQDN, or 205 whether A is a different client configured with the same FQDN. If 206 the servers cannot distinguish between these situations, they cannot 207 enforce the site's naming policies. 209 4. Use of the DHCID RR 211 A solution to both of these problems is for the updater (a DHCP 212 client or DHCP server) to be able to determine which DHCP client has 213 been associated with a FQDN, in order to offer administrators the 214 opportunity to configure updater behavior. 216 For this purpose, a DHCID RR, specified in [2], is used to associate 217 client identification information with a FQDN and the A, AAAA, and 218 PTR RRs associated with that FQDN. When either a client or server 219 adds A, AAAA, or PTR RRs for a client, it also adds a DHCID RR that 220 specifies a unique client identity, based on data from the client's 221 DHCP message. In this model, only one client is associated with a 222 given FQDN at a time. 224 By associating this ownership information with each FQDN, cooperating 225 DNS updaters may determine whether their client is currently 226 associated with a particular FQDN and implement the appropriately 227 configured administrative policy. In addition, DHCP clients which 228 currently have FQDNs may move from one DHCP server to another without 229 losing their FQDNs. 231 The specific algorithm utilizing the DHCID RR to signal client 232 ownership is explained below. The algorithm only works in the case 233 where the updating entities all cooperate -- this approach is 234 advisory only and is not a substitute for DNS security, nor is it 235 replaced by DNS security. 237 5. Procedures for Performing DNS Updates 239 5.1. Error Return Codes 241 Certain RCODEs defined in RFC 2136 [3] indicate that the destination 242 DNS server cannot perform an update: FORMERR, SERVFAIL, REFUSED, 243 NOTIMP. If one of these RCODEs is returned, the updater MUST 244 terminate its update attempt. Because these errors may indicate a 245 misconfiguration of the updater or of the DNS server, the updater MAY 246 attempt to signal to its administrator that an error has occurred, 247 e.g. through a log message. 249 5.2. Dual IPv4/IPv6 Client Considerations 251 At the time of publication of this document, a small minority of DHCP 252 clients support both IPv4 and IPv6. We anticipate, however, that a 253 transition will take place over a period of time, and more sites will 254 have dual-stack clients present. IPv6 clients require updates of 255 AAAA RRs; IPv4 client require updates of A RRs. The administrators 256 of mixed deployments will likely wish to permit a single FQDN to 257 contain A and AAAA RRs from the same client. 259 Sites that wish to permit a single FQDN to contain both A and AAAA 260 RRs MUST make use of DHCPv4 clients and servers that support using 261 the DHCP Unique Identifier (DUID) for DHCPv4 client identifiers such 262 that this DUID is used in computing the RDATA of the DHCID RR by both 263 DHCPv4 and DHCPv6 for the client, see [12]. Otherwise, a dual-stack 264 client that uses older-style DHCPv4 client identifiers (see [4] and 265 [13]) will only be able to have either its A or AAAA records in DNS 266 under a single FQDN because of the DHCID RR conflicts that result. 268 5.3. Adding A and/or AAAA RRs to DNS 270 When a DHCP client or server intends to update A and/or AAAA RRs, it 271 starts with the update query in Section 5.3.1. 273 As the update sequence below can result in loops, implementers SHOULD 274 limit the total number of attempts for a single transaction. 276 5.3.1. Initial DHCID RR Query 278 The updater prepares a DNS UPDATE query that includes as a 279 prerequisite the assertion that the FQDN does not exist. The update 280 section of the query attempts to add the new FQDN and its IP address 281 mapping (A and/or AAAA RRs) and the DHCID RR with its unique client 282 identity. 284 If the update operation succeeds, the A and/or AAAA RR update is now 285 complete (and a client updater is finished, while a server would then 286 proceed to perform a PTR RR update). 288 If the update returns YXDOMAIN, the updater can now conclude that the 289 intended FQDN is in use and proceeds to Section 5.3.2. 291 If any other status is returned, the updater SHOULD NOT attempt an 292 update (see Section 5.1). 294 5.3.2. DNS UPDATE When FQDN in Use 296 The updater next attempts to confirm that the FQDN is not being used 297 by some other client by preparing an UPDATE query in which there are 298 two prerequisites. The first prerequisite is that the FQDN exists. 299 The second is that the desired FQDN has attached to it a DHCID RR 300 whose contents match the client identity. The update section of the 301 UPDATE query contains: 302 1. A delete of any existing A RRs on the FQDN if this is an A update 303 or an AAAA update and the updater does not desire A records on 304 the FQDN or this update is adding an A and the updater only 305 desires a single IP address on the FQDN. 306 2. A delete of the existing AAAA RRs on the FQDN if the updater does 307 not desire AAAA records on the FQDN or this update is adding an 308 AAAA and the updater only desires a single IP address on the 309 FQDN. 311 3. An add (or adds) of the A RR that matches the DHCP binding if 312 this is an A update. 313 4. Adds of the AAAA RRs that match the DHCP bindings if this is an 314 AAAA update. 316 Whether A or AAAA RRs are deleted depends on the updater or updater's 317 policy. For example, if the updater is the client or configured as 318 the only DHCP server for the link on which the client is located, the 319 updater may find it beneficial to delete all A and/or AAAA RRs and 320 then add the current set of A and/or AAAA RRs, if any, for the 321 client. 323 If the update succeeds, the updater can conclude that the current 324 client was the last client associated with the FQDN, and that the 325 FQDN now contains the updated A and/or AAAA RRs. The update is now 326 complete (and a client updater is finished, while a server would then 327 proceed to perform a PTR RR update). 329 If the update returns NXDOMAIN, the FQDN is no longer in use and the 330 updater proceeds back to Section 5.3.1. 332 If the update returns NXRRSET, there are two possibilities - there 333 are no DHCID RRs for the FQDN or the DHCID RR does not match. In 334 either case, the updater proceeds to Section 5.3.3. 336 5.3.3. FQDN in Use by another Client 338 As the FQDN appears to be in use by another client or is not 339 associated with any client, the updater SHOULD either choose another 340 FQDN and restart the update process with this new FQDN or terminate 341 the update with a failure. 343 Techniques that may be considered to disambiguate FQDNs include 344 adding some suffix or prefix to the hostname portion of the FQDN or 345 randomly generating a hostname. 347 5.4. Adding PTR RR Entries to DNS 349 The DHCP server submits a DNS query that deletes all of the PTR RRs 350 associated with the client's assigned IP address, and adds a PTR RR 351 whose data is the client's (possibly disambiguated) FQDN. The server 352 MAY also add a DHCID RR as specified in Section 4, in which case it 353 would include a delete of all of the DHCID RRs associated with the 354 client's assigned IP address, and adds a DHCID RR for the client. 356 There is no need to validate the DHCID RR for PTR updates as the DHCP 357 server (or servers) only assigns an address to a single client at a 358 time. 360 5.5. Removing Entries from DNS 362 The most important consideration in removing DNS entries is to be 363 sure that an entity removing a DNS entry is only removing an entry 364 that it added, or for which an administrator has explicitly assigned 365 it responsibility. 367 When an address' lease time or valid lifetime expires or a DHCP 368 client issues a DHCPRELEASE [4] or Release [5] request, the DHCP 369 server SHOULD delete the PTR RR that matches the DHCP binding, if one 370 was successfully added. The server's update query SHOULD assert that 371 the domain name (PTRDNAME field) in the PTR record matches the FQDN 372 of the client whose address has expired or been released and should 373 delete all RRs for the FQDN. 375 The entity chosen to handle the A or AAAA records for this client 376 (either the client or the server) SHOULD delete the A or AAAA records 377 that were added when the address was assigned to the client. 378 However, the updater should only remove the DHCID RR if there are no 379 A or AAAA RRs remaining for the client. 381 In order to perform this A or AAAA RR delete, the updater prepares an 382 UPDATE query that contains a prerequisite that asserts that the DHCID 383 RR exists whose data is the client identity described in Section 4 384 and contains an update section that deletes the client's specific A 385 or AAAA RR. 387 If the query succeeds, the updater prepares a second UPDATE query 388 that contains three prerequisites and contains an update section that 389 deletes all RRs for the FQDN. The first prerequisite asserts that 390 the DHCID RR exists whose data is the client identity described in 391 Section 4. The second prerequisite asserts that there are no A RRs. 392 The third prerequisite asserts that there are no AAAA RRs. 394 If either query fails, the updater MUST NOT delete the FQDN. It may 395 be that the client whose address has expired has moved to another 396 network and obtained an address from a different server, which has 397 caused the client's A or AAAA RR to be replaced. Or, the DNS data 398 may have been removed or altered by an administrator. 400 5.6. Updating Other RRs 402 The procedures described in this document only cover updates to the 403 A, AAAA, PTR, and DHCID RRs. Updating other types of RRs is outside 404 the scope of this document. 406 6. Security Considerations 408 Administrators should be wary of permitting unsecured DNS updates to 409 zones, whether or not they are exposed to the global Internet. Both 410 DHCP clients and servers SHOULD use some form of update request 411 authentication (e.g., TSIG [14]) when performing DNS updates. 413 Whether a DHCP client may be responsible for updating an FQDN to IP 414 address mapping, or whether this is the responsibility of the DHCP 415 server is a site-local matter. The choice between the two 416 alternatives may be based on the security model that is used with the 417 Dynamic DNS Update protocol (e.g., only a client may have sufficient 418 credentials to perform updates to the FQDN to IP address mapping for 419 its FQDN). 421 Whether a DHCP server is always responsible for updating the FQDN to 422 IP address mapping (in addition to updating the IP to FQDN mapping), 423 regardless of the wishes of an individual DHCP client, is also a 424 site-local matter. The choice between the two alternatives may be 425 based on the security model that is being used with dynamic DNS 426 updates. In cases where a DHCP server is performing DNS updates on 427 behalf of a client, the DHCP server should be sure of the FQDN to use 428 for the client, and of the identity of the client. 430 Currently, it is difficult for DHCP servers to develop much 431 confidence in the identities of their clients, given the absence of 432 entity authentication from the DHCP protocol itself. There are many 433 ways for a DHCP server to develop a FQDN to use for a client, but 434 only in certain relatively rare circumstances will the DHCP server 435 know for certain the identity of the client. If DHCP Authentication 436 [15] becomes widely deployed this may become more customary. 438 One example of a situation that offers some extra assurances is when 439 the DHCP client is connected to a network through a DOCSIS cable 440 modem, and the Cable Modem Termination System (head-end) of the cable 441 modem ensures that MAC address spoofing simply does not occur. 442 Another example of a configuration that might be trusted is when 443 clients obtain network access via a network access server using PPP. 444 The Network Access Server (NAS) itself might be obtaining IP 445 addresses via DHCP, encoding client identification into the DHCP 446 client-id option. In this case, the NAS as well as the DHCP server 447 might be operating within a trusted environment, in which case the 448 DHCP server could be configured to trust that the user authentication 449 and authorization processing of the NAS was sufficient, and would 450 therefore trust the client identification encoded within the DHCP 451 client-id. 453 7. Acknowledgements 455 Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter 456 Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, David W. 457 Hankins, R. Barr Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed 458 Lewis, Michael Lewis, Josh Littlefield, Michael Patton, Pekka Savola, 459 and Glenn Stump for their review and comments. 461 8. References 463 8.1. Normative References 465 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 466 Levels", BCP 14, RFC 2119, March 1997. 468 [2] Stapp, M., Gustafsson, A., and T. Lemon, "A DNS RR for Encoding 469 DHCP Information (draft-ietf-dnsext-dhcid-rr-*)", February 2006. 471 [3] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 472 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 473 April 1997. 475 [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 476 March 1997. 478 [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 479 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 480 RFC 3315, July 2003. 482 8.2. Informative References 484 [6] Mockapetris, P., "Domain names - implementation and 485 specification", STD 13, RFC 1035, November 1987. 487 [7] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996. 489 [8] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option 490 (draft-ietf-dhc-fqdn-option-*.txt)", February 2006. 492 [9] Volz, B., "The DHCPv6 Client FQDN Option 493 (draft-ietf-dhc-dhcpv6-fqdn-*.txt)", February 2006. 495 [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic 496 Update", RFC 3007, November 2000. 498 [11] Eastlake, D., "Domain Name System Security Extensions", 499 RFC 2535, March 1999. 501 [12] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers 502 for Dynamic Host Configuration Protocol Version Four (DHCPv4)", 503 RFC 4361, February 2006. 505 [13] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 506 Extensions", RFC 2132, March 1997. 508 [14] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, 509 "Secret Key Transaction Authentication for DNS (TSIG)", 510 RFC 2845, May 2000. 512 [15] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 513 RFC 3118, June 2001. 515 Authors' Addresses 517 Mark Stapp 518 Cisco Systems, Inc. 519 1414 Massachusetts Ave. 520 Boxborough, MA 01719 521 USA 523 Phone: 978.936.1535 524 Email: mjs@cisco.com 526 Bernie Volz 527 Cisco Systems, Inc. 528 1414 Massachusetts Ave. 529 Boxborough, MA 01719 530 USA 532 Phone: 978.936.0382 533 Email: volz@cisco.com 535 Intellectual Property Statement 537 The IETF takes no position regarding the validity or scope of any 538 Intellectual Property Rights or other rights that might be claimed to 539 pertain to the implementation or use of the technology described in 540 this document or the extent to which any license under such rights 541 might or might not be available; nor does it represent that it has 542 made any independent effort to identify any such rights. Information 543 on the procedures with respect to rights in RFC documents can be 544 found in BCP 78 and BCP 79. 546 Copies of IPR disclosures made to the IETF Secretariat and any 547 assurances of licenses to be made available, or the result of an 548 attempt made to obtain a general license or permission for the use of 549 such proprietary rights by implementers or users of this 550 specification can be obtained from the IETF on-line IPR repository at 551 http://www.ietf.org/ipr. 553 The IETF invites any interested party to bring to its attention any 554 copyrights, patents or patent applications, or other proprietary 555 rights that may cover technology that may be required to implement 556 this standard. Please address the information to the IETF at 557 ietf-ipr@ietf.org. 559 Disclaimer of Validity 561 This document and the information contained herein are provided on an 562 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 563 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 564 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 565 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 566 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 567 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 569 Copyright Statement 571 Copyright (C) The Internet Society (2006). This document is subject 572 to the rights, licenses and restrictions contained in BCP 78, and 573 except as set forth therein, the authors retain all their rights. 575 Acknowledgment 577 Funding for the RFC Editor function is currently provided by the 578 Internet Society.