DHC B. Volz Internet-Draft Cisco Systems, Inc. Expires:
March 17,July 29, 2005 January 25, 2005 September 16, 2004The DHCPv6 Client FQDN Option draft-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 of sectionSection 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 on March 17,July 29, 2005. Copyright Notice Copyright (C) The Internet Society (2004).(2005). Abstract This document specifies a new DHCPDynamic 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 Client behaviorBehavior . . . . . . . . . . . . . . . . . . . 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 (, ) maintains (among other things) the information about mapping between hosts' Fully Qualified Domain Names (FQDNs)  and IPIPv6 addresses assigned to the hosts. The information is maintained in two types of Resource Records (RRs): AAAA and PTR .. The DNS update specification () describes a mechanism that enables DNS information to be updated over a network. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6)  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 . Familiarity with the DNS Update protocol , DHCPv6, and DHCPv6 terminology as defined in  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 servers maydo in cases where clients do not supply domain names. Other work, such as "Resolving Name Conflicts" , 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 addresses in 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 is 2.1 octet. The Formatformat 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 in IA_NA-options and IA_TA-options (see ) fieldsa message's options field and applies to all addresses for that binding.all IA_NA bindings in the transaction. 4.1 The Flags Field The Formatformat of the Flags field:field is: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | MBZ |N|O|S| +-+-+-+-+-+-+-+-+ When a DHCPv6 client sendsThe "S" bit indicates whether the Client 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 indicate that it will notthe server SHOULD NOT perform any DNS updates,the updates and that it expects1 to indicate the DHCPv6server toSHOULD perform any FQDN-to-IPv6 (the AAAA RR) DNS updates on its behalf. If thisthe updates. The state of the bit is clear,in the clientreply from the server indicates that it intendsthe action to performbe taken by the server; if 1, the FQDN-to-IPv6 DNS updates. If a DHCPv6server intends to takehas taken responsibility for theAAAA RR updates, 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" bit before sendingindicates whether the Client FQDN option and servers MUST ignoreserver has overridden the received state ofclient's preference for the "O""S" bit. A client MAYMUST set this bit to 0. A server MUST set this bit to 1 if the "N""S" bit in its request messagesreply to indicate thatthe server shouldclient does not match the "S" bit received from the client. The "N" bit indicates whether the server SHOULD NOT perform any DNS updates on its behalf. As mentioned in Section 3, in generalupdates. A client sets this bit to 0 to request that the DHCPv6server will be maintaining DNSSHOULD perform updates (the PTR recordsRR and possibly the AAAA RR based on behalf of clients. However, there may be deployments in which clients are configuredthe "S" bit) or to 1 to request that the server SHOULD NOT perform all desired DNS updates or may not wantany DNS updates. The server MAY be configured to honor this configuration. If theA server has been configured to honor a client's "N" indication, it SHOULD setsets the "N" bit in Client FQDN options which it sendsto indicate whether the client in its response messages. Clients which have setserver SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N" bit in their requests SHOULD use the state ofis 1, the "N""S" bit in 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 MUST setclear the MBZ bits to 0,bits, and they MUST ignore these bits. 4.2 The Domain Name Field The Domain Name fieldpart of the option carries all or part of the FQDN of a DHCPv6 client. The data in the Domain Name field MUST appear in uncompressed DNS encodingbe encoded as specifieddescribed in .Section 8 of . In order to determine whether a namethe FQDN has changed between message exchanges, an unambiguous canonical form is necessary. Eventually,the IETF 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 and clients should be sensitive to canonicalization when comparing names inserver MUST NOT alter the Domain Name field andcontents unless the name canonicalization defined in  MAY be used.FQDN has actually changed. A client mayMAY be configured with a fully-qualified domain name,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 a non-terminal sequence of labels infully-qualified domain name, the Domain Name field is set to the DNS encoded domain name field ofincluding the option. 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 field containsempty if it desires the server to provide a fully-qualified name unless this partial-name format exists.name. Servers MUST alwaysSHOULD send the complete fully-qualified domain name in Client FQDN options. 5. DHCPv6 Client behaviorBehavior The following describes the behavior of a DHCPv6 client that implements the Client FQDN option. A client MUST only include the Client FQDN options 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 FQDN option 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 and withaddress(es) used by the desired partial or fully qualified domain name. There is no requirement thatclient, the client send identical Client FQDN options data in each of its messages to a server. In particular, if a client has sentMUST include the Client FQDN options to its server, andoption in the configuration ofSOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message originated by the client. A client changes so that its notion of its domain name changes, itMAY sendchoose to include the new name data in aClient FQDN options 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 the AAAA record representingFlags field in the client, to delete that recordoption MUST be 0. The "O" and attempt 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 REPLY message,message and successfully completes a final check on the parameters passed in the message), the client SHOULDMAY originate the DNS updatesan update for the AAAA RRRRs (associated with the client's FQDNs) for any Client FQDN options for which the received "S" and the "O" bits inFQDN) unless the option's Flags field are notserver has set and if it is otherwise configured to perform the DNS updates. The update SHOULD be originated followingthe procedures described in ."S" bit to 1. If the DHCPv6 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 Name field and the addresses in that binding.field. 5.2 Client Desires Server to Do DNS Updates A client that delegatescan choose to delegate the responsibility for updating the FQDN-to-IPv6FQDN to IPv6 address mapping to a server does not receive any indication (either positive or negative) fromfor the server whetherFQDN and address(es) used by the server was ableclient to performthe update. 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, to confirmdelete that record and attempt an update for the DNS 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 is updated.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 the valid lifetimeexpiration or is unable to extend the lifetimes for an address andof the valid lifetime expires,and the client is responsible for updating its AAAA RRs,RR, the client SHOULD delete the AAAA RR associated with the address before sending a RELEASE message 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 lifetime expires.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 FQDN options for a bindingoption in ADVERTISE and REPLY messages if the client included a Client FQDN option for that bindingand the Client 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 option is requested byit will return to the Option Request Option inclient. o If the client's message"N" bit is 1 and the server's configuration allows it to whichhonor the client's request for no server is responding. Servers MUST only include Client FQDN options in the IA_NA-options and IA_TA-options fields in messages sent byinitiated DNS updates, the server. When aserver allocates a new address from a binding, it usessets the Client FQDN option,"N" bit to 1. o Otherwise, if any, inthe IA_NA-options or IA_TA-options field of that bindingclient's "S" bit is 1 and the servers's configuration allows it to determinehonor the fully qualified domain name and who will take responsibilityclient's request for the server to initiate AAAA RR DNS updates. 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 the resultsname supplied in the client's Client FQDN option.option, or it MAY be configured to modify the supplied name, or substitute a different name. The DHCPv6server SHOULD send its notion of the complete FQDN for the client in the Domain Name field. The server MAY simply copy the Domain 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 field fromof the Client FQDN option thatin the clientDHCPACK message (to be) sent to the server.client. The DHCPv6server MAY be configured to complete or modifyperform these updates even if the domain name which a client sent, or it MAY be configured to substitute a different name. If aclient's SOLICIT, REQUEST, RENEW, or REBINDmessage doesn't includedid not carry the Client FQDN option for a binding (e.g.,option. The server MUST NOT initiate DNS updates when responding with an ADVERTISE message to the client doesn't implementclient. The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR) before the Client FQDN option),server sends the REPLY message to the client. Alternatively, the server MAY be configuredsend the REPLY message to the client without waiting for the update to be completed. Whether the DNS update eitheroccurs before or both ofafter the AAAA and PTR RRs.REPLY is sent is entirely up to the DHCPv6 server's configuration. If a client's message includes a Client FQDN option for a binding andthe requested 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's current knowledge ofinteraction with the DNS server MAY cause the DHCPv6 server to change the fully-qualifieddomain name andthat it associates with the client. This can occur, for example, if the server is configured to allow use ofdetects and resolves a domain-name conflict . In such cases, the domain name that name,the server SHOULD performreturns to the necessary DNS updates -DHCPv6 client would change between two DHCPv6 exchanges. If the server SHOULD removepreviously performed DNS updates for the old PTR and AAAA RRs it added, if any,client and addthe new RRs - if itclient's information has that 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 PTR RRsRR which it associated with the address via DNS update. In addition, if the server took responsibility for theAAAA RR,RRs, the server SHOULD also delete thatthe 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 updater must 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 domains may beare based on the specific address bound to a client or the client's DUID, and in these casesclient, conflicts should notSHOULD NOT occur. However, without this level of securityOr, a name conflict resolution technique as described in the DNS system or use of non-conflicting names, other techniques need to"Resolving Name Conflicts" ) SHOULD be developed. Thisused. 8. IANA Considerations IANA is an arearequested to assign a DHCPv6 option code for future work (see ). 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. Administrators shouldneed 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 )) when performing DNS updates. Whether a DHCPv6 client may 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 alternatives may 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 to IPIPv6 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 alternatives may 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 server shouldSHOULD 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 ). And, to Ted Lemon, Mark Stapp, Josh Littlefield, Kim Kinnear, and Ralph Droms for discussions on this work. 10.11. References 10.111.1 Normative References  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.  Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.  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 Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients (draft-ietf-dhc-ddns-resolution-*.txt)", October 2003.September 2004. 11.2 Informative References  Stapp, M., Volz, B. and Y. Rekhter, "The DHCP Client FQDN Option (draft-ietf-dhc-fqdn-option-*.txt)", July 2004.January 2005.  Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions", RFC 1594, March 1994.  Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.  Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.  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 0382 EMail:Email: firstname.lastname@example.org 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 email@example.com. 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.