Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 6977 X. Pougnard
Category: Standards Track France Telecom
ISSN: 2070-1721 July 2013
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 6977 X. Pougnard
Category: Standards Track France Telecom
ISSN: 2070-1721 July 2013
Triggering DHCPv6 Reconfiguration from Relay Agents
从中继代理触发DHCPv6重新配置
Abstract
摘要
This document defines two new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. The Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. The Reconfigure-Reply message is used by the server to acknowledge the receipt of the Reconfigure-Request message.
本文档定义了两条新的DHCPv6消息：重新配置请求和重新配置回复。重新配置请求消息由DHCPv6中继代理发送，以通知DHCPv6服务器配置信息更改，以便DHCPv6服务器可以相应地发送重新配置消息。服务器使用重新配置回复消息确认收到重新配置请求消息。
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/rfc6977.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6977.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
5. Link Address Option . . . . . . . . . . . . . . . . . . . . . 6
6. Detailed Specification . . . . . . . . . . . . . . . . . . . 6
6.1. Messages Format . . . . . . . . . . . . . . . . . . . . . 6
6.2. Messages Validation . . . . . . . . . . . . . . . . . . . 7
6.2.1. Reconfigure-Request . . . . . . . . . . . . . . . . . 7
6.2.2. Reconfigure-Reply . . . . . . . . . . . . . . . . . . 7
6.3. Creation and Transmission of a Reconfigure-Request . . . 7
6.4. Intermediate Relay Agents Behavior . . . . . . . . . . . 9
6.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 9
6.6. Receipt of a Reconfigure-Reply . . . . . . . . . . . . . 10
7. Rate-Limiting Considerations . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
5. Link Address Option . . . . . . . . . . . . . . . . . . . . . 6
6. Detailed Specification . . . . . . . . . . . . . . . . . . . 6
6.1. Messages Format . . . . . . . . . . . . . . . . . . . . . 6
6.2. Messages Validation . . . . . . . . . . . . . . . . . . . 7
6.2.1. Reconfigure-Request . . . . . . . . . . . . . . . . . 7
6.2.2. Reconfigure-Reply . . . . . . . . . . . . . . . . . . 7
6.3. Creation and Transmission of a Reconfigure-Request . . . 7
6.4. Intermediate Relay Agents Behavior . . . . . . . . . . . 9
6.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 9
6.6. Receipt of a Reconfigure-Reply . . . . . . . . . . . . . 10
7. Rate-Limiting Considerations . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12
This document specifies two new DHCPv6 messages [RFC3315]: Reconfigure-Request and Reconfigure-Reply.
本文档指定了两条新的DHCPv6消息[RFC3315]：重新配置请求和重新配置回复。
Section 3 describes a typical problem scenario encountered that triggers the DHCPv6 server to issue a Reconfigure message when the configuration data is supplied by the relay agent. This problem may be encountered in other contexts. It is out of scope of this document to list all these cases.
第3节描述了在中继代理提供配置数据时触发DHCPv6服务器发出重新配置消息的典型问题场景。在其他情况下可能会遇到此问题。列出所有这些案例超出了本文件的范围。
Section 4 describes the proposed solution that relies on the use of Reconfigure-Request and Reconfigure-Reply messages. The Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration-information change, so that the DHCPv6 server can send a Reconfigure message accordingly. The Reconfigure-Reply message is used by the server to acknowledge the receipt of Reconfigure-Request.
第4节描述了建议的解决方案，该解决方案依赖于使用重新配置请求和重新配置回复消息。重新配置请求消息由DHCPv6中继代理发送，以通知DHCPv6服务器配置信息更改，以便DHCPv6服务器可以相应地发送重新配置消息。服务器使用重新配置回复消息确认收到重新配置请求。
Section 5 specifies the Link Address Option used by the relay agent to indicate the link on which the client is located to the server.
第5节指定中继代理使用的链路地址选项，以指示客户端到服务器所在的链路。
Section 6 provides the detailed specification of the procedure to trigger Reconfigure messages by DHCPv6 relay agents.
第6节提供了触发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]中所述进行解释。
For cases where the DHCPv6 relay agent possesses some information that would be useful to the DHCPv6 client, [RFC6422] specifies a mechanism whereby the DHCPv6 relay agent can provide such information to the DHCPv6 server, which can, in turn, pass this information on to the DHCP client. This is achieved by use of RSOO (Relay-Supplied Options option), which carries configuration data to the DHCPv6 server. The data conveyed in an RSOO is then sent back by the DHCPv6 server to the requesting DHCPv6 client.
对于DHCPv6中继代理拥有一些对DHCPv6客户端有用的信息的情况，[RFC6422]指定了一种机制，DHCPv6中继代理可以通过该机制向DHCPv6服务器提供此类信息，而DHCPv6服务器又可以将此信息传递给DHCP客户端。这是通过使用RSOO（继电器提供的选项）实现的，RSOO将配置数据传送到DHCPv6服务器。然后，在RSOO中传输的数据由DHCPv6服务器发送回请求DHCPv6客户端。
An example of RSOO usage is shown in Figure 1; only a subset of exchanged DHCPv6 and RADIUS messages is represented. Figure 1 shows a broadband network scenario in which the Network Access Server (NAS) embeds a DHCPv6 relay agent.
图1显示了RSOO使用的示例；仅表示交换的DHCPv6和RADIUS消息的子集。图1显示了一个宽带网络场景，其中网络访问服务器（NAS）嵌入了DHCPv6中继代理。
+-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server |
| | | Relay)| | |
+-------+ +-------+ +-------+
| | |
|---Solicit---------------->| |
| |---Access-Request---------->|
|<--Access-Accept------------|
| (e.g., DS-Lite-Tunnel-Name)|
....
| +-------+
| |DHCPv6 |
| |Server |
| | |
| +-------+
| |
|---Relay-Forward----------->|
| (RSOO(OPTION_AFTR_NAME)) |
| |
| |<--Relay-Reply--------------|
|<--Advertise---------------| (e.g., OPTION_AFTR_NAME) |
| (e.g., OPTION_AFTR_NAME) |
....
+-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server |
| | | Relay)| | |
+-------+ +-------+ +-------+
| | |
|---Solicit---------------->| |
| |---Access-Request---------->|
|<--Access-Accept------------|
| (e.g., DS-Lite-Tunnel-Name)|
....
| +-------+
| |DHCPv6 |
| |Server |
| | |
| +-------+
| |
|---Relay-Forward----------->|
| (RSOO(OPTION_AFTR_NAME)) |
| |
| |<--Relay-Reply--------------|
|<--Advertise---------------| (e.g., OPTION_AFTR_NAME) |
| (e.g., OPTION_AFTR_NAME) |
....
Figure 1: An Example of the RSOO Usage
图1:RSOO使用示例
A configuration change may result in an exchange of CoA (Change-of-Authorization) [RFC5176] messages between the NAS/DHCPv6 relay agent and Dynamic Authorization Client (DAC) server as shown in Figure 2. In this example, the NAS answers with a CoA-Ack message to notify the DAC that the CoA-Request has been successfully handled.
配置更改可能导致NAS/DHCPv6中继代理和动态授权客户端（DAC）服务器之间交换CoA（授权更改）[RFC5176]消息，如图2所示。在此示例中，NAS使用CoA Ack消息进行应答，以通知DAC CoA请求已成功处理。
Note that the change of the configuration in the DHCPv6 relay agent can be triggered by any other out-of-band mechanism.
请注意，DHCPv6中继代理中的配置更改可由任何其他带外机制触发。
+-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server/|
| | | Relay)| | DAC |
+-------+ +-------+ +-------+
| | |
|<-----CoA-Request-----------|
|(e.g., DS-Lite-Tunnel-Name) |
|------CoA-Ack-------------->|
....
+-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server/|
| | | Relay)| | DAC |
+-------+ +-------+ +-------+
| | |
|<-----CoA-Request-----------|
|(e.g., DS-Lite-Tunnel-Name) |
|------CoA-Ack-------------->|
....
Figure 2: Change of Configuration
图2：配置的更改
Whenever the configuration information sent by the DHCPv6 relay agent to the DHCPv6 server changes, the DHCPv6 server has no means of detecting the change so that it can send a Reconfigure message accordingly. A solution is sketched in Section 4.
每当DHCPv6中继代理发送到DHCPv6服务器的配置信息发生更改时，DHCPv6服务器无法检测到该更改，因此无法相应地发送重新配置消息。第4节概述了解决方案。
To solve the problem described in Section 3, this document proposes a new DHCP message called Reconfigure-Request. In the example depicted in Figure 3, a Reconfigure-Request message is sent by the DHCPv6 relay agent to a DHCPv6 server as soon as the configuration data conveyed in an RSOO has changed. Upon receipt of this message, and if it is configured to support such a mode, the DHCPv6 server must build Reconfigure-Reply and Reconfigure messages. Reconfigure-Reply is used to acknowledge the receipt of Reconfigure-Request. The Reconfigure message encapsulated in Relay-Reply is sent to the DHCPv6 relay, which in turn will forward the message to the appropriate DHCPv6 client.
为了解决第3节中描述的问题，本文提出了一个新的DHCP消息，称为重新配置请求。在图3所示的示例中，一旦RSOO中传输的配置数据发生更改，DHCPv6中继代理就会向DHCPv6服务器发送重新配置请求消息。收到此消息后，如果将其配置为支持此模式，DHCPv6服务器必须生成重新配置回复和重新配置消息。重新配置回复用于确认收到重新配置请求。中继应答中封装的重新配置消息被发送到DHCPv6中继，而DHCPv6中继又将消息转发到相应的DHCPv6客户端。
This setup assumes the relay has a record of the client, so that it has enough information to send the Reconfigure-Request message to the server. How the state is recorded in the relay is out of scope of this document. For better resilience of the proposed solution, means to recover state in the event of failure (e.g., use of stable storage, DHCPv6 Bulk Leasequery [RFC5460]) need to be supported. These state recovery solutions are not discussed in this document.
此设置假定中继具有客户端的记录，因此它有足够的信息将重新配置请求消息发送到服务器。如何在继电器中记录状态超出了本文件的范围。为了提高拟议解决方案的弹性，需要支持在发生故障时恢复状态的方法（例如，使用稳定存储、DHCPv6批量租赁[RFC5460]）。本文档中不讨论这些状态恢复解决方案。
+-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server/|
| | | Relay)| | DAC |
+-------+ +-------+ +-------+
| | |
|<-----CoA-Request-----------|
|(e.g., DS-Lite-Tunnel-Name) |
| |
|------CoA-Ack-------------->|
....
| +-------+
| |DHCPv6 |
| |Server |
| | |
| +-------+
| |
|---Reconfigure-Request----->|
|<--Reconfigure-Reply--------|
| |
| |<--Relay-Reply -------------|
|<--Reconfigure-------------| (Reconfigure) |
| | |
....
+-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server/|
| | | Relay)| | DAC |
+-------+ +-------+ +-------+
| | |
|<-----CoA-Request-----------|
|(e.g., DS-Lite-Tunnel-Name) |
| |
|------CoA-Ack-------------->|
....
| +-------+
| |DHCPv6 |
| |Server |
| | |
| +-------+
| |
|---Reconfigure-Request----->|
|<--Reconfigure-Reply--------|
| |
| |<--Relay-Reply -------------|
|<--Reconfigure-------------| (Reconfigure) |
| | |
....
Figure 3: Flow Example with Reconfigure-Request
图3：带有重新配置请求的流程示例
The support of Reconfigure-Reply messages simplifies the retransmission procedure of the relay as it provides an explicit indication from the server (see Section 6.3 for more details). An alternative approach is the relay monitors' Reconfigure messages received from the server to conclude whether or not the Reconfigure-Request was successfully handled. Nevertheless, this implicit approach may fail to achieve its goals in some cases: for example, the server accepts the request but it delays generating the corresponding Reconfigure messages due to its rate-limiting policies, the request was partially failed for some clients, etc. To avoid useless reconfigure cycles (e.g., due to the loss of Reconfigure-Reply messages), the approach adopted in this document allows the relay to correct the content of a retransmitted Reconfigure-Request based on some observed events (e.g., the client has retrieved the updated configuration). If the relay has no client to be reconfigured, it stops sending Reconfigure-Request messages.
重新配置回复消息的支持简化了中继的重新传输过程，因为它提供了来自服务器的明确指示（有关更多详细信息，请参阅第6.3节）。另一种方法是中继监控器从服务器接收的重新配置消息，以确定重新配置请求是否已成功处理。然而，这种隐式方法在某些情况下可能无法实现其目标：例如，服务器接受请求，但由于其速率限制策略而延迟生成相应的重新配置消息，某些客户端的请求部分失败，等等，以避免无用的重新配置周期（例如，由于丢失了重新配置回复消息），本文档中采用的方法允许中继根据一些观察到的事件（例如，客户端检索到更新的配置）更正重新传输的重新配置请求的内容。如果中继没有要重新配置的客户端，它将停止发送重新配置请求消息。
The Reconfigure-Request message can also be used in scenarios other than those that assume the use of RSOO. It is out of scope of this document to describe all these scenarios.
重新配置请求消息也可用于假定使用RSOO的场景之外的场景。描述所有这些场景超出了本文档的范围。
Figure 4 shows the format of the Link Address Option.
图4显示了linkaddress选项的格式。
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_LINK_ADDRESS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_LINK_ADDRESS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Message Format of Link Address Option
图4：链接地址选项的消息格式
The description of the fields are as follows:
这些字段的说明如下所示：
option-code: OPTION_LINK_ADDRESS (80)
选项代码：选项链接地址（80）
option-len: 16 (octets)
选项len:16（八位字节）
link-address: An IPv6 address used by the server to identify the link on which the client is located.
链路地址：服务器用于标识客户端所在链路的IPv6地址。
The Link Address Option is used by the relay agent to indicate to the server the link on which the client is located. The relay agent MUST use a link-address value that is equivalent to the value used when relaying messages from the client to the server. Two link-address values are said to be equivalent if both values are IPv6 addresses that are on-link for the network link to which the client is connected.
中继代理使用链路地址选项向服务器指示客户端所在的链路。中继代理必须使用与将消息从客户端中继到服务器时使用的值相等的链接地址值。如果两个链路地址值都是客户端连接到的网络链路的链路上的IPv6地址，则称这两个链路地址值相等。
To defend against poor implementations that do not correctly evaluate equivalence, the relay agent SHOULD use the same value that was sent to the DHCPv6 server when relaying messages from the client to the server, as in Section 20.1.1 of [RFC3315].
为了防止未正确评估等效性的不良实现，中继代理应使用从客户端向服务器中继消息时发送到DHCPv6服务器的相同值，如[RFC3315]第20.1.1节所述。
Two new message type codes are defined:
定义了两个新的消息类型代码：
o RECONFIGURE-REQUEST (18)
o 重新配置请求（18）
o RECONFIGURE-REPLY (19)
o 重新配置-答复（19）
Reconfigure-Request and Reconfigure-Reply use the same format as defined in Section 6 of [RFC3315].
重新配置请求和重新配置回复使用[RFC3315]第6节中定义的相同格式。
Clients MUST silently discard any received Reconfigure-Request messages.
客户端必须以静默方式放弃任何接收到的重新配置请求消息。
Servers MUST discard any received Reconfigure-Request messages that meet any of the following conditions:
服务器必须丢弃任何接收到的满足以下任何条件的重新配置请求消息：
o the message does not include a Client Identifier Option [RFC3315].
o 该消息不包括客户端标识符选项[RFC3315]。
o the message does not include a Link Address Option (Section 5).
o 该消息不包括链接地址选项（第5节）。
o the message includes a Server Identifier Option [RFC3315] but the contents of the Server Identifier Option do not match the server's identifier.
o 消息包含服务器标识符选项[RFC3315]，但服务器标识符选项的内容与服务器标识符不匹配。
Clients and servers MUST silently discard any received Reconfigure-Reply messages.
客户端和服务器必须以静默方式放弃任何接收到的重新配置回复消息。
The relay MUST silently discard any received Reconfigure-Reply messages that meet any of the following conditions:
中继必须以静默方式放弃任何接收到的满足以下任何条件的重新配置回复消息：
o the "transaction-id" field in the message does not match the value used in the original message.
o 消息中的“事务id”字段与原始消息中使用的值不匹配。
o the message does not include a Server Identifier Option.
o 该消息不包括服务器标识符选项。
o the message does not include a Status Code Option [RFC3315].
o 该消息不包括状态代码选项[RFC3315]。
For any event (e.g., modification of the configuration information) that requires the server to issue a Reconfigure message, the relay agent determines the client(s) affected by the change and then builds a Reconfigure-Request message: the relay agent sets the "msg-type" field to RECONFIGURE-REQUEST, generates a transaction ID, and inserts it in the "transaction-id" field.
对于要求服务器发出重新配置消息的任何事件（例如，修改配置信息），中继代理确定受更改影响的客户端，然后构建重新配置请求消息：中继代理将“msg type”字段设置为重新配置请求，生成事务ID，并将其插入“事务id”字段中。
The relay agent MUST include one or more Client Identifier Options [RFC3315] and a Link Address Option (Section 5) so that the DHCPv6
中继代理必须包括一个或多个客户端标识符选项[RFC3315]和链接地址选项（第5节），以便DHCPv6
server can identify the corresponding client and the link on which the client is located.
服务器可以识别相应的客户端和客户端所在的链接。
The relay agent MAY include a Relay Identifier Option [RFC5460].
中继代理可以包括中继标识符选项[RFC5460]。
The relay agent MAY supply the updated configuration in the RSOO [RFC6422]. The relay agent MAY supply a Reconfigure Message Option to indicate which form of Reconfigure to use. The relay agent MAY include any option (e.g., Interface Identifier [RFC3315]) that it might insert when relaying a message received from a client.
中继代理可以在RSOO[RFC6422]中提供更新的配置。中继代理可以提供重新配置消息选项，以指示要使用哪种形式的重新配置。中继代理可以包括在中继从客户端接收的消息时可能插入的任何选项（例如，接口标识符[RFC3315]）。
When several clients on the same link are affected by a configuration change, the relay MUST include several Client Identifier Options; each of these options identifies a specific client. If including the Client Identifier Options of all impacted clients exceeds the maximum message size (see Section 7), the relay MUST generate several Reconfigure-Request messages required to carry all Client Identifier Options. Rate-limit considerations are discussed in Section 7.
当同一链路上的多个客户端受到配置更改的影响时，中继必须包括多个客户端标识符选项；每个选项都标识一个特定的客户端。如果包括所有受影响客户端的客户端标识符选项超过了最大消息大小（参见第7节），则中继必须生成多条重新配置请求消息，以承载所有客户端标识符选项。第7节讨论了费率限制的考虑因素。
The relay sets the destination address of the Reconfigure-Request message to the IP address it would have sent a Relay-Forward message (see Section 20 of [RFC3315]).
中继器将重新配置请求消息的目标地址设置为其将发送中继器转发消息的IP地址（参见[RFC3315]第20节）。
In case multiple servers are configured to the relay agent, several Reconfigure-Request messages are to be built. The behavior of the relay agent to disambiguate responses when multiple servers are configured is implementation specific. For example, an implementation may generate a distinct "transaction-id" per server while another implementation may use the content of the "transaction-id" field and the Server Identifier Option to disambiguate the responses.
如果中继代理配置了多台服务器，则需要生成多条重新配置请求消息。中继代理在配置多个服务器时消除响应歧义的行为是特定于实现的。例如，一个实现可以为每台服务器生成不同的“事务id”，而另一个实现可以使用“事务id”字段的内容和服务器标识符选项来消除响应的歧义。
The relay transmits Reconfigure-Request messages according to Section 14 of [RFC3315], using the following parameters:
根据[RFC3315]第14节，继电器使用以下参数发送重新配置请求消息：
IRT (Initial retransmission time): 1 sec MRT (Maximum retransmission time): 10 secs MRC (Maximum retransmission count): 5 MRD (Maximum retransmission duration): 0
IRT（初始重传时间）：1秒MRT（最大重传时间）：10秒MRC（最大重传计数）：5MRD（最大重传持续时间）：0
The relay MAY remove clients from the client identifier list in subsequent retransmissions, but MUST NOT add clients to the client identifier list. This decision is local to the relay (e.g., it may be based on observed events such as one or more clients were reconfigured on their own).
中继可以在随后的重传中将客户端从客户端标识符列表中移除，但不得将客户端添加到客户端标识符列表中。该决定是中继的本地决定（例如，它可能基于观察到的事件，例如一个或多个客户端自行重新配置）。
The relay may receive Reconfigure encapsulated in Relay-Reply before Reconfigure-Reply. The relay SHOULD NOT interpret it as if the
中继可以在重新配置应答之前接收封装在中继应答中的重新配置。继电器不应将其解释为
Reconfigure-Request was successfully handled by the server. The relay SHOULD use Reconfigure-Reply, not the Reconfigure message, to determine if the request was successful (see the discussion in Section 4).
服务器已成功处理重新配置请求。中继应该使用重新配置应答而不是重新配置消息来确定请求是否成功（参见第4节中的讨论）。
The relay agent MUST be configurable to accept or reject Reconfigure-Request messages received from other relay agents. If no indication is explicitly configured to the relay, the default behavior is to accept Reconfigure-Request messages.
中继代理必须可配置为接受或拒绝从其他中继代理接收的重新配置请求消息。如果没有为中继显式配置指示，则默认行为是接受重新配置请求消息。
If the relay is configured not to allow Reconfigure-Request messages, the relay MUST silently discard any Reconfigure-Request message it receives. If the relay is configured to accept Reconfigure-Request messages, these messages are relayed as specified in Section 20.1.1 of [RFC3315].
如果中继配置为不允许重新配置请求消息，则中继必须以静默方式放弃其接收的任何重新配置请求消息。如果继电器配置为接受重新配置请求消息，则按照[RFC3315]第20.1.1节的规定对这些消息进行中继。
The server MUST be configurable to accept or reject Reconfigure-Request messages. If no indication is explicitly configured to the server, the default behavior is to reject Reconfigure-Request messages.
服务器必须可配置为接受或拒绝重新配置请求消息。如果没有向服务器显式配置指示，则默认行为是拒绝重新配置请求消息。
Upon receipt of a valid Reconfigure-Request message from a DHCPv6 relay agent (see Section 6.2), the server determines the client(s) for which a Reconfigure message is to be sent.
从DHCPv6中继代理接收到有效的重新配置请求消息后（参见第6.2节），服务器确定要向其发送重新配置消息的客户端。
The server constructs a Reconfigure-Reply message by setting the "msg-type" field to RECONFIGURE-REPLY and copying the transaction ID from the Reconfigure-Request message into the "transaction-id" field. The server includes its server identifier in a Server Identifier Option. The server MUST include a Status Code Option [RFC3315] indicating whether the request has been successfully processed, failed, or partially failed.
服务器通过将“msg type”字段设置为Reconfigure-Reply并将事务ID从Reconfigure请求消息复制到“transaction ID”字段中来构造一条Reconfigure Reply消息。服务器在服务器标识符选项中包含其服务器标识符。服务器必须包含状态代码选项[RFC3315]，指示请求是否已成功处理、失败或部分失败。
o If the server fails to process the request, the server MUST set the Status Code Option to the appropriate status code (e.g., UnspecFail, NotAllowed, etc.). In particular,
o 如果服务器无法处理请求，则服务器必须将状态代码选项设置为相应的状态代码（例如，UnspecFail、NotAllowed等）。特别地，
* UnspecFail MUST be returned if the Reconfigure-Request message is malformed.
* 如果重新配置请求消息格式不正确，则必须返回UnspecFail。
* NotAllowed MUST be returned if the server is not configured to allow Reconfigure-Request.
* 如果服务器未配置为允许重新配置请求，则必须返回NotAllowed。
* NotConfigured MUST be returned if the server has no record of the link [RFC5007].
* 如果服务器没有链接记录[RFC5007]，则必须返回NotConfigured。
o If the Reconfigure-Request is successfully validated, the server MUST return a Status Code Option indicating "Success". In addition, the server MUST include a list of all the Client Identifier Options of the clients to which Reconfigure messages will not be sent (e.g., the server has no record of the client or the client did not negotiate for Reconfigure support). Note that this means that "Success" will be returned even if Reconfigure messages will not be sent to any of the clients.
o 如果成功验证重新配置请求，服务器必须返回一个状态代码选项，指示“成功”。此外，服务器必须包括不向其发送重新配置消息的客户端的所有客户端标识符选项的列表（例如，服务器没有客户端的记录，或者客户端没有协商重新配置支持）。请注意，这意味着即使不向任何客户端发送重新配置消息，也会返回“Success”。
If RSOO is supplied, the server might use its content to double check whether a Reconfigure is required to be sent to the client. This assumes the server stored the content of RSOO it used to generate the configuration data sent to requesting clients.
如果提供了RSOO，服务器可能会使用其内容来双重检查是否需要向客户端发送重新配置。这假定服务器存储了用于生成发送给请求客户端的配置数据的RSOO内容。
The server might use the content of the Reconfigure Message Option supplied by the relay agent to determine which form of Reconfigure to use.
服务器可能会使用中继代理提供的重新配置消息选项的内容来确定要使用哪种形式的重新配置。
Then, the server MUST follow the procedure defined in Section 19.1 of [RFC3315] to construct a Reconfigure message.
然后，服务器必须按照[RFC3315]第19.1节中定义的程序构造重新配置消息。
Rate-limit considerations are discussed in Section 7.
第7节讨论了费率限制的考虑因素。
Depending on the status code enclosed in a received Reconfigure-Reply message, the relay may decide to terminate the request (e.g., NotAllowed, NotConfigured, and Success) or try a different corrected Reconfigure-Request (e.g., UnspecFail).
根据接收到的重新配置回复消息中包含的状态代码，中继器可能决定终止请求（例如，不允许、未配置和成功）或尝试不同的更正的重新配置请求（例如，未声明失败）。
When multiple servers are configured, the relay should expect to receive several Reconfigure-Reply messages. As mentioned in Section 6.3, the relay should be able to disambiguate these responses and associate them with a given server. The relay agent assumes the request is successfully handled for a client if there is at least one Reconfigure-Reply message in which the corresponding Client Identifier Option does not appear.
当配置了多个服务器时，中继应该会收到多条重新配置回复消息。如第6.3节所述，中继应能够消除这些响应的歧义，并将其与给定服务器关联。如果至少有一条重新配置回复消息中没有出现相应的客户机标识符选项，则中继代理假定客户机的请求已成功处理。
The relay MUST rate-limit Reconfigure-Request messages to be sent to the server. The relay MUST be configured with required rate-limit parameters. The maximum Reconfigure-Request packet size SHOULD be configurable and the default value MUST be 1280 octets.
中继必须重新配置发送到服务器的请求消息的速率限制。继电器必须配置所需的速率限制参数。最大重新配置请求数据包大小应可配置，默认值必须为1280个八位字节。
The server MUST rate-limit Reconfigure messages triggered by Reconfigure-Request messages. The server MUST be configured with required rate-limit parameters.
服务器必须限制由重新配置请求消息触发的重新配置消息的速率。服务器必须配置所需的速率限制参数。
IANA has assigned the following new DHCPv6 Message types in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters:
IANA在中维护的注册表中分配了以下新的DHCPv6消息类型http://www.iana.org/assignments/dhcpv6-parameters:
RECONFIGURE-REQUEST
重新配置请求
RECONFIGURE-REPLY
重新配置应答
IANA has assigned the following new DHCPv6 Option Codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters:
IANA在中维护的注册表中分配了以下新的DHCPv6选项代码：http://www.iana.org/assignments/dhcpv6-parameters:
OPTION_LINK_ADDRESS
选项链接地址
Security considerations elaborated in [RFC3315] (in particular Section 21.1) and [RFC6422] must be taken into account. In addition, DHCPv6 servers MAY be configured to reject relayed Reconfigure-Request messages or restrict relay chaining (see [RFC5007] for more discussion about the rationale of this recommended behavior). Section 6.5 specifies the error code to return when the server is configured to reject Reconfigure-Request messages.
必须考虑[RFC3315]（特别是第21.1节）和[RFC6422]中阐述的安全注意事项。此外，DHCPv6服务器可配置为拒绝中继的重新配置请求消息或限制中继链接（有关此建议行为的基本原理的更多讨论，请参阅[RFC5007]）。第6.5节指定了服务器配置为拒绝重新配置请求消息时返回的错误代码。
Relay agents SHOULD implement appropriate means to prevent using Reconfigure-Request messages as a denial-of-service attack on the DHCPv6 servers.
中继代理应实施适当的方法，以防止在DHCPv6服务器上使用重新配置请求消息作为拒绝服务攻击。
Because the Reconfigure-Request message provides a mechanism for triggering the DHCPv6 Reconfigure message, and the DHCPv6 Reconfigure message can raise security threats (e.g., to control the timing of a DHCPv6 renewal), the DHCPv6 server MUST have some mechanism for determining that the relay agent is a trusted entity. DHCPv6 servers and relay agents MUST implement relay message authentication as described in Section 21.1 of [RFC3315]. DHCPv6 servers MAY also implement a control policy based on the content of a received Relay Identifier Option [RFC5460]. Administrators are strongly advised to configure one of these security mechanisms.
由于重新配置请求消息提供了一种触发DHCPv6重新配置消息的机制，并且DHCPv6重新配置消息可能引发安全威胁（例如，为了控制DHCPv6续订的时间），因此DHCPv6服务器必须具有某种机制来确定中继代理是受信任的实体。DHCPv6服务器和中继代理必须按照[RFC3315]第21.1节所述实施中继消息身份验证。DHCPv6服务器还可以基于接收到的中继标识符选项[RFC5460]的内容实施控制策略。强烈建议管理员配置这些安全机制之一。
In an environment where the network connecting the relay agent to the DHCPv6 server is physically secure and does not contain devices not controlled by the server administrator, it may be sufficient to trust
在将中继代理连接到DHCPv6服务器的网络物理上是安全的，并且不包含不受服务器管理员控制的设备的环境中，信任可能就足够了
the Relay Agent Identifier provided by the relay agent. In networks where the security of the machines with access to the data path is not under the control of the server administrator, IPsec [RFC4301] is necessary to prevent spoofing of Reconfigure-Request messages. DHCPv6 servers MUST silently discard Reconfigure-Request messages originating from unknown relay agents.
中继代理提供的中继代理标识符。在可访问数据路径的计算机的安全性不受服务器管理员控制的网络中，IPsec[RFC4301]对于防止对重新配置请求消息的欺骗是必要的。DHCPv6服务器必须以静默方式放弃源自未知中继代理的重新配置请求消息。
Many thanks to R. Maglione, A. Kostur, G. Halwasia, C. Jacquenet, B. Leiba, R. Sparks, A. Farrel, B. Claise, J. Jaeggli, and P. Resnick for the comments and review.
非常感谢R.Maglione、A.Kostur、G.Halwasia、C.Jacquenet、B.Leiba、R.Sparks、A.Farrel、B.Claise、J.Jaeggli和P.Resnick的评论和评论。
Special thanks to T. Lemon, B. Volz, and T. Mrugalski who provided a detailed review.
特别感谢T.Lemon、B.Volz和T.Mrugalski提供了详细的回顾。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 6422, December 2011.
[RFC6422]Lemon，T.和Q.Wu，“继电器提供的DHCP选项”，RFC 6422，2011年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5007]Brzowski，J.，Kinnear，K.，Volz，B.，和S.Zeng，“DHCPv6租赁”，RFC 5007，2007年9月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5176]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 51762008年1月。
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 2009.
[RFC5460]Stapp，M.，“DHCPv6散装租赁”，RFC 54602009年2月。
Authors' Addresses
作者地址
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
EMail: mohamed.boucadair@orange.com
EMail: mohamed.boucadair@orange.com
Xavier Pougnard France Telecom Lannion France
Xavier Pougnard法国电信公司
EMail: xavier.pougnard@orange.com
EMail: xavier.pougnard@orange.com