Internet Engineering Task Force (IETF) O. Troan
Request for Comments: 7550 B. Volz
Updates: 3315, 3633 Cisco Systems, Inc.
Category: Standards Track M. Siodelski
ISSN: 2070-1721 ISC
May 2015
Internet Engineering Task Force (IETF) O. Troan
Request for Comments: 7550 B. Volz
Updates: 3315, 3633 Cisco Systems, Inc.
Category: Standards Track M. Siodelski
ISSN: 2070-1721 ISC
May 2015
Issues and Recommendations with Multiple Stateful DHCPv6 Options
多状态DHCPv6选项的问题和建议
Abstract
摘要
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specification defined two stateful options, IA_NA and IA_TA, but did not anticipate the development of additional stateful options. DHCPv6 Prefix Delegation added the IA_PD option, which is stateful. Applications that use IA_NA and IA_PD together have revealed issues that need to be addressed. This document updates RFCs 3315 and 3633 to address these issues.
IPv6的动态主机配置协议（DHCPv6）规范定义了两个有状态选项，即IA_-NA和IA_-TA，但未预期会开发其他有状态选项。DHCPv6前缀委派添加了IA_PD选项，该选项是有状态的。同时使用IA_-NA和IA_-PD的应用程序揭示了需要解决的问题。本文件更新了RFCs 3315和3633，以解决这些问题。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7550.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7550.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Handling of Multiple IA Option Types . . . . . . . . . . . . 4
4.1. Placement of Status Codes in an Advertise Message . . . . 6
4.2. Advertise Message Processing by a Client . . . . . . . . 8
4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 10
4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 10
4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 11
4.4.3. Updates to Section 18.1.3 of RFC 3315 . . . . . . . . 11
4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 13
4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 14
4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 16
4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 18
4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 20
4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 21
4.6. Decline Should Not Necessarily Trigger a Release . . . . 22
4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Normative References . . . . . . . . . . . . . . . . . . 22
6.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Handling of Multiple IA Option Types . . . . . . . . . . . . 4
4.1. Placement of Status Codes in an Advertise Message . . . . 6
4.2. Advertise Message Processing by a Client . . . . . . . . 8
4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 10
4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 10
4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 11
4.4.3. Updates to Section 18.1.3 of RFC 3315 . . . . . . . . 11
4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 13
4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 14
4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 16
4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 18
4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 20
4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 21
4.6. Decline Should Not Necessarily Trigger a Release . . . . 22
4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Normative References . . . . . . . . . . . . . . . . . . 22
6.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
DHCPv6 [RFC3315] was written without the expectation that additional stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation [RFC3633] since added a new stateful option for Prefix Delegation to DHCPv6. Implementation experience of the Customer Edge (CE) router model described in [RFC7084] has shown issues with the DHCPv6 protocol in supporting multiple stateful option types, in particular IA_NA (non-temporary addresses) and IA_PD (delegated prefixes).
编写DHCPv6[RFC3315]时，并不期望开发额外的有状态DHCPv6选项。DHCPv6前缀委派[RFC3633]，因为为DHCPv6的前缀委派添加了一个新的有状态选项。[RFC7084]中描述的客户边缘（CE）路由器模型的实施经验表明，DHCPv6协议在支持多种有状态选项类型方面存在问题，特别是IA_NA（非临时地址）和IA_PD（委托前缀）。
This document describes a number of problems encountered with coexistence of the IA_NA and IA_PD option types and specifies changes to the DHCPv6 protocol to address these problems.
本文档描述了IA_NA和IA_PD选项类型共存时遇到的许多问题，并指定了对DHCPv6协议的更改以解决这些问题。
The intention of this work is to clarify and, where needed, modify the DHCPv6 protocol specification to support IA_NA and IA_PD option types within a single DHCPv6 session.
这项工作的目的是澄清并在需要时修改DHCPv6协议规范，以便在单个DHCPv6会话中支持IA_NA和IA_PD选项类型。
Note that while IA_TA (temporary addresses) options may be included with other IA option type requests, these generally are not renewed (there are no T1/T2 times) and have a separate life cycle from IA_NA and IA_PD option types. Therefore, the IA_TA option type is mostly out of scope for this document.
请注意，虽然IA_TA（临时地址）选项可能包含在其他IA选项类型请求中，但这些选项通常不更新（没有T1/T2时间），并且与IA_NA和IA_PD选项类型有单独的生命周期。因此，IA_TA选项类型基本上超出了本文档的范围。
The changes described in this document are intended to be incorporated in a new revision of the DHCPv6 protocol specification [DHCPv6].
本文件中描述的变更旨在纳入DHCPv6协议规范[DHCPv6]的新版本中。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In addition to the terminology defined in [RFC3315], [RFC3633], and [RFC7227], the following terminology is used in this document:
除[RFC3315]、[RFC3633]和[RFC7227]中定义的术语外，本文件中还使用了以下术语：
Identity Association (IA): Throughout this document, "IA" is used to refer to the Identity Association containing addresses or prefixes assigned to a client and carried in the IA_NA or IA_PD options, respectively.
身份关联（IA）：在本文档中，“IA”是指包含分配给客户机的地址或前缀的身份关联，并分别包含在IA_-NA或IA_-PD选项中。
IA option types: This is used to generally mean an IA_NA and/or IA_PD option.
IA选项类型：通常指IA_NA和/或IA_PD选项。
Stateful options: Options that require a dynamic binding state per client on the server.
有状态选项：要求服务器上每个客户端具有动态绑定状态的选项。
Top-level options: Top-level options are DHCPv6 options that are not encapsulated within other options, excluding the Relay Message option. Options encapsulated by Relay Message options, but not by any other option, are still top-level options, whether they appear in a relay agent message or a server message; see [RFC7227].
顶级选项：顶级选项是不封装在其他选项中的DHCPv6选项，不包括中继消息选项。由中继消息选项封装但不由任何其他选项封装的选项仍然是顶级选项，无论它们出现在中继代理消息或服务器消息中；见[RFC7227]。
The DHCPv6 specification [RFC3315] was written with the assumption that the only stateful options were for assigning addresses. DHCPv6 Prefix Delegation [RFC3633] describes how to extend the DHCPv6 protocol to handle prefix delegation, but does not clearly specify how the DHCP address assignment and prefix delegation coexist.
编写DHCPv6规范[RFC3315]时，假设只有用于分配地址的有状态选项。DHCPv6前缀委派[RFC3633]描述了如何扩展DHCPv6协议以处理前缀委派，但没有明确指定DHCP地址分配和前缀委派如何共存。
If a client requests multiple IA option types, but the server is configured to only offer a subset of them, the client could react in several ways:
如果客户机请求多种IA选项类型，但服务器配置为仅提供其中的一个子集，则客户机可以通过多种方式作出反应：
1. Reset the state machine and continue to send Solicit messages,
1. 重置状态机并继续发送请求消息，
2. Create separate DHCP sessions for each IA option type and continue to Solicit for the unfulfilled IA options, or
2. 为每个IA选项类型创建单独的DHCP会话，并继续请求未实现的IA选项，或
3. The client could continue with the single session and include the unfulfilled IA options in subsequent messages to the server.
3. 客户端可以继续执行单个会话，并在发送给服务器的后续消息中包含未完成的IA选项。
Resetting the state machine and continuing to send Solicit messages may result in the client never completing DHCP and is generally not considered a good solution. It can also result in a packet storm if the client does not appropriately rate limit its sending of Solicit messages or if there are many clients on the network. Client implementors that follow this approach SHOULD implement the updates to RFC 3315 specified in [RFC7083].
重置状态机并继续发送请求消息可能导致客户端无法完成DHCP，通常认为这不是一个好的解决方案。如果客户端没有适当地限制其发送请求消息的速率，或者如果网络上有许多客户端，则也可能导致数据包风暴。遵循此方法的客户机实现者应实现[RFC7083]中指定的对RFC 3315的更新。
Creating a separate DHCP session (separate instances of the client state machine) per IA option type, while conceptually simple, causes a number of issues: additional host resources required to create and maintain multiple instances of the state machine in clients, additional DHCP protocol traffic, unnecessary duplication of other configuration options and the potential for conflict, and divergence in that each IA option type specification specifies its 'own' version of the DHCP protocol.
根据IA选项类型创建单独的DHCP会话（客户端状态机的单独实例），虽然概念上很简单，但会导致许多问题：在客户端中创建和维护多个状态机实例所需的额外主机资源，额外的DHCP协议流量，其他配置选项的不必要重复和冲突的可能性，以及每个IA选项类型规范指定其“自己”版本的DHCP协议的分歧。
The single session and state machine allows the client to use the best configuration it is able to obtain from a single DHCP server during the configuration exchange. Note, however, that the server may not be configured to deliver the entire configuration requested by the client. In that case, the client could continue to operate only using the configuration received, even if other servers can provide the missing configuration. In practice, especially in the case of handling IA_NA and IA_PD, this situation should be rare or a temporary operational error. So, it is more likely for the client to get all configuration if it continues, in each subsequent configuration exchange, to request all the configuration information it is programmed to try to obtain, including any stateful configuration options for which no results were returned in previous exchanges.
单会话和状态机允许客户端在配置交换期间使用它能够从单个DHCP服务器获得的最佳配置。但是，请注意，服务器可能未配置为提供客户端请求的整个配置。在这种情况下，即使其他服务器可以提供缺少的配置，客户端也只能使用收到的配置继续运行。在实践中，尤其是在处理IA_NA和IA_PD的情况下，这种情况应该很少发生，或者是暂时的操作错误。因此，如果客户机在每个后续配置交换中继续请求其编程尝试获取的所有配置信息，包括在先前交换中未返回结果的任何有状态配置选项，则更有可能获取所有配置。
One major issue of this last approach is that it is difficult to allow it with the current DHCPv6 specifications; in some cases they are not clear enough, and in other cases existing restrictions can make it impossible. This document introduces some clarifications and small modifications to the current specifications to address these concerns.
最后一种方法的一个主要问题是，在当前的DHCPv6规范中很难允许它；在某些情况下，它们不够清晰，而在其他情况下，现有的限制可能使其无法实现。本文件对当前规范进行了一些澄清和小修改，以解决这些问题。
While all approaches have their own pros and cons, approach number 3 above SHOULD be used and is the focus of this document because it is deemed to work best for common cases of the mixed use of IA_NA and IA_PD. But this document does not exclude other approaches. Also, in some corner cases it may not be feasible to maintain a single DHCPv6 session for both IA_NA and IA_PD. These corner cases are beyond the scope of this document and may depend on the network in which the client (CE router) is designed to operate and on the functions the client is required to perform.
虽然所有方法都有各自的优缺点，但应使用上述第3种方法，这是本文件的重点，因为它被认为最适用于IA_NA和IA_PD混合使用的常见情况。但本文件并不排除其他方法。此外，在某些情况下，为IA_NA和IA_PD维护一个DHCPv6会话可能是不可行的。这些极端情况超出了本文件的范围，可能取决于客户端（CE路由器）设计用于操作的网络以及客户端需要执行的功能。
The sections that follow update RFCs 3315 and 3633 to accommodate the recommendation, though many of the changes are also applicable even if other approaches are used.
随后的章节更新了RFCs 3315和3633，以适应该建议，尽管即使使用了其他方法，许多更改也适用。
In Reply messages, IA-specific status codes (i.e., NoAddrsAvail, NotOnLink, NoBinding, and NoPrefixAvail) are encapsulated in the IA option. In Advertise messages though, the NoAddrsAvail code is returned at the top level. This makes sense if the client is only interested in the assignment of the addresses and the failure case is fatal. However, if the client sends both IA_NA and IA_PD options in a Solicit message, it is possible that the server will offer some prefixes but no addresses, and the client may choose to send a Request message to obtain the offered prefixes. In this case, it is better if the Status Code option for IA-specific status codes is encapsulated in the IA option to indicate that the failure occurred for the specific IA. This also makes the NoAddrsAvail and NoPrefixAvail Status Code option placement for Advertise messages identical to Reply messages.
在回复消息中，IA特定的状态代码（即NoAddrsAvail、NotOnLink、NoBinding和NoPrefixAvail）封装在IA选项中。不过，在播发消息中，NoAddrsAvail代码是在顶层返回的。如果客户机只对地址分配感兴趣，并且失败案例是致命的，那么这是有意义的。但是，如果客户端在请求消息中同时发送IA_NA和IA_PD选项，则服务器可能会提供一些前缀，但没有地址，并且客户端可能会选择发送请求消息以获取提供的前缀。在这种情况下，最好将IA特定状态代码的状态代码选项封装在IA选项中，以指示特定IA发生故障。这也使得播发消息的NoAddrsAvail和NoPrefixAvail状态代码选项的位置与回复消息相同。
In addition, how a server formats the Advertise message when addresses are not available has been a point of some confusion and implementations seem to vary (some strictly follow RFC 3315 while others assumed it was encapsulated in the IA option as for Reply messages).
此外，当地址不可用时，服务器如何格式化播发消息一直是一个令人困惑的问题，实现方式似乎有所不同（一些服务器严格遵循RFC 3315，而另一些服务器则假设它与回复消息一样封装在IA选项中）。
We have chosen the following solution:
我们选择了以下解决方案：
Clients MUST handle each of the following Advertise message formats when there are no addresses available (even when no other IA option types were in the Solicit):
当没有可用地址时（即使请求中没有其他IA选项类型），客户端必须处理以下每种播发消息格式：
1. Advertise containing the IA_NAs and/or IA_TAs with an encapsulated Status Code option of NoAddrsAvail and no top-level Status Code option.
1. 包含IA_NAs和/或IA_TA的播发，带有封装状态代码选项NOADRSAVAIL和无顶级状态代码选项。
2. Advertise containing just a top-level Status Code option of NoAddrsAvail and no IA_NAs/IA_TAs.
2. 仅包含NoAddrsAvail的顶级状态码选项且不包含IA_NAs/IA_TAs的广告。
3. Advertise containing a top-level Status Code option of NoAddrsAvail and IA_NAs and/or IA_TAs with a Status Code option of NoAddrsAvail.
3. 包含顶级状态码选项NOADRSAVAIL和IA_NAs和/或IA_TAs（状态码选项NOADRSAVAIL）的播发。
Note: Clients MUST handle the last two formats listed above to facilitate backward compatibility with the servers that have not been updated to this specification.
注意：客户端必须处理上面列出的最后两种格式，以便与尚未更新到此规范的服务器向后兼容。
See Section 4.2 for updated text for Section 17.1.3 of RFC 3315 and Section 11.1 of RFC 3633.
有关RFC 3315第17.1.3节和RFC 3633第11.1节的更新文本，请参见第4.2节。
Servers MUST return the Status Code option of NoAddrsAvail encapsulated in IA_NA/IA_TA options and MUST NOT return a top-level Status Code option of NoAddrsAvail when no addresses will be assigned (number 1 in the above list). This means that the Advertise response matches the Reply response with respect to the handling of the NoAddrsAvail status.
服务器必须返回封装在IA_NA/IA_TA options中的NOADRSAVail的状态代码选项，并且在未分配地址时不得返回NOADRSAVail的顶级状态代码选项（上面列表中的数字1）。这意味着播发响应与应答响应在处理NoAddrsAvail状态方面相匹配。
Replace the following paragraph in RFC 3315, Section 17.2.2:
替换RFC 3315第17.2.2节中的以下段落：
If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID.
如果服务器在来自客户端的后续请求中不会将任何地址分配给任何IAs，则服务器必须向客户端发送一条播发消息，该消息仅包括一个带有代码NOADRSAVAIL的状态代码选项和一条针对用户的状态消息，一个带有服务器DUID的服务器标识符选项，以及一个带有客户端DUID的客户端标识符选项。
With the following text (which addresses the existing erratum [Err2472]):
使用以下文本（解决现有勘误表[Err2472]）：
If the server will not assign any addresses to an IA in a subsequent Request from the client, the server MUST include the IA in the Advertise message with no addresses in the IA and a Status Code option encapsulated in the IA containing status code NoAddrsAvail.
如果服务器在客户端的后续请求中不会向IA分配任何地址，则服务器必须在播发消息中包含IA，IA中不包含地址，并且在IA中封装状态代码选项（包含状态代码NoAddrsAvail）。
[RFC3315] specifies that a client must ignore an Advertise message if a server will not assign any addresses to a client, and [RFC3633] specifies that a client must ignore an Advertise message if a server returns the NoPrefixAvail status to a requesting router. Thus, a client requesting both IA_NA and IA_PD, with a server that only offers either addresses or delegated prefixes, is not supported by the current protocol specifications.
[RFC3315]指定如果服务器不向客户端分配任何地址，客户端必须忽略播发消息，[RFC3633]指定如果服务器向请求路由器返回NoPrefixAvail状态，客户端必须忽略播发消息。因此，当前协议规范不支持同时请求IA_NA和IA_PD的客户端，而服务器只提供地址或委派前缀。
Solution: a client SHOULD accept Advertise messages, even when not all IA option types are being offered. And, in this case, the client SHOULD include the not offered IA option types in its Request. A client SHOULD only ignore an Advertise message when none of the requested IA options include offered addresses or delegated prefixes. Note that ignored messages MUST still be processed for SOL_MAX_RT and INF_MAX_RT options as specified in [RFC7083].
解决方案：即使不是所有IA选项类型都提供，客户机也应该接受播发消息。在这种情况下，客户机应该在其请求中包含未提供的IA选项类型。只有当请求的IA选项中没有包含提供的地址或委派的前缀时，客户端才应忽略播发消息。请注意，对于[RFC7083]中指定的SOL_MAX_RT和INF_MAX_RT选项，仍必须处理被忽略的消息。
Replace Section 17.1.3 of RFC 3315: (existing errata)
替换RFC 3315第17.1.3节：（现有勘误表）
The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message(s) to the user.
客户端必须忽略任何包含包含值NOADRSAVAIL的状态代码选项的播发消息，但客户端可能会向用户显示关联的状态消息除外。
With the following text (which addresses the existing erratum [Err2471] and includes the changes made by [RFC7083]):
以下文本（解决了现有勘误表[Err2471]，包括[RFC7083]所做的更改）：
The client MUST ignore any Advertise message that contains no addresses (IAADDR options encapsulated in IA_NA or IA_TA options) and no delegated prefixes (IAPREFIX options encapsulated in IA_PD options; see RFC 3633) with the exception that the client:
客户端必须忽略任何不包含地址（IA_NA或IA_TA选项中封装的IAADDR选项）和未包含委派前缀（IA_PD选项中封装的IAPREFIX选项；请参阅RFC 3633）的播发消息，但客户端：
- MUST process an included SOL_MAX_RT option (RFC 7083) and - MUST process an included INF_MAX_RT option (RFC 7083).
- 必须处理包含的SOL_MAX_RT选项（RFC 7083）和-必须处理包含的INF_MAX_RT选项（RFC 7083）。
A client can display any associated status message(s) to the user or activity log.
客户端可以向用户或活动日志显示任何关联的状态消息。
The client ignoring this Advertise message MUST NOT restart the Solicit retransmission timer.
忽略此播发消息的客户端不得重新启动请求重传计时器。
And, replace:
以及，替换：
- The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available addresses advertised in IAs.
- 如果服务器具有一组更好的公布参数，例如在IAs中公布的可用地址，则客户端可以选择一个不太首选的服务器。
With:
与：
- The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available set of IAs, as well as the set of other configuration options advertised.
- 如果服务器具有更好的公布参数集（例如可用的IAs集）以及公布的其他配置选项集，则客户端可以选择较不首选的服务器。
And, replace the last paragraph of Section 11.1 of RFC 3633 with the following text (which addresses the existing erratum [Err2469]):
并且，将RFC 3633第11.1节的最后一段替换为以下文本（解决现有勘误表[Err2469]）：
The requesting router MUST ignore any Advertise message that contains no addresses (IAADDR options encapsulated in IA_NA or IA_TA options) and no delegated prefixes (IAPREFIX options encapsulated in IA_PD options; see RFC 3633) with the exception that the requesting router:
请求路由器必须忽略任何不包含地址（IA_NA或IA_TA选项中封装的IAADDR选项）和不包含委派前缀（IA_PD选项中封装的IAPREFIX选项；请参阅RFC 3633）的播发消息，但请求路由器：
- MUST process an included SOL_MAX_RT option (RFC 7083) and - MUST process an included INF_MAX_RT option (RFC 7083).
- 必须处理包含的SOL_MAX_RT选项（RFC 7083）和-必须处理包含的INF_MAX_RT选项（RFC 7083）。
A client can display any associated status message(s) to the user or activity log.
客户端可以向用户或活动日志显示任何关联的状态消息。
The requesting router ignoring this Advertise message MUST NOT restart the Solicit retransmission timer.
忽略此播发消息的请求路由器不得重新启动请求重传计时器。
The T1 and T2 times determine when the client will contact the server to extend lifetimes of information received in an IA. How should a client handle the case where multiple IA options have different T1 and T2 times?
T1和T2时间确定客户端何时联系服务器以延长IA中接收的信息的生命周期。如果多个IA选项具有不同的T1和T2时间，客户机应如何处理这种情况？
In a multiple IA option type model, the T1/T2 times are protocol timers that should be independent of the IA options themselves. If we were to redo the DHCP protocol from scratch, the T1/T2 times should be carried in a separate DHCP option.
在多IA选项类型模型中，T1/T2时间是协议计时器，应该独立于IA选项本身。如果我们从头开始重做DHCP协议，T1/T2时间应该在单独的DHCP选项中进行。
Solution: The server MUST set the T1/T2 times in all IA options in a Reply or Advertise message to the same value. To deal with the case where servers have not yet been updated to do that, the client MUST select a T1 and T2 time from all IA options, which will guarantee
解决方案：服务器必须将回复或播发消息中所有IA选项中的T1/T2时间设置为相同的值。要处理服务器尚未更新的情况，客户端必须从所有IA选项中选择T1和T2时间，这将保证
that the client will send Renew/Rebind messages not later than at the T1/T2 times associated with any of the client's bindings.
客户端将不晚于与任何客户端绑定相关的T1/T2时间发送续订/重新绑定消息。
As an example, if the client receives a Reply with T1_NA of 3600 / T2_NA of 5760 and T1_PD of 0 / T2_PD of 1800, the client SHOULD use the T1_PD of 0 / T2_PD of 1800. The reason for this is that a T1 of 0 means that the Renew time is at the client's discretion, but this value cannot be greater than the T2 value (1800).
例如，如果客户机收到的回复的T1_NA为3600/T2_NA为5760，T1_PD为0/T2_PD为1800，则客户机应使用0/T2_PD为1800的T1_PD。原因是T1为0表示续订时间由客户自行决定，但该值不能大于T2值（1800）。
The following paragraph should be added to Sections 18.2.1, 18.2.3, and 18.2.4 of RFC 3315:
应在RFC 3315第18.2.1、18.2.3和18.2.4节中添加以下段落：
The T1/T2 times set in each applicable IA option for a Reply MUST be the same values across all IAs. The server MUST determine the T1/T2 times across all of the applicable client's bindings in the Reply. This facilitates the client being able to renew all of the bindings at the same time.
在每个适用的IA选项中为回复设置的T1/T2时间在所有IA中必须是相同的值。服务器必须在应答中确定所有适用客户端绑定的T1/T2时间。这使客户端能够同时更新所有绑定。
Note: This additional paragraph has also been included in the revised text later in this document for Sections 18.2.3 and 18.2.4 of RFC 3315.
注：本附加段落也已包含在本文件下文RFC 3315第18.2.3节和第18.2.4节的修订文本中。
Changes for client T1/T2 handling are included in Sections 4.4.3 and 4.4.4.
客户T1/T2处理的变更包含在第4.4.3节和第4.4.4节中。
This section presents issues with handling multiple IA option types in the context of creation and processing the Renew and Rebind messages. It also introduces relevant updates to [RFC3315] and [RFC3633].
本节介绍在创建和处理续订和重新绑定消息的上下文中处理多个IA选项类型的问题。它还介绍了[RFC3315]和[RFC3633]的相关更新。
In multiple IA option type models, the client may include multiple IA options in the Request message, and the server may create bindings only for a subset of the IA options included by the client. For the IA options in the Request message for which the server does not create the bindings, the server sends the IA options in the Reply message with the NoAddrsAvail or NoPrefixAvail status codes.
在多IA选项类型模型中，客户端可能在请求消息中包含多个IA选项，服务器可能仅为客户端包含的IA选项的子集创建绑定。对于服务器未为其创建绑定的请求消息中的IA选项，服务器会在回复消息中发送带有NOADRSAVAIL或NoPrefixAvail状态代码的IA选项。
The client may accept the bindings created by the server, but may desire the other bindings to be created once they become available, e.g., when the server configuration is changed. The client that accepted the bindings created by the server will periodically send a Renew message to extend their lifetimes. However, the Renew message,
客户端可以接受服务器创建的绑定，但可能希望在其他绑定可用时（例如，当服务器配置更改时）创建这些绑定。接受服务器创建的绑定的客户端将定期发送续订消息以延长其生命周期。然而，更新消息，
as described in [RFC3315], does not support the ability for the client to extend the lifetimes of the bindings for some IAs, while requesting bindings for other IAs.
如[RFC3315]所述，不支持客户端在请求其他IAs绑定的同时，延长某些IAs绑定的生存期。
Solution: The client, which sends a Renew message to extend the lifetimes of the bindings assigned to the client, SHOULD include IA options for these bindings as well as IA options for all other bindings that the client desires but has been unable to obtain. The client and server processing need to be modified. Note that this change makes the server's IA processing of Renew similar to the Request processing.
解决方案：客户端发送续订消息以延长分配给客户端的绑定的生存期，它应该包括这些绑定的IA选项以及客户端希望但无法获得的所有其他绑定的IA选项。需要修改客户端和服务器处理。请注意，此更改使服务器的续订IA处理与请求处理类似。
According to Section 4.4.1, the client includes IA options in a Renew message for the bindings it desires but has been unable to obtain by sending a Request message, apart from the IA options for the existing bindings.
根据第4.4.1节的规定，除了现有绑定的IA选项外，客户机还将IA选项包含在续订消息中，用于其所需但无法通过发送请求消息获得的绑定。
At time T2, the client stops sending Renew messages to the server and initiates the Rebind/Reply message exchange with any available server. In this case, it should be possible to continue trying to obtain new bindings using the Rebind message if the client failed to get the response from the server to the Renew message.
在时间T2，客户端停止向服务器发送续订消息，并启动与任何可用服务器的重新绑定/回复消息交换。在这种情况下，如果客户端无法从服务器获取对续订消息的响应，则应该可以继续尝试使用Rebind消息获取新绑定。
Solution: The client SHOULD continue to include the IA options received from the server, and it MAY include additional IA options to request creation of the additional bindings.
解决方案：客户机应继续包括从服务器接收的IA选项，并且可能包括其他IA选项以请求创建其他绑定。
Replace Section 18.1.3 of RFC 3315 with the following text:
将RFC 3315第18.1.3节替换为以下文本：
To extend the valid and preferred lifetimes for the addresses assigned to an IA, the client sends a Renew message to the server from which the addresses were obtained, which includes an IA option for the IA whose address lifetimes are to be extended. The client includes IA Address options within the IA option for the addresses assigned to the IA. The server determines new lifetimes for these addresses according to the administrative configuration of the server. The server may also add new addresses to the IA. The server can remove addresses from the IA by returning IA Address options for such addresses with preferred and valid lifetimes set to 0.
为了延长分配给IA的地址的有效和首选生存期，客户端向从中获取地址的服务器发送续订消息，该消息包括要延长地址生存期的IA的IA选项。对于分配给IA的地址，客户端在IA选项中包含IA地址选项。服务器根据服务器的管理配置确定这些地址的新生存期。服务器还可以向IA添加新地址。服务器可以通过返回首选和有效生存期设置为0的地址的IA地址选项，从IA中删除地址。
The server controls the time at which the client contacts the server to extend the lifetimes on assigned addresses through the T1 and T2 parameters assigned to an IA. However, as the client
服务器通过分配给IA的T1和T2参数控制客户端与服务器联系以延长分配地址的生存期的时间。然而，作为客户
Renews/Rebinds all IAs from the server at the same time, the client MUST select a T1 and T2 time from all IA options, which will guarantee that the client will send Renew/Rebind messages not later than at the T1/T2 times associated with any of the client's bindings.
从服务器续订/重新绑定所有IA同时，客户端必须从所有IA选项中选择T1和T2时间，这将保证客户端发送续订/重新绑定消息的时间不晚于与任何客户端绑定相关的T1/T2时间。
At time T1, the client initiates a Renew/Reply message exchange to extend the lifetimes on any addresses in the IA.
在时间T1，客户端发起续订/应答消息交换，以延长IA中任何地址的生存期。
If T1 or T2 had been set to 0 by the server (for an IA_NA) or there are no T1 or T2 times (for an IA_TA) in a previous Reply, the client may send a Renew or Rebind message, respectively, at the client's discretion.
如果服务器（对于IA_NA）将T1或T2设置为0，或者在以前的回复中没有T1或T2次（对于IA_TA），则客户端可以自行决定分别发送续订或重新绑定消息。
The client sets the "msg-type" field to RENEW. The client generates a transaction ID and inserts this value in the "transaction-id" field.
客户端将“消息类型”字段设置为续订。客户端生成一个事务ID并将该值插入“事务ID”字段。
The client places the identifier of the destination server in a Server Identifier option.
客户端将目标服务器的标识符放置在服务器标识符选项中。
The client MUST include a Client Identifier option to identify itself to the server. The client adds any appropriate options, including one or more IA options.
客户机必须包含一个客户机标识符选项，以便向服务器标识自己。客户端添加任何适当的选项，包括一个或多个IA选项。
For IAs to which addresses have been assigned, the client includes a corresponding IA option containing an IA Address option for each address assigned to the IA. The client MUST NOT include addresses in any IA option that the client did not obtain from the server or that are no longer valid (that have a valid lifetime of 0).
对于已分配地址的IAs，客户端包括一个相应的IA选项，其中包含分配给IA的每个地址的IA地址选项。客户端不得在任何IA选项中包含客户端未从服务器获取的地址或不再有效的地址（有效生存期为0）。
The client MAY include an IA option for each binding it desires but has been unable to obtain. This IA option MUST NOT contain any addresses. However, it MAY contain the IA Address option with the "IPv6 address" field set to 0 to indicate the client's preference for the preferred and valid lifetimes for any newly assigned addresses.
客户可能会为其希望但无法获得的每个绑定提供IA选项。此IA选项不得包含任何地址。但是，它可能包含“IPv6地址”字段设置为0的IA地址选项，以指示客户端对任何新分配地址的首选和有效生存期的偏好。
The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.
客户必须包括一个选项请求选项（见第22.7节），以表明客户有兴趣接收的选项。客户机可能包括带有数据值的选项，作为向服务器提示客户机希望返回的参数值。
The client transmits the message according to section 14, using the following parameters:
客户端使用以下参数根据第14节传输消息：
IRT REN_TIMEOUT
IRT RENU超时
MRT REN_MAX_RT
捷运站
MRC 0
MRC 0
MRD Remaining time until T2
MRD到T2的剩余时间
The message exchange is terminated when time T2 is reached (see section 18.1.4), at which time the client begins a Rebind message exchange.
当到达时间T2（见第18.1.4节）时，消息交换终止，此时客户端开始重新绑定消息交换。
Replace Section 18.1.4 of RFC 3315 with the following text:
将RFC 3315第18.1.4节替换为以下文本：
At time T2 (which will only be reached if the server to which the Renew message was sent at time T1 has not responded), the client initiates a Rebind/Reply message exchange with any available server.
在时间T2（仅当在时间T1向其发送续订消息的服务器没有响应时才会到达该时间T2），客户端启动与任何可用服务器的重新绑定/回复消息交换。
The client constructs the Rebind message as described in section 18.1.3 with the following differences:
客户端按照第18.1.3节所述构造重新绑定消息，但有以下区别：
- The client sets the "msg-type" field to REBIND.
- 客户端将“msg type”字段设置为重新绑定。
- The client does not include the Server Identifier option in the Rebind message.
- 客户端在重新绑定消息中不包括服务器标识符选项。
The client transmits the message according to section 14, using the following parameters:
客户端使用以下参数根据第14节传输消息：
IRT REB_TIMEOUT
IRT REB_超时
MRT REB_MAX_RT
捷运快线快线
MRC 0
MRC 0
MRD Remaining time until valid lifetimes of all addresses in all IAs have expired
MRD剩余时间，直到所有IAs中所有地址的有效生存期到期
If all addresses for an IA have expired, the client may choose to include this IA without any addresses (or with only a hint for lifetimes) in subsequent Rebind messages to indicate that the client is interested in assignment of the addresses to this IA.
如果IA的所有地址都已过期，则客户端可以选择在后续重新绑定消息中包含此IA，而不包含任何地址（或仅包含生存期提示），以表明客户端有兴趣将地址分配给此IA。
The message exchange is terminated when the valid lifetimes of all addresses across all IAs have expired, at which time the client uses the Solicit message to locate a new DHCP server and sends a Request for the expired IAs to the new server.
当所有IAs中所有地址的有效生存期过期时，消息交换终止，此时客户端使用请求消息定位新的DHCP服务器，并向新服务器发送过期IAs的请求。
Replace Section 18.1.8 of RFC 3315 with the following text:
将RFC 3315第18.1.8节替换为以下文本：
Upon the receipt of a valid Reply message in response to a Solicit (with a Rapid Commit option), Request, Confirm, Renew, Rebind, or Information-request message, the client extracts the configuration information contained in the Reply. The client MAY choose to report any status code or message from the Status Code option in the Reply message.
在收到响应请求（具有快速提交选项）、请求、确认、续订、重新绑定或信息请求消息的有效回复消息后，客户端提取回复中包含的配置信息。客户端可以从回复消息中的状态代码选项中选择报告任何状态代码或消息。
If the client receives a Reply message with a status code containing UnspecFail, the server is indicating that it was unable to process the message due to an unspecified failure condition. If the client retransmits the original message to the same server to retry the desired operation, the client MUST limit the rate at which it retransmits the message and limit the duration of the time during which it retransmits the message.
如果客户端接收到状态代码包含UnspecFail的回复消息，则服务器表示由于未指定的故障条件，它无法处理该消息。如果客户端将原始消息重新传输到同一服务器以重试所需操作，则客户端必须限制其重新传输消息的速率，并限制其重新传输消息的持续时间。
When the client receives a Reply message with a Status Code option with the value UseMulticast, the client records the receipt of the message and sends subsequent messages to the server through the interface on which the message was received using multicast. The client resends the original message using multicast.
当客户端接收到一条带有状态代码选项且值为UseMulticast的回复消息时，客户端会记录消息的接收情况，并通过使用multicast接收消息的接口将后续消息发送到服务器。客户端使用多播重新发送原始消息。
When the client receives a NotOnLink status from the server in response to a Confirm message, the client performs DHCP server solicitation, as described in section 17, and client-initiated configuration, as described in section 18. If the client receives any Reply messages that do not indicate a NotOnLink status, the client can use the addresses in the IA and ignore any messages that indicate a NotOnLink status.
当客户端收到来自服务器的NotOnLink状态以响应确认消息时，客户端执行DHCP服务器请求（如第17节所述）和客户端启动配置（如第18节所述）。如果客户端收到任何不指示NotOnLink状态的回复消息，则客户端可以使用IA中的地址并忽略任何指示NotOnLink状态的消息。
When the client receives a NotOnLink status from the server in response to a Request, the client can either reissue the Request without specifying any addresses or restart the DHCP server discovery process (see section 17).
当客户端从服务器接收到响应请求的NotOnLink状态时，客户端可以在不指定任何地址的情况下重新发出请求，也可以重新启动DHCP服务器发现过程（请参阅第17节）。
The client SHOULD perform duplicate address detection [17] on each of the received addresses in any IAs, on which it has not performed duplicate address detection during processing of any of the previous Reply messages from the server. The client performs the duplicate address detection before using the received addresses for
客户机应在任何IAs中的每个接收地址上执行重复地址检测[17]，在处理来自服务器的任何先前回复消息期间，客户机未对其执行重复地址检测。客户端在使用接收到的地址进行复制之前执行重复地址检测
the traffic. If any of the addresses are found to be in use on the link, the client sends a Decline message to the server for those addresses as described in section 18.1.7.
交通堵塞。如果发现任何地址在链路上使用，客户端将向服务器发送拒绝消息，以获取第18.1.7节所述的地址。
If the Reply was received in response to a Solicit (with a Rapid Commit option), Request, Renew, or Rebind message, the client updates the information it has recorded about IAs from the IA options contained in the Reply message:
如果收到回复是对请求（具有快速提交选项）、请求、续订或重新绑定消息的响应，则客户机将根据回复消息中包含的IA选项更新其记录的有关IAs的信息：
- Record T1 and T2 times.
- 记录T1和T2次。
- Add any new addresses in the IA option to the IA as recorded by the client.
- 将IA选项中的任何新地址添加到客户端记录的IA中。
- Update lifetimes for any addresses in the IA option that the client already has recorded in the IA.
- 更新IA选项中客户端已在IA中记录的任何地址的生存期。
- Discard any addresses from the IA, as recorded by the client, that have a valid lifetime of 0 in the IA Address option.
- 丢弃客户端记录的IA地址中IA地址选项中有效生存期为0的所有地址。
- Leave unchanged any information about addresses the client has recorded in the IA but that were not included in the IA from the server.
- 保留有关客户端已记录在IA中但未包含在服务器IA中的地址的任何信息不变。
Management of the specific configuration information is detailed in the definition of each option in section 22.
具体配置信息的管理详见第22节中每个选项的定义。
The client examines the status code in each IA individually. If the client receives a NoAddrsAvail status code, the client has received no usable addresses in the IA.
客户机单独检查每个IA中的状态代码。如果客户端收到NoAddrsAvail状态代码，则表示客户端在IA中未收到可用地址。
If the client can operate with the addresses obtained from the server, the client uses addresses and other information from any IAs that do not contain a Status Code option with the NoAddrsAvail status code. The client MAY include the IAs for which it received the NoAddrsAvail status code, with no addresses, in subsequent Renew and Rebind messages sent to the server, to retry obtaining the addresses for these IAs.
如果客户机可以使用从服务器获得的地址进行操作，则客户机将使用来自任何IAs的地址和其他信息，这些IAs不包含带有NOADRSAVAIL状态代码的状态代码选项。客户端可以在发送到服务器的后续续订和重新绑定消息中包括接收到NoAddrsAvail状态代码（无地址）的IAs，以重试获取这些IAs的地址。
If the client cannot operate without the addresses for the IAs for which it received the NoAddrsAvail status code, the client may try another server (perhaps by restarting the DHCP server discovery process).
如果客户端在没有收到NoAddrsAvail状态代码的IAs地址的情况下无法运行，则客户端可以尝试其他服务器（可能通过重新启动DHCP服务器发现过程）。
If the client finds no usable addresses in any of the IAs, it may either try another server (perhaps restarting the DHCP server discovery process) or use the Information-request message to obtain other configuration information only.
如果客户端在任何IAs中找不到可用的地址，它可以尝试另一台服务器（可能重新启动DHCP服务器发现过程），或者使用信息请求消息仅获取其他配置信息。
When the client receives a Reply message in response to a Renew or Rebind message, the client:
当客户端收到响应续订或重新绑定消息的回复消息时，客户端：
- sends a Request message if any of the IAs in the Reply message contains the NoBinding status code. The client places IA options in this message for only those IAs for which the server returned the NoBinding status code in the Reply message. The client continues to use other bindings for which the server did not return an error.
- 如果回复消息中的任何IAs包含NoBinding状态代码，则发送请求消息。客户端在此消息中仅为服务器在回复消息中为其返回NoBinding状态代码的IAs放置IA选项。客户端继续使用服务器未返回错误的其他绑定。
- sends a Renew/Rebind if any of the IAs are not in the Reply message, but in this case the client MUST limit the rate at which it sends these messages, to avoid the Renew/Rebind storm.
- 如果任何IAs不在回复消息中，则发送续订/重新绑定，但在这种情况下，客户端必须限制其发送这些消息的速率，以避免续订/重新绑定风暴。
- otherwise accepts the information in the IA.
- 否则接受IA中的信息。
When the client receives a valid Reply message in response to a Release message, the client considers the Release event completed, regardless of the Status Code option(s) returned by the server.
当客户端收到响应发布消息的有效回复消息时，无论服务器返回的状态代码选项是什么，客户端都会认为发布事件已完成。
When the client receives a valid Reply message in response to a Decline message, the client considers the Decline event completed, regardless of the Status Code option(s) returned by the server.
当客户端收到响应拒绝消息的有效回复消息时，无论服务器返回的状态代码选项如何，客户端都会认为拒绝事件已完成。
Replace Section 18.2.3 of RFC 3315 with the following text:
将RFC 3315第18.2.3节替换为以下文本：
When the server receives a Renew message via unicast from a client to which the server has not sent a unicast option, the server discards the Renew message and responds with a Reply message containing a Status Code option with the value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options.
当服务器通过单播从未向其发送单播选项的客户端接收到续订消息时，服务器将丢弃续订消息，并使用包含值为UseMotcast的状态代码选项（包含服务器DUID的服务器标识符选项）的回复消息进行响应，客户端消息中的客户端标识符选项，不包含其他选项。
For each IA in the Renew message from a client, the server locates the client's binding and verifies that the information in the IA from the client matches the information stored for that client.
对于来自客户端的续订消息中的每个IA，服务器将定位客户端的绑定，并验证来自客户端的IA中的信息是否与为该客户端存储的信息匹配。
If the server finds the client entry for the IA, the server sends back the IA to the client with new lifetimes and, if applicable, T1/T2 times. If the server is unable to extend the lifetimes of an address in the IA, the server MAY choose not to include the IA Address option for this address.
如果服务器找到IA的客户机条目，则服务器将IA发送回客户机，并提供新的生存期，如果适用，还包括T1/T2时间。如果服务器无法延长IA中地址的生存期，则服务器可能会选择不包含此地址的IA地址选项。
The server may choose to change the list of addresses and the lifetimes of addresses in IAs that are returned to the client.
服务器可以选择更改IAs中返回给客户端的地址列表和地址的生存期。
If the server finds that any of the addresses in the IA are not appropriate for the link to which the client is attached, the server returns the address to the client with lifetimes of 0.
如果服务器发现IA中的任何地址不适合客户端连接到的链接，则服务器将地址返回给客户端，其生存期为0。
For each IA for which the server cannot find a client entry, the server has the following choices depending on the server's policy and configuration information:
对于服务器找不到客户端条目的每个IA，服务器根据服务器的策略和配置信息有以下选择：
- If the server is configured to create new bindings as a result of processing Renew messages, the server SHOULD create a binding and return the IA with allocated addresses with lifetimes and, if applicable, T1/T2 times and other information requested by the client. The server MAY use values in the IA Address option (if included) as a hint.
- 如果服务器配置为在处理续订消息后创建新绑定，则服务器应创建一个绑定，并返回IA，其中包含已分配的地址、生存时间、T1/T2时间（如果适用）以及客户端请求的其他信息。服务器可以使用IA地址选项（如果包括）中的值作为提示。
- If the server is configured to create new bindings as a result of processing Renew messages, but the server will not assign any addresses to an IA, the server returns the IA option containing a Status Code option with the NoAddrsAvail status code and a status message for a user.
- 如果服务器配置为在处理续订消息后创建新绑定，但服务器不会为IA分配任何地址，则服务器将返回IA选项，其中包含状态代码选项、NOADRSAVAIL状态代码以及用户的状态消息。
- If the server does not support creation of new bindings for the client sending a Renew message, or if this behavior is disabled according to the server's policy or configuration information, the server returns the IA option containing a Status Code option with the NoBinding status code and a status message for a user.
- 如果服务器不支持为发送续订消息的客户端创建新绑定，或者根据服务器的策略或配置信息禁用了此行为，则服务器将返回IA选项，该选项包含一个状态代码选项，其中包含NoBinding Status Code和一条用户状态消息。
The server constructs a Reply message by setting the "msg-type" field to REPLY and copying the transaction ID from the Renew message into the "transaction-id" field.
服务器通过将“msg type”字段设置为Reply并将事务ID从续订消息复制到“transaction ID”字段中来构造回复消息。
The server MUST include a Server Identifier option containing the server's DUID and the Client Identifier option from the Renew message in the Reply message.
服务器必须在回复消息中包含包含服务器DUID的服务器标识符选项和续订消息中的客户端标识符选项。
The server includes other options containing configuration information to be returned to the client as described in section 18.2.
如第18.2节所述，服务器包括包含要返回给客户端的配置信息的其他选项。
The T1/T2 times set in each applicable IA option for a Reply MUST be the same values across all IAs. The server MUST determine the T1/T2 times across all of the applicable client's bindings in the Reply. This facilitates the client being able to renew all of the bindings at the same time.
在每个适用的IA选项中为回复设置的T1/T2时间在所有IA中必须是相同的值。服务器必须在应答中确定所有适用客户端绑定的T1/T2时间。这使客户端能够同时更新所有绑定。
Replace Section 18.2.4 of RFC 3315 with the following text:
将RFC 3315第18.2.4节替换为以下文本：
When the server receives a Rebind message that contains an IA option from a client, it locates the client's binding and verifies that the information in the IA from the client matches the information stored for that client.
当服务器从客户端接收到包含IA选项的重新绑定消息时，它将定位客户端的绑定，并验证来自客户端的IA中的信息是否与为该客户端存储的信息匹配。
If the server finds the client entry for the IA and the server determines that the addresses in the IA are appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server SHOULD send back the IA to the client with new lifetimes and, if applicable, T1/T2 times. If the server is unable to extend the lifetimes of an address in the IA, the server MAY choose not to include the IA Address option for this address.
如果服务器找到IA的客户机条目，并且服务器根据服务器的显式配置信息确定IA中的地址适用于客户端接口连接到的链接，则服务器应将IA发送回具有新生命周期的客户机，如果适用，还应发送T1/T2时间。如果服务器无法延长IA中地址的生存期，则服务器可能会选择不包含此地址的IA地址选项。
If the server finds that the client entry for the IA and any of the addresses are no longer appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server returns the address to the client with lifetimes of 0.
如果根据服务器的显式配置信息，服务器发现IA的客户端条目和任何地址不再适用于客户端接口连接到的链接，则服务器会将地址返回给客户端，其生存期为0。
If the server cannot find a client entry for the IA, the IA contains addresses and the server determines that the addresses in the IA are not appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server MAY send a Reply message to the client containing the client's IA, with the lifetimes for the addresses in the IA set to 0. This Reply constitutes an explicit notification to the client that the addresses in the IA are no longer valid. In this situation, if the server does not send a Reply message, it silently discards the Rebind message.
如果服务器找不到IA的客户端条目，IA包含地址，并且服务器根据服务器的显式配置信息确定IA中的地址不适合客户端接口连接到的链接，则服务器可以向包含客户端IA的客户端发送回复消息，IA中地址的生存期设置为0。此回复构成对客户端的明确通知，即IA中的地址不再有效。在这种情况下，如果服务器不发送回复消息，它会自动丢弃重新绑定消息。
Otherwise, for each IA for which the server cannot find a client entry, the server has the following choices depending on the server's policy and configuration information:
否则，对于服务器找不到客户端条目的每个IA，服务器根据服务器的策略和配置信息有以下选择：
- If the server is configured to create new bindings as a result of processing Rebind messages (also see the note about the Rapid Commit option below), the server SHOULD create a binding and return the IA with allocated addresses with lifetimes and, if applicable, T1/T2 times and other information requested by the client. The server MAY use values in the IA Address option (if included) as a hint.
- 如果服务器配置为在处理重新绑定消息后创建新绑定（另请参阅下面关于快速提交选项的说明），则服务器应创建绑定并返回IA，其中包含分配的地址、生存时间，以及T1/T2时间（如果适用）和客户机请求的其他信息。服务器可以使用IA地址选项（如果包括）中的值作为提示。
- If the server is configured to create new bindings as a result of processing Rebind messages, but the server will not assign any addresses to an IA, the server returns the IA option containing a Status Code option with the NoAddrsAvail status code and a status message for a user.
- 如果服务器配置为在处理重新绑定消息后创建新绑定，但服务器不会将任何地址分配给IA，则服务器将返回IA选项，其中包含状态代码选项、NOADRSAVAIL状态代码以及用户的状态消息。
- If the server does not support creation of new bindings for the client sending a Rebind message, or if this behavior is disabled according to the server's policy or configuration information, the server returns the IA option containing a Status Code option with the NoBinding status code and a status message for a user.
- 如果服务器不支持为发送重新绑定消息的客户端创建新绑定，或者根据服务器的策略或配置信息禁用了此行为，则服务器将返回IA选项，该选项包含状态代码选项、NoBinding状态代码以及用户的状态消息。
When the server creates new bindings for the IA, it is possible that other servers also create bindings as a result of receiving the same Rebind message. This is the same issue as in the Discussion under "Rapid Commit Option"; see section 22.14. Therefore, the server SHOULD only create new bindings during processing of a Rebind message if the server is configured to respond with a Reply message to a Solicit message containing the Rapid Commit option.
当服务器为IA创建新绑定时，其他服务器也可能会由于接收到相同的重新绑定消息而创建绑定。这与“快速提交选项”下讨论的问题相同；见第22.14节。因此，如果服务器配置为使用回复消息响应包含快速提交选项的请求消息，则服务器仅应在处理重新绑定消息期间创建新绑定。
The server constructs a Reply message by setting the "msg-type" field to REPLY and copying the transaction ID from the Rebind message into the "transaction-id" field.
服务器通过将“msg type”字段设置为Reply并将事务ID从重新绑定消息复制到“transaction ID”字段中来构造一条回复消息。
The server MUST include a Server Identifier option containing the server's DUID and the Client Identifier option from the Rebind message in the Reply message.
服务器必须包括一个包含服务器DUID的服务器标识符选项和回复消息中重新绑定消息的客户端标识符选项。
The server includes other options containing configuration information to be returned to the client as described in section 18.2.
如第18.2节所述，服务器包括包含要返回给客户端的配置信息的其他选项。
The T1/T2 times set in each applicable IA option for a Reply MUST be the same values across all IAs. The server MUST determine the T1/T2 times across all of the applicable client's bindings in the Reply. This facilitates the client being able to renew all of the bindings at the same time.
在每个适用的IA选项中为回复设置的T1/T2时间在所有IA中必须是相同的值。服务器必须在应答中确定所有适用客户端绑定的T1/T2时间。这使客户端能够同时更新所有绑定。
Replace the following text in Section 12.1 of RFC 3633:
替换RFC 3633第12.1节中的以下文本：
Each prefix has valid and preferred lifetimes whose durations are specified in the IA_PD Prefix option for that prefix. The requesting router uses Renew and Rebind messages to request the extension of the lifetimes of a delegated prefix.
每个前缀都有有效的首选生存期，其持续时间在该前缀的IA_PD prefix选项中指定。请求路由器使用Renew和Rebind消息请求延长委派前缀的生存期。
With:
与：
Each prefix has valid and preferred lifetimes whose durations are specified in the IA_PD Prefix option for that prefix. The requesting router uses Renew and Rebind messages to request the extension of the lifetimes of a delegated prefix.
每个前缀都有有效的首选生存期，其持续时间在该前缀的IA_PD prefix选项中指定。请求路由器使用Renew和Rebind消息请求延长委派前缀的生存期。
The requesting router MAY include IA_PD options without any prefixes, i.e., without an IA Prefix option or with the IPv6 prefix field of the IA Prefix option set to 0, in a Renew or Rebind message to obtain bindings it desires but has been unable to obtain. The requesting router MAY set the "prefix-length" field of the IA Prefix option as a hint to the server. As in [RFC3315], the requesting router MAY also provide lifetime hints in the IA Prefix option.
请求路由器可在续订或重新绑定消息中包括不带任何前缀的IA_PD选项，即，不带IA前缀选项或IA前缀选项的IPv6前缀字段设置为0，以获得其期望但无法获得的绑定。请求路由器可以将IA prefix选项的“prefix length”字段设置为对服务器的提示。与[RFC3315]中一样，请求路由器也可以在IA前缀选项中提供生存期提示。
Replace the following text in Section 12.2 of RFC 3633:
替换RFC 3633第12.2节中的以下文本：
The delegating router behaves as follows when it cannot find a binding for the requesting router's IA_PD:
当委托路由器找不到请求路由器的IA_PD的绑定时，其行为如下：
With:
与：
For the Renew or Rebind, if the IA_PD contains no IA Prefix option or it contains an IA Prefix option with the IPv6 prefix field set to 0, the delegating router SHOULD assign prefixes to the IA_PD according to the delegating router's explicit configuration information. In this case, if the IA_PD contains an IA Prefix option with the IPv6 prefix field set to 0, the delegating router MAY use the value in the "prefix-length" field of the IA Prefix option as a hint for the length of the prefixes to be assigned. The delegating router MAY also respect lifetime hints provided by the requesting router in the IA Prefix option.
对于续订或重新绑定，如果IA_PD不包含IA前缀选项，或者包含IPv6前缀字段设置为0的IA前缀选项，则委派路由器应根据委派路由器的显式配置信息为IA_PD分配前缀。在这种情况下，如果IA_PD包含IPv6前缀字段设置为0的IA前缀选项，则委派路由器可以使用IA前缀选项的“前缀长度”字段中的值作为要分配的前缀长度的提示。委托路由器还可以尊重请求路由器在IA前缀选项中提供的生存期提示。
The delegating router behaves as follows when it cannot find a binding for the requesting router's IA_PD containing prefixes:
当委托路由器找不到请求路由器包含前缀的IA_PD的绑定时，其行为如下：
The Confirm message, as described in [RFC3315], is specific to address assignment. It allows a server without a binding to reply to the message, under the assumption that the server only needs knowledge about the prefix(es) on the link, to inform the client that the address is likely valid or not. This message is sent when, e.g., the client has moved and needs to validate its addresses. Not all bindings can be validated by servers and the Confirm message provides for this by specifying that a server that is unable to determine the on-link status MUST NOT send a Reply.
如[RFC3315]所述，确认消息特定于地址分配。它允许没有绑定的服务器回复消息，前提是服务器只需要知道链接上的前缀，从而通知客户端地址可能有效或无效。此消息在客户端移动并需要验证其地址时发送。并非所有绑定都可以由服务器验证，确认消息通过指定无法确定链接状态的服务器不得发送回复来实现这一点。
Note: Confirm has a specific meaning and does not overload Renew/ Rebind. It also has a lower processing cost as the server does NOT need to extend lease times or otherwise send back other configuration options.
注：确认具有特定含义，且不会导致续订/重新绑定过载。它还具有较低的处理成本，因为服务器不需要延长租用时间或以其他方式发回其他配置选项。
The Confirm message is used by the client to verify that it has not moved to a different link. For IAs with addresses, the mechanism used to verify if a client has moved or not is by matching the link's on-link prefix(es) (typically a /64) against the prefix-length first bits of the addresses provided by the client in the IA_NA or IA_TA IA-types. As a consequence, Confirm can only be used when the client has an IA with an address(es) (IA_NA or IA_TA).
客户端使用确认消息来验证它是否已移动到其他链接。对于具有地址的IAs，用于验证客户端是否已移动的机制是通过将链路的链路上前缀（通常为a/64）与客户端在IA NA或IA TA IA类型中提供的地址的前缀长度第一位进行匹配。因此，只有当客户具有带有地址（IA_NA或IA_TA）的IA时，才能使用确认。
A client MUST have a binding including an IA with addresses to use the Confirm message. A client with IAs with addresses as well as other IA-types MAY, depending on the IA-type, use the Confirm message to detect if the client has moved to a different link. A client that does not have a binding with an IA with addresses MUST use the Rebind message instead.
客户端必须有一个绑定，包括一个带有地址的IA，才能使用确认消息。具有地址为的IAs以及其他IA类型的客户端可能会根据IA类型使用确认消息来检测客户端是否已移动到其他链接。没有与具有地址的IA绑定的客户端必须改用重新绑定消息。
IA_PD requires verification that the delegating router (server) has the binding for the IAs. In that case, a requesting router (client) MUST use the Rebind message in place of the Confirm message and it MUST include all of its bindings, even address IAs.
IA_PD需要验证授权路由器（服务器）是否具有IAs的绑定。在这种情况下，请求路由器（客户端）必须使用重新绑定消息来代替确认消息，并且它必须包含其所有绑定，甚至包括地址IAs。
Note that Section 18.1.2 of RFC 3315 states that a client MUST initiate a Confirm when it may have moved to a new link. This is relaxed to a SHOULD as a client may have determined whether it has or has not moved using other techniques, such as described in [RFC6059]. And, as stated above, a client with delegated prefixes MUST send a Rebind instead of a Confirm.
请注意，RFC 3315第18.1.2节规定，当客户机可能已移动到新链接时，必须启动确认。这被放宽到一个应该，因为客户端可能已经使用其他技术（如[RFC6059]中所述）确定了它是否已经移动。而且，如上所述，具有委派前缀的客户端必须发送重新绑定而不是确认。
Some client implementations have been found to send a Release message for other bindings they may have received after they determine a conflict and have correctly sent a Decline message for the conflicting address(es).
已发现一些客户端实现在确定冲突并正确发送了冲突地址的拒绝消息后，会发送其他绑定的释放消息。
A client SHOULD NOT send a Release message for other bindings it may have received just because it sent a Decline message. The client SHOULD retain the non-conflicting bindings. The client SHOULD treat the failure to acquire a binding as a result of the conflict, to be equivalent to not having received the binding, insofar as it behaves when sending Renew and Rebind messages.
客户端不应该仅仅因为发送了拒绝消息就发送它可能已收到的其他绑定的发布消息。客户端应保留非冲突绑定。客户机应将由于冲突而无法获取绑定视为未收到绑定，因为它在发送续订和重新绑定消息时的行为。
This document has assumed that all DHCP servers on a network are in a single provisioning domain and thus should be "equal" in the service that they offer. This was also assumed by [RFC3315] and [RFC3633].
本文档假设网络上的所有DHCP服务器都位于一个配置域中，因此它们所提供的服务应该“相等”。[RFC3315]和[RFC3633]也假设了这一点。
One could envision a network where the DHCP servers are in multiple provisioning domains, and it may be desirable to have the DHCP client obtain different IA-types from different provisioning domains. How a client detects the multiple provisioning domains and how it would interact with the multiple servers in these different domains is outside the scope of this document (see [MPVD-ARCH] and [DHCPv6-SUPPORT]).
可以设想一个网络，其中DHCP服务器位于多个供应域中，并且可能需要让DHCP客户端从不同的供应域获取不同的IA类型。客户机如何检测多个供应域以及如何与这些不同域中的多个服务器交互不在本文档的范围内（请参阅[MPVD-ARCH]和[DHCPv6支持]）。
There are no new security considerations pertaining to this document.
本文档没有新的安全注意事项。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，DOI 10.17487/RFC3633，2003年12月<http://www.rfc-editor.org/info/rfc3633>.
[RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 2013, <http://www.rfc-editor.org/info/rfc7083>.
[RFC7083]Droms，R.，“修改SOL_MAX_RT和INF_MAX_RT的默认值”，RFC 7083，DOI 10.17487/RFC7083，2013年11月<http://www.rfc-editor.org/info/rfc7083>.
[DHCPv6] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis", Work in Progress, draft-ietf-dhc-rfc3315bis-00, March 2015.
[DHCPv6]Mrugalski，T.，Siodelski，M.，Volz，B.，Yourtchenko，A.，Richardson，M.，Jiang，S.，和T.Lemon，“IPv6（DHCPv6）bis的动态主机配置协议”，正在进行中的工作，草案-ietf-dhc-rfc3315bis-00，2015年3月。
[DHCPv6-SUPPORT] Krishnan, S., Korhonen, J., and S. Bhandari, "Support for multiple provisioning domains in DHCPv6", Work in Progress, draft-ietf-mif-mpvd-dhcp-support-01, March 2015.
[DHCPv6支持]Krishnan，S.，Korhonen，J.，和S.Bhandari，“支持DHCPv6中的多个资源调配域”，正在进行的工作，草稿-ietf-mif-mpvd-dhcp-SUPPORT-012015年3月。
[Err2469] RFC Errata, Errata ID 2469, RFC 3633, <http://www.rfc-editor.org>.
[Err2469]RFC勘误表，勘误表ID 2469，RFC 3633<http://www.rfc-editor.org>.
[Err2471] RFC Errata, Errata ID 2471, RFC 3315, <http://www.rfc-editor.org>.
[Err2471]RFC勘误表，勘误表ID 2471，RFC 3315<http://www.rfc-editor.org>.
[Err2472] RFC Errata, Errata ID 2472, RFC 3315, <http://www.rfc-editor.org>.
[Err2472]RFC勘误表，勘误表ID 2472，RFC 3315<http://www.rfc-editor.org>.
[MPVD-ARCH] Anipko, D., "Multiple Provisioning Domain Architecture", Work in Progress, draft-ietf-mif-mpvd-arch-11, March 2015.
[MPVD-ARCH]Anipko，D.，“多供应域体系结构”，正在进行的工作，草稿-ietf-mif-MPVD-ARCH-112015年3月。
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, DOI 10.17487/RFC6059, November 2010, <http://www.rfc-editor.org/info/rfc6059>.
[RFC6059]Krishnan，S.和G.Daley，“IPv6中检测网络连接的简单程序”，RFC 6059，DOI 10.17487/RFC6059，2010年11月<http://www.rfc-editor.org/info/rfc6059>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <http://www.rfc-editor.org/info/rfc7084>.
[RFC7084]Singh，H.，Beebee，W.，Donley，C.，和B.Stark，“IPv6客户边缘路由器的基本要求”，RFC 7084，DOI 10.17487/RFC7084，2013年11月<http://www.rfc-editor.org/info/rfc7084>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <http://www.rfc-editor.org/info/rfc7227>.
[RFC7227]Hankins，D.，Mrugalski，T.，Siodelski，M.，Jiang，S.，和S.Krishnan，“创建新DHCPv6选项的指南”，BCP 187，RFC 7227，DOI 10.17487/RFC7227，2014年5月<http://www.rfc-editor.org/info/rfc7227>.
Acknowledgements
致谢
Thanks to the many people that contributed to identify the stateful issues addressed by this document and for reviewing drafts of this document, including Ralph Droms, John Brzozowski, Ted Lemon, Hemant Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, Rob Shakir, Jinmei Tatuya, Andrew Yourtchenko, Fred Templin, Tomek Mrugalski, Suresh Krishnan, and Ian Farrer.
感谢许多人，包括拉尔夫·德罗姆斯、约翰·布佐夫斯基、特德·莱蒙、赫曼特·辛格、韦斯·比比、戈劳·哈尔瓦西亚、巴德·米尔沃德、蒂姆·温特斯、罗布·夏吉尔、金美·塔图亚、安德鲁·尤琴科、弗雷德·坦普林、托梅克·穆鲁加尔斯基，为确定本文件所述的重大问题和审查本文件草案作出了贡献，苏雷什·克里希南和伊恩·法勒。
Authors' Addresses
作者地址
Ole Troan Cisco Systems, Inc. Philip Pedersens vei 20 N-1324 Lysaker Norway
Ole Troan思科系统有限公司Philip Pedersens vei 20 N-1324 Lysaker Norway
EMail: ot@cisco.com
EMail: ot@cisco.com
Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 United States
Bernie Volz Cisco Systems，Inc.美国马萨诸塞州Boxborough大道1414号，邮编01719
EMail: volz@cisco.com
EMail: volz@cisco.com
Marcin Siodelski ISC 950 Charter Street Redwood City, CA 94063 United States
美国加利福尼亚州红木市Charter Street 950号Marcin Siodelski ISC 94063
EMail: msiodelski@gmail.com
EMail: msiodelski@gmail.com