RFC5007 日本語訳
5007 DHCPv6 Leasequery. J. Brzozowski, K. Kinnear, B. Volz, S. Zeng. September 2007. (Format: TXT=47186 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Brzozowski
Request for Comments: 5007 Comcast Cable
Category: Standards Track K. Kinnear
B. Volz
S. Zeng
Cisco Systems, Inc.
September 2007
Brzozowskiがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5007年のコムキャストケーブルカテゴリ: 標準化過程K.キネアB.フォルツS.ZengシスコシステムズInc.2007年9月
DHCPv6 Leasequery
DHCPv6 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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies a leasequery exchange for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) that can be used to obtain lease information about DHCPv6 clients from a DHCPv6 server. This document specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. This document extends DHCPv6.
このドキュメントはDHCPv6サーバからDHCPv6クライアントのリース情報を得るのに使用できるIPv6(DHCPv6)にDynamic Host Configuration Protocolへのleasequery交換を指定します。このドキュメントはDHCPv6 leasequery要請者とサーバの振舞いの両方と同様に検索できるデータの範囲を指定します。 このドキュメントはDHCPv6を広げています。
Brzozowski, et al. Standards Track [Page 1] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. On-Demand Query . . . . . . . . . . . . . . . . . . . . . 4
3.2. Anticipatory Query . . . . . . . . . . . . . . . . . . . . 5
3.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Message and Option Definitions . . . . . . . . . . . . . . 6
4.1.1. Messages . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 12
4.1.4. Transmission and Retransmission Parameters . . . . . . 12
4.2. Message Validation . . . . . . . . . . . . . . . . . . . . 12
4.2.1. LEASEQUERY . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2. LEASEQUERY-REPLY . . . . . . . . . . . . . . . . . . . 13
4.3. DHCPv6 Leasequery Requestor Behavior . . . . . . . . . . . 13
4.3.1. Creation of LEASEQUERY . . . . . . . . . . . . . . . . 13
4.3.2. Transmission of LEASEQUERY . . . . . . . . . . . . . . 13
4.3.3. Receipt of LEASEQUERY-REPLY . . . . . . . . . . . . . 14
4.3.4. Handling DHCPv6 Client Data from Multiple Sources . . 15
4.4. DHCPv6 Leasequery Server Behavior . . . . . . . . . . . . 16
4.4.1. Receipt of LEASEQUERY Messages . . . . . . . . . . . . 16
4.4.2. Constructing the Client's OPTION_CLIENT_DATA . . . . . 17
4.4.3. Transmission of LEASEQUERY-REPLY Messages . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 概要. . . . . . . . . . . . . . . . . . . . . . 4 3.1について議定書の中で述べてください。 要求次第の質問. . . . . . . . . . . . . . . . . . . . . 4 3.2。 予期的な質問. . . . . . . . . . . . . . . . . . . . 5 3.3。 タイプ. . . . . . . . . . . . . . . . . . . . . . . 5 4について質問してください。 詳細. . . . . . . . . . . . . . . . . . . . . . . 6 4.1について議定書の中で述べてください。 メッセージとオプション定義. . . . . . . . . . . . . . 6 4.1.1。 メッセージ. . . . . . . . . . . . . . . . . . . . . . . 6 4.1.2。 オプション. . . . . . . . . . . . . . . . . . . . . . . 6 4.1.3。 ステータスコード. . . . . . . . . . . . . . . . . . . . . 12 4.1.4。 トランスミッションとRetransmissionパラメタ. . . . . . 12 4.2。 メッセージ合法化. . . . . . . . . . . . . . . . . . . . 12 4.2.1。 LEASEQUERY. . . . . . . . . . . . . . . . . . . . . . 12 4.2.2。 LEASEQUERY-回答.134.3。 DHCPv6 Leasequery要請者の振舞い. . . . . . . . . . . 13 4.3.1。 LEASEQUERY. . . . . . . . . . . . . . . . 13 4.3.2の作成。 LEASEQUERY. . . . . . . . . . . . . . 13 4.3.3の送信。 領収書、.144.3は.4にLEASEQUERY返答します。 .154.4に複数のソースからのDHCPv6クライアントデータを扱います。 DHCPv6 Leasequeryサーバの振舞い. . . . . . . . . . . . 16 4.4.1。 LEASEQUERYメッセージ. . . . . . . . . . . . 16 4.4.2の領収書。 クライアントのオプション_クライアント_データ. . . . . 17 4.4.3を構成します。 LEASEQUERY-応答メッセージ.175の送信。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 17 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 19 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 20 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 20 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 20
Brzozowski, et al. Standards Track [Page 2] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[2ページ]。
1. Introduction
1. 序論
The DHCPv6 [2] protocol specifies a mechanism for the assignment of both IPv6 address and configuration information to IPv6 nodes. IPv6 Prefix Options for DHCPv6 [4] specifies a mechanism for the automated delegation of IPv6 prefixes and related options. Similar to DHCPv4 [5], DHCPv6 servers maintain authoritative information related to their operations including, but not limited to, lease information for IPv6 addresses and delegated prefixes.
DHCPv6[2]プロトコルはIPv6アドレスと設定情報のIPv6ノードへの両方の課題にメカニズムを指定します。 DHCPv6[4]のためのIPv6 Prefix OptionsはIPv6接頭語と関連するオプションの自動化された委譲にメカニズムを指定します。 DHCPv4[5]と同様です、DHCPv6サーバは彼らの操作に関係づけられて、包含、他がIPv6アドレスと代表として派遣された接頭語のために情報を賃貸するという信頼できる情報を維持します。
The requirement exists in various types of IPv6 deployments, particularly those of a broadband variety, to leverage DHCPv6 [2] for retrieving data related to the operation of DHCPv6 servers programmatically. In particular, it is desirable to be able to extract lease information about IPv6 addresses and delegated prefixes assigned using DHCPv6 [2] [4]. Specific examples where this information has illustrated value are in broadband networks to facilitate access control by edge devices. This capability to programmatically extract lease data from the DHCPv6 server is called leasequery.
要件は様々なタイプのIPv6展開で存在しています、特に広帯域のバラエティーのもの、プログラムに基づいてDHCPv6サーバの操作に関連するデータを検索するためのてこの作用DHCPv6[2]に。 DHCPv6[2][4]を使用することで割り当てられたIPv6アドレスと代表として派遣された接頭語のリース情報を抜粋できるのは特に、望ましいです。 エッジデバイスでアクセスコントロールを容易にするために、広帯域ネットワークにはこの情報が値を例証した特定の例があります。 DHCPv6サーバからリースデータをプログラムに基づいて抜粋するこの能力はleasequeryと呼ばれます。
The leasequery capability described in this document parallels the DHCPv4 leasequery capability documented in [3]. As such, it shares the basic motivations, background, design goals and constraints as described in [3]. Differences are due to the differences between IPv4 and IPv6 and by extension, DHCPv4 and DHCPv6. For example, Neighbor Discovery [7] is used in IPv6 instead of the Address Resolution Protocol (ARP) [8] (Section 4.1 of [3]) and DOCSIS 3.0 [11] defines IPv6 support for cable modem environments.
本書では説明されたleasequery能力は[3]に記録されたDHCPv4 leasequery能力に沿います。 そういうものとして、それは[3]で説明されるように基本的な動機、バックグラウンド、デザイン目標、および規制を共有します。 違いはIPv4とIPv6、拡大、DHCPv4、およびDHCPv6による違いのためです。 例えば、Neighborディスカバリー[7]はAddress Resolutionプロトコル(ARP)[8]の代わりにIPv6で使用されます。([3])とDOCSIS3.0[11]のセクション4.1はケーブルモデム環境のIPv6サポートを定義します。
2. Terminology
2. 用語
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 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか?
DHCPv6 terminology is defined in [2]. Terminology specific to DHCPv6 leasequery can be found below:
DHCPv6用語は[2]で定義されます。 以下でDHCPv6 leasequeryに特定の用語を見つけることができます:
access concentrator
An access concentrator is a router or switch at the
broadband access provider's edge of a public
broadband access network. This document assumes that
the access concentrator includes the DHCPv6 relay
agent functionality.
アクセス集中装置Anアクセス集中装置は、広帯域アクセスプロバイダーの公立の広帯域アクセスネットワークの縁のルータかスイッチです。 このドキュメントは、アクセス集中装置がDHCPv6中継エージェントの機能性を含んでいると仮定します。
Brzozowski, et al. Standards Track [Page 3] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[3ページ]。
client(s) The nodes that have one or more bindings with a
DHCPv6 server. This does not refer to the node
issuing the LEASEQUERY unless it itself has one or
more bindings with a DHCPv6 server.
クライアント、(s) . これがするDHCPv6サーバによる1つ以上の結合を持っているノードはDHCPv6サーバでそれ自体に1つ以上の結合がない場合LEASEQUERYを発行するノードを示しません。
gleaning Gleaning is the extraction of location information
from DHCPv6 messages, as the messages are forwarded
by the DHCP relay agent function.
落ち穂拾いGleaningはDHCPv6メッセージからの位置情報の抽出です、DHCP中継エージェント機能でメッセージを転送するとき。
location information
Location information is information needed by the
access concentrator to forward traffic to a
broadband-accessible host. This information includes
knowledge of the host hardware address, the port or
virtual circuit that leads to the host, and/or the
hardware address of the intervening subscriber modem.
位置情報Location情報は広帯域にアクセスしやすいホストにトラフィックを送るためにアクセス集中装置によって必要とされた情報です。 この情報はホストに通じるホストハードウェアアドレス、ポートまたは仮想の回路に関する知識、そして/または、介入している加入者モデムのハードウェア・アドレスを含んでいます。
requestor The node that sends LEASEQUERY messages to one or
more servers to retrieve information on the bindings
for a client.
要請者、クライアントのために結合の情報を検索するために1つ以上のサーバへのメッセージをLEASEQUERYに送るノード。
3. Protocol Overview
3. プロトコル概要
The focus of this document is to extend the DHCPv6 protocol to allow processes and devices that wish to access information from a DHCPv6 server to do so in a lightweight and convenient manner. It is especially appropriate for processes and devices that already interpret DHCPv6 messages.
このドキュメントの焦点は、DHCPv6サーバから情報にアクセスしたがっているプロセスとデバイスが軽量の、そして、便利な方法でそうするのを許容するためにDHCPv6プロトコルを広げることになっています。 既にDHCPv6メッセージの機械言語に翻訳処理をするプロセスとデバイスに、それは特に適切です。
The LEASEQUERY message is a query message only and does not affect the state of the IPv6 address or prefix, or the binding information associated with it.
LEASEQUERYメッセージは、質問メッセージ専用であり、IPv6アドレスか接頭語の事情、またはそれに関連している拘束力がある情報に影響しません。
One important motivating example is that the LEASEQUERY message allows access concentrators to query DHCP servers to obtain location information of broadband access network devices. This is described in Section 1 of [3] for IPv4.
1つの重要な動機づけている例はアクセス集中装置が広帯域アクセスネットワークデバイスに関する位置情報を得るためにLEASEQUERYメッセージでDHCPサーバについて質問できるということです。 これはIPv4のための[3]のセクション1で説明されます。
3.1. On-Demand Query
3.1. 要求次第の質問
The on-demand leasequery capability allows requesting just the information necessary to satisfy an immediate need. If the requestor is an access concentrator, then the immediate need will typically be that it has received an IPv6 packet and it needs to refresh its information concerning the DHCPv6 client to which that IPv6 address is currently leased. In this case, the request will be by address. This fits clearly into the single request/response cycle common to other DHCPv6 message exchanges.
要求次第のleasequery能力は、即座の需要を満たすようまさしく必要情報に要求するのを許容します。 要請者がアクセス集中装置であるなら、即座の必要性は通常ことになるでしょうIPv6パケットを受けて、そのIPv6アドレスが現在賃貸されるDHCPv6クライアントに関して情報をリフレッシュするのが必要であるという。 この場合、要求がアドレスであるでしょう。 これは明確に他のDHCPv6交換処理に共通のただ一つの要求/応答サイクルに収まります。
Brzozowski, et al. Standards Track [Page 4] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[4ページ]。
However, this approach has limitations when used with prefix delegation [4] as no traffic may arrive because the access concentrator is unable to inject the appropriate routing information into the routing infrastructure, such as after a reboot. This approach does work if the access concentrator is configured to inject routing information for a prefix that aggregates potentially delegated prefixes. Or, it also works if the access concentrator and requesting router use a routing protocol; as then the requesting router can trigger the access concentrator to request information from a DHCPv6 server and inject appropriate routing information into the routing infrastructure.
しかしながら、このアプローチには、アクセス集中装置が適切なルーティング情報をルーティングインフラストラクチャに注ぐことができないのでトラフィックが全く到着しないかもしれないので接頭語委譲[4]と共に使用されると、制限があります、リブートなどの後のように。 アクセス集中装置が接頭語のための集合が潜在的に接頭語を代表として派遣したというルーティング情報を注入するために構成されるなら、このアプローチは働いています。 または、また、アクセス集中装置と要求ルータがルーティング・プロトコルを使用するなら、働いています。 次に、要求ルータがDHCPv6サーバから要求情報にアクセス集中装置の引き金となって、注入されることができるように、ルーティング情報をルーティングインフラストラクチャに当ててください。
3.2. Anticipatory Query
3.2. 予期的な質問
A second approach for requesting information from a DHCPv6 server would be to use a leasequery-like capability to rebuild an internal data store containing information available from a DHCPv6 server. The rebuilding of the data store in this approach can take place as soon as possible after the need to rebuild it is discovered (such as on booting), and doesn't wait on the receipt of specific packets to trigger a piecemeal database update (as is the case for on-demand leasequery). This approach would also remove the limitation discussed above for prefix delegation.
DHCPv6サーバから情報を要求するための2番目のアプローチはDHCPv6サーバから利用可能な情報を含む内部のデータ・ストアを再建するleasequeryのような能力を使用するだろうことです。このアプローチにおける、データ・ストアの再建は、再建する必要性の後にできるだけ早くそれが発見される場所(穂ばらみなどの)を取ることができて、特定のパケットの領収書の上でばらばらのデータベース更新の引き金となるのを待っていません(要求次第のleasequeryのためにそうであるように)。 また、このアプローチは接頭語委譲のために上で議論した制限を取り除くでしょう。
This anticipatory query is not specified in this document and is an area of future work.
この予期的な質問は、本書では指定されないで、今後の活動の領域です。
3.3. Query Types
3.3. 質問タイプ
Leasequery provides for the following queries:
Leasequeryは以下の質問に備えます:
Query by IPv6 address - This query allows a requestor to request
from a server the bindings for a client that either is bound to
the address or has been delegated the prefix that contains the
address.
IPv6で、アドレスについて質問してください--要請者はアドレスに縛られるか、または代表として派遣されたクライアントのためにこの質問からサーバから結合を要求できます。アドレスを含む接頭語。
Query by Client Identifier (DUID) - This query allows a requestor to
request from a server the bindings for a specific client on a
specific link or a list of the links on which the client has one
or more bindings.
Client Identifierで、(DUID)について質問してください--この質問で、要請者は特定のクライアントのためにクライアントが1つ以上の結合を持っているリンクの特定のリンクかリストでサーバから結合を要求できます。
Brzozowski, et al. Standards Track [Page 5] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[5ページ]。
4. Protocol Details
4. プロトコルの詳細
4.1. Message and Option Definitions
4.1. メッセージとオプション定義
4.1.1. Messages
4.1.1. メッセージ
The LEASEQUERY and LEASEQUERY-REPLY messages use the Client/Server message formats described in [2], Section 6. Two new message codes are defined:
LEASEQUERYとLEASEQUERY-REPLYメッセージは[2]、セクション6で説明されたClient/サーバメッセージ・フォーマットを使用します。 2つの新しいメッセージコードが定義されます:
LEASEQUERY (14) - A requestor sends a LEASEQUERY message to any
available server to obtain information on a client's leases. The
options in an OPTION_LQ_QUERY determine the query.
LEASEQUERY(14)--要請者は、クライアントのリースの情報を得るためにどんな利用可能なサーバにもLEASEQUERYメッセージを送ります。 OPTION_LQ_QUERYのオプションは質問を決定します。
LEASEQUERY-REPLY (15) - A server sends a LEASEQUERY-REPLY message
containing client data in response to a LEASEQUERY message.
LEASEQUERY-REPLY(15)--サーバはLEASEQUERYメッセージに対応してクライアントデータを含むLEASEQUERY-REPLYメッセージを送ります。
4.1.2. Options
4.1.2. オプション
4.1.2.1. Query Option
4.1.2.1. 質問オプション
The Query option is used only in a LEASEQUERY message and identifies the query being performed. The option includes the query type, link- address (or 0::0), and option(s) to provide data needed for the query.
Queryオプションは、LEASEQUERYメッセージだけで使用されて、実行される質問を特定します。 または、オプションが質問タイプ、リンクアドレスを含んでいる、(0: : 0) そして、質問に必要であるデータを提供するオプション。
The format of the Query option is shown below:
Queryオプションの書式は以下に示されます:
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_LQ_QUERY | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-type | |
+-+-+-+-+-+-+-+-+ |
| |
| link-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | .
+-+-+-+-+-+-+-+-+ .
. query-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション_LQ_質問| オプション-len| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 質問タイプ| | +-+-+-+-+-+-+-+-+ | | | | リンクアドレス| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . +++++++++、…+++++++++++++++++++++++++++++++++を質問してゆだねます。
option-code OPTION_LQ_QUERY (44)
オプションコードOPTION_LQ_QUERY(44)
option-len 17 + length of query-options field.
質問オプションの17+長さがさばくオプション-len。
Brzozowski, et al. Standards Track [Page 6] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[6ページ]。
link-address A global address that will be used by the
server to identify the link to which the
query applies, or 0::0 if unspecified.
サーバによって使用される、質問が適用されるリンクを特定するリンクアドレスAグローバルアドレス、または0:、:0 不特定です。
query-type The query requested (see below).
質問が要求した(以下を見ます)質問タイプ。
query-options The options related to the query.
オプションが質問に関係づけた質問オプション。
The query-type and required query-options are:
質問タイプと必要な質問オプションは以下の通りです。
QUERY_BY_ADDRESS (1) - The query-options MUST contain an
OPTION_IAADDR option [2]. The link-address field, if not 0::0,
specifies an address for the link on which the client is located
if the address in the OPTION_IAADDR option is of insufficient
scope. Only the information for the client that has a lease for
the specified address or was delegated a prefix that contains the
specified address is returned (if available).
QUERY_BY_ADDRESS(1)--質問オプションはOPTION_IAADDRオプション[2]を含まなければなりません。 まして、リンクアドレス分野、0:、:0 クライアントがOPTION_IAADDRオプションにおけるアドレスが不十分な範囲のものであるなら見つけられているリンクへのアドレスを指定します。 クライアントへの指定されたアドレスのためのリースを持っているか、代表として派遣して、指定されたアドレスを含む接頭語を返すという(利用可能であるなら)ことであった唯一の情報。
QUERY_BY_CLIENTID (2) - The query-options MUST contain an
OPTION_CLIENTID option [2]. The link-address field, if not 0::0,
specifies an address for the link on which the client is located.
If the link-address field is 0::0, the server SHOULD search all of
its links for the client.
QUERY_BY_CLIENTID(2)--質問オプションはOPTION_CLIENTIDオプション[2]を含まなければなりません。 まして、リンクアドレス分野、0:、:0 クライアントが見つけられているリンクへのアドレスを指定します。 以下のこと、リンクアドレス分野が0であるなら:0 サーバSHOULDはクライアントのためにリンクのすべてを捜します。
The query-options MAY also include an OPTION_ORO option [2] to indicate the options for each client that the requestor would like the server to return. Note that this OPTION_ORO is distinct and separate from an OPTION_ORO that may be in the requestor's LEASEQUERY message.
また、質問オプションは、要請者が、サーバに返して欲しい各クライアントのためにオプションを示すためにOPTION_OROオプション[2]を含むかもしれません。 このOPTION_OROが要請者のLEASEQUERYメッセージにあるかもしれないOPTION_OROから異なって別々であることに注意してください。
If a server receives an OPTION_LQ_QUERY with a query-type it does not support, the server SHOULD return an UnknownQueryType status-code. If a server receives a supported query-type but the query-options is missing a required option, the server SHOULD return a MalformedQuery status-code.
サーバがそれがサポートしない質問タイプでOPTION_LQ_QUERYを受けるなら、サーバSHOULDはUnknownQueryTypeステータスコードを返します。 サーバがサポートしている質問タイプを受けるか、しかし、オプションについて質問するのは必要なオプション(SHOULDがMalformedQueryステータスコードを返すサーバ)を逃しています。
Brzozowski, et al. Standards Track [Page 7] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[7ページ]。
4.1.2.2. Client Data Option
4.1.2.2. クライアントデータオプション
The Client Data option is used to encapsulate the data for a single client on a single link in a LEASEQUERY-REPLY message.
Client Dataオプションは、独身のクライアントのためにLEASEQUERY-REPLYメッセージの単一のリンクの上にデータをカプセル化するのに使用されます。
The format of the Client Data option is shown below:
Client Dataオプションの書式は以下に示されます:
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_CLIENT_DATA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. client-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション_クライアント_データ| オプション-len| クライアント..オプション
option-code OPTION_CLIENT_DATA (45)
オプションコードOPTION_CLIENT_DATA(45)
option-len Length, in octets, of the encapsulated client-
options field.
カプセル化されたクライアントオプション分野の八重奏におけるオプション-len Length。
client-options The options associated with this client.
オプションがこのクライアントに関連づけたクライアントオプション。
The encapsulated client-options include the OPTION_CLIENTID, OPTION_IAADDR, OPTION_IAPREFIX, and OPTION_CLT_TIME options and other options specific to the client and requested by the requestor in the OPTION_ORO in the OPTION_LQ_QUERY's query-options. The server MUST return all of the client's statefully assigned addresses and delegated prefixes, with a non-zero valid lifetime, on the link.
_カプセル化されたクライアントオプションはOPTION_CLIENTID、OPTION_IAADDR、OPTION_IAPREFIX、OPTION_CLT_タイム誌のオプション、およびクライアントにとって、特定の別の選択肢を含んでいます、そして、OPTIONのOPTION_OROで要請者によって要求されていて、LQ_QUERYはオプションについて質問します。 サーバはクライアントのstatefully割り当てられたアドレスと代表として派遣された接頭語のすべてを返さなければなりません、非ゼロの有効な生涯で、リンクの上に。
Brzozowski, et al. Standards Track [Page 8] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[8ページ]。
4.1.2.3. Client Last Transaction Time Option
4.1.2.3. クライアントはトランザクション時間オプションが続きます。
The Client Last Transaction Time option is encapsulated in an OPTION_CLIENT_DATA and identifies how long ago the server last communicated with the client, in seconds.
Client Last Transaction Timeオプションは、OPTION_CLIENT_DATAでカプセル化されて、サーバが最後にどれくらい昔にクライアントとコミュニケートしたかを特定します、秒に。
The format of the Client Last Transaction Time option is shown below:
Client Last Transaction Timeオプションの書式は以下に示されます:
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_CLT_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client-last-transaction-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション_CLT_時間| オプション-len| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントはトランザクション時間続きます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLT_TIME (46)
オプションコードOPTION_CLT_タイム誌(46)
option-len 4
オプション-len4
client-last-transaction-time
The number of seconds since the server last
communicated with the client (on that link).
クライアントはトランザクション時間続きます。サーバが持続するので、秒数はクライアント(そのリンクの)とコミュニケートしました。
The client-last-transaction-time is a positive value and reflects the number of seconds since the server last communicated with the client (on that link).
サーバが最後にクライアント(そのリンクの)とコミュニケートしたので、最後のトランザクション時間のクライアントは、正の数であり、秒数を反映します。
Brzozowski, et al. Standards Track [Page 9] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[9ページ]。
4.1.2.4. Relay Data
4.1.2.4. リレーデータ
The Relay Data option is used only in a LEASEQUERY-REPLY message and provides the relay agent information used when the client last communicated with the server.
Relay Dataオプションは、LEASEQUERY-REPLYメッセージだけで使用されて、クライアントが最後にサーバとコミュニケートしたとき使用される中継エージェント情報を提供します。
The format of the Relay Data option is shown below:
Relay Dataオプションの書式は以下に示されます:
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_LQ_RELAY_DATA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| peer-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DHCP-relay-message |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション_LQ_リレー_データ| オプション-len| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 同輩アドレス(IPv6アドレス)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DHCPリレーメッセージ| . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_RELAY_DATA (47)
オプションコードOPTION_LQ_RELAY_DATA(47)
option-len 16 + length of DHCP-relay-message.
DHCPリレーメッセージのオプション-lenの16+長さ。
peer-address The address of the relay agent from which
the relayed message was received by the
server.
リレーされたメッセージがサーバによって受け取られた中継エージェントのアドレスを同輩と同じくらい扱ってください。
DHCP-relay-message
The last complete relayed message, excluding
the client's message OPTION_RELAY_MSG,
received by the server.
最後の完全なリレーされたメッセージがクライアントのメッセージOPTION_RELAY_MSGを除いてサーバで受け取ったDHCPリレーメッセージ。
This option is used by the server to return full relay agent information for a client. It MUST NOT be returned if the server does not have such information, either because the client communicated directly (without relay agent) with the server or if the server did not retain such information.
このオプションはサーバによって使用されて、クライアントのために完全な中継エージェント情報を返します。 サーバにそのような情報がないなら、それを返してはいけません、クライアントがサーバと共に直接伝達したか(中継エージェントなしで)、またはサーバがそのような情報を保有しなかったなら。
If returned, the DHCP-relay-message MUST contain a valid (perhaps multi-hop) RELAY-FORW message as the most recently received by the server for the client. However, the (innermost) OPTION_RELAY_MSG option containing the client's message MUST have been removed.
返すなら、DHCPリレーメッセージは最も最近クライアントのためにサーバで受け取るように有効な(恐らくマルチホップ)RELAY-FORWメッセージを含まなければなりません。 しかしながら、クライアントのメッセージを含む(最も奥深い)のOPTION_RELAY_MSGオプションを取り除いたに違いありません。
Brzozowski, et al. Standards Track [Page 10] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[10ページ]。
This option SHOULD only be returned if requested by the OPTION_ORO of the OPTION_LQ_QUERY.
これはSHOULDにゆだねます。OPTION_LQ_QUERYのOPTION_OROが要求する場合にだけ、返します。
4.1.2.5. Client Link Option
4.1.2.5. クライアントリンクオプション
The Client Link option is used only in a LEASEQUERY-REPLY message and identifies the links on which the client has one or more bindings. It is used in reply to a query when no link-address was specified and the client is found to be on more than one link.
Client Linkオプションは、LEASEQUERY-REPLYメッセージだけで使用されて、クライアントが1つ以上の結合を持っているリンクを特定します。 それはリンクアドレスが全く指定されないで、クライアントがオンであることがわかっているときの質問に対する中古の1個以上のリンクです。
The format of the Client Link option is shown below:
Client Linkオプションの書式は以下に示されます:
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_LQ_CLIENT_LINK | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション_LQ_クライアント_リンク| オプション-len| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | リンクアドレス(IPv6アドレス)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | リンクアドレス(IPv6アドレス)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_CLIENT_LINK (48)
オプションコードOPTION_LQ_CLIENT_LINK(48)
option-len Length of the list of links in octets;
must be a multiple of 16.
八重奏におけるリンクのリストのオプション-len Length。 16の倍数はそうであるに違いありませんか?
link-address A global address used by the server to
identify the link on which the client is
located.
サーバによって使用される、クライアントが見つけられているリンクを特定するリンクアドレスAグローバルアドレス。
A server may respond to a query by client-id, where the 0::0 link- address was specified, with this option if the client is found to be on multiple links. The requestor may then repeat the query once for each link-address returned in the list, specifying the returned link- address. If the client is on a single link, the server SHOULD return the client's data in an OPTION_CLIENT_DATA option.
サーバがaに反応するかもしれないAはクライアントイド、どこで0について質問するか:、:0 リンクアドレスは指定されて、クライアントがオンであることがわかっているなら、このオプションに、倍数はリンクされます。 そして、要請者は返されたリンクアドレスを指定して、リストで返された各リンクアドレスのために一度質問を繰り返すかもしれません。 クライアントが単一のリンクの上にいるなら、サーバSHOULDはOPTION_CLIENT_DATAオプションにおけるクライアントのデータを返します。
Brzozowski, et al. Standards Track [Page 11] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[11ページ]。
4.1.3. Status Codes
4.1.3. ステータスコード
The following new status codes are defined:
以下の新しいステータスコードは定義されます:
UnknownQueryType (7) - The query-type is unknown to or not supported
by the server.
UnknownQueryType(7)--質問タイプは、サーバによって未知かサポートされません。
MalformedQuery (8) - The query is not valid; for example, a required
query-option is missing from the OPTION_LQ_QUERY.
MalformedQuery(8)--質問は有効ではありません。 例えば、必要な質問オプションはOPTION_LQ_QUERYからなくなっています。
NotConfigured (9) - The server does not have the target address or
link in its configuration.
NotConfigured(9)--サーバは、あて先アドレスを持ってもいませんし、構成でリンクもされません。
NotAllowed (10) - The server does not allow the requestor to issue
this LEASEQUERY.
NotAllowed(10)--サーバで、要請者はこのLEASEQUERYを発行できません。
4.1.4. Transmission and Retransmission Parameters
4.1.4. トランスミッションとRetransmissionパラメタ
This section presents a table of values used to describe the message transmission behavior for leasequery.
このセクションはleasequeryのためにメッセージトランスミッションの振舞いについて説明するのに使用される値のテーブルを寄贈します。
Parameter Default Description ---------------------------------- LQ_TIMEOUT 1 sec Initial LEASEQUERY timeout LQ_MAX_RT 10 secs Max LEASEQUERY timeout value LQ_MAX_RC 5 Max LEASEQUERY retry attempts
パラメタデフォルト記述---------------------------------- MAX_RC5マックスのLEASEQUERY再試行が試みる1秒の間のLQ_TIMEOUT Initial LEASEQUERYタイムアウトLQ_MAX_RT10秒のマックスLEASEQUERYタイムアウト値のLQ_
4.2. Message Validation
4.2. メッセージ合法化
4.2.1. LEASEQUERY
4.2.1. LEASEQUERY
Requestors and clients MUST discard any received LEASEQUERY messages.
要請者とクライアントはどんな受信されたLEASEQUERYメッセージも捨てなければなりません。
Servers MUST discard any received LEASEQUERY messages that meet any of the following conditions:
サーバは以下の条件のいずれも満たすどんな受信されたLEASEQUERYメッセージも捨てなければなりません:
o the message does not include an OPTION_CLIENTID option.
o メッセージはOPTION_CLIENTIDオプションを含んでいません。
o the message includes an OPTION_SERVERID option but the contents of
the OPTION_SERVERID option does not match the server's identifier.
o メッセージはOPTION_SERVERIDオプションを含んでいますが、OPTION_SERVERIDオプションのコンテンツはサーバの識別子に合っていません。
o the message does not include an OPTION_LQ_QUERY option.
o メッセージはOPTION_LQ_QUERYオプションを含んでいません。
Brzozowski, et al. Standards Track [Page 12] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[12ページ]。
4.2.2. LEASEQUERY-REPLY
4.2.2. LEASEQUERY-回答
Requestors MUST discard any received LEASEQUERY-REPLY messages that meet any of the following conditions:
要請者は以下の条件のいずれも満たすどんな受信されたLEASEQUERY-REPLYメッセージも捨てなければなりません:
o the message does not include an OPTION_SERVERID option.
o メッセージはOPTION_SERVERIDオプションを含んでいません。
o the message does not include an OPTION_CLIENTID option, or the
contents of the OPTION_CLIENTID option do not match the DUID of
the requestor.
o メッセージがOPTION_CLIENTIDオプションを含んでいないか、またはOPTION_CLIENTIDオプションの内容は要請者のDUIDに合っていません。
o the "transaction-id" field in the message does not match the value
used in the original message.
o メッセージの「トランザクションイド」分野はオリジナルのメッセージで使用される値に合っていません。
Servers and Relay Agents (on the server port, 547 [2]) MUST discard any received LEASEQUERY-REPLY messages.
サーバとRelayエージェント、(サーバポートの上では、547[2])はどんな受信されたLEASEQUERY-REPLYメッセージも捨てなければなりません。
4.3. DHCPv6 Leasequery Requestor Behavior
4.3. DHCPv6 Leasequery要請者の振舞い
This section describes how a requestor initiates lease data retrieval from DHCPv6 servers.
このセクションは要請者がDHCPv6サーバからリースデータの検索をどう開始するかを説明します。
4.3.1. Creation of LEASEQUERY
4.3.1. LEASEQUERYの作成
The requestor sets the "msg-type" field to LEASEQUERY. The requestor generates a transaction ID and inserts this value in the "transaction-id" field.
要請者は「msg-タイプ」分野をLEASEQUERYに設定します。 要請者は「トランザクションイド」分野でトランザクションがIDであり、差し込みがこの値であると生成します。
The requestor MUST include an OPTION_CLIENTID option to identify itself to the server.
要請者は、サーバにそれ自体を特定するためにOPTION_CLIENTIDオプションを入れなければなりません。
The requestor MUST include an OPTION_LQ_QUERY option and set the query-type, link-address, and query-options as appropriate to the query-type (Section 4.1.2.1).
要請者がOPTION_LQ_QUERYオプションを入れて、適宜質問タイプ、リンクアドレス、および質問オプションを質問タイプに設定しなければならない、(セクション4.1 .2 .1)。
The requestor SHOULD include an OPTION_SERVERID if it is not unicasting the LEASEQUERY yet only wants a response from a specific server.
LEASEQUERYをunicastingしていませんが、特定のサーバから応答が欲しいだけであるなら、要請者SHOULDはOPTION_SERVERIDを含んでいます。
4.3.2. Transmission of LEASEQUERY
4.3.2. LEASEQUERYのトランスミッション
The requestor MAY be configured to use a list of destination addresses, which MAY include unicast addresses, the All_DHCP_Servers multicast address, or other addresses selected by the network administrator. If the requestor has not been explicitly configured, it MAY use the All_DHCP_Servers multicast address as the default.
要請者は、ネットワーク管理者によって選択されたユニキャストアドレス、All_DHCP_Serversマルチキャストアドレス、または他のアドレスを含むかもしれない送付先アドレスのリストを使用するために構成されるかもしれません。 要請者が明らかに構成されていないなら、それはデフォルトとしてAll_DHCP_Serversマルチキャストアドレスを使用するかもしれません。
Brzozowski, et al. Standards Track [Page 13] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[13ページ]。
The requestor SHOULD send LEASEQUERY to one or more DHCPv6 servers that are known to possess authoritative information concerning the query target.
要請者SHOULDは質問目標に関して信頼できる情報を持っているのが知られている1つ以上のDHCPv6サーバにLEASEQUERYを送ります。
In the absence of information concerning which DHCPv6 servers might possess authoritative information on the query target, the requestor SHOULD send LEASEQUERY to all DHCPv6 servers that the requestor knows about or is configured with. For example, the requestor MAY send LEASEQUERY to the All_DHCP_Servers multicast address.
DHCPv6サーバには質問目標に関する信頼できる情報があるかもしれない情報がないとき、要請者SHOULDは要請者が知っているか、または構成されるすべてのDHCPv6サーバにLEASEQUERYを送ります。 例えば、要請者はAll_DHCP_ServersマルチキャストアドレスにLEASEQUERYを送るかもしれません。
The requestor transmits LEASEQUERY messages according to Section 14 of [2], using the following parameters:
以下のパラメタを使用して、[2]のセクション14に応じて、要請者はLEASEQUERYメッセージを送ります:
IRT LQ_TIMEOUT
MRT LQ_MAX_RT
MRC LQ_MAX_RC
MRD 0
IRT LQ_タイムアウト台北新交通システムLQ_マックス_RT MRC LQ_マックス_RC MRD0
If the message exchange fails, the requestor takes an action based on the requestor's local policy. Examples of actions the requestor might take include:
交換処理が失敗するなら、要請者は要請者のローカルの方針に基づいて訴訟を起こします。 要請者が取るかもしれない行動に関する例は:
o Select another server from a list of servers known to the
requestor.
o 要請者にとって知られているサーバのリストから別のサーバを選択してください。
o Send to multiple servers by multicasting to the All_DHCP_Servers
address.
o All_DHCP_Serversアドレスへのマルチキャスティングで複数のサーバに発信してください。
o Terminate the request.
o 要求を終えてください。
4.3.3. Receipt of LEASEQUERY-REPLY
4.3.3. LEASEQUERY-回答の領収書
A successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE option (or an OPTION_STATUS_CODE option with a success code). There are three variants:
うまくいっているLEASEQUERY-REPLYはOPTION_STATUS_CODEオプション(または、成功コードによるOPTION_STATUS_CODEオプション)がなければ1歳です。 3つの異形があります:
1. If the server had bindings for the requested client, the message
includes an OPTION_CLIENT_DATA option and the requestor extracts
the client data from the LEASEQUERY-REPLY and updates its binding
information database. If the OPTION_CLIENT_DATA contains no
OPTION_CLT_TIME, the requestor SHOULD silently discard the
OPTION_CLIENT_DATA option.
1. サーバに要求されたクライアントのための結合があったなら、メッセージがOPTION_CLIENT_DATAオプションを含んでいて、要請者は、LEASEQUERY-REPLYからクライアントデータを抜粋して、拘束力がある情報データベースをアップデートします。 OPTION_CLIENT_DATAがOPTION_CLT_タイム誌を全く含まないなら、要請者SHOULDは静かにOPTION_CLIENT_DATAオプションを捨てます。
2. If the server found bindings for the client on multiple links,
the message includes an OPTION_CLIENT_LINK option. The requestor
will need to reissue LEASEQUERY messages using each of the
returned link-addresses to obtain the client's bindings.
2. サーバであるなら、複数のリンクの上のクライアントのために結合を設立してください、そして、メッセージはOPTION_CLIENT_LINKオプションを含んでいます。 要請者は、クライアントの結合を得るのにそれぞれの返されたリンクアドレスを使用することでLEASEQUERYメッセージを再発行する必要があるでしょう。
Brzozowski, et al. Standards Track [Page 14] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[14ページ]。
3. If the server had no bindings for the client, neither the
OPTION_CLIENT_DATA nor OPTION_CLIENT_LINK option will be present.
3. サーバにクライアントのための結合が全くなかったなら、OPTION_CLIENT_DATAもOPTION_CLIENT_LINKオプションも存在しないでしょう。
An unsuccessful LEASEQUERY-REPLY is one that has an OPTION_STATUS_CODE with an error code. Depending on the status code, the requestor may try a different server (such as for NotAllowed, NotConfigured, and UnknownQueryType), try a different or corrected query (such as for UnknownQueryType and MalformedQuery), or terminate the query.
失敗のLEASEQUERY-REPLYはOPTION_STATUS_CODEがエラーコードと共にあるものです。 要請者は異なったサーバ(NotAllowedや、NotConfiguredや、UnknownQueryTypeなどの)を試みるか、異なったか直っている質問(UnknownQueryTypeやMalformedQueryなどの)を試みるか、または質問を終えて、ステータスコードによるかもしれません。
4.3.4. Handling DHCPv6 Client Data from Multiple Sources
4.3.4. 複数のソースからの取り扱いDHCPv6クライアントデータ
A requestor may receive lease data on the same client from the same DHCPv6 server in response to different types of LEASEQUERY. If a LEASEQUERY is sent to multiple servers, the requestor may receive from several servers lease data on the same DHCPv6 client. This section describes how the requestor handles multiple lease data sources on the same DHCPv6 client from the same server or different servers.
要請者はLEASEQUERYの異なったタイプに対応して同じDHCPv6サーバから同じクライアントに関するリースデータを受け取るかもしれません。 複数のサーバにLEASEQUERYを送るなら、要請者は同じDHCPv6クライアントに関するいくつかのサーバリースデータから受信するかもしれません。 このセクションは要請者が同じサーバか異なったサーバから同じDHCPv6クライアントの上の複数のリースデータ送信端末をどう扱うかを説明します。
The client data from the different sources may be disjoint or overlapping. The disjoint and overlapping relationship can happen between data from the same server or different servers.
さまざまな原因からのクライアントデータは、ばらばらになることであるかもしれないか重なっています。 ばらばらになってください。そうすれば、関係を重ね合わせるのはデータの間で同じサーバか異なったサーバから起こることができます。
If client data from two sources on the same client are of different types or values, then the data are disjoint. An example of data of different types is when a requestor receives an IPv6 address lease from one server and a prefix lease from another server, both assigned to the same client. An example of different values (but the same type) is when a requestor receives two IPv6 address leases from two different servers, both assigned to the same client, but the leases are on two different IPv6 addresses. If the requestor receives disjoint client data from different sources, it SHOULD merge them.
同じクライアントの上の2つのソースからのクライアントデータに異なったタイプか値があるなら、データはそうです。ばらばらになってください。 異なったタイプに関するデータに関する例は要請者が1つのサーバと接頭語リースから別のサーバからIPv6アドレスリースを受ける時です、同じクライアントに割り当てられた両方。 異価(しかし、同じタイプ)に関する例は要請者がともに同じクライアントに割り当てられた2つの異なったサーバから2つのIPv6アドレスリースを受ける時ですが、リースが2つの異なったIPv6アドレスにあります。 要請者が受信するならさまざまな原因からのクライアントデータをばらばらにならせてください、それ、SHOULDは彼らを合併します。
If client data from two sources on the same client are of the same type and value, then the data are overlapping. An example of overlapping data is when a requestor receives a lease on the same IPv6 address from two different servers. Overlapping client data are also called conflicting data.
同じクライアントの上の2つのソースからのクライアントデータに同じタイプと価値があるなら、データは重なっています。 重なっているデータに関する例は要請者が同じIPv6アドレスで2つの異なったサーバからリースを受ける時です。 また、重なっているクライアントデータは闘争データと呼ばれます。
The requestor SHOULD use the OPTION_CLT_TIME to resolve data conflicts originated from different servers, and SHOULD accept data with most recent OPTION_CLT_TIME.
要請者SHOULDはデータ闘争が異なったサーバから発したと決議するのにOPTION_CLT_タイム誌を使用します、そして、SHOULDは最新の_OPTION_CLTタイム誌と共にデータを受け入れます。
Brzozowski, et al. Standards Track [Page 15] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[15ページ]。
4.4. DHCPv6 Leasequery Server Behavior
4.4. DHCPv6 Leasequeryサーバの振舞い
A DHCPv6 server sends LEASEQUERY-REPLY messages in response to valid LEASEQUERY messages it receives to return the statefully assigned addresses, delegated prefixes, and other information that match the query.
DHCPv6サーバは質問に合っているそれがstatefully割り当てられたアドレスを返すために受け取る有効なLEASEQUERYメッセージ、代表として派遣された接頭語、および他の情報に対応してメッセージをLEASEQUERY-REPLYに送ります。
4.4.1. Receipt of LEASEQUERY Messages
4.4.1. LEASEQUERYメッセージの領収書
Upon receipt of a valid LEASEQUERY message, the DHCPv6 server locates the requested client, collects data on the client, and constructs and returns a LEASEQUERY-REPLY. A LEASEQUERY message cannot be used to assign, release, or otherwise modify bindings or other configuration information.
有効なLEASEQUERYメッセージを受け取り次第、DHCPv6サーバは、LEASEQUERY-REPLYを要求されたクライアントの居場所を見つけて、データをクライアントに集めて、組み立てて、返します。 結合か他の設定情報を割り当てるか、発表するか、またはそうでなければ、変更するのにLEASEQUERYメッセージを使用できません。
The server constructs a LEASEQUERY-REPLY message by setting the "msg- type" field to LEASEQUERY-REPLY, and copying the transaction ID from the LEASEQUERY message into the transaction-id field.
サーバは、「msgタイプ」分野をLEASEQUERY-REPLYに設定して、LEASEQUERYメッセージからトランザクションイド分野にトランザクションIDをコピーすることによって、LEASEQUERY-REPLYメッセージを構成します。
If the query-type in the OPTION_LQ_QUERY option is not a known or supported value, the server adds an OPTION_STATUS_CODE option with the UnknownQueryType status code and sends the LEASEQUERY-REPLY to the requestor. If the query-options do not contain the required options for the query-type, the server adds an OPTION_STATUS_CODE option with the MalformedQuery status code and sends the LEASEQUERY- REPLY to the client.
OPTION_LQ_QUERYオプションにおける質問タイプが知られているかサポートしている値でないなら、サーバは、UnknownQueryTypeステータスコードでOPTION_STATUS_CODEオプションを加えて、LEASEQUERY-REPLYを要請者に送ります。 質問オプションが質問タイプに、必要なオプションを含んでいないなら、サーバは、MalformedQueryステータスコードでOPTION_STATUS_CODEオプションを加えて、LEASEQUERY- REPLYをクライアントに送ります。
A server may also restrict LEASEQUERY messages, or query-types, to certain requestors. In this case, the server MAY discard the LEASEQUERY message or MAY add an OPTION_STATUS_CODE option with the NotAllowed status code and send the LEASEQUERY-REPLY to the requestor.
また、サーバはLEASEQUERYメッセージ、または質問タイプを確信している要請者に制限するかもしれません。 この場合、サーバは、LEASEQUERYメッセージを捨てるか、NotAllowedステータスコードでOPTION_STATUS_CODEオプションを加えて、またはLEASEQUERY-REPLYを要請者に送るかもしれません。
If the OPTION_LQ_QUERY specified a non-zero link-address, the server MUST use the link-address to find the appropriate link for the client. For a QUERY_BY_ADDRESS, if the 0::0 link-address was specified, the server uses the address from the OPTION_IAADDR option to find the appropriate link for the client. In either of these cases, if the server is unable to find the link, it SHOULD return an OPTION_STATUS_CODE option with the NotConfigured status and send the LEASEQUERY-REPLY to the requestor.
OPTION_LQ_QUERYが非ゼロリンクアドレスを指定したなら、サーバは、クライアントのために適切なリンクを見つけるのにリンクアドレスを使用しなければなりません。 aに関しては、_アドレスは0であるなら_について質問してください:、:0 リンクアドレスは指定されて、サーバは、クライアントのために適切なリンクを見つけるのにOPTION_IAADDRオプションからアドレスを使用します。 コネはどちらかこれらのケースサーバであるならリンクを見つけることができません、それ。SHOULDは_NotConfigured状態があるSTATUS_CODEオプションをOPTIONに返して、LEASEQUERY-REPLYを要請者に送ります。
For a QUERY_BY_CLIENTID, if a 0::0 link-address was specified, the server MUST search all of its links for the client. If the client is only found on a single link, the server SHOULD return that client's data in an OPTION_CLIENT_DATA option. If the client is found on more
aに関しては、_CLIENTIDはa0であるなら_について質問してください:、:0 リンクアドレスは指定されて、サーバはクライアントのためにリンクのすべてを捜さなければなりません。 クライアントが単一のリンクの上に見つけられるだけであるなら、サーバSHOULDはOPTION_CLIENT_DATAオプションにおけるそのクライアントのデータを返します。 クライアントが以上で見つけられるなら
Brzozowski, et al. Standards Track [Page 16] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[16ページ]。
than a single link, the server MUST return the list of links in the OPTION_CLIENT_LINK option; the server MUST NOT return any client data.
単一のリンク、サーバがOPTION_CLIENT_LINKオプションでリンクのリストを返さなければならないより。 サーバは少しのクライアントデータも返してはいけません。
Otherwise, the server uses the data in the OPTION_LQ_QUERY to initiate the query. The result of the query will be zero or one client. This will result in zero or one OPTION_CLIENT_DATA option being added to the LEASEQUERY-REPLY.
さもなければ、サーバは、質問を開始するのにOPTION_LQ_QUERYのデータを使用します。 質問の結果は、ゼロか1人のクライアントになるでしょう。 これはLEASEQUERY-REPLYに加えられるゼロか1つのOPTION_CLIENT_DATAオプションをもたらすでしょう。
4.4.2. Constructing the Client's OPTION_CLIENT_DATA
4.4.2. クライアントのオプション_クライアント_データを構成します。
An OPTION_CLIENT_DATA option in a LEASEQUERY-REPLY message MUST minimally contain the following options: 1. OPTION_CLIENTID 2. OPTION_IAADDR and/or OPTION_IAPREFIX 3. OPTION_CLT_TIME
LEASEQUERY-REPLYメッセージにおけるOPTION_CLIENT_DATAオプションは以下のオプションを最少量で含まなければなりません: 1. オプション_CLIENTID2。 オプション_IAADDR、そして/または、オプション_IAPREFIX3。 オプション_CLT_時間
Depending on the bindings the client has on a link, either OPTION_IAADDR options, OPTION_IAPREFIX options, or both may be present.
クライアントがリンク、どちらのOPTION_IAADDRオプションのときにも持っている結合によるか、OPTION_IAPREFIXオプション、または両方が存在しているかもしれません。
The OPTION_CLIENT_DATA SHOULD include options requested in the OPTION_ORO of the OPTION_LQ_QUERY option in the LEASEQUERY message and that are acceptable to return based on the list of "sensitive options", discussed below.
OPTION_CLIENT_DATA SHOULDはLEASEQUERYメッセージにおけるOPTION_LQ_QUERYオプションのOPTION_OROで要求された以下で議論した「敏感なオプション」のリストに基づいて戻るのにおいて許容できるオプションを含んでいます。
DHCPv6 servers SHOULD be configurable with a list of "sensitive options" that must not be returned to the requestor when specified in the OPTION_ORO of the OPTION_LQ_QUERY option in the LEASEQUERY message. Any option on this list MUST NOT be returned to a requestor, even if requested by that requestor.
DHCPv6サーバSHOULD、LEASEQUERYメッセージにおけるOPTION_LQ_QUERYオプションのOPTION_OROで指定されると要請者に返してはいけない「敏感なオプション」のリストで、構成可能であってください。 その要請者が要求しても、このリストにおける少しのオプションも要請者に返してはいけません。
4.4.3. Transmission of LEASEQUERY-REPLY Messages
4.4.3. LEASEQUERY-応答メッセージの伝達
The server sends the LEASEQUERY-REPLY message as described in the "Transmission of Reply Messages" section of [2].
サーバは[2]の「応答メッセージの伝達」セクションで説明されるようにLEASEQUERY-REPLYメッセージを送ります。
5. Security Considerations
5. セキュリティ問題
Access concentrators are expected to be common leasequery requestors. Access concentrators that use DHCPv6 gleaning (i.e., [10]), refreshed with LEASEQUERY messages, will maintain accurate client/binding information. This ensures that the access concentrator can forward data traffic to the intended destination in the broadband access network, can perform IPv6 source address verification of datagrams from the access network, and can encrypt traffic that can only be
アクセス集中装置は一般的なleasequery要請者であると予想されます。 落ち穂拾いでありながらDHCPv6を使用する集中装置にアクセスしてください。(すなわち、LEASEQUERYメッセージでリフレッシュされた[10])は正確なクライアント/拘束力がある情報を保守するでしょう。 これは、アクセス集中装置が広帯域アクセスネットワークで意図している目的地にデータ通信量を送ることができて、アクセスネットワークからデータグラムのIPv6ソースアドレス検査を実行できて、缶があるだけであるトラフィックを暗号化できるのを確実にします。
Brzozowski, et al. Standards Track [Page 17] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[17ページ]。
decrypted by the intended access modem (e.g., [12] and [13]). Thus, the leasequery capability allows an access concentrator to provide considerably enhanced security.
意図によって解読されて、モデムにアクセスしてください。(例えば、[12]と[13])。 したがって、leasequery能力で、アクセス集中装置はかなり高められたセキュリティを提供できます。
The "Security Considerations" section of [2] details the general threats to DHCPv6, and thus to LEASEQUERY messages. The "Authentication of DHCP Messages" section of [2] describes securing communication between relay agents and servers, as well as clients and servers. If the requestor is an access concentrator, the IPsec- based [9] security as described in [2] Section 21.1 SHOULD be used. Other types of requestors are essentially DHCPv6 clients. Thus, DHCPv6 authentication, Section 21 of [2], is an appropriate mechanism for securing LEASEQUERY and LEASEQUERY-REPLY messages. As the number of leasequery requestors and servers in an administrative domain is relatively small, any shared key distribution issues are minimized.
[2]の「セキュリティ問題」セクションはDHCPv6と、そして、その結果、LEASEQUERYメッセージへの一般的な脅威を詳しく述べます。 [2]の「DHCPメッセージの認証」セクションは、中継エージェントとサーバとのコミュニケーションを保証すると説明します、クライアントとサーバと同様に。 要請者であるなら、アクセス集中装置、基づくIPsec[9]は説明されるとしてセキュリティです。[2] セクション21.1SHOULDでは、使用されてください。 他のタイプの要請者は本質的にはDHCPv6クライアントです。 したがって、DHCPv6認証([2]のセクション21)は、LEASEQUERYとLEASEQUERY-REPLYがメッセージであると機密保護するための適切な手段です。 管理ドメインのleasequery要請者とサーバの数が比較的少ないときに、どんな共有された主要な分配問題も最小にされます。
After implementing the above approaches, the DHCPv6 server should only be communicating with trusted LEASEQUERY requestors, and so security needs should be met.
上のアプローチを実装した後にDHCPv6サーバが信じられたLEASEQUERY要請者とコミュニケートしているだけであるべきであるので、安全要求は満たされるべきです。
However, not all traffic originates directly from these trusted requestors. For example, trusted relay agents can relay LEASEQUERY messages from untrusted requestors or elsewhere in the network. This SHOULD be prevented at least at the perimeter relay agents (or on all relay agents unless relayed LEASEQUERY messages are required for some requestors). DHCPv6 servers MAY be configured to discard relayed LEASEQUERY messages or restrict relay chaining.
しかしながら、トラフィックが直接これらから溯源するというわけではないすべてが要請者を信じました。 例えば、信じられた中継エージェントはネットワークにおけるほかの場所で信頼されていない要請者からのLEASEQUERYメッセージをリレーできます。 このSHOULD、少なくとも周辺中継エージェントで防がれてください(リレーされない場合、すべての中継エージェントの上では、LEASEQUERYメッセージが何人かの要請者に必要です)。 DHCPv6サーバは、リレーされたLEASEQUERYメッセージを捨てるか、またはリレー推論を制限するために構成されるかもしれません。
DHCPv6 servers SHOULD also provide for the ability to restrict the information returned for a client in a LEASEQUERY-REPLY even to a trusted LEASEQUERY requestor, as described in Section 4.4.2.
また、DHCPv6サーバSHOULDはLEASEQUERY-REPLYのクライアントのために信じられたLEASEQUERY要請者にさえ返された情報を制限する能力に備えます、セクション4.4.2で説明されるように。
Since even trusted access concentrators may generate LEASEQUERY requests as a result of activity external to the access concentrator, access concentrators SHOULD minimize potential denial-of-service attacks on the DHCPv6 servers by minimizing the generation of LEASEQUERY messages. In particular, the access concentrator SHOULD employ negative caching (i.e., cache the fact that a particular recent query failed to return client data) and address restrictions where possible (i.e., don't send a LEASEQUERY message for addresses outside the range of the attached broadband access networks). Together, these mechanisms limit the access concentrator to transmitting one LEASEQUERY message (excluding message retries) per legitimate broadband access network address after a reboot event.
信じられたアクセス集中装置さえアクセス集中装置への外部の活動の結果、LEASEQUERYに要求を生成するかもしれないので、アクセス集中装置SHOULDはDHCPv6サーバでLEASEQUERYメッセージの世代を最小にすることによって、潜在的サービス不能攻撃を最小にします。 特に、アクセス集中装置SHOULDは可能である(すなわち、付属広帯域アクセスネットワークの範囲の外のアドレスへのLEASEQUERYメッセージを送りません)ところで否定的キャッシュ(すなわち、特定の最近の質問がクライアントデータを返さなかったという事実をキャッシュする)とアドレス制限を使います。 これらのメカニズムはアクセス集中装置をリブートイベントの後に正統の広帯域アクセスネットワーク・アドレス単位で1つのLEASEQUERYメッセージを送るのに(メッセージ再試行を除いて)一緒に、制限します。
Packet-flooding denial-of-service attacks can result in the exhaustion of processing resources, thus preventing the server from serving legitimate and regular DHCPv6 clients as well as legitimate
パケット大量送信サービス不能攻撃は処理リソースの疲労困憊をもたらすことができます、その結果、サーバが正統であるとしてまた、正統の、そして、レギュラーのDHCPv6クライアントに役立つのを防ぎます。
Brzozowski, et al. Standards Track [Page 18] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[18ページ]。
DHCPv6 LEASEQUERY requestors, denying configurations to legitimate DHCPv6 clients as well lease information to legitimate DHCPv6 LEASEQUERY requestors. While these attacks are unlikely when only communicating with trusted LEASEQUERY requestors, the possibility always exists that the trust is misplaced, security techniques are compromised, or even trusted requestors can have bugs in them. Therefore, techniques for defending against packet-flooding denial of service are always a good idea, and they include good perimeter security, as mentioned earlier, and rate limiting DHCPv6 traffic by relay agents, other network elements, or the server itself.
また、正統のDHCPv6クライアントに対して構成を否定して、DHCPv6 LEASEQUERY要請者は正統のDHCPv6 LEASEQUERY要請者に情報を賃貸してください。 信じられたLEASEQUERY要請者とコミュニケートするだけであるとき、これらの攻撃はありそうもないのですが、信頼が置き違えられる可能性がいつも存在しているか、セキュリティのテクニックは感染されるか、または信じられた要請者さえそれらにバグを持つことができます。 したがって、いつもサービスのパケット大量送信否定に対して防御するためのテクニックが名案であり、彼らは、先に述べたように良い国境保障を含んで、中継エージェント、他のネットワーク要素、またはサーバ自体でDHCPv6トラフィックを制限しながら、評価します。
One way to attack an access concentrator (as opposed to a DHCPv6 server) as a LEASEQUERY requestor is the establishment of a malicious server with the intent of providing incorrect lease or route information to the access concentrator, thwarting source IPv6 address verification, and preventing correct routing. This type of attack can be minimized by using IPsec as described in Section 21.1 of [2].
LEASEQUERY要請者としてアクセス集中装置(DHCPv6サーバと対照的に)を攻撃する1つの方法が不正確なリースか経由地案内をアクセス集中装置に供給する意図を伴う悪意があるサーバの確立です、ソースIPv6アドレス検査を阻んで、正しいルーティングを防いで。 [2]のセクション21.1で説明されるようにIPsecを使用することによって、このタイプの攻撃を最小にすることができます。
6. IANA Considerations
6. IANA問題
IANA has assigned the following new DHCPv6 Message types in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters:
IANAは http://www.iana.org/assignments/dhcpv6-parameters: で維持された登録で以下の新しいDHCPv6 Messageタイプを選任しました。
LEASEQUERY
LEASEQUERY-REPLY
LEASEQUERY LEASEQUERY-回答
IANA has assigned the following new DHCPv6 Option Codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters:
IANAは http://www.iana.org/assignments/dhcpv6-parameters: で維持された登録で以下の新しいDHCPv6 Option Codesを割り当てました。
OPTION_LQ_QUERY
OPTION_CLIENT_DATA
OPTION_CLT_TIME
OPTION_LQ_RELAY_DATA
OPTION_LQ_CLIENT_LINK
オプション_LQ_質問オプション_クライアント_データオプション_CLT_時間オプション_LQ_リレー_データオプション_LQ_クライアント_リンク
IANA has assigned the following new DHCPv6 Status Codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters:
IANAは http://www.iana.org/assignments/dhcpv6-parameters: で維持された登録で以下の新しいDHCPv6 Status Codesを割り当てました。
UnknownQueryType
MalformedQuery
NotConfigured
NotAllowed
UnknownQueryType MalformedQuery NotConfigured NotAllowed
Brzozowski, et al. Standards Track [Page 19] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[19ページ]。
IANA has created a new registry for the OPTION_LQ_QUERY option query- type codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters with the following initial assignments:
IANAは登録のタイプコードが http://www.iana.org/assignments/dhcpv6-parameters で以下の初期の課題で維持したOPTION_LQ_QUERYオプション質問のために新しい登録を作成しました:
QUERY_BY_ADDRESS 1
QUERY_BY_CLIENTID 2
__CLIENTID2によるアドレス1質問_で_について質問してください。
New OPTION_LQ_QUERY option query-type codes are assigned through Standards Action, as defined in [6].
新しいOPTION_LQ_QUERYオプション質問タイプコードは[6]で定義されるようにStandards Actionを通して割り当てられます。
7. Acknowledgements
7. 承認
Thanks to Ralph Droms, Richard Johnson, Josh Littlefield, Hemant Singh, Pak Siripunkaw, Markus Stenberg, and Ole Troan for their input, ideas, and review during the production of this document.
彼らの入力、考え、およびレビューをこのドキュメントの生産の間、ラルフDroms、リチャード・ジョンソン、ジョッシュ・リトルフィールド、Hemantシン、Pak Siripunkaw、マーカスStenberg、およびOle Troanをありがとうございます。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[2] Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[3] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol
(DHCP) Leasequery", RFC 4388, February 2006.
[3]WoundyとR.とK.キネア、「Dynamic Host Configuration Protocol(DHCP)Leasequery」、RFC4388 2006年2月。
[4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[4]TroanとO.とR.Droms、「Dynamic Host Configuration Protocol(DHCP)バージョン6インチIPv6 Prefix Options、RFC3633、2003年12月。」
8.2. Informative References
8.2. 有益な参照
[5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[5]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[6]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[7]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
Brzozowski, et al. Standards Track [Page 20] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[20ページ]。
[8] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[8] プラマー、D.、「イーサネットアドレス決議は以下について議定書の中で述べます」。 「または、ネットワーク・プロトコルを変換するのは、イーサネットハードウェアの上でイーサネットがトランスミッションのためのアドレスであると48.bitに扱う」STD37、RFC826、1982年11月。
[9] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[9] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[10] Droms, R., "DHCPv6 Relay Agent Assignment Notification (RAAN)
Option", Work in Progress, November 2006.
[10] R.、「DHCPv6中継エージェント課題通知(RAAN)オプション」というDromsは進歩、2006年11月に働いています。
[11] CableLabs, "Data-Over-Cable Service Interface Specifications:
DOCSIS 3.0, MAC and Upper Layer Protocols Interface
Specification, CM-SP-MULPIv3.0-I04-070518", May 2007, available
at http://www.cablemodem.com/.
[11] CableLabs、「データ過剰ケーブルサービスは仕様を連結します」。 2007年5月に http://www.cablemodem.com/ で利用可能な「DOCSIS3.0とMACとUpper LayerプロトコルInterface Specification、CM-SP-MULPIv3.0-I04-070518。」
[12] SCTE Data Standards Subcommittee, "Data-Over-Cable Service
Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface
Specification SCTE 22-2 2002", 2002, available at
http://www.scte.org/standards/.
[12]SCTEデータの規格小委員会、「データ過剰ケーブルサービスは仕様を連結します」。 「DOCSIS、1.0 http://www.scte.org/standards/ で利用可能なBaseline Privacy Interface Specification SCTE22-2 2002、インチ2002。
[13] CableLabs, "Data-Over-Cable Service Interface Specifications:
Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12-
050812", August 2005, available at http://www.cablemodem.com/.
[13] CableLabs、「データ過剰ケーブルサービスは仕様を連結します」。 Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12- 050812", August 2005, available at http://www.cablemodem.com/.
Brzozowski, et al. Standards Track [Page 21] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[21ページ]。
Authors' Addresses
作者のアドレス
John Jason Brzozowski Comcast Cable 1800 Bishops Gate Boulevard Mt. Laurel, NJ 08054 USA
ローレル山、ジョンジェイソンBrzozowskiコムキャストCable1800司教ゲート並木街ニュージャージー08054米国
Phone: +1 856 324 2671 EMail: john_brzozowski@cable.comcast.com
以下に電話をしてください。 +1 2671年の856 324メール: john_brzozowski@cable.comcast.com
Kim Kinnear Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
キムキネアシスコシステムズInc.1414マサチューセッツAve。 Boxborough、MA01719米国
Phone: +1 978 936 0000 EMail: kkinnear@cisco.com
以下に電話をしてください。 +1 0000年の978 936メール: kkinnear@cisco.com
Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
バーナードフォルツシスコシステムズInc.1414マサチューセッツAve。 Boxborough、MA01719米国
Phone: +1 978 936 0000 EMail: volz@cisco.com
以下に電話をしてください。 +1 0000年の978 936メール: volz@cisco.com
Shengyou Zeng Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Shengyou ZengシスコシステムズInc.1414マサチューセッツAve。 Boxborough、MA01719米国
Phone: +1 978 936 0000 EMail: szeng@cisco.com
以下に電話をしてください。 +1 0000年の978 936メール: szeng@cisco.com
Brzozowski, et al. Standards Track [Page 22] RFC 5007 DHCPv6 Leasequery September 2007
Brzozowski、他 規格はDHCPv6 Leasequery2007年9月にRFC5007を追跡します[22ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Brzozowski, et al. Standards Track [Page 23]
Brzozowski、他 標準化過程[23ページ]
一覧
スポンサーリンク
