インターネット制御メッセージプロトコル

インターネット制御メッセージプロトコル
通信プロトコル
ICMPv4の一般的なヘッダー
目的IPv4の補助プロトコル[1] ：52 
開発者DARPA
導入1981年; 44年前 (1981)
OSI層ネットワーク層
RFC(s)792

インターネット制御メッセージプロトコル（ICMP ）は、インターネットプロトコルスイートの補助プロトコル[2]です。ルータなどのネットワークデバイスが、別のIPアドレスとの通信時に成功または失敗を示すエラーメッセージや動作情報を送信するために使用されます。たとえば、要求されたサービスが利用できない場合や、ホストまたはルータに到達できなかった場合にエラーが示されます。[3] ICMPは、TCPやUDPなどのトランスポートプロトコルとは異なり、システム間のデータ交換には通常使用されず、エンドユーザーのネットワークアプリケーションでも定期的に使用されることはありません（ pingやtracerouteなどの一部の診断ツールを除く）。

IPv6では別のインターネット制御メッセージプロトコル（ICMPv6と呼ばれる）が使用されます。[4]

Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

技術的な詳細

ICMPは、RFC 792で定義されているインターネットプロトコルスイートの一部です。ICMPメッセージは通常、診断または制御の目的で使用され、IP操作におけるエラー（RFC 1122で規定）への応答として生成されます。ICMPエラーは、送信元パケットの送信元IPアドレスに送信されます。[3]

例えば、IPデータグラムを転送するすべてのデバイス（中間ルーターなど）は、まずIPヘッダーのTTL（Time to Live ）フィールドを1つ減らします。TTLが0になった場合、パケットは破棄され、ICMPのTime to Liveメッセージがデータグラムの送信元アドレスに送信されます。

一般的に使用されている多くのネットワークユーティリティは、ICMPメッセージに基づいています。tracerouteコマンドは、IP TTLヘッダーフィールドを特別に設定したIPデータグラムを送信し、その応答として生成されるICMP送信時間超過メッセージと宛先到達不能メッセージを調べることで実装できます。関連するpingユーティリティは、ICMPエコー要求メッセージとエコー応答メッセージを使用して実装されています。

ICMPはIPの基本サポートを高レベルプロトコルのように利用しますが、実際にはIPの不可欠な部分です。ICMPメッセージは標準IPパケットに含まれていますが、通常は通常のIP処理とは区別された特別なケースとして処理されます。多くの場合、ICMPメッセージの内容を検査し、ICMPメッセージの送信を促したIPパケットの送信を担当するアプリケーションに適切なエラーメッセージを返す必要があります。

ICMPはネットワーク層プロトコルであり、7層OSI参照モデルでは第3層プロトコルに該当します。4層TCP/IPモデルに基づくICMPはインターネット層プロトコルであり、インターネット標準RFC 1122 TCP/IP 4層モデルでは第2層プロトコル、現代の5層TCP/IPプロトコル定義（Kozierok、Comer、Tanenbaum、Forouzan、Kurose、Stallingsによる）では第3層プロトコルに該当します。[要出典]

ICMPパケットにはポート番号は関連付けられていません。これらの番号は、TCPやUDPなどの上位のトランスポート層のプロトコルに関連付けられています。 [5]

データグラム構造

ICMPパケットはIPv4パケットにカプセル化されます。[3]パケットはヘッダーセクションとデータセクションで構成されています。

ICMPヘッダーはIPv4ヘッダーの後に始まり、プロトコル番号1で識別されます。[6]すべてのICMPパケットは8バイトのヘッダーと可変サイズのデータ​​セクションを持ちます。ヘッダーの最初の4バイトは固定フォーマットですが、最後の4バイトはICMPパケットのタイプとコードによって異なります。[3]

ICMPヘッダー形式
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00タイプコードチェックサム
432ヘッダーの残り
タイプ: 8ビット
ICMP タイプについては、§ 制御メッセージを参照してください。
コード: 8ビット
ICMP サブタイプについては、§ 制御メッセージを参照してください。
チェックサム: 16ビット
エラーチェックのためのインターネットチェックサム[7]。ICMPヘッダーとこのフィールドに代入された値0のデータから計算されます。
残りのヘッダー: 32ビット
4 バイトのフィールド。内容は ICMP のタイプとコードによって異なります。

データ

ICMPエラーメッセージには、IPv4ヘッダー全体のコピーと、エラーメッセージの原因となったIPv4パケットの最初の8バイト以上のデータを含むデータセクションが含まれます。ICMPエラーメッセージの長さは576バイトを超えてはなりません。[1]このデータは、ホストがメッセージを適切なプロセスに関連付けるために使用されます。上位プロトコルがポート番号を使用している場合、それらは元のデータグラムのデータの最初の8バイトに含まれているものとみなされます。[2]

ICMPパケットのデータセクションの可変サイズが悪用されています。「 Ping of death 」では、大きな、あるいは断片化されたICMPパケットがサービス拒否攻撃に利用されます。ICMPデータは、通信のための隠れチャネルを作成するためにも利用されます。これらのチャネルはICMPトンネルと呼ばれます。

制御メッセージ

制御メッセージは、タイプフィールドの値によって識別されます。コードフィールドは、メッセージの追加のコンテキスト情報を提供します。一部の制御メッセージは、プロトコルの導入以降、非推奨となっています。

注目すべき制御メッセージ[8] [9]
タイプコード状態説明
0 – エコー返信[2] : 14 0エコー応答（ pingに使用）
1と2未割り当て予約済み
3 – 宛先到達不能[2] : 4  [8]0宛先ネットワークに到達できません
1宛先ホストに到達できません
2宛先プロトコルに到達できません
3宛先ポートに到達できません
4フラグメンテーションが必要で、DFフラグが設定されている
5ソースルートが失敗しました
6宛先ネットワークが不明です
7宛先ホストが不明です
8ソースホストが分離されました
9ネットワークは管理上禁止されています
10ホストは管理上禁止されています
11ToSによりネットワークにアクセスできません
12ToSによりホストにアクセスできません
13通信は管理上禁止されています
14ホスト優先順位違反
15優先順位のカットオフが有効
4 – ソースクエンチ0非推奨[10]ソースクエンチ（輻輳制御）
5 – リダイレクトメッセージ0ネットワークのデータグラムをリダイレクトする
1ホストへのデータグラムのリダイレクト
2ToSとネットワークのリダイレクトデータグラム
3ToSとホストのリダイレクトデータグラム
6非推奨[11]代替ホストアドレス
7未割り当て予約済み
8 – エコー要求0エコー要求（ pingに使用）
9 –ルータ広告0ルーター広告
10 –ルータ要請0ルータの検出/選択/要請
11 –時間超過[2] : 6 0転送中に有効期限（TTL）が切れました
1フラグメント再構成時間を超過しました
12 – パラメータの問題: 不正なIPヘッダー0ポインタはエラーを示します
1必須オプションがありません
2長さが間違っている
13 – タイムスタンプ0タイムスタンプ
14 – タイムスタンプ返信0タイムスタンプ返信
15 – 情報要求0非推奨[11]情報リクエスト
16 – 情報返信0非推奨[11]情報返信
17 – アドレスマスク要求0非推奨[11]アドレスマスク要求
18 – アドレスマスク返信0非推奨[11]アドレスマスク返信
19未割り当てセキュリティのために予約済み
20から29未割り当て堅牢性実験用に予約済み
30 –トレースルート0非推奨[11]情報リクエスト
31非推奨[11]データグラム変換エラー
32非推奨[11]モバイルホストリダイレクト
33非推奨[11]Where-Are-You (元々はIPv6向け)
34非推奨[11]Here-I-Am (元々はIPv6向け)
35非推奨[11]モバイル登録リクエスト
36非推奨[11]モバイル登録返信
37非推奨[11]ドメイン名申請
38非推奨[11]ドメイン名の返信
39非推奨[11]SKIPアルゴリズム検出プロトコル、インターネットプロトコルのためのシンプルな鍵管理
40写真、セキュリティの失敗
41実験的Seamobyなどの実験的なモビリティプロトコル用のICMP 。[12]
42 – 拡張エコー要求[13]0拡張エコーの要求
43 – 拡張エコー応答[13]0エラーなし
1不正なクエリ
2そのようなインターフェースはありません
3そのようなテーブルエントリはありません
4複数のインターフェースがクエリを満たす
44から252未割り当て予約済み
253実験的RFC3692スタイルの実験1 [14]
254実験的RFC3692スタイルの実験2 [14]
255未割り当て予約済み

ソースクエンチ

ソースクエンチは、送信元に対し、ルータまたはホストへのメッセージ送信レートを下げるよう要求します。このメッセージは、ルータまたはホストに要求を処理するのに十分なバッファスペースがない場合、またはルータまたはホストのバッファが限界に近づいている場合に生成されることがあります。

データは、1台のホスト、または複数のホストから同時に、ネットワーク上の特定のルーターに非常に高速に送信されます。ルーターにはバッファリング機能がありますが、バッファリングできる範囲は一定に制限されています。ルーターは、限られたバッファリングスペースの容量を超えるデータをキューに入れることはできません。そのため、キューがいっぱいになると、キューがいっぱいになるまで受信データは破棄されます。しかし、ネットワーク層には確認応答メカニズムが存在しないため、クライアントはデータが宛先に正常に到達したかどうかを知ることができません。そのため、このような状況を回避するために、ネットワーク層で何らかの対策を講じる必要があります。これらの対策は、ソースクエンチと呼ばれます。

ソースクエンチメカニズムでは、ルーターは受信データレートが送信データレートよりもはるかに速いことを検知し、クライアントにICMPメッセージを送信して、データ転送速度を落とすか、それ以上のデータ送信を試みる前に一定時間待つように通知します。クライアントがこのメッセージを受信すると、自動的に送信データレートを落とすか、十分な時間待機してルーターがキューを空にできるようにします。このように、ソースクエンチICMPメッセージは、ネットワーク層におけるフロー制御として機能します。

研究により「ICMPソースクエンチは輻輳に対する効果のない（そして不公平な）解毒剤である」と示唆されたため、[10]ルータによるソースクエンチメッセージの作成は1995年にRFC 1812で非推奨となりました。さらに、ソースクエンチメッセージの転送とそれに対するあらゆる種類の反応（フロー制御アクション）は2012年からRFC 6633で非推奨となりました。

ソースクエンチメッセージ[2] : 9 
0001020304050607080910111213141516171819202122232425262728293031
タイプ = 4コード = 0チェックサム
未使用
IPヘッダーと元のデータグラムのデータの最初の8バイト

どこ：

タイプは4に設定する必要があります
コードは0に設定する必要があります
IPヘッダーと追加データは、送信者が応答と関連する要求を一致させるために使用されます。

リダイレクト

ICMPv4リダイレクトメッセージの動作例

リダイレクトは、データ パケットを別のルートで送信するよう要求します。ICMP リダイレクトは、ルータがホストにルーティング情報を伝達するためのメカニズムです。このメッセージは、ホストにルーティング情報を更新する (パケットを別のルートで送信する) ように通知します。ホストがルータ( R1) 経由でデータを送信しようとし、R1 が別のルータ (R2) でデータを送信し、ホストから R2 への直接パスが使用できる (つまり、ホストと R2 が同じサブネット上にある) 場合、R1 はリダイレクト メッセージを送信して、宛先への最適なルートは R2 経由であることをホストに通知します。その後、ホストはルート情報を変更し、その宛先へのパケットを直接 R2 に送信する必要があります。ルータは元のデータグラムを目的の宛先に送信します。[15]ただし、データグラムにルーティング情報が含まれている場合は、より良いルートが使用可能であってもこのメッセージは送信されません。RFC 1122 では、リダイレクトはゲートウェイによってのみ送信され、インターネット ホストによって送信されてはならないと規定されています。

リダイレクトメッセージ[2] : 11 
0001020304050607080910111213141516171819202122232425262728293031
タイプ = 5コードチェックサム
IPアドレス
IPヘッダーと元のデータグラムのデータの最初の8バイト

どこ：

タイプは5 に設定する必要があります。
コードはリダイレクトの理由を指定し、次のいずれかになります。
コード説明
0ネットワークへのリダイレクト
1ホストのリダイレクト
2サービスタイプとネットワークのリダイレクト
3サービスタイプとホストのリダイレクト
IP アドレスは、リダイレクトを送信するゲートウェイの 32 ビット アドレスです。
IP ヘッダーと追加データが含まれており、ホストが応答をリダイレクト応答の原因となった要求と一致させることができます。

時間超過

Time Exceededは、ゲートウェイによって生成され、TTL フィールドがゼロに達したために破棄されたデータグラムの送信元に通知します。また、ホストが制限時間内にフラグメント化されたデータグラムを再構成できなかった場合にも、Time Exceeded メッセージが送信されることがあります。

時間超過メッセージは、tracerouteユーティリティによって、2 つのホスト間のパス上のゲートウェイを識別するために使用されます。

時間超過メッセージ[2] : 5 
0001020304050607080910111213141516171819202122232425262728293031
タイプ = 11コードチェックサム
未使用
IPヘッダーと元のデータグラムのデータの最初の8バイト

どこ：

タイプは11に設定する必要があります
コードは時間超過メッセージの理由を指定し、次のものが含まれます。
コード説明
0転送中に有効期限を超過しました。
1フラグメントの再構成時間が超過しました。
IPヘッダーと元のペイロードの最初の64ビットは、送信元ホストが時間超過メッセージと破棄されたデータグラムを照合するために使用されます。UDPやTCPなどの高レベルプロトコルの場合、64ビットのペイロードには、破棄されたパケットの送信元ポートと宛先ポートが含まれます。

タイムスタンプ

タイムスタンプは時刻同期に使用されます。送信元のタイムスタンプは、送信者が最後にパケットにアクセスした時刻（午前0時からのミリ秒単位）に設定されます。受信および送信のタイムスタンプは使用されません。

タイムスタンプメッセージ[2] : 15 
0001020304050607080910111213141516171819202122232425262728293031
タイプ = 13コード = 0チェックサム
識別子シーケンス番号
発信タイムスタンプ
受信タイムスタンプ
送信タイムスタンプ

どこ：

タイプは13に設定する必要があります
コードは0に設定する必要があります
識別子とシーケンス番号は、クライアントがタイムスタンプ応答とタイムスタンプ要求を一致させるために使用できます。
発信タイムスタンプは、世界標準時（UT）の午前0時からの経過時間（ミリ秒）です。UT参照が利用できない場合は、最上位ビットを設定して非標準の時刻値を示すことができます。

タイムスタンプ返信

タイムスタンプ応答は、タイムスタンプメッセージへの返信です。タイムスタンプ応答は、タイムスタンプの送信者から送信された発信タイムスタンプ、タイムスタンプの受信時刻を示す受信タイムスタンプ、そしてタイムスタンプ応答の送信時刻を示す送信タイムスタンプで構成されます。

タイムスタンプ返信メッセージ[2] : 15 
0001020304050607080910111213141516171819202122232425262728293031
タイプ = 14コード = 0チェックサム
識別子シーケンス番号
発信タイムスタンプ
受信タイムスタンプ
送信タイムスタンプ

どこ：

タイプは14に設定する必要があります
コードは0に設定する必要があります
識別子とシーケンス番号は、クライアントが応答とその応答の原因となった要求を一致させるために使用できます。
発信タイムスタンプは、送信者がメッセージを送信する前に最後に操作した時刻です。
受信タイムスタンプは、エコー装置が受信時に最初にタッチした時刻です。
送信タイムスタンプは、エコー送信者がメッセージを送信する際に最後にアクセスした時刻です。
すべてのタイムスタンプは、UT午前0時を基準としたミリ秒単位で表されます。ミリ秒単位の時刻が利用できない場合、またはUT午前0時を基準とした時刻が提供できない場合は、タイムスタンプの上位ビットが非標準値であることを示すように設定されている限り、任意の時刻をタイムスタンプに挿入できます。

インターネットノードのクロックを同期するためのタイムスタンプとタイムスタンプ応答メッセージの使用は、UDPベースのネットワークタイムプロトコルと高精度時間プロトコルに大きく置き換えられました。[16]

アドレスマスク要求

アドレス マスク要求は通常、適切なサブネット マスクを取得するためにホストからルーターに送信されます。

受信者は、アドレス マスク返信メッセージでこのメッセージに返信する必要があります。

アドレスマスク要求
0001020304050607080910111213141516171819202122232425262728293031
タイプ = 17コード = 0チェックサム
識別子シーケンス番号
アドレスマスク

どこ：

タイプは17に設定する必要があります
コードは0に設定する必要があります
アドレスマスクは0に設定できます

ICMPアドレスマスク要求は、標的ネットワークに関する情報を収集するための偵察攻撃の一部として使用される可能性があるため、Cisco IOSではICMPアドレスマスク応答はデフォルトで無効になっています。[17]

アドレスマスク返信

アドレス マスク応答は、適切なサブネット マスクを使用してアドレス マスク要求メッセージに応答するために使用されます。

アドレスマスク返信
0001020304050607080910111213141516171819202122232425262728293031
タイプ = 18コード = 0チェックサム
識別子シーケンス番号
アドレスマスク

どこ：

タイプは18に設定する必要があります
コードは0に設定する必要があります
アドレスマスクはサブネットマスクに設定する必要があります

宛先に到達できません

宛先到達不能メッセージは、ホストまたはその受信ゲートウェイ[2]によって生成され、何らかの理由で宛先に到達できないことをクライアントに通知します。このメッセージの理由としては、ホストへの物理的な接続が存在しない（距離が無限大である）、指定されたプロトコルまたはポートがアクティブではない、データをフラグメント化する必要があるが「フラグメントしない」フラグがオンになっている、などが挙げられます。[18]到達不能なTCPポートは、予想されるような宛先到達不能タイプ3ではなく、TCP RSTで応答します。宛先到達不能メッセージは、 IPマルチキャスト伝送では報告されません。

宛先到達不能メッセージ[2] : 4  [19]
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00タイプ (3)コードチェックサム
432未使用（長さ）（ネクストホップMTU）
864IPヘッダーと元のデータグラムのデータの最初のバイト
⋮⋮
5724576

フィールドの内容は次のとおりです。

タイプ: 8 ビット; タイプ == 3
値3は「宛先に到達できない」ことを示します。
コード: 8ビット
これはエラーの種類を指定するもので、次のいずれかになります。[8]
コード説明
0ネットワークに到達できないエラーです。
1ホスト到達不能エラー。
2プロトコル到達不能エラー (指定されたトランスポート プロトコルはサポートされていません)。
3ポート到達不能エラー (指定されたプロトコルが受信メッセージをホストに通知できません)。
4データグラムが大きすぎます。パケットの断片化が必要ですが、「断片化しない」(DF) フラグがオンになっています。
5ソースルート失敗エラー。
6宛先ネットワーク不明エラー。
7宛先ホスト不明エラー。
8ソース ホスト分離エラー。
9宛先ネットワークは管理上禁止されています。
10宛先ホストは管理上禁止されています。
11サービス タイプではネットワークに到達できません。
12ホストはサービス タイプに到達できません。
13通信は管理上禁止されています (管理フィルタリングによりパケットの転送が防止されます)。
14ホスト優先順位違反 (要求された優先順位がホストまたはネットワークとポートの組み合わせに対して許可されていないことを示します)。
15優先順位のカットオフが有効です (データグラムの優先順位がネットワーク管理者によって設定されたレベルを下回っています)。
未使用: 8 - 32 ビット; 未使用 == 0
未使用のため、ゼロに設定する必要があります。長さまたはネクストホップMTUが使用されていない場合は、このフィールドの一部とみなされます。
長さ: 8ビット
オプション。長さフィールドは、元のデータグラムデータの長さを32ビットワードで示します。これにより、このICMPメッセージに追加情報を追加できます。このフィールドを使用する場合は、元のデータグラムデータに最も近い32ビット境界までゼロをパディングする必要があります。
ネクストホップMTU: 16ビット
オプション。コード 4 エラーが発生した場合、ネクストホップ ネットワークの MTU が含まれます。
IPヘッダーとデータ: 20 - 568バイト
IPヘッダー（20バイト）と、元のデータグラムの先頭から最大548バイト（IPv4再構成バッファの最小サイズを超えないようにするため）。このメッセージが拡張されている場合、このフィールドには少なくとも128バイトの元のデータグラムデータ（必要に応じてゼロで埋める）が含まれている必要があります。これらのデータは、クライアントが応答と、宛先到達不能
応答の原因となった要求を照合できるようにするために含まれています。

拡張機能

ICMPメッセージは追加情報で拡張することができます。この情報は、ICMP拡張ヘッダーに先行する1つ以上の拡張オブジェクトで伝送されます。[19]

ICMP拡張ヘッダー
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00バージョン予約済みチェックサム
432拡張オブジェクト
864
⋮⋮
バージョン: 4 ビット; バージョン == 2
拡張ヘッダーのバージョン。
予約済み: 12 ビット; 予約済み == 0
予約済み。
チェックサム: 16ビット
このヘッダーとすべての拡張オブジェクトのチェックサム。このフィールド自体も含まれているため、計算実行中はゼロに設定されます。

拡張オブジェクトの一般的な構造は次のとおりです。

拡張オブジェクトヘッダー
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00長さクラス番号Cタイプ
432（オブジェクトペイロード）
864
⋮⋮
長さ: 16ビット
ヘッダーを含むオブジェクトの長さ（オクテット単位）。
クラス番号: 8ビット
オブジェクトのクラスを識別します。
Cタイプ: 8ビット
オブジェクトのサブタイプを識別します。
オブジェクトペイロード: 変数
オプションのペイロード。空でない場合、32ビットの倍数のサイズのデータ​​構造が含まれます。

参照

参考文献

  1. ^ ab F. Baker編 (1995年6月). IPバージョン4ルータの要件. ネットワークワーキンググループ. doi : 10.17487/RFC1812 . RFC 1812. 提案された標準。RFC 1716 および 1009 を廃止します。RFC 2644 および 6633 によって更新されます。
  2. ^ abcdefghijkl J. Postel (1981年9月). インターネット制御メッセージプロトコル - DARPAインターネットプログラムプロトコル仕様. ネットワークワーキンググループ. doi : 10.17487/RFC0792 . STD 5. RFC 792. インターネット標準 5。RFC 760、777、IEN 109、128 を更新。RFC 950、4884、6633、6918 によって更新。
  3. ^ abcd Forouzan, Behrouz A. (2007).データ通信とネットワーキング（第4版）. ボストン: McGraw-Hill. pp. 621–630. ISBN 978-0-07-296775-3。
  4. ^ A. Conta; S. Deering (2006年3月). M. Gupta (編). インターネットプロトコルバージョン6 (IPv6) 仕様のためのインターネット制御メッセージプロトコル (ICMPv6). ネットワークワーキンググループ. doi : 10.17487/RFC4443 . STD 89. RFC 4443. インターネット標準 89。RFC 2463 を廃止。RFC 2780 を更新。RFC 4884によって更新。
  5. ^ 「OSIモデルの7つの層の定義と機能の説明」。Microsoftサポート。 2014年12月28日閲覧。
  6. ^ 「プロトコル番号」。インターネット割り当て番号局。 2011年6月23日閲覧。
  7. ^ R. Braden、D. Borman、C. Partridge（1988年9月）。インターネットチェックサムの計算。ネットワークワーキンググループ。doi : 10.17487 / RFC1071。RFC 1071 。 情報提供。RFC 1141 により更新されました。
  8. ^ abc 「インターネット制御メッセージプロトコル（ICMP）パラメータ」IANA. 2012年9月21日. 2013年1月7日閲覧。
  9. ^ 黒瀬, JF; ロス, KW (2006). コンピュータネットワーキング：トップダウンアプローチ. ワールドスチューデントシリーズ. アディソン・ウェズリー. ISBN 9780321418494。
  10. ^ ab F. Gont (2012年5月). ICMP送信元抑制メッセージの廃止.インターネット技術タスクフォース. doi : 10.17487/RFC6633 . ISSN  2070-1721. RFC 6633. 提案された標準。RFC 792、1122、および 1812 を更新します。
  11. ^ abcdefghijklmno F. Gont; C. Pignataro (2013年4月). 一部のICMPv4メッセージタイプの正式な廃止.インターネット技術タスクフォース. doi : 10.17487/RFC6918 . ISSN  2070-1721. RFC 6918. 提案された標準。RFC 1788 を廃止します。RFC 792 および 950 を更新します。
  12. ^ J. Kempf (2005年7月). Seamobyおよび実験的モビリティプロトコルのIANA割り当てに関する指示. doi : 10.17487/RFC4065 . RFC 4065. 実験的。
  13. ^ ab R. Bonica; R. Thomas; J. Linkova; C. Lenart; M. Boucadair (2018年2月). PROBE: インターフェースプローブ用ユーティリティ. Internet Engineering Task Force . doi : 10.17487/RFC8335 . ISSN  2070-1721. RFC 8335. 提案された標準。RFC 4884 を更新します。
  14. ^ ab B. Fenner (2006年11月). IPv4、IPv6、ICMPv4、ICMPv6、UDP、TCPヘッダーの実験値. IETFネットワークワーキンググループ. doi : 10.17487/RFC4727 . RFC 4727. 提案された標準。
  15. ^ 「ICMPリダイレクトはいつ送信されるか？」Cisco Systems . 2008年6月28日. 2013年8月15日閲覧。
  16. ^ DL Mills (1985年9月). ネットワークタイムプロトコル (NTP). doi : 10.17487/RFC0958 . RFC 958.これはタイムプロトコルとICMPタイムスタンプメッセージから発展したもので、両方の適切な代替手段です。
  17. ^ 「Cisco IOS IPコマンドリファレンス、第1巻/第4巻：アドレス指定とサービス、リリース12.3 - IPアドレス指定およびサービスコマンド：ip mask-replyからip web-cacheまで」。シスコシステムズ。2013年1月2日時点のオリジナルよりアーカイブ。 2013年1月7日閲覧。
  18. ^ J. Mogul; S. Deering (1990年11月). パスMTU検出. ネットワークワーキンググループ. doi : 10.17487/RFC1191 . RFC 1191. ドラフト標準。 RFC 1063 は廃止されます。
  19. ^ ab R. Bonica; D. Gan; D. Tappan; C. Pignataro (2007年4月). マルチパートメッセージのサポートのための拡張ICMP. ネットワークワーキンググループ. doi : 10.17487/RFC4884 . RFC 4884. 提案された標準。RFC 792 および 4443 を更新します。RFC 8335 によって更新されます。
ウィキバーシティにはインターネット制御メッセージプロトコルに関する学習リソースがあります
  • IANAプロトコル番号
  • Wayback Machineにおける ICMP リダイレクト動作の説明(2015 年 1 月 10 日アーカイブ)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Internet_Control_Message_Protocol&oldid=1322300378"