Network Working Group B. Volz
Request for Comments: 4704 Cisco Systems, Inc.
Category: Standards Track October 2006
Network Working Group B. Volz
Request for Comments: 4704 Cisco Systems, Inc.
Category: Standards Track October 2006
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option
IPv6（DHCPv6）客户端完全限定域名（FQDN）选项的动态主机配置协议
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document specifies a new Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option that can be used to exchange information about a DHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments.
本文档指定了一个新的IPv6动态主机配置协议（DHCPv6）选项，该选项可用于交换有关DHCPv6客户端的完全限定域名（FQDN）以及有关更新与客户端地址分配相关的DNS资源记录（RRs）的责任的信息。
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 Behavior ..........................................7
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 ..........................................9
6.1. When to Perform DNS Updates ................................9
7. DNS RR TTLs ....................................................10
8. DNS Update Conflicts ...........................................11
9. IANA Considerations ............................................11
10. Security Considerations .......................................12
11. Acknowledgements ..............................................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................13
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 Behavior ..........................................7
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 ..........................................9
6.1. When to Perform DNS Updates ................................9
7. DNS RR TTLs ....................................................10
8. DNS Update Conflicts ...........................................11
9. IANA Considerations ............................................11
10. Security Considerations .......................................12
11. Acknowledgements ..............................................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................13
DNS ([2], [3]) maintains (among other things) the information about mapping between hosts' Fully Qualified Domain Names (FQDNs) [10] and IPv6 addresses assigned to the hosts. The information is maintained in two types of Resource Records (RRs): AAAA and PTR [12]. The DNS update specification [4] describes a mechanism that enables DNS information to be updated over a network.
DNS（[2]、[3]）维护（除其他外）主机的完全限定域名（FQDN）[10]与分配给主机的IPv6地址之间的映射信息。信息保存在两种类型的资源记录（RRs）中：AAAA和PTR[12]。DNS更新规范[4]描述了一种使DNS信息能够通过网络更新的机制。
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 about who has the responsibility for updating the DNS with the associated AAAA and PTR RRs.
IPv6的动态主机配置协议（DHCPv6）[5]提供了一种机制，通过该机制，主机（DHCPv6客户端）可以获取某些配置信息及其有状态IPv6地址。本文档指定了一个新的DHCPv6选项，即客户机FQDN选项，DHCPv6客户机和服务器可以使用该选项交换有关客户机完全限定域名的信息，以及有关谁负责使用关联的AAAA和PTR RRs更新DNS的信息。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
Familiarity with the DNS Update protocol [4] and with DHCPv6 and its terminology, as defined in [5], is assumed.
假设熟悉DNS更新协议[4]和DHCPv6及其术语（如[5]中所定义）。
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:
当DHCPv6客户端获取地址时，站点管理员可能希望更新客户端FQDN的AAAA RR和获取地址的PTR RR。因此，可能会发生两个单独的DNS更新事务。通过DHCPv6获取地址涉及两个实体：DHCPv6客户端和DHCPv6服务器。原则上，这些实体中的每一个都可以不执行、执行一个或同时执行两个DNS更新事务。然而，在实践中，并非所有排列都有意义。DHCPv6客户端FQDN选项主要用于以下两种情况：
1. DHCPv6 client updates the AAAA RR; DHCPv6 server updates the PTR RR.
1. DHCPv6客户端更新AAAA RR；DHCPv6服务器更新PTR RR。
2. DHCPv6 server updates both the AAAA and the PTR RRs.
2. DHCPv6服务器同时更新AAAA和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.
这两种情况之间的唯一区别在于FQDN到IPv6的地址映射是由DHCPv6客户端还是由DHCPv6服务器更新的。在这两种情况下，IPv6地址到FQDN的映射都由DHCPv6服务器更新。
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.
这两个原因很重要，而其他原因则不太可能，这与对各自DNS域名的权限有关。DHCPv6客户机可能被授予映射其自身AAAA RRs的权限，或者该权限可能被限制为服务器，以防止客户机列出任意地址或将其地址与任意域名关联。在所有情况下，对与该地址相关的PTR RRs的权限的唯一合理位置是在分配该地址的DHCPv6服务器中。
Note: A third case is supported in which 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 that 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 that 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 that initiate DNS updates.
在任何情况下，站点是否允许所有、部分或不允许DHCPv6服务器和客户端对其控制的区域执行DNS更新完全取决于本地管理策略。本文件不要求任何具体的行政政策，也不提出任何具体的行政政策。可能的策略范围非常广泛，从仅向DHCPv6服务器提供DNS服务器将接受的凭据的站点，到为每个单独的DHCPv6客户端配置了允许客户端修改其自己域名的凭据的站点。兼容实现可能支持部分或全部这些可能性。此外，此规范仅适用于DHCPv6客户端和服务器进程：它不适用于启动DNS更新的其他进程。
This document describes a new DHCPv6 option that a client can use to convey all or part of its domain name to a DHCPv6 server. Site-specific policy determines whether or not DHCPv6 servers use the names that clients offer, and what DHCPv6 servers do in cases where clients do not supply domain names.
本文档描述了一个新的DHCPv6选项，客户机可以使用该选项将其全部或部分域名传送到DHCPv6服务器。特定于站点的策略确定DHCPv6服务器是否使用客户端提供的名称，以及在客户端不提供域名的情况下DHCPv6服务器的操作。
To update the IPv6-address-to-FQDN mapping, a DHCPv6 server needs to know the FQDN of the client for the addresses 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 that DHCPv6 clients and servers use to negotiate who does which updates.
要将IPv6地址更新为FQDN映射，DHCPv6服务器需要知道客户端的FQDN，以获取客户端IA_NA绑定的地址。为了允许客户机将其FQDN传递给服务器，本文档定义了一个名为“客户机FQDN”的新DHCPv6选项。客户端FQDN选项还包含DHCPv6客户端和服务器用于协商谁执行哪些更新的标志。
The code for this option is 39. Its minimum length is 1 octet.
此选项的代码为39。它的最小长度是1个八位组。
The format of the DHCPv6 Client FQDN option is shown below:
DHCPv6客户端FQDN选项的格式如下所示：
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (39)
选项代码选项\客户端\ FQDN（39）
option-len 1 + length of domain name
选项长度1+域名长度
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)
域名部分或完全限定的域名（长度选项len-1）
The Client FQDN option MUST only appear in a message's options field and applies to all addresses for all IA_NA bindings in the transaction.
客户端FQDN选项必须仅出现在消息的选项字段中，并应用于事务中所有IA_NA绑定的所有地址。
The format of the Flags field is:
“标志”字段的格式为：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |N|O|S|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |N|O|S|
+-+-+-+-+-+-+-+-+
The "S" bit indicates whether the server SHOULD or SHOULD NOT perform the AAAA RR (FQDN-to-address) DNS updates. A client sets the bit to 0 to indicate that the server SHOULD NOT perform the updates and 1 to indicate that the server SHOULD perform the updates. The state of the bit in the reply from the server indicates the action to be taken by the server; if it is 1, the server has taken responsibility for AAAA RR updates for the FQDN.
“S”位指示服务器是否应该执行AAAA RR（FQDN到地址）DNS更新。客户端将位设置为0表示服务器不应执行更新，将位设置为1表示服务器应执行更新。来自服务器的回复中位的状态指示服务器要采取的操作；如果为1，则服务器负责FQDN的AAAA RR更新。
The "O" bit indicates whether the server has overridden the client's preference for the "S" bit. A client MUST set this bit to 0. A server MUST set this bit to 1 if the "S" bit in its reply to the client does not match the "S" bit received from the client.
“O”位表示服务器是否已覆盖客户端对“s”位的首选项。客户端必须将此位设置为0。如果服务器对客户端的回复中的“S”位与从客户端接收到的“S”位不匹配，则服务器必须将该位设置为1。
The "N" bit indicates whether the server SHOULD NOT perform any DNS updates. A client sets this bit to 0 to request that the server SHOULD perform updates (the PTR RR and possibly the AAAA RR based on the "S" bit) or to 1 to request that the server SHOULD NOT perform any DNS updates. A server sets the "N" bit to indicate whether the server SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N" bit is 1, the "S" bit MUST be 0.
“N”位指示服务器是否不应执行任何DNS更新。客户端将此位设置为0以请求服务器执行更新（PTR RR，可能还有基于“S”位的AAAA RR），或将此位设置为1以请求服务器不执行任何DNS更新。服务器设置“N”位，以指示服务器应（0）还是不应（1）执行DNS更新。如果“N”位为1，“S”位必须为0。
The remaining bits in the Flags field are reserved for future assignment. DHCPv6 clients and servers that send the Client FQDN option MUST clear the MBZ bits, and they MUST ignore these bits.
标志字段中的剩余位保留用于将来的分配。发送客户端FQDN选项的DHCPv6客户端和服务器必须清除MBZ位，并且必须忽略这些位。
The Domain Name part of the option carries all or part of the FQDN of a DHCPv6 client. The data in the Domain Name field MUST be encoded as described in Section 8 of [5]. In order to determine whether the FQDN has changed between message exchanges, the client and server MUST NOT alter the Domain Name field contents unless the FQDN has actually changed.
选项的域名部分包含DHCPv6客户端的全部或部分FQDN。域名字段中的数据必须按照[5]第8节所述进行编码。为了确定FQDN在消息交换之间是否已更改，客户端和服务器不得更改域名字段内容，除非FQDN已实际更改。
A client MAY be configured with a fully qualified domain 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.
可以使用完全限定的域名或不完全限定的部分名称配置客户端。如果客户机只知道其名称的一部分，它可能会发送一个不完全限定的名称，表示它知道名称的一部分，但不一定知道名称将嵌入的区域。
To send a fully qualified domain name, the Domain Name field is set to the DNS-encoded domain name including the terminating 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.
要发送完全限定的域名，域名字段设置为DNS编码的域名，包括终止的零长度标签。要发送部分名称，域名字段将设置为DNS编码的域名，而不带终止零长度标签。
A client MAY also leave the Domain Name field empty if it desires the server to provide a name.
如果客户机希望服务器提供名称，它也可以将域名字段留空。
Servers SHOULD send the complete fully qualified domain name in Client FQDN options.
服务器应在客户端FQDN选项中发送完整的完全限定域名。
The following describes the behavior of a DHCPv6 client that implements the Client FQDN option.
下面描述了实现客户机FQDN选项的DHCPv6客户机的行为。
A client MUST only include the Client FQDN option in SOLICIT, REQUEST, RENEW, or REBIND messages.
客户端只能在请求、请求、续订或重新绑定消息中包含客户端FQDN选项。
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.
如果发送客户端FQDN选项的客户端希望服务器在任何响应中包含客户端FQDN选项，则它还必须在选项请求选项中包含该选项。
If a client that owns/maintains its own FQDN wants to be responsible for updating the FQDN-to-IPv6-address mapping for the FQDN and address(es) used by the client, the client MUST include the Client FQDN option in the SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message originated by the client. A client MAY choose to include the Client FQDN option in its SOLICIT messages. The "S", "O", and "N" bits in the Flags field in the option MUST be 0.
如果拥有/维护自己的FQDN的客户端希望负责更新该客户端使用的FQDN和地址的FQDN到IPv6地址映射，则该客户端必须在由该客户端发起的具有快速提交、请求、续订和重新绑定消息的请求中包含客户端FQDN选项。客户端可以选择在其请求消息中包含客户端FQDN选项。选项中标志字段中的“S”、“O”和“N”位必须为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 an update for the AAAA RRs (associated with the client's FQDN) unless the server has set the "S" bit to 1. If the "S" is 1, the DHCPv6 client SHOULD NOT initiate an update for the name in the server's returned Client FQDN option Domain Name field. However, a DHCPv6 client that is explicitly configured with a FQDN MAY ignore the state of the "S" bit if the server's returned name matches the client's configured name.
一旦客户机的DHCPv6配置完成（客户机收到回复消息并成功完成对消息中传递的参数的最终检查），客户机可能会发起AAAA RRs（与客户机的FQDN关联）的更新，除非服务器已将“s”位设置为1。如果“S”为1，则DHCPv6客户端不应启动服务器返回的客户端FQDN选项域名字段中的名称更新。但是，如果服务器返回的名称与客户端配置的名称匹配，则显式配置了FQDN的DHCPv6客户端可能会忽略“S”位的状态。
A client can choose to delegate the responsibility for updating the FQDN-to-IPv6-address mapping for the FQDN and address(es) used by the client to the server. 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 "S" bit in the Flags field in the option MUST be 1, and the "O" and "N" bits MUST be 0.
客户端可以选择将更新客户端使用的FQDN和地址的FQDN到IPv6地址映射的责任委托给服务器。为了将此选择通知服务器，客户机应在其请求中包含客户机FQDN选项以及快速提交、请求、续订和重新绑定消息，并可在其请求中包含客户机FQDN选项。选项中标志字段中的“S”位必须为1，“O”和“N”位必须为0。
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
客户端可以选择请求服务器不代表其执行DNS更新。为了将此选择通知服务器，客户机应在其请求中包含客户机FQDN选项
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.
快速提交、请求、续订和重新绑定消息，并可能在其请求中包含客户端FQDN选项。选项中标志字段中的“N”位必须为1，“S”和“O”位必须为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; it MAY also perform the AAAA RR updates if the "S" bit is 1.
一旦客户机的DHCPv6配置完成（客户机收到回复消息并成功完成对消息中传递的参数的最终检查），只要服务器的“N”位为1，客户机就可以发起其DNS更新。如果服务器的“N”位为0，则服务器可以执行PTR-RR更新；如果“S”位为1，它还可能执行AAAA RR更新。
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 delete that record and attempt an update for the client's current domain name.
由于DHCPv6服务器可能配置为完成或替换客户端发送的域名，因此客户端可能会发现在其请求消息中发送客户端FQDN选项很有用。如果DHCPv6服务器在其播发消息中返回不同的域名数据，则客户端可以使用该数据执行其自己的最终AAAA RR更新，或形成其在后续消息中发送的客户端FQDN选项。不要求客户端在其请求、请求、续订或重新绑定消息中发送相同的客户端FQDN选项数据。特别是，如果客户机已将客户机FQDN选项发送到其服务器，并且客户机的配置发生了更改，因此其域名的概念发生了更改，则当其再次与服务器通信时，可能会在客户机FQDN选项中发送新的名称数据。这可能会导致DHCPv6服务器更新与PTR记录关联的名称，如果服务器更新了代表客户端的AAAA记录，则会删除该记录并尝试更新客户端的当前域名。
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 as to whether the server was able to perform the update. The client MAY use a DNS query to check whether the mapping is 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 authoritative servers might not have completed the updates or zone transfers, or caching resolvers may yet have updated their caches.
委托负责将FQDN到IPv6地址映射更新到服务器的客户端将不会从服务器接收到有关服务器是否能够执行更新的任何指示（肯定或否定）。客户端可以使用DNS查询来检查映射是否是最新的。但是，根据DHCPv6和DNS服务器上的负载以及DNS传播延迟，客户端只能推断成功。如果在DNS中未找到最新信息，则权威服务器可能尚未完成更新或区域传输，或者缓存解析程序可能尚未更新其缓存。
If a client releases an address prior to the expiration of the valid lifetime and the client is responsible for updating its AAAA RR, the client SHOULD delete the AAAA RR associated with the address before sending a RELEASE message. 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
如果客户端在有效生存期到期之前释放了地址，并且客户端负责更新其AAAA RR，则客户端应在发送释放消息之前删除与该地址关联的AAAA RR。类似地，如果客户端负责更新其AAAA RR，但无法续订地址的生存期，则客户端应尝试在更新之前删除AAAA RR
lifetime on the address is no longer valid. A DHCPv6 client that has not been able to delete an AAAA RR that it added SHOULD attempt to notify its administrator, perhaps by emitting a log message.
地址上的生存期不再有效。无法删除其添加的AAAA RR的DHCPv6客户端应尝试通知其管理员，可能是通过发出日志消息。
A client SHOULD NOT perform DNS updates to AAAA RRs for its non-Global Unicast addresses [7] or temporary addresses [6].
客户端不应为其非全局单播地址[7]或临时地址[6]对AAAA RRs执行DNS更新。
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.
以下描述了当客户端消息包含客户端FQDN选项时，实现客户端FQDN选项的DHCPv6服务器的行为。
Servers MUST only include a Client FQDN option in ADVERTISE and REPLY messages if the client included a Client FQDN option and the Client FQDN option is requested by the Option Request option in the client's message to which the server is responding.
如果客户端包含客户端FQDN选项，并且客户端FQDN选项是由服务器响应的客户端消息中的选项请求选项请求的，则服务器只能在播发和回复消息中包含客户端FQDN选项。
The server examines its configuration and the Flag bits in the client's Client FQDN option to determine how to respond:
服务器检查其配置和客户端的客户端FQDN选项中的标志位，以确定如何响应：
o The server sets to 0 the "S", "O", and "N" bits in its copy of the option it will return to the client.
o 服务器将返回给客户端的选项副本中的“S”、“O”和“N”位设置为0。
o If the client's "N" bit is 1 and the server's configuration allows it to honor the client's request for no server-initiated DNS updates, the server sets the "N" bit to 1.
o 如果客户端的“N”位为1，并且服务器的配置允许它接受客户端的请求，不进行服务器启动的DNS更新，则服务器将“N”位设置为1。
o Otherwise, if the client's "S" bit is 1 and the server's configuration allows it to honor the client's request for the server to initiate AAAA RR DNS updates, 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.
o 否则，如果客户端的“s”位为1，并且服务器的配置允许它接受客户端请求服务器启动AAAA RR DNS更新，则服务器将“s”设置为1。如果服务器的“s”位与客户端的“s”位不匹配，则服务器将“O”位设置为1。
The server MAY be configured to use the name supplied in the client's Client FQDN option, or it MAY be configured to modify the supplied name or to substitute a different name. The server SHOULD send its notion of the complete FQDN for the client in the Domain Name field. The server MAY simply copy the Domain Name field from the Client FQDN option that the client sent to the server.
服务器可以配置为使用客户端的客户端FQDN选项中提供的名称，也可以配置为修改提供的名称或替换其他名称。服务器应在“域名”字段中为客户端发送其完整FQDN的概念。服务器可以简单地从客户端发送到服务器的客户端FQDN选项复制域名字段。
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 that it previously added via DNS updates for the client.
如果发送到客户端的回复消息中客户端FQDN选项的标志字段中的“N”位为1，则服务器不应执行任何DNS更新。但是，服务器应该删除以前通过DNS更新为客户端添加的所有RRs。
The server MAY perform the PTR RR DNS update (unless the "N" bit is 1).
服务器可以执行PTR RR DNS更新（除非“N”位为1）。
The server MAY perform the AAAA RR DNS update if the "S" bit is 1 in the Flags field of the Client FQDN option in the REPLY message (to be) sent to the client.
如果发送到客户端的回复消息（待发送）中客户端FQDN选项的标志字段中的“S”位为1，则服务器可能会执行AAAA RR DNS更新。
The server MAY perform these updates even if the client's message did not carry the Client FQDN option. The server MUST NOT initiate DNS updates when responding with an ADVERTISE message to the client.
即使客户端消息未包含客户端FQDN选项，服务器也可能执行这些更新。当向客户端发送播发消息进行响应时，服务器不得启动DNS更新。
The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR) before or after sending the REPLY message to the client.
服务器可以在向客户端发送回复消息之前或之后完成其DNS更新（PTR RR或PTR和AAAA RR）。
If the server's AAAA RR DNS update does not complete until after the server has replied to the DHCPv6 client, the server's interaction with the DNS server MAY cause the DHCPv6 server to change the domain name that it associates with the client. This can occur, for example, if the server detects and resolves a domain-name conflict [8]. In such cases, the domain name that the server returns to the DHCPv6 client would change between two DHCPv6 exchanges.
如果服务器的AAAA RR DNS更新在服务器回复DHCPv6客户端后才完成，则服务器与DNS服务器的交互可能会导致DHCPv6服务器更改其与客户端关联的域名。例如，如果服务器检测到并解决域名冲突[8]，就会发生这种情况。在这种情况下，服务器返回给DHCPv6客户机的域名将在两次DHCPv6交换之间更改。
If the server previously performed DNS updates for the client and the client's information has not changed, the server MAY skip performing additional DNS updates.
如果服务器先前为客户端执行了DNS更新，并且客户端的信息没有更改，则服务器可能会跳过执行其他DNS更新。
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 RR that it associated with the address via DNS update. In addition, if the server took responsibility for AAAA RRs, the server SHOULD also delete the AAAA RR.
当服务器接收到地址的释放或拒绝，检测到服务器绑定到客户端的地址的有效生存期已过期，或在绑定到期之前终止地址的绑定（例如，通过发送地址的有效生存期为零的回复），服务器应通过DNS更新删除与地址关联的任何PTR RR。此外，如果服务器负责AAAA RR，则服务器还应删除AAAA RR。
RRs associated with DHCP clients may be more volatile than statically configured RRs. DHCP clients and servers that perform dynamic updates should attempt to specify resource record TTLs that reflect this volatility, in order to minimize the possibility that answers to DNS queries will return records that refer to DHCP IP address assignments that have expired or been released.
与DHCP客户端关联的RRs可能比静态配置的RRs更不稳定。执行动态更新的DHCP客户端和服务器应尝试指定反映此波动性的资源记录TTL，以最大限度地减少DNS查询的答案将返回指向已过期或已发布的DHCP IP地址分配的记录的可能性。
The coupling among primary, secondary, and caching DNS servers is 'loose'; that is a fundamental part of the design of the DNS. This looseness makes it impossible to prevent all possible situations in which a resolver may return a record reflecting a DHCP-assigned IP
主DNS服务器、辅助DNS服务器和缓存DNS服务器之间的耦合“松散”；这是DNS设计的基本部分。这种松散性使得不可能防止冲突解决程序返回反映DHCP分配的IP的记录的所有可能情况
address that has expired or been released. In deployment, this rarely, if ever, represents a significant problem. Most DHCP-managed clients are infrequently looked up by name in the DNS, and the deployment of IXFR [13] and NOTIFY [14] can reduce the latency between updates and their visibility at secondary servers.
已发布或已过期的地址。在部署中，这很少（如果有的话）是一个重大问题。大多数DHCP管理的客户端很少在DNS中按名称查找，部署IXFR[13]和NOTIFY[14]可以减少更新之间的延迟以及它们在辅助服务器上的可见性。
We suggest these basic guidelines for implementers. In general, the TTLs for RRs added as a result of DHCP IP address assignment activity SHOULD be less than the initial lifetime. The RR TTL on a DNS record added SHOULD NOT exceed 1/3 of the lifetime, but SHOULD NOT be less than 10 minutes. We recognize that individual administrators will have varying requirements: DHCP servers and clients SHOULD allow administrators to configure TTLs and upper and lower bounds on the TTL values, either as an absolute time interval or as a percentage of the lease lifetime.
我们向实施者建议这些基本准则。通常，由于DHCP IP地址分配活动而添加的RRs的TTL应小于初始生存期。添加的DNS记录上的RR TTL不应超过生存期的1/3，但不应少于10分钟。我们认识到，个别管理员将有不同的要求：DHCP服务器和客户端应允许管理员配置TTL以及TTL值的上限和下限，无论是作为绝对时间间隔，还是作为租约生存期的百分比。
While clients and servers MAY update the TTL of the records as the lifetime is about to expire, there is no requirement that they do so as this puts additional load on the DNS system with likely little benefit.
虽然客户机和服务器可能会在生命周期即将到期时更新记录的TTL，但不要求他们这样做，因为这会给DNS系统带来额外的负载，可能没有什么好处。
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.
本文档不解析DHCPv6客户端或服务器如何防止名称冲突。本文档仅说明DHCPv6客户端和服务器如何协商完全限定的域名以及谁将执行DNS更新。
Implementers of this work will need to consider how name conflicts will be prevented. If a DNS updater needs a security token in order to successfully perform DNS updates on a specific name, name conflicts can only occur if multiple updaters are given a security token for that name. Or, if the fully qualified domains are based on the specific address bound to a client, conflicts will not occur. Or, a name conflict resolution technique as described in "Resolving Name Conflicts" [8]) SHOULD be used.
这项工作的实现者需要考虑如何防止名称冲突。如果DNS更新程序需要安全令牌才能成功地对特定名称执行DNS更新，则只有在为多个更新程序提供该名称的安全令牌时，才会发生名称冲突。或者，如果完全限定的域基于绑定到客户端的特定地址，则不会发生冲突。或者，应使用“解决名称冲突”[8]）中所述的名称冲突解决技术。
The IANA has assigned DHCPv6 option code 39 for the Client FQDN option.
IANA已为客户端FQDN选项分配DHCPv6选项代码39。
Unauthenticated updates to the DNS can lead to tremendous confusion, through malicious attack or through inadvertent misconfiguration. Administrators need to be wary of permitting unsecured DNS updates to zones that 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 [11]) when performing DNS updates.
未经验证的DNS更新可能会通过恶意攻击或无意的错误配置导致巨大的混乱。管理员需要警惕允许对暴露于全球互联网的区域进行不安全的DNS更新。在执行DNS更新时，DHCPv6客户端和服务器都应使用某种形式的更新请求源身份验证过程（例如，安全DNS动态更新[11]）。
Whether a DHCPv6 client is 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 is 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-IPv6-address mapping for its FQDN).
DHCPv6客户端是否负责更新FQDN到IPv6地址映射，或者这是否是DHCPv6服务器的责任，这是一个站点本地问题。这两个备选方案之间的选择可能基于DNS更新协议使用的安全模型（例如，只有客户端可能具有足够的凭据来执行对其FQDN的FQDN到IPv6地址映射的更新）。
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 is 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 SHOULD be sure of the DNS name to use for the client, and of the identity of the client.
DHCPv6服务器是否总是负责更新FQDN到IPv6地址映射（除了更新IPv6到FQDN映射之外），而不管单个DHCPv6客户端的意愿如何，这也是站点本地的问题。这两个备选方案之间的选择可能基于DNS更新使用的安全模型。如果DHCPv6服务器代表客户端执行DNS更新，则DHCPv6服务器应确保用于客户端的DNS名称以及客户端的标识。
Depending on the presence 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.
根据身份验证选项使用的身份验证的存在或类型，DHCPv6服务器可能对其客户端的身份不太信任。DHCPv6服务器可以通过多种方式开发用于客户端的DNS名称，但只有在某些情况下，DHCPv6服务器才能确定客户端的身份。
It is critical to implement proper conflict resolution, and the security considerations of conflict resolution apply [8].
实施适当的冲突解决至关重要，冲突解决的安全考虑也适用[8]。
Many thanks to Mark Stapp and Yakov Rekhter, as this document is based on the DHCPv4 Client FQDN option [9], and to Ralph Droms, Ted Lemon, Josh Littlefield, Kim Kinnear, Pekka Savola, and Mark Stapp for their review and comments.
非常感谢Mark Stapp和Yakov Rekhter，因为本文件基于DHCPv4客户FQDN选项[9]，感谢Ralph Droms、Ted Lemon、Josh Littlefield、Kim Kinnear、Pekka Savola和Mark Stapp的审查和评论。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[2] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[3] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[3] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[4] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[4] Vixie，P.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[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.
[5] Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[6] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[6] Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC3041，2001年1月。
[7] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[7] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[8] Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients", RFC 4703, October 2006.
[8] Stapp，M.和B.Volz，“解决动态主机配置协议（DHCP）客户端之间的完全限定域名（FQDN）冲突”，RFC 4703，2006年10月。
[9] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option", RFC 4702, October 2006.
[9] Stapp，M.，Volz，B.，和Y.Rekhter，“动态主机配置协议（DHCP）客户端完全限定域名（FQDN）选项”，RFC 4702，2006年10月。
[10] Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions", FYI 4, RFC 1594, March 1994.
[10] Marine，A.，Reynolds，J.，和G.Malkin，“供参考的问题和答案-常见问题“新互联网用户”问题的答案”，供参考第4期，RFC 1594，1994年3月。
[11] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[11] 威灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[12] Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[13] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[13] Ohta，M.“DNS中的增量区域转移”，RFC 1995，1996年8月。
[14] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[14] Vixie，P.，“区域变更即时通知机制（DNS通知）”，RFC 1996，1996年8月。
Author's Address
作者地址
Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
伯纳德·沃兹思科系统公司，美国马萨诸塞州博克斯伯勒马萨诸塞大道1414号，邮编01719
Phone: +1 978 936 0382
EMail: volz@cisco.com
Phone: +1 978 936 0382
EMail: volz@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。