[要約] RFC 4620は、IPv6ノード情報クエリに関する仕様を定めたものであり、IPv6ネットワークでのノード情報の取得方法を提供しています。このRFCの目的は、ネットワーク管理者がIPv6ノードの情報を効果的に取得し、ネットワークのトラブルシューティングや監視を容易にすることです。
Network Working Group M. Crawford
Request for Comments: 4620 Fermilab
Category: Experimental B. Haberman, Ed.
JHU APL
August 2006
IPv6 Node Information Queries
IPv6ノード情報クエリ
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging.
Table of Contents
目次
1. Introduction ....................................................2
2. Applicability Statement .........................................2
3. Terminology .....................................................2
4. Node Information Messages .......................................3
5. Message Processing ..............................................5
6. Defined Qtypes ..................................................6
6.1. NOOP .......................................................7
6.2. Node Name ..................................................7
6.3. Node Addresses .............................................8
6.4. IPv4 Addresses .............................................9
6.4.1. Discussion ..........................................9
7. IANA Considerations ............................................10
8. Security Considerations ........................................10
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
This document specifies a mechanism for discovering information about names and addresses. The applicability of these mechanisms is currently limited to diagnostic and debugging tools and network management (e.g., node discovery). In the global internet, the Domain Name System (DNS) [1][2] is the authoritative source of such information and this specification is not intended to supplant or supersede it. In fact, in a well-supported network, the names and addresses dealt with by this mechanism will be the same ones, with the same relationships, as those listed in the DNS.
このドキュメントは、名前とアドレスに関する情報を発見するためのメカニズムを指定します。これらのメカニズムの適用性は現在、診断およびデバッグツールとネットワーク管理（ノード発見など）に限定されています。グローバルインターネットでは、ドメイン名システム（DNS）[1] [2]はそのような情報の権威あるソースであり、この仕様はそれを取得または置き換えることを意図していません。実際、よくサポートされているネットワークでは、このメカニズムによって扱われる名前とアドレスは、DNSにリストされているものと同じ関係と同じものになります。
This new Node Information protocol provides facilities that are not found in the DNS, for example, discovering relationships between addresses without reference to names. The functions that do overlap with the DNS may be useful in serverless environments, for debugging, or in regard to link-local and unique-local addresses [3] that often will not be listed in the DNS.
この新しいノード情報プロトコルは、DNSにはない機能を提供します。たとえば、名前を参照することなくアドレス間の関係を発見します。DNSと重複する関数は、DNSにはしばしばリストされていないリンクローカルおよびユニークなローカルアドレス[3]に関して、サーバーレス環境、デバッグ、またはリンクローカルおよびユニークなローカルアドレスに関して役立つ場合があります。
IPv6 Node Information Queries include the capability to provide forward and reverse name lookups independent of the DNS by sending packets directly to IPv6 nodes or groups of nodes.
IPv6ノード情報クエリには、IPv6ノードまたはノードのグループにパケットを直接送信することにより、DNSとは独立したフォワードおよびリバース名のルックアップを提供する機能が含まれます。
The applicability of these mechanisms is currently limited to diagnostic and debugging tools and network management (e.g., node discovery). These mechanisms can be used to learn the addresses and names for nodes on the other end of a point-to-point link or nodes on a shared-medium link such as an Ethernet. This is very useful when debugging problems or when bringing up IPv6 service where there is no global routing or DNS name services available. IPv6's large auto-configured addresses make debugging network problems and bringing up IPv6 service difficult without these mechanisms. An example of an IPv6 debugging tool using IPv6 Node Information Queries is the ping6 program in the KAME (http://www.kame.net), USAGI, and other IPv6 implementations.
The mechanisms defined in this document may have wider applicability in the future, but any use beyond debugging and diagnostic tools is left for further study and is beyond the scope of this document.
このドキュメントで定義されているメカニズムは、将来的にはより広範な適用可能性を持っている可能性がありますが、デバッグや診断ツールを超えて使用することはさらなる研究のために残されており、このドキュメントの範囲を超えています。
A "Node Information Query" (or "NI Query") message is sent by a "Querier" node to a "Responder" node in an ICMPv6 packet addressed to the "Queried Address". The Query contains a "Subject Address" (which may differ from the Queried Address and may be an IPv6 or IPv4 address) or a "Subject Name". The Responder sends a "Node Information Reply" to the Querier, containing information associated with the node at the Queried Address. A node receiving an NI Query will be termed a Responder even if it does not send a reply.
「ノード情報クエリ」（または「niクエリ」）メッセージは、「クエリアドレス」にアドレス指定されたICMPv6パケットの「応答者」ノードに「Querier」ノードによって送信されます。クエリには、「サブジェクトアドレス」（クエリアドレスとは異なる場合があり、IPv6またはIPv4アドレス）または「サブジェクト名」である場合があります。レスポンダーは、クエリドアドレスのノードに関連付けられた情報を含むQuerierに「ノード情報返信」を送信します。NIクエリを受信するノードは、返信を送信しなくても、レスポンダーと呼ばれます。
The word "name" in this document refers to a hostname with or without the domain. Where necessary, the cases of fully-qualified and single-label names will be distinguished.
このドキュメントの「名前」という言葉は、ドメインの有無にかかわらずホスト名を指します。必要に応じて、完全に適格化された単一盲rabeのケースが区別されます。
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 [4].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[4]で説明されているように解釈される。
Packet fields marked "unused" must be zero on transmission and, aside from inclusion in checksums or message integrity checks, ignored on reception.
「未使用」とマークされたパケットフィールドは、送信時にゼロである必要があり、チェックサムやメッセージの整合性チェックに含めることは別として、受信で無視されます。
Two types of Node Information messages, the NI Query and the NI Reply, are carried in ICMPv6 [5] packets. They have the same format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qtype | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nonce +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Data /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Node Information Messages
図1：ノード情報メッセージ
Fields:
田畑：
o Type
o タイプ
* 139 - NI Query
*
* 140 - NI Reply
* 140 -NI返信
o Code
o コード
* For NI Query
* Niクエリ用
+ 0 - Indicates that the Data field contains an IPv6 address that is the Subject of this Query.
+ 0-データフィールドに、このクエリの主題であるIPv6アドレスが含まれていることを示します。
+ 1 - Indicates that the Data field contains a name that is the Subject of this Query, or is empty, as in the case of a NOOP.
+ 1-データフィールドに、NOOPの場合のように、このクエリの主題である、または空の名前が含まれていることを示します。
+ 2 - Indicates that the Data field contains an IPv4 address that is the Subject of this Query.
+ 2-データフィールドに、このクエリの主題であるIPv4アドレスが含まれていることを示します。
* For NI Reply
* NI返信の場合
+ 0 - Indicates a successful reply. The Reply Data field may or may not be empty.
+ 0-返信が成功したことを示します。返信データフィールドは空になる場合とそうでない場合があります。
+ 1 - Indicates that the Responder refuses to supply the answer. The Reply Data field will be empty.
+ 1-応答者が答えの提供を拒否していることを示します。返信データフィールドは空になります。
+ 2 - Indicates that the Qtype of the Query is unknown to the Responder. The Reply Data field will be empty.
+ 2-クエリのQTYPEがレスポンダーにとって不明であることを示します。返信データフィールドは空になります。
o Checksum - The ICMPv6 checksum.
o チェックサム-ICMPV6チェックサム。
o Qtype - A 16-bit field that designates the type of information requested in a Query or supplied in a Reply. Its value in a Reply is always copied from the corresponding Query by the Responder. Five values of Qtype are specified in this document.
o
o Flags - Qtype-specific flags that may be defined for certain Query types and their Replies. Flags not defined for a given Qtype must be zero on transmission and ignored on reception, and must not be copied from a Query to a Reply unless so specified in the definition of the Qtype.
o フラグ -QTYPE固有のフラグは、特定のクエリタイプとその返信に対して定義される可能性があります。特定のQTYPEに対して定義されていないフラグは、送信時にゼロであり、受信時に無視する必要があり、QTYPEの定義で指定されていない限り、クエリから返信にコピーしてはなりません。
o Nonce - An opaque 64-bit field to help avoid spoofing and/or to aid in matching Replies with Queries. Its value in a Query is chosen by the Querier. Its value in a Reply is always copied from the corresponding Request by the Responder.
o Nonce-スプーフィングを回避したり、クエリとの一致した応答を支援するのに役立つ不透明な64ビットフィールド。クエリのその値は、クエリエによって選択されます。返信のその値は、対応するリクエストから常に対応するリクエストからコピーされます。
o Data - In a Query, the Subject Address or Name. In a Reply, Qtype-specific data is present only when the ICMPv6 Code field is zero. The length of the Data may be inferred from the IPv6 header's Payload Length field [6], the length of the fixed portion of the NI packet, and the lengths of the ICMPv6 header and intervening extension headers.
o データ - クエリでは、サブジェクトアドレスまたは名前。返信では、QTYPE固有のデータが存在します。ICMPV6コードフィールドがゼロの場合にのみ存在します。データの長さは、IPv6ヘッダーのペイロード長さフィールド[6]、Niパケットの固定部分の長さ、およびICMPV6ヘッダーの長さと介在する拡張ヘッダーから推測できます。
Note that the type of information present in the Data field of a Query is declared by the ICMP Code, whereas the type of information, if any, in the Data field of a Reply is determined by the Qtype.
クエリのデータフィールドに存在する情報のタイプは、ICMPコードによって宣言されているのに対し、返信のデータフィールドにある情報のタイプ（ある場合）はQTypeによって決定されることに注意してください。
When the Subject of a Query is a name, the name MUST be in DNS wire format [2]. The name may be either a fully-qualified domain name, including the terminating zero-length label, or a single DNS label followed by two zero-length labels. Since a Query contains at most one name, DNS name compression MUST NOT be used.
クエリの件名が名前の場合、名前はDNSワイヤ形式[2]でなければなりません。名前は、終端ゼロ長のラベルを含む完全に資格のあるドメイン名、または1つのDNSラベルに続いて2つのゼロ長さのラベルを含むものです。クエリにはせいぜい1つの名前が含まれているため、DNS名圧縮は使用してはなりません。
The Querier constructs an ICMP NI Query and sends it to the address from which information is wanted. When the Subject of the Query is an IPv6 address, that address will normally be used as the IPv6 destination address of the Query, but need not be if the Querier has useful a priori information about the addresses of the target node. An NI Query may also be sent to a multicast address of link-local scope [3].
QuerierはICMP Niクエリを構築し、情報が必要なアドレスに送信します。クエリの件名がIPv6アドレスである場合、そのアドレスは通常、クエリのIPv6宛先アドレスとして使用されますが、Querierがターゲットノードのアドレスに関するアプリオリ情報を有用である場合は必要ありません。NIクエリは、Link-Local Scope [3]のマルチキャストアドレスに送信することもできます。
When the Subject is a name, either fully-qualified or single-component, and the Querier does not have a unicast address for the target node, the query MUST be sent to a link-scope multicast address formed in the following way. The Subject Name is converted to the canonical form defined by DNS Security [7], which is uncompressed with all alphabetic characters in lowercase. (If additional DNS label types or character sets for hostnames are defined, the rules for canonicalizing those labels will be found in their defining specification.) Compute the MD5 hash [8] of the first label of the Subject Name--the portion beginning with the first one-octet length field and up to, but excluding, any subsequent length field. Append the first 24 bits of that 128-bit hash to the prefix FF02:0:0:0:0:2:FF00::/104. The resulting multicast address will be termed the "NI Group Address" for the name. A node will support an "NI Group Address" for each unique single-label name.
被験者が完全に適格または単一コンポーネントの名前であり、Querierにターゲットノードのユニキャストアドレスがない場合、クエリは次の方法で形成されたリンクスコープマルチキャストアドレスに送信する必要があります。件名は、DNSセキュリティ[7]によって定義された標準形式に変換されます。これは、小文字のすべてのアルファベット文字で圧縮されていません。（ホスト名の追加のDNSラベルタイプまたは文字セットが定義されている場合、それらのラベルを正規化するためのルールは、定義仕様にあります。）件名の最初のラベルのMD5ハッシュ[8]を計算します。最初の1オクテットの長さフィールドとその後の長さフィールドまでは、しかし除く。その128ビットハッシュの最初の24ビットをプレフィックスFF02：0：0：0：0：2：FF00 ::/104に追加します。結果のマルチキャストアドレスは、名前の「NIグループアドレス」と呼ばれます。ノードは、一意のシングルラベル名ごとに「NIグループアドレス」をサポートします。
The Nonce MUST be a random or good pseudo-random value to foil spoofed replies. An implementation that allows multiple independent processes to send NI Queries MAY use the Nonce value to deliver Replies to the correct process. Nonetheless, such processes MUST check the received Nonce and ignore extraneous Replies.
Nonceは、スプーフィングされた応答をフォイルするには、ランダムまたは良好な擬似ランダム値でなければなりません。複数の独立したプロセスがNIクエリを送信できるようにする実装は、NonCE値を使用して正しいプロセスへの返信を提供する場合があります。それにもかかわらず、そのようなプロセスは、受け取ったノンセをチェックし、無関係な応答を無視する必要があります。
If true communication security is required, IP Security (IPsec) [14] should be used. Providing the infrastructure to authenticate NI Queries and Replies may be quite difficult outside of a well-defined community.
真のコミュニケーションセキュリティが必要な場合は、IPセキュリティ（IPSEC）[14]を使用する必要があります。NIクエリと応答を認証するためのインフラストラクチャを提供することは、明確に定義されたコミュニティ以外では非常に困難な場合があります。
Upon receiving an NI Query, the Responder must check the Query's IPv6 destination address and discard the Query without further processing unless it is one of the Responder's unicast or anycast addresses, or a link-local scope multicast address that the Responder has joined. Typically, the latter will be an NI Group Address for a name belonging to the Responder. A node MAY be configured to discard NI Queries to multicast addresses other than its NI Group Address(es), but if so, the default configuration SHOULD be not to discard them.
NIクエリを受信すると、Responderは、クエリのIPv6宛先アドレスを確認し、ResponderのユニキャストまたはAnycastアドレスの1つでない場合、Responderが参加したLink-Local Scope Multicastアドレスでない限り、さらに処理することなくクエリを破棄する必要があります。通常、後者はレスポンダーに属する名前のNIグループアドレスになります。Niグループアドレス以外のマルチキャストアドレスにniクエリを破棄するようにノードを構成することができますが、その場合、デフォルトの構成はそれらを破棄することはできません。
A Responder must also silently discard a Query whose Subject Address or Name (in the Data field) does not belong to that node. A single-component Subject Name matches any fully-qualified name whose first label matches the Subject. All name matching is done in a case-independent manner consistent with DNS Security (DNSSEC) name canonicalization [7].
また、応答者は、サブジェクトアドレスまたは名前（データフィールド）がそのノードに属していないクエリを静かに破棄する必要があります。単一コンポーネントのサブジェクト名は、最初のラベルが件名と一致する完全に資格のある名前と一致します。すべての名前のマッチングは、DNSセキュリティ（DNSSEC）の標準化[7]と一致するケースに依存しない方法で行われます。
Next, if Qtype is unknown to the Responder, it must return an NI Reply with ICMPv6 Code = 2 and no Reply Data. The Responder should rate-limit such replies as it would ICMPv6 error replies [5].
次に、QTYPEが応答者に不明な場合、ICMPV6コード= 2でNI応答を返す必要があり、返信データはありません。Responderは、ICMPv6エラーが応答するように、そのような応答を評価する必要があります[5]。
Next, the Responder should decide whether to refuse an answer, based on local policy. (See the "Security Considerations" section for recommended default behavior.) If an answer is refused, depending on local policy the Responder can elect to silently discard the query or send an NI Reply with ICMPv6 Code = 1 and no Reply Data. Again, the Responder should rate-limit such replies as it would ICMPv6 error replies [5].
次に、レスポンダーは、ローカルポリシーに基づいて、回答を拒否するかどうかを決定する必要があります。（推奨されるデフォルトの動作については、「セキュリティ上の考慮事項」セクションを参照してください。）回答が拒否された場合、ローカルポリシーに応じて、レスポンダーはクエリを静かに廃棄するか、ICMPV6コード= 1でNI返信を送信することを選択できます。繰り返しますが、Responderは、ICMPv6エラーが応答するように、そのような応答をレートに制限する必要があります[5]。
Finally, if the Qtype is known and the response is allowed by local policy, the Responder MUST fill in the Flags and Reply Data of the NI Reply in accordance with the definition of the Qtype and transmit the NI Reply. The source address of the NI Reply SHOULD be selected using the rules defined in [9].
最後に、QTYPEが既知であり、ローカルポリシーによって応答が許可されている場合、レスポンダーはQTYPEの定義に従ってNI応答のフラグを記入し、NI応答の返信データを記入し、NI応答を送信する必要があります。[9]で定義されているルールを使用して、NI応答のソースアドレスを選択する必要があります。
If the Query was sent to a multicast address, transmission of the Reply MUST be delayed by a random interval between zero and [Query Response Interval], as defined by Multicast Listener Discovery Version 2 [10].
クエリがマルチキャストアドレスに送信された場合、マルチキャストリスナーディスカバリーバージョン2 [10]で定義されているように、応答の送信は、ゼロと[クエリ応答間隔]の間のランダム間隔によって遅延する必要があります。
The following Qtypes are defined. Qtypes 0, 2, and 3 MUST be supported by any implementation of this protocol. Qtype 4 SHOULD be supported by any implementation of this protocol on an IPv4/IPv6 dual-stack node and MAY be supported on an IPv6-only node.
次のQTypesが定義されています。QTypes 0、2、および3は、このプロトコルの実装によってサポートする必要があります。QTYPE 4は、IPv4/IPv6デュアルスタックノード上のこのプロトコルの実装によってサポートされ、IPv6のみのノードでサポートされる場合があります。
+-------------+----------------+
| Qtype Value | Qtype Name |
+-------------+----------------+
| 0 | NOOP |
| 1 | unused |
| 2 | Node Name |
| 3 | Node Addresses |
| 4 | IPv4 Addresses |
+-------------+----------------+
This NI type has no defined flags and never has a Data field. A Reply to an NI NOOP Query tells the Querier that a node with the Queried Address is up and reachable and implements the Node Information protocol. On transmission, the ICMPv6 Code in a NOOP Query must be set to 1 and the Code in a NOOP Reply must be 0. On reception of a NOOP Query or Reply, the Code must be ignored.
このNIタイプには定義されたフラグがなく、データフィールドはありません。NI NOOPクエリへの返信は、クエリエがクエリされたアドレスを持つノードがアップして到達可能であり、ノード情報プロトコルを実装していることをQuerierに伝えます。送信では、NOOPクエリのICMPV6コードを1に設定し、NOOP返信のコードを0に設定する必要があります。NOOPクエリまたは応答の受信では、コードを無視する必要があります。
The NI Node Name Query requests the fully-qualified or single-component name corresponding to the Subject Address or Name. The Reply Data has the following format.
Niノード名クエリは、サブジェクトアドレスまたは名前に対応する完全に適格または単一コンポーネント名を要求します。返信データには次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Names ... |
+ +
/ /
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Node Information Reply Message
図2：ノード情報返信メッセージ
o TTL (Time to Live) - MUST be zero. Any non-zero value received MUST be treated as zero. This field is no longer used but is present to preserve backward compatibility with older implementations.
o TTL（ライブの時間） - ゼロでなければなりません。受信したゼロ以外の値は、ゼロとして扱わなければなりません。このフィールドはもはや使用されていませんが、古い実装との後方互換性を維持するために存在します。
o Node Names - The fully-qualified or single-component name or names of the Responder that correspond(s) to the Subject Address or Name, in DNS wire format, Section 3.1 of [2]. Each name MUST be fully-qualified if the responder knows the domain suffix;
o ノード名 - 被験者の住所または名前に対応するレスポンダーの完全な資格または単一コンポーネント名または名前[2]のセクション3.1。応答者がドメインの接尾辞を知っている場合、各名前は完全に資格を付ける必要があります。
otherwise, each name MUST be a single DNS label followed by two zero-length labels. When multiple node names are returned and more than one of them is fully-qualified, DNS name compression, Section 4.1.4 of [2], SHOULD be used, and the offsets are counted from the first octet of the Data field. An offset of 4, for example, will point to the beginning of the first name.
それ以外の場合、各名前は単一のDNSラベルに続いて、2つのゼロ長さのラベルを使用する必要があります。複数のノード名が返され、複数のノード名が完全に適格である場合、[2]のセクション4.1.4を使用する必要があり、オフセットはデータフィールドの最初のオクテットからカウントされます。たとえば、4のオフセットは、名の先頭を指します。
The Responder must fill in the TTL field of the Reply with zero.
応答者は、返信のTTLフィールドにゼロで記入する必要があります。
Only one TTL is included in the Reply.
返信には1つのTTLのみが含まれています。
If the Responder does not know its name at all, it MUST send a Reply with TTL=0 and no Node Names (or a Reply with Code=1 indicating refusal to answer). The Querier will be able to determine from the packet length that the Data field contains no names.
レスポンダーがその名前をまったく知らない場合、TTL = 0で返信を送信する必要があり、ノード名はありません（または、回答の拒否を示すコード= 1の返信）。クエリエは、データフィールドに名前が含まれていないことをパケットの長さから決定することができます。
The NI Node Addresses Query requests some set of the Responder's IPv6 unicast addresses. The Reply Data is a sequence of 128-bit IPv6 addresses, with each address preceded by a separate 32-bit TTL value, with Preferred addresses listed before Deprecated addresses [11]; otherwise, they are in no special order. Five flag bits are defined in the Query and six in the Reply.
Niノードアドレスは、クエリのリクエストを要求します。ResponderのIPv6ユニキャストアドレスのセットが要求されます。返信データは128ビットIPv6アドレスのシーケンスであり、各アドレスの前には別の32ビットTTL値があり、控除アドレスの前にリストされた優先アドレスがリストされています[11]。そうでなければ、それらは特別な順序ではありません。クエリでは5つのフラグビットが定義されており、6つは返信で定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qtype=3 | unused |G|S|L|C|A|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Node Information Address Query
図3：ノード情報アドレスクエリ
o G - If set to 1, Global-scope addresses [12] are requested.
o G- 1に設定すると、グローバルスコープアドレス[12]が要求されます。
o S - If set to 1, Site-local addresses [12] are requested. However, Site-local addresses are now deprecated [15] and this flag is for backward compatibility.
o S- 1に設定すると、サイトローカルアドレス[12]が要求されます。ただし、サイトローカルアドレスは現在廃止され[15]、このフラグは後方互換性のためのものです。
o L - If set to 1, Link-local addresses [12] are requested.
o L- 1に設定すると、Link -Localアドレス[12]が要求されます。
o C - If set to 1, IPv4-compatible (now deprecated) and IPv4-mapped addresses [3] are requested. Responses SHOULD include IPv4 addresses in IPv4-mapped form.
o c- 1に設定されている場合、IPv4互換（現在は廃止）およびIPv4マップのアドレス[3]が要求されます。応答には、IPv4マップフォームのIPv4アドレスを含める必要があります。
o A - If set to 1, all the Responder's unicast addresses (of the specified scope(s)) are requested. If 0, only those addresses are requested that belong to the interface (or any one interface) that has the Subject Address or that are associated with the Subject Name.
o a -1に設定すると、すべてのResponderのユニキャストアドレス（指定されたスコープの）が要求されます。0の場合、サブジェクトアドレスを持っている、またはサブジェクト名に関連付けられているインターフェイス（または1つのインターフェイス）に属するアドレスのみが要求されます。
o T - Defined in a Reply only, indicates that the set of addresses is incomplete for space reasons.
o t-返信のみで定義されている場合、アドレスのセットが空間の理由で不完全であることを示します。
Flags G, S, L, C, and A are copied from a Query to the corresponding Reply.
フラグG、S、L、C、およびAは、クエリから対応する応答にコピーされます。
The TTL associated with each address MUST be zero.
各アドレスに関連付けられているTTLはゼロでなければなりません。
The NI IPv4 Addresses Query requests some set of the Responder's IPv4 unicast addresses. The Reply Data is a sequence of 32-bit IPv4 addresses, each address preceded by a 32-bit TTL value. One flag bit is defined in the Query and two in the Reply.
Ni IPv4アドレスクエリは、ResponderのIPv4ユニキャストアドレスのいくつかのセットを要求します。返信データは32ビットIPv4アドレスのシーケンスであり、各アドレスは32ビットTTL値が先行します。1つのフラグビットはクエリで定義され、2つは返信に定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qtype=4 | unused |A|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Node Information IPv4 Address Query
図4：ノード情報IPv4アドレスクエリ
o A - If set to 1, all the Responder's unicast addresses are requested. If 0, only those addresses are requested that belong to the interface (or any one interface) that has the Subject Address.
o a -1に設定すると、すべてのResponderのユニキャストアドレスが要求されます。0の場合、サブジェクトアドレスを持つインターフェイス（または1つのインターフェイス）に属するアドレスのみが要求されます。
o T - Defined in a Reply only, indicates that the set of addresses is incomplete for space reasons.
o t-返信のみで定義されている場合、アドレスのセットが空間の理由で不完全であることを示します。
Flag A is copied from a Query to the corresponding Reply.
フラグAは、クエリから対応する返信にコピーされます。
The TTL associated with each address MUST be zero.
各アドレスに関連付けられているTTLはゼロでなければなりません。
It is possible that a node may treat IPv4 interfaces and IPv6 interfaces as distinct, even though they are associated with the same hardware. When such a node is responding to an NI Query having a Subject Address of one type requesting the other type, and the Query has the A flag set to 0, it SHOULD consider IP interfaces, other than tunnels, associated with the same hardware as being the same interface.
ノードは、同じハードウェアに関連付けられていても、IPv4インターフェイスとIPv6インターフェイスを異なるものとして扱う可能性があります。そのようなノードが、1つのタイプの件名アドレスを他のタイプを要求するNIクエリに応答し、クエリには0に設定されたフラグがある場合、トンネル以外のIPインターフェイスを考慮する必要があります。同じインターフェイス。
ICMPv6 type values 139 and 140 were previously assigned by IANA for this protocol. This document defines three values of the ICMPv6 Code field for each of these ICMPv6 Type values. Additional Code values may be defined using the "Specification Required" criteria from [16]. IANA has established and will maintain a registry for the Code fields associated with the Node Information Query ICMPv6 Types as a part of its ICMPv6 Registry updated in [13].
ICMPV6タイプ値139および140は、このプロトコルのために以前にIANAによって割り当てられていました。このドキュメントでは、これらのICMPV6タイプ値のそれぞれについて、ICMPV6コードフィールドの3つの値を定義します。[16]の「必要な仕様」基準を使用して、追加のコード値を定義できます。IANAは、[13]で更新されたICMPv6レジストリの一部として、ノード情報クエリICMPV6タイプに関連付けられたコードフィールドのレジストリを確立し、維持します。
This document defines five values of Qtype, numbers 0 through 4. Following the policies outlined in [16], new values, and their associated Flags and Reply Data, are to be defined by IETF Consensus.
このドキュメントでは、[16]で概説されているポリシーに従って、QTYPEの5つの値、番号0〜4を定義します。新しい値、および関連するフラグと返信データは、IETFコンセンサスによって定義されます。
The IANA has assigned the IPv6 multicast prefix FF02:0:0:0:0:2:FF00::/104 for use in Node Information Queries as defined in Section 5. It should be noted that this assignment does conform with the requirements defined in [17].
IANAは、セクション5で定義されているノード情報クエリで使用するために、IPv6マルチキャストプレフィックスFF02：0：0：0：0：0：0：2：FF00 ::/104を割り当てました。[17]。
This protocol shares the security issues of ICMPv6 that are documented in the "Security Considerations" section of [5].
このプロトコルは、[5]の「セキュリティ上の考慮事項」セクションで文書化されているICMPV6のセキュリティ問題を共有しています。
This protocol has the potential of revealing information useful to a would-be attacker. An implementation of this protocol MUST have a default configuration that refuses to answer queries from global-scope [3] addresses.
このプロトコルには、攻撃者に役立つ情報を公開する可能性があります。このプロトコルの実装には、Global-Scope [3]アドレスからのクエリへの回答を拒否するデフォルトの構成が必要です。
Implementations SHOULD apply rate-limiting to NI responses to avoid being used in a denial-of-service attack.
実装は、サービス拒否攻撃で使用されないように、NI応答に料金制限を適用する必要があります。
The anti-spoofing Nonce does not give any protection from spoofers who can eavesdrop the Query or the Reply.
スプーフィング防止Nonceは、クエリや返信を盗聴できるスプーファーからの保護を与えません。
The information learned via this protocol SHOULD NOT be trusted for making security-relevant decisions unless some other mechanisms beyond the scope of this document are used to authenticate this information.
このプロトコルを介して学んだ情報は、このドキュメントの範囲を超えた他のメカニズムがこの情報を認証するために使用されない限り、セキュリティ関連の決定を下すために信頼されるべきではありません。
An implementation of this protocol SHOULD provide the ability to control the dissemination of information related to IPv6 Privacy Addresses [18]. The default action of this policy SHOULD NOT provide a response to a Query that contains a node's Privacy Addresses.
このプロトコルの実装は、IPv6プライバシーアドレスに関連する情報の普及を制御する機能を提供する必要があります[18]。このポリシーのデフォルトのアクションは、ノードのプライバシーアドレスを含むクエリへの応答を提供してはなりません。
A node MUST NOT include Privacy Addresses in any Node Addresses response that includes a public address, or for which the source address of the response, the destination address of the request, or the Subject Address of the request is a public address. Similarly, a node MUST NOT include any address other than the (single) Privacy Address in any Node Addresses response that includes the Privacy Address, or for which the source address of the response, the destination address of the request, or the Subject Address of the request is the Privacy Address.
ノードには、パブリックアドレス、または応答のソースアドレス、リクエストの宛先アドレス、またはリクエストの主題アドレスがパブリックアドレスを含むノードアドレスの応答にプライバシーアドレスを含めてはなりません。同様に、ノードには、プライバシーアドレス、または応答のソースアドレス、リクエストの宛先アドレス、または主題アドレスを含むノードアドレスの応答に（単一の）プライバシーアドレス以外のアドレスを含めてはなりません。リクエストはプライバシーアドレスです。
Alain Durand contributed to this specification, and valuable feedback and implementation experience were provided by Jun-Ichiro Hagino and Tatuya Jinmei. Other useful comments were received from Robert Elz, Keith Moore, Elwyn Davies, Pekka Savola, and Dave Thaler. Bob Hinden and Brian Haberman have acted as document editors during the IETF advancement process.
Alain Durandはこの仕様に貢献し、Jun-Ichiro HaginoとTatuya Jinmeiによって貴重なフィードバックと実装の経験が提供されました。他の有用なコメントは、ロバート・エルツ、キース・ムーア、エルウィン・デイビス、ペッカ・サヴォラ、デイブ・タラーから受け取られました。ボブ・ヒンデンとブライアン・ハーバーマンは、IETFの進歩プロセス中に文書編集者として行動しました。
This document is not the first proposal of a direct query mechanism for address-to-name translation. The idea had been discussed briefly in the IPng working group, and RFC 1788 [19] describes such a mechanism for IPv4.
このドキュメントは、アドレス間翻訳のための直接クエリメカニズムの最初の提案ではありません。このアイデアはIPNGワーキンググループで簡単に議論されており、RFC 1788 [19]はIPv4のこのようなメカニズムを説明しています。
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[2] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[3] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[5] Conta、A。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）」、RFC 2463、1998年12月。
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[6] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[7] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[7] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のリソースレコード」、RFC 4034、2005年3月。
[8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[8] Rivest、R。、「The Md5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[9] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[9] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[10] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[11] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[11] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6の近隣発見（IPv6）」、RFC 2461、1998年12月。
[12] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003.
[12] Hinden、R.、Deering、S。、およびE. Nordmark、「IPv6 Global Unicastアドレス形式」、RFC 3587、2003年8月。
[13] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[13] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）」、RFC 4443、2006年3月。
[14] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[14] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[15] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[15] Huitema、C。and B. Carpenter、「現場の地元住所」、RFC 3879、2004年9月。
[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[16] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[17] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[17] Haberman、B。、「IPv6マルチキャストアドレスの割り当てガイドライン」、RFC 3307、2002年8月。
[18] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[18] Narten、T。およびR. Draves、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[19] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995.
[19] シンプソン、W。、「ICMPドメイン名メッセージ」、RFC 1788、1995年4月。
Authors' Addresses
著者のアドレス
Matt Crawford Fermilab PO Box 500 Batavia, IL 60510 US
マット・クロフォード・フェルミラブ・ポックス500バタビア、イリノイ60510米国
Phone: +1 630 840 3461
EMail: crawdad@fnal.gov
Brian Haberman (editor) Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
ブライアンハーバーマン（編集者）ジョンズホプキンス大学応用物理学ラボ11100ジョンズホプキンスロードローレル、メリーランド20723-6099 US
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。