idnits 2.17.00 (12 Aug 2021) /tmp/idnits51015/draft-volz-dhc-dhcpv6-fqdn-00.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 510. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 526), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (July 9, 2004) is 6518 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) ** Obsolete normative reference: RFC 3315 (ref. '5') (Obsoleted by RFC 8415) -- No information found for draft-ietf-dhc-ddns-resolution- - is the name correct? -- No information found for draft-ietf-dhc-fqdn-option- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1594 (ref. '8') (Obsoleted by RFC 2664) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '9') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '12') (Obsoleted by RFC 4941) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC B. Volz 3 Internet-Draft Cisco Systems, Inc. 4 Expires: January 7, 2005 July 9, 2004 6 The DHCPv6 Client FQDN Option 7 draft-volz-dhc-dhcpv6-fqdn-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 7, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document specifies a new DHCP for IPv6, DHCPv6, option which can 41 be used to exchange information about a DHCPv6 client's 42 fully-qualified domain name and about responsibility for updating DNS 43 RRs related to the client's address assignments. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Models of Operation . . . . . . . . . . . . . . . . . . . . . 3 50 4. The DHCPv6 Client FQDN Option . . . . . . . . . . . . . . . . 4 51 4.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 52 4.2 The Domain Name Field . . . . . . . . . . . . . . . . . . 6 53 5. DHCPv6 Client behavior . . . . . . . . . . . . . . . . . . . . 7 54 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 8 55 7. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 9 56 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 57 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 60 10.2 Informative References . . . . . . . . . . . . . . . . . . . 11 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 62 Intellectual Property and Copyright Statements . . . . . . . . 12 64 1. Introduction 66 DNS ([2], [3]) maintains (among other things) the information about 67 mapping between hosts' Fully Qualified Domain Names (FQDNs) [8] and 68 IP addresses assigned to the hosts. The information is maintained in 69 two types of Resource Records (RRs): AAAA and PTR [11]. The DNS 70 update specification ([4]) describes a mechanism that enables DNS 71 information to be updated over a network. 73 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [5] 74 provides a mechanism by which a host (a DHCPv6 client) can acquire 75 certain configuration information, along with its stateful IPv6 76 address(es). This document specifies a new DHCPv6 option, the Client 77 FQDN option, which can be used by DHCPv6 clients and servers to 78 exchange information about the client's fully-qualified domain name 79 for an address and who has the responsibility for updating the DNS 80 with the associated AAAA and PTR RRs. 82 2. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [1]. 88 Familiarity with the DNS Update protocol [4], DHCPv6, and DHCPv6 89 terminology as defined in [5] is assumed. 91 3. Models of Operation 93 When a DHCPv6 client acquires an address, a site's administrator may 94 desire that the AAAA RR for the client's FQDN and the PTR RR for the 95 acquired address be updated. Therefore, two separate DNS update 96 transactions may occur. Acquiring an address via DHCPv6 involves two 97 entities: a DHCPv6 client and a DHCPv6 server. In principle each of 98 these entities could perform none, one, or both of the transactions. 99 However, in practice not all permutations make sense. The DHCPv6 100 Client FQDN option is primarily intended to operate in the following 101 two cases: 103 1. DHCPv6 client updates the AAAA RR, DHCPv6 server updates the PTR 104 RR 105 2. DHCPv6 server updates both the AAAA and the PTR RRs 107 The only difference between these two cases is whether the FQDN to 108 IPv6 address mapping is updated by a DHCPv6 client or by a DHCPv6 109 server. The IPv6 address to FQDN mapping is updated by a DHCPv6 110 server in both cases. 112 The reason these two are important, while others are unlikely, has to 113 do with authority over the respective DNS domain names. A DHCPv6 114 client may be given authority over mapping its own AAAA RRs, or that 115 authority may be restricted to a server to prevent the client from 116 listing arbitrary addresses or associating its addresses with 117 arbitrary domain names. In all cases, the only reasonable place for 118 the authority over the PTR RRs associated with the address is in the 119 DHCPv6 server that allocates the address. 121 Note: A third case is supported - the client requests that the server 122 perform no updates. However, this case is presumed to be rare 123 because of the authority issues. 125 In any case, whether a site permits all, some, or no DHCPv6 servers 126 and clients to perform DNS updates into the zones which it controls 127 is entirely a matter of local administrative policy. This document 128 does not require any specific administrative policy, and does not 129 propose one. The range of possible policies is very broad, from 130 sites where only the DHCPv6 servers have been given credentials that 131 the DNS servers will accept, to sites where each individual DHCPv6 132 client has been configured with credentials which allow the client to 133 modify its own domain name. Compliant implementations MAY support 134 some or all of these possibilities. Furthermore, this specification 135 applies only to DHCPv6 client and server processes: it does not apply 136 to other processes which initiate DNS updates. 138 This document describes a new DHCPv6 option which a client can use to 139 convey all or part of its domain name to a DHCPv6 server. 140 Site-specific policy determines whether DHCPv6 servers use the names 141 that clients offer or not, and what DHCPv6 servers may do in cases 142 where clients do not supply domain names. 144 Other work, such as "Resolving Name Conflicts" [6], may define 145 procedures for establishing policy and arbitrating conflicts when 146 collisions occur in the use of FQDNs by DHCPv6 clients. 148 4. The DHCPv6 Client FQDN Option 150 To update the IPv6 address to FQDN mapping a DHCPv6 server needs to 151 know the FQDN of the client to which the server binds each address. 152 To allow the client to convey its FQDN to the server this document 153 defines a new DHCPv6 option, called "Client FQDN". The Client FQDN 154 option also contains Flags which DHCPv6 clients and servers use to 155 negotiate who does which updates. 157 The code for this option is TBD. Its minimum length is 2. 159 The Format of the DHCPv6 Client FQDN option: 161 0 1 2 3 162 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | OPTION_FQDN | option-len | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | flags | | 167 +-+-+-+-+-+-+-+-+ | 168 . . 169 . domain-name . 170 . . 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 option-code OPTION_CLIENT_FQDN (TBD) 175 option-len 1 + length of domain name 177 flags flag bits used between client and server to 178 negotiate who performs which updates 180 domain-name the partial or fully qualified domain name 181 (with length option-len - 1) 183 4.1 The Flags Field 185 The Format of the Flags field: 187 0 1 2 3 4 5 6 7 188 +-+-+-+-+-+-+-+-+ 189 | MBZ |N|O|S| 190 +-+-+-+-+-+-+-+-+ 192 When a DHCPv6 client sends the Client FQDN option, it sets the "S" 193 bit to indicate that it will not perform any DNS updates, and that it 194 expects the DHCPv6 server to perform any FQDN-to-IPv6 (the AAAA RR) 195 DNS update on its behalf. If this bit is clear, the client indicates 196 that it intends to maintain its own FQDN-to-IPv6 mapping update. 198 If a DHCPv6 server intends to take responsibility for the AAAA RR 199 update, whether or not the client sending the Client FQDN option has 200 set the "S" bit, it sets both the "O" and "S" bits, and sends the 201 FQDN option in its response message. Clients SHOULD clear the "O" 202 bit before sending the Client FQDN option and servers MUST ignore the 203 received state of the "O" bit. 205 A client MAY set the "N" bit in its request messages to indicate that 206 the server should not perform any DNS updates on its behalf. As 207 mentioned in Section 3, in general the DHCPv6 server will be 208 maintaining DNS PTR records on behalf of clients. However, there may 209 be deployments in which clients are configured to perform all desired 210 DNS updates or may not want any DNS updates. The server MAY be 211 configured to honor this configuration. If the server has been 212 configured to honor a client's "N" indication, it SHOULD set the "N" 213 bit in Client FQDN options which it sends to the client in its 214 response messages. Clients which have set the "N" bit in their 215 requests SHOULD use the state of the "N" bit in server responses to 216 determine whether the server was prepared to honor the client's 217 indication. If a client has set the "N" bit but its server does not, 218 the client SHOULD conclude that the server was not configured to 219 honor the client's suggestion, and that the server may attempt to 220 perform DNS updates on its behalf. 222 The remaining bits in the Flags field are reserved for future 223 assignment. DHCPv6 clients and servers which send the Client FQDN 224 option MUST set the MBZ bits to 0, and they MUST ignore these bits. 226 4.2 The Domain Name Field 228 The Domain Name field of the option carries all or part of the FQDN 229 of a DHCPv6 client. The data in the Domain Name field MUST appear in 230 uncompressed DNS encoding as specified in [3]. In order to determine 231 whether a name has changed between message exchanges, an unambiguous 232 canonical form is necessary. Eventually, the IETF IDN Working Group 233 is expected to produce a standard canonicalization specification, and 234 this specification may be updated to include its standard. Until 235 that time, servers and clients should be sensitive to 236 canonicalization when comparing names in the Domain Name field and 237 the name canonicalization defined in [9] MAY be used. 239 A client may be configured with a fully-qualified domain name, or 240 with a partial name that is not fully-qualified. If a client knows 241 only part of its name, it MAY send a name that is not 242 fully-qualified, indicating that it knows part of the name but does 243 not necessarily know the zone in which the name is to be embedded. A 244 client which wants to convey part of its FQDN sends a non-terminal 245 sequence of labels in the domain name field of the option. Clients 246 and servers should assume that the name field contains a 247 fully-qualified name unless this partial-name format exists. 249 Servers MUST always send the complete fully-qualified domain name in 250 Client FQDN options. 252 5. DHCPv6 Client behavior 254 The following describes the behavior of a DHCPv6 client that 255 implements the Client FQDN option. 257 A client sends the Client FQDN option with no Flags bits set, the "S" 258 Flags bit set, or the "N" Flags bit set and with the desired partial 259 or fully qualified domain name. 261 A client MUST only include the Client FQDN option in the SOLICIT, 262 REQUEST, RENEW, or REBIND messages. 264 As a client may be assigned addresses or more addresses when sending 265 a REQUEST, RENEW, or REBIND message, it SHOULD include a Client FQDN 266 option in any IA_NA-option fields and MAY include the Client FQDN 267 option in IA_TA-option fields (see [12]). If it previously received 268 a Client FQDN option for a specific address (i.e., in the 269 IAaddr-options field of an IA Address option) and is including that 270 address in a subsequent REQUEST, RENEW, or REBIND message, it MUST 271 include that option in the IAaddr-options field for that address. 273 There is no requirement that the client send identical Client FQDN 274 options data in each of its messages to a server. In particular, if 275 a client has sent Client FQDN options to its server, and the 276 configuration of the client changes so that its notion of its domain 277 name changes, it MAY send the new name data in a Client FQDN options 278 when it communicates with the server again. This may cause the 279 DHCPv6 server to update the name associated with the PTR record, and, 280 if the server updated the AAAA record representing the client, to 281 delete that record and attempt an update for the client's current 282 domain name. 284 Once the client's DHCPv6 configuration is completed (the client 285 receives a REPLY message, and successfully completes a final check on 286 the parameters passed in the message), the client SHOULD originate 287 the DNS updates for the AAAA RR (associated with the client's FQDNs) 288 for any Client FQDN options for which the received "S" and the "O" 289 bits in the option's Flags field are not set and if it is otherwise 290 configured to perform the DNS updates. The update SHOULD be 291 originated following the procedures described in [4]. If the DHCPv6 292 server from which the client is requesting addresses includes Client 293 FQDN options in its REPLY message, and if the server sets both the 294 "S" and "O" bits in the option's Flags field, the DHCPv6 client MUST 295 NOT initiate an update for the name in the Domain Name field and that 296 address. 298 A client that delegates the responsibility for updating the FQDN to 299 IPv6 address mapping to a server does not receive any indication 300 (either positive or negative) from the server whether the server was 301 able to perform the update. If the client needs to confirm the DNS 302 update, it SHOULD use a DNS query to check whether the mapping is 303 updated. 305 If a client releases a binding for an address prior to the valid 306 lifetime expiration or is unable to extend the lifetimes for an 307 address and the valid lifetime expires, and the client is responsible 308 for updating its AAAA RRs, the client SHOULD delete the AAAA RR 309 associated with the address before sending a RELEASE message or the 310 lifetime expires. A DHCPv6 client which has not been able to delete 311 an AAAA RR which it added (because it has lost the use of addresses 312 of sufficient scope to communicate with the DNS server or exceeds 313 retry intervals) should attempt to notify its administrator, perhaps 314 by emitting a log message. 316 6. DHCPv6 Server Behavior 318 Servers MUST only include Client FQDN options in ADVERTISE and REPLY 319 messages if received in the client's message to which it is 320 responding. Servers MUST only include Client FQDN options in the 321 IAaddr-options field of IA Address options in messages sent by the 322 server. 324 When a server allocates a new address to an IA, it uses the Client 325 FQDN option, if any, in the IA_NA-options or IA_TA-options field of 326 that IA to negotiate the fully qualified domain name and who will 327 take responsibility for the DNS updates. It records the results in 328 the Client FQDN in the IAaddr-options field of the IA Address option 329 for that address. The DHCPv6 server SHOULD send its notion of the 330 complete FQDN for the client in the Domain Name field. The server 331 MAY simply copy the Domain Name field from the Client FQDN option 332 that the client sent to the server. The DHCPv6 server MAY be 333 configured to complete or modify the domain name which a client sent, 334 or it MAY be configured to substitute a different name. 336 If a client's SOLICIT, REQUEST, RENEW, or REBIND message doesn't 337 include the Client FQDN option for an IA (e.g., the client doesn't 338 implement the Client FQDN option), the server MAY be configured to 339 update either or both of the AAAA and PTR RRs. 341 If a client's message includes a Client FQDN option for an address 342 and the requested domain-name is different from the server's current 343 knowledge of the fully-qualified domain name and the server is 344 configured to allow use of that name, the server SHOULD perform the 345 necessary DNS updates - the server SHOULD remove the old PTR and AAAA 346 RRs it added, if any, and SHOULD add the new RRs if it has that 347 responsibility. 349 When a server receives a RELEASE or DECLINE for an address, detects 350 that the valid lifetime on an address that the server bound to a 351 client has expired, or terminates a binding on an address prior to 352 the binding's expiration time (for instance, by sending a REPLY with 353 a zero valid lifetime for an address), the server SHOULD delete any 354 PTR RRs which it associated with the address via DNS update. In 355 addition, if the server took responsibility for the AAAA RR, the 356 server SHOULD also delete that AAAA RR. 358 A server MAY initiate and complete the DNS update(s) before the 359 server sends the REPLY message to the client. Alternatively, the 360 server MAY send the REPLY message to the client without waiting for 361 the update to be initiated or completed. The choice between the two 362 alternatives is entirely determined by the configuration of the 363 DHCPv6 server. Servers SHOULD support both configuration options. 365 If the server initiates a DNS update that is not complete until after 366 the server has replied to the client, the server's interaction with 367 the DNS server may cause the DHCPv6 server to change the domain name 368 that it associates with an address for the client. This may occur, 369 for example, if the server detects and resolves a domain-name 370 conflict. In such cases, the domain name that the server returns to 371 the client may change between two DHCPv6 exchanges. 373 7. DNS Update Conflicts 375 This document does not resolve how a DHCPv6 client or server prevent 376 name conflicts. This document addresses only how a DHCPv6 client and 377 server negotiate who will perform the DNS updates and the fully 378 qualified domain name requested or used. 380 Implementers of this work will need to consider how name conflicts 381 will be prevented. It may be that the DNS updater must hold a 382 security token in order to successfully perform DNS updates on a 383 specific name, in which case name conflicts can only occur if 384 multiple clients are given a security token for that name. Or, the 385 fully qualified domains may be based on the specific address bound to 386 a client or the client's DUID, and in these cases conflicts should 387 not occur. However, without this level of security in the DNS system 388 or use of non-conflicting names, other techniques need to be 389 developed. This is an area for future work (see [6]). 391 8. Security Considerations 393 Unauthenticated updates to the DNS can lead to tremendous confusion, 394 through malicious attack or through inadvertent misconfiguration. 395 Administrators should be wary of permitting unsecured DNS updates to 396 zones which are exposed to the global Internet. Both DHCPv6 clients 397 and servers SHOULD use some form of update request origin 398 authentication procedure (e.g., Secure DNS Dynamic Update [10]) when 399 performing DNS updates. 401 Whether a DHCPv6 client may be responsible for updating an FQDN to 402 IPv6 address mapping or whether this is the responsibility of the 403 DHCPv6 server is a site-local matter. The choice between the two 404 alternatives may be based on the security model that is used with the 405 DNS update protocol (e.g., only a client may have sufficient 406 credentials to perform updates to the FQDN to IP address mapping for 407 its FQDN). 409 Whether a DHCPv6 server is always responsible for updating the FQDN 410 to IPv6 address mapping (in addition to updating the IPv6 to FQDN 411 mapping), regardless of the wishes of an individual DHCPv6 client, is 412 also a site-local matter. The choice between the two alternatives 413 may be based on the security model that is being used with DNS 414 updates. In cases where a DHCPv6 server is performing DNS updates on 415 behalf of a client, the DHCPv6 server should be sure of the DNS name 416 to use for the client, and of the identity of the client. 418 Depending on the prescence of or type of authentication used with the 419 Authentication option, a DHCPv6 server may not have much confidence 420 in the identities of its clients. There are many ways for a DHCPv6 421 server to develop a DNS name to use for a client, but only in certain 422 circumstances will the DHCPv6 server know for certain the identity of 423 the client. 425 9. Acknowledgements 427 Many thanks to Mark Stapp and Yakov Rekhter as this document is based 428 on draft-ietf-dhc-fqdn-option [7]. And, to Mark Stapp, Josh 429 Littlefield, Kim Kinnear, and Ralph Droms for discussions on this 430 option for DHCPv6 and on reviewing early copies of the draft. 432 10. References 434 10.1 Normative References 436 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 437 Levels", BCP 14, RFC 2119, March 1997. 439 [2] Mockapetris, P., "Domain names - concepts and facilities", STD 440 13, RFC 1034, November 1987. 442 [3] Mockapetris, P., "Domain names - implementation and 443 specification", STD 13, RFC 1035, November 1987. 445 [4] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 446 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 447 1997. 449 [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 450 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 451 RFC 3315, July 2003. 453 10.2 Informative References 455 [6] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients 456 (draft-ietf-dhc-ddns-resolution-*.txt)", October 2003. 458 [7] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option 459 (draft-ietf-dhc-fqdn-option-*.txt)", October 2003. 461 [8] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and 462 Answers - Answers to Commonly asked "New Internet User" 463 Questions", RFC 1594, March 1994. 465 [9] Eastlake, D., "Domain Name System Security Extensions", RFC 466 2535, March 1999. 468 [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic 469 Update", RFC 3007, November 2000. 471 [11] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS 472 Extensions to Support IP Version 6", RFC 3596, October 2003. 474 [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless 475 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 477 Author's Address 479 Bernard Volz 480 Cisco Systems, Inc. 481 1414 Massachusetts Ave. 482 Boxborough, MA 01719 483 USA 485 Phone: +1 978 936 0382 486 EMail: volz@cisco.com 488 Intellectual Property Statement 490 The IETF takes no position regarding the validity or scope of any 491 Intellectual Property Rights or other rights that might be claimed to 492 pertain to the implementation or use of the technology described in 493 this document or the extent to which any license under such rights 494 might or might not be available; nor does it represent that it has 495 made any independent effort to identify any such rights. Information 496 on the procedures with respect to rights in RFC documents can be 497 found in BCP 78 and BCP 79. 499 Copies of IPR disclosures made to the IETF Secretariat and any 500 assurances of licenses to be made available, or the result of an 501 attempt made to obtain a general license or permission for the use of 502 such proprietary rights by implementers or users of this 503 specification can be obtained from the IETF on-line IPR repository at 504 http://www.ietf.org/ipr. 506 The IETF invites any interested party to bring to its attention any 507 copyrights, patents or patent applications, or other proprietary 508 rights that may cover technology that may be required to implement 509 this standard. Please address the information to the IETF at 510 ietf-ipr@ietf.org. 512 Disclaimer of Validity 514 This document and the information contained herein are provided on an 515 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 516 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 517 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 518 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 519 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 520 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 522 Copyright Statement 524 Copyright (C) The Internet Society (2004). This document is subject 525 to the rights, licenses and restrictions contained in BCP 78, and 526 except as set forth therein, the authors retain all their rights. 528 Acknowledgment 530 Funding for the RFC Editor function is currently provided by the 531 Internet Society.