RFC792 日本語訳
0792 Internet Control Message Protocol. J. Postel. September 1981. (Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950, RFC4884) (Also STD0005) (Status: STANDARD)
RFC一覧
英語原文
Network Working Group J. Postel
RFC: 792 ISI
1981年9月
更新: RFC 777, 760
更新: IENs 109, 128
インターネット制御メッセージプロトコル
DARPAインターネットプログラム
プロトコル仕様書
はじめに
インターネットプロトコル（IP）［1］は、Catenet［2］という相互接続ネッ
トワークのシステムにおけるホストツーホストのデータグラムサービスのた
めに使用される。ネットワーク接続装置はゲートウェイと呼ばれる。このゲ
ートウェイは制御目的のためにゲートウェイ同士で、ゲートウェイツーゲー
トウェイプロトコル（GGP）［3，4］を使った通信を行っている。例えばデー
タグラム処理におけるエラーの通知のためなどで、ゲートウェイや宛先ホス
トが送信元ホストと通信するときもあるだろう。そのような目的のためにこ
のプロトコル、すなわちインターネット制御メッセージプロトコル（ICMP）
が使用される。ICMPは、まるで上位プロトコルであるかのようにIPの基本的
なサポートを使用するが、ICMPは実際にはIPの不可欠な要素であり、全てのI
Pモジュールが実装していなければならない。
ICMPメッセージはいくつかの状況で送信される。例えば、データグラムが宛
先に到達できないとき、ゲートウェイがデータグラムを転送できるだけのバ
ッファリング機能を持っていないとき、ゲートウェイが、より短い経路でト
ラフィックを送信するホストに誘導できるときなどがある。
インターネットプロトコルは、絶対的に信頼できるようには設計されていな
い。この制御メッセージの目的は、通信環境での問題に関するフィードバッ
クを提供することであり、IPを信頼できるものにすることではない。データ
グラムを配達することや、制御メッセージが返されることに保証がないこと
は変わらない。データグラムが配達されず、損失したという通知も無い場合
もあるだろう。信頼性のある通信が必要なら、IPを使用する上位プロトコル
で独自の信頼性プロシージャを実行しなければならない。
ICMPメッセージは通常、データグラム処理におけるエラーを通知する。メッ
セージについてのメッセージについての……と無限に返し合うのを避けるた
めに、ICMPメッセージについてのICMPメッセージは送信されない。フラグメ
ントされたデータグラムを処理する際のエラーのICMPメッセージも、フラグ
メント0の処理のときだけである（フラグメント0とは、フラグメントオフセ
ットが0のものである）。
[Page 1]
1981年9月
RFC 792
メッセージフォーマット
ICMPメッセージは基本的なIPヘッダを使用して送信される。データグラムの
データ部における最初のオクテットは、ICMPタイプフィールドである。この
フィールドの値は以降のデータのフォーマットを決める。「未使用」と記さ
れたフィールドは後の拡張のために予約されており、送信時には0でなければ
ならないが、受信側はこのフィールドを使用すべきではない（チェックサム
に含めるときを除く）。個々のフォーマット解説で別途表記しない限りは、
インターネットヘッダフィールドの値は以下のとおりとなる。
バージョン
4
IHL
32ビットワード単位のインターネットヘッダ長。
サービスタイプ
0
全パケット長
オクテット単位でのインターネットヘッダおよびデータの長さ。
{識別子、フラグ、フラグメントオフセット
フラグメンテーションで使用、［1］を参照せよ。
生存時間
秒単位での生存時間。データグラムを処理するそれぞれのマシンでこのフ
ィールドが減らされるため、このフィールドの値は少なくともデータグラ
ムが通り抜けるゲートウェイの数にすべきである。
プロトコル
ICMP = 1
ヘッダチェックサム
ヘッダ内の全16ビットワードの1の補数を合計したものの16ビットの1の補
数。チェックサムの計算の際は、チェックサムフィールドは0にする。こ
のチェックサムは将来変更される可能性がある。
[Page 2]
1981年9月
RFC 792
送信元アドレス
ICMPメッセージを構成するゲートウェイまたはホストのアドレス。別途表
記しない限り、これはゲートウェイのアドレスのどれかになる。
宛先アドレス
メッセージが送るべきゲートウェイまたはホストのアドレス。
[Page 3]
1981年9月
RFC 792
宛先到達不能メッセージ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| タイプ | コード | チェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 未使用 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| インターネットヘッダ + 64ビットの元データからなるデータグラム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPフィールド：
宛先アドレス
元のデータグラムのデータグラムのデータから得た送信元ネットワークと
アドレス。
ICMPフィールド：
タイプ
3
コード
0 = ネット到達不能
1 = ホスト到達不能
2 = プロトコル到達不能
3 = ポート到達不能
4 = 要フラグメンテーション・DFセット
5 = ソースルート失敗
チェックサム
チェックサムは、ICMPタイプから始まるICMPメッセージの1の補数の合計
について、16ビットの1の補数を取ったものである。チェックサム計算中
は、チェックサムフィールドを0にする。このチェックサムは将来置き換
えられる可能性がある。
[Page 4]
1981年9月
RFC 792
インターネットヘッダ + 64ビットのデータからなるデータグラム
元のデータグラムのインターネットヘッダとデータの先頭64ビット。この
データは、ホストがメッセージを適切なプロセスと対応させるために使用
する。上位プロトコルがポート番号を使用しているのであれば、元データ
グラムのデータの先頭64データビットにそのポート番号があるという仮定
である。
解説
ゲートウェイのルーティングテーブルの情報に従ったとき、データグラム
のインターネット宛先フィールドで指定されたネットワークが到達不能で
ある場合、例えば、そのネットワークへの距離が無限大であるような場合、
そのゲートウェイは宛先到達不能メッセージをデータグラムのインターネ
ットの送信元ホストに送信することができる。さらに、ネットワークによ
っては、ゲートウェイが、インターネット宛先ホストが到達不能かどうか
を判別することもできる。このようなネットワークのゲートウェイは、宛
先ホストが到達不能なとき宛先到達不能メッセージを送信元ホストに送信
することができる。
宛先ホストにおいて、指定されたプロトコルモジュールやプロセスのポー
トがアクティブでないために、IPモジュールがデータグラムを配達できな
い場合、その宛先ホストは宛先到達不能メッセージを送信元ホストに送信
することができる。
それ以外に、データグラムをフラグメントしないと、ゲートウェイが転送
できない状況で、さらにフラグメント禁止フラグが立っている場合がある。
このようなとき、ゲートウェイはデータグラムを廃棄して宛先到達不能メ
ッセージを返すことができる。
コード0、1、4、5はゲートウェイから受け取ることになる。そして、コー
ド2、3はホストから受け取ることになる。
[Page 5]
1981年9月
RFC 792
時間超過メッセージ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| タイプ | コード | チェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 未使用 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| インターネットヘッダ + 64ビットの元データからなるデータグラム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPフィールド：
宛先アドレス
元のデータグラムのデータグラムのデータから得た送信元ネットワークと
アドレス。
ICMPフィールド：
タイプ
11
コード
0 = 転送時の生存時間超過
1 = フラグメントのリアセンブリ時間超過
チェックサム
チェックサムは、ICMPタイプから始まるICMPメッセージの1の補数の合計
について、16ビットの1の補数を取ったものである。チェックサム計算中
は、チェックサムフィールドを0にする。このチェックサムは将来置き換
えられる可能性がある。
インターネットヘッダ + 64ビットのデータからなるデータグラム
元のデータグラムのインターネットヘッダとデータの先頭64ビット。この
データは、ホストがメッセージを適切なプロセスと対応させるために使用
する。上位プロトコルがポート番号を使用しているのであれば、元データ
グラムのデータの先頭64データビットにそのポート番号があるという仮定
である。
[Page 6]
1981年9月
RFC 792
解説
ゲートウェイがデータグラムを処理している際、生存時間フィールド値が
0になっていると判ると、そのデータグラムを廃棄する。さらに、このと
きゲートウェイは時間超過メッセージを使って送信元ホストに通知を行う
ことができる。
ホストがフラグメントされたデータグラムをリアセンブルしている際、制
限時間内にフラグメントが到着せずリアセンブリが完了できなかった場合、
そのデータグラムを廃棄し、時間超過メッセージを送信することができる。
フラグメント0が来なかった場合は、時間超過メッセージは一切送信され
ない。
コード0はゲートウェイから受け取ることになる。そして、コード1はホス
トから受け取ることになる。
[Page 7]
1981年9月
RFC 792
パラメータ異常メッセージ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| タイプ | コード | チェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ポインタ | 未使用 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| インターネットヘッダ + 64ビットの元データからなるデータグラム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPフィールド：
宛先アドレス
元のデータグラムのデータグラムのデータから得た送信元ネットワークと
アドレス。
ICMPフィールド：
タイプ
12
コード
0 = ポインタがエラーを示している
チェックサム
チェックサムは、ICMPタイプから始まるICMPメッセージの1の補数の合計
について、16ビットの1の補数を取ったものである。チェックサム計算中
は、チェックサムフィールドを0にする。このチェックサムは将来置き換
えられる可能性がある。
ポインタ
コード = 0の場合、エラーが検出されたオクテットを示している。
インターネットヘッダ + 64ビットのデータからなるデータグラム
元のデータグラムのインターネットヘッダとデータの先頭64ビット。この
データは、ホストがメッセージを適切なプロセスと対応させるために使用
する。上位プロトコルがポート番号を使用しているのであれば、元データ
グラムのデータの先頭64データビットにそのポート番号があるという仮定
である。
[Page 8]
1981年9月
RFC 792
解説
ゲートウェイやホストがデータグラムを処理している際、データグラムの
処理を完了できないようなヘッダのパラメータの異常を発見した場合、そ
のデータグラムを廃棄しなければならない。このような異常を発生させる
原因になり得るものとして、不正な引数のオプションがある。また、この
ときさらにゲートウェイやホストは、送信元ホストにパラメータ異常メッ
セージで通知することができる。このメッセージは、エラーでデータグラ
ムが廃棄された場合にだけ送信される。
ポインタは、元のデータグラムのヘッダにおいてエラーが検出されたオク
テットを示している（オプションの途中の場合もある）。例えば、1とい
う値はサービスタイプの部分で何か異常があることを示しており、（オプ
ションが存在するとして）20という値は最初のオプションのタイプコード
に何か異常があることを示している。
コード0はゲートウェイまたはホストから受け取ることになる。
[Page 9]
1981年9月
RFC 792
送信元抑制メッセージ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| タイプ | コード | チェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 未使用 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| インターネットヘッダ + 64ビットの元データからなるデータグラム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPフィールド：
宛先アドレス
元のデータグラムのデータグラムのデータから得た送信元ネットワークと
アドレス。
ICMPフィールド：
タイプ
4
コード
0
チェックサム
チェックサムは、ICMPタイプから始まるICMPメッセージの1の補数の合計
について、16ビットの1の補数を取ったものである。チェックサム計算中
は、チェックサムフィールドを0にする。このチェックサムは将来置き換
えられる可能性がある。
インターネットヘッダ + 64ビットのデータからなるデータグラム
元のデータグラムのインターネットヘッダとデータの先頭64ビット。この
データは、ホストがメッセージを適切なプロセスと対応させるために使用
する。上位プロトコルがポート番号を使用しているのであれば、元データ
グラムのデータの先頭64データビットにそのポート番号があるという仮定
である。
解説
宛先ネットワークへの経路の途中で、次のネットワークへの出力するとき
データグラムをキューイングするために必要なバッファ容量が無い場合、
[Page 10]
1981年9月
RFC 792
ゲートウェイはインターネットデータグラムを廃棄する。ゲートウェイが
データグラムを廃棄する場合、そのデータグラムのインターネット送信元
ホストに送信元抑制メッセージを送信することができる。さらに宛先ホス
トも、データグラムの到着が早すぎて処理しきれない場合に送信元抑制メ
ッセージを送ることができる。送信元抑制メッセージは、ホストに対して、
このインターネットでの宛先に向かうトラフィックの送信速度を落とすよ
う要求することである。ゲートウェイは廃棄される全てのメッセージに対
して送信元抑制メッセージを送信することができる。送信元抑制メッセー
ジを受け取った場合、送信元ホストは、ゲートウェイから送信元抑制メッ
セージが来なくなるまで、指定の宛先に向かうトラフィックの送信速度を
落とすべきである。そして、送信元ホストは、再び送信元抑制メッセージ
を受け取るまで、その宛先に向かうトラフィックの送信速度を徐々に上げ
ていくことができる。
ゲートウェイやホストは、容量を越えるまで待たないで、容量の限界に近
づいた段階で送信元抑制メッセージを送っても構わない。これは、送信元
抑制メッセージの引き金となるようなデータのデータグラムが送られる可
能性がでてきたことを意味する。
コード0はゲートウェイまたはホストから受け取ることになる。
[Page 11]
1981年9月
RFC 792
リダイレクトメッセージ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| タイプ | コード | チェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ゲートウェイのインターネットアドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| インターネットヘッダ + 64ビットの元データからなるデータグラム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPフィールド：
宛先アドレス
元のデータグラムのデータグラムのデータから得た送信元ネットワークと
アドレス。
ICMPフィールド：
タイプ
5
コード
0 = ネットワークについてのデータグラムのリダイレクト
1 = ホストについてのデータグラムのリダイレクト
2 = サービスタイプとネットワークについてのデータグラムのリダイレク
ト
3 = サービスタイプとホストについてのデータグラムのリダイレクト
チェックサム
チェックサムは、ICMPタイプから始まるICMPメッセージの1の補数の合計
について、16ビットの1の補数を取ったものである。チェックサム計算中
は、チェックサムフィールドを0にする。このチェックサムは将来置き換
えられる可能性がある。
ゲートウェイのインターネットアドレス
元データグラムのデータのインターネット宛先ネットワークフィールドに
指定されているネットワークへ向かうときにトラフィックが送信されるべ
きゲートウェイのアドレス。
[Page 12]
1981年9月
RFC 792
インターネットヘッダ + 64ビットのデータからなるデータグラム
元のデータグラムのインターネットヘッダとデータの先頭64ビット。この
データは、ホストがメッセージを適切なプロセスと対応させるために使用
する。上位プロトコルがポート番号を使用しているのであれば、元データ
グラムのデータの先頭64データビットにそのポート番号があるという仮定
である。
解説
ゲートウェイは次のような状況でリダイレクトメッセージをホストに送信
する。ゲートウェイG1は、接続されているネットワーク上のホストからイ
ンターネットデータグラムを受信する。ゲートウェイG1は、ルーティング
テーブルを見てデータグラムのインターネット宛先ネットワークXに向か
う経路上の次のゲートウェイG2のアドレスを得る。G2とデータグラムのイ
ンターネット送信元アドレスが示すホストが同一ネットワーク上にある場
合、そのホストに対してリダイレクトメッセージが送信される。リダイレ
クトメッセージによって、ネットワークXに対する自身のトラフィックは
直接ゲートウェイG2に送信すれば、その宛先へのより短いパスとなること
をホストは知ることができる。そしてゲートウェイは、元のデータグラム
のデータをインターネット宛先に転送する。
IPソースルートオプションおよび宛先アドレスフィールドにゲートウェイ
アドレスを持つデータグラムの場合、ソースルートの次のアドレスより最
終的な宛先へのもっと良い経路があったとしても、リダイレクトメッセー
ジが送信されることはない。
コード0、1、2、3はゲートウェイまたはホストから受け取ることになる。
[Page 13]
1981年9月
RFC 792
エコー／エコー応答メッセージ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| タイプ | コード | チェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 | シーケンス番号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ ...
+-+-+-+-+-
IPフィールド：
宛先アドレス
エコーメッセージにおける送信元のアドレスはエコー応答メッセージの宛
先になる。エコー応答メッセージを作るには、送信元アドレスと宛先アド
レスを単純に逆にして、タイプコードを0に変更し、チェックサムを再計
算すればよい。
ICMPフィールド：
タイプ
8 エコーメッセージ
0 エコー応答メッセージ
コード
0
チェックサム
チェックサムは、ICMPタイプから始まるICMPメッセージの1の補数の合計
について、16ビットの1の補数を取ったものである。チェックサム計算中
は、チェックサムフィールドを0にする。全体の長さが奇数になった場合、
チェックサムの計算のために、受信データに0で埋められた1オクテット分
のパディングが行われる。このチェックサムは将来置き換えられる可能性
がある。
識別子
コード = 0のとき、識別子はエコーと応答との対応付けの手がかりとなる
が、別に0でも構わない。
シーケンス番号
[Page 14]
1981年9月
RFC 792
コード = 0のとき、シーケンス番号はエコーと応答との対応付けの手がか
りとなるが、別に0でも構わない。
解説
エコーメッセージで受信したデータは、エコー応答メッセージで返さなけ
ればならない。
識別子とシーケンス番号は、エコーの送信側が応答とエコー要求との対応
付けの手がかりとして使用可能である。例えば、識別子はTCPやUDPにおけ
るポートのように使用してセッションを識別し、シーケンス番号は送信さ
れるエコー要求ごとに増加させるということもできる。エコーを返す側は、
エコー応答で同じ識別子とシーケンス番号の値を返す。
コード0はゲートウェイまたはホストから受け取ることになる。
[Page 15]
1981年9月
RFC 792
タイムスタンプ／タイムスタンプ応答メッセージ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| タイプ | コード | チェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 | シーケンス番号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 元のタイムスタンプ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 受信タイムスタンプ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 送信タイムスタンプ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPフィールド：
宛先アドレス
タイムスタンプメッセージにおける送信元のアドレスはタイムスタンプ応
答メッセージの宛先になる。タイムスタンプ応答メッセージを作るには、
送信元アドレスと宛先アドレスを単純に逆にして、タイプコードを14に変
更し、チェックサムを再計算すればよい。
ICMPフィールド：
タイプ
13 タイムスタンプメッセージ
14 タイムスタンプ応答メッセージ
コード
0
チェックサム
チェックサムは、ICMPタイプから始まるICMPメッセージの1の補数の合計
について、16ビットの1の補数を取ったものである。チェックサム計算中
は、チェックサムフィールドを0にする。このチェックサムは将来置き換
えられる可能性がある。
識別子
コード = 0のとき、識別子はタイムスタンプと応答との対応付けの手がか
りとなるが、別に0でも構わない。
[Page 16]
1981年9月
RFC 792
シーケンス番号
コード = 0のとき、シーケンス番号はタイムスタンプと応答との対応付け
の手がかりとなるが、別に0でも構わない。
解説
メッセージで受信したデータ（タイムスタンプ）は、タイムスタンプが追
加された応答で返される。タイムスタンプはUTの午前0時からのミリ秒を
表す32ビットである。このタイムスタンプの使い方の1つはMills［5］に
よって述べられている。
元のタイムスタンプは送信側が送信前に最後にメッセージを処理した時刻
であり、受信タイムスタンプはエコーを返す側が受信時に最初に処理した
時刻、送信タイムスタンプはエコーを返す側が送信時に最後にメッセージ
を処理した時刻である。
ミリ秒単位で時刻を得られない、あるいはUTの午前0時からの時刻が提供
できない場合は、それが非標準の値であることを示すためにタイムスタン
プの上位ビットをセットするという条件で、タイムスタンプに任意の時刻
を入れることができる。
識別子とシーケンス番号は、送信側が応答と要求との対応付けの手がかり
として使用可能である。例えば、識別子はTCPやUDPにおけるポートのよう
に使用してセッションを識別し、シーケンス番号は送信される要求ごとに
増加させるということもできる。宛先側は、応答で同じ識別子とシーケン
ス番号の値を返す。
コード0はゲートウェイまたはホストから受け取ることになる。
[Page 17]
1981年9月
RFC 792
情報要求／情報応答メッセージ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| タイプ | コード | チェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 | シーケンス番号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPフィールド：
宛先アドレス
情報要求メッセージにおける送信元のアドレスは情報応答メッセージの宛
先になる。情報応答メッセージを作るには、送信元アドレスと宛先アドレ
スを単純に逆にして、タイプコードを16に変更し、チェックサムを再計算
すればよい。
ICMPフィールド：
タイプ
15 情報要求メッセージ
16 情報応答メッセージ
コード
0
チェックサム
チェックサムは、ICMPタイプから始まるICMPメッセージの1の補数の合計
について、16ビットの1の補数を取ったものである。チェックサム計算中
は、チェックサムフィールドを0にする。このチェックサムは将来置き換
えられる可能性がある。
識別子
コード = 0のとき、識別子は要求と応答との対応付けの手がかりとなるが、
別に0でも構わない。
シーケンス番号
コード = 0のとき、シーケンス番号は要求と応答との対応付けの手がかり
となるが、別に0でも構わない。
[Page 18]
1981年9月
RFC 792
解説
このメッセージは、送信元のネットワークを通じて、IPヘッダの送信元・
宛先アドレスフィールドに0（「自分の」ネットワークを意味する）を入
れて送信できる。応答するIPモジュールは、完全指定のアドレスを入れて
応答を送信すべきである。このメッセージは、ホストが接続されているネ
ットワークの番号を調べる1つの方法である。
識別子とシーケンス番号は、送信側が応答と要求との対応付けの手がかり
として使用可能である。例えば、識別子はTCPやUDPにおけるポートのよう
に使用してセッションを識別し、シーケンス番号は送信される要求ごとに
増加させるということもできる。宛先側は、応答で同じ識別子とシーケン
ス番号の値を返す。
コード0はゲートウェイまたはホストから受け取ることになる。
[Page 19]
1981年9月
RFC 792
メッセージタイプのまとめ
0 エコー応答
3 宛先到達不能
4 送信元抑制
5 リダイレクト
8 エコー
11 時間超過
12 パラメータ異常
13 タイムスタンプ
14 タイムスタンプ応答
15 情報要求
16 情報応答
[Page 20]
1981年9月
RFC 792
参考文献
[1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program
Protocol Specification," RFC 791, USC/Information Sciences
Institute, September 1981.
[2] Cerf, V., "The Catenet Model for Internetworking," IEN 48,
Information Processing Techniques Office, Defense Advanced
Research Projects Agency, July 1978.
[3] Strazisar, V., "Gateway Routing: An Implementation
Specification", IEN 30, Bolt Beranek and Newman, April 1979.
[4] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek
and Newman, August 1979.
[5] Mills, D., "DCNET Internet Clock Service," RFC 778, COMSAT
Laboratories, April 1981.
[Page 21]
一覧
スポンサーリンク
