DHC B. Volz Internet-Draft Cisco Systems, Inc. Expires:March 17,July 29, 2005 January 25, 2005September 16, 2004The DHCPv6 Client FQDN Optiondraft-ietf-dhc-dhcpv6-fqdn-00.txtdraft-ietf-dhc-dhcpv6-fqdn-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions ofsectionSection 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onMarch 17,July 29, 2005. Copyright Notice Copyright (C) The Internet Society(2004).(2005). Abstract This document specifies a newDHCPDynamic Host Configuration Protocol for IPv6, DHCPv6, option which can be used to exchange information about a DHCPv6 client's fully-qualified domain name and about responsibility for updating DNS RRs related to the client's address assignments. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . ..3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . ..3 3. Models of Operation . . . . . . . . . . . . . . . . . . . ..3 4. The DHCPv6 Client FQDN Option . . . . . . . . . . . . . . ..4 4.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 4.2 The Domain Name Field . . . . . . . . . . . . . . . . . . 6 5. DHCPv6 ClientbehaviorBehavior . . . . . . . . . . . . . . . . . . . 6 5.1 Client Desires to Update AAAA RRs . . . . . . . . . . . . 7 5.2 Client Desires Server to Do DNS Updates . . . . . . . . . 7 5.3 Client Desires No Server DNS Updates . . . . . . . . . . . 7 5.4 Domain Name and DNS Update Issues . . . . . . . . . . . . 8 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . ..8 6.1 When to Perform DNS Updates . . . . . . . . . . . . . . . 9 7. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . .. 910 8.SecurityIANA Considerations . . . . . . . . . . . . . . . . . . .9. 10 9.AcknowledgementsSecurity Considerations . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . .10 10.. . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . .10 10.111 11.1 Normative References . . . . . . . . . . . . . . . . . .. . 10 10.211 11.2 Informative References . . . . . . . . . . . . . . . . .. . 1112 Author's Address . . . . . . . . . . . . . . . . . . . . . .. 1112 Intellectual Property and Copyright Statements . . . . . . .. 1213 1. Introduction DNS ([2], [3]) maintains (among other things) the information about mapping between hosts' Fully Qualified Domain Names (FQDNs) [8] andIPIPv6 addresses assigned to the hosts. The information is maintained in two types of Resource Records (RRs): AAAA and PTR[11].[10]. The DNS update specification ([4]) describes a mechanism that enables DNS information to be updated over a network. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [5] provides a mechanism by which a host (a DHCPv6 client) can acquire certain configuration information, along with its stateful IPv6 address(es). This document specifies a new DHCPv6 option, the Client FQDN option, which can be used by DHCPv6 clients and servers to exchange information about the client's fully-qualified domain name and who has the responsibility for updating the DNS with the associated AAAA and PTR RRs. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. Familiarity with the DNS Update protocol [4], DHCPv6, and DHCPv6 terminology as defined in [5] is assumed. 3. Models of Operation When a DHCPv6 client acquires an address, a site's administrator may desire that the AAAA RR for the client's FQDN and the PTR RR for the acquired address be updated. Therefore, two separate DNS update transactions may occur. Acquiring an address via DHCPv6 involves two entities: a DHCPv6 client and a DHCPv6 server. In principle each of these entities could perform none, one, or both of the DNS update transactions. However, in practice not all permutations make sense. The DHCPv6 Client FQDN option is primarily intended to operate in the following two cases: 1. DHCPv6 client updates the AAAA RR, DHCPv6 server updates the PTR RR 2. DHCPv6 server updates both the AAAA and the PTR RRs The only difference between these two cases is whether the FQDN to IPv6 address mapping is updated by a DHCPv6 client or by a DHCPv6 server. The IPv6 address to FQDN mapping is updated by a DHCPv6 server in both cases. The reason these two are important, while others are unlikely, has to do with authority over the respective DNS domain names. A DHCPv6 client may be given authority over mapping its own AAAA RRs, or that authority may be restricted to a server to prevent the client from listing arbitrary addresses or associating its addresses with arbitrary domain names. In all cases, the only reasonable place for the authority over the PTR RRs associated with the address is in the DHCPv6 server that allocates the address. Note: A third case is supported - the client requests that the server perform no updates. However, this case is presumed to be rare because of the authority issues. In any case, whether a site permits all, some, or no DHCPv6 servers and clients to perform DNS updates into the zones which it controls is entirely a matter of local administrative policy. This document does not require any specific administrative policy, and does not propose one. The range of possible policies is very broad, from sites where only the DHCPv6 servers have been given credentials that the DNS servers will accept, to sites where each individual DHCPv6 client has been configured with credentials which allow the client to modify its own domain name. Compliant implementations MAY support some or all of these possibilities. Furthermore, this specification applies only to DHCPv6 client and server processes: it does not apply to other processes which initiate DNS updates. This document describes a new DHCPv6 option which a client can use to convey all or part of its domain name to a DHCPv6 server. Site-specific policy determines whether DHCPv6 servers use the names that clients offer or not, and what DHCPv6 serversmaydo in cases where clients do not supply domain names.Other work, such as "Resolving Name Conflicts" [6], may define procedures for establishing policy and arbitrating conflicts when collisions occur in the use of FQDNs by DHCPv6 clients.4. The DHCPv6 Client FQDN Option To update the IPv6 address to FQDN mapping a DHCPv6 server needs to know the FQDN of the client for the addressesin a binding.for the client's IA_NA bindings. To allow the client to convey its FQDN to the server this document defines a new DHCPv6 option, called "Client FQDN". The Client FQDN option also contains Flags which DHCPv6 clients and servers use to negotiate who does which updates. The code for this option is TBD. Its minimum length is2.1 octet. TheFormatformat of the DHCPv6 Client FQDN option is shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_FQDN | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | | +-+-+-+-+-+-+-+-+ | . . . domain-name . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_CLIENT_FQDN (TBD) option-len 1 + length of domain name flags flag bits used between client and server to negotiate who performs which updates domain-name the partial or fully qualified domain name (with length option-len - 1) The Client FQDN option MUST only appear inIA_NA-options and IA_TA-options (see [12]) fieldsa message's options field and applies to all addresses forthat binding.all IA_NA bindings in the transaction. 4.1 The Flags Field TheFormatformat of the Flagsfield:field is: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | MBZ |N|O|S| +-+-+-+-+-+-+-+-+When a DHCPv6 client sendsThe "S" bit indicates whether theClient FQDN option, itserver SHOULD or SHOULD NOT perform the AAAA RR (FQDN to address) DNS updates. A client sets the"S"bit to 0 to indicatethat it will notthe server SHOULD NOT performany DNS updates,the updates andthat it expects1 to indicate theDHCPv6servertoSHOULD performany FQDN-to-IPv6 (the AAAA RR) DNS updates on its behalf. If thisthe updates. The state of the bitis clear,in theclientreply from the server indicatesthat it intendsthe action toperformbe taken by the server; if 1, theFQDN-to-IPv6 DNS updates. If a DHCPv6serverintends to takehas taken responsibility fortheAAAA RRupdates, whether or not the client sending the Client FQDN option has set the "S" bit, it sets both the "O" and "S" bits, and sends the Client FQDN option in its response message. Clients SHOULD clearupdates for the FQDN. The "O" bitbefore sendingindicates whether theClient FQDN option and servers MUST ignoreserver has overridden thereceived state ofclient's preference for the"O""S" bit. A clientMAYMUST set this bit to 0. A server MUST set this bit to 1 if the"N""S" bit in itsrequest messagesreply toindicate thattheserver shouldclient does not match the "S" bit received from the client. The "N" bit indicates whether the server SHOULD NOT perform any DNSupdates on its behalf. As mentioned in Section 3, in generalupdates. A client sets this bit to 0 to request that theDHCPv6serverwill be maintaining DNSSHOULD perform updates (the PTRrecordsRR and possibly the AAAA RR based onbehalf of clients. However, there may be deployments in which clients are configuredthe "S" bit) or to 1 to request that the server SHOULD NOT performall desired DNS updates or may not wantany DNS updates.The server MAY be configured to honor this configuration. If theA serverhas been configured to honor a client's "N" indication, it SHOULD setsets the "N" bitin Client FQDN options which it sendsto indicate whether theclient in its response messages. Clients which have setserver SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N" bitin their requests SHOULD use the state ofis 1, the"N""S" bitin server responses to determine whether the server was prepared to honor the client's indication. If a client has set the "N" bit but its server does not, the client SHOULD conclude that the server was not configured to honor the client's suggestion, and that the server may attempt to perform DNS updates on its behalf. The remaining bitsMUST be 0. The remaining bits in the Flags field are reserved for future assignment. DHCPv6 clients and servers which send the Client FQDN option MUSTsetclear the MBZbits to 0,bits, and they MUST ignore these bits. 4.2 The Domain Name Field The Domain Namefieldpart of the option carries all or part of the FQDN of a DHCPv6 client. The data in the Domain Name field MUSTappear in uncompressed DNS encodingbe encoded asspecifieddescribed in[3].Section 8 of [5]. In order to determine whethera namethe FQDN has changed between message exchanges,an unambiguous canonical form is necessary. Eventually,theIETF IDN Working Group is expected to produce a standard canonicalization specification, and this specification may be updated to include its standard. Until that time, serversclient andclients should be sensitive to canonicalization when comparing names inserver MUST NOT alter the Domain Name fieldandcontents unless thename canonicalization defined in [9] MAY be used.FQDN has actually changed. A clientmayMAY be configured with a fully-qualified domainname,name or with a partial name that is not fully-qualified. If a client knows only part of its name, it MAY send a name that is not fully-qualified, indicating that it knows part of the name but does not necessarily know the zone in which the name is to be embedded.A client which wants to convey part of its FQDN sendsTo send anon-terminal sequence of labels infully-qualified domain name, the Domain Name field is set to the DNS encoded domain namefield ofincluding theoption. Clients and servers should assume thatterminating zero-length label. To send a partial name, the Domain Name field is set to the DNS encoded domain name without the terminating zero-length label. A client MAY also leave the Domain Name fieldcontainsempty if it desires the server to provide afully-qualified name unless this partial-name format exists.name. ServersMUST alwaysSHOULD send the complete fully-qualified domain name in Client FQDN options. 5. DHCPv6 ClientbehaviorBehavior The following describes the behavior of a DHCPv6 client that implements the Client FQDN option. A client MUST only include the Client FQDNoptions in the IA_NA-options and IA_TA-options fieldsoption in SOLICIT, REQUEST, RENEW, or REBIND messages. A client that sends the Client FQDN option MUST also include the option in the Option Request option if it expects the server to include the Client FQDN option in any responses.A client sends the5.1 Client Desires to Update AAAA RRs If a client that owns/maintains its own FQDNoption with no Flags bits set,wants to be responsible for updating the"S" Flags bit set, orFQDN to IPv6 address mapping for the"N" Flags bit setFQDN andwithaddress(es) used by thedesired partial or fully qualified domain name. There is no requirement thatclient, the clientsend identical Client FQDN options data in each of its messages to a server. In particular, if a client has sentMUST include the Client FQDNoptions to its server, andoption in theconfiguration ofSOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message originated by the client. A clientchanges so that its notion of its domain name changes, itMAYsendchoose to include thenew name data in aClient FQDNoptions when it communicates with the server again. This may cause the DHCPv6 server to update the name associated with the PTR record, and, if the server updatedoption in its SOLICIT messages. The "S" bit in theAAAA record representingFlags field in theclient, to delete that recordoption MUST be 0. The "O" andattempt an update for the client's current domain name."N" bits MUST be 0. Once the client's DHCPv6 configuration is completed (the client receives a REPLYmessage,message and successfully completes a final check on the parameters passed in the message), the clientSHOULDMAY originatethe DNS updatesan update for the AAAARRRRs (associated with the client'sFQDNs) for any Client FQDN options for which the received "S" and the "O" bits inFQDN) unless theoption's Flags field are notserver has setand if it is otherwise configured to perform the DNS updates. The update SHOULD be originated followingtheprocedures described in [4]."S" bit to 1. If theDHCPv6 server from which the client is requesting addresses includes Client FQDN options in its REPLY message, and if the server sets both the"S"and "O" bits in the option's Flags field,is 1, the DHCPv6 client MUST NOT initiate an update for the name in the Domain Namefield and the addresses in that binding.field. 5.2 Client Desires Server to Do DNS Updates A clientthat delegatescan choose to delegate the responsibility for updating theFQDN-to-IPv6FQDN to IPv6 address mappingto a server does not receive any indication (either positive or negative) fromfor theserver whetherFQDN and address(es) used by theserver was ableclient toperformtheupdate. If the client needsserver. In order to inform the server of this choice, the client SHOULD include the Client FQDN option in its SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message and MAY include the Client FQDN option in its SOLICIT. The "S" bit in the Flags field in the option MUST be 1. The "O" and "N" bits MUST be 0. 5.3 Client Desires No Server DNS Updates A client can choose to request that the server perform no DNS updates on its behalf. In order to inform the server of this choice, the client SHOULD include the Client FQDN option in its SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND messages and MAY include the Client FQDN option in its SOLICIT. The "N" bit in the Flags field in the option MUST be 1 and the "S" and "O" bits MUST be 0. Once the client's DHCPv6 configuration is completed (the client receives a REPLY message and successfully completes a final check on the parameters passed in the message), the client MAY originate its DNS updates provided the server's "N" bit is 1. If the server's "N" bit is 0, the server MAY perform the PTR RR updates; and, MAY also perform the AAAA RR updates if the "S" bit is 1. 5.4 Domain Name and DNS Update Issues As there is a possibility that the DHCPv6 server is configured to complete or replace a domain name that the client sends, the client MAY find it useful to send the Client FQDN option in its SOLICIT messages. If the DHCPv6 server returns different Domain Name data in its ADVERTISE message, the client could use that data in performing its own eventual AAAA RR update, or in forming the Client FQDN option that it sends in its subsequent messages. There is no requirement that the client send identical Client FQDN option data in its SOLICIT, REQUEST, RENEW, or REBIND messages. In particular, if a client has sent the Client FQDN option to its server, and the configuration of the client changes so that its notion of its domain name changes, it MAY send the new name data in a Client FQDN option when it communicates with the server again. This MAY cause the DHCPv6 server to update the name associated with the PTR records, and, if the server updated the AAAA record representing the client, toconfirmdelete that record and attempt an update for theDNS update, it SHOULDclient's current domain name. A client that delegates the responsibility for updating the FQDN to IPv6 address mapping to a server will not receive any indication (either positive or negative) from the server whether the server was able to perform the update. The client MAY use a DNS query to check whether the mapping isupdated.up to date. However, depending on the load on the DHCPv6 and DNS servers and the DNS propagation delays, the client can only infer success. If the information is not found to be up to date in DNS, the servers might not have completed the updates or zone transfers, or not yet updated their caches. If a client releases an address prior to thevalid lifetimeexpirationor is unable to extend the lifetimes for an address andof the valid lifetimeexpires,and the client is responsible for updating its AAAARRs,RR, the client SHOULD delete the AAAA RR associated with the address before sending a RELEASEmessage ormessage. Similarly, if a client is responsible for updating its AAAA RRs, but is unable to renew the lifetimes for an address, the client SHOULD attempt to delete the AAAA RR before the lifetimeexpires.on the address is no longer valid. A DHCPv6 client which has not been able to delete an AAAA RR which it added(because it has lost the use of addresses of sufficient scope to communicate with the DNS server or has exhausted retry limits) shouldSHOULD attempt to notify its administrator, perhaps by emitting a log message. 6. DHCPv6 Server Behavior The following describes the behavior of a DHCPv6 server that implements the Client FQDN option when the client's message includes the Client FQDN option. Servers MUST only include a Client FQDNoptions for a bindingoption in ADVERTISE and REPLY messages if the client included a Client FQDN optionfor that bindingand theClient FQDNClient FQDN option is requested by the Option Request Option in the client's message to which the server is responding. The server examines its configuration and the Flag bits in the client's Client FQDN option to determine how to respond: o The server sets to 0 the "S", "O", and "N" Flag bits in its copy of the optionis requested byit will return to theOption Request Option inclient. o If the client'smessage"N" bit is 1 and the server's configuration allows it towhichhonor the client's request for no serveris responding. Servers MUST only include Client FQDN options in the IA_NA-options and IA_TA-options fields in messages sent byinitiated DNS updates, theserver. When aserverallocates a new address from a binding, it usessets theClient FQDN option,"N" bit to 1. o Otherwise, ifany, intheIA_NA-options or IA_TA-options field of that bindingclient's "S" bit is 1 and the servers's configuration allows it todeterminehonor thefully qualified domain name and who will take responsibilityclient's request for the server to initiate AAAA RR DNSupdates. It recordsupdates and if it has the necessary credentials, the server sets the "S" to 1. If the server's "S" bit does not match the client's "S" bit, the server sets the "O" bit to 1. The server MAY be configured to use theresultsname supplied in the client's Client FQDNoption.option, or it MAY be configured to modify the supplied name, or substitute a different name. TheDHCPv6server SHOULD send its notion of the complete FQDN for the client in the Domain Name field. The server MAY simply copy theDomain NameDomain Name field from the Client FQDN option that the client sent to the server. 6.1 When to Perform DNS Updates The server SHOULD NOT perform any DNS updates if the "N" bit is 1 in the Flags field of the Client FQDN option in the REPLY messages (to be) sent to the client. However, the server SHOULD delete any RRs which it previously added via DNS updates for the client. The server MAY perform the PTR RR DNS update (unless the "N" bit is 1). The server MAY perform the AAAA RR DNS update if the "S" bit is 1 in the Flags fieldfromof the Client FQDN optionthatin theclientDHCPACK message (to be) sent to theserver.client. TheDHCPv6server MAYbe configured to complete or modifyperform these updates even if thedomain name which a client sent, or it MAY be configured to substitute a different name. If aclient'sSOLICIT, REQUEST, RENEW, or REBINDmessagedoesn't includedid not carry the Client FQDNoption for a binding (e.g.,option. The server MUST NOT initiate DNS updates when responding with an ADVERTISE message to theclient doesn't implementclient. The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR) before theClient FQDN option),server sends the REPLY message to the client. Alternatively, the server MAYbe configuredsend the REPLY message to the client without waiting for the update to be completed. Whether the DNS updateeitheroccurs before orboth ofafter theAAAA and PTR RRs.REPLY is sent is entirely up to the DHCPv6 server's configuration. Ifa client's message includes a Client FQDN option for a binding andtherequested domain-name is different fromserver's AAAA RR DNS update does not complete until after the server has replied to the DHCPv6 client, the server'scurrent knowledge ofinteraction with the DNS server MAY cause the DHCPv6 server to change thefully-qualifieddomain nameandthat it associates with the client. This can occur, for example, if the serveris configured to allow use ofdetects and resolves a domain-name conflict [6]. In such cases, the domain name thatname,the serverSHOULD performreturns to thenecessary DNS updates -DHCPv6 client would change between two DHCPv6 exchanges. If the serverSHOULD removepreviously performed DNS updates for theold PTR and AAAA RRs it added, if any,client andaddthenew RRs - if itclient's information hasthat responsibility.not changed, the server MAY skip performing additional DNS updates. When a server receives a RELEASE or DECLINE for an address, detects that the valid lifetime on an address that the server bound to a client has expired, or terminates a binding on an address prior to the binding's expiration time (for instance, by sending a REPLY with a zero valid lifetime for an address), the server SHOULD delete any PTRRRsRR which it associated with the address via DNS update. In addition, if the server took responsibility fortheAAAARR,RRs, the server SHOULD also deletethatthe AAAA RR.A server MAY initiate and complete the DNS update(s) before the server sends the REPLY message to the client. Alternatively, the server MAY send the REPLY message to the client without waiting for the update to be initiated or completed. The choice between the two alternatives is entirely determined by the configuration of the DHCPv6 server. Servers SHOULD support both configuration options. If the server initiates a DNS update that is not complete until after the server has replied to the client, the server's interaction with the DNS server may cause the DHCPv6 server to change the domain name that it associates with an address for the client. This may occur, for example, if the server detects and resolves a domain-name conflict. In such cases, the domain name that the server returns to the client may change between two DHCPv6 exchanges.7. DNS Update Conflicts This document does not resolve how a DHCPv6 client or server prevent name conflicts. This document addresses only how a DHCPv6 client and server negotiate the fully qualified domain name and who will perform the DNS updates. Implementers of this work will need to consider how name conflicts will be prevented.It may be that theIf a DNS updatermust holdneeds a security token in order to successfully perform DNS updates on a specific name,in which casename conflicts can only occur if multiple clients are given a security token for that name. Or, if the fully qualified domainsmay beare based on the specific address bound to aclient or the client's DUID, and in these casesclient, conflictsshould notSHOULD NOT occur.However, without this level of securityOr, a name conflict resolution technique as described inthe DNS system or use of non-conflicting names, other techniques need to"Resolving Name Conflicts" [6]) SHOULD bedeveloped. Thisused. 8. IANA Considerations IANA isan arearequested to assign a DHCPv6 option code forfuture work (see [6]). 8.the Client FQDN option. 9. Security Considerations Unauthenticated updates to the DNS can lead to tremendous confusion, through malicious attack or through inadvertent misconfiguration. Administratorsshouldneed to be wary of permitting unsecured DNS updates to zones which are exposed to the global Internet. Both DHCPv6 clients and servers SHOULD use some form of update request origin authentication procedure (e.g., Secure DNS Dynamic Update[10])[9]) when performing DNS updates. Whether a DHCPv6 clientmay beis responsible for updating an FQDN to IPv6 address mapping or whether this is the responsibility of the DHCPv6 server is a site-local matter. The choice between the two alternativesmay beis likely based on the security model that is used with the DNS update protocol (e.g., only a client may have sufficient credentials to perform updates to the FQDN toIPIPv6 address mapping for its FQDN). Whether a DHCPv6 server is always responsible for updating the FQDN to IPv6 address mapping (in addition to updating the IPv6 to FQDN mapping), regardless of the wishes of an individual DHCPv6 client, is also a site-local matter. The choice between the two alternativesmay beis likely based on the security model that is being used with DNS updates. In cases where a DHCPv6 server is performing DNS updates on behalf of a client, the DHCPv6 servershouldSHOULD be sure of the DNS name to use for the client, and of the identity of the client. Depending on the prescence of or type of authentication used with the Authentication option, a DHCPv6 server may not have much confidence in the identities of its clients. There are many ways for a DHCPv6 server to develop a DNS name to use for a client, but only in certain circumstances will the DHCPv6 server know for certain the identity of the client.9.10. Acknowledgements Many thanks to Mark Stapp and Yakov Rekhter as this document is based on the DHCPv4 Client FQDN option (draft-ietf-dhc-fqdn-option [7]). And, to Ted Lemon, Mark Stapp, Josh Littlefield, Kim Kinnear, and Ralph Droms for discussions on this work.10.11. References10.111.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [3] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [4] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.10.2 Informative References[6] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients (draft-ietf-dhc-ddns-resolution-*.txt)",October 2003.September 2004. 11.2 Informative References [7] Stapp, M., Volz, B. and Y. Rekhter, "The DHCP Client FQDN Option (draft-ietf-dhc-fqdn-option-*.txt)",July 2004.January 2005. [8] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions", RFC 1594, March 1994. [9]Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [10]Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.[11][10] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.[12] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.Author's Address Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA Phone: +1 978 936 0382EMail:Email: volz@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society(2004).(2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.