Network Working Group M. Crawford
Request for Comments: 4620 Fermilab
Category: Experimental B. Haberman, Ed.
JHU APL
August 2006
IPv6 Node Information Queries
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書では、そのホスト名または完全修飾ドメイン名として、特定のネットワーク情報を提供するIPv6ノードを尋ねるためのプロトコルを記述しています。 IPv6実装の経験は、ホスト名の直接クエリが有用であることが示されており、およびその他の情報については、直接クエリメカニズムは、サーバレス環境でのデバッグのために有用であることが分かっています。
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と重複しない機能は、[3]多くの場合、DNSにリストされないことをデバッグするため、またはリンクローカルおよびユニークローカルアドレスに関して、サーバレス環境において有用であり得ます。
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.
これらのメカニズムの適用性は、現在の診断およびデバッグツールとネットワーク管理（例えば、ノード発見）に制限されます。これらのメカニズムは、イーサネット（登録商標）などの共有媒体リンク上のポイントツーポイントリンクまたはノードのもう一方の端のノードのアドレスと名前を学ぶために使用することができます。問題をデバッグするとき、または利用可能なグローバルルーティングやDNSネームサービスが存在しないIPv6サービスを立ち上げるとき、これは非常に便利です。 IPv6の大規模の自動設定アドレスは、ネットワークの問題をデバッグし、これらのメカニズムのない困難なIPv6サービスを育てます。 IPv6のノード情報クエリを使用してIPv6のデバッグツールの一例は、KAME（http://www.kame.net）、USAGI、および他のIPv6実装でにping6プログラムです。
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パケットに「レスポンダ」ノードに「クエリア」ノードによって送信されます。クエリ（問合せ対象のアドレスと異なる場合がありますおよびIPv6又はIPv4のアドレスであってもよい）、または「サブジェクト名」「対象アドレス」を含みます。レスポンダ照会住所のノードに関連する情報を含む、クエリアに「ノード情報が返信」を送信します。 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.
この文書内の単語「の名前は」またはドメインなしのホスト名を指します。必要な場合には、完全修飾および単一ラベル名の例が区別されます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
ノード情報メッセージの二種類、NIクエリとNIの返信は、[5]パケットのICMPv6で運ばれます。彼らは、同じフォーマットを持っています。
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
＊ １４０ ー に れｐｌｙ
o Code
お こで
* 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 - Responderは答えを提供することを拒否していることを示します。返信のデータフィールドは空になります。
+ 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 QTYPE - 情報クエリで要求または応答で供給されるのタイプを指定する16ビットのフィールド。返信で、その値は常にレスポンダにより、対応するクエリからコピーされます。 QTYPEの5つの値は、この文書で指定されています。
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ナンス - 不透明な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
Oデータ - クエリで、件名アドレスまたは名前。 ICMPv6のコードフィールドがゼロである場合にのみ応答で、QTYPE固有のデータが存在しています。データの長さは、IPv6ヘッダのペイロード長フィールド[6]、固定部の長さから推測することができます
of the NI packet, and the lengths of the ICMPv6 header and intervening extension headers.
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]。名前が終端長さゼロのラベルを含めた完全修飾ドメイン名、または2つのゼロの長さのラベルに続く単一のDNSラベルのいずれであってもよいです。クエリは多くても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].
クエリアはICMP NIクエリを構築し、情報が欲しかっされたアドレスに送信します。クエリの件名は、IPv6アドレスである場合には、そのアドレスは、通常、クエリのIPv6宛先アドレスとして使用されますが、質問者がターゲットノードのアドレスに関する有用な事前情報を持っている場合である必要はありません。 NIクエリはまた、[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.
サブジェクト名であり、いずれかの完全修飾または単一成分、及びクエリアがターゲットノードのユニキャストアドレスを持っていない場合、クエリは次のようにして形成されたリンクスコープのマルチキャストアドレスに送信されなければなりません。サブジェクト名は小文字ですべてのアルファベット文字で圧縮されていないDNSセキュリティ[7]によって定義される標準形式に変換されます。 （ホスト名の追加のDNSラベルタイプまたは文字セットが定義されている場合、これらのラベルをcanonicalizingための規則は、それらの定義明細書に見出される。）MD5ハッシュを計算し、[8]サブジェクト名の最初のラベルの - 部分は、で始まります最初の1オクテットの長さフィールドと、最大、しかし、それ以降の長さフィールドを除きます。プレフィックスFF02への128ビットのハッシュの最初の24ビットを追加：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.
ノンスは、スプーフィングされた応答を箔にランダムまたは良好な擬似ランダム値でなければなりません。 NIクエリを送信するために複数の独立したプロセスを可能にする実装が正しいプロセスに返信を送達するためにノンス値を使用することができます。それにもかかわらず、このようなプロセスは、受け取ったノンスをチェックして、余分な回答を無視しなければなりません。
If true communication security is required, IP Security (IPsec) [14] should be used. Providing the infrastructure to authenticate NI
真の通信のセキュリティが必要な場合は、IPセキュリティ（IPsec）の[14]を使用する必要があります。 NIを認証するためのインフラストラクチャを提供
Queries and Replies may be quite difficult outside of a well-defined community.
クエリと回答は、明確に定義されたコミュニティの外では非常に困難であろう。
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クエリを受信すると、レスポンダは、クエリのIPv6宛先アドレスをチェックする必要があり、それはレスポンダのユニキャストまたはエニーキャストアドレスのいずれか、またはレスポンダが参加しているリンクローカルスコープのマルチキャストアドレスでない限り、さらなる処理なしでクエリを捨てます。一般的に、後者は、レスポンダに属する名前用のNIグループアドレスになります。ノードは、そのNIグループアドレス（複数可）以外のマルチキャストアドレスにNIクエリを破棄するように構成することもできるが、その場合、デフォルトの設定では、それらを破棄しないようにすべきである（SHOULD）。
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].
Responderはまた静かにその対象アドレスまたは名前（Dataフィールドで）そのノードに属していないクエリを破棄しなければなりません。単一成分のサブジェクト名は、その最初のラベル件名に一致する完全修飾名と一致します。すべての名前マッチングは、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 Replyを返さなければなりません。レスポンダは、レート制限する必要があり、そのような応答が同じように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].
次に、レスポンダは、ローカルポリシーに基づいて、答えを拒否するかどうかを決定する必要があります。 （推奨デフォルトの動作のための「セキュリティの考慮事項」を参照してください。）答えが拒否されている場合は、ローカルポリシーに応じて、Responderは静かにクエリを破棄またはICMPv6のコード= 1、応答なしのデータとNI Replyを送信することを選択することができます。再び、レスポンダは、速度制限すべきである、そのような応答が同じよう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が知られており、応答はローカルポリシーによって許可された場合、最後に、Responderは国旗で埋め、QTYPEの定義に従ってNI返信データを返信し、NI Replyを伝えなければなりません。 NI返信の送信元アドレスは、[9]で定義されたルールを使用して選択されるべきです。
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タイプには定義されたフラグを持ち、決してDataフィールドを持っています。 NI NOOPクエリーに対する応答が照会アドレスを持つノードが起動して到達可能であるとノード情報プロトコルを実装することクエリアを伝えます。送信に、NOOP QueryでのICMPv6コードを1に設定する必要があり、NOOP応答でコードNOOPクエリや応答の受信に0にする必要があり、コードは無視されなければなりません。
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ノード名 - 完全修飾または単一成分名またはDNSワイヤフォーマットでは、対象アドレスまたは名前に（S）に対応する応答者の名前、[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.
そうでない場合は、各名前は、2つのゼロの長さのラベルに続く単一DNSラベルでなければなりません。複数のノード名が返され、そのうちの2つ以上が完全に修飾されている場合、DNS名圧縮、[2]を使用すべきであるのセクション4.1.4、およびオフセットは、データフィールドの最初のオクテットから数えています。 4のオフセット、例えば、最初の名前の先頭を指します。
The Responder must fill in the TTL field of the Reply with zero.
Responderはゼロで返信のTTLフィールドに入力する必要があります。
Only one TTL is included in the Reply.
一つだけ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.
Responderがまったくその名を知らない場合、それは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ノードは、クエリは、レスポンダのIPv6ユニキャストアドレスの一部のセットを要求アドレス。応答データは、前に記載されている非推奨アドレス優先アドレスと、別の32ビットTTL値が先行する各アドレスに、128ビットのIPv6アドレスのシーケンスである[11]。そうでない場合、彼らは特別な順序です。五個のフラグビットは、クエリと応答の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、リンクローカルアドレス[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互換IF（廃止）と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 - 1に設定した場合、（指定された範囲（複数可）の）すべてのレスポンダのユニキャストアドレスが要求されています。 0の場合、アドレスだけが対象アドレスを持っているか、それがサブジェクト名に関連付けられたインターフェイス（またはいずれかのインターフェイス）に所属することを要請しています。
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のクエリは、レスポンダのIPv4ユニキャストアドレスの一部のセットを要求アドレス。応答データは、32ビットのTTL値が先行する各アドレスの32ビットのIPv4アドレスの配列です。 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 - 1に設定すると、すべてのレスポンダのユニキャストアドレスは、要求されています。 0の場合、アドレスのみが対象アドレスを持つインタフェース（またはいずれかのインターフェイス）に所属することを要請しています。
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インタフェースを扱うことが可能です。そのようなノードは、他のタイプの要求一種の件名アドレスを有する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.
この文書では、QTYPEの5つの値を定義し、4を介して0 [16]に概説された方針、新しい値、およびそれらに関連するフラグに従い、データの返信数値は、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].
第5節で定義されたこの割り当ては、定義された要件に適合しないことに留意すべきであるノード情報クエリで使用するためFF00 :: / 104：0：0：0：0：2 IANAはIPv6マルチキャストプレフィックスFF02が割り当てられています[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.
このプロトコルは、-なり、攻撃者に有用な情報を明らかにする可能性を秘めています。このプロトコルの実装は、[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.
アランデュランは、この仕様に貢献し、貴重なフィードバックと実装経験が6月-一郎萩野達也と神明によって提供されました。他の有用なコメントはロバート・エルツ、キースムーア、エルウィン・デイヴィス、ペッカSavola、とDaveターラーから受け取りました。ボブHindenとハーバーマンとブライアンは、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.デアリング、 "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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[5]コンタ、A.、およびS.デアリングを、 "インターネット制御メッセージプロトコル（ICMPv6の）インターネットプロトコルバージョン6（IPv6）の仕様は、"、RFC 2463、1998年12月。
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[6]デアリング、S.と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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのリソースレコード"、RFC 4034、2005年3月。
[8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[8]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[9] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[9] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[10]ヴィーダ、R.とL.コスタ、 "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.シンプソン、 "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.、デアリング、S.、およびE. Nordmarkと、 "IPv6のグローバルユニキャストアドレス形式"、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]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 4443、2006年3月。
[14] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[14]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[15] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[15]のHuitema、C.およびB.大工、 "卑下サイトローカルアドレス"、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.
、BCP 26、RFC 2434、1998年10月[16] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[17] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[17]ハーバーマン、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におけるステートレスアドレス自動設定のための個人情報保護の拡張"、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バタビア、IL 60510米国
Phone: +1 630 840 3461 EMail: crawdad@fnal.gov
電話：+1 630 840 3461 Eメール：crawdad@fnal.gov
Brian Haberman (editor) Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
ブライアンハーバーマン（エディタ）ジョンズ・ホプキンス大学応用物理研究所11100ジョンズホプキンスロードローレル、MD 20723から6099米
Phone: +1 443 778 1319 EMail: brian@innovationslab.net
電話：+1 443 778 1319 Eメール：brian@innovationslab.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。