RFC4620 日本語訳
4620 IPv6 Node Information Queries. M. Crawford, B. Haberman, Ed.. August 2006. (Format: TXT=31134 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Crawford
Request for Comments: 4620 Fermilab
Category: Experimental B. Haberman, Ed.
JHU APL
August 2006
コメントを求めるワーキンググループM.クロフォードの要求をネットワークでつないでください: 4620年のフェルミ国立加速研究所カテゴリ: エド実験的なB.ハーバーマン、JHU APL2006年8月
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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実装経験は、ホスト名のためのダイレクト質問が役に立つのを示しました、そして、他の情報のためのダイレクト質問メカニズムがserverless環境とデバッグの役に立つのがわかりました。
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
1. 序論…2 2. 適用性声明…2 3. 用語…2 4. ノード情報メッセージ…3 5. メッセージ処理…5 6. Qtypesを定義します…6 6.1. NOOP…7 6.2. ノード名…7 6.3. ノードアドレス…8 6.4. IPv4アドレス…9 6.4.1. 議論…9 7. IANA問題…10 8. セキュリティ問題…10 9. 承認…11 10. 参照…11 10.1. 標準の参照…11 10.2. 有益な参照…12
Crawford & Haberman Experimental [Page 1] RFC 4620 IPv6 Node Information Queries August 2006
情報が2006年8月に質問するクロフォードとハーバーマン実験的な[1ページ]RFC4620IPv6Node
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.
このドキュメントは名前とアドレスの情報を発見するのにメカニズムを指定します。 これらのメカニズムの適用性は現在、病気の特徴、デバッグ用ツール、およびネットワークマネージメント(例えば、ノード発見)に制限されます。 グローバルなインターネットでは、ドメインネームシステム(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.
この新しいNode情報プロトコルは例えば名前の参照なしでアドレスの間の関係を発見しながらDNSで見つけられない施設を提供します。 DNSに重なる機能はserverless環境、デバッグ、または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.
IPv6 Node情報Queriesは直接ノードの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.
これらのメカニズムの適用性は現在、病気の特徴、デバッグ用ツール、およびネットワークマネージメント(例えば、ノード発見)に制限されます。 ノードのために共有された媒体リンクの上のイーサネットなどのポイントツーポイント接続かノードのもう一方の端でアドレスと名前を学ぶのにこれらのメカニズムを使用できます。 IPv6サービスを持って来るとき、問題をデバッグするとき、これが非常に役に立つか、またはどんなグローバルなルーティングもどこにないか、そして、DNSが利用可能なサービスを命名します。 IPv6の大きい自動構成されたアドレスでネットワーク問題をデバッグして、IPv6サービスを持って来るのはこれらのメカニズムなしで難しくなります。IPv6 Node情報Queriesを使用する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.
本書では定義されたメカニズムが将来、より広い適用性を持つかもしれませんが、デバッグと診断用道具を超えたどんな使用も、さらなる研究に発たれて、このドキュメントの範囲を超えています。
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
"Querier"というノードは「ノード情報質問」(または、「Ni質問」)メッセージを「質問されたアドレス」に扱われたICMPv6パケットの「応答者」というノードに送ります。 Queryが「対象のアドレス」を含んでいる、(Queried Addressと異なっているかもしれなくて、IPv6かIPv4であるかもしれません。
Crawford & Haberman Experimental [Page 2] RFC 4620 IPv6 Node Information Queries August 2006
情報が2006年8月に質問するクロフォードとハーバーマン実験的な[2ページ]RFC4620IPv6Node
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.
アドレス) または、「対象の名前。」 Queried Addressのノードに関連している情報を含んでいて、Responderは「ノード情報回答」をQuerierに送ります。 返信しないでも、NI Queryを受けるノードはResponderと呼ばれるでしょう。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[4]で説明されるように本書では解釈されることであるべきですか?
Packet fields marked "unused" must be zero on transmission and, aside from inclusion in checksums or message integrity checks, ignored on reception.
「未使用であること」が示されるパケット分野はトランスミッションであってチェックサムかメッセージの保全チェックでの包含は別としてレセプションで無視されるところでゼロであるに違いありません。
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.
NI QueryとNI Replyという2つのタイプに関するNode情報メッセージは、ICMPv6[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 /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 一回だけ+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | /データ/| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Node Information Messages
図1: ノード情報メッセージ
Fields:
分野:
o Type
o タイプ
* 139 - NI Query
* 139--Ni質問
* 140 - NI Reply
* 140--Ni回答
Crawford & Haberman Experimental [Page 3] RFC 4620 IPv6 Node Information Queries August 2006
情報が2006年8月に質問するクロフォードとハーバーマン実験的な[3ページ]RFC4620IPv6Node
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--Data分野がこのQueryのSubjectである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--Data分野がこのQueryのSubjectであるか、またはケースのようにNOOPがない名前を含むのを示します。
+ 2 - Indicates that the Data field contains an IPv4 address
that is the Subject of this Query.
+2--Data分野がこのQueryのSubjectであるIPv4アドレスを含むのを示します。
* For NI Reply
* Ni回答のために
+ 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--Responderが、答えを供給するのを拒否するのを示します。 Reply Data分野は人影がなくなるでしょう。
+ 2 - Indicates that the Qtype of the Query is unknown to the
Responder. The Reply Data field will be empty.
+2--Responderにおいて、QueryのQtypeが未知であることを示します。 Reply Data分野は人影がなくなるでしょう。
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--Queryで要求されているか、またはReplyで供給された情報の種類を任命する16ビットの分野。 対応するQueryはいつもResponderによってReplyの値が回避されます。 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 旗--あるQueryタイプと彼らのRepliesのために定義されるかもしれないQtype特有の旗。 旗を、与えられたQtypeがトランスミッションのゼロであるに違いなく、レセプションで無視されて、定義しないで、そのようにQtypeの定義で指定されない場合、QueryからReplyまでコピーしてはいけません。
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 一回だけ--だますのを避けるのを助けて、RepliesをQueriesに合わせる際に支援する不透明な64ビットの分野。 Queryの値はQuerierによって選ばれています。 対応するRequestはいつもResponderによってReplyの値が回避されます。
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 Code分野がゼロであるときにだけ、Replyでは、Qtype特有のデータは存在しています。 Dataの長さはIPv6ヘッダーの有効搭載量Length分野[6]から推論されるかもしれません、固定部分の長さ
Crawford & Haberman Experimental [Page 4] RFC 4620 IPv6 Node Information Queries August 2006
情報が2006年8月に質問するクロフォードとハーバーマン実験的な[4ページ]RFC4620IPv6Node
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.
QueryのData分野に出席している情報の種類がICMP Codeによって宣言されますが、もしあればReplyのData分野の情報の種類が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.
QueryのSubjectが名前であるときに、DNSワイヤ形式[2]には名前があるに違いありません。 名前は完全修飾ドメイン名であるかもしれません、終わっているゼロ・レングスラベル、または2個のゼロ・レングスラベルが支えた単一のDNSラベルを含んでいて。 Queryが1つの名前を高々含んでいるので、DNS名前圧縮を使用してはいけません。
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].
Querierは情報が欲しいアドレスにICMP NI Queryを組み立てて、それを送ります。 QueryのSubjectがIPv6アドレスであるときに、そのアドレスは、QueryのIPv6送付先アドレスとして通常使用されますが、Querierで先験的な役に立つ情報があるかどうかという目標ノードのアドレスに関することである必要はありません。 また、リンク地方の範囲[3]のマルチキャストアドレスにNI Queryを送るかもしれません。
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.
Subjectが名前、完全に適切であるかただ一つのコンポーネントであり、Querierには目標ノードのためのユニキャストアドレスがなくて、以下の方法で形成されたリンク範囲マルチキャストアドレスに質問を送らなければならないとき。 Subject NameはDNS Security[7]によって定義された標準形に変換されて、中にすべての英字がある状態でどれが解凍されるかは小文字で印刷します。 (ホスト名のための追加DNSラベル形式か文字集合が定義されると、それらが仕様を定義する際にそれらのラベルをcanonicalizingするための規則は見つけられるでしょう。) Subject Nameの最初のラベルのMD5ハッシュ[8]を計算してください--分野にもかかわらず、最初の1八重奏の長さの分野とどんなその後の長さの分野でも始まる部分。 その128ビットのハッシュの最初の24ビットを接頭語FF02に追加してください:、0:0:2 0:0::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 Queriesを送ることができる実装は、正しいプロセスにRepliesを提供するのにNonce値を使用するかもしれません。 それにもかかわらず、そのようなプロセスは、容認されたNonceをチェックして、異質なRepliesを無視しなければなりません。
If true communication security is required, IP Security (IPsec) [14] should be used. Providing the infrastructure to authenticate NI
本当のコミュニケーションセキュリティが必要であるなら、IP Security(IPsec)[14]は使用されるべきです。 NIを認証するためにインフラストラクチャを提供します。
Crawford & Haberman Experimental [Page 5] RFC 4620 IPv6 Node Information Queries August 2006
情報が2006年8月に質問するクロフォードとハーバーマン実験的な[5ページ]RFC4620IPv6Node
Queries and Replies may be quite difficult outside of a well-defined community.
質問とRepliesは外で明確な共同体でかなり難しいかもしれません。
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.
ResponderはそれがNI Queryを受けて、Responderのユニキャストかanycastアドレスの1つ、またはResponderが接合したリンクローカルの範囲マルチキャストアドレスでないならQueryのIPv6送付先アドレスをチェックして、さらなる処理なしでQueryを捨てなければなりません。 後者はResponderに属す名前のために通常、NI Group Addressになるでしょう。 ノードはNI Group Address(es)以外のマルチキャストアドレスにNI Queriesを捨てるために構成されるかもしれませんが、そうだとすれば、デフォルト設定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は静かに、Subject AddressかName(Data分野の)がそのノードに属さないQueryを捨てなければなりません。 ただ一つのコンポーネントSubject Nameは最初のラベルがSubjectに合っているどんな完全に修飾された名前にも合っています。 DNS Security(DNSSEC)名前canonicalization[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].
次に、ICMPv6 Code=2があるNI Replyを返しますが、Responderにおいて、Qtypeが未知であるなら、それはどんなReply Dataも返してはいけません。 ICMPv6エラー応答[5]を制限するようにResponderはそのような回答をレートで制限するはずです。
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は、ローカルの方針に基づいて答えを拒否するかどうか決めるはずです。 (お勧めのデフォルトの振舞いに関して「セキュリティ問題」セクションを見てください。) 答えが拒否されるなら、ローカルの方針によって、Responderは、ICMPv6 Code=1にもかかわらず、どんなReply Dataと共にも静かに質問を捨てもしませんし、NI Replyを送りもしないのを選ぶことができます。 一方、ICMPv6エラー応答[5]を制限するようにResponderはそのような回答をレートで制限するはずです。
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 ReplyのFlagsとReply Dataに記入して、NI Replyを伝えなければなりません。 選択された使用が[9]で定義された規則であったならNI Reply 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].
マルチキャストアドレスにQueryを送ったなら、ゼロと[質問Response Interval]の無作為の間隔のそばでReplyのトランスミッションを遅らせなければなりません、Multicast Listenerディスカバリーバージョンで2[10]を定義するので。
6. Defined Qtypes
6. 定義されたQtypes
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は定義されます。 このプロトコルのどんな実装でもQtypes0、2、および3をサポートしなければなりません。 Qtype4SHOULDはIPv4/IPv6デュアルスタックノードの上でこのプロトコルのどんな実装によってもサポートされて、IPv6だけノードの上でサポートされるかもしれません。
Crawford & Haberman Experimental [Page 6] RFC 4620 IPv6 Node Information Queries August 2006
情報が2006年8月に質問するクロフォードとハーバーマン実験的な[6ページ]RFC4620IPv6Node
+-------------+----------------+
| Qtype Value | Qtype Name |
+-------------+----------------+
| 0 | NOOP |
| 1 | unused |
| 2 | Node Name |
| 3 | Node Addresses |
| 4 | IPv4 Addresses |
+-------------+----------------+
+-------------+----------------+ | Qtype値| Qtype名| +-------------+----------------+ | 0 | NOOP| | 1 | 未使用| | 2 | ノード名| | 3 | ノードアドレス| | 4 | IPv4アドレス| +-------------+----------------+
6.1. NOOP
6.1. NOOP
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 QueryへのReplyは、Queried Addressとのノードが上がって届いて、Node情報プロトコルを実装するとQuerierに言います。 トランスミッションのときに、NOOP QueryのICMPv6 Codeは1に用意ができなければなりません、そして、NOOP ReplyのCodeは0歳であるに違いありません。 NOOP QueryかReplyのレセプションでは、Codeを無視しなければなりません。
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.
NI Node Name QueryはSubject AddressかNameに対応する完全に適切であるかただ一つのコンポーネント名を要求します。 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Names ... |
+ +
/ /
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ノード名… | + + / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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(Liveへの時間)--ゼロでなければなりません。 ゼロとしてどんな非ゼロ対価領収も扱わなければなりません。 この分野は、もう使用されませんが、より古い実装との後方の互換性を保存するために存在しています。
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 ノードNames--、完全に適切であるかただ一つのコンポーネントの名前か名前、対応するResponderでは、DNSのSubject AddressかNameへの(s)は形式([2]のセクション3.1)を配線します。 応答者がドメイン接尾語を知っているなら、それぞれの名前は完全に適切でなければなりません。
Crawford & Haberman Experimental [Page 7] RFC 4620 IPv6 Node Information Queries August 2006
情報が2006年8月に質問するクロフォードとハーバーマン実験的な[7ページ]RFC4620IPv6Node
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ラベルであるに違いありません。 SHOULD、使用されて、それらの名前が返される複数のノードと1つ以上であるときに、完全に適切なDNS名前圧縮、セクション4.1.4は[2]のものです。オフセットはData分野の最初の八重奏から数えられます。 例えば、4のオフセットは名の始まりまで指すでしょう。
The Responder must fill in the TTL field of the Reply with zero.
ResponderはゼロでReplyのTTL分野に記入しなければなりません。
Only one TTL is included in the Reply.
1TTLだけがReplyに含まれています。
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にもかかわらず、どんなNode Names(または、Code=1が黙秘を示しているReply)と共にも返信してはいけません。 Querierは、パケット長からData分野が名前を全く含まないことを決定できるでしょう。
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.
NI Node Addresses Queryは何らかのセットのResponderのIPv6ユニキャストアドレスを要求します。 Reply Dataは128ビットのIPv6アドレスの系列です、別々の32ビットのTTL値が各アドレスに先行していて、Deprecatedが[11]を扱う前に記載されたPreferredアドレスで。 さもなければ、彼らはどんな特注品にもいません。 5フラグビットがReplyのQueryと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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 未使用|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に設定されるなら、Global-範囲アドレス[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に設定されるなら、Siteローカルのアドレス[12]は要求されます。 しかしながら、Siteローカルのアドレスは現在推奨しない[15]です、そして、この旗は後方の互換性のためのものです。
o L - If set to 1, Link-local addresses [12] are requested.
o L--1に設定されるなら、Linkローカルのアドレス[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]は要求されます。 応答SHOULDは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
o 1、すべてのResponderのユニキャストにアドレスを設定してください。A--、(指定された範囲では、(s))が要求されています。 インタフェース(または、どんなインタフェースも)に属すそれらのアドレスだけが0であるなら、要求される、それ
Crawford & Haberman Experimental [Page 8] RFC 4620 IPv6 Node Information Queries August 2006
情報が2006年8月に質問するクロフォードとハーバーマン実験的な[8ページ]RFC4620IPv6Node
has the Subject Address or that are associated with the Subject
Name.
Subject AddressかそれがSubject Nameに関連づけられましたか?
o T - Defined in a Reply only, indicates that the set of addresses
is incomplete for space reasons.
o T--中でReplyだけを定義して、アドレスのセットがスペース理由で不完全であることを示します。
Flags G, S, L, C, and A are copied from a Query to the corresponding Reply.
旗G、S、L、C、およびAはQueryから対応するReplyまでコピーされます。
The TTL associated with each address MUST be zero.
各アドレスに関連しているTTLはゼロであるに違いありません。
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.
NI IPv4 Addresses Queryは何らかのセットのResponderのIPv4ユニキャストアドレスを要求します。 Reply Dataは32ビットのIPv4アドレス、32ビットのTTL値が先行したそれぞれのアドレスの系列です。 あるフラグビットがReplyのQueryと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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 未使用|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であるなら、Subject Addressを持っているインタフェース(または、どんなインタフェースも)に属すそれらのアドレスだけが要求されます。
o T - Defined in a Reply only, indicates that the set of addresses
is incomplete for space reasons.
o T--中でReplyだけを定義して、アドレスのセットがスペース理由で不完全であることを示します。
Flag A is copied from a Query to the corresponding Reply.
旗AはQueryから対応するReplyまでコピーされます。
The TTL associated with each address MUST be zero.
各アドレスに関連しているTTLはゼロであるに違いありません。
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.
ノードが異なるとしてIPv4インタフェースとIPv6インタフェースを扱うのは、可能です、それらが同じハードウェアに関連していますが。 1のSubject Addressにもう片方を要求しながらタイプさせながらそのようなノードがNI Queryに応じているときにはタイプしてください。そうすれば、QueryはA旗を0に設定させます、それ。SHOULDは、IPがインタフェースであると考えます、トンネルを除いて、同じインタフェースであるのと同じハードウェアに関連しています。
Crawford & Haberman Experimental [Page 9] RFC 4620 IPv6 Node Information Queries August 2006
情報が2006年8月に質問するクロフォードとハーバーマン実験的な[9ページ]RFC4620IPv6Node
7. IANA Considerations
7. IANA問題
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 Type値のためにICMPv6 Code分野の3つの値を定義します。 追加Code値は、[16]から「仕様が必要である」という評価基準を使用することで定義されるかもしれません。 IANAは、確証して、登録であると[13]でアップデートされたICMPv6 Registryの一部としてNode情報Query ICMPv6 Typesに関連しているCode分野に主張するでしょう。
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つの値、No.0〜4を定義します。 それらの[16]に概説された方針、新しい値、関連Flags、およびReply Dataに続いて、IETF Consensusによって定義されることになっていてください。
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はIPv6マルチキャスト接頭語FF02を割り当てました:、0:0:2 0:0::FF00、:、:セクション5で定義されるNode情報Queriesにおける使用のための/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]の「セキュリティ問題」セクションで記録される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.
実装SHOULDは、サービス不能攻撃に使用されるのを避けるためにレート制限をNI応答に適用します。
The anti-spoofing Nonce does not give any protection from spoofers who can eavesdrop the Query or the Reply.
反スプーフィングNonceはQueryかReplyを盗み聞くことができるspoofersから少しの保護も与えません。
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.
SHOULDが情報の普及を制御する能力を提供するこのプロトコルの実装はIPv6 Privacy Addresses[18]に関連しました。 SHOULD NOTがノードのPrivacy Addressesを含むQueryへの応答を提供するこの方針のデフォルト動作。
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
またはノードはa場内放送を含んでいるか、またはソースが扱う応答のもののためにそうするどんなNode Addresses応答にもPrivacy Addressesを含んではいけません、要求の送付先アドレス。
Crawford & Haberman Experimental [Page 10] RFC 4620 IPv6 Node Information Queries August 2006
情報が2006年8月に質問するクロフォードとハーバーマン実験的な[10ページ]RFC4620IPv6Node
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.
要求のSubject Addressは場内放送です。 同様に、ノードはPrivacy Addressを含んでいるか、応答のソースアドレス、要求の送付先アドレス、または要求のSubject AddressがPrivacy AddressであるどんなNode Addresses応答でも(単一)のプライバシーAddress以外の少しのアドレスも含んではいけません。
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.
アラン・ジュランドはこの仕様に貢献しました、そして、有益なフィードバックと実現経験は6月-イチローHaginoとTatuya Jinmeiによって提供されました。 ロバートElz、キース・ムーア、Elwynデイヴィース、ペッカSavola、およびデーヴThalerから他の役に立つコメントを受けました。 IETF前進の間のドキュメントエディタが処理するとき、ボブHindenとブライアン・ハーバーマンは行動しました。
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ワーキンググループで簡潔に考えについて議論しました、そして、RFC1788[19]はIPv4のためにそのようなメカニズムについて説明します。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[1]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[2]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[3]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] コンタ、A.、およびS.デアリング、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC2463、1998年12月。
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[6] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[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.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。
Crawford & Haberman Experimental [Page 11] RFC 4620 IPv6 Node Information Queries August 2006
情報が2006年8月に質問するクロフォードとハーバーマン実験的な[11ページ]RFC4620IPv6Node
[8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[8] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[9] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[9]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。
[10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
そして、[10] ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
[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)のための隣人発見」、RFC2461、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のグローバルなユニキャストアドレス形式」、RFC3587、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.グプタ、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC4443、2006年3月。
10.2. Informative References
10.2. 有益な参照
[14] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[14] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[15] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[15] Huitema、C.、およびB.は2004年9月に「サイトのローカルのアドレスを非難すること」でのRFC3879の大工仕事をします。
[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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[17] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[17] ハーバーマン、B.、「IPv6マルチキャストアドレスのための配分ガイドライン」、RFC3307、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"での国がないアドレス自動構成のためのプライバシー拡大、RFC3041、2001年1月。」
[19] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995.
[19] シンプソン、W.、「ICMPドメイン名メッセージ」、RFC1788、1995年4月。
Crawford & Haberman Experimental [Page 12] RFC 4620 IPv6 Node Information Queries August 2006
情報が2006年8月に質問するクロフォードとハーバーマン実験的な[12ページ]RFC4620IPv6Node
Authors' Addresses
作者のアドレス
Matt Crawford Fermilab PO Box 500 Batavia, IL 60510 US
マットクロフォードフェルミ国立加速研究所PO Box500IL60510バタビア(米国)
Phone: +1 630 840 3461 EMail: crawdad@fnal.gov
以下に電話をしてください。 +1 3461年の630 840メール: crawdad@fnal.gov
Brian Haberman (editor) Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
ブライアンハーバーマン(エディタ)ジョーンズ・ホプキンス大学応用物理学研究室11100のジョーンズ・ホプキン・Road MD20723-6099ローレル(米国)
Phone: +1 443 778 1319 EMail: brian@innovationslab.net
以下に電話をしてください。 +1 1319年の443 778メール: brian@innovationslab.net
Crawford & Haberman Experimental [Page 13] RFC 4620 IPv6 Node Information Queries August 2006
情報が2006年8月に質問するクロフォードとハーバーマン実験的な[13ページ]RFC4620IPv6Node
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Crawford & Haberman Experimental [Page 14]
クロフォードとハーバーマンExperimentalです。[14ページ]
一覧
スポンサーリンク
