[要約] RFC 6977は、リレーエージェントからDHCPv6再構成をトリガーするための仕様です。その目的は、ネットワークの再構成を効率的に行い、ユーザーの接続を維持することです。
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.
このドキュメントでは、2つの新しいDHCPv6メッセージ、Reconfigure-RequestとReconfigure-Replyを定義しています。再構成要求メッセージはDHCPv6リレーエージェントによって送信され、DHCPv6サーバーに構成情報の変更を通知するため、DHCPv6サーバーはそれに応じて再構成メッセージを送信できます。サーバーは、Reconfigure-Replyメッセージを使用して、Reconfigure-Requestメッセージの受信を確認します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
This document specifies two new DHCPv6 messages [RFC3315]: Reconfigure-Request and Reconfigure-Reply.
このドキュメントは、2つの新しいDHCPv6メッセージ[RFC3315]を指定します：Reconfigure-RequestおよびReconfigure-Reply。
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では、Reconfigure-RequestおよびReconfigure-Replyメッセージの使用に依存する提案されたソリューションについて説明します。再構成要求メッセージはDHCPv6リレーエージェントによって送信され、DHCPv6サーバーに構成情報の変更を通知するため、DHCPv6サーバーはそれに応じて再構成メッセージを送信できます。サーバーは、Reconfigure-Replyメッセージを使用して、Reconfigure-Requestの受信を確認します。
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リレーエージェントによってReconfigureメッセージをトリガーする手順の詳細を説明します。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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サーバーにそのような情報を提供できるメカニズムを指定します。 DHCPクライアント。これは、構成データをDHCPv6サーバーに伝送するRSOO（リレー提供オプションオプション）を使用して実現されます。 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.
RSOOの使用例を図1に示します。交換された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) |
....
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.
構成を変更すると、図2に示すように、NAS / DHCPv6リレーエージェントと動的認証クライアント（DAC）サーバー間でCoA（Change-of-Authorization）[RFC5176]メッセージが交換される可能性があります。この例では、NASは次のように応答します。 CoA-Requestが正常に処理されたことをDACに通知するCoA-Ackメッセージ。
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-------------->|
....
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で説明した問題を解決するために、このドキュメントではReconfigure-Requestと呼ばれる新しいDHCPメッセージを提案します。図3に示す例では、RSOOで伝達される構成データが変更されるとすぐに、DHCPv6リレーエージェントによってDHCPv6サーバーにReconfigure-Requestメッセージが送信されます。このメッセージを受信すると、そのようなモードをサポートするように構成されている場合、DHCPv6サーバーはReconfigure-ReplyおよびReconfigureメッセージを作成する必要があります。 Reconfigure-Replyは、Reconfigure-Requestの受信を確認するために使用されます。リレー応答にカプセル化された再構成メッセージは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.
この設定では、リレーにクライアントのレコードがあるため、Reconfigure-Requestメッセージをサーバーに送信するのに十分な情報があると想定しています。状態がリレーに記録される方法は、このドキュメントの範囲外です。提案されたソリューションの回復力を高めるには、障害発生時に状態を回復する手段（安定したストレージの使用、DHCPv6 Bulk Leasequery [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) |
| | |
....
Figure 3: Flow Example with Reconfigure-Request
図3：Reconfigure-Requestを使用したフローの例
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.
Reconfigure-Replyメッセージのサポートは、サーバーからの明示的な指示を提供するため、リレーの再送信手順を簡素化します（詳細については、セクション6.3を参照）。別のアプローチは、Reconfigure-Requestが正常に処理されたかどうかを結論付けるために、サーバーから受信したリレーモニターのReconfigureメッセージです。それでも、この暗黙のアプローチでは、場合によっては目標を達成できないことがあります。たとえば、サーバーはリクエストを受け入れますが、レート制限ポリシーのために対応するReconfigureメッセージの生成が遅れたり、一部のクライアントではリクエストが部分的に失敗したりします。無駄な再構成サイクル（たとえば、Reconfigure-Replyメッセージの損失による）を回避するために、このドキュメントで採用されているアプローチにより、リレーは、いくつかの観察されたイベント（たとえば、クライアントが取得したイベント）に基づいて再送信されたReconfigure-Requestの内容を修正できます。更新された構成）。リレーに再構成するクライアントがない場合、リレーはReconfigure-Requestメッセージの送信を停止します。
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.
Reconfigure-Requestメッセージは、RSOOの使用を想定しているシナリオ以外のシナリオでも使用できます。これらすべてのシナリオを説明することは、このドキュメントの範囲外です。
Figure 4 shows the format of the Link Address Option.
図4は、リンクアドレスオプションのフォーマットを示しています。
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)
オプションコード：OPTION_LINK_ADDRESS（80）
option-len: 16 (octets)
オプション：16（オクテット）
link-address: An IPv6 address used by the server to identify the link on which the client is located.
link-address：サーバーがクライアントのリンクを識別するために使用する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アドレスが両方の値である場合、2つのリンクアドレス値は同等であると言います。
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].
[RFC3315]のセクション20.1.1のように、同等性を正しく評価しない不適切な実装を防ぐために、リレーエージェントは、クライアントからサーバーにメッセージをリレーするときにDHCPv6サーバーに送信されたものと同じ値を使用する必要があります。
Two new message type codes are defined:
2つの新しいメッセージタイプコードが定義されています。
o RECONFIGURE-REQUEST (18)
o 再構成要求（18）
o RECONFIGURE-REPLY (19) Reconfigure-Request and Reconfigure-Reply use the same format as defined in Section 6 of [RFC3315].
o RECONFIGURE-REPLY（19）Reconfigure-RequestおよびReconfigure-Replyは、[RFC3315]のセクション6で定義されているものと同じ形式を使用します。
Clients MUST silently discard any received Reconfigure-Request messages.
クライアントは受信したReconfigure-Requestメッセージをサイレントに破棄する必要があります。
Servers MUST discard any received Reconfigure-Request messages that meet any of the following conditions:
サーバーは、次のいずれかの条件を満たす受信したReconfigure-Requestメッセージを破棄する必要があります。
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.
クライアントとサーバーは、受信したReconfigure-Replyメッセージをサイレントに破棄する必要があります。
The relay MUST silently discard any received Reconfigure-Reply messages that meet any of the following conditions:
リレーは、次のいずれかの条件を満たす受信したReconfigure-Replyメッセージをサイレントに破棄する必要があります。
o the "transaction-id" field in the message does not match the value used in the original message.
o メッセージの「transaction-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.
サーバーがReconfigureメッセージの発行を必要とするイベント（構成情報の変更など）の場合、リレーエージェントは変更の影響を受けるクライアントを特定し、Reconfigure-Requestメッセージを作成します。リレーエージェントは「 msg-type "フィールドをRECONFIGURE-REQUESTに追加し、トランザクションIDを生成して、それを" transaction-id "フィールドに挿入します。
The relay agent MUST include one or more Client Identifier Options [RFC3315] and a Link Address Option (Section 5) so that the DHCPv6
リレーエージェントは、1つ以上のクライアント識別子オプション[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]で更新された構成を提供する場合があります。リレーエージェントは、使用する再構成の形式を示す再構成メッセージオプションを提供する場合があります。リレーエージェントは、クライアントから受信したメッセージをリレーするときに挿入するオプション（たとえば、Interface Identifier [RFC3315]）を含めることができます（MAY）。
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を参照）を超える場合、リレーは、すべてのクライアント識別子オプションを運ぶために必要ないくつかのReconfigure-Requestメッセージを生成する必要があります。レート制限の考慮事項については、セクション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]).
リレーは、Reconfigure-Requestメッセージの宛先アドレスを、Relay-Forwardメッセージを送信したはずの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.
リレーエージェントに対して複数のサーバーが構成されている場合、複数のReconfigure-Requestメッセージが作成されます。複数のサーバーが構成されている場合の応答を明確にするためのリレーエージェントの動作は、実装によって異なります。たとえば、ある実装ではサーバーごとに異なる「transaction-id」を生成し、別の実装では「transaction-id」フィールドのコンテンツとサーバー識別子オプションを使用して、応答を明確化します。
The relay transmits Reconfigure-Request messages according to Section 14 of [RFC3315], using the following parameters:
リレーは、[RFC3315]のセクション14に従って、次のパラメータを使用してReconfigure-Requestメッセージを送信します。
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（最大再送回数）：5 MRD（最大再送時間）：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).
リレーは、後続の再送信でクライアント識別子リストからクライアントを削除してもよい（MAY）が、クライアントをクライアント識別子リストに追加してはならない（MUST NOT）。この決定は、リレーに対してローカルです（たとえば、1つ以上のクライアントが独自に再構成されたなどの観測されたイベントに基づく場合があります）。
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).
リレーは、Reconfigure-Replyの前に、Relay-Replyにカプセル化されたReconfigureを受信する場合があります。リレーは、Reconfigure-Requestがサーバーによって正常に処理されたかのように解釈すべきではありません（SHOULD NOT）。リレーは、リクエストが成功したかどうかを判断するために、ReconfigureメッセージではなくReconfigure-Replyを使用する必要があります（セクション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.
リレーエージェントは、他のリレーエージェントから受信したReconfigure-Requestメッセージを受け入れるか拒否するように構成可能である必要があります。リレーに対して明示的に構成された指示がない場合、デフォルトの動作はReconfigure-Requestメッセージを受け入れることです。
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].
リレーがReconfigure-Requestメッセージを許可しないように構成されている場合、リレーは受信したすべてのReconfigure-Requestメッセージを警告なしに破棄する必要があります。リレーがReconfigure-Requestメッセージを受け入れるように構成されている場合、これらのメッセージは[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.
サーバーは、Reconfigure-Requestメッセージを受け入れるか拒否するように構成可能である必要があります。サーバーに対して明示的に構成された指示がない場合、デフォルトの動作はReconfigure-Requestメッセージを拒否することです。
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リレーエージェントから有効なReconfigure-Requestメッセージを受信すると（セクション6.2を参照）、サーバーはReconfigureメッセージを送信するクライアントを決定します。
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-Requestメッセージから「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.
* Reconfigure-Requestメッセージの形式が正しくない場合は、UnspecFailを返す必要があります。
* NotAllowed MUST be returned if the server is not configured to allow Reconfigure-Request.
* サーバーがReconfigure-Requestを許可するように構成されていない場合は、NotAllowedを返す必要があります。
* NotConfigured MUST be returned if the server has no record of the link [RFC5007].
* サーバーにリンクのレコードがない場合は、NotConfiguredを返す必要があります[RFC5007]。
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 Reconfigure-Requestが正常に検証された場合、サーバーは「成功」を示すステータスコードオプションを返さなければなりません（MUST）。さらに、サーバーには、再構成メッセージが送信されないクライアントのすべてのクライアント識別子オプションのリストを含める必要があります（たとえば、サーバーにクライアントのレコードがないか、クライアントが再構成サポートについて交渉していません）。これは、再構成メッセージがどのクライアントにも送信されない場合でも、「成功」が返されることを意味することに注意してください。
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.
サーバーは、リレーエージェントによって提供されるReconfigure Message Optionのコンテンツを使用して、使用するReconfigureの形式を決定する場合があります。
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).
受信したReconfigure-Replyメッセージに含まれるステータスコードに応じて、リレーはリクエストを終了するか（NotAllowed、NotConfigured、Successなど）、別の修正されたReconfigure-Requestを試行するか（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.
複数のサーバーが構成されている場合、リレーは複数のReconfigure-Replyメッセージを受信することを期待する必要があります。セクション6.3で述べたように、リレーはこれらの応答を明確にし、特定のサーバーに関連付けることができる必要があります。リレーエージェントは、対応するクライアント識別子オプションが表示されないReconfigure-Replyメッセージが少なくとも1つある場合、クライアントの要求が正常に処理されたと見なします。
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.
リレーは、サーバーに送信されるReconfigure-Requestメッセージをレート制限する必要があります。リレーは、必須のレート制限パラメーターで構成する必要があります。 Reconfigure-Requestパケットの最大サイズは構成可能である必要があり、デフォルト値は1280オクテットでなければなりません。
The server MUST rate-limit Reconfigure messages triggered by Reconfigure-Request messages. The server MUST be configured with required rate-limit parameters.
サーバーは、Reconfigure-RequestメッセージによってトリガーされたReconfigureメッセージをレート制限する必要があります。サーバーは、必須のレート制限パラメーターで構成する必要があります。
IANA has assigned the following new DHCPv6 Message types in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters:
IANAは、http：//www.iana.org/assignments/dhcpv6-parametersで管理されているレジストリで、次の新しいDHCPv6メッセージタイプを割り当てました。
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は、http：//www.iana.org/assignments/dhcpv6-parametersで管理されているレジストリに、次の新しいDHCPv6オプションコードを割り当てました。
OPTION_LINK_ADDRESS
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サーバーは、リレーされたReconfigure-Requestメッセージを拒否するか、リレーチェーンを制限するように構成できます（この推奨される動作の根拠についての詳細は、[RFC5007]を参照してください）。セクション6.5では、サーバーがReconfigure-Requestメッセージを拒否するように構成されている場合に返されるエラーコードを指定しています。
Relay agents SHOULD implement appropriate means to prevent using Reconfigure-Request messages as a denial-of-service attack on the DHCPv6 servers.
リレーエージェントは、DHCPv6サーバーでのサービス拒否攻撃としてReconfigure-Requestメッセージを使用しないようにする適切な手段を実装する必要があります（SHOULD）。
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.
Reconfigure-RequestメッセージはDHCPv6 Reconfigureメッセージをトリガーするためのメカニズムを提供し、DHCPv6 Reconfigureメッセージはセキュリティ上の脅威を引き起こす可能性があるため（たとえば、DHCPv6更新のタイミングを制御するため）、DHCPv6サーバーはリレーを決定するための何らかのメカニズムを備えている必要がありますエージェントは信頼できるエンティティです。 DHCPv6サーバーとリレーエージェントは、[RFC3315]のセクション21.1で説明されているように、リレーメッセージ認証を実装する必要があります。 DHCPv6サーバーは、受信したリレー識別子オプション[RFC5460]の内容に基づいて制御ポリシーを実装することもできます（MAY）。管理者は、これらのセキュリティメカニズムの1つを構成することを強くお勧めします。
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 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.
リレーエージェントをDHCPv6サーバーに接続するネットワークが物理的に安全で、サーバー管理者によって制御されないデバイスが含まれていない環境では、リレーエージェントによって提供されるリレーエージェント識別子を信頼するだけで十分な場合があります。データパスにアクセスできるマシンのセキュリティがサーバー管理者の管理下にないネットワークでは、再構成要求メッセージのなりすましを防ぐためにIPsec [RFC4301]が必要です。 DHCPv6サーバーは、不明なリレーエージェントから送信されたReconfigure-Requestメッセージをサイレントに破棄する必要があります。
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.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 6422, December 2011.
[RFC6422] Lemon、T。およびQ. Wu、「Relay-Supplied DHCP Options」、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 4301、2005年12月。
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5007] Brzozowski、J.、Kinnear、K.、Volz、B。、およびS. Zeng、「DHCPv6 Leasequery」、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.、and B. Aboba、 "Dynamic Authorization Extensions to Remote Authentication Dial In User Service（RADIUS）"、RFC 5176、January 2008。
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 2009.
[RFC5460] Stapp、M。、「DHCPv6 Bulk Leasequery」、RFC 5460、2009年2月。
Authors' Addresses
著者のアドレス
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
EMail: mohamed.boucadair@orange.com
Xavier Pougnard France Telecom Lannion France
Xavier Pougnard France Telecom Lannion France
EMail: xavier.pougnard@orange.com