idnits 2.17.00 (12 Aug 2021) /tmp/idnits44060/draft-ietf-dhc-ddns-resolution-12.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 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 559. ** 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 (March 22, 2006) is 5897 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 2845 (ref. '13') (Obsoleted by RFC 8945) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 12 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: September 23, 2006 Cisco Systems, Inc. 5 March 22, 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 September 23, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 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 Request . . . . . . . . . . . . . . . 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. Introduction 79 "The Client FQDN Option" [8] includes a description of the operation 80 of [4] clients and servers that use the DHCPv4 client FQDN option. 81 And, "The DHCPv6 Client FQDN Option" [9] includes a description of 82 the operation of [5] clients and servers that use the DHCPv6 client 83 FQDN option. Through the use of the client FQDN option, DHCP clients 84 and servers can negotiate the client's FQDN and the allocation of 85 responsibility for updating the DHCP client's A and/or AAAA RRs. 86 This document identifies situations in which conflicts in the use of 87 FQDNs may arise among DHCP clients and servers, and describes a 88 strategy for the use of the DHCID DNS resource record [2] in 89 resolving those conflicts. 91 In any case, whether a site permits all, some, or no DHCP servers and 92 clients to perform DNS updates ([3], [10]) into the zones that it 93 controls is entirely a matter of local administrative policy. This 94 document does not require any specific administrative policy, and 95 does not propose one. The range of possible policies is very broad, 96 from sites where only the DHCP servers have been given credentials 97 that the DNS servers will accept, to sites where each individual DHCP 98 client has been configured with credentials that allow the client to 99 modify its own FQDN. Compliant implementations MAY support some or 100 all of these possibilities. Furthermore, this specification applies 101 only to DHCP client and server processes; it does not apply to other 102 processes that initiate DNS updates. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [1]. 110 This document assumes familiarity with DNS terminology defined in [6] 111 and DHCP terminology defined in [4] and [5]. 113 FQDN, or Fully Qualified Domain Name, is the full name of a system, 114 rather than just its hostname. For example, "venera" is a hostname 115 and "venera.isi.edu" is an FQDN. See [7]. 117 DOCSIS, or Data-Over-Cable Service Interface Specifications, is 118 defined by CableLabs (www.cablelabs.com). 120 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 [10] may configure 147 credentials for each client and its assigned FQDN in a way that is 148 more error-resistant, as both the FQDN and credentials must match. 150 Consider an example in which two DHCP clients in the "example.com" 151 network are both configured with the hostname "foo". The clients are 152 permitted to perform their own DNS updates. The first client, client 153 A, is configured via DHCP. It adds an A RR to "foo.example.com", and 154 its DHCP server adds a PTR RR corresponding to its assigned IP 155 address. When the second client, client B, boots, it is also 156 configured via DHCP, and it also begins to update "foo.example.com". 158 At this point, the "example.com" administrators may wish to establish 159 some policy about DHCP clients' FQDNs. If the policy is that each 160 client that boots should replace any existing A RR that matches its 161 FQDN, Client B can proceed, though Client A may encounter problems. 162 In this example, Client B replaces the A RR associated with 163 "foo.example.com". Client A must have some way to recognize that the 164 RR associated with "foo.example.com" now contains information for 165 Client B, so that it can avoid modifying the RR. When Client A's 166 assigned IP address expires, for example, it should not remove a RR 167 that reflects Client B's DHCP assigned IP address. 169 If the policy is that the first DHCP client with a given FQDN should 170 be the only client associated with that FQDN, Client B needs to be 171 able to determine if it is not the client associated with 172 "foo.example.com". It could be that Client A booted first, and that 173 Client B should choose another FQDN. Or it could be that B has 174 booted on a new subnet, and received a new IP address assignment, in 175 which case B should update the DNS with its new IP address. It must 176 either retain persistent state about the last IP address it was 177 assigned (in addition to its current IP address) or it must have some 178 other way to detect that it was the last updater of "foo.example.com" 179 in order to implement the site's policy. 181 3.2. Multiple DHCP Servers 183 It is possible to arrange for DHCP servers to perform A and/or AAAA 184 RR updates on behalf of their clients. If a single DHCP server 185 manages all of the DHCP clients at a site, it can maintain a database 186 of the FQDNs in use, and can check that database before assigning a 187 FQDN to a client. Such a database is necessarily proprietary, 188 however, and the approach does not work once more than one DHCP 189 server is deployed. 191 When multiple DHCP servers are deployed, the servers require a way to 192 coordinate the identities of DHCP clients. Consider an example in 193 which DHCPv4 Client A boots, obtains an IP address from Server S1, 194 presenting the hostname "foo" in a Client FQDN option [8] in its 195 DHCPREQUEST message. Server S1 updates the FQDN "foo.example.com", 196 adding an A RR containing the IP address assigned to A. The client 197 then moves to another subnet, served by Server S2. When Client A 198 boots on the new subnet, Server S2 will assign it a new IP address, 199 and will attempt to add an A RR containing the newly assigned IP 200 address to the FQDN "foo.example.com". At this point, without some 201 communication mechanism which S2 can use to ask S1 (and every other 202 DHCP server that updates the zone) about the client, S2 has no way to 203 know whether Client A is currently associated with the FQDN, or 204 whether A is a different client configured with the same FQDN. If 205 the servers cannot distinguish between these situations, they cannot 206 enforce the site's naming policies. 208 4. Use of the DHCID RR 210 A solution to both of these problems is for the updater (a DHCP 211 client or DHCP server) to be able to determine which DHCP client has 212 been associated with a FQDN, in order to offer administrators the 213 opportunity to configure updater behavior. 215 For this purpose, a DHCID RR, specified in [2], is used to associate 216 client identification information with a FQDN and the A, AAAA, and 217 PTR RRs associated with that FQDN. When either a client or server 218 adds A, AAAA, or PTR RRs for a client, it also adds a DHCID RR that 219 specifies a unique client identity, based on data from the client's 220 DHCP message. In this model, only one client is associated with a 221 given FQDN at a time. 223 By associating this ownership information with each FQDN, cooperating 224 DNS updaters may determine whether their client is currently 225 associated with a particular FQDN and implement the appropriately 226 configured administrative policy. In addition, DHCP clients which 227 currently have FQDNs may move from one DHCP server to another without 228 losing their FQDNs. 230 The specific algorithm utilizing the DHCID RR to signal client 231 ownership is explained below. The algorithm only works in the case 232 where the updating entities all cooperate -- this approach is 233 advisory only and is not a substitute for DNS security, nor is it 234 replaced by DNS security. 236 5. Procedures for Performing DNS Updates 238 5.1. Error Return Codes 240 Certain RCODEs defined in [3] indicate that the destination DNS 241 server cannot perform an update, i.e., FORMERR, SERVFAIL, REFUSED, 242 NOTIMP. If one of these RCODEs is returned, the updater MUST 243 terminate its update attempt. Other RCODEs [13] may indicate that 244 there are problems with the key being used and may mean to try a 245 different key, if available, or to terminate the operation. Because 246 some errors may indicate a misconfiguration of the updater or the DNS 247 server, the updater MAY attempt to signal to its administrator that 248 an error has occurred, e.g. through a log message. 250 5.2. Dual IPv4/IPv6 Client Considerations 252 At the time of publication of this document, a small minority of DHCP 253 clients support both IPv4 and IPv6. We anticipate, however, that a 254 transition will take place over a period of time, and more sites will 255 have dual-stack clients present. IPv6 clients require updates of 256 AAAA RRs; IPv4 client require updates of A RRs. The administrators 257 of mixed deployments will likely wish to permit a single FQDN to 258 contain A and AAAA RRs from the same client. 260 Sites that wish to permit a single FQDN to contain both A and AAAA 261 RRs MUST make use of DHCPv4 clients and servers that support using 262 the DHCP Unique Identifier (DUID) for DHCPv4 client identifiers such 263 that this DUID is used in computing the RDATA of the DHCID RR by both 264 DHCPv4 and DHCPv6 for the client, see [11]. Otherwise, a dual-stack 265 client that uses older-style DHCPv4 client identifiers (see [4] and 266 [12]) will only be able to have either its A or AAAA records in DNS 267 under a single FQDN because of the DHCID RR conflicts that result. 269 5.3. Adding A and/or AAAA RRs to DNS 271 When a DHCP client or server intends to update A and/or AAAA RRs, it 272 starts with the UPDATE request in Section 5.3.1. 274 As the update sequence below can result in loops, implementers SHOULD 275 limit the total number of attempts for a single transaction. 277 5.3.1. Initial DHCID RR Request 279 The updater prepares a DNS UPDATE request that includes as a 280 prerequisite the assertion that the FQDN does not exist. The update 281 section of the request attempts to add the new FQDN and its IP 282 address mapping (A and/or AAAA RRs) and the DHCID RR with its unique 283 client identity. 285 If the UPDATE request succeeds, the A and/or AAAA RR update is now 286 complete (and a client updater is finished, while a server would then 287 proceed to perform a PTR RR update). 289 If the response to the UPDATE returns YXDOMAIN, the updater can now 290 conclude that the intended FQDN is in use and proceeds to 291 Section 5.3.2. 293 If any other status is returned, the updater SHOULD NOT attempt an 294 update (see Section 5.1). 296 5.3.2. DNS UPDATE When FQDN in Use 298 The updater next attempts to confirm that the FQDN is not being used 299 by some other client by preparing an UPDATE request in which there 300 are two prerequisites. The first prerequisite is that the FQDN 301 exists. The second is that the desired FQDN has attached to it a 302 DHCID RR whose contents match the client identity. The update 303 section of the UPDATE request contains: 304 1. A delete of any existing A RRs on the FQDN if this is an A update 305 or an AAAA update and the updater does not desire A records on 306 the FQDN or this update is adding an A and the updater only 307 desires a single IP address on the FQDN. 308 2. A delete of the existing AAAA RRs on the FQDN if the updater does 309 not desire AAAA records on the FQDN or this update is adding an 310 AAAA and the updater only desires a single IP address on the 311 FQDN. 313 3. An add (or adds) of the A RR that matches the DHCP binding if 314 this is an A update. 315 4. Adds of the AAAA RRs that match the DHCP bindings if this is an 316 AAAA update. 318 Whether A or AAAA RRs are deleted depends on the updater or updater's 319 policy. For example, if the updater is the client or configured as 320 the only DHCP server for the link on which the client is located, the 321 updater may find it beneficial to delete all A and/or AAAA RRs and 322 then add the current set of A and/or AAAA RRs, if any, for the 323 client. 325 If the UPDATE request succeeds, the updater can conclude that the 326 current client was the last client associated with the FQDN, and that 327 the FQDN now contains the updated A and/or AAAA RRs. The update is 328 now complete (and a client updater is finished, while a server would 329 then proceed to perform a PTR RR update). 331 If the response to the UPDATE request returns NXDOMAIN, the FQDN is 332 no longer in use and the updater proceeds back to Section 5.3.1. 334 If the response to the UPDATE request returns NXRRSET, there are two 335 possibilities - there are no DHCID RRs for the FQDN or the DHCID RR 336 does not match. In either case, the updater proceeds to 337 Section 5.3.3. 339 5.3.3. FQDN in Use by another Client 341 As the FQDN appears to be in use by another client or is not 342 associated with any client, the updater SHOULD either choose another 343 FQDN and restart the update process with this new FQDN or terminate 344 the update with a failure. 346 Techniques that may be considered to disambiguate FQDNs include 347 adding some suffix or prefix to the hostname portion of the FQDN or 348 randomly generating a hostname. 350 5.4. Adding PTR RR Entries to DNS 352 The DHCP server submits a DNS UPDATE request that deletes all of the 353 PTR RRs associated with the client's assigned IP address, and adds a 354 PTR RR whose data is the client's (possibly disambiguated) FQDN. The 355 server MAY also add a DHCID RR as specified in Section 4, in which 356 case it would include a delete of all of the DHCID RRs associated 357 with the client's assigned IP address, and adds a DHCID RR for the 358 client. 360 There is no need to validate the DHCID RR for PTR updates as the DHCP 361 server (or servers) only assigns an address to a single client at a 362 time. 364 5.5. Removing Entries from DNS 366 The most important consideration in removing DNS entries is to be 367 sure that an entity removing a DNS entry is only removing an entry 368 that it added, or for which an administrator has explicitly assigned 369 it responsibility. 371 When an address' lease time or valid lifetime expires or a DHCP 372 client issues a DHCPRELEASE [4] or Release [5] request, the DHCP 373 server SHOULD delete the PTR RR that matches the DHCP binding, if one 374 was successfully added. The server's UPDATE request SHOULD assert 375 that the domain name (PTRDNAME field) in the PTR record matches the 376 FQDN of the client whose address has expired or been released and 377 should delete all RRs for the FQDN. 379 The entity chosen to handle the A or AAAA records for this client 380 (either the client or the server) SHOULD delete the A or AAAA records 381 that were added when the address was assigned to the client. 382 However, the updater should only remove the DHCID RR if there are no 383 A or AAAA RRs remaining for the client. 385 In order to perform this A or AAAA RR delete, the updater prepares an 386 UPDATE request that contains a prerequisite that asserts that the 387 DHCID RR exists whose data is the client identity described in 388 Section 4 and contains an update section that deletes the client's 389 specific A or AAAA RR. 391 If the UPDATE request succeeds, the updater prepares a second UPDATE 392 request that contains three prerequisites and contains an update 393 section that deletes all RRs for the FQDN. The first prerequisite 394 asserts that the DHCID RR exists whose data is the client identity 395 described in Section 4. The second prerequisite asserts that there 396 are no A RRs. The third prerequisite asserts that there are no AAAA 397 RRs. 399 If either request fails, the updater MUST NOT delete the FQDN. It 400 may be that the client whose address has expired has moved to another 401 network and obtained an address from a different server, which has 402 caused the client's A or AAAA RR to be replaced. Or, the DNS data 403 may have been removed or altered by an administrator. 405 5.6. Updating Other RRs 407 The procedures described in this document only cover updates to the 408 A, AAAA, PTR, and DHCID RRs. Updating other types of RRs is outside 409 the scope of this document. 411 6. Security Considerations 413 Administrators should be wary of permitting unsecured DNS updates to 414 zones, whether or not they are exposed to the global Internet. Both 415 DHCP clients and servers SHOULD use some form of update request 416 authentication (e.g., TSIG [13]) when performing DNS updates. 418 Whether a DHCP client may be responsible for updating an FQDN to IP 419 address mapping, or whether this is the responsibility of the DHCP 420 server is a site-local matter. The choice between the two 421 alternatives may be based on the security model that is used with the 422 Dynamic DNS Update protocol (e.g., only a client may have sufficient 423 credentials to perform updates to the FQDN to IP address mapping for 424 its FQDN). 426 Whether a DHCP server is always responsible for updating the FQDN to 427 IP address mapping (in addition to updating the IP to FQDN mapping), 428 regardless of the wishes of an individual DHCP client, is also a 429 site-local matter. The choice between the two alternatives may be 430 based on the security model that is being used with dynamic DNS 431 updates. In cases where a DHCP server is performing DNS updates on 432 behalf of a client, the DHCP server should be sure of the FQDN to use 433 for the client, and of the identity of the client. 435 Currently, it is difficult for DHCP servers to develop much 436 confidence in the identities of their clients, given the absence of 437 entity authentication from the DHCP protocol itself. There are many 438 ways for a DHCP server to develop a FQDN to use for a client, but 439 only in certain relatively rare circumstances will the DHCP server 440 know for certain the identity of the client. If [14] becomes widely 441 deployed this may become more customary. 443 One example of a situation that offers some extra assurances is when 444 the DHCP client is connected to a network through a DOCSIS cable 445 modem, and the Cable Modem Termination System (head-end) of the cable 446 modem ensures that MAC address spoofing simply does not occur. 447 Another example of a configuration that might be trusted is when 448 clients obtain network access via a network access server using PPP. 449 The Network Access Server (NAS) itself might be obtaining IP 450 addresses via DHCP, encoding client identification into the DHCP 451 client-id option. In this case, the NAS as well as the DHCP server 452 might be operating within a trusted environment, in which case the 453 DHCP server could be configured to trust that the user authentication 454 and authorization processing of the NAS was sufficient, and would 455 therefore trust the client identification encoded within the DHCP 456 client-id. 458 7. Acknowledgements 460 Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter 461 Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, David W. 462 Hankins, R. Barr Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed 463 Lewis, Michael Lewis, Josh Littlefield, Michael Patton, Pekka Savola, 464 and Glenn Stump for their review and comments. 466 8. References 468 8.1. Normative References 470 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 471 Levels", BCP 14, RFC 2119, March 1997. 473 [2] Stapp, M., Gustafsson, A., and T. Lemon, "A DNS RR for Encoding 474 DHCP Information (draft-ietf-dnsext-dhcid-rr-*)", February 2006. 476 [3] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 477 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 478 April 1997. 480 [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 481 March 1997. 483 [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 484 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 485 RFC 3315, July 2003. 487 8.2. Informative References 489 [6] Mockapetris, P., "Domain names - implementation and 490 specification", STD 13, RFC 1035, November 1987. 492 [7] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996. 494 [8] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option 495 (draft-ietf-dhc-fqdn-option-*.txt)", February 2006. 497 [9] Volz, B., "The DHCPv6 Client FQDN Option 498 (draft-ietf-dhc-dhcpv6-fqdn-*.txt)", February 2006. 500 [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic 501 Update", RFC 3007, November 2000. 503 [11] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers 504 for Dynamic Host Configuration Protocol Version Four (DHCPv4)", 505 RFC 4361, February 2006. 507 [12] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 508 Extensions", RFC 2132, March 1997. 510 [13] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, 511 "Secret Key Transaction Authentication for DNS (TSIG)", 512 RFC 2845, May 2000. 514 [14] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 515 RFC 3118, June 2001. 517 Authors' Addresses 519 Mark Stapp 520 Cisco Systems, Inc. 521 1414 Massachusetts Ave. 522 Boxborough, MA 01719 523 USA 525 Phone: 978.936.1535 526 Email: mjs@cisco.com 528 Bernie Volz 529 Cisco Systems, Inc. 530 1414 Massachusetts Ave. 531 Boxborough, MA 01719 532 USA 534 Phone: 978.936.0382 535 Email: volz@cisco.com 537 Intellectual Property Statement 539 The IETF takes no position regarding the validity or scope of any 540 Intellectual Property Rights or other rights that might be claimed to 541 pertain to the implementation or use of the technology described in 542 this document or the extent to which any license under such rights 543 might or might not be available; nor does it represent that it has 544 made any independent effort to identify any such rights. Information 545 on the procedures with respect to rights in RFC documents can be 546 found in BCP 78 and BCP 79. 548 Copies of IPR disclosures made to the IETF Secretariat and any 549 assurances of licenses to be made available, or the result of an 550 attempt made to obtain a general license or permission for the use of 551 such proprietary rights by implementers or users of this 552 specification can be obtained from the IETF on-line IPR repository at 553 http://www.ietf.org/ipr. 555 The IETF invites any interested party to bring to its attention any 556 copyrights, patents or patent applications, or other proprietary 557 rights that may cover technology that may be required to implement 558 this standard. Please address the information to the IETF at 559 ietf-ipr@ietf.org. 561 Disclaimer of Validity 563 This document and the information contained herein are provided on an 564 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 565 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 566 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 567 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 568 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 569 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 571 Copyright Statement 573 Copyright (C) The Internet Society (2006). This document is subject 574 to the rights, licenses and restrictions contained in BCP 78, and 575 except as set forth therein, the authors retain all their rights. 577 Acknowledgment 579 Funding for the RFC Editor function is currently provided by the 580 Internet Society.