[要約] RFC 5460は、DHCPv6 Bulk Leasequeryプロトコルに関する仕様であり、DHCPv6サーバーから大量のリース情報を効率的に取得するための手法を提供します。目的は、ネットワーク管理者がリース情報を効率的に取得し、ネットワークの状態を把握することです。
Network Working Group M. Stapp
Request for Comments: 5460 Cisco Systems, Inc.
Category: Standards Track February 2009
DHCPv6 Bulk Leasequery
DHCPV6バルクリースクリー
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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バインディングに関する情報を要求できるようにするリースクリー機能で拡張されています。そのメカニズムは、個々のバインディングのクエリに限定されています。状況によっては、個々のバインディングクエリは効率的ではない場合もあります。このドキュメントは、リースクリープロトコルで拡張され、新しいクエリタイプを追加し、TCPを介したDHCPV6結合データの一括転送を可能にします。
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 [RFC3633]のIPv6プレフィックス委任（PD）は、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クライアントは、委任ネットワークにルートを注入することを許可されない場合があります。たとえば、Service-Provider（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サーバーからの個々のバインディングのクエリを許可するDHCPV6リースクリープロトコル[RFC5007]が開発されました。個々のクエリメカニズムは、トラフィックの受領時など、ターゲットバインディングが要求者に知られている場合にのみ使用可能です。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リースクリープロトコルを拡張して、これらの要件に対処するクエリのサポートを追加します。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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
DHCPv6 terminology is defined in [RFC3315]. DHCPv6 Leasequery terminology is defined in [RFC5007].
DHCPV6用語は[RFC3315]で定義されています。DHCPV6リースクリーの用語は[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.
バルクリースクリーメカニズムは、[RFC5007]の既存の個々のリースクリープロトコルをモデルにしています。ほとんどの違いは、TCPの使用から生じます。バルクリースクリークライアントは、DHCPV6ポート547を使用して、DHCPV6サーバーへのTCP接続を開きます。これは、リスケットクライアントが構成またはその他の手段を介して使用可能なサーバーIPアドレスを持っていることを意味し、それがUNICAST IPリーチ可能性を備えていることに注意してください。サーバー。バルクリースクリーの中継は指定されていません。
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.
接続を確立した後、クライアントは、関心のあるバインディングに関するクエリタイプとデータを含むリースクリーメッセージを送信します。サーバーはクエリタイプとデータを使用して、関連するバインディングを識別します。いくつかのクエリタイプをサポートするために、サーバーは追加のデータ構造を維持するか、特定のオプションデータに基づいてバインディングを見つけることができる場合があります。サーバーは、クエリの成功または失敗を示しているリースクリーを繰り返したメッセージで返信します。クエリが成功した場合、サーバーには、リースクリーリプリーメッセージに最初のクライアントのバインディングデータも含まれています。複数のクライアントのバインディングが返されている場合、サーバーは、追加のクライアントバインディングを一連のリースクエリDATAメッセージに送信します。サーバーが少なくとも1つのクライアントのバインディングを送信した場合、返信が終了したときにリースクリードーンメッセージが送信されます。クライアントは、接続を再利用して追加のクエリを送信する場合があります。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オプションが含まれています。このオプションには、DHCPV6リレーエージェントを識別するDUID（DHCP一意の識別子）が含まれています。リレーエージェントは、このオプションを送信するリレーフォワードメッセージに含めることができます。サーバーは、リレーIDを保持し、リレーのクライアントに代わって作成されたバインディングに関連付けることができます。リレーは、リレー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.
Bulk Leasequeryは、[RFC5007]で指定されているように、IPv6アドレスとクライアントDUIDによってクエリをサポートしています。バルクリースクリープロトコルには、いくつかの新しいクエリも追加されています。ここで導入された新しいクエリは、UDPリースクリープロトコルで効果的に使用することはできません。要求者は、[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.
バルクリースクリーは、既存のUDPリースクリープロトコル[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リースクリープロトコルで導入されたクエリタイプは、バルクリースクリープロトコルで使用できます。動作に1つの変更が導入されます。[RFC5007]は、セクション4.1.2.5および4.3.3で、複数のバインディングが見つかった場合のリーズクエリレプリーメッセージでクライアントリンクオプションの使用を指定しています。バルクリースクリーが使用される場合、このメカニズムは必要ありません。複数のバインディングを返すサーバーは、このドキュメントで指定されたとおりに直接それを行うだけです。クライアントリンクオプションは、バルクリースクリーの返信に表示されてはなりません。
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.
バルクリースクリー接続では、リースクリー、リースクリー、リースクリー、リースクリーデータ、およびリースクリードーンメッセージのみが許可されています。他のDHCPV6メッセージはサポートされていません。バルクリースクリー接続は、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リースクリープロトコルでは使用できません。この仕様を実装し、UDPクエリを許可するサーバーは、UDPリースクリーメッセージのバルクリースクリークエリタイプを受け入れてはなりません。このようなサーバーは、Allowed [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.
バルクリースクリープロトコルにTCPを使用すると、1つ以上のDHCPV6メッセージを一度に送信できます。受信者は、各メッセージの大きさを判断できる必要があります。ネットワークバイト順序でメッセージサイズを含む2つのオクテットは、バルクリースクリー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.
リースクリーとリースクリーの繰り返しメッセージは、[RFC5007]で定義されています。バルクリースクリーの交換では、クエリの成功または失敗を示すために、単一のリースクリーリプリーメッセージを使用し、サーバーIDやクライアントなどの単一のクエリと回答のコンテキストで変更されないデータを伝達するために使用されます。-idオプション。クエリが成功した場合、1つのリースクリーリプリーメッセージのみが表示される必要があります。サーバーがバインディングデータを返している場合、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-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 MessageのTransaction-IDフィールドは、Leasequery RequestメッセージのTransaction-IDと一致する必要があります。Server-ID、Client-ID、およびOption_Status_Codeオプションは含めるべきではありません。そのデータは、1つのバルクリースクリーの返信に対して一定である必要があり、リースクリーリップのメッセージで伝えられる必要があります。
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 MessageのTransaction-IDフィールドは、Leasequery RequestメッセージのTransaction-IDと一致する必要があります。メッセージ自体の存在は、返信メッセージのストリームの終わりを示しています。少なくとも1つのバインディングを返したバルクリースクリーリクエストを成功させるために、すべての返信（リースクリーリプリーとゼロ以上のリースクリーデータメッセージ）の後に、単一のリースクリードーンを送信する必要があります。
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.
サーバーは、最初のリリースクリーリプリーを送信した後、エラー条件に遭遇する場合があります。その場合、リクエストターにエラー条件を示すOption_Status_Codeオプションを使用してリスケリードーンを送信しようとする必要があります。他のDHCPV6オプションは、リースクリードーンメッセージに含めないでください。
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-Typesを紹介します：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 -query -optionsにはoption_relay_idオプションを含める必要があります。Link-Addressフィールドが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-queryのリンクアドレスには、リレーがリレーに使用したアドレスが含まれています。サーバーは、リンクアドレスと同じネットワークセグメントでバインディングを見つけようとします。
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-query-optionsには、リレーエージェントリモートIDオプション[RFC4649]を含める必要があります。サーバーがバインディングでリモート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 queriesに応答することは不可能です。リレーは、この目的のために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.
オプションコードオプション_RELAY_ID。
option-len Length of DUID in octets.
オクテットのデュイドのオプションレン長。
DUID The DUID for the relay agent.
リレーエージェントのDuid The 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.
クエリ終了 - サーバーがクエリを実行できないか、何らかの理由でクエリを早期に終了したことを示します（メッセージのテキストで伝達する必要があります）。これは、サーバーがリソースが不足しているか、シャットダウンされているためかもしれません。リクエスターは、後でクエリを再試行する場合があります。要求者は、再試行する前に少なくとも短い間隔を待つ必要があります。サーバーは単に接続の端を時期尚早に閉じることができますが、サーバーがこのステータスコードでリリースクリーまたはリースクリードーンを送信して、条件を要求者に通知することが望ましいことに注意してください。
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.
バルクリースクリーをサポートするDHCPV6サーバーは、DHCPV6サーバーポート547で着信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.
このセクションでは、推奨されるデフォルトを含む、バルクリースクリーの動作を制御するために使用される価値の表を紹介します。実装により、これらの値が構成可能になる場合があります。ただし、小さなタイムアウト値を構成すると、このアプリケーションとネットワーク内の他のトラフィックの両方に有害な動作が発生する場合があります。その結果、デフォルト値よりも小さいタイムアウト値は推奨されません。
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.
リクエスターは、リースクリー交換を開始するために、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]で指定されているように、リースクリーメッセージを作成します。クエリには、定義されたクエリタイプのいずれかがあり、選択されたクエリタイプに必要なオプションとデータが含まれています。要求者はメッセージサイズを送信し、セクション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接続からリースクリーリプのメッセージを読み取ろうとします。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.
要求者は、リースクリーの繰り返しメッセージを調べ、進行方法を決定します。メッセージ検証ルールは、DHCPV6リースクリー[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 Protocolは、Option_Client_Linkオプションを、単一のクエリに応じて複数のバインディングが存在することを示すインジケーターとして使用します。バルクリースクリーの場合、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.
バインディングデータを返しているリースクリーリップの成功には、option_client_dataオプションと追加のオプションが含まれます。返される追加のバインディングがある場合、それらはリースクリーデータメッセージで運ばれます。各Leasequery-Dataメッセージには、option_client_dataオプションが含まれています。option_client_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.
単一のバルククエリは、多数の返信をもたらす可能性があります。たとえば、単一のリレーエージェントが、数千のクライアントの委任されたプレフィックスのルートを担当する可能性があります。要求者は、単一のリースクリーメッセージに一致するトランザクションIDを使用して、複数のリースクリーデータを受信する準備をする必要があります。
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.
リースクリードーンメッセージは、少なくとも1つのバインディングを返した成功したバルクリースクリーリクエストを終了します。バインディングのないリリースクリーは、同じTransaction-IDのリースクリードーンメッセージを続けてはなりません。サーバーからリースクリードーンを受信した後、要求者はそのサーバーへのTCP接続を閉じることができます。リースクリードーンのTransaction-IDが未払いのリースクリーメッセージと一致しない場合、クライアントは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:
これらの条件のいずれかが満たされた場合、バルクリースクリーリクエストへの返信は完了しました（つまり、そのリクエストトランザクション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メッセージが受信されたとき、
3. else when the connection is closed.
3. それ以外の場合、接続が閉じているとき。
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.
バルクリースクリークライアントは、複数のDHCPV6サーバーに接続して並行して照会しようとするように構成されている場合があります。DHCPV6リースクリー仕様[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.
拘束力のある情報を回復するために、バルクリースクリークライアントが複数のクエリを作成する必要がある場合があります。要求者は、単一の接続を使用して複数のクエリを発行できます。各クエリには一意のトランザクションIDが必要です。サーバーは、一度に複数のクエリを処理する場合があります。そうすることをいとわないサーバーは、送信する応答メッセージのストリーム内の複数のクエリへの返信をインターリーブする場合があります。クライアントは、複数のクエリの返信が返信メッセージのストリーム内にインターリーブされる可能性があることに注意する必要があります。（トランザクションIDに基づく）インターリーブの返信を処理できないクライアントは、一度に複数のクエリを送信してはなりません。要求者は、サーバーがクエリを並行して処理する必要がないこと、およびサーバーが1つの要求者からクエリを処理するレートを制限する可能性が高いことに注意する必要があります。
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.
リクエスターは、サーバーにリリースクリーメッセージを送信した後、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接続を聴きます。ポート番号については、セクション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.
サーバーは、特定のクライアントへのバルクリースクリー接続とリースクリーメッセージを制限する場合があります。許可されたクライアントからのものではない接続は、サーバー接続のリソースの使い果たしを避けるために、すぐに閉じる必要があります。サーバーは、一部のクライアントを特定のクエリタイプに制限する場合があります。サーバーは、Allowed Statusコード[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リースクリー[RFC5007]仕様では、リスケリセプリーメッセージの初期構築とquery_by_addressおよびquery_by_clientIdの処理について説明します。複数のバインディングを運ぶためのリースクリーリプリーおよびリースクリーデータメッセージの使用については、セクション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オプションにエラーコードを含むリスケアリセプリーを送信する必要があります。これは、データが返されないことを要求者に信号します。サーバーが既に1つ以上の応答メッセージが作成されているクエリを処理しているときにエラーを遭遇した場合、サーバーはエラーステータスでリスケリードーンメッセージを送信する必要があります。サーバーは、クエリ処理を完了できなかったことを示すために、接続の終了を閉じる必要があります。
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を送信する必要があります。それ以外の場合、サーバーは各バインディングのデータを返信メッセージに送信します。最初の返信メッセージは、リースクリーリプリーです。バインディングデータは、[RFC5007]で指定され、以下に拡張されたように、option_client_dataオプションで送られます。サーバーは、冗長データ（リクエスターのクライアントIDなど）を回避できるリースクリーデータメッセージの後続のバインディングを返します。
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の場合、サーバーはQueryのリレーIDオプション値に関連付けられた各バインディングを見つけます。query_by_relay_idに意味のある返信を行うには、サーバーはこの関連付けをDHCPV6バインディングデータで維持できる必要があります。クエリのリンクアドレスが0 :: 0に設定されていない場合、サーバーはそのアドレスを含む可能性のあるリンクのバインディングのみを返します。Link-Addressが0 :: 0ではなく、サーバーが一致するリンクを見つけることができない場合、サーバーはリースクリーリングで構成されていないステータスを返す必要があります。
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の場合、サーバーは、queryのリンクアドレス値によって識別されたリンクに関連付けられた各バインディングを見つけます。
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の場合、サーバーは、QueryのリレイリモートIDオプション値に関連付けられた各バインディングを見つけます。このクエリに意味のある返信を提供できるようにするために、サーバーはこの関連付けをバインディングデータベースで維持できる必要があります。クエリメッセージのリンクアドレスが0 :: 0に設定されていない場合、サーバーはそのアドレスを含む可能性のあるリンクのバインディングのみを返します。Link-Addressが0 :: 0ではなく、サーバーが一致するリンクを見つけることができない場合、サーバーはリースクリーリングで構成されていないステータスを返す必要があります。
The server sends the LEASEQUERY-DONE message as specified in Section 5.2.
サーバーは、セクション5.2で指定されているように、リースクリードーンメッセージを送信します。
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.
これは、管理上管理されている機能かもしれません。クエリを並行して処理できるサーバーは、複数の要求者がサービスを求めている場合にリソースの使用を制御するために、1つの要求者から許可される同時クエリの数を制限する構成を提供する必要があります。
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.
サーバーは、クエリに応じて、最後のメッセージ（リースクリーリプリーまたはリースクリードーン）を送信した後、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接続の終了を閉じる必要があります。インプロセスリクエストを中止するサーバーは、クエリ終了（セクション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リースクリー仕様[RFC5007]は、特にリレーしたリースクリーメッセージ、パケットフラッド拒否拒否（DOS）攻撃の緩和、信頼できるクライアントへの制限、およびIPSEC [RFC4301]の使用に関して、リースクリープロトコルの推奨事項について説明します。
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クエリ終了
IANA has assigned the following values in the registry of DHCPv6 Message types:
IANAは、DHCPV6メッセージタイプのレジストリに次の値を割り当てました。
16 LEASEQUERY-DONE 17 LEASEQUERY-DATA
16リースクリードーン17リースクリーダタ
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.
この文書のアイデアの多くは、もともとキム・キニア、リチャード・ジョンソン、ヘマント・シン、オール・トローン、バーニー・ヴォルツによって提案されました。John Brzozowski、Marcus Goller、Alfred Hoenes、Ted Lemon、Bud Millwood、Thomas Nartenなど、DHCワーキンググループの参加者によって、さらなる提案と改善が行われました。
[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の動的ホスト構成プロトコル」、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、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006.
[RFC4649] Volz、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.、Kinnear、K.、Volz、B。、およびS. Zeng、「DHCPV6リースクリー」、RFC 5007、2007年9月。
[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月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
[RFC4614] Duke、M.、Braden、R.、Eddy、W。、およびE. Blanton、「伝送制御プロトコル（TCP）仕様文書のロードマップ」、RFC 4614、2006年9月。
Author's Address
著者の連絡先
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Mark Stapp Cisco Systems、Inc。1414 Massachusetts Ave. Boxborough、MA 01719 USA
Phone: +1 978 936 0000
EMail: mjs@cisco.com