idnits 2.17.1 draft-ietf-dhc-dhcpv6-fqdn-05.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 611. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 6582 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) ** Obsolete normative reference: RFC 3041 (ref. '6') (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3513 (ref. '7') (Obsoleted by RFC 4291) -- No information found for draft-ietf-dhc-ddns-resolution- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '8' -- No information found for draft-ietf-dhc-fqdn-option- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1594 (ref. '10') (Obsoleted by RFC 2664) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 11 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: September 23, 2006 March 22, 2006 6 The DHCPv6 Client FQDN Option 7 draft-ietf-dhc-dhcpv6-fqdn-05.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 19 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 September 23, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document specifies a new Dynamic Host Configuration Protocol for 41 IPv6, DHCPv6, option which can be used to exchange information about 42 a DHCPv6 client's fully-qualified domain name and about 43 responsibility for updating DNS RRs related to the client's address 44 assignments. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Models of Operation . . . . . . . . . . . . . . . . . . . . . 3 51 4. The DHCPv6 Client FQDN Option . . . . . . . . . . . . . . . . 4 52 4.1. The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 53 4.2. The Domain Name Field . . . . . . . . . . . . . . . . . . 6 54 5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 6 55 5.1. Client Desires to Update AAAA RRs . . . . . . . . . . . . 7 56 5.2. Client Desires Server to Do DNS Updates . . . . . . . . . 7 57 5.3. Client Desires No Server DNS Updates . . . . . . . . . . . 7 58 5.4. Domain Name and DNS Update Issues . . . . . . . . . . . . 8 59 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 9 60 6.1. When to Perform DNS Updates . . . . . . . . . . . . . . . 9 61 7. DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 8. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 11 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 68 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 Intellectual Property and Copyright Statements . . . . . . . . . . 15 72 1. Introduction 74 DNS ([2], [3]) maintains (among other things) the information about 75 mapping between hosts' Fully Qualified Domain Names (FQDNs) [10] and 76 IPv6 addresses assigned to the hosts. The information is maintained 77 in two types of Resource Records (RRs): AAAA and PTR [12]. The DNS 78 update specification ([4]) describes a mechanism that enables DNS 79 information to be updated over a network. 81 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [5] 82 provides a mechanism by which a host (a DHCPv6 client) can acquire 83 certain configuration information, along with its stateful IPv6 84 address(es). This document specifies a new DHCPv6 option, the Client 85 FQDN option, which can be used by DHCPv6 clients and servers to 86 exchange information about the client's fully-qualified domain name 87 and who has the responsibility for updating the DNS with the 88 associated AAAA and PTR RRs. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [1]. 96 Familiarity with the DNS Update protocol [4], DHCPv6, and DHCPv6 97 terminology as defined in [5] is assumed. 99 3. Models of Operation 101 When a DHCPv6 client acquires an address, a site's administrator may 102 desire that the AAAA RR for the client's FQDN and the PTR RR for the 103 acquired address be updated. Therefore, two separate DNS update 104 transactions may occur. Acquiring an address via DHCPv6 involves two 105 entities: a DHCPv6 client and a DHCPv6 server. In principle each of 106 these entities could perform none, one, or both of the DNS update 107 transactions. However, in practice not all permutations make sense. 108 The DHCPv6 Client FQDN option is primarily intended to operate in the 109 following two cases: 111 1. DHCPv6 client updates the AAAA RR, DHCPv6 server updates the PTR 112 RR 113 2. DHCPv6 server updates both the AAAA and the PTR RRs 115 The only difference between these two cases is whether the FQDN to 116 IPv6 address mapping is updated by a DHCPv6 client or by a DHCPv6 117 server. The IPv6 address to FQDN mapping is updated by a DHCPv6 118 server in both cases. 120 The reason these two are important, while others are unlikely, has to 121 do with authority over the respective DNS domain names. A DHCPv6 122 client may be given authority over mapping its own AAAA RRs, or that 123 authority may be restricted to a server to prevent the client from 124 listing arbitrary addresses or associating its addresses with 125 arbitrary domain names. In all cases, the only reasonable place for 126 the authority over the PTR RRs associated with the address is in the 127 DHCPv6 server that allocates the address. 129 Note: A third case is supported - the client requests that the server 130 perform no updates. However, this case is presumed to be rare 131 because of the authority issues. 133 In any case, whether a site permits all, some, or no DHCPv6 servers 134 and clients to perform DNS updates into the zones which it controls 135 is entirely a matter of local administrative policy. This document 136 does not require any specific administrative policy, and does not 137 propose one. The range of possible policies is very broad, from 138 sites where only the DHCPv6 servers have been given credentials that 139 the DNS servers will accept, to sites where each individual DHCPv6 140 client has been configured with credentials which allow the client to 141 modify its own domain name. Compliant implementations MAY support 142 some or all of these possibilities. Furthermore, this specification 143 applies only to DHCPv6 client and server processes: it does not apply 144 to other processes which initiate DNS updates. 146 This document describes a new DHCPv6 option which a client can use to 147 convey all or part of its domain name to a DHCPv6 server. Site- 148 specific policy determines whether DHCPv6 servers use the names that 149 clients offer or not, and what DHCPv6 servers do in cases where 150 clients do not supply domain names. 152 4. The DHCPv6 Client FQDN Option 154 To update the IPv6 address to FQDN mapping a DHCPv6 server needs to 155 know the FQDN of the client for the addresses for the client's IA_NA 156 bindings. To allow the client to convey its FQDN to the server this 157 document defines a new DHCPv6 option, called "Client FQDN". The 158 Client FQDN option also contains Flags which DHCPv6 clients and 159 servers use to negotiate who does which updates. 161 The code for this option is TBD. Its minimum length is 1 octet. 163 The format of the DHCPv6 Client FQDN option is shown below: 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | OPTION_FQDN | option-len | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | flags | | 171 +-+-+-+-+-+-+-+-+ | 172 . . 173 . domain-name . 174 . . 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 option-code OPTION_CLIENT_FQDN (TBD) 179 option-len 1 + length of domain name 181 flags flag bits used between client and server to 182 negotiate who performs which updates 184 domain-name the partial or fully qualified domain name 185 (with length option-len - 1) 187 The Client FQDN option MUST only appear in a message's options field 188 and applies to all addresses for all IA_NA bindings in the 189 transaction. 191 4.1. The Flags Field 193 The format of the Flags field is: 195 0 1 2 3 4 5 6 7 196 +-+-+-+-+-+-+-+-+ 197 | MBZ |N|O|S| 198 +-+-+-+-+-+-+-+-+ 200 The "S" bit indicates whether the server SHOULD or SHOULD NOT perform 201 the AAAA RR (FQDN to address) DNS updates. A client sets the bit to 202 0 to indicate the server SHOULD NOT perform the updates and 1 to 203 indicate the server SHOULD perform the updates. The state of the bit 204 in the reply from the server indicates the action to be taken by the 205 server; if 1, the server has taken responsibility for AAAA RR updates 206 for the FQDN. 208 The "O" bit indicates whether the server has overridden the client's 209 preference for the "S" bit. A client MUST set this bit to 0. A 210 server MUST set this bit to 1 if the "S" bit in its reply to the 211 client does not match the "S" bit received from the client. 213 The "N" bit indicates whether the server SHOULD NOT perform any DNS 214 updates. A client sets this bit to 0 to request that the server 215 SHOULD perform updates (the PTR RR and possibly the AAAA RR based on 216 the "S" bit) or to 1 to request that the server SHOULD NOT perform 217 any DNS updates. A server sets the "N" bit to indicate whether the 218 server SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N" 219 bit is 1, the "S" bit MUST be 0. 221 The remaining bits in the Flags field are reserved for future 222 assignment. DHCPv6 clients and servers which send the Client FQDN 223 option MUST clear the MBZ bits, and they MUST ignore these bits. 225 4.2. The Domain Name Field 227 The Domain Name part of the option carries all or part of the FQDN of 228 a DHCPv6 client. The data in the Domain Name field MUST be encoded 229 as described in Section 8 of [5]. In order to determine whether the 230 FQDN has changed between message exchanges, the client and server 231 MUST NOT alter the Domain Name field contents unless the FQDN has 232 actually changed. 234 A client MAY be configured with a fully-qualified domain name or with 235 a partial name that is not fully-qualified. If a client knows only 236 part of its name, it MAY send a name that is not fully-qualified, 237 indicating that it knows part of the name but does not necessarily 238 know the zone in which the name is to be embedded. 240 To send a fully-qualified domain name, the Domain Name field is set 241 to the DNS encoded domain name including the terminating zero-length 242 label. To send a partial name, the Domain Name field is set to the 243 DNS encoded domain name without the terminating zero-length label. 245 A client MAY also leave the Domain Name field empty if it desires the 246 server to provide a name. 248 Servers SHOULD send the complete fully-qualified domain name in 249 Client FQDN options. 251 5. DHCPv6 Client Behavior 253 The following describes the behavior of a DHCPv6 client that 254 implements the Client FQDN option. 256 A client MUST only include the Client FQDN option in SOLICIT, 257 REQUEST, RENEW, or REBIND messages. 259 A client that sends the Client FQDN option MUST also include the 260 option in the Option Request option if it expects the server to 261 include the Client FQDN option in any responses. 263 5.1. Client Desires to Update AAAA RRs 265 If a client that owns/maintains its own FQDN wants to be responsible 266 for updating the FQDN to IPv6 address mapping for the FQDN and 267 address(es) used by the client, the client MUST include the Client 268 FQDN option in the SOLICIT with Rapid Commit, REQUEST, RENEW, and 269 REBIND message originated by the client. A client MAY choose to 270 include the Client FQDN option in its SOLICIT messages. The "S", 271 "O", and "N" bits in the Flags field in the option MUST be 0. 273 Once the client's DHCPv6 configuration is completed (the client 274 receives a REPLY message and successfully completes a final check on 275 the parameters passed in the message), the client MAY originate an 276 update for the AAAA RRs (associated with the client's FQDN) unless 277 the server has set the "S" bit to 1. If the "S" is 1, the DHCPv6 278 client SHOULD NOT initiate an update for the name in the server's 279 returned Client FQDN option Domain Name field. However, a DHCPv6 280 client that is explicitly configured with a FQDN MAY ignore the state 281 of the "S" bit if the server's returned name matches the client's 282 configured name. 284 5.2. Client Desires Server to Do DNS Updates 286 A client can choose to delegate the responsibility for updating the 287 FQDN to IPv6 address mapping for the FQDN and address(es) used by the 288 client to the server. In order to inform the server of this choice, 289 the client SHOULD include the Client FQDN option in its SOLICIT with 290 Rapid Commit, REQUEST, RENEW, and REBIND message and MAY include the 291 Client FQDN option in its SOLICIT. The "S" bit in the Flags field in 292 the option MUST be 1 and the "O" and "N" bits MUST be 0. 294 5.3. Client Desires No Server DNS Updates 296 A client can choose to request that the server perform no DNS updates 297 on its behalf. In order to inform the server of this choice, the 298 client SHOULD include the Client FQDN option in its SOLICIT with 299 Rapid Commit, REQUEST, RENEW, and REBIND messages and MAY include the 300 Client FQDN option in its SOLICIT. The "N" bit in the Flags field in 301 the option MUST be 1 and the "S" and "O" bits MUST be 0. 303 Once the client's DHCPv6 configuration is completed (the client 304 receives a REPLY message and successfully completes a final check on 305 the parameters passed in the message), the client MAY originate its 306 DNS updates provided the server's "N" bit is 1. If the server's "N" 307 bit is 0, the server MAY perform the PTR RR updates; and, MAY also 308 perform the AAAA RR updates if the "S" bit is 1. 310 5.4. Domain Name and DNS Update Issues 312 As there is a possibility that the DHCPv6 server is configured to 313 complete or replace a domain name that the client sends, the client 314 MAY find it useful to send the Client FQDN option in its SOLICIT 315 messages. If the DHCPv6 server returns different Domain Name data in 316 its ADVERTISE message, the client could use that data in performing 317 its own eventual AAAA RR update, or in forming the Client FQDN option 318 that it sends in its subsequent messages. There is no requirement 319 that the client send identical Client FQDN option data in its 320 SOLICIT, REQUEST, RENEW, or REBIND messages. In particular, if a 321 client has sent the Client FQDN option to its server, and the 322 configuration of the client changes so that its notion of its domain 323 name changes, it MAY send the new name data in a Client FQDN option 324 when it communicates with the server again. This MAY cause the 325 DHCPv6 server to update the name associated with the PTR records, 326 and, if the server updated the AAAA record representing the client, 327 to delete that record and attempt an update for the client's current 328 domain name. 330 A client that delegates the responsibility for updating the FQDN to 331 IPv6 address mapping to a server will not receive any indication 332 (either positive or negative) from the server whether the server was 333 able to perform the update. The client MAY use a DNS query to check 334 whether the mapping is up to date. However, depending on the load on 335 the DHCPv6 and DNS servers and the DNS propagation delays, the client 336 can only infer success. If the information is not found to be up to 337 date in DNS, the authoritative servers might not have completed the 338 updates or zone transfers, or caching resolvers may yet have updated 339 their caches. 341 If a client releases an address prior to the expiration of the valid 342 lifetime and the client is responsible for updating its AAAA RR, the 343 client SHOULD delete the AAAA RR associated with the address before 344 sending a RELEASE message. Similarly, if a client is responsible for 345 updating its AAAA RRs, but is unable to renew the lifetimes for an 346 address, the client SHOULD attempt to delete the AAAA RR before the 347 lifetime on the address is no longer valid. A DHCPv6 client which 348 has not been able to delete an AAAA RR which it added SHOULD attempt 349 to notify its administrator, perhaps by emitting a log message. 351 A client SHOULD NOT perform DNS updates to AAAA RRs for its non- 352 Global Unicast addresses [7] or temporary addresses [6]. 354 6. DHCPv6 Server Behavior 356 The following describes the behavior of a DHCPv6 server that 357 implements the Client FQDN option when the client's message includes 358 the Client FQDN option. 360 Servers MUST only include a Client FQDN option in ADVERTISE and REPLY 361 messages if the client included a Client FQDN option and the Client 362 FQDN option is requested by the Option Request Option in the client's 363 message to which the server is responding. 365 The server examines its configuration and the Flag bits in the 366 client's Client FQDN option to determine how to respond: 368 o The server sets to 0 the "S", "O", and "N" bits in its copy of the 369 option it will return to the client. 370 o If the client's "N" bit is 1 and the server's configuration allows 371 it to honor the client's request for no server initiated DNS 372 updates, the server sets the "N" bit to 1. 373 o Otherwise, if the client's "S" bit is 1 and the server's 374 configuration allows it to honor the client's request for the 375 server to initiate AAAA RR DNS updates, the server sets the "S" to 376 1. If the server's "S" bit does not match the client's "S" bit, 377 the server sets the "O" bit to 1. 379 The server MAY be configured to use the name supplied in the client's 380 Client FQDN option, or it MAY be configured to modify the supplied 381 name, or substitute a different name. The server SHOULD send its 382 notion of the complete FQDN for the client in the Domain Name field. 383 The server MAY simply copy the Domain Name field from the Client FQDN 384 option that the client sent to the server. 386 6.1. When to Perform DNS Updates 388 The server SHOULD NOT perform any DNS updates if the "N" bit is 1 in 389 the Flags field of the Client FQDN option in the REPLY messages (to 390 be) sent to the client. However, the server SHOULD delete any RRs 391 which it previously added via DNS updates for the client. 393 The server MAY perform the PTR RR DNS update (unless the "N" bit is 394 1). 396 The server MAY perform the AAAA RR DNS update if the "S" bit is 1 in 397 the Flags field of the Client FQDN option in the REPLY message (to 398 be) sent to the client. 400 The server MAY perform these updates even if the client's message did 401 not carry the Client FQDN option. The server MUST NOT initiate DNS 402 updates when responding with an ADVERTISE message to the client. 404 The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR) 405 before or after sending the REPLY message to the client. 407 If the server's AAAA RR DNS update does not complete until after the 408 server has replied to the DHCPv6 client, the server's interaction 409 with the DNS server MAY cause the DHCPv6 server to change the domain 410 name that it associates with the client. This can occur, for 411 example, if the server detects and resolves a domain-name conflict 412 [8]. In such cases, the domain name that the server returns to the 413 DHCPv6 client would change between two DHCPv6 exchanges. 415 If the server previously performed DNS updates for the client and the 416 client's information has not changed, the server MAY skip performing 417 additional DNS updates. 419 When a server receives a RELEASE or DECLINE for an address, detects 420 that the valid lifetime on an address that the server bound to a 421 client has expired, or terminates a binding on an address prior to 422 the binding's expiration time (for instance, by sending a REPLY with 423 a zero valid lifetime for an address), the server SHOULD delete any 424 PTR RR which it associated with the address via DNS update. In 425 addition, if the server took responsibility for AAAA RRs, the server 426 SHOULD also delete the AAAA RR. 428 7. DNS RR TTLs 430 RRs associated with DHCP clients may be more volatile than statically 431 configured RRs. DHCP clients and servers that perform dynamic 432 updates should attempt to specify resource record TTLs which reflect 433 this volatility, in order to minimize the possibility that answers to 434 DNS queries will return records that refer to DHCP IP address 435 assignments that have expired or been released. 437 The coupling among primary, secondary, and caching DNS servers is 438 'loose'; that is a fundamental part of the design of the DNS. This 439 looseness makes it impossible to prevent all possible situations in 440 which a resolver may return a record reflecting a DHCP assigned IP 441 address that has expired or been released. In deployment, this 442 rarely, if ever, represents a significant problem. Most DHCP-managed 443 clients are infrequently looked-up by name in the DNS, and the 444 deployment of IXFR ([13]) and NOTIFY ([14]) can reduce the latency 445 between updates and their visibility at secondary servers. 447 We suggest these basic guidelines for implementers. In general, the 448 TTLs for RRs added as a result of DHCP IP address assignment activity 449 SHOULD be less than the initial lifetime. The RR TTL on a DNS record 450 added SHOULD NOT exceed 1/3 of the lifetime, but SHOULD NOT be less 451 than 10 minutes. We recognize that individual administrators will 452 have varying requirements: DHCP servers and clients SHOULD allow 453 administrators to configure TTLs and upper and lower bounds on the 454 TTL values, either as an absolute time interval or as a percentage of 455 the lease lifetime. 457 While clients and servers MAY update the TTL of the records as the 458 lifetime is about to expire, there is no requirement that they do so 459 as this puts additional load on the DNS system with likely little 460 benefit. 462 8. DNS Update Conflicts 464 This document does not resolve how a DHCPv6 client or server prevent 465 name conflicts. This document addresses only how a DHCPv6 client and 466 server negotiate the fully qualified domain name and who will perform 467 the DNS updates. 469 Implementers of this work will need to consider how name conflicts 470 will be prevented. If a DNS updater needs a security token in order 471 to successfully perform DNS updates on a specific name, name 472 conflicts can only occur if multiple updaters are given a security 473 token for that name. Or, if the fully qualified domains are based on 474 the specific address bound to a client, conflicts will not occur. 475 Or, a name conflict resolution technique as described in "Resolving 476 Name Conflicts" [8]) SHOULD be used. 478 9. IANA Considerations 480 IANA is requested to assign a DHCPv6 option code for the Client FQDN 481 option. 483 10. Security Considerations 485 Unauthenticated updates to the DNS can lead to tremendous confusion, 486 through malicious attack or through inadvertent misconfiguration. 487 Administrators need to be wary of permitting unsecured DNS updates to 488 zones which are exposed to the global Internet. Both DHCPv6 clients 489 and servers SHOULD use some form of update request origin 490 authentication procedure (e.g., Secure DNS Dynamic Update [11]) when 491 performing DNS updates. 493 Whether a DHCPv6 client is responsible for updating an FQDN to IPv6 494 address mapping or whether this is the responsibility of the DHCPv6 495 server is a site-local matter. The choice between the two 496 alternatives is likely based on the security model that is used with 497 the DNS update protocol (e.g., only a client may have sufficient 498 credentials to perform updates to the FQDN to IPv6 address mapping 499 for its FQDN). 501 Whether a DHCPv6 server is always responsible for updating the FQDN 502 to IPv6 address mapping (in addition to updating the IPv6 to FQDN 503 mapping), regardless of the wishes of an individual DHCPv6 client, is 504 also a site-local matter. The choice between the two alternatives is 505 likely based on the security model that is being used with DNS 506 updates. In cases where a DHCPv6 server is performing DNS updates on 507 behalf of a client, the DHCPv6 server SHOULD be sure of the DNS name 508 to use for the client, and of the identity of the client. 510 Depending on the presence of or type of authentication used with the 511 Authentication option, a DHCPv6 server may not have much confidence 512 in the identities of its clients. There are many ways for a DHCPv6 513 server to develop a DNS name to use for a client, but only in certain 514 circumstances will the DHCPv6 server know for certain the identity of 515 the client. 517 It is critical to implement proper conflict resolution, and the 518 security considerations of conflict resolution apply [8]. 520 11. Acknowledgements 522 Many thanks to Mark Stapp and Yakov Rekhter as this document is based 523 on the DHCPv4 Client FQDN option (draft-ietf-dhc-fqdn-option [9]). 524 And, to Ralph Droms, Ted Lemon, Josh Littlefield, Kim Kinnear, Pekka 525 Savola, and Mark Stapp for their review and comments. 527 12. References 529 12.1. Normative References 531 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 532 Levels", BCP 14, RFC 2119, March 1997. 534 [2] Mockapetris, P., "Domain names - concepts and facilities", 535 STD 13, RFC 1034, November 1987. 537 [3] Mockapetris, P., "Domain names - implementation and 538 specification", STD 13, RFC 1035, November 1987. 540 [4] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 541 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 542 April 1997. 544 [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 545 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 546 RFC 3315, July 2003. 548 [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless 549 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 551 [7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 552 Addressing Architecture", RFC 3513, April 2003. 554 [8] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients 555 (draft-ietf-dhc-ddns-resolution-*.txt)", February 2006. 557 12.2. Informative References 559 [9] Stapp, M., Volz, B., and Y. Rekhter, "The DHCP Client FQDN 560 Option (draft-ietf-dhc-fqdn-option-*.txt)", February 2006. 562 [10] Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions and 563 Answers - Answers to Commonly asked "New Internet User" 564 Questions", RFC 1594, March 1994. 566 [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic 567 Update", RFC 3007, November 2000. 569 [12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS 570 Extensions to Support IP Version 6", RFC 3596, October 2003. 572 [13] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 573 August 1996. 575 [14] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes 576 (DNS NOTIFY)", RFC 1996, August 1996. 578 Author's Address 580 Bernard Volz 581 Cisco Systems, Inc. 582 1414 Massachusetts Ave. 583 Boxborough, MA 01719 584 USA 586 Phone: +1 978 936 0382 587 Email: volz@cisco.com 589 Intellectual Property Statement 591 The IETF takes no position regarding the validity or scope of any 592 Intellectual Property Rights or other rights that might be claimed to 593 pertain to the implementation or use of the technology described in 594 this document or the extent to which any license under such rights 595 might or might not be available; nor does it represent that it has 596 made any independent effort to identify any such rights. Information 597 on the procedures with respect to rights in RFC documents can be 598 found in BCP 78 and BCP 79. 600 Copies of IPR disclosures made to the IETF Secretariat and any 601 assurances of licenses to be made available, or the result of an 602 attempt made to obtain a general license or permission for the use of 603 such proprietary rights by implementers or users of this 604 specification can be obtained from the IETF on-line IPR repository at 605 http://www.ietf.org/ipr. 607 The IETF invites any interested party to bring to its attention any 608 copyrights, patents or patent applications, or other proprietary 609 rights that may cover technology that may be required to implement 610 this standard. Please address the information to the IETF at 611 ietf-ipr@ietf.org. 613 Disclaimer of Validity 615 This document and the information contained herein are provided on an 616 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 617 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 618 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 619 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 620 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 621 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 623 Copyright Statement 625 Copyright (C) The Internet Society (2006). This document is subject 626 to the rights, licenses and restrictions contained in BCP 78, and 627 except as set forth therein, the authors retain all their rights. 629 Acknowledgment 631 Funding for the RFC Editor function is currently provided by the 632 Internet Society.