|
Network Working Group Request for Comments: 2463 Obsoletes: 1885 Category: Standards Track |
A. Conta Lucent S. Deering Cisco Systems December 1998 |
このドキュメントは、インターネット社会の為のインターネット標準トラックプロトコルを規定しており、改善の為の議論と提案を求めている。このプロトコルの標準化の状態と状況については、"Internet Official Protocol Standards" (STD 1) の現在の版を参照されたい。このメモの配布は制限されない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
このドキュメントは、インターネットプロトコルのバージョン 6 (IPv6) と共に使用される、インターネット制御メッセージプロトコル (ICMP) のセットを規定する。
Table of Contents
1. 導入
2. ICMPv6 (IPv6 用の ICMP)
2.1 メッセージの一般形式
2.2 メッセージの送信元アドレス決定
2.3 メッセージチェックサム計算
2.4 メッセージ処理規則
3. ICMPv6 エラーメッセージ
3.1 宛先未到達メッセージ
3.2 パケットサイズ超過メッセージ
3.3 時間超過メッセージ
3.4 パラメタ問題メッセージ
4. ICMPv6 情報メッセージ
4.1 エコー要求メッセージ
4.2 エコー応答メッセージ
5. セキュリティの考慮
5.1 ICMP メッセージの認証とカプセル化
5.2 ICMP 攻撃
6. 参照
7. 謝辞
8. 作者のアドレス
付録 A - RFC 1885 からの変更点
完全なコピーライト宣言
インターネットプロトコルバージョン 6 (IPv6) は、IP の新しいバージョンである。IPv6 は IPv4 [RFC-792] で定義されたものを数多く変更した、インターネット制御メッセージプロトコル (ICMP) を使用する。結果的に作成されたプロトコルは ICMPv6 と呼ばれ、IPv6 次ヘッダ値は 58 である。
このドキュメントは、ICMPv6 で使用された制御メッセージのセットの形式を規定する。このドキュメントは、パス MTU 検出の様な機能を達成するためにこれらのメッセージを使用するための手続きは規定しない。そうした手続きは、他のドキュメントで規定される (例えば [PMTU])。他のドキュメントではさらに、例えば隣接者検出メッセージ [IPv6-DISC] 追加の ICMPv6 メッセージタイプを導入している。それらは、このドキュメントのセクション 2 で示されている ICMPv6 メッセージのための一般規則に従っている。
IPv6 規定 [IPv6] で定義された用語や、IPv6 ルーティングとアドレス付け規定 [IPv6-ADDR] は、このドキュメントにも適用される。
このドキュメント中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は、[RFC-2119] で規定された解釈と同じである。
ICMPv6 はパケットを処理する際に遭遇したエラーを通知したり、他のインターネット層機能、例えば診断 (ICMPv6 "ping") を実現するために、IPv6 ノードによって使用される。ICMPv6 は IPv6 に不可欠な一部であり、あらゆる IPv6 ノードも完全に実装しなければならない (MUST)。
ICMPv6 メッセージは二つのクラス、エラーメッセージと情報メッセージにグループ化される。エラーメッセージは、メッセージタイプフィールドの最上位ビットが 0 であると識別される。従って、エラーメッセージのメッセージタイプは 0 〜 127 であり、情報メッセージのメッセージタイプは 128 〜 255 である。このドキュメントは、以下の ICMPv6 メッセージのメッセージ形式を定義する。
ICMPv6 エラーメッセージ 1 宛先未到達 (セクション 3.1 参照) 2 パケットサイズ超過 (セクション 3.2 参照) 3 時間超過 (セクション 3.3 参照) 4 パラメタ問題 (セクション 3.4 参照) ICMPv6 情報メッセージ 128 エコー要求 (セクション 4.1 参照) 129 エコー応答 (セクション 4.2 参照)
全ての ICMPv6 メッセージは、IPv6 ヘッダと 0 個以上の IPv6 拡張ヘッダの後ろに続く。ICMPv6 ヘッダは、直前のヘッダの次ヘッダフィールドの値 58 によって識別される。(注記: これは IPv4 で ICMP を識別するために使用された値とは異なる)。
ICMPv6 メッセージは、以下の一般的な形式を持つ。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Message Body + | |
タイプフィールドはメッセージのタイプを識別する。その値は残りのデータの形式を決定する。
コードフィールドはメッセージのタイプによる。これは、メッセージ精度の付加レベルを生成するために使用される。
チェックサムフィールドは、ICMPv6 メッセージと IPv6 ヘッダの一部のデータ破損を検出するために使用される。
ICMPv6 メッセージを送信するノードは、チェックサムを計算する前に、送信元と宛先 IPv6 ヘッダの両方を決定しなければならない。もしノードが一つ以上のユニキャストアドレスを持つならば、送信元は以下のようにメッセージの送信元アドレスを選択しなければならない。
チェックサムは、[IPv6, セクション 8.1] で規定されている IPv6 ヘッダフィールドの "擬似ヘッダ" (直前にある) と、ICMPv6 メッセージタイプフィールドから始まる ICMPv6 メッセージ全体の 1 の補数の合計の 16 ビットの 1 の補数である。擬似ヘッダで使用される次ヘッダの値は 58 である。(注記: ICMPv6 チェックサムに擬似ヘッダを含めることは、IPv4 からの変更点である。この変更の原理については [IPv6] を参照されたい)。
チェックサムを算出するために、チェックサムフィールドを 0 に設定する。
実装体は ICMPv6 メッセージを処理する際、以下の規則を守らなければならない (MUST)。([RFC-1122] より)
以降のセクションは、上記の ICMPv6 メッセージのメッセージ形式について規定する。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMPv6 パケットが IPv6 MTU [IPv6]の | + 最小値を超えないだけの起動パケット + | |
Destination Address
起動パケットの送信元アドレスフィールドからコピーされる。
Type
1
Code
0 - 宛先までの経路が無い
1 - 宛先との通信が管理上禁止されている
2 - (未割り当て)
3 - 宛先未到達
4 - ポート未到達
Unused
このフィールドは全てのコードの値で使用されない。このフィールドは、送信側が
0 に初期化しなければならず、受信側は無視しなければならない。
宛先未到達メッセージは、輻輳以外の理由により宛先まで配送できないパケットの応答として、ルータか起動ノードの
IPv6 層が生成すべきである (SHOULD)。(もし輻輳によってパケットを落とすならば、ICMPv6
メッセージを生成してはならない (MUST NOT))。
もし、配送失敗の理由が転送ノードのルーティングテーブル中に一致するエントリが存在しないということならば、Code フィールドに 0 を設定する (注記: このエラーは自身のルーティングテーブルに "デフォルト経路" を持たないノードでしか起こり得ない)。
もし、配送失敗の理由が "ファイアウォールフィルタ" などの管理上の禁止ならば、Code フィールドに 1 を設定する。
もし、配送失敗が例えば IPv6 宛先アドレスを対応するリンクアドレスに変換できないことや、ある種のリンク特定の問題等の他の理由によるものならば、Code フィールドに 3 を設定する。
宛先ノードは、トランスポートプロトコル (例えば UDP) でリッスンされていないパケットに対する応答として、もしそのトランスポートプロトコルが送信側にそのことを通知する代替手段を持たないならば、Code が 4 の宛先未到達メッセージを送信すべきである (SHOULD)。
ICMPv6 宛先未到達メッセージを受信したノードは、上位層プロセスに通知しなければならない (MUST)。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMPv6 パケットが IPv6 MTU [IPv6]の | + 最小値を超えないだけの起動パケット + | |
Destination Address
起動パケットの送信元アドレスフィールドからコピーされる。
Type
2
Code
送信側は 0 に設定し、受信側は無視する。
MTU
次ホップのリンクの最大転送単位。
パケットサイズ超過は、パケットが出力回線の MTU よりも大きいために転送できないパケットの応答として、ルータが送信しなければならない (MUST)。このメッセージ中の情報は、パス MTU 検出処理 [PMTU] の一部で使用される。
パケットサイズ超過の送信は、ICMPv6 エラーメッセージをいつ送信するかについての規則の一つに対する例外であり、他のメッセージとは異なり、IPv6 マルチキャスト宛先アドレスか、リンク層ブロードキャストアドレスが指定されて受信したパケットの応答で送信される。
受信したパケットサイズ超過メッセージは、上位層プロセスに渡さなければならない (MUST)。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMPv6 パケットが IPv6 MTU [IPv6]の | + 最小値を超えないだけの起動パケット + | |
Destination Address
起動パケットの送信元アドレスフィールドからコピーされる。
Type
3
Code
0 - 転送時のホップ制限超過
1 - フラグメント組立時間超過
Unused
このフィールドは全てのコードの値で使用されない。このフィールドは、送信側が
0 に初期化しなければならず、受信側は無視しなければならない。
もしルータがホップ制限が 0 のパケットを受信したか、パケットのホップ制限を減らして 0 になったら、そのパケットを破棄してコード 0 の ICMPv6 時間超過メッセージをパケットの送信元に送信しなければならない (MUST)。これは、ルーティングループか初期ホップ制限値が小さ過ぎることを示す。
このメッセージの送信元アドレスを選択する規則は、セクション 2.2 で定義されている。
受信した時間超過メッセージは、上位層プロセスに渡さなければならない (MUST)。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMPv6 パケットが IPv6 MTU [IPv6]の | + 最小値を超えないだけの起動パケット + | |
Destination Address
起動パケットの送信元アドレスフィールドからコピーされる。
Type
4
Code
0 - 異常なヘッダフィールドに遭遇した
1 - 未知の次ヘッダタイプに遭遇した
2 - 未知の IPv6 オプションに遭遇した
Pointer
エラーを検出した起動パケット内のオクテットオフセットを識別する。
ポインタは、もし異常なフィールドが ICMPv6 エラーメッセージの最大長に収まる部分を超えたところにあるならば、ICMPv6 パケットの終端を超えた所を指すだろう。
もしパケットを処理している IPv6 ノードが、パケットの処理を完了できないような IPv6 ヘッダか拡張ヘッダを検出したら、そのパケットを破棄しなければならず (MUST)、問題のタイプと場所を示す ICMPv6 パラメタ問題メッセージをそのパケットの送信元に送信すべきである (SHOULD)。
ポインタは、異常が検出された元のパケットのヘッダのオクテットを識別する。例えば、タイプフィールド = 4、コードフィールド = 1、ポインタフィールド = 40 の ICMPv6 メッセージは、元のパケットの IPv6 ヘッダに続く IPv6 拡張ヘッダが、未知の次ヘッダフィールド値を保持していることを示す。
受信した時間超過メッセージは、上位層プロセスに渡さなければならない (MUST)。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-
Destination Address
正しい IPv6 アドレス
Type
128
Code
0
Identifier
このエコー要求に対するエコー応答の対応付けを補助する識別子。0 でもよい。
Sequence Number
このエコー要求に対するエコー応答の対応付けを補助するシーケンス番号。0
でもよい。
Data
0 個以上の任意のデータ。
全てのノードは、エコー要求を受信し、それに対応するエコー応答を送信する ICMPv6 エコー応答機能を実装しなければならない (MUST)。ノードは診断の目的のために、エコー要求を送信し、エコー応答を受信するアプリケーション層インタフェースも実装すべきである (SHOULD)。
エコー要求メッセージは、ICMP メッセージを受信するプロセスに渡してもよい (MAY)。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-
Destination Address
エコー要求パケットの送信元アドレスフィールドからコピーされる。
Type
129
Code
0
Identifier
起動されたエコー要求メッセージの識別子。
Sequence Number
起動されたエコー要求メッセージのシーケンス番号。
Data
起動されたエコー要求メッセージのデータ。
全てのノードは、エコー要求を受信して、それに対応するエコー応答を送信する ICMPv6 エコー応答機能を実装しなければならない (MUST)。ノードは診断のために、エコー要求を送信してエコー応答を受信するためのアプリケーション層インタフェースも実装すべきである (SHOULD)。
ユニキャストのエコー要求メッセージに対して送信されたエコー応答の送信元アドレスは、そのエコー要求メッセージの宛先アドレスと同じでなければならない (MUST)。
IPv6 マルチキャストアドレスに送信されたエコー要求メッセージの応答として、エコー応答を送信すべきである (SHOULD)。応答の送信元アドレスは、マルチキャストエコー要求メッセージを受信したインタフェースに属するユニキャストアドレスでなければならない (MUST)。
ICMPv6 エコー要求メッセージで受信したデータは、ICMPv6 エコー応答メッセージに、全体を変更せずに返却しなければならない (MUST)。
エコー応答メッセージは、エコー要求メッセージを起動したプロセスに渡さなければならない (MUST)。エコー要求メッセージを起動しなかったプロセスに渡してもよい。
ICMP プロトコルパケット交換は、IP 認証ヘッダを使用して認証することが可能である [IPv6-AUTH]。もし IP 認証ヘッダを使用したセキュリティアソシエーションが宛先アドレスに対して存在するならば、ノードは ICMP メッセージを送信する時、認証ヘッダを含むべきである (SHOULD)。セキュリティアソシエーションは、手動設定かある鍵管理プロトコルの操作を通じて生成されたかもしれない。
ICMP パケット中で受信した認証ヘッダは、正当性を照合しなければならず (MUST)、不正な認証を持つパケットは無視し、破棄しなければならない (MUST)。
認証ヘッダかカプセル化セキュリティペイロードのいずれかを使用して認証されない全ての ICMP メッセージを無視するよう、システム管理者がノードを設定することを可能にすべきである (SHOULD)。その設定は、デフォルトでは未認証メッセージを許可すべきである (SHOULD)。
機密性の問題は、IP セキュリティ体系と IP カプセル化セキュリティペイロードのドキュメントで取り上げられている。
ICMP メッセージは様々な攻撃を受けやすい。完全な議論については、IP セキュリティ体系 [IPv6-SA] に示されている。そうした攻撃や防護の簡潔な議論については、以下の通りである。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6, (IPv6) Specification", RFC 2460, December 1998.
[IPv6-ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[IPv6-DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC-1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 5, RFC 1122, August 1989.
[PMTU] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPv6-Auth] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[IPv6-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
このドキュメントは、SIPP と IPng ワーキンググループの以前の ICMP ドラフトに由来している。
IPng ワーキンググループや特に Robert Elz, Jim Bound, Bill Simpson, Thomas Narten, Charlie Lynn, Bill Fink, Scott Bradner, Dimitri Haskin, Bob Hinden (年代順) は、広範囲なレビュー情報とフィードバックを提供してくれた。
Alex Conta Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742 USA Phone: +1 978 287-2842 EMail: aconta@lucent.com
Stephen Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 527-8213 EMail: deering@cisco.com
Version 2-02
Version 2-01
Version 2-00
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
(このドキュメントと翻訳は全体または一部を、如何なる種類の制限無しで、上記のコピーライト記述を提供し、このパラグラフを全てのコピーや派生作業に含めて、他者へコピーや供給してもよく、コメントしたり、別途説明したり、実装を援助するといった派生作業を準備、コピー、出版、配布してもよい。しかし、このドキュメント自身は、インターネット標準プロセスで定義された手続きに従わなければならず、インターネット標準を開発する目的で必要な場合や、英語以外の言語に翻訳するために必要な場合を除いて、コピーライト記述やインターネット社会、他のインターネット組織への参照等を、如何なる方法でも修正してはならない。
上記で認められた制限された許可は永久的であり、インターネット社会や継承者や割当て者によって無効にされることはないだろう。)
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.