Loading article…
| 通信プロトコル | |
 ICMPv4の一般的なヘッダー | |
| 目的 | IPv4の補助プロトコル[1] ：52 |
|---|---|
| 開発者 | DARPA |
| 導入 | 1981 |
| OSI層 | ネットワーク層 |
| RFC(複数) | RFC792 の翻訳 |
インターネット制御メッセージプロトコル（ICMP ）は、インターネットプロトコルスイートのサポートプロトコル[2]です。ルータなどのネットワークデバイスが、別のIPアドレスとの通信時に成功または失敗を示すエラーメッセージや動作情報を送信するために使用されます。たとえば、要求されたサービスが利用できない場合や、ホストまたはルータに到達できなかった場合にエラーが示されます。[3] ICMPは、TCPやUDPなどのトランスポートプロトコルとは異なり、通常はシステム間でデータを交換するために使用されず、エンドユーザーのネットワークアプリケーションでも定期的に使用されません（ pingやtracerouteなどの一部の診断ツールを除く）。
IPv6では別のインターネット制御メッセージプロトコル（ICMPv6と呼ばれる）が使用されます。[4]
技術的な詳細
ICMPは、RFC 792で定義されているインターネットプロトコルスイートの一部です。ICMPメッセージは通常、診断または制御の目的で使用され、IP操作のエラーに応答して生成されます（RFC 1122で指定）。ICMPエラーは、発信元パケットの送信元IPアドレスに送信されます。[3]
たとえば、 IPデータグラムを転送するすべてのデバイス (中間ルーターなど) は、まずIP ヘッダーの存続時間(TTL) フィールドを 1 減らします。結果の TTL が 0 の場合、パケットは破棄され、ICMP時間超過メッセージがデータグラムの送信元アドレスに送信されます。
一般的に使用されているネットワーク ユーティリティの多くは、ICMP メッセージに基づいています。tracerouteコマンドは、特別に設定された IP TTL ヘッダー フィールドを持つ IP データグラムを送信し、応答として生成される ICMP 転送時間超過メッセージと宛先到達不能メッセージを探すことによって実装できます。関連するpingユーティリティは、ICMPエコー要求メッセージとエコー応答メッセージを使用して実装されます。
ICMP は、IP の基本サポートを、より高レベルのプロトコルであるかのように使用しますが、実際には ICMP は IP の不可欠な部分です。ICMP メッセージは標準の IP パケット内に含まれていますが、ICMP メッセージは通常、通常の 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]
- タイプ: 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 データは、通信用の秘密チャネルを作成するためにも使用できます。これらのチャネルはICMP トンネルと呼ばれます。
制御メッセージ
制御メッセージは、タイプフィールドの値によって識別されます。コードフィールドは、メッセージの追加のコンテキスト情報を提供します。プロトコルが最初に導入されて以来、 一部の制御メッセージは非推奨になっています。
ソースクエンチ
Source Quench は、送信者がルータまたはホストに送信されるメッセージのレートを下げるように要求します。このメッセージは、ルータまたはホストに要求を処理するための十分なバッファ スペースがない場合、またはルータまたはホストのバッファが制限に近づいている場合に生成されることがあります。
データは、1 台のホストから、または複数のホストから同時に、ネットワーク上の特定のルーターに非常に高速に送信されます。ルーターにはバッファリング機能がありますが、バッファリングは指定された範囲内に制限されています。ルーターは、限られたバッファリング スペースの容量を超えるデータをキューに入れることはできません。したがって、キューがいっぱいになると、キューがいっぱいでなくなるまで、着信データは破棄されます。ただし、ネットワーク層に確認応答メカニズムが存在しないため、クライアントはデータが宛先に正常に到達したかどうかを知ることができません。したがって、このような状況を回避するために、ネットワーク層で何らかの対策を講じる必要があります。これらの対策は、ソース クエンチと呼ばれます。
ソース クエンチ メカニズムでは、ルータは受信データ レートが送信データ レートよりはるかに速いことを認識し、クライアントに ICMP メッセージを送信して、データ転送速度を遅くするか、さらにデータを送信する前に一定時間待つように通知します。クライアントがこのメッセージを受信すると、自動的に送信データ レートを遅くするか、十分な時間待機して、ルータがキューを空にできるようにします。このように、ソース クエンチ ICMP メッセージは、ネットワーク層でフロー制御として機能します。
研究により「ICMP Source Quenchは輻輳に対する効果のない（そして不公平な）解毒剤である」と示唆されたため、[11]ルーターによるSource Quenchメッセージの作成は1995年にRFC 1812によって非推奨となりました。さらに、Source Quenchメッセージの転送とそれに対するあらゆる種類の反応（フロー制御アクション）は2012年からRFC 6633によって非推奨となりました。
どこ：
- タイプは4に設定する必要があります
- コードは0に設定する必要があります
- IPヘッダーと追加データは、送信者が応答を関連する要求と一致させるために使用されます。
リダイレクト
リダイレクトは、データ パケットを代替ルートで送信するよう要求します。ICMP リダイレクトは、ルータがホストにルーティング情報を伝達するためのメカニズムです。このメッセージは、ホストにルーティング情報を更新する (パケットを代替ルートで送信する) ように通知します。ホストがルータ( R1) 経由でデータを送信しようとし、R1 が別のルータ (R2) でデータを送信し、ホストから R2 への直接パスが利用できる場合 (つまり、ホストと R2 が同じサブネット上にある場合)、R1 はリダイレクト メッセージを送信して、宛先への最適なルートは R2 経由であることをホストに通知します。その後、ホストはルート情報を変更し、その宛先へのパケットを直接 R2 に送信する必要があります。ルータは元のデータグラムを目的の宛先に送信します。[16]ただし、データグラムにルーティング情報が含まれている場合は、より良いルートが利用可能であってもこのメッセージは送信されません。RFC 1122 では、リダイレクトはゲートウェイによってのみ送信され、インターネット ホストによって送信されてはならないと規定されています。
どこ：
- タイプは5 に設定する必要があります。
- コードはリダイレクトの理由を指定し、次のいずれかになります。
- IP アドレスは、リダイレクトを送信するゲートウェイの 32 ビット アドレスです。
- IP ヘッダーと追加データが含まれており、ホストが応答をリダイレクト応答の原因となった要求と一致させることができます。
時間超過
時間超過は、ゲートウェイによって生成され、存続時間フィールドがゼロに達したために破棄されたデータグラムのソースに通知します。時間超過メッセージは、ホストが時間制限内に断片化されたデータグラムを再構成できなかった場合にも送信されることがあります。
時間超過メッセージは、tracerouteユーティリティによって、2 つのホスト間のパス上のゲートウェイを識別するために使用されます。
どこ：
- タイプは11に設定する必要があります
- コードは、時間超過メッセージの理由を指定します。これには次のものが含まれます。
- IP ヘッダーと元のペイロードの最初の 64 ビットは、送信元ホストによって、時間超過メッセージを破棄されたデータグラムと一致させるために使用されます。UDPやTCPなどの上位レベルのプロトコルの場合、64 ビットのペイロードには、破棄されたパケットの送信元ポートと宛先ポートが含まれます。
タイムスタンプ
タイムスタンプは時間同期に使用されます。発信タイムスタンプは、送信者が最後にパケットにアクセスした時間 (午前 0 時からのミリ秒単位) に設定されます。受信および送信タイムスタンプは使用されません。
どこ：
- タイプは13に設定する必要があります
- コードは0に設定する必要があります
- 識別子とシーケンス番号は、クライアントがタイムスタンプ応答とタイムスタンプ要求を一致させるために使用できます。
- 発信タイムスタンプは、世界標準時(UT)の午前 0 時からのミリ秒数です。UT 参照が利用できない場合は、最上位ビットを設定して非標準の時間値を示すことができます。
タイムスタンプ返信
タイムスタンプ応答は、タイムスタンプメッセージに応答します。タイムスタンプの送信者から送信された発信タイムスタンプ、タイムスタンプが受信された時刻を示す受信タイムスタンプ、およびタイムスタンプ応答が送信された時刻を示す送信タイムスタンプで構成されます。
どこ：
- タイプは14に設定する必要があります
- コードは0に設定する必要があります
- 識別子とシーケンス番号は、クライアントが応答とその応答の原因となった要求を一致させるために使用できます。
- 発信タイムスタンプは、送信者がメッセージを送信する前に最後にメッセージを操作した時刻です。
- 受信タイムスタンプは、エコーが受信時に最初にタッチした時刻です。
- 送信タイムスタンプは、エコーがメッセージを送信する際に最後にメッセージを受信した時刻です。
- すべてのタイムスタンプは、UT の午前 0 時からのミリ秒単位です。ミリ秒単位の時間が利用できない場合、または UT の午前 0 時からの時間を提供できない場合は、タイムスタンプの上位ビットもこの非標準値を示すように設定されていれば、任意の時間をタイムスタンプに挿入できます。
インターネットノードの時計を同期するためのタイムスタンプとタイムスタンプ応答メッセージの使用は、UDPベースのネットワークタイムプロトコルと高精度時間プロトコルに大きく置き換えられました。[17]
アドレスマスク要求
アドレス マスク要求は通常、適切なサブネット マスクを取得するためにホストからルーターに送信されます。
受信者は、アドレス マスク返信メッセージを使用してこのメッセージに返信する必要があります。
どこ：
- タイプは17に設定する必要があります
- コードは0に設定する必要があります
- アドレスマスクは0に設定できます
ICMPアドレスマスク要求は、標的ネットワークに関する情報を収集するための偵察攻撃の一部として使用される可能性があるため、Cisco IOSではICMPアドレスマスク応答はデフォルトで無効になっています。[18]
アドレスマスク返信
アドレス マスク応答は、適切なサブネット マスクを使用してアドレス マスク要求メッセージに応答するために使用されます。
どこ：
- タイプは18に設定する必要があります
- コードは0に設定する必要があります
- アドレスマスクはサブネットマスクに設定する必要があります
目的地に到達できません
宛先到達不能は、何らかの理由で宛先に到達できないことをクライアントに通知するために、ホストまたはその受信ゲートウェイ[2]によって生成されます。このメッセージの理由には、ホストへの物理的な接続が存在しない (距離が無限大)、指定されたプロトコルまたはポートがアクティブでない、データを断片化する必要があるが「断片化しない」フラグがオンになっているなどがあります。[19]到達不能な TCP ポートは、予想される宛先到達不能タイプ 3ではなく、TCP RSTで応答します。宛先到達不能は、IP マルチキャスト送信では報告されません。
フィールドの内容は次のとおりです。
- タイプ: 8 ビット; タイプ == 3
- 値3は「宛先に到達できない」ことを示します。
- コード: 8 ビット
- これはエラーの種類を指定し、次のいずれかになります。[8]
- 未使用: 8 - 32 ビット; 未使用 == 0
- 未使用。ゼロに設定する必要があります。長さまたはネクストホップ MTUが使用されない場合は、このフィールドの一部と見なされます。
- 長さ: 8 ビット
- オプション。長さフィールドは、元のデータグラム データの長さを 32 ビット ワードで示します。これにより、この ICMP メッセージに追加情報を追加して拡張できます。使用する場合は、元のデータグラム データを最も近い 32 ビット境界までゼロで埋める必要があります。
- ネクストホップMTU: 16ビット
- オプション。コード 4 エラーが発生した場合、ネクストホップ ネットワークの MTU が含まれます。
- IP ヘッダーとデータ: 20 - 568 バイト
- IP ヘッダー (20 バイト) と、元のデータグラムの開始部分 (最小 IPv4 再構成バッファ サイズを超えないように) の最大 548 バイト。このメッセージが拡張される場合、このフィールドには少なくとも 128 バイトの元のデータグラム データ (必要に応じてゼロで埋める) が含まれている必要があります。これらのデータは、クライアントが、宛先到達不能応答
の原因となった要求と応答を一致させることができるようにするために含まれています。
拡張機能
ICMPメッセージは追加情報で拡張することができます。この情報は1つ以上の拡張オブジェクトで運ばれ、その前にICMP拡張ヘッダーが付きます。[20]
- バージョン: 4 ビット; バージョン == 2
- 拡張ヘッダーのバージョン。
- 予約: 12 ビット; 予約 == 0
- 予約済み。
- チェックサム: 16 ビット
- このヘッダーとすべての拡張オブジェクトのチェックサム。このフィールド自体も含まれるため、計算の実行中はゼロに設定されます。
拡張オブジェクトの一般的な構造は次のとおりです。
- 長さ: 16 ビット
- ヘッダーを含むオブジェクトの長さ（オクテット単位）。
- クラス番号: 8 ビット
- オブジェクトのクラスを識別します。
- Cタイプ: 8ビット
- オブジェクトのサブタイプを識別します。
- オブジェクトペイロード: 変数
- オプションのペイロード。空でない場合は、サイズが 32 ビットの倍数であるデータ構造が含まれます。
参照
参考文献
- ^ ab F. Baker編 (1995 年 6 月)。IP バージョン 4 ルータの要件。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1812。RFC 1812 。 提案された標準。RFC 1716 および 1009 は廃止されました。RFC 2644 および 6633 によって更新されました。
- ^ 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 によって更新。
- ^ abcd Forouzan, Behrouz A. (2007).データ通信とネットワーキング(第4版). ボストン: McGraw-Hill. pp. 621–630. ISBN 978-0-07-296775-3。
- ^ 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 によって更新。
- ^ 「OSI モデルの 7 つのレイヤーの定義と機能の説明」 。Microsoftサポート。2014 年 12 月 28 日閲覧。
- ^ 「プロトコル番号」。インターネット割り当て番号局。2011年6月23日閲覧。
- ^ R. Braden、D. Borman、C. Partridge (1988 年 9 月)。インターネット チェックサムの計算。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1071。RFC 1071 。 情報提供。RFC 1141 により更新されました。
- ^ ab 「IANA ICMP パラメータ」。Iana.org。2012 年 9 月 21 日。2013 年 1 月 7 日に閲覧。
- ^ 黒瀬, JF; ロス, KW (2006). コンピュータネットワーキング: トップダウンアプローチ. ワールドスチューデントシリーズ. アディソン・ウェズリー. ISBN 9780321418494。
- ^ 「インターネット制御メッセージプロトコル（ICMP）パラメータ」www.iana.org . 2023年9月13日閲覧。
- ^ ab F. Gont (2012 年5月). ICMP ソース クエンチ メッセージの廃止。インターネット エンジニアリング タスク フォース。doi : 10.17487/ RFC6633。ISSN 2070-1721。RFC 6633 。 提案された標準。RFC 792、1122、および 1812 を 更新します。
- ^ abcdefghijklmno F. Gont; C. Pignataro (2013 年 4 月). 一部の ICMPv4 メッセージ タイプの正式な廃止。インターネットエンジニアリング タスク フォース。doi : 10.17487/ RFC6918。ISSN 2070-1721。RFC 6918 。 提案された標準。RFC 1788 を 廃止します。RFC 792 および 950 を更新します。
- ^ J. Kempf (2005 年 7月). Seamoby および実験的モビリティ プロトコルの IANA 割り当てに関する手順。doi : 10.17487/ RFC4065。RFC 4065 。 実験的。
- ^ ab R. Bonica; R. Thomas; J. Linkova ; C. Lenart; M. Boucadair (2018 年 2 月). PROBE: インターフェースをプローブするためのユーティリティ。インターネット エンジニアリング タスク フォース。doi : 10.17487 / RFC8335。ISSN 2070-1721。RFC 8335 。 提案された標準。RFC 4884 を更新します。
- ^ ab B. Fenner (2006 年 11 月). IPv4、IPv6、ICMPv4、ICMPv6、UDP、および TCP ヘッダーの実験値。ネットワーク ワーキング グループ。doi : 10.17487 / RFC4727。RFC 4727 。 提案された標準。
- ^ 「ICMP リダイレクトはいつ送信されるか?」Cisco Systems 2008-06-28 2013-08-15閲覧。
- ^ DL Mills (1985 年 9 月). ネットワーク タイム プロトコル (NTP). doi : 10.17487/RFC0958 . RFC 958.
これは、タイム プロトコルと ICMP タイムスタンプ メッセージから発展したもので、両方の適切な代替品です。
- ^ 「Cisco IOS IP コマンド リファレンス、第 1 巻/第 4 巻: アドレス指定およびサービス、リリース 12.3 - IP アドレス指定およびサービス コマンド: ip mask-reply から ip web-cache」。Cisco Systems。2013年 1 月 2 日のオリジナルからアーカイブ。2013年 1 月 7 日に取得。
- ^ J. Mogul、S. Deering (1990 年 11 月) 。パス MTU 検出。ネットワーク ワーキング グループ。doi : 10.17487 /RFC1191。RFC 1191 。 ドラフト標準。 RFC 1063 は 廃止されます。
- ^ ab R. Bonica; D. Gan; D. Tappan; C. Pignataro (2007 年 4 月). マルチパート メッセージのサポートのための拡張 ICMP。ネットワーク ワーキング グループ。doi : 10.17487/ RFC4884。RFC 4884 。 提案された標準。RFC 792 および 4443 を更新します。RFC 8335 によって更新されます。
外部リンク
Wikiversityにはインターネット制御メッセージプロトコルに関する学習リソースがあります
- IANA ICMPパラメータ
- IANAプロトコル番号
- Wayback Machineでの ICMP リダイレクト動作の説明(2015-01-10 アーカイブ)