この文書はRFC 4620の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネットコミュニティのための実験的プロトコルを定義し
ます。これはインターネット標準を指定しません。議論と改善提案が要求さ
れています。このメモの配布は無制限です。
Copyright Notice
著作権表示
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
1. はじめに
2. Applicability Statement
2. 適用性宣言
3. Terminology
3. 用語
4. Node Information Messages
4. ノード情報メッセージ
5. Message Processing
5. メッセージ処理
6. Defined Qtypes
6. 問合せ種別の定義
6.1. NOOP
6.1. 運用確認
6.2. Node Name
6.2. ノード名
6.3. Node Addresses
6.3. ノードアドレス
6.4. IPv4 Addresses
6.4. IPv4アドレス
6.4.1. Discussion
6.4.1. 議論
7. IANA Considerations
7. ＩＡＮＡの考慮
8. Security Considerations
8. セキュリティの考察
9. Acknowledgements
9. 謝辞
10. References
10. 参考文献
10.1. Normative References
10.1. 参照する参考文献
10.2. Informative References
10.2. 有益な参考文献
1. Introduction
1. はじめに
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.
この文書は名前とアドレスの情報を発見する機構を指定します。この機構
の適用性は、現時点で、診断とデバッグ用ツール、およびネットワーク管
理(例えば、ノード発見)に制限されます。グローバルインターネットでは、
ドメインネームシステム（ＤＮＳ[1][2]がこのような情報の権威であり、
この仕様はＤＮＳの置き換えを意図しません。事実上、よく管理されてい
るネットワークでは、この機構によって得られる名前とアドレスはＤＮＳ
で記載されたものと同じで、同じ関係になるでしょう。
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.
この新しいノード情報プロトコルは、例えば名前参照なしのアドレスの発見
といった、ＤＮＳで見つけられない機能を提供します。ＤＮＳと重なる機能
は、しばしばＤＮＳに記載されない、サーバなし環境や、デバッグや、リン
クローカルや一意ローカルアドレス[3]の役に立つかもしれません。
2. Applicability Statement
2. 適用性宣言
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.
ＩＰｖ６ノード情報問合せは、直接ＩＰｖ６ノードかノードのグループにパ
ケットを送り、ＤＮＳに依存せずに名前解決と逆解決を提供する能力を含ん
でいます。
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.
これらの機構の適用性は、現在、診断とデバッグ用ツールと、ネットワー
ク管理(例えば、ノード発見)に制限されます。この機構は１対１リンクの
反対側のノードや、イーサーネットの様な共有媒体リンク上のノードのア
ドレスと名前を学ぶのに使用できます。デバッグ時やＩＰｖ６サービスを
開始するときグローバルルーティングやＤＮＳ名前サービスが利用可能で
ないので、これは役に立ちます。ＩＰｖ６の広い自動生成アドレスはネッ
トワークデバッグに問題を生じ、これらの機構なしでＩＰｖ６サービスを
開始するのは難しいです。ＩＰｖ６ノード情報問合せを使用するＩＰｖ６
デバッグ用ツールに関する例は、KAME( http://www.kame.net )、USAGI、
および他のＩＰｖ６実装での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.
本書では定義された機構が、将来より広い適用性を持つかもしれませんが、
デバッグと診断の道具以外での使用は研究課題で、この文書の範囲外です。
3. Terminology
3. 用語
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.
「ノード情報問合せ」（又は「ＮＩ問合せ」）メッセージは、「質問者」
ノードから「応答者」ノードに、「問合せ先アドレス」へのＩＣＭＰｖ６
パケットを使い、送られます。問合せは「対象アドレス」(問合せ先アドレ
スと異なるかもしれず、ＩＰｖ６かＩＰｖ４アドレスかもしれない)や「対
象名」を含んでいます。応答者は、問合せ先アドレスのノードに関連する
情報を含む「ノード情報応答」を質問者に送ります。ＮＩ問合せを受け取
るノードは、返信しない場合も、応答者と呼ばれます。
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"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"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.
「未使用(unused)」と示されるパケットフィールドは送信時にゼロを設定し、
チェックサム計算に含めることと、メッセージ完全性検査に含めることを除
き、受信者は無視します。
4. Node Information Messages
4. ノード情報メッセージ
Two types of Node Information messages, the NI Query and the NI
Reply, are carried in ICMPv6 [5] packets. They have the same format.
２種類のノード種別メッセージ、ＮＩ問合せとＮＩ応答がＩＣＭＰｖ６[5]パ
ケットで伝えられます。これらは同じ形式です。
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
図１：ノード情報メッセージ
Fields:
フィールド
o Type
種別
* 139 - NI Query
ＮＩ問合せ
* 140 - NI Reply
ＮＩ応答
o Code
コード
* For NI Query
ＮＩ問合せで
+ 0 - Indicates that the Data field contains an IPv6 address
that is the Subject of this Query.
+ 0 - データ(Data)フィールドにこの問合せの対象のＩＰｖ６ア
ドレスを含みます。
+ 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 - データ(Data)フィールドにこの問合せの対象の名前を含むか、
運用確認(NOOP)の場合は空です。
+ 2 - Indicates that the Data field contains an IPv4 address
that is the Subject of this Query.
+ 2 - データ(Data)フィールドにこの問合せの対象のＩＰｖ４アド
レスを含みます。
* For NI Reply
* ＮＩ応答で
+ 0 - Indicates a successful reply. The Reply Data field may
or may not be empty.
+ 0 - 成功応答を示します。応答データ(Reply Data)フィールドは
空かも知れずそうでないかもしれません。
+ 1 - Indicates that the Responder refuses to supply the
answer. The Reply Data field will be empty.
+ 1 - 応答者が、回答の供給を拒否するのを示します。応答データ
(Reply Data)フィールドは空でしょう。
+ 2 - Indicates that the Qtype of the Query is unknown to the
Responder. The Reply Data field will be empty.
+ 2 - 応答者にとって、問合せの問合せ種別(Qtype)が未知である
ことを示します。応答データ(Reply Data)フィールドは空でしょ
う。
o Checksum - The ICMPv6 checksum.
o チェックサム--ＩＣＭＰｖ６チェックサム。
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 フラグ--ある問合せと応答で定義されるかもしれない問合せ種別固有のフ
ラグ。ある問合せ種別でフラグが定義されていなければ、送信時にゼロを
設定し、受信時に無視し、問合せ種別の定義で指定されている場合を除き、
問合せから応答に複写してはなりません。
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 乱数値 -- 偽装を避け、問合せと応答の対応付けのための、意味を持たな
い６４ビットフィールド。問合せでのこの値は質問者が選択します。応答
でのこの値は常に対応する質問者からの問合せから複写されます。
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 データ - 問合せでは、対象のアドレスか名前です。応答ではＩＣＭＰｖ６
のコードフィールドがゼロである場合は問合せ種別固有のデータです。デー
タの長さはＩＰｖ６ヘッダのペイロード長フィールド[6]、ＮＩパケットの
固定部分の長と、ＩＣＭＰｖ６ヘッダ長と、拡張ヘッダから推論します。
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.
問合せのデータフィールドに存在する情報の種類はＩＣＭＰコードで宣言さ
れますが、応答のデータフィールドにデータがある場合の情報の種類が問合
せ種別で決定されることに注意してください。
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.
問合せの対象が名前であるときに、名前はＤＮＳワイヤ形式[2]でなければ
なりません(MUST)。名前は、長さゼロのラベルで終わる完全ドメイン名かも
しれないし、２つの長さゼロのラベルで終わる単一ＤＮＳラベルかもしれま
せん。問合せは最大１つの名前しか含められないので、ＤＮＳ名前圧縮を使っ
てはなりません(MUST NOT)。
5. Message Processing
5. メッセージ処理
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].
質問者はＩＣＭＰ ＮＩ問合せを組立て、情報が欲しいアドレスに送ります。
問合せの対象がＩＰｖ６アドレスであるとき、通常はそのアドレスが問い
合わせのＩＰｖ６宛先アドレスとして使用されますが、質問者が対象ノー
ドに関する有用な情報を既に持っていれば、他の宛先あどれすでもかまい
ません。ＮＩ問合せはリンクローカル範囲の[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.
対象が、完全ドメイン名か単一名の名前で、質問者が対象ノードのユニキャ
ストアドレスを知らない場合、問合せは以下の方法で作られたリンク範囲
マルチキャストアドレスに送らなければなりません。対象名をＤＮＳセキュ
リティ[7]で定義された正規化名に変換します、これは圧縮がされず全ての
アルファベットは小文字です。(ホスト名のＤＮＳラベル種別か文字の追加
定義される時は、それらの仕様を定義する際にラベルを正規化する規則が見
つかるでしょう。)対象名の最初のラベル−最初の１オクテットの長さフィー
ルドから次の長さフィールドの前まで−のＭＤ５ハッシュ[8]を計算します。
１２８ビットのハッシュ値の最初の２４ビットに、プレフィックス
FF02:0:0:0:0:2:FF00::/104を加えます。生成したマルチキャストアドレス
は名前に対する「ＮＩグループアドレス」と呼ばれるでしょう。ノードはそ
れぞれの一意な１つのラベル名の「ＮＩグループアドレス」に対応するで
しょう。
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)は、偽造された応答を防ぐために、無作為であるか、良い擬似
乱数でなければなりません(MUST)。複数の独立のプロセスがＮＩ問合せを
送ることが可能な実装は、正しいプロセスに応答を返すために乱数(Nonce)
値を使用するかもしれません(MAY)。この様な場合も、プロセスは受信した
乱数(Nonce)を検査し、無関係な応答を無視しなければなりません(MUST)。
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.
もし真の通信セキュリティが必要なら、ＩＰセキュリティ(IPsec)[14]が使
用されるべきです。ＮＩ問合せと応答を認証するために基盤を提供するのは
明確な組織でない限り難しいかもしれません。
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.
ＮＩ問合せを受信すると、応答者は問合せのＩＰｖ６宛先アドレスを確認し、
それが応答者のユニキャストアドレスかエニキャストアドレスか、応答者の
加入するリンクローカル範囲マルチキャストアドレスでなければ、後の処理
をせず、問合せを廃棄しなければなりません。通常、後者は応答者の属す名
前のＮＩグループアドレスになるでしょう。ノードはＮＩグループアドレス
以外のマルチキャストアドレスのＮＩ問合せを捨てる様に設定されるかもし
れませんが(MAY)、デフォルト設定では廃棄しないべきです(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].
(データフィールドの)対象アドレスか名前が応答者ノードに属さない問合せ
を、応答者は静かに捨てなければなりません。単一要素の対象名は、最初の
ラベルが対象名に一致する全ての完全ドメイン名に一致します。全ての名前
比較は、ＤＮＳセキュリティ(DNSSEC)名前正規化と整合した、大文字小文字
を区別しない方法で行われます。
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)を知らない場合、ＩＣＭＰｖ６のコー
ド＝２で応答データがないＮＩ応答を返します。ＩＣＭＰｖ６エラー応答を
制限する[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].
次に、応答者は、ローカル方針に基づいて回答を拒否するかどうか決めるべ
きです。(お勧めのデフォルトの振舞いに関しては「セキュリティの考察」章
を見てください。)回答を拒否するなら、ローカル方針に従って、応答者は静
かに問合せを捨てるか、ＩＣＭＰｖ６のコード＝１で応答データがないＮＩ
応答を送るかを選択します。もちろん、応答者はＩＣＭＰｖ６エラー応答を
制限するように、回答の送信率を制限するべきです。
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)を知っていて、回答がローカル方針で許容
されているなら、応答者は問合せ種別の定義に従ってＮＩ応答のフラグと応答
データを記入し、ＮＩ応答を伝えなければなりません。ＮＩ応答のソースアド
レスは[9]で定義された規則で選択するべきです(SHOULD)。
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].
もしマルチキャストアドレスに問合せを送ったなら、マルチキャスト受信者
発見２版[10]で定義されるように応答の送信はゼロから[Query Response
Interval]の間のランダム間隔だけ遅延させなければなりません(MUST)。
6. Defined Qtypes
6. 問合せ種別の定義
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.
以下の問合せ種別が定義されます。このプロトコルの全ての実装は問合せ種
別の０と２と３に対応しなければなりません(MUST)。問合せ種別４は、ＩＰ
ｖ４とＩＰｖ６のデュアルスタックのノードでこのプロトコルの全ての実装
で対応するべきで(SHOULD)、ＩＰｖ６だけのノードでも対応されるかもしれ
ません(MAY)。
+-------------+----------------+
| Qtype Value | Qtype Name |
+-------------+----------------+
| 0 | NOOP |
| 1 | unused |
| 2 | Node Name |
| 3 | Node Addresses |
| 4 | IPv4 Addresses |
+-------------+----------------+
6.1. NOOP
6.1. 運用確認
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.
このＮＩ種別は、定義されたフラグがなく、データフィールドもありません。
ＮＩ運用確認問合せへの応答は、質問者に、問合せアドレスのノードが動作
し、到達可能で、ノード情報問合せを実装していることを知らせます。送信
時に、運用確認問合せのＩＣＭＰｖ６コードは１が設定され、運用確認応答
では０を設定します。運用確認問合せと応答の受信時に、コードは無視しな
ければなりません。
6.2. Node Name
6.2. ノード名
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.
ＮＩノード名問合せは対象アドレスか名前に対する完全ドメイン名か単一
要素名を要求します。 応答データは以下の形式です。
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
図２：ノード情報応答メッセージ
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(有効期間)--ゼロでなえればなりません(MUST)。ゼロでない値を受け
取ってもゼロと扱わなければなりません(MUST)。このフィールドはもう使
用されていませんが、より古い実装との後方互換性を維持するために存在
しています。
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;
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.
o ノード名--応答者の完全ドメイン名か単一要素名か名前で、対象アドレス
か名前に対応するもので、[2]の３．１章のＤＮＳワイヤフォーマットで
す。応答者がドメイン接尾語を知っているなら、それぞれの名前は完全ド
メイン名でなければなりません(MUST)。さもなければ、それぞれの名前は
単一ＤＮＳラベルに続く２個のゼロ長ラベルがでなければなりません(MUST)。
もし複数のノード名を返し、そのうち１つ以上が完全ドメイン名ならば、
[2]の４．１．４章のＤＮＳ名前圧縮が使われ、オフセットはデータフィー
ルドの最初のオクテットからの計算になります。 例えば、オフセットが
４ならば、これは最初の名前を示します。
The Responder must fill in the TTL field of the Reply with zero.
応答者は応答の有効期間(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.
もし応答者が名前を全く知らないなら、TTLが０でノード名がない応答（又
は、回答拒否を示すコード＝１の応答)を返します(MUST)。質問者はパケッ
ト長からデータフィールドに名前が全く含まないことを決定できるでしょう。
6.3. Node Addresses
6.3. ノードアドレス
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.
ＮＩノードアドレス問合せは応答者のＩＰｖ６ユニキャストアドレスのある
集合を求めます。応答データ(Reply Data)は１２８ビットのＩＰｖ６アドレ
スの並びで、それぞれのアドレスの前には３２ビットのＴＴＬ値があり、推
奨アドレスが非推奨アドレスアドレスより前にあります[11]；それ以外、特
に順序はありません。問合せには５ビットのフラグが定義され、応答には６
ビットのフラグが定義されます。
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
図３：ノード情報アドレス問合せ
o G - If set to 1, Global-scope addresses [12] are requested.
o G - １に設定されるなら、グローバル範囲アドレス[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 - １に設定されるなら、サイトローカルアドレス[12]を要求します。
しかしながら、サイトローカルアドレスは現在推奨されていません[15]、
そして、このフラグは後方互換性のためです。
o L - If set to 1, Link-local addresses [12] are requested.
o L - １に設定されるなら、リンクローカルアドレス[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 - １に設定されるなら、ＩＰｖ４互換(現在、非推奨)と、ＩＰｖ４写
像アドレス[3]を要求します。応答にはＩＰｖ４写像形式のＩＰｖ４
アドレスを含めるべきです(SHOULD)。
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 - １に設定されるなら、応答者の（指定された範囲の）全てのユニキャ
ストアドレスを要求しています。もし０なら、対象アドレスか対象名に関
連するインターフェース（またはインターフェースの任意の１つ）に属す
るアドレスを要求します。
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.
各アドレスに関するＴＴＬはゼロに違いありません(MUST)。
6.4. IPv4 Addresses
6.4. IPv4アドレス
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.
ＮＩ ＩＰｖ４アドレス問合せは、応答者のあるＩＰｖ４ユニキャストアド
レスの集合を求めます。応答データ(Reply 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qtype=4 | unused |A|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Node Information IPv4 Address Query
図４ノード情報ＩＰｖ４アドレス問合せ
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 - １に設定されるなら、応答者の全てのユニキャストアドレスを要求
しています。もし０なら、対象アドレスに関連するインターフェース
（またはインターフェースの任意の１つ）に属するアドレスを要求して
います。
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.
各アドレスに関するＴＴＬはゼロに違いありません(MUST)。
6.4.1. Discussion
6.4.1. 議論
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.
ノードが同じハードウェアに関連しているＩＰｖ４インタフェースとＩＰｖ
６インタフェースを区別して扱うのは可能です。もしこの様なノードが対象
アドレスが一方の種類で要求が他方の種類の応答をするとき、そしてAフラグ
が０のとき、トンネルを除き、同じハードウェアに属するＩＰインターフェー
スは同じインターフェースであると考えるべきです(SHOULD)。
7. IANA Considerations
7. ＩＡＮＡの考慮
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].
ＩＣＭＰｖ６の種別値１３９と１４０はこのプロトコルのためにＩＡＮＡに
よって割り当てられました。この文書はこれらのＩＣＭＰｖ６種別値のそれ
ぞれにＩＣＭＰｖ６コードフィールドの３つの値を定義します。追加のコー
ド値は、[16]の「仕様が必要」という評価基準を使用して定義されるかもし
れません。ＩＡＮＡは[13]のＩＣＭＰｖ６登記所の更新の一部として、ノー
ド情報問合せのＩＣＭＰｖ６種別に関するコードフィールドの登記を確認し
登録すえるでしょう。
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)に５つの値、０番から４番を定義します。[16]
に概説された方針に従い、新しい値と、関連するフラグや応答データ(Reply
Data)はＩＥＴＦ同意によって定義されます。
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].
ＩＡＮＡはＩＰｖ６マルチキャストプレフィックスFF02:0:0:0:0:2:FF00::/104
を５章で定義されるノード情報問合せに割り当てました。この割当は[17]で
定義された要件に従うことに注意してください。
8. Security Considerations
8. セキュリティの考察
This protocol shares the security issues of ICMPv6 that are
documented in the "Security Considerations" section of [5].
このプロトコルは[5]の「セキュリティの考察」の章に記録されるＩＣＭＰｖ
６のセキュリティ課題を共有します。
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]アドレスからの質問に答える
のを拒否するデフォルト設定がなければなりません(MUST)。
Implementations SHOULD apply rate-limiting to NI responses to avoid
being used in a denial-of-service attack.
実装はサービス妨害攻撃に使用されるのを避けるためにＮＩ応答に送信率制
限を適用すべきです(SHOULD)。
The anti-spoofing Nonce does not give any protection from spoofers
who can eavesdrop the Query or the Reply.
偽装防止の乱数は、問合せと応答を盗聴できる盗聴者に対し、何の保護も与
えません。
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.
情報は、このプロトコルSHOULD NOTを通してこのドキュメントの範囲を超え
たある他のメカニズムがこの情報を認証するのに使用されない場合セキュリ
ティ関連している決定をしながら信用貸しされるように学びました。
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.
このプロトコルの実装はIPｖ６プライバシアドレス[18]に関する情報の配布
を制御する能力を提供するべきです(SHOULD)。このポリシのデフォルト動作
はノードのプライバシアドレスを含む問合せへの応答を提供するべきではあ
りません(SHOULD NOT)。
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.
ノードは、公共アドレスを含むか、公共アドレスが応答のソースアドレスか、
公共アドレスが問合せの宛先アドレスか、問合せの対象アドレスが公共アド
レスである、ノードアドレス応答にプライバシアドレスを含めてはなりませ
ん(MUST NOT)。同様に、ノードは、プライバシアドレスを含むか、プライバ
シアドレスが応答のソースアドレスか、プライバシアドレスが問合せの宛先
アドレスか、プライバシアドレスが問合せの対象アドレスである問合せに、
(単体の）プライバシアドレス以外を含めてはなりません(MUST NOT)。
9. Acknowledgements
9. 謝辞
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から有益なフィードバックと実装経験が提供されました。Robert Elz
とKeith MooreとElwyn DaviesとPekka SavolaとDave Thalerから他の役に立
つコメントを受けました。ＩＥＴＦ進行処理期間の文書編集でBob Hindenと
Brian Habermanが活躍しました。
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.
この文書はアドレス名前翻訳の直接問合せ機構の最初の提案ではありません。
ＩＰｎｇ作業班で考えについて議論し、RFC 1788[19]はＩＰｖ４のためにそ
のような機構を説明します。
10. References
10. 参考文献
10.1. Normative References
10.1. 参照する参考文献
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[7] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[9] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[11] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[12] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast
Address Format", RFC 3587, August 2003.
[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.
10.2. Informative References
10.2. 有益な参考文献
[14] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[15] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[17] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[18] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[19] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995.
Authors' Addresses
著者のアドレス
Matt Crawford
Fermilab
PO Box 500
Batavia, IL 60510
US
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
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Full Copyright Statement
完全著作権表示
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.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。