Network Working Group
Request for Comments: 2463
Obsoletes: 1885
Category: Standards Track
A. Conta
Lucent
S. Deering
Cisco Systems
December 1998

Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification

このメモのステータス

このドキュメントは、インターネット社会の為のインターネット標準トラックプロトコルを規定しており、改善の為の議論と提案を求めている。このプロトコルの標準化の状態と状況については、"Internet Official Protocol Standards" (STD 1) の現在の版を参照されたい。このメモの配布は制限されない。

Copyright Notice

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract

このドキュメントは、インターネットプロトコルのバージョン 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 からの変更点

完全なコピーライト宣言



1. 導入

インターネットプロトコルバージョン 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] で規定された解釈と同じである。

2. ICMPv6 (IPv6 用の ICMP)

ICMPv6 はパケットを処理する際に遭遇したエラーを通知したり、他のインターネット層機能、例えば診断 (ICMPv6 "ping") を実現するために、IPv6 ノードによって使用される。ICMPv6 は IPv6 に不可欠な一部であり、あらゆる IPv6 ノードも完全に実装しなければならない (MUST)。

2.1 メッセージの一般形式

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 ヘッダの一部のデータ破損を検出するために使用される。

2.2 メッセージの送信元アドレス決定

ICMPv6 メッセージを送信するノードは、チェックサムを計算する前に、送信元と宛先 IPv6 ヘッダの両方を決定しなければならない。もしノードが一つ以上のユニキャストアドレスを持つならば、送信元は以下のようにメッセージの送信元アドレスを選択しなければならない。

  1. もしメッセージがノードのユニキャストアドレスの一つに送信されたメッセージに対する応答ならば、応答の送信元アドレスはそれと同じアドレスでなければならない。

  2. もしメッセージが、ノードがメンバに入っているマルチキャストかエニイキャストのグループに送信されたメッセージに対する応答ならば、応答の送信元アドレスは、マルチキャストかエニイキャストパケットを受信したインタフェースに属するユニキャストアドレスでなければならない。

  3. もしメッセージが、ノードに属さないユニキャストアドレスに送信されたメッセージに対する応答ならば、応答の送信元アドレスは、エラーを診断するために最も効果的なノードに属しているユニキャストアドレスであるべきである。例えば、もしメッセージが、正常に完了できないパケット転送動作に対する応答ならば、送信元アドレスはパケット転送が失敗したインタフェースに属するユニキャストアドレスであるべきである。

  4. さもなくば、そのメッセージを宛先に送信するために使用されたインタフェースを決定するために、ノードのルーティングテーブルをチェックしなければならず、そのインタフェースに属しているユニキャストアドレスを、ルッセージの送信元アドレスとして使用しなければならない。

2.3 メッセージチェックサム計算

チェックサムは、[IPv6, セクション 8.1] で規定されている IPv6 ヘッダフィールドの "擬似ヘッダ" (直前にある) と、ICMPv6 メッセージタイプフィールドから始まる ICMPv6 メッセージ全体の 1 の補数の合計の 16 ビットの 1 の補数である。擬似ヘッダで使用される次ヘッダの値は 58 である。(注記: ICMPv6 チェックサムに擬似ヘッダを含めることは、IPv4 からの変更点である。この変更の原理については [IPv6] を参照されたい)。

チェックサムを算出するために、チェックサムフィールドを 0 に設定する。

2.4 メッセージ処理規則

実装体は ICMPv6 メッセージを処理する際、以下の規則を守らなければならない (MUST)。([RFC-1122] より)

  1. もし未知のタイプの ICMPv6 エラーメッセージを受信したら、それを上位層に渡さなければならない (MUST)。

  2. もし未知のタイプの ICMPv6 情報メッセージを受信したら、黙って破棄しなければならない (MUST)。

  3. 全ての ICMPv6 エラーメッセージ (タイプ < 128) は、エラーメッセージパケットが IPv6 MTU [IPv6] の最小値を超えない程度の、IPv6 の発端となった (起動) パケット (エラーを引き起こしたパケット) を含める。

  4. インターネット層プロトコルが ICMPv6 パケットを上位層に渡す必要がある場合、その上位層のプロトコルタイプは元のパケット (ICMPv6 エラーメッセージの本体に含まれる) から取り込み、そのエラーを扱う適切な上位層プロセスを選択するために使用する。

    もし元のパケットが異常に大きなサイズの拡張ヘッダを持っていたら、IPv6 MTU [IPv6] の最小値制限に合わせて元のパケットを取り除くことによって、上位層プロトコルタイプが ICMPv6 メッセージに存在しないことが有り得る。その場合、エラーメッセージは、IPv6 層の処理後に黙って落とす。

  5. ICMPv6 エラーメッセージは、以下を受信した結果で送信してはならない (MUST NOT)。

    1. ICMPv6 エラーメッセージ。

    2. IPv6 マルチキャストアドレス宛てのパケット (この規則には二つの例外がある: (1) パス MTU 検出が IPv6 マルチキャストで動作することを可能にするためのパケットサイズ超過メッセージ - セクション 3.2。(2) オプションタイプの最上位 2 ビットが 10 に設定された、認識できない IPv6 オプションのパラメタ問題メッセージ - セクション 3.4)。

    3. リンク層マルチキャストとして送信されたパケット (e.2 の例外はこのケースにも適用される)。

    4. リンク層ブロードキャストとして送信されたパケット (e.2 の例外はこのケースにも適用される)。

    5. 送信元アドレスがユニークに一つのノードを識別できないパケット、例えば IPv6 未指定アドレス、IPv6 マルチキャストアドレス、ICMP メッセージ送信側によって IPv6 エニイキャストアドレスとして認識されたアドレス。

  6. 最後に、送信側 ICMPv6 エラーメッセージで被る帯域や転送コストを制限するために、IPv6 ノードは送信する ICMPv6 エラーメッセージの割合を制限しなければならない (MUST)。この状況は、異常なパケットのストリームを送信している送信元が、ICMPv6 エラーメッセージの結果に注意を払えなかった時に起こるかもしれない。レートを制限する機能の実装には様々な方法がある。例えば以下のもの。

    1. 時間ベース、例えば指定した送信元、あるいは全ての送信元に対して、最大 T ミリ秒毎につき 1 回に、エラーメッセージの送信レートを制限する。

    2. 帯域ベース、例えば特定のインタフェースから送信されるエラーメッセージを、接続された回線の帯域分の F に制限する。

    制限するパラメタ (例えば上記の例の T や F) は、保守的なデフォルト値 (例えば T = 1 秒で 0 秒ではない、あるいは F = 2 パーセントで 100 パーセントではない) を持って、ノードが設定可能でなければならない (MUST)。

以降のセクションは、上記の ICMPv6 メッセージのメッセージ形式について規定する。

3. ICMPv6 エラーメッセージ

3.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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Unused                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             ICMPv6 パケットが IPv6 MTU [IPv6]の               |
+             最小値を超えないだけの起動パケット                +
|                                                               |
IPv6 Fields:

Destination Address

起動パケットの送信元アドレスフィールドからコピーされる。

ICMPv6 Fields:

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)。

3.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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             MTU                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             ICMPv6 パケットが IPv6 MTU [IPv6]の               |
+             最小値を超えないだけの起動パケット                +
|                                                               |
IPv6 Fields:

Destination Address

起動パケットの送信元アドレスフィールドからコピーされる。

ICMPv6 Fields:

Type

2

Code

送信側は 0 に設定し、受信側は無視する。

MTU

次ホップのリンクの最大転送単位。

説明

パケットサイズ超過は、パケットが出力回線の MTU よりも大きいために転送できないパケットの応答として、ルータが送信しなければならない (MUST)。このメッセージ中の情報は、パス MTU 検出処理 [PMTU] の一部で使用される。

パケットサイズ超過の送信は、ICMPv6 エラーメッセージをいつ送信するかについての規則の一つに対する例外であり、他のメッセージとは異なり、IPv6 マルチキャスト宛先アドレスか、リンク層ブロードキャストアドレスが指定されて受信したパケットの応答で送信される。

上位層への通知

受信したパケットサイズ超過メッセージは、上位層プロセスに渡さなければならない (MUST)。

3.3 時間超過メッセージ

 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]の               |
+             最小値を超えないだけの起動パケット                +
|                                                               |
IPv6 Fields:

Destination Address

起動パケットの送信元アドレスフィールドからコピーされる。

ICMPv6 Fields:

Type

3

Code

0 - 転送時のホップ制限超過
1 - フラグメント組立時間超過

Unused

このフィールドは全てのコードの値で使用されない。このフィールドは、送信側が 0 に初期化しなければならず、受信側は無視しなければならない。

説明

もしルータがホップ制限が 0 のパケットを受信したか、パケットのホップ制限を減らして 0 になったら、そのパケットを破棄してコード 0 の ICMPv6 時間超過メッセージをパケットの送信元に送信しなければならない (MUST)。これは、ルーティングループか初期ホップ制限値が小さ過ぎることを示す。

このメッセージの送信元アドレスを選択する規則は、セクション 2.2 で定義されている。

上位層への通知

受信した時間超過メッセージは、上位層プロセスに渡さなければならない (MUST)。

3.4 パラメタ問題メッセージ

 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]の               |
+             最小値を超えないだけの起動パケット                +
|                                                               |
IPv6 Fields:

Destination Address

起動パケットの送信元アドレスフィールドからコピーされる。

ICMPv6 Fields:

Type

4

Code

0 - 異常なヘッダフィールドに遭遇した
1 - 未知の次ヘッダタイプに遭遇した
2 - 未知の IPv6 オプションに遭遇した

Pointer

エラーを検出した起動パケット内のオクテットオフセットを識別する。

ポインタは、もし異常なフィールドが ICMPv6 エラーメッセージの最大長に収まる部分を超えたところにあるならば、ICMPv6 パケットの終端を超えた所を指すだろう。

説明

もしパケットを処理している IPv6 ノードが、パケットの処理を完了できないような IPv6 ヘッダか拡張ヘッダを検出したら、そのパケットを破棄しなければならず (MUST)、問題のタイプと場所を示す ICMPv6 パラメタ問題メッセージをそのパケットの送信元に送信すべきである (SHOULD)。

ポインタは、異常が検出された元のパケットのヘッダのオクテットを識別する。例えば、タイプフィールド = 4、コードフィールド = 1、ポインタフィールド = 40 の ICMPv6 メッセージは、元のパケットの IPv6 ヘッダに続く IPv6 拡張ヘッダが、未知の次ヘッダフィールド値を保持していることを示す。

上位層への通知

受信した時間超過メッセージは、上位層プロセスに渡さなければならない (MUST)。

4. ICMPv6 情報メッセージ

4.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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Data ...                                                   
+-+-+-+-+-                                                       
IPv6 Fields:

Destination Address

正しい IPv6 アドレス

ICMPv6 Fields:

Type

128

Code

0

Identifier

このエコー要求に対するエコー応答の対応付けを補助する識別子。0 でもよい。

Sequence Number

このエコー要求に対するエコー応答の対応付けを補助するシーケンス番号。0 でもよい。

Data

0 個以上の任意のデータ。

説明

全てのノードは、エコー要求を受信し、それに対応するエコー応答を送信する ICMPv6 エコー応答機能を実装しなければならない (MUST)。ノードは診断の目的のために、エコー要求を送信し、エコー応答を受信するアプリケーション層インタフェースも実装すべきである (SHOULD)。

上位層への通知

エコー要求メッセージは、ICMP メッセージを受信するプロセスに渡してもよい (MAY)。

4.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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Data ...                                                   
+-+-+-+-+-                                                       
IPv6 Fields:

Destination Address

エコー要求パケットの送信元アドレスフィールドからコピーされる。

ICMPv6 Fields:

Type

129

Code

0

Identifier

起動されたエコー要求メッセージの識別子。

Sequence Number

起動されたエコー要求メッセージのシーケンス番号。

Data

起動されたエコー要求メッセージのデータ。

説明

全てのノードは、エコー要求を受信して、それに対応するエコー応答を送信する ICMPv6 エコー応答機能を実装しなければならない (MUST)。ノードは診断のために、エコー要求を送信してエコー応答を受信するためのアプリケーション層インタフェースも実装すべきである (SHOULD)。

ユニキャストのエコー要求メッセージに対して送信されたエコー応答の送信元アドレスは、そのエコー要求メッセージの宛先アドレスと同じでなければならない (MUST)。

IPv6 マルチキャストアドレスに送信されたエコー要求メッセージの応答として、エコー応答を送信すべきである (SHOULD)。応答の送信元アドレスは、マルチキャストエコー要求メッセージを受信したインタフェースに属するユニキャストアドレスでなければならない (MUST)。

ICMPv6 エコー要求メッセージで受信したデータは、ICMPv6 エコー応答メッセージに、全体を変更せずに返却しなければならない (MUST)。

上位層への通知

エコー応答メッセージは、エコー要求メッセージを起動したプロセスに渡さなければならない (MUST)。エコー要求メッセージを起動しなかったプロセスに渡してもよい。

5. セキュリティの考慮

5.1 ICMP メッセージの認証とカプセル化

ICMP プロトコルパケット交換は、IP 認証ヘッダを使用して認証することが可能である [IPv6-AUTH]。もし IP 認証ヘッダを使用したセキュリティアソシエーションが宛先アドレスに対して存在するならば、ノードは ICMP メッセージを送信する時、認証ヘッダを含むべきである (SHOULD)。セキュリティアソシエーションは、手動設定かある鍵管理プロトコルの操作を通じて生成されたかもしれない。

ICMP パケット中で受信した認証ヘッダは、正当性を照合しなければならず (MUST)、不正な認証を持つパケットは無視し、破棄しなければならない (MUST)。

認証ヘッダかカプセル化セキュリティペイロードのいずれかを使用して認証されない全ての ICMP メッセージを無視するよう、システム管理者がノードを設定することを可能にすべきである (SHOULD)。その設定は、デフォルトでは未認証メッセージを許可すべきである (SHOULD)。

機密性の問題は、IP セキュリティ体系と IP カプセル化セキュリティペイロードのドキュメントで取り上げられている。

5.2 ICMP 攻撃

ICMP メッセージは様々な攻撃を受けやすい。完全な議論については、IP セキュリティ体系 [IPv6-SA] に示されている。そうした攻撃や防護の簡潔な議論については、以下の通りである。

  1. ICMP メッセージは、メッセージがメッセージ起動者とは異なる送信元から来たと受信側に信用させることを意図した動作を被りやすい。この攻撃に対する防護は、ICMP メッセージに IPv6 認証メカニズム [IPv6-Auth] を適用することによって達成できる。

  2. ICMP メッセージは、メッセージやその応答が、メッセージ起動者の意図とは異なる宛先に行かせることを意図した動作を被りやすい。悪意のある介入者による、そのメッセージを送信する IP パケットの宛先と送信元アドレスの改変に対して、ICMP チェックサムの計算が防護メカニズムを提供する。ICMP チェックサムフィールドは、ICMP メッセージの認証 [IPv6-Auth] かカプセル化 [IPv6-ESP] によって、その改変に対して防護される。

  3. ICMP メッセージは、メッセージフィールドやペイロードの改変を被りやすい。ICMP メッセージの認証 [IPv6-Auth] かカプセル化 [IPv6-ESP] が、そうした動作に対する防護である。

  4. ICMP メッセージは、誤った IP パケットを返送することによるサービス拒否攻撃を実現する試みとして使用されるかもしれない。この規約のセクション 2.4 の (f) 段落に正しく従った実装体は、ICMP エラーの割合制限メカニズムによって保護されるだろう。

6. 参照

[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.

7. 謝辞

このドキュメントは、SIPP と IPng ワーキンググループの以前の ICMP ドラフトに由来している。

IPng ワーキンググループや特に Robert Elz, Jim Bound, Bill Simpson, Thomas Narten, Charlie Lynn, Bill Fink, Scott Bradner, Dimitri Haskin, Bob Hinden (年代順) は、広範囲なレビュー情報とフィードバックを提供してくれた。

8. 作者のアドレス

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

付録 A - RFC 1885 からの変更点

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.