Network Working Group M. Stapp
Request for Comments: 5460 Cisco Systems, Inc.
Category: Standards Track February 2009
DHCPv6 Bulk Leasequery
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP.
IPv6の動的ホスト構成プロトコル（DHCPv6の）は、クライアントがDHCPv6のバインディングに関する情報を要求することを可能にするLEASEQUERY機能で拡張されました。そのメカニズムは、個々のバインディングのためのクエリに限定されています。いくつかの状況では、個々の結合クエリは、効率的な、あるいはできないことがあります。この文書は、新しいクエリの種類を追加し、TCP経由のDHCPv6バインディングデータのバルク転送を可能に、LEASEQUERYプロトコルを拡張したものです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Interaction between UDP Leasequery and Bulk Leasequery . . . . 5
5. Message and Option Definitions . . . . . . . . . . . . . . . . 6
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 6
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2.1. LEASEQUERY-DATA . . . . . . . . . . . . . . . . . . . 7
5.2.2. LEASEQUERY-DONE . . . . . . . . . . . . . . . . . . . 7
5.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 7
5.3.1. QUERY_BY_RELAY_ID . . . . . . . . . . . . . . . . . . 7
5.3.2. QUERY_BY_LINK_ADDRESS . . . . . . . . . . . . . . . . 8
5.3.3. QUERY_BY_REMOTE_ID . . . . . . . . . . . . . . . . . . 8
5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4.1. Relay-ID Option . . . . . . . . . . . . . . . . . . . 8
5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 9
5.6. Connection and Transmission Parameters . . . . . . . . . . 9
6. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Connecting . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Forming Queries . . . . . . . . . . . . . . . . . . . . . 10
6.3. Processing Replies . . . . . . . . . . . . . . . . . . . . 10
6.3.1. Reply Completion . . . . . . . . . . . . . . . . . . . 11
6.4. Querying Multiple Servers . . . . . . . . . . . . . . . . 11
6.5. Multiple Queries to a Single Server . . . . . . . . . . . 12
6.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 12
6.6. Closing Connections . . . . . . . . . . . . . . . . . . . 13
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Accepting Connections . . . . . . . . . . . . . . . . . . 13
7.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 14
7.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 15
7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
The DHCPv6 [RFC3315] protocol specifies a mechanism for the assignment of IPv6 address and configuration information to IPv6 nodes. IPv6 Prefix Delegation (PD) for DHCPv6 [RFC3633] specifies a mechanism for DHCPv6 delegation of IPv6 prefixes and related data. DHCPv6 servers maintain authoritative information including binding information for delegated IPv6 prefixes.
DHCPv6の[RFC3315]プロトコルは、IPv6ノードにIPv6アドレスと構成情報の割り当てのための機構を指定します。 DHCPv6のためのIPv6プレフィックス委任（PD）[RFC3633]はIPv6プレフィックスと関連するデータのDHCPv6の委任のための機構を指定します。 DHCPv6サーバは、委任IPv6プレフィックスの結合情報を含む正式な情報を維持します。
The client of a PD binding is typically a router, which then advertises the delegated prefix to locally-connected hosts. The delegated IPv6 prefix must be routeable in order to be useful. The actual DHCPv6 PD client may not be permitted to inject routes into the delegating network. In service-provider (SP) networks, for example, an edge router typically acts as a DHCPv6 relay agent, and this edge router often has the responsibility to maintain routes within the service-provider network for clients' PD bindings.
結合PDのクライアントは、典型的には、その後、ローカルに接続されたホストに委譲されたプレフィックスを広告するルータです。委任のIPv6プレフィックスが有用であるためでルーティング可能でなければなりません。実際のDHCPv6 PDクライアントは委譲ネットワークにルートを注入することを許可されなくてもよいです。サービスプロバイダ（SP）ネットワークでは、例えば、エッジルータは、典型的には、DHCPv6のリレーエージェントとして機能し、このエッジルータは、多くの場合、顧客のPDバインディングのサービスプロバイダーネットワーク内のルートを維持する責任を有しています。
A DHCPv6 relay with this responsibility requires a means to recover binding information from the authoritative DHCPv6 server(s) in the event of replacement or reboot, in order to restore routeability to delegated prefixes. The relay may be a network device without adequate local storage to maintain the necessary binding-to-route data. A DHCPv6 Leasequery protocol [RFC5007] has been developed that allows queries for individual bindings from the authoritative DHCPv6 server(s). The individual query mechanism is only useable when the target binding is known to the requestor, such as upon receipt of traffic. In the case of DHCPv6 Prefix Delegation, the PD binding data may need to be known before any traffic arrives from the client router. The DHCPv6 relay router may not be able to form individual queries in such cases.
この責任を持つのDHCPv6リレーは、委任プレフィックスにルート機能を回復するためには、交換または再起動の際に権威のDHCPv6サーバ（群）からバインディング情報を回復するための手段を必要とします。リレーは、必要な結合対ルートデータを維持するために十分なローカルストレージなしでネットワークデバイスであってもよいです。 DHCPv6のLEASEQUERYプロトコル[RFC5007]は権威DHCPv6サーバ（複数可）から個々のバインディングに対するクエリを可能にするように開発されてきました。結合標的がそのようなトラフィックを受信するように、要求者に知られている場合、個々のクエリ機構のみ使用可能です。 DHCPv6のプレフィックス委任の場合は、PD結合データは、すべてのトラフィックは、クライアントルータから到着する前に知る必要があります。 DHCPv6の中継ルータは、このような場合には個々のクエリを形成することができないかもしれません。
This document extends the DHCPv6 Leasequery protocol to add support for queries that address these requirements. At the SP edge there may be many thousands of delegated prefixes per relay, so we specify the use of TCP [RFC4614] for efficiency of data transfer. We specify a new DHCPv6 option, the Relay Identifier option, to support efficient recovery of all data associated with a specific relay agent; we also add a query-type for this purpose. We add query-types by network segment and by Remote-ID option value, to assist a relay that needs to recover a subset of its clients' bindings.
この文書では、これらの要件に対処するクエリのサポートを追加するためのDHCPv6 LEASEQUERYプロトコルを拡張します。 SPエッジで中継あたり委任プレフィックスの数千があるかもしれないので、我々は、データ転送の効率のためにTCP [RFC4614]を使用することを指定します。私たちは、特定のリレーエージェントに関連するすべてのデータの効率的な回収をサポートするために、新しいDHCPv6のオプション、リレー識別子オプションを指定します。我々はまた、この目的のために、クエリタイプを追加します。我々は、顧客のバインディングのサブセットを回復する必要がリレーを支援するために、ネットワークセグメントによっておよびリモートIDのオプション値によってクエリの種類を追加します。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
DHCPv6 terminology is defined in [RFC3315]. DHCPv6 Leasequery terminology is defined in [RFC5007].
DHCPv6の用語は、[RFC3315]で定義されています。 DHCPv6のLEASEQUERY用語は[RFC5007]で定義されています。
The Bulk Leasequery mechanism is modeled on the existing individual Leasequery protocol in [RFC5007]; most differences arise from the use of TCP. A Bulk Leasequery client opens a TCP connection to a DHCPv6 server, using the DHCPv6 port 547. Note that this implies that the Leasequery client has server IP address(es) available via configuration or some other means, and that it has unicast IP reachability to the server. No relaying for bulk leasequery is specified.
バルクLEASEQUERY機構は、[RFC5007]の既存の個々LEASEQUERYプロトコルにモデル化されます。ほとんど違いはTCPの使用から生じます。バルクLEASEQUERYクライアントは、これはLEASEQUERYクライアントは、設定またはいくつかの他の手段を介して利用可能なサーバーのIPアドレスを持っていることを意味し、それがユニキャストIP到達可能性を有していることをDHCPv6のポート547（注）を使用して、DHCPv6サーバへのTCP接続をオープンしますサーバー。バルクLEASEQUERYのための中継が指定されていません。
After establishing a connection, the client sends a LEASEQUERY message containing a query-type and data about bindings it is interested in. The server uses the query-type and the data to identify any relevant bindings. In order to support some query-types, servers may have to maintain additional data structures or be able to locate bindings based on specific option data. The server replies with a LEASEQUERY-REPLY message, indicating the success or failure of the query. If the query was successful, the server includes the first client's binding data in the LEASEQUERY-REPLY message also. If more than one client's bindings are being returned, the server then transmits the additional client bindings in a series of LEASEQUERY-DATA messages. If the server has sent at least one client's bindings, it sends a LEASEQUERY-DONE message when it has finished sending its replies. The client may reuse the connection to send additional queries. Each end of the TCP connection can be closed after all data has been sent.
接続を確立した後、クライアントは、それが興味を持っているバインディングに関する問い合わせタイプとデータを含むLEASEQUERYメッセージを送信します。サーバは、関連するすべてのバインディングを識別するために、クエリタイプとデータを使用しています。いくつかのクエリの種類をサポートするために、サーバーは、追加のデータ構造を維持するか、特定のオプションデータに基づいてバインディングを見つけることができるようにする必要があります。サーバーは、クエリの成功または失敗を示す、LEASEQUERY-REPLYメッセージで応答します。クエリが成功した場合、サーバーは、LEASEQUERY-REPLYメッセージの最初のクライアントのデータバインディングを含んでいます。複数のクライアントのバインディングが返されている場合は、サーバーは、LEASEQUERY-DATAの一連のメッセージに追加のクライアントバインディングを送信します。サーバーが少なくとも1つのクライアントのバインディングを送信した場合、その応答を送信し終えたとき、それはLEASEQUERY-DONEメッセージを送信します。クライアントは、追加のクエリを送信するために、接続を再利用することができます。すべてのデータが送信された後、TCP接続の各端部を閉じることができます。
This specification includes a new DHCPv6 option, the Relay-ID option. The option contains a DUID (DHCP Unique Identifier) identifying a DHCPv6 relay agent. Relay agents can include this option in Relay-Forward messages they send. Servers can retain the Relay-ID and associate it with bindings made on behalf of the relay's clients. A relay can then recover binding information about downstream clients by using the Relay-ID in a LEASEQUERY message. The Relay-ID option is defined in Section 5.4.1.
この仕様は新しいDHCPv6のオプション、リレー-IDオプションが含まれています。オプションはDUID（DHCP一意識別子）のDHCPv6リレーエージェントを識別が含まれています。リレーエージェントは、彼らが送るリレーフォワードメッセージでこのオプションを含めることができます。サーバーは、リレー-IDを保持し、リレーのクライアントのために作られたバインディングに関連付けることができます。リレーは、次にLEASEQUERYメッセージにリレー-IDを使用してダウンストリームクライアントに関するバインディング情報を回復することができます。リレー-IDオプションは、セクション5.4.1で定義されています。
Bulk Leasequery supports the queries by IPv6 address and by Client DUID as specified in [RFC5007]. The Bulk Leasequery protocol also adds several new queries. The new queries introduced here cannot be used effectively with the UDP Leasequery protocol. Requestors MUST NOT send these new query-types in [RFC5007] query messages.
バルクLEASEQUERYは、[RFC5007]で指定されたIPv6アドレスでとクライアントDUIDでクエリをサポートしています。バルクLEASEQUERYプロトコルはまた、いくつかの新しいクエリを追加します。ここで導入された新しいクエリはUDP LEASEQUERYプロトコルと効果的に使用することはできません。リクエスタは、[RFC5007]クエリーメッセージにこれらの新しいクエリのタイプを送ってはいけません。
Query by Relay Identifier - This query asks a server for the bindings associated with a specific relay; the relay is identified by a DUID carried in a Relay-ID option.
リレー識別子によってクエリ - このクエリは、特定のリレーに関連付けられているバインディングのためにサーバに要求します。リレーはリレー-IDオプションで運ばDUIDによって識別されます。
Query by Link Address - This query asks a server for the bindings on a particular network segment; the link is specified in the query's link-address field.
リンクアドレスによる問合せ - このクエリは、特定のネットワークセグメント上のバインディング用のサーバーを要求します。リンクは、クエリのリンクアドレスフィールドに指定されています。
Query by Remote ID - This query asks a server for the bindings associated with a Relay Agent Remote-ID option [RFC4649] value.
リモートIDによる問合せ - このクエリは、リレーエージェントリモートIDオプション[RFC4649]の値に関連付けられたバインディングのサーバーを要求します。
Bulk Leasequery can be seen as an extension of the existing UDP Leasequery protocol [RFC5007]. This section tries to clarify the relationship between the two protocols.
バルクLEASEQUERYは、既存のUDP LEASEQUERYプロトコル[RFC5007]の拡張とみなすことができます。このセクションでは、2つのプロトコル間の関係を明確にしようとします。
The query-types introduced in the UDP Leasequery protocol can be used in the Bulk Leasequery protocol. One change in behavior is introduced when Bulk Leasequery is used. [RFC5007], in sections 4.1.2.5 and 4.3.3, specifies the use of a Client Link option in LEASEQUERY-REPLY messages in cases where multiple bindings were found. When Bulk Leasequery is used, this mechanism is not necessary: a server returning multiple bindings simply does so directly as specified in this document. The Client Link option MUST NOT appear in Bulk Leasequery replies.
UDP LEASEQUERYプロトコルで導入されたクエリのタイプはバルクLEASEQUERYプロトコルで使用することができます。バルクLEASEQUERYを使用した場合の動作の1つの変更が導入されます。 [RFC5007]は、セクション4.1.2.5および4.3.3で、複数のバインディングが発見された場合にLEASEQUERY-REPLYメッセージでクライアント・リンクオプションを使用することを指定します。バルクLEASEQUERYを使用する場合は、このメカニズムは必要ありません：複数のバインディングを返すサーバは、単にので、直接、この文書で指定されません。クライアント・リンクオプションは、バルクLEASEQUERY返信に現れてはいけません。
Only LEASEQUERY, LEASEQUERY-REPLY, LEASEQUERY-DATA, and LEASEQUERY-DONE messages are allowed over the Bulk Leasequery connection. No other DHCPv6 messages are supported. The Bulk Leasequery connection is not an alternative DHCPv6 communication option for clients seeking DHCPv6 service.
LEASEQUERY、LEASEQUERY-REPLY、LEASEQUERY-DATA、およびLEASEQUERY-DONEメッセージは、バルクLEASEQUERY接続を介して許可されているのみ。他のDHCPv6のメッセージがサポートされていません。バルクLEASEQUERY接続はDHCPv6サービスを求めているクライアントのための代替のDHCPv6通信オプションではありません。
The new queries introduced in this specification cannot be used with the UDP Leasequery protocol. Servers that implement this specification and also permit UDP queries MUST NOT accept Bulk Leasequery query-types in UDP Leasequery messages. Such servers MUST respond with an error status code of NotAllowed [RFC5007].
この仕様で導入された新しいクエリはUDP LEASEQUERYプロトコルで使用することはできません。この仕様を実装し、また、UDPクエリを許可するサーバはUDP LEASEQUERYメッセージで一括LEASEQUERYクエリ・タイプを受け入れてはいけません。このようなサーバは、のnotAllowed [RFC5007]のエラーステータスコードで応じなければなりません。
Implementors should note that the TCP message framing defined in Section 5.1 is not compatible with the UDP message format. If a TCP-framed request is sent as a UDP message, it may not be valid, because protocol fields will be offset by the message-size prefix.
実装者は、セクション5.1で定義されたTCPメッセージフレーミングがUDPメッセージのフォーマットと互換性がないことに注意してください。 TCP枠の要求がUDPメッセージとして送信されている場合は、プロトコルフィールドがメッセージサイズの接頭辞によって相殺されるので、それは、有効でない場合があります。
The use of TCP for the Bulk Leasequery protocol permits one or more DHCPv6 messages to be sent at a time. The receiver needs to be able to determine how large each message is. Two octets containing the message size in network byte order are prepended to each DHCPv6 message sent on a Bulk Leasequery TCP connection. The two message-size octets 'frame' each DHCPv6 message.
バルクLEASEQUERYプロトコルのTCPの使用は、一度に送信される1つの以上のDHCPv6メッセージを許可します。受信機は、各メッセージがどれくらい大きいかを決定することができる必要があります。ネットワークバイト順序でメッセージサイズを含む2つのオクテットは、バルクLEASEQUERY TCPコネクション上で送信される各のDHCPv6メッセージの前に付加されています。 2つのメッセージサイズのオクテット「フレーム」は、各々のDHCPv6メッセージ。
DHCPv6 message framed for TCP:
TCPのためのフレームのDHCPv6メッセージ：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message-size | msg-type | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: transaction-id | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| .
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
message-size the number of octets in the message that follows, as a 16-bit integer in network byte order.
メッセージサイズネットワークバイト順に16ビットの整数として、次のメッセージのオクテットの数。
All other fields are as specified in DHCPv6 [RFC3315].
DHCPv6の[RFC3315]で指定されている他のすべてのフィールドがあります。
The LEASEQUERY and LEASEQUERY-REPLY messages are defined in [RFC5007]. In a Bulk Leasequery exchange, a single LEASEQUERY-REPLY message is used to indicate the success or failure of a query, and to carry data that do not change in the context of a single query and answer, such as the Server-ID and Client-ID options. If a query is successful, only a single LEASEQUERY-REPLY message MUST appear. If the server is returning binding data, the LEASEQUERY-REPLY also contains the first client's binding data in an OPTION_CLIENT_DATA option.
LEASEQUERYとLEASEQUERY-REPLYメッセージは、[RFC5007]で定義されています。バルクLEASEQUERY交換では、単一LEASEQUERY-REPLYメッセージは、クエリの成功または失敗を示すために、そのようなサーバIDとクライアントのような単一のクエリとの回答のコンテキストで変わらないデータを、運ぶために使用されています-IDオプション。クエリが成功した場合、唯一のシングルLEASEQUERY-REPLYメッセージが表示される必要があります。サーバーは、結合データを返している場合は、LEASEQUERY-REPLYもOPTION_CLIENT_DATAオプションの最初のクライアントのデータバインディングが含まれています。
The LEASEQUERY-DATA message carries data about a single DHCPv6 client's leases and/or PD bindings on a single link. The purpose of the message is to reduce redundant data when there are multiple bindings to be sent. The LEASEQUERY-DATA message MUST be preceded by a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY carries the query's status, the Leasequery's Client-ID and Server-ID options, and the first client's binding data if the query was successful.
LEASEQUERY-DATAメッセージは、単一のリンク上の単一のDHCPv6クライアントのリースおよび/またはPDバインディングに関するデータを運びます。メッセージの目的は、送信される複数のバインディングが存在する冗長データを低減することです。 LEASEQUERY-DATAメッセージはLEASEQUERY応答メッセージによって先行されなければなりません。クエリが成功した場合LEASEQUERY-REPLYは、クエリのステータス、LEASEQUERYのクライアントIDとサーバIDオプション、および最初のクライアントの結合データを運びます。
LEASEQUERY-DATA MUST ONLY be sent in response to a successful LEASEQUERY, and only if more than one client's data is to be sent. The LEASEQUERY-DATA message's transaction-id field MUST match the transaction-id of the LEASEQUERY request message. The Server-ID, Client-ID, and OPTION_STATUS_CODE options SHOULD NOT be included: that data should be constant for any one Bulk Leasequery reply, and should have been conveyed in the LEASEQUERY-REPLY message.
LEASEQUERY-DATAは、ONLY成功LEASEQUERYに対応して送らなければなりませんし、複数のクライアントのデータを送信する場合にのみ。 LEASEQUERY-DATAメッセージのトランザクションIDフィールドはLEASEQUERY要求メッセージのトランザクションIDと一致する必要があります。データは、任意の1つのバルクLEASEQUERY応答のための定数でなければならないこと、およびLEASEQUERY-REPLYメッセージで搬送されている必要があります：サーバID、クライアントID、およびOPTION_STATUS_CODEオプションが含まれるべきではありません。
The LEASEQUERY-DONE message indicates the end of a group of related Leasequery replies. The LEASEQUERY-DONE message's transaction-id field MUST match the transaction-id of the LEASEQUERY request message. The presence of the message itself signals the end of a stream of reply messages. A single LEASEQUERY-DONE MUST BE sent after all replies (a successful LEASEQUERY-REPLY and zero or more LEASEQUERY-DATA messages) to a successful Bulk Leasequery request that returned at least one binding.
LEASEQUERY-DONEメッセージは、関連LEASEQUERY応答のグループの終わりを示します。 LEASEQUERY-DONEメッセージのトランザクションIDフィールドはLEASEQUERY要求メッセージのトランザクションIDと一致する必要があります。メッセージ自体の存在は、応答メッセージのストリームの終わりを知らせます。すべての返信後に送信されなければならない単一DONE LEASEQUERY結合の少なくともいずれかを返さ成功バルクLEASEQUERY要求に（成功LEASEQUERY-REPLY及びゼロ以上LEASEQUERY-DATAメッセージ）。
A server may encounter an error condition after it has sent the initial LEASEQUERY-REPLY. In that case, it SHOULD attempt to send a LEASEQUERY-DONE with an OPTION_STATUS_CODE option indicating the error condition to the requestor. Other DHCPv6 options SHOULD NOT be included in the LEASEQUERY-DONE message.
それは初期LEASEQUERY-REPLYを送信した後、サーバーは、エラー状態が発生する可能性があります。その場合には、LEASEQUERY-DONE要求者にエラー状態を示すOPTION_STATUS_CODEオプションでの送信を試みるべきです。その他のDHCPv6オプションはLEASEQUERY-DONEメッセージに含まれるべきではありません。
The OPTION_LQ_QUERY option is defined in [RFC5007]. We introduce the following new query-types: QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, and QUERY_BY_REMOTE_ID. These queries are designed to assist relay agents in recovering binding data in circumstances where some or all of the relay's binding data has been lost.
OPTION_LQ_QUERYオプションは、[RFC5007]で定義されています。 QUERY_BY_RELAY_ID、QUERY_BY_LINK_ADDRESS、およびQUERY_BY_REMOTE_ID：私たちは、次の新しいクエリの種類を紹介します。これらのクエリは、リレーの結合データの一部またはすべてが失われた状況で結合データを回復するには、リレーエージェントを支援するために設計されています。
This query asks the server to return bindings associated with the specified relay DUID.
このクエリは、指定された中継DUIDに関連付けられているバインディングを返すようにサーバーに要求します。
QUERY_BY_RELAY_ID - The query-options MUST contain an OPTION_RELAY_ID option. If the link-address field is 0::0, the query asks for all bindings associated with the specified relay DUID. If the link-address is specified, the query asks for bindings on that link.
QUERY_BY_RELAY_ID - クエリオプションはOPTION_RELAY_IDオプションを含まなければなりません。リンク・アドレス・フィールドが0 :: 0である場合、クエリは指定された中継DUIDに関連付けられているすべてのバインディングを要求します。リンクアドレスが指定されている場合、クエリは、そのリンク上のバインディングを要求します。
The QUERY_BY_LINK_ADDRESS asks the server to return bindings on a network segment identified by a link-address value from a relay's Relay-Forward message.
QUERY_BY_LINK_ADDRESSは、リレーのリレーフォワードメッセージからのリンク・アドレス値によって識別されたネットワークセグメント上のバインディングを返すようにサーバーに要求します。
QUERY_BY_LINK_ADDRESS - The query's link-address contains an address a relay may have used in the link-address of a Relay-Forward message. The Server attempts to locate bindings on the same network segment as the link-address.
QUERY_BY_LINK_ADDRESS - クエリのリンクアドレスは、リレーはリレーフォワードメッセージのリンクアドレスで使用している可能性のアドレスが含まれています。サーバは、リンク・アドレスと同じネットワークセグメント上のバインディングを見つけることを試みます。
The QUERY_BY_REMOTE_ID asks the server to return bindings associated with a Remote-ID option value from a relay's Relay-Forward message. The query-options MUST include a Relay Agent Remote-ID option [RFC4649].
QUERY_BY_REMOTE_IDは、リレーのリレーフォワードメッセージからリモートIDオプションの値に関連付けられているバインディングを返すようにサーバーに要求します。クエリオプションは、リレーエージェントリモートIDオプション[RFC4649]を含まなければなりません。
In order to support this query, a server needs to record the most-recent Remote-ID option value seen in a Relay-Forward message along with its other binding data.
このクエリをサポートするために、サーバーは、そのほかの結合データと一緒にリレーフォワードメッセージで見られる最も最近のリモートIDのオプション値を記録する必要があります。
QUERY_BY_REMOTE_ID - The query-options MUST include a Relay Agent Remote-ID option [RFC4649]. If the Server has recorded Remote-ID values with its bindings, it uses the option's value to identify bindings to return.
QUERY_BY_REMOTE_ID - クエリオプションは、リレーエージェントリモートIDオプション[RFC4649]を含まなければなりません。 Serverはそのバインディングとリモート-ID値を記録している場合、それは返すようにバインディングを識別するために、オプションの値を使用しています。
The Relay-ID option carries a DUID [RFC3315]. A relay agent MAY include the option in Relay-Forward messages it sends. Obviously, it will not be possible for a server to respond to QUERY_BY_RELAY_ID queries unless the relay agent has included this option. A relay SHOULD be able to generate a DUID for this purpose, and capture the result in stable storage. A relay SHOULD also allow the DUID value to be configurable: doing so allows an administrator to replace a relay agent while retaining the association between the relay and existing DHCPv6 bindings.
リレー-IDオプションはDUID [RFC3315]を運びます。リレーエージェントは、それが送信リレーフォワードメッセージにオプションを含むかもしれません。リレーエージェントは、このオプションが含まれていない限り、サーバーがクエリをQUERY_BY_RELAY_IDに応答するために明らかに、それはできません。リレーは、この目的のためにDUIDを生成し、安定したストレージに結果を捕捉することができるべきです。リレーはまた、DUID値が設定可能なことを可能にする必要があります。そうすることは、リレーと、既存のDHCPv6バインディングとの間の関連性を維持しながら、管理者がリレーエージェントを置き換えることができます。
A DHCPv6 server MAY associate Relay-ID options from Relay-Forward messages it processes with prefix delegations and/or lease bindings that result. Doing so allows it to respond to QUERY_BY_RELAY_ID Leasequeries.
DHCPv6サーバは、それが結果プレフィックス代表団および/またはリースのバインディングを持つプロセスリレーフォワードメッセージからリレー-IDオプションを関連付けることができます。そうすることはQUERY_BY_RELAY_ID Leasequeriesに応答することができます。
The format of the Relay-ID option is shown below:
リレー-IDオプションのフォーマットは以下の通りです：
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_RELAY_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RELAY_ID.
オプションコードOPTION_RELAY_ID。
option-len Length of DUID in octets.
オクテットDUIDのオプション-LENの長さ。
DUID The DUID for the relay agent.
リレーエージェントのためのDUIDをDUID。
QueryTerminated - Indicates that the server is unable to perform a query or has prematurely terminated the query for some reason (which should be communicated in the text of the message). This may be because the server is short of resources or is being shut down. The requestor may retry the query at a later time. The requestor should wait at least a short interval before retrying. Note that while a server may simply prematurely close its end of the connection, it is preferable for the server to send a LEASEQUERY-REPLY or LEASEQUERY-DONE with this status-code to notify the requestor of the condition.
QueryTerminated - サーバがクエリを実行することができないか、早まっ（メッセージのテキストで伝達されなければならない）何らかの理由で、クエリを終了したことを示します。サーバはリソースが不足している、またはシャットダウンされているためと考えられます。要求者は、後でクエリを再試行することがあります。リクエスタは再試行する前に、少なくとも短い間隔を待つ必要があります。サーバは、単に途中接続のその端部を閉じることながら、サーバがLEASEQUERY-REPLYまたは状態の要求者に通知するために、このステータスコードとLEASEQUERY-DONEを送信するために、それが好ましいことに留意されたいです。
DHCPv6 servers that support Bulk Leasequery SHOULD listen for incoming TCP connections on the DHCPv6 server port 547. Implementations MAY offer to make the incoming port configurable, but port 547 MUST be the default. Client implementations SHOULD make TCP connections to port 547, and MAY offer to make the destination server port configurable.
バルクLEASEQUERYをサポートするのDHCPv6サーバは547実装は着信ポートを設定可能にするために提供することがありますが、ポート547がデフォルトでなければならないDHCPv6サーバポート上の着信TCP接続をリッスンすべきです。クライアントの実装では、ポート547へのTCP接続をしなければならない、と送信先サーバのポートを設定可能にするために提供することがあります。
This section presents a table of values used to control Bulk Leasequery behavior, including recommended defaults. Implementations MAY make these values configurable. However, configuring too-small timeout values may lead to harmful behavior both to this application as well as to other traffic in the network. As a result, timeout values smaller than the default values are NOT RECOMMENDED.
このセクションでは、推奨されるデフォルトを含むバルクLEASEQUERYの動作を制御するために使用される値の表を提示しています。実装は、これらの値が設定可能にするかもしれません。しかし、小さすぎるタイムアウト値を設定すると、このアプリケーションにだけでなく、ネットワーク内の他のトラフィックの両方に有害な行動につながる可能性があります。その結果、デフォルト値よりも小さいタイムアウト値は推奨されません。
Parameter Default Description
-------------------------------------------
BULK_LQ_DATA_TIMEOUT 300 s Bulk Leasequery data timeout
BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections
A requestor attempts to establish a TCP connection to a DHCPv6 server in order to initiate a Leasequery exchange. If the attempt fails, the requestor MAY retry.
リクエスタはLEASEQUERY交換を開始するために、DHCPv6サーバへのTCP接続を確立しようとします。失敗した場合、リクエスタは再試行するかもしれません。
After a connection is established, the requestor constructs a Leasequery message, as specified in [RFC5007]. The query may have any of the defined query-types, and includes the options and data required by the query-type chosen. The requestor sends the message size then sends the actual DHCPv6 message, as described in Section 5.1.
接続が確立された後、リクエスタは[RFC5007]で指定されるように、LEASEQUERYメッセージを構築します。クエリが定義されたクエリのタイプのいずれかを有し、そして選択されたクエリのタイプによって必要とされるオプション及びデータを含むことができます。リクエスタは、セクション5.1で説明したように、メッセージのサイズは、次に、実際のDHCPv6メッセージを送信する送信します。
If the TCP connection becomes blocked or stops being writeable while the requestor is sending its query, the requestor SHOULD be prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow requestors to control the period of time they are willing to wait before abandoning a connection, independent of notifications from the TCP implementations they may be using.
TCP接続がブロックされたか、要求者がそのクエリを送信している間、書き込み可能であることを停止してしまう場合は、要求者はBULK_LQ_DATA_TIMEOUT後に接続を終了するために準備する必要があります。私たちは、この勧告は、リクエスタは、彼らが使用している可能性のTCP実装からの通知の独立した接続を、放棄する前に待機して喜んでいる時間を制御できるようにします。
The requestor attempts to read a LEASEQUERY-REPLY message from the TCP connection. If the TCP connection stops delivering reply data (if the connection stops being readable), the requestor SHOULD be prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT, and MAY begin retry-processing if configured to do so.
リクエスタは、TCP接続からLEASEQUERY-REPLYメッセージを読み取ろうとします。 TCP接続は（接続が読み取ることが停止した場合）の応答データを配信停止した場合、リクエスタはBULK_LQ_DATA_TIMEOUT後に接続を終了するために準備する必要があり、そしてそうするように設定されている場合、リトライ処理を開始してもよいです。
The requestor examines the LEASEQUERY-REPLY message, and determines how to proceed. Message validation rules are specified in DHCPv6 Leasequery [RFC5007]. If the reply contains an error status code (carried in an OPTION_STATUS_CODE option), the requestor follows the recommendations in [RFC5007]. A successful reply that does not include an OPTION_CLIENT_DATA option indicates that the target server had no bindings matching the query.
リクエスタはLEASEQUERY-REPLYメッセージを調べて、続行する方法を決定します。メッセージの検証規則はDHCPv6のLEASEQUERY [RFC5007]で指定されています。応答が（OPTION_STATUS_CODEオプションで運ば）エラーステータスコードが含まれている場合、リクエスタは[RFC5007]の推奨事項に従います。 OPTION_CLIENT_DATAオプションが含まれていない正常な応答は、ターゲットサーバーがクエリに一致するバインディングがなかったことを示しています。
Note: The Leasequery protocol uses the OPTION_CLIENT_LINK option as an indicator that multiple bindings were present in response to a single query. For Bulk Leasequery, the OPTION_CLIENT_LINK option is not used, and MUST NOT be present in replies.
注：LEASEQUERYプロトコルは、複数のバインディングは、単一のクエリに応答して存在したことの指標としてOPTION_CLIENT_LINKオプションを使用します。バルクLEASEQUERYについて、OPTION_CLIENT_LINKオプションが使用されていない、と応答中に存在してはなりません。
A successful LEASEQUERY-REPLY that is returning binding data includes an OPTION_CLIENT_DATA option and possibly additional options. If there are additional bindings to be returned, they will be carried in LEASEQUERY-DATA messages. Each LEASEQUERY-DATA message contains an OPTION_CLIENT_DATA option, and possibly other options. A LEASEQUERY-DATA message that does not contain an OPTION_CLIENT_DATA MUST be discarded.
結合データを返す成功LEASEQUERY-REPLYはOPTION_CLIENT_DATAオプションと、おそらく追加のオプションが含まれています。余分なバインディングが返されることがある場合、それらはLEASEQUERY-DATAメッセージで運ばれます。各LEASEQUERY-DATAメッセージはOPTION_CLIENT_DATAオプション、およびおそらく他のオプションが含まれています。 OPTION_CLIENT_DATAが含まれていませんLEASEQUERY-DATAメッセージを捨てなければなりません。
A single bulk query can result in a large number of replies. For example, a single relay agent might be responsible for routes for thousands of clients' delegated prefixes. The requestor MUST be prepared to receive more than one LEASEQUERY-DATA with transaction-ids matching a single LEASEQUERY message.
バルク単クエリが回答の多くをもたらすことができます。例えば、単一のリレーエージェントは、クライアントの委任プレフィックスの何千ものルートに責任があるかもしれません。リクエスタは単一LEASEQUERYメッセージに一致するトランザクションIDを持つ複数のLEASEQUERY・データを受信するように準備しなければなりません。
The LEASEQUERY-DONE message ends a successful Bulk Leasequery request that returned at least one binding. A LEASEQUERY-REPLY without any bindings MUST NOT be followed by a LEASEQUERY-DONE message for the same transaction-id. After receiving LEASEQUERY-DONE from a server, the requestor MAY close the TCP connection to that server. If the transaction-id in the LEASEQUERY-DONE does not match an outstanding LEASEQUERY message, the client MUST close the TCP connection.
LEASEQUERY-DONEメッセージは、結合の少なくともいずれかを返さ成功バルクLEASEQUERY要求を終了します。任意のバインディングなしのLEASEQUERY-REPLYは、同じトランザクションIDのLEASEQUERY-DONEメッセージに続いてはいけません。 LEASEQUERY-DONEサーバーからの受信後、要求者は、そのサーバーへのTCP接続を閉じます。 LEASEQUERY-DONEのtransaction-idは、優れたLEASEQUERYメッセージと一致しない場合、クライアントは、TCP接続を閉じる必要があります。
The reply to a Bulk Leasequery request is complete (i.e., no further messages for that request transaction-id will be received) when one of these conditions is met:
これらのいずれかの条件が満たされたときにバルクLEASEQUERY要求に対する応答（すなわち、その要求のトランザクションIDのための更なるメッセージが受信されません）が完了しました。
1. if the LEASEQUERY-REPLY message had no OPTION_CLIENT_DATA option, when the LEASEQUERY-REPLY is received,
1. LEASEQUERY-REPLYメッセージは何OPTION_CLIENT_DATAオプションを持っていた場合、LEASEQUERY-REPLYを受信したときに、
2. else if the LEASEQUERY-REPLY did have an OPTION_CLIENT_DATA, when the corresponding LEASEQUERY-DONE message is received,
2. LEASEQUERY-REPLYがOPTION_CLIENT_DATAを持っていた他の場合は、対応するLEASEQUERY-DONEメッセージを受信したときに、
A Bulk Leasequery client MAY be configured to attempt to connect to and query from multiple DHCPv6 servers in parallel. The DHCPv6 Leasequery specification [RFC5007] includes a discussion about reconciling binding data received from multiple DHCPv6 servers.
バルクLEASEQUERYクライアントは、並行して複数のDHCPv6サーバからにして、クエリの接続を試みるように構成することができます。 DHCPv6のLEASEQUERY仕様[RFC5007]は複数のDHCPv6サーバから受信した結合データを調和に関する議論を含みます。
Bulk Leasequery clients may need to make multiple queries in order to recover binding information. A requestor MAY use a single connection to issue multiple queries. Each query MUST have a unique transaction-id. A server MAY process more than one query at a time. A server that is willing to do so MAY interleave replies to the multiple queries within the stream of reply messages it sends. Clients need to be aware that replies for multiple queries may be interleaved within the stream of reply messages. Clients that are not able to process interleaved replies (based on transaction-id) MUST NOT send more than one query at a time. Requestors should be aware that servers are not required to process queries in parallel, and that servers are likely to limit the rate at which they process queries from any one requestor.
バルクLEASEQUERYクライアントはバインディング情報を回復するために、複数のクエリを作成する必要があるかもしれません。リクエスタは複数のクエリを発行する単一の接続を使用するかもしれません。各クエリは、一意のトランザクションIDが必要です。サーバは、一度に複数のクエリを処理することができます。そうする意志があるサーバは、送信する応答メッセージのストリーム内の複数のクエリへの応答をインターリーブするかもしれません。クライアントは、複数のクエリのための応答が応答メッセージのストリーム内にインターリーブすることができることに注意する必要があります。 （トランザクションIDに基づいて）インターリーブされた応答を処理することができませんクライアントは、一度に複数のクエリを送ってはいけません。リクエスタは、サーバが並列クエリを処理するために必要とされていないこと、およびサーバは、彼らがいずれかのリクエスタからのクエリを処理する速度を制限する可能性があることに注意する必要があります。
This example illustrates what a series of queries and responses might look like. This is only an example -- there is no requirement that this sequence must be followed, or that clients or servers must support parallel queries.
この例では、クエリと一連の応答がどのように見えるかを示しています。このシーケンスは従わなければならない、またはクライアントまたはサーバは、並列クエリをサポートしなければならないという要件がない - これは一例に過ぎません。
In the example session, the client sends four queries after establishing a connection; "xid" denotes a transaction-id in the diagram. Query 1 results in a failure; query 2 succeeds and the stream of replies concludes before the client issues any new query. Query 3 and query 4 overlap, and the server interleaves its replies to those two queries.
例セッションでは、クライアントは接続を確立した後、4つのクエリを送信します。 「XIDは、」図中のトランザクションIDを示しています。クエリの失敗で1つの結果。クエリ2は成功し、クライアントは、新しいクエリを発行する前に応答のストリームが終了します。クエリ3とクエリ4オーバーラップ、およびサーバは、これらの2つのクエリへの応答をインターリーブします。
Client Server
------ ------
LEASEQUERY xid 1 ----->
<----- LEASEQUERY-REPLY xid 1 (w/error)
LEASEQUERY xid 2 ----->
<----- LEASEQUERY-REPLY xid 2
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DONE xid 2
LEASEQUERY xid 3 ----->
LEASEQUERY xid 4 ----->
<----- LEASEQUERY-REPLY xid 4
<----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-REPLY xid 3
<----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DONE xid 3
<----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-DONE xid 4
The requestor MAY close its end of the TCP connection after sending a LEASEQUERY message to the server. The requestor MAY choose to retain the connection if it intends to issue additional queries. Note that this client behavior does not guarantee that the connection will be available for additional queries: the server might decide to close the connection based on its own configuration.
リクエスタは、サーバへのLEASEQUERYメッセージを送信した後、TCPコネクションの終わりを閉じます。リクエスタは、それは追加のクエリを発行しようとする場合、接続を維持するために選ぶかもしれません。サーバーには、独自の構成に基づいて、接続を閉じるように決めるかもしれません：このクライアントの動作は、接続が追加クエリのために利用可能になることを保証するものではないことに注意してください。
Servers that implement DHCPv6 Bulk Leasequery listen for incoming TCP connections. Port numbers are discussed in Section 5.6. Servers MUST be able to limit the number of currently accepted and active connections. The value BULK_LQ_MAX_CONNS MUST be the default; implementations MAY permit the value to be configurable.
DHCPv6のバルクを実装するサーバは、着信TCP接続をリッスンLEASEQUERY。ポート番号は5.6節で議論されています。サーバーは、現在受け入れられ、アクティブな接続の数を制限することができなければなりません。値BULK_LQ_MAX_CONNSはデフォルトでなければなりません。実装は、設定する値を許可することができます。
Servers MAY restrict Bulk Leasequery connections and LEASEQUERY messages to certain clients. Connections that are not from permitted clients SHOULD BE closed immediately, to avoid server connection resource exhaustion. Servers MAY restrict some clients to certain query types. Servers MAY reply to queries that are not permitted with the NotAllowed status code [RFC5007], and/or close the connection.
サーバは特定のクライアントに一括LEASEQUERY接続とLEASEQUERYメッセージを制限することができます。許可されたクライアントからの接続ではありませんが、サーバー接続リソースの枯渇を避けるために、すぐに閉じる必要があります。サーバーは、特定のクエリの種類に一部のクライアントを制限することができます。サーバーは、のnotAllowedステータスコード[RFC5007]で許可されていないクエリに応答、及び/又は、接続を閉じます。
If the TCP connection becomes blocked while the server is accepting a connection or reading a query, it SHOULD be prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow Servers to control the period of time they are willing to wait before abandoning an inactive connection, independent of the TCP implementations they may be using.
サーバが接続を受け入れるか、クエリを読んでいる間にTCP接続がブロックされた状態になる場合、BULK_LQ_DATA_TIMEOUT後に接続を終了するために準備する必要があります。私たちは、この勧告は、サーバは、彼らが使用している可能性のTCP実装の独立した非アクティブな接続を、放棄する前に待機して喜んでいる時間を制御できるようにします。
The DHCPv6 Leasequery [RFC5007] specification describes the initial construction of LEASEQUERY-REPLY messages and the processing of QUERY_BY_ADDRESS and QUERY_BY_CLIENTID. Use of the LEASEQUERY-REPLY and LEASEQUERY-DATA messages to carry multiple bindings is described in Section 5.2. Message transmission and framing for TCP is described in Section 5.1. If the connection becomes blocked while the server is attempting to send reply messages, the server SHOULD be prepared to terminate the TCP connection after BULK_LQ_DATA_TIMEOUT.
DHCPv6のLEASEQUERY [RFC5007]仕様はLEASEQUERY返信メッセージの初期構成とQUERY_BY_ADDRESSとQUERY_BY_CLIENTIDの処理について説明します。複数のバインディングを運ぶLEASEQUERY-REPLYとLEASEQUERY-DATAメッセージの使用は、セクション5.2に記載されています。 TCPのためのメッセージ送信やフレーミングは、セクション5.1に記載されています。サーバが応答メッセージを送信しようとしている間に、接続がブロックされた状態になる場合は、サーバーはBULK_LQ_DATA_TIMEOUT後のTCP接続を終了するために準備する必要があります。
If the server encounters an error during initial query processing, before any reply has been sent, it SHOULD send a LEASEQUERY-REPLY containing an error code in an OPTION_STATUS_CODE option. This signals to the requestor that no data will be returned. If the server encounters an error while processing a query that has already resulted in one or more reply messages, the server SHOULD send a LEASEQUERY-DONE message with an error status. The server SHOULD close its end of the connection as an indication that it was not able to complete query processing.
すべての返信が送られてきた前に、サーバーは、最初のクエリ処理中にエラーが発生した場合、それはOPTION_STATUS_CODEオプションでエラーコードを含むLEASEQUERY-REPLYを送信すべきです。これは、何もデータが返されないことを要求者に通知します。すでに一つ以上の応答メッセージをもたらしたクエリの処理中にサーバーでエラーが発生した場合は、サーバがエラー状態でLEASEQUERY-DONEメッセージを送信する必要があります。サーバはクエリ処理を完了することができなかったことを示すものとして、接続の終わりを閉じる必要があります。
If the server does not find any bindings satisfying a query, it SHOULD send a LEASEQUERY-REPLY without an OPTION_STATUS_CODE option and without any OPTION_CLIENT_DATA option. Otherwise, the server sends each binding's data in a reply message. The first reply message is a LEASEQUERY-REPLY. The binding data is carried in an OPTION_CLIENT_DATA option, as specified in [RFC5007] and extended below. The server returns subsequent bindings in LEASEQUERY-DATA messages, which can avoid redundant data (such as the requestor's Client-ID).
サーバーがクエリを満たす任意のバインディングが見つからない場合は、OPTION_STATUS_CODEオプションを使用せず、あらゆるOPTION_CLIENT_DATAオプションなしでLEASEQUERY-REPLYを送信すべきです。そうでなければ、サーバは、応答メッセージ内の各バインディングのデータを送信します。最初の応答メッセージはLEASEQUERY-REPLYあります。 [RFC5007]で指定し、以下のように拡張バインディングデータは、OPTION_CLIENT_DATAオプションで運ばれます。サーバは、（例えば、要求側のクライアントIDのような）、冗長データを避けることができるLEASEQUERY-DATAメッセージに後続のバインディングを返します。
For QUERY_BY_RELAY_ID, the server locates each binding associated with the query's Relay-ID option value. In order to give a meaningful reply to a QUERY_BY_RELAY_ID, the server has to be able to maintain this association in its DHCPv6 binding data. If the query's link-address is not set to 0::0, the server only returns bindings on links that could contain that address. If the link-address is not 0::0 and the server cannot find any matching links, the server SHOULD return the NotConfigured status in a LEASEQUERY-REPLY.
QUERY_BY_RELAY_IDの場合、サーバーは、それぞれがクエリのリレー-IDのオプション値に関連付けられたバインディング検索します。 QUERY_BY_RELAY_IDに意味のある応答を与えるために、サーバはDHCPv6のバインディングデータは、この関連付けを維持することができなければなりません。クエリのリンクアドレスは0 :: 0に設定されていない場合、サーバはそのアドレスが含まれている可能性があり、リンク上のバインディングを返します。リンクアドレスが0 :: 0でなく、サーバが一致するリンクを見つけることができない場合、サーバーはLEASEQUERY-REPLYにNotConfiguredステータスを返すべきです。
For QUERY_BY_LINK_ADDRESS, the server locates each binding associated with the link identified by the query's link-address value.
QUERY_BY_LINK_ADDRESSの場合、サーバーは、それぞれが、クエリのリンクアドレス値によって識別されたリンクに関連付けられたバインディング検索します。
For QUERY_BY_REMOTE_ID, the server locates each binding associated with the query's Relay Remote-ID option value. In order to be able to give meaningful replies to this query, the server has to be able to maintain this association in its binding database. If the query message's link-address is not set to 0::0, the server only returns bindings on links that could contain that address. If the link-address is not 0::0 and the server cannot find any matching links, the server SHOULD return the NotConfigured status in a LEASEQUERY-REPLY.
QUERY_BY_REMOTE_IDの場合、サーバーは、それぞれがクエリのリレーリモートIDのオプション値に関連付けられたバインディング検索します。このクエリに意味のある応答を与えることができるようにするために、サーバは、その結合のデータベースにこの関連付けを維持することができなければなりません。問い合わせメッセージのリンクアドレスが0 :: 0に設定されていない場合、サーバはそのアドレスが含まれている可能性があり、リンク上のバインディングを返します。リンクアドレスが0 :: 0でなく、サーバが一致するリンクを見つけることができない場合、サーバーはLEASEQUERY-REPLYにNotConfiguredステータスを返すべきです。
The server sends the LEASEQUERY-DONE message as specified in Section 5.2.
サーバーは、5.2節で指定されLEASEQUERY-DONEメッセージを送信します。
As discussed in Section 6.5, requestors may want to leverage an existing connection if they need to make multiple queries. Servers MAY support reading and processing multiple queries from a single connection. A server MUST NOT read more query messages from a connection than it is prepared to process simultaneously.
6.5節で述べたように、要求者は、彼らが複数のクエリを作成する必要がある場合は、既存の接続を活用することもできます。サーバーは、単一の接続からの読み取りと処理、複数のクエリをサポートするかもしれません。同時に処理するために準備されているよりも、サーバが接続からより多くのクエリーメッセージを読んではなりません。
This MAY be a feature that is administratively controlled. Servers that are able to process queries in parallel SHOULD offer configuration that limits the number of simultaneous queries permitted from any one requestor, in order to control resource use if there are multiple requestors seeking service.
これは、管理制御されている特徴であり得ます。並行してクエリを処理することができるサーバは、サービスを求める複数のリクエスタが存在する場合、リソースの使用を制御するために、いずれかのリクエスタから許可同時クエリの数を制限する構成を提供するべきです。
The server MAY close its end of the TCP connection after sending its last message (a LEASEQUERY-REPLY or a LEASEQUERY-DONE) in response to a query. Alternatively, the server MAY retain the connection and wait for additional queries from the client. The server SHOULD be prepared to limit the number of connections it maintains, and SHOULD be prepared to close idle connections to enforce the limit.
サーバがクエリに応答して、最後のメッセージ（LEASEQUERY-REPLYまたはLEASEQUERY-DONE）を送信した後、TCPコネクションの終わりを閉じます。また、サーバは接続を保持し、クライアントからの追加のクエリを待つことができます。サーバは、それが保持する接続の数を制限するために準備する必要があり、そして制限を適用するためにアイドル状態の接続を閉じるために準備されるべきです。
The server MUST close its end of the TCP connection if it encounters an error sending data on the connection. The server MUST close its end of the TCP connection if it finds that it has to abort an in-process request. A server aborting an in-process request MAY attempt to notify its clients by using the QueryTerminated (Section 5.5) status code. If the server detects that the client end has been closed, the server MUST close its end of the connection after it has finished processing any outstanding requests from the client.
それは、接続上のデータの送信中にエラーが発生した場合、サーバーは、TCPコネクションの終わりを閉じる必要があります。それはインプロセス要求を中止する必要があることを発見した場合、サーバーは、TCPコネクションの終わりを閉じる必要があります。インプロセス要求を中止するサーバはQueryTerminated（5.5節）ステータスコードを使用することによって、そのクライアントに通知しようとすることができます。サーバーは、クライアント側が閉じられたことを検出した場合、それはクライアントからの未処理の要求の処理を完了した後、サーバーは接続の終わりを閉じる必要があります。
The "Security Considerations" section of [RFC3315] details the general threats to DHCPv6. The DHCPv6 Leasequery specification [RFC5007] describes recommendations for the Leasequery protocol, especially with regard to relayed LEASEQUERY messages, mitigation of packet-flooding denial-of-service (DoS) attacks, restriction to trusted clients, and use of IPsec [RFC4301].
[RFC3315]の「セキュリティについての考慮事項」セクションには、DHCPv6のに一般的な脅威を詳述します。 DHCPv6のLEASEQUERY仕様[RFC5007]は、特に中継LEASEQUERYメッセージ、パケットフラッディングサービス拒否（DoS）攻撃の緩和、信頼できるクライアントに制限、およびIPsecの使用[RFC4301]に関連して、LEASEQUERYプロトコルのための推奨事項について説明します。
The use of TCP introduces some additional concerns. Attacks that attempt to exhaust the DHCPv6 server's available TCP connection resources, such as SYN flooding attacks, can compromise the ability of legitimate clients to receive service. Malicious clients who succeed in establishing connections, but who then send invalid queries, partial queries, or no queries at all also can exhaust a server's pool of available connections. We recommend that servers offer configuration to limit the sources of incoming connections, that they limit the number of accepted connections and the number of in-process queries from any one connection, and that they limit the period of time during which an idle connection will be left open.
TCPの使用は、いくつかの追加の懸念を紹介します。このようSYNフラッド攻撃などDHCPv6サーバの利用可能なTCPコネクションリソースを、排出しようとする攻撃は、サービスを受信するための正当なクライアントの能力を損なうことができます。接続を確立することに成功したが、誰が、その後も、まったく無効なクエリ、部分的なクエリ、または全くクエリを送信悪意のあるクライアントが利用可能な接続のサーバーのプールを排出することができます。我々は、彼らがいずれかの接続から受け入れた接続の数と処理中のクエリの数を制限することを、サーバーが着信接続のソースを制限するための設定を提供することをお勧めします、と彼らはアイドル状態の接続がされる期間を制限すること開いたまま。
IANA has assigned a new value in the registry of DHCPv6 Option Codes:
IANAは、DHCPv6のオプションコードのレジストリに新しい値を割り当てています：
53 OPTION_RELAY_ID
53 OPTION_RELAY_ID
IANA has assigned a new value in the registry of DHCPv6 Status Codes:
IANAは、DHCPv6のステータスコードのレジストリに新しい値を割り当てています：
11 QueryTerminated
11 QueryTerminated
IANA has assigned the following values in the registry of DHCPv6 Message types:
IANAは、DHCPv6のメッセージタイプのレジストリに次の値を割り当てています：
16 LEASEQUERY-DONE 17 LEASEQUERY-DATA
16 LEASEQUERY-DONE 17 LEASEQUERY-DATA
IANA has assigned the following values in the registry of query-types for the DHCPv6 OPTION_LQ_QUERY option:
IANAは、DHCPv6のOPTION_LQ_QUERYオプションのクエリの種類のレジストリに次の値を割り当てています：
3 QUERY_BY_RELAY_ID 4 QUERY_BY_LINK_ADDRESS 5 QUERY_BY_REMOTE_ID
3 QUERY_BY_RELAY_ID 4 QUERY_BY_LINK_ADDRESS 5 QUERY_BY_REMOTE_ID
The above-mentioned registries are available from http://www.iana.org.
上記レジストリはhttp://www.iana.orgから入手可能です。
Many of the ideas in this document were originally proposed by Kim Kinnear, Richard Johnson, Hemant Singh, Ole Troan, and Bernie Volz. Further suggestions and improvements were made by participants in the DHC working group, including John Brzozowski, Marcus Goller, Alfred Hoenes, Ted Lemon, Bud Millwood, and Thomas Narten.
この文書のアイデアの多くは、もともとキム・キニア、リチャード・ジョンソン、Hemantシン、オレTroan、バーニーフォルツによって提案されました。さらに、提案や改善がジョンBrzozowski、マーカスGoller、アルフレッドHoenes、テッド・レモン、バドミルウッド、およびトーマスNarten氏を含めDHCワーキンググループの参加者によって行われました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O.とR. Droms、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006.
[RFC4649]フォルツ、B.、 "IPv6の動的ホスト構成プロトコル（DHCPv6）リレーエージェントリモートIDオプション"、RFC 4649、2006年8月。
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5007] Brzozowski、J.、キニア、K.、フォルツ、B.、およびS.曽、 "DHCPv6のLEASEQUERY"、RFC 5007、2007年9月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
[RFC4614]デューク、M.、ブレーデン、R.、エディ、W.、及びE.ブラントン、RFC 4614、2006年9月 "伝送制御プロトコル（TCP）仕様書のためのロードマップ"。
Author's Address
著者のアドレス
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
マーク・スタップシスコシステムズ株式会社1414年マサチューセッツアベニュー。ボックスボロー、MA 01719 USA
Phone: +1 978 936 0000 EMail: mjs@cisco.com
電話：+1 978 936 0000 Eメール：mjs@cisco.com