IPng Working Group Matt Crawford Internet Draft Fermilab August 28, 2000 IPv6 Node Information Queries 本メモの状態 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. 概要 この文書ではIPv6ノードに対して、その完全修飾ドメイン名といった特定の ネットワーク情報を尋ねるための実プロトコルを説明している。IPv6の実装の 経験により、DNS名を直接尋ねることは有用であることが明らかとなり、その 他の情報を直接尋ねる機構が必要とされている。 1. 用語 "Node Information(=ノード情報)(あるいは NI) Query" メッセージは "Querier" ノードから "Responder" ノードに対し、"Queried Address" に むけた ICMPv6 パケットで送られる。Query では "Queried Address" と 異なるかもしれない "Subject Address"、あるいは "Subject Name" に 関係する。Responder は Querier に対して "Node Information Reply" を 送り、それには Queries Address のノードに関連した情報を含む。 NI Query を受けとったノードは Reply を送らないとしても Responder と 呼ばれるものとする。 本文書においては、キーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は、[2119] に示された通りに解釈される。 Expires March 2, 2001 Crawford [Page 1] Internet Draft ICMP Name Lookups August 28, 2000 未使用と記されたパケットフィールドは 0 でなければならず、受信時は チェックサムやメッセージの完全性チェックは別として、無視されな ければならない。 2. ノード情報メッセージ(Node Information Messages) 2つの型の NI メッセージ、NI Query と NI Reply は ICMPv6 [2463] パケットで運ばれる。それらは同じ形式を持つ。 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 / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type 139 - NI Query 140 - NI Reply Code NI Query 用: 0 Data フィールドがこの Query で対象としている IPv6 アドレスを含むことを示す。 1 Data フィールドがこの Query で対象としているドメイン 名を含むことを示すか、NOOP か サポート済 Qtype 問い合わせであるときは空であることを示す。 2 Data フィールドがこの Query で対象としている IPv4 アドレスを含むことを示す。 NI Reply 用: Expires March 2, 2001 Crawford [Page 2] Internet Draft ICMP Name Lookups August 28, 2000 0 成功を示す。Reply Data は空かもしれないしそうでない かもしれない。 1 Responder が Query に対する返答を拒否したことを示す。 Reply Data は空である。 2 Responder にとって Qtype が未知であったことを示す。 Reply Data は空である。 Checksum ICMPv6 チェックサム Qtype Query で情報が要求された、あるいは Reply で返答された 場合の、型を示す16ビットのフィールド。Reply でのその値は、 Responder により、常に対応する Query からコピーされる。 本文書で 5 つの値が定義されている。 Flags 特定の Query 型とその返答毎に定義されているかもしれない、 Qtype 依存のフラグ。Qtype に対して Flags が未定義の場合、 送信時は 0 でなければならず、受信時は無視し、Qtype の 定義で決められている場合を除き、Reply にコピーしては ならない。 Nonce Reply と Query の対応や、なり済まし(spoofing)の回避を 補助するための不明確なフィールド。その値は Querier に よって選ばれる。Reply でのその値は、Responder により、 常に対応する Request からコピーされる。 Data Query においては、対象のアドレス(Subject Address) あるいは名前(Subject Name)。Reply においては、ICMPv6 コードフィールドが0のときしか存在しない、Qtype依存な データ。Data の長さは、IPv6 ヘッダの Payload Length フィールド [2460] 、NI パケットの固定の部分の長さ、 ICMPv6 ヘッダと間の拡張ヘッダの長さから推測できる。 Queryにおける Data フィールドに存在する情報の型はICMPコードで推測 され、Reply の Data フィールドの情報の型は、それがもしあれば、Qtype から推測される。 Query の対象が名前であるとき、その名前は DNS wire format [1035] で なければならない(MUST)。その名前は、ゼロ長のラベルで終端した完全修飾 ドメイン名(FQDN)、あるいは、2つのゼロ長ラベルが後続する単一DNSラベル をとることができる。問い合わせには最大でも1つのDNS名しか含まないので、 DNS圧縮は用いられない。 Expires March 2, 2001 Crawford [Page 3] Internet Draft ICMP Name Lookups August 28, 2000 3. メッセージ処理 Querier は ICMP NI Query を構成し、それを情報を必要とされている ノードへ送る。質問の対象が IPv6 アドレスである時、通常、その アドレスが Query の宛先アドレスとして用いられるが、もし、Querier が 対象ノードのアドレスについての先験的に有用な情報をもっているときは その必要はない。NI Query はまた、リンクローカルスコープ[2373]のマルチ キャストアドレスにも送ることもできる。 もし、対象が、完全修飾、または単一コンポーネントのドメイン名であり、 Querier が目的アドレスに対するユニキャストアドレスがわからないとき、 その問い合わせは次のように構成されたリンクスコープのマルチキャスト アドレスに送られなければならない(MUST)。対象名(Subject Name)は DNSセキュリティ [2535] で定義されるように規準名に変換され、 すべてのアルファベット文字は小文字に展開される。(もし、ホスト名を 示す追加的なDNSラベル型が定義されたときは、それらのラベルの規準化の 規則は規格で明らかにされるだろう。) 対象名の最初のラベル-最初の 1オクテットの長さフィールドの部分からはじまり、ただし、続く長さ フィールドを除く-についてMD5ハッシュ値 [1321] を計算し、128ビットの ハッシュ値の最初の32ビットをプレフィクス FF02:0:0:0:0:2::/96 に 加える。結果的に得られたマルチキャストアドレスは、その名前のための "NI Group Address" と呼ばれる。 Nonce はなりすましを妨げるため、乱数かよい疑似乱数値であるべきで ある。複数の独立なNI問い合わせ処理を許す実装では、Replyを正しい プロセスに届けるためにNonce値を用いることができる(MAY)。にも かかわらず、そのようなプロセスは受けとった Nonce を確認し、無関係の Reply を無視しなくてはならない(MUST)。 もし本当の通信の安全が必要なら、IPsec [2401] を使わなければならない。 NI Query を受け取ったら、Responder は Query の IPv6 宛先アドレスを 確認し、それが Responder のユニキャストアドレス、エニキャストアドレス、 または Responder が参加しているリンクローカルスコープのマルチキャスト のいずれかでなければ、それ以上の処理をすることなく、破棄しなければ ならない。典型的には、後者は Responder に属する名前用の NI Group Address か、Responder が代理サービスで提供している名前用の NI Group Address となる。ノードはその NI Group Address 以外のマルチキャスト アドレスへの NI Query を破棄するように設定してよいが、そうするなら、 デフォルトの設定は破棄するようにしてはならない。 Responder はまた Query の(Dataフィールド中の)対象アドレスまたは名前が そのノードに属さない場合、そのノードが(問い合わせ)対象のための代理 サービスを提供していなければ、Query をだまった破棄しなければならない。 Expires March 2, 2001 Crawford [Page 4] Internet Draft ICMP Name Lookups August 28, 2000 単一コンポーネントの対象名は、その最初のラベルが対象に一致するあらゆる 完全修飾名に一致する。すべての名前比較はDNSSEC名前正規化[2523]に適合 するように大文字小文字関係なしに行われる。 次に、もし Qtype が Responder に未知であれば、それは ICMPv6 Code = 2 で Reply Data のない NI Reply を返さなければならない。Responder はその ような返答について、それが ICMPv6 エラー返答[2464, 2.4(f)] のように、 速度制限を課すべきである。 次に、Responder は、ここでは規定されないローカルなポリシーに基づいて、 答えを拒否するかどうかを決定すべきである。返答が拒否されるとき、 Responder は ICMPv6 Code = 1 で Reply Data のない NI Reply を送る ことができる。また、Responder はそのような返答について、それが ICMPv6 エラー返答[2464, 2.4(f)] のように、速度制限を課すべきである。 ついに、Qtype が既知でローカルなポリシーで返答が許されたたら、 Responder は Qtype の定義に適合するように NI Reply に Flag と Reply Data を埋め、問い合わせされたアドレス(Queried Address)がエニキャスト またはマルチキャストアドレスでない場合、それと一致する ICMPv6発信元 アドレスで NI Reply を送信しなければならない。問い合わせされた アドレスがエニキャストまたはマルチキャストアドレスであった場合、 Replyにつく発信元アドレスは、Queryが受信したインタフェースに属する アドレスの1つであるべきである(SHOULD)。 もし Query がエニキャストまたはマルチキャストアドレスに送られたら、 IPv6近隣探索[2461] で定義されるように、Reply の送信は0から MAX_ANYCAST_DELAY_TIMEまでの乱数の間隔をあけなければならない(MUST)。 4. 定義済 Qtype 次の5つの Qtype が定義される。最初の4つ(0〜3)はこのプロトコルの いかなる実装でもサポートされなければならない(MUST)。最後の一つは いかなるIPv4/IPv6デュアルスタックノードでの実装でもサポートすべき (SHOULD)であり、IPv6専用ノードでもサポートしてよい(MAY)。 0 NOOP (無操作) 1 サポート済 Qtype 2 DNS 名 3 ノードアドレス 4 IPv4 アドレス Expires March 2, 2001 Crawford [Page 5] Internet Draft ICMP Name Lookups August 28, 2000 4.1. NOOP (無操作) この NI 型にフラグの定義はなく、決して Data フィールドをもたない。 NI NOOP Query に対する返答は、Querier に対して問い合わせされた アドレスが有効で到達可能であり、NIプロトコルを実装しているか、 そして付随的に、問い合わされたアドレスがエニキャストアドレスで あったかどうかが Querier にわかる。送信時、NOOP 問合せ中の ICMPv6 Code は 1 にセットされなければならず、 NOOP Reply では 0 にセット されなければならない。NOOP Query または Reply 受信時は、Code は 無視されなければならない。 4.2. サポート済 Qtype この Query は Data フィールドを含まない。Reply Data は、Responder が どの Qtype をサポートするかを示すビットベクトルである。その Reply Data は2つの異形式: 非圧縮および圧縮形式を持つ。非圧縮形式は1つ以上の 完全な32ビット語で、それぞれの語の最下位ビットが32ごとのQtypeの組中の 最小値に対応する。最初の語は、0〜31のQtypeのResponderの対応を示し、 2番目の語は32〜63、などとなる。 1 となっているビットは対応するQtypeへの対応を示す。最初の32ビット語の 最下位の4ビットは 1 になっていなければならず、それはこの規格で定義 されている、4つの必須Qtypeへの対応を示す。なので、必須Qtypeだけを実装 する Responder からのサポート済 Qtype NI 返答(NI Supported QTypes Reply)の Data フィールドには、次の形の32ビットを含むことになる: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 . . . 0 0 0 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reply Data における圧縮形式は、ブロックの連続からなり、それぞれの ブロックは2つの16ビット符号なし整数 nWord と nSkip 、それに続く 連続するサポート済 Qtype を示す nWord 個の 32ビットのビットマスク からなる。nSkip はそれに続くすべて0で抑制された32ビット語の個数で ある。最後のブロックは nSkip = 0 でなければならない(MUST)。例えば、 Qtype 0, 1, 2, 3, 60, 4097 をサポートする Responder は、その情報を 次のような Reply Data で表現できる (nWord と nSkip フィールドは読みやすいように10進数で書かれている): Expires March 2, 2001 Crawford [Page 6] Internet Draft ICMP Name Lookups August 28, 2000 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 126 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 . . . 0 0 0 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 0 0 . . . 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 . . . 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1つのフラグビットが定義されている。 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=1 | unused |C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ QueryではCフラグの 1 は Querier が圧縮形式の Reply Data を受け入れる ことを示す。Reply でCフラグの 1 は、Reply Data が圧縮されていることを 示す。Query のCフラグがセットされていた場合に限り、Reply での圧縮形式を 利用してよい(MAY)。本規格の実装は圧縮形式をサポートすべきであり (SHOULD)、もしサポートするなら、すべての(この) サポート済 Qtype Query で Cフラグをセットすべきであり(SHOULD)、そうすることで Reply の フラグメントを避け、または大きさを著しく節約することができるかもしれない よう、サポート済 Qtype Reply では(問い合わせの Cフラグで許されている 時は)圧縮形式を使うべきである(SHOULD)。 4.3. DNS 名 DNS名 NI Query 要求は、対象アドレスあるいは名前の、完全修飾または 単一コンポーネントの名前を要求する。Reply Data は次の形式をもつ。 Expires March 2, 2001 Crawford [Page 7] Internet Draft ICMP Name Lookups August 28, 2000 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DNS Names ... | + + / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TTL 名前がキャッシュされてよい秒数。DNS [1035] との互換性の ため、これは32ビット符号付き2の補数であるが、負であっては ならない。 DNS Names DNS wire 形式 [1035] で表現された、完全修飾、または単一 コンポーネント名、あるいは、対象アドレスに関係する Responder の名前(群)。応答者がドメインサフィックスを 知っているときはそれぞれの名前は完全修飾ドメイン名、 さもなくば、単一DNSラベルに2つの長さ0のラベルが続か なければならない(MUST)。 もし複数のDNS名が返るとき、DNS名圧縮[1035]が使われるべき であり、そのオフセットはDataフィールドの先頭から数え られる。例えば、4というオフセットは最初の名前の先頭を 示すことになる。 Responder は Reply の TTL フィールドを可能なら意味のある値で埋め なければならない。その値は次のいずれかであるべきである。 対象アドレスのDHCP開放までの残存時間(lifetime); ステートレスアドレス自動設定[2461, 2462]で配られた対象アドレスの プレフィクスの残存有効時間(Valid Lifetime); 対象アドレスと返されようとしている名前を関連づけるAAAAあるいは A6アドレスレコードのTTL値。 もし Responder が複数の名前を返したが、ひとつのだけを正式、あるいは 規準的と考えるとき、その名前はTTLの直後に位置しなければならない(MUST)。 Expires March 2, 2001 Crawford [Page 8] Internet Draft ICMP Name Lookups August 28, 2000 ひとつのTTLだけが返答に含まれる。もしResponderが複数の名前を複数の 時間でキャッシュ可能と考えるなら、そのTTLフィールドはそれらの時間の 最小値より大きくてはならない。 もしResponderが名前を知らないときは、TTL=0とし、ひとつもDNS名を 返してはならない(MUST)。Querierはパケット長からDataフィールドがTTL しか含まないことを決定できるだろう。 Replyに対してのみ、1つのフラグビットが定義される。 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=2 | 未使用 |T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NI DNS名 Reply におけるTフラグの1は、TTLフィールドの値が意味のある ものであることを示す。Tフラグが0なら、TTL値は Responder によって 0 とされるべきであり(SHOULD)、Querierはそれを無視しなければならない (MUST)。 もし、アドレスでなく名前が Query の対象でありとき、Tフラグは 0 でなければらなず(MUST)、TTLは0であるべきである(SHOULD)。 Tフラグ 1 の NI DNS Name Reply の情報は、その TTLで示された時間だけ キャッシュされ得る。もし TTL をもたない (Tフラグ 0)場合、対応する その Reply 中の情報は一度以上利用してはならない。もし Query が DNS サーバによりDNSクライアントの代理として送信された場合、その結果を そのクライアントへTTL 0 で返してよい。とはいえ、もしそのサーバが 一致する AAAA レコードを、キャッシュ中あるいは信ずべきゾーン (authoritative zone)に持つ場合には、そのレコードの TTL を、NI DNS Name Reply の存在しない TTL として扱ってよく、返答に含まれる情報は その期間だけキャッシュし、利用してよい。 受け取った NI DNS名 NI Reply に一致する AAAA あるいは A6 レコードへの 問い合わせをサーバが実行することもサーバの実装の選択となるだろう。 これは Reply をキャッシュ可能とし、あるいは DNS名 Query を引き起こした クライアント Reply がそのような AAAA 検索を行うことを予期して行われる のかも知れない。 4.3.1. 議論 ノードが起動していて到達可能な場合だけ DNS Name Request に答えられる ので、例えばサブネットやサイト毎といった、ノード群用の代理応答者を 作ることも有用かもしれない。そのような機構はここでは定義しない。 Expires March 2, 2001 Crawford [Page 9] Internet Draft ICMP Name Lookups August 28, 2000 得られる情報の信頼性の大幅な向上のため、IPsec を NI DNS名 メッセージに 適用することができるが、QuerierとResponderの間で行われている(あるいは 行われようとしている)他の通信IPsecに直接適用することによりそのような 必要は不要となるかもしれない。 4.4. ノードアドレス NI ノードアドレス要求(NI Node Address Query) は Responder のいくらかの IPv6ユニキャストアドレスのセットを要求する。Reply Data は 128ビットの IPv6 アドレス、それぞれのアドレスに先立つ 32 ビットの TTL値の並びで あり、推奨アドレスが非推奨アドレス[2461]に先行するが、その他は順不同で ある。5つのフラグが Query に、6つのフラグが Reply に定義される。 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G 1なら、グローバルスコープアドレス [2374] が要求される S 1なら、サイトローカルアドレス [2374] が要求される L 1なら、リンクローカルアドレス [2374] が要求される C 1なら、IPv4互換と写像アドレス [2373] が要求される A 1 なら、Responderのすべての(スコープに適合する)ユニキャスト アドレスが要求される。0なら、対象アドレス(あるいは対象名)を もつその(あるいはある)インタフェースに属するそれらのアドレス だけが要求される T Reply でのみ定義され、アドレスのセットが空間的問題で不完全で あることを示す G, S, L, C および A フラグは Query から対応する Reply にコピーされる。 各アドレスに関連づけられたTTLは第5.3章の規則で決定され、自動設定 有効期間を除き、(問い合わせ)対象よりむしろ返されたアドレスに適用される。 もしアドレスに対して無意味なキャッシング時間が提供されるかもしれない ときは、対応する TTL フィールドは 0 でなければならない(MUST)。 Expires March 2, 2001 Crawford [Page 10] Internet Draft ICMP Name Lookups August 28, 2000 NI Node Address Reply の中の 非0 TTL を伴った アドレスは、その TTL で示された時間だけキャッシュされ得る。もし TTL が 0 の場合、対応する アドレスは一度以上利用してはならない。もし Query が DNSサーバにより DNSクライアントの代理として送信された場合、その結果をそのクライアントへ TTL 0 で返してよい。 IPv4写像アドレスはIPv4専用ノードのアドレスを示し、(それらは) 必然的にこのプロトコルを実装しないので、(IPv4写像アドレスは) NIプロキシによってのみ返される。 4.5. IPv4 Addresses NI IPv4アドレス要求(NI IPv4 Address Query) は Responder のいくらかの IPv4アドレスのセットを要求する。Reply Data は 32ビットの IPv4 アドレス、それぞれのアドレスに先立つ 32 ビットの TTL値の並びである。 1つのフラグが Query に、2つのフラグが Reply に定義される。 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A 1 の場合、Responder のすべてのユニキャストアドレスが要求されて いる。0 の場合、Subject Address をもつインタフェース(あるいは どれかひとつのインタフェース)に属するアドレスが要求されている T Reply でのみ定義され、アドレスのセットが空間的理由で不完全である ことを示す。 Flag A は Query から対応する Reply にコピーされる。 各アドレスに関連づけられたTTLは第5.3章の規則で決定され、自動設定 有効期間を除き、Subject よりむしろ返されたアドレスに適用される。 もしアドレスに対して無意味なキャッシング時間が提供されるかもしれない ときは、対応する TTL フィールドは 0 でなければならない(MUST)。 NI IPv4 Address Reply の中の 非0 TTL を伴った アドレスは、その TTL で示された時間だけキャッシュされ得る。もし TTL が 0 の場合、対応する アドレスは一度以上利用してはならない。もし Query が DNSサーバにより DNSクライアントの代理として送信された場合、その結果をそのクライアントへ TTL 0 で返してよい。 Expires March 2, 2001 Crawford [Page 11] Internet Draft ICMP Name Lookups August 28, 2000 4.5.1. 議論 ノードはIPv4インタフェースとIPv6インタフェースを、たとえそれが 同じハードウェアに割り当てられていたとしても、全く別なものと扱う ことができる。もしそのようなノードが他のタイプを要求する Subject Address をもち、Query の A フラグが 0 になっている NI Query に 返答するとき、トンネル以外の同一のハードウェアに関係している IP インタフェースを考えるべき(SHOULD)である。 5. IANA 考察 ICMPv6 タイプ 139 および 140 は、このプロトコルのため、すでに IANA により割り当てられている。本文書ではこれらそれぞれの ICMPv6 タイプ値 毎に0〜2の3つの ICMPv6 コードを定義している。追加的な値は IETF 合意 [2434] によってのみ定義されるだろう。 本文書では0〜4の5つの Qtype の値を定義している。次ようなポリシーが "Guidelines for Writing an IANA Considerations Section in RFCs" [2434]に示されており、新しい値、関係する Flag 、そして Reply は次の ように定義されるだろう。 5〜255 までの Qtype, IETF Consensus による 256〜1023, 規格化が必要 1024〜4095, 早い者勝ち(First Come First Served) 4096〜65535, プライベート利用 プライベート利用の使用者は、8000から9000より大きなその値は、Reply Data 用の圧縮がされないと、"Supported Qtypes"の断片化につながって しまいそうだ、ということに注意しなければならない。 第3章(Section 3)で使われたマルチキャストアドレスプレフィクス FF02:0:0:0:0:2::/96 は、IPv6 Node Information Queries の宛先 アドレスとして割り当てが必要である。 6. セキュリティ考察 なりすまし対策の Nonce は、Query と Reply を覗き見できるなりすまし者 (spoofer)に対しては、なんの防護にもならない。 比較的頻繁にリナンバリングの行われるインターネットにおいては、 アドレス-名前変換に使われるゾーンのKEYとSIGレコード[2535]の管理は NS,SOA,PTRレコードそのものの管理に比べて決して簡単ではなく、そして Expires March 2, 2001 Crawford [Page 12] Internet Draft ICMP Name Lookups August 28, 2000 これは多くの場合困難であることがわかってきている。それゆえ、著者は元の DNS機構であろうがこの新しい機構であろうが、アドレス-名前マッピングは、 返された名前を索引としてより信頼できる情報を探すためのヒントとしてだけ 使われるだろうと思っている。 7. 謝辞 Alain Durand がこの規格に貢献し、価値ある還元と実験的実装が萩野 純一郎と神明達也から提供された。本文書がアドレス-名前変換を直接 問い合わせる機構の最初の提案ではない。そのアイディアはIPng作業班で 簡単に議論され、RFC 1788 [1788] はIPv4のためのそのような機構を 説明している。 8. 参考文献 [1035] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 1035, STD 13, November 1987. [1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788, April 1995. [2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997. [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [2434] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. [2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Expires March 2, 2001 Crawford [Page 13] Internet Draft ICMP Name Lookups August 28, 2000 [2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [2535] D. Eastlake 3rd, "Domain Name System Security Extensions", RFC 2535, March 1999. 9. 著者の聯絡先 Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA Phone: +1 630 840 3461 Email: crawdad@fnal.gov Expires March 2, 2001 Crawford [Page 14] 訳者: 吉藤英明