RFC791 日本語訳
0791 Internet Protocol. J. Postel. September 1981. (Format: TXT=97779 bytes) (Obsoletes RFC0760) (Updated by RFC1349) (Also STD0005) (Status: STANDARD)
RFC一覧
英語原文
RFC: 791
インターネットプロトコル
DARPAインターネットプログラム
プロトコル仕様書
1981年9月
提出先
Defense Advanced Research Projects Agency
Information Processing Techniques Office
1400 Wilson Boulevard
Arlington, Virginia 22209
作成
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
1981年9月
インターネットプロトコル
目 次
前書き ......................................................... iii
1. 序説 ............................................................. 1
1.1 動機 .......................................................... 1
1.2 スコープ ...................................................... 1
1.3 インタフェース ................................................ 1
1.4 動作 .......................................................... 2
2. 概観 ............................................................. 5
2.1 他のプロトコルとの関係 ........................................ 5
2.2 動作モデル .................................................... 5
2.3 機能解説 ...................................................... 7
2.4 ゲートウェイ .................................................. 9
3. 仕様 ............................................................ 11
3.1 インターネットヘッダフォーマット ............................. 11
3.2 議論 ......................................................... 22
3.3 インタフェース................................................ 31
付録A： 具体例とシナリオ ............................................ 34
付録B： データ転送順序 .............................................. 39
用 語 ............................................................... 41
参考文献 ............................................................ 45
[Page i]
1981年9月
インターネットプロトコル
[Page ii]
1981年9月
インターネットプロトコル
前書き
このドキュメントはDoD標準のインターネットプロトコルを規定している。この
ドキュメントは、以前の版の6つのARPAインターネットプロトコル仕様書を基に
しており、現在の文章の多くはこれらの版から集められたものである。多くの方
が、コンセプトの面と文章の面でこの作業に貢献してくれた。この版では、アド
レッシング、エラー処理、オプションコードの部分や、インターネットプロトコ
ルのセキュリティ・優先度・コンパートメント・ハンドリング制限の機能の部分
で改訂されている。
Jon Postel
編者
[Page iii]
1981年9月
RFC： 791
置換： RFC 760
IEN 128, 123, 111,
80, 54, 44, 41, 28, 26
インターネットプロトコル
DARPAインターネットプログラム
プロトコル仕様書
1. 序説
1.1. 動機
インターネットプロトコルは、相互接続されたパケット交換型コンピュータ通
信ネットワークシステムで使用するように設計されている。このようなシステ
ムは「catenet」［1］と呼ばれてきた。インターネットプロトコルは、データ
グラムと呼ばれるデータのブロックを送信元から宛先へと転送することを規定
している。ここで送信元と宛先は、固定長のアドレスで識別されるホストであ
る。また、インターネットプロトコルは、「小パケット」ネットワークでの転
送で、必要に応じて、長いデータグラムのフラグメンテーションとリアセンブ
リすることも規定している。
1.2. スコープ
インターネットプロトコルは、 特にビットの塊 （インターネットデータグラ
ム）を相互接続されたネットワークシステム上で送信元から宛先へと配送する
ために必要な機能を提供するという範囲に限られる。ホスト・ホスト間プロト
コルで一般的に見られる、エンド・エンド間のデータの信頼性、フロー制御、
順番制御などのサービスを向上させるメカニズムは持っていない。インターネ
ットプロトコルは、サポートするネットワークのサービスを利用して様々なサ
ービスタイプやサービス品質を提供することができる。
1.3. インタフェース
このプロトコルは、インターネット環境のホスト・ホスト間プロトコルによっ
て呼び出される。また、このプロトコルは、インターネットデータグラムを次
のゲートウェイまたは宛先ホストに運ぶためにローカルネットワークプロトコ
ルを呼び出す。
例えば、TCPモジュールはインターネットモジュールを呼び出して、（TCPヘッ
ダとユーザデータを含む）TCPセグメントをインターネットデータグラムのデ
ータ部として運ぶ。TCPモジュールは、呼び出す際の引数としてインターネッ
トヘッダ中のアドレスとその他のパラメータをインターネットモジュールに渡
す。そして、インターネットモジュールはインターネットデータグラムを作り、
ローカルネットワークインタフェースを呼び出してインターネットデータグラ
ムを転送する。
例えばARPANETの場合、インターネットモジュールはローカルネットモジュー
[Page 1]
1981年9月
インターネットプロトコル
序説
ルを呼び出す。このローカルネットモジュールは、IMPに転送するために1822
リーダ［2］を付けてARPANETメッセージを作成する。ARPANETアドレスは、ロ
ーカルネットワークインタフェースによってインターネットアドレスから得ら
れ、ARPANET内のあるホストのアドレスである。このホストは他のネットワー
クへのゲートウェイかもしれない。
1.4. 動作
インターネットプロトコルは2つの基本的な機能を実装している。それはアド
レッシングとフラグメンテーションである。
インターネットモジュールは、インターネットヘッダに入っているアドレスを
使用して、インターネットデータグラムをその宛先へと転送する。転送に使う
パスの選択のことをルーティングと呼んでいる。
インターネットモジュールは、「小パケット」ネットワークでの転送に必要な
場合、インターネットヘッダ内のフィールドを使用して、インターネットデー
タグラムのフラグメントやリアセンブルを行う。
この動作のモデルでは、インターネット通信に参加している各ホストやネット
ワークを相互接続している各ゲートウェイにインターネットモジュールが備わ
っている。このモジュールは、アドレスフィールドの解釈やインターネットデ
ータグラムのフラグメントとリアセンブルに対する共通のルールを共有する。
さらに、このモジュール（特にゲートウェイのモジュール）は、ルーティング
決定などの機能を行うためのプロシージャを持っている。
インターネットプロトコルは、それぞれのインターネットデータグラムを他の
インターネットデータグラムと関連性がない独立したものとして扱う。コネク
ションや論理的な回線は（仮想的なものも、そうでないものも）存在しない。
インターネットプロトコルは、サービスを提供する際に4つの主要なメカニズ
ムを使用する。すなわち、サービスタイプ、生存時間、オプション、ヘッダチ
ェックサムである。
サービスタイプは、求められるサービスの品質を示すために使用する。サービ
スタイプは抽象的な、あるいは一般化されたパラメータの集合で、インターネ
ットを構成するネットワークで提供されているサービスの選択方法の特徴を決
める。このサービスタイプの指定はゲートウェイが使用し、個々のネットワー
クに対する実際の転送パラメータや、ネクストホップに対して使用するネット
ワーク、インターネットデータグラムをルーティングするときのネクストゲー
トウェイなどを選択するためのものである。
生存時間は、インターネットデータグラムの有効期間の上限を示すものである。
この値は、データグラムの送信者が設定し、経路上の処理を行うポイントで減
らされる。インターネットデータグラムが宛先に到達する前に生存時間が0に
なった場合、そのインターネットデータグラムは破棄される。生存時間は自爆
タイムリミットと考えることもできる。
[Page 2]
1981年9月
インターネットプロトコル
序説
オプションは、ある状況では必要または有用だが、およそ一般的な通信では必
要ないような制御機能を提供する。このオプションには、タイムスタンプ、セ
キュリティ、特殊なルーティングの提供が含まれる。
ヘッダチェックサムは、インターネットデータグラムの処理に使用する情報が
正しく転送されてきたかを確認する機能を提供する。データがエラーを含んで
いる可能性もある。ヘッダチェックサムに失敗した場合、そのインターネット
データグラムはエラーを検出した機器によってただちに廃棄される。
インターネットプロトコルは信頼性のある通信機能を提供しない。エンド間や
ホップごとの応答確認は無い。ヘッダのチェックサムだけで、データのエラー
制御も無い。また、再送やフロー制御も無い。
検出されたエラーを、インターネットプロトコルモジュールで実装されている
インターネット制御メッセージプロトコル（ICMP）［3］で通知することもあ
る。
[Page 3]
1981年9月
インターネットプロトコル
[Page 4]
1981年9月
インターネットプロトコル
2. 概観
2.1. 他のプロトコルとの関係
以下の図は、プロトコル階層構造におけるインターネットプロトコルの位置付
けを示している。
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | | TFTP| ... | ... |
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | UDP | ... | ... |
+-----+ +-----+ +-----+
| | |
+---------------------------------+
| インターネットプロトコル & ICMP |
+---------------------------------+
|
+---------------------------------+
| ローカルネットワークプロトコル |
+---------------------------------+
プロトコル関係図
図1
インターネットプロトコルは、一方で上位のホスト・ホスト間プロトコルと結
びつき、もう一方でローカルネットワークプロトコルと結びついている。この
文で「ローカルネットワーク」は、ビル内の小規模ネットワークかもしれない
し、ARPANETのような大規模ネットワークかもしれない。
2.2. 動作モデル
データグラムをあるアプリケーションプログラムから別のアプリケーションプ
ログラムに転送するときの動作モデルは、以下のシナリオで説明される。
この転送には1つの中間ゲートウェイが含まれているとする。
送信する方のアプリケーションプログラムは、データを準備し、ローカルの
インターネットモジュール呼び出してデータをデータグラムとして送信し、
宛先アドレスとその他のパラメータを呼び出しの引数として渡す。
インターネットモジュールは、データグラムヘッダを準備し、それにデータ
を付加する。インターネットモジュールは、このインターネットアドレスに
たどり着くためのローカルネットワークアドレスを決定する。この場合ゲー
トウェイのアドレスである。
[Page 5]
1981年9月
インターネットプロトコル
概観
このデータグラムとローカルネットワークアドレスをローカルネットワーク
インタフェースに送信する。
ローカルネットワークインタフェースはローカルネットワークヘッダを作成
し、それにデータグラムを付加する。そして、できたものをローカルネット
ワークを通して送信する。
データグラムはローカルネットワークヘッダに包まれてゲートウェイホスト
に到着し、ローカルネットワークインタフェースはこのヘッダを取り去って
データグラムをインターネットモジュールに引き渡す。インターネットモジ
ュールは、データグラムが2つ目のネットワークにある別のホストに転送さ
れるべきであることをインターネットアドレスから判断する。インターネッ
トモジュールは、宛先ホストにたどり着くためのローカルネットワークアド
レスを決定する。そして、このネットワークに対するローカルネットワーク
インタフェースを呼び出して、データグラムを送信する。
このローカルネットワークインタフェースはローカルネットワークヘッダを
作成し、データグラムを付加し、それを宛先ホストに送信する。
この宛先ホストでは、データグラムはローカルネットワークインタフェース
によってローカルネットヘッダを取り去られ、インターネットモジュールに
渡される。
インターネットモジュールは、このデータグラムが自分のホストのアプリケ
ーションプログラム宛てであることを判断する。システムコールに応答する
形でアプリケーションプログラムにデータを渡し、呼び出し結果としてソー
スアドレスと他のパラメータを渡す。
アプリケーション アプリケーション
プログラム プログラム
＼ ／
インターネット インターネット インターネット
モジュール モジュール モジュール
＼ ／ ＼ ／
LNI-1 LNI-1 LNI-2 LNI-2
＼ ／ ＼ ／
ローカルネットワーク1 ローカルネットワーク2
転送パス
図2
[Page 6]
1981年9月
インターネットプロトコル
概観
2.3. 機能解説
インターネットプロトコルの機能や目的は、相互接続されたネットワーク群を
通してデータグラムを運ぶことである。これは、宛先にたどり着くまで、イン
ターネットモジュールから別のインターネットモジュールへとデータグラムを
渡していくことで実行される。インターネットモジュールは、インターネット
システムにおけるホストおよびゲートウェイに備わっている。データグラムは、
インターネットモジュールから別のインターネットモジュールへと個々のネッ
トワークを通るとき、インターネットアドレスの解釈に基づいてルーティング
される。これから判るように、インターネットプロトコルの重要なメカニズム
の1つはインターネットアドレスである。
インターネットモジュールから別のインターネットモジュールへとメッセージ
をルーティングするとき、データグラムは、自分のサイズよりも小さい最大パ
ケットサイズを持つネットワークを通る必要があるかもしれない。この困難を
解決するために、フラグメンテーションのメカニズムがインターネットプロト
コルでは提供されている。
アドレッシング
区別は名前、アドレス、経路で行われる［4］。名前は何を探しているかを
示す。アドレスはどこにあるかを示す。経路はどうやってそこに至るかを示
す。インターネットプロトコルは主にアドレスを扱う。名前からアドレスへ
の対応付けを行うことは上位（すなわち、ホスト・ホスト間やアプリケーシ
ョン）プロトコルの仕事である。インターネットモジュールは、インターネ
ットアドレスとローカルネットアドレスを対応付ける。ローカルネットアド
レスから経路への対応付けは下位（すなわち、ローカルネットやゲートウェ
イ）プロトコルの仕事である。
アドレスは4オクテット（32ビット）の固定長である。アドレスはネットワ
ーク番号で始まり、ローカルアドレス（「レスト」フィールドと呼ぶ）が続
く。インターネットアドレスには3つの形式あるいはクラスが存在する。ク
ラスaでは、上位ビットが0で、次の7ビットがネットワーク、最後の24ビッ
トがローカルアドレスとなる。クラスbでは、上位2ビットが10で、次の14ビ
ットがネットワーク、最後の16ビットがローカルアドレスとなる。クラスc
では、上位3ビットが110で、次の21ビットがネットワーク、最後の8ビット
がローカルアドレスとなる。
インターネットアドレスとローカルネットアドレスの対応付けには注意が必
要だ。1台の物理的なホストが、複数の異なるインターネットアドレスを使
用する場合に、複数の異なるホストであるかのようにふるまうことができな
ければならない。ホストによっては、複数の物理インタフェースを持つこと
もある（マルチホーミング）。
すなわち、ホストがネットワークに対して複数の物理インタフェースを持ち、
それぞれが複数の論理インターネットアドレスを持つ場合に備えなければな
らない。
[Page 7]
1981年9月
インターネットプロトコル
概観
アドレスの対応付けの例は『Address Mappings』［5］にある。
フラグメンテーション
大きなパケットサイズを許すローカルネットで作られたデータグラムが、宛
先に到達するまでの途中のネットワークでより小さいサイズにパケットが制
限されるとき、インターネットデータグラムのフラグメンテーションが必要
となる。
インターネットデータグラムには「フラグメント禁止」とマークすることが
できる。このようにマークされたインターネットデータグラムは、どんな場
合でもインターネットフラグメントされることはない。フラグメント禁止と
マークされたインターネットデータグラムが、フラグメントせずには宛先ま
で送信できない場合、送信せず廃棄すべきである。
インターネットプロトコルモジュールに見えないローカルネットワーク内で
のフラグメンテーション、転送、リアセンブリは、イントラネットフラグメ
ンテーションと呼ばれ、使用可能である［6］。
インターネットフラグメンテーションおよびリアセンブリのプロシージャは、
後でリアセンブル可能なほぼ自由な数の断片にデータグラムを分割できなけ
ればならない。フラグメントの受信側は識別子フィールドを使用して、異な
るデータグラムのフラグメントが混在しないようにする。フラグメントのオ
フセットフィールドは、元のデータグラムにおけるフラグメントの位置を受
信側に伝える。フラグメントのオフセットおよび長さフィールドによって、
元のデータグラムのどの部分をこのフラグメントが扱っているかが判る。フ
ラグメント継続フラグは、（0にセットすることで）最後のフラグメントで
あることを示す。これらのフィールドは、データグラムをリアセンブルする
ための重要な情報を提供する。
識別子フィールドは、あるデータグラムと別のデータグラムのフラグメント
を区別するために使用する。インターネットデータグラムの発信元プロトコ
ルモジュールは識別子フィールドに値をセットするが、データグラムがイン
ターネットシステムでアクティブな期間は、その送信元・宛先の組み合わせ
とプロトコルについてこの値が一意でなければならない。完全なデータグラ
ムの場合は、発信元プロトコルモジュールによってフラグメント継続フラグ
が0に、フラグメントオフセットが0にセットされる。
長いインターネットデータグラムをフラグメントする場合、（例えばゲート
ウェイにおける）インターネットプロトコルモジュールは、2つの新しいイ
ンターネットデータグラムを作り、インターネットヘッダフィールドの内容
をその長いデータグラムから両方の新しいインターネットヘッダにコピーす
る。長いデータグラムののデータは、8オクテット（64ビット）境界で2つの
部分に分割される （2番目の部分は8オクテットの整数倍でなくても構わな
い）。1番目の部分の8オクテットブロックの数をNFB（フラグメントブロッ
ク数）と呼ぶ。データの1番目の部分は、1番目の新しいインターネットデー
タグラムに入れられ、全パケット長フィールドは1番目のデータグラムの長
さがセットされる。そして、フラグメント継続フラグは1にセットされる。
[Page 8]
1981年9月
インターネットプロトコル
概観
データの2番目の部分は、2番目の新しいインターネットデータグラムに入れ
られ、全パケット長フィールドは2番目のデータグラムの長さがセットされ
る。そして、フラグメント継続フラグは、元の長いデータグラムと同じ値を
運ぶことになる。2番目の新しいインターネットデータグラムのフラグメン
トオフセットフィールドは、元の長いデータグラムのフラグメントオフセッ
トフィールドの値にNFBを加えた値がセットされる。
このプロシージャは、説明した2分割だけではなく、n分割に一般化すること
ができる。
インターネットデータグラムのフラグメントをリアセンブルする場合、（例
えば、宛先ホストにおける）インターネットプロトコルモジュールは、識別
子フィールド、送信元フィールド、宛先フィールド、プロトコルフィールド
の4つのフィールドが同じ値である全てのインターネットデータグラムを結
合する。この結合は、フラグメントのインターネットヘッダのフラグメント
オフセットが示す相対的な位置に各フラグメントのデータ部分を格納するこ
とで行われる。最初のフラグメントのフラグメントオフセットは0であり、
最後のフラグメントのフラグメント継続フラグは0にリセットされているだ
ろう。
2.4. ゲートウェイ
ゲートウェイはネットワーク間でデータグラムを転送するために、インターネ
ットプロトコルを実行する。また、ゲートウェイはルーティングと他のインタ
ーネット制御情報を調整するために、ゲートウェイ間プロトコル（GGP）［7］
も実行する。
ゲートウェイでは上位プロトコルは実装されていなくてもよく、GGP機能がIP
モジュールに追加されている。
+---------------------------------------+
| インターネットプロトコル & ICMP & GGP |
+---------------------------------------+
| |
+---------------+ +---------------+
| ローカルネット| | ローカルネット|
+---------------+ +---------------+
ゲートウェイプロトコル
図3
[Page 9]
1981年9月
インターネットプロトコル
[Page 10]
1981年9月
インターネットプロトコル
3. 仕様
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | IHL |サービスタイプ | 全パケット長 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 | Flg | フラグメントオフセット |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 生存時間 | プロトコル | ヘッダチェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 送信元アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 宛先アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| オプション | パディング |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
インターネットデータグラムヘッダの例
図4
注：目盛りはそれぞれ1ビットの位置を示している。
バージョン（Ver）： 4ビット
バージョンフィールドは、インターネットヘッダのフォーマットを示してい
る。このドキュメントでは、バージョン4について説明している。
IHL： 4ビット
インターネットヘッダ長は32ビットワード単位でのインターネットヘッダ長
であり、したがってデータの開始位置である。正しいヘッダの最小値は5で
あることに注意する。
[Page 11]
1981年9月
インターネットプロトコル
仕様
サービスタイプ： 8ビット
サービスタイプは、求められるサービスの品質の抽象的なパラメータの指定
である。このパラメータは、個々のネットワークでデータグラム転送すると
きの実際のサービスパラメータを選択するための指針として使用するもので
ある。それぞれのネットワークでサービスの優先度が提供され、このサービ
スの優先度によって、何らかの形で高い優先度のトラフィックが他のトラフ
ィックよりも重要なものとして扱われる（一般的に、高負荷時にある優先度
以上のトラフィックだけが受け入れられる）。重要な選択は、低遅延、高信
頼性、高スループットの3者間のトレードオフである。
ビット0-2： 優先度
ビット 3： 0 = 通常遅延 1 = 低遅延
ビット 4： 0 = 通常スループット 1 = 高スループット
ビット 5： 0 = 通常信頼性 1 = 高信頼性
ビット6-7： 将来使用するために予約
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | |
| 優先度 | D | T | R | 0 | 0 |
| | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
優先度
111 - ネットワーク制御
110 - インターネットワーク制御
101 - 重要情報／緊急命令用優先度
100 - 瞬間的・最優先
011 - 瞬間的
010 - 即時的
001 - 優先
000 - 通常
遅延、スループット、信頼性の指示を使った場合、サービスの（見方によっ
ては）コストが増大する可能性がある。多くのネットワークで、これらのパ
ラメータの1つについて性能を向上させることは、別のパラメータの性能を
悪化させることに結びつく。非常に稀なケースを除けば、セットするのは、
これら3つの指示のうち多くても2つまでにすべきである。
サービスタイプは、データグラムがインターネットシステム中を転送されて
いるときに、そのデータグラムの処理の指定に使われる。インターネットの
サービスタイプと、AUTODIN IIやARPANET、SATNET、PRNETのようなネットワ
ークで提供される実際のサービスとの対応付けの例は『Service Mappings』
［8］で与えられている。
ネットワーク制御という優先度指定は、ネットワーク内だけで使用すること
[Page 12]
1981年9月
インターネットプロトコル
仕様
を想定している。この指定の実際の使用や制御は、各ネットワークの責任と
なる。インターネットワーク制御という指定は、ゲートウェイ制御のオリジ
ネータだけが使用することを想定している。これらの優先度指定を実際に使
用することがあるネットワークにとって命題である場合、そのネットワーク
の責任でこれらの優先度指定を調べたり使用したりする制御をしなければな
らない。
全パケット長： 16ビット
全パケット長は、オクテット単位でのデータグラムの長さで、インターネッ
トヘッダとデータが含まれている。このフィールドが許すデータグラムの長
さは65,535オクテットまでである。このような長いデータグラムは、ほとん
どのホストやネットワークで扱えない。全てのホストは、576オクテットま
でのデータグラムを（そのデータグラムが完全な形で到着したのか、フラグ
メントとして到着したのかにかかわらず）許容するようになっていなければ
ならない。宛先において576オクテットよりも大きいデータグラムが許容さ
れるていると判っている場合は、ホストは576オクテットより大きいデータ
グラムだけを送信することが推奨される。
576という数は、適切なサイズのデータグブロックに必要なヘッダ情報を付
けて転送できるように選ばれている。例えば、このサイズならば、512オク
テットのデータブロックに64オクテットのヘッダを加えたものをデータグラ
ムに詰め込むことができる。最長のインターネットヘッダは60オクテットで、
通常のインターネットヘッダは20オクテットであり、上位プロトコルのヘッ
ダを入れる余地がある。
識別子： 16ビット
データグラムのフラグメントを組み立てる助けとなるよう、送信側が割り当
てられた識別用の値。
フラグ（Flg）： 3ビット
各種制御フラグである。
ビット0： 予約、必ず0とする
ビット1： (DF) 0 = フラグメント許可 1 = フラグメント禁止
ビット2： (MF) 0 = 最終フラグメント 1 = フラグメント継続
0 1 2
+---+---+---+
| | D | M |
| 0 | F | F |
+---+---+---+
フラグメントオフセット： 13ビット
このフィールドは、このフラグメントがデータグラムのどこに属しているか
[Page 13]
1981年9月
インターネットプロトコル
仕様
を示す。このフラグメントオフセットは、8オクテット（64ビット）を単位
でとしている。最初のフラグメントのオフセットは0となる。
生存時間： 8ビット
このフィールドは、データグラムがインターネットシステム内で存在し続け
られる最大時間を示す。このフィールドの値が0になると、そのデータグラ
ムは破棄される。このフィールドは、インターネットヘッダの処理の中で書
き換えられる。この時間は秒単位であるが、たとえデータグラムの処理が1
秒未満であっても、データグラムの処理を行う全てのモジュールはTTLを最
低1つは減らさなければならないので、TTLはデータグラムが存在できる時間
の上限でしかないと考えるべきである。TTLの狙いは、転送不可能なデータ
グラムが破棄されるようにし、データグラムの最大有効期間を決めることで
ある。
プロトコル： 8ビット
このフィールドは、 インターネットデータグラムのデータ部で使用されて
いる次レベルのプロトコルを示している。 各種プロトコルに対する値は
『Assigned Numbers』［9］で規定されている。
ヘッダチェックサム： 16ビット
ヘッダだけのチェックサムである。変更されるヘッダ（例えば生存時間）も
あるので、このチェックサムはインターネットヘッダを処理するポイントご
とに再計算と照合が行われる。
チェックサムアルゴリズムは次の通りである。
チェックサムフィールドは、ヘッダ内の全ての16ビットワードの1の補数
の和を取り、この和の16ビットの1の補数となる。チェックサムを計算す
る際は、チェックサムフィールドの値を0にして計算する。
このアルゴリズムはチェックサムの計算が簡単であり、妥当であることが実
験的な証拠で示されているが、これは暫定解であり、今後の実績によっては
CRCプロシージャに置き換えることもありえる。
送信元アドレス： 32ビット
送信元アドレス。第3.2節参照。
宛先アドレス： 32ビット
宛先アドレス。第3.2節参照。
[Page 14]
1981年9月
インターネットプロトコル
仕様
オプション： 可変
オプションはデータグラム中にあっても無くてもよい。これらは全てのIPモ
ジュール（ホストとゲートウェイ）で実装されなければならない。オプショ
ンとなっているのは、データグラムによってオプションが転送されるかどう
かであり、実装するかどうかではない。
環境によっては、セキュリティのオプションが全データグラムで要求される
かもしれない。
オプションフィールドは可変長である。0個以上のオプションを使うことが
できる。オプションのフォーマットには次の2つのケースがある。
ケース1： オプションタイプ単独オクテット。
ケース2： オプションタイプオクテットとオプション長オクテット、実際
のオプションデータオクテット群。
オプション長オクテットは、オプションタイプオクテットとオプション長オ
クテット、およびオプションデータオクテット群をカウントしている。
オプションタイプオクテットは次の3つのフィールドを持っていると考えら
れる。
1ビット コピーフラグ
2ビット オプションクラス
5ビット オプション番号
コピーフラグは、フラグメンテーション時にこのオプションを全フラグメン
トにコピーすることを示している。
0 = コピーしない
1 = コピーする
オプションクラスは以下の通りである。
0 = 制御
1 = 将来使用するために予約
2 = デバッグと計測
3 = 将来使用するために予約
[Page 15]
1981年9月
インターネットプロトコル
仕様
以下のインターネットオプションが定義されている。
クラス 番号 長さ 説明
------ ---- ---- ----
0 0 - オプションリスト終了。このオプションは1オクテッ
トだけ使用する。オプション長オクテットは持たな
い。
0 1 - ノーオペレーション。このオプションは1オクテット
だけ使用する。オプション長オクテットは持たない。
0 2 11 セキュリティ。DOD要求と互換性のあるセキュリティ、
区分、ユーザグループ（TCC）、取り扱い制限のコー
ドを運ぶために使う。
0 3 可変 ルーズソースルーティング。送信元が提供する情報
に基づいてインターネットデータグラムをルーティ
ングするのに使う。
0 9 可変 ストリクトソースルーティング。送信元が提供する
情報に基づいてインターネットデータグラムをルー
ティングするのに使う。
0 7 可変 レコードルート。インターネットデータグラムが取
る経路をトレースするのに使う。
0 8 4 ストリームID。ストリーム識別子を運ぶために使う。
2 4 可変 インターネットタイムスタンプ。
指定オプション定義
オプションリスト終了
+--------+
|00000000|
+--------+
タイプ=0
このオプションはオプションリストの終了を示している。これは、イン
ターネットヘッダ長が示すインターネットヘッダの終了と一致しない場
合もある。このオプションはそれぞれのオプションの終了ではなく、全
てのオプションの終了を示すとき使用するものであり、オプションの終
了がインターネットヘッダの終了と一致せずに異なっている場合だけ必
要である。
このオプションは、フラグメンテーション時、あるいはその他の理由で
コピー、挿入、削除してよい。
[Page 16]
1981年9月
インターネットプロトコル
仕様
ノーオペレーション
+--------+
|00000001|
+--------+
タイプ=1
このオプションは、例えば、連続するオプションの開始を32ビット境界
に揃えるためなどで、オプションとオプションの間に使用する。
このオプションは、フラグメンテーション時、あるいはその他の理由で
コピー、挿入、削除してよい。
セキュリティ
このオプションによって、ホストはセキュリティ、コンパートメント、
ハンドリング制限、TCC（閉域ユーザグループ）のパラメータを送信す
ることができる。このオプションのフォーマットは以下の通りである。
+--------+--------+---//---+---//---+---//---+---//---+
|10000010|00001011|SSS SSS|CCC CCC|HHH HHH| TCC |
+--------+--------+---//---+---//---+---//---+---//---+
タイプ=130 長さ=11
セキュリティ（Sフィールド）： 16ビット
16レベルのセキュリティ（そのうち8つは将来使用するために予約）
のうち1つを指定する。
00000000 00000000 - 非機密
11110001 00110101 - 内部
01111000 10011010 - EFTO
10111100 01001101 - MMMM
01011110 00100110 - PROG
10101111 00010011 - 取扱制限
11010111 10001000 - 機密
01101011 11000101 - 最高機密
00110101 11100010 - （将来使用するために予約）
10011010 11110001 - （将来使用するために予約）
01001101 01111000 - （将来使用するために予約）
00100100 10111101 - （将来使用するために予約）
00010011 01011110 - （将来使用するために予約）
10001001 10101111 - （将来使用するために予約）
11000100 11010110 - （将来使用するために予約）
11100010 01101011 - （将来使用するために予約）
[Page 17]
1981年9月
インターネットプロトコル
仕様
コンパートメント（Cフィールド）： 16ビット
転送される情報をコンパートメントに分けないときは、 全て 0 とい
う値を使用する。 それ以外のコンパートメントフィールドの値は、
Defense Intelligence Agencyから得ることができる。
ハンドリング制限（Hフィールド）： 16ビット
制御と解放を示すための値は英数2文字で、 Defense Intelligence
Agency Manual DIAM 65-19『Standard Security Markings』で定義さ
れている。
転送制御コード（TCCフィールド）： 24ビット
トラフィックを分離する方法を提供し、加入者同士の制御された利益
共同体を定義する。TCCの値は3文字で、HQ DCA Code 530から入手で
きる。
このオプションは、フラグメンテーション時にコピーされなければなら
ない。また、1つのデータグラムに最大1回だけ現れる。
ルーズソース・レコードルート
+--------+--------+--------+---------//--------+
|10000011| 長さ |ポインタ| 経路データ |
+--------+--------+--------+---------//--------+
タイプ=131
ルーズソース・レコードルート（LSRR）オプションは、ゲートウェイが
宛先までデータグラムを転送するとき使用するルーティング情報を、イ
ンターネットデータグラムの送信元が与える方法、および経路情報を記
録する方法を提供する。
このオプションの最初はオプションタイプコードである。2番目のオク
テットはオプション長で、この長さにはオプションタイプコードおよび
長さオクテット、ポインタオクテット、長さ-3オクテット分の経路デー
タが含まれる。3番目のオクテットは経路データへのポインタで、次に
処理される送信元アドレスの開始オクテットを示す。ポインタはこのオ
プションに関する相対ポインタであり、ポインタの正しい最小値は4で
ある。
経路データはインターネットアドレスを並べたものである。それぞれの
インターネットアドレスは32ビットあるいは4オクテットである。ポイ
ンタが長さよりも大きい場合、ソースルートは空（かつ記録経路はフル）
であり、ルーティングは宛先アドレスフィールドに基づくことになる。
宛先アドレスフィールドのアドレスに到着し、かつポインタが長さより
大きくない場合、ソースルートにある次のアドレスが宛先アドレスフィ
[Page 18]
1981年9月
インターネットプロトコル
仕様
ールドのアドレスになり、またそのとき使用している送信元アドレスを
記録経路のアドレスに入れ、ポインタを4増加させる。
記録経路のアドレスは、このデータグラムを転送している環境における
インターネットモジュール自身のアドレスである。
データグラムがインターネットを通りぬける際、このソースルートと記
録経路の置き換え処理によって（記録経路の順序はソースルートとして
使用する際の順序とは逆になるが）オプション（およびIPヘッダ全体）
の長さは変化しない。
このオプションがルーズソースルーティングであるのは、他の中間ゲー
トウェイを使用しないと経路中の次のアドレスに到達できないようなゲ
ートウェイまたはホストのIPが許されるからである。
このオプションは、フラグメンテーション時にコピーされなければなら
ない。そして、1つのデータグラムに最大1回だけ現れる。
ストリクトソース・レコードルート
+--------+--------+--------+---------//--------+
|10001001| 長さ |ポインタ| 経路データ |
+--------+--------+--------+---------//--------+
タイプ=137
ストリクトソース・レコードルート（SSRR）オプションは、ゲートウェ
イが宛先までデータグラムを転送するとき使用するルーティング情報を、
インターネットデータグラムの送信元が与える方法、および経路情報を
記録する方法を提供する。
このオプションの最初はオプションタイプコードである。2番目のオク
テットはオプション長で、この長さにはオプションタイプコードおよび
長さオクテット、ポインタオクテット、長さ-3オクテット分の経路デー
タが含まれる。3番目のオクテットは経路データへのポインタで、次に
処理される送信元アドレスの開始オクテットを示す。ポインタはこのオ
プションに関する相対ポインタであり、ポインタの正しい最小値は4で
ある。
経路データはインターネットアドレスを並べたものである。それぞれの
インターネットアドレスは32ビットあるいは4オクテットである。ポイ
ンタが長さよりも大きい場合、ソースルートは空（かつ記録経路はフル）
であり、ルーティングは宛先アドレスフィールドに基づくことになる。
宛先アドレスフィールドのアドレスに到着し、かつポインタが長さより
大きくない場合、ソースルートにある次のアドレスが宛先アドレスフィ
ールドのアドレスになり、またそのとき使用している送信元アドレスを
記録経路のアドレスに入れ、ポインタを4増加させる。
[Page 19]
1981年9月
インターネットプロトコル
仕様
記録経路のアドレスは、このデータグラムを転送している環境における
インターネットモジュール自身のアドレスである。
データグラムがインターネットを通りぬける際、このソースルートと記
録経路の置き換え処理によって（記録経路の順序はソースルートとして
使用する際の順序とは逆になるが）オプション（およびIPヘッダ全体）
の長さは変化しない。
このオプションがストリクトソースルーティングであるのは、ゲートウ
ェイやホストのIPがソースルート中の次のアドレスにデータグラムを送
信する際、次のアドレスに示されている直接接続ネットワークだけを使
って、経路に指定されているゲートウェイやホストに到達しなければな
らないからである。
このオプションは、フラグメンテーション時にコピーされなければなら
ない。そして、1つのデータグラムに最大1回だけ現れる。
レコードルート
+--------+--------+--------+---------//--------+
|00000111| 長さ |ポインタ| 経路データ |
+--------+--------+--------+---------//--------+
タイプ=7
レコードルートオプションは、インターネットデータグラムの経路を記
録する方法を提供する。
このオプションの最初はオプションタイプコードである。2番目のオク
テットはオプション長で、この長さにはオプションタイプコードおよび
長さオクテット、ポインタオクテット、長さ-3オクテット分の経路デー
タが含まれる。3番目のオクテットは経路データへのポインタで、次に
処理される送信元アドレスの開始オクテットを示す。ポインタはこのオ
プションに関する相対ポインタであり、ポインタの正しい最小値は4で
ある。
経路データはインターネットアドレスを並べたものである。それぞれの
インターネットアドレスは32ビットあるいは4オクテットである。ポイ
ンタが長さよりも大きい場合、記録経路はフルであり。発信元のホスト
は、予想されるアドレス全てを保持するのに十分な大きさの経路データ
領域をこのオプションに与えなければならない。このオプションのサイ
ズはアドレスを追加しても変化しない。初期の経路データ領域の内容は
0にしなければならない。
インターネットモジュールがデータグラムをルーティングするとき、レ
コードルートオプションがあるかどうかを確認する。もしあるなら、こ
のデータグラムが転送されている環境でのモジュール自身のインターネ
ットアドレスを、ポインタが指しているオクテットからの記録経路に挿
入し、ポインタを4増加させる。
[Page 20]
1981年9月
インターネットプロトコル
仕様
経路データ領域がすでにフルである（ポインタが長さを越えている）場
合は、記録経路にアドレスを挿入せずにデータグラムを転送する。また、
空きがあっても完全なアドレスを挿入するには足りない場合は、元のデ
ータグラムはエラーであるとみなされて廃棄される。どちらの場合も、
ICMPパラメータ問題メッセージが送信元ホストに送信される場合がある
［3］。
このオプションは、フラグメンテーション時にコピーされない。1番目
のフラグメントで運ばれる。1つのデータグラムに最大1回だけ現れる。
ストリーム識別子
+--------+--------+--------+--------+
|10001000|00000010| ストリームID |
+--------+--------+--------+--------+
タイプ=136 長さ=4
このオプションは、ストリームの概念をサポートしないネットワークで
16ビットのSATNETストリーム識別子を運ぶ方法を提供する。
フラグメンテーション時にコピーされなければならない。1つのデータ
グラムに最大1回だけ現れる。
インターネットタイムスタンプ
+--------+--------+--------+--------+
|01000100| 長さ |ポインタ|oflw|flg|
+--------+--------+--------+--------+
| インターネットアドレス |
+--------+--------+--------+--------+
| タイムスタンプ |
+--------+--------+--------+--------+
| . |
.
.
タイプ=68
オプション長は、タイプ、長さ、ポインタ、オーバーフロー／フラグと
いったオクテット（最大長40）を入れたオプション内のオクテット数で
ある。
ポインタはこのオプションの先頭からタイムスタンプの末尾+1（すなわ
ち、次のタイムスタンプが使う空き領域の開始オクテットの位置）まで
のオクテット数である。正しい最小値は5である。ポインタが長さより
も大きいとき、タイムスタンプ領域はフルである。
オーバーフロー（oflw）［4ビット］は、空き領域の不足によってタイ
ムスタンプが登録できなかったIPモジュールの数の数である。
[Page 21]
1981年9月
インターネットプロトコル
仕様
フラグ（flg）［4ビット］の値は以下の通りである。
0 -- タイムスタンプのみ。連続する32ビットのワードで格納。
1 -- 各タイムスタンプの前に、登録したモジュールのインターネッ
トアドレスが付く。
3 -- インターネットアドレスフィールドは予め指定される。IPモジ
ュールの持つアドレスが次のフィールドに指定されたインター
ネットアドレスと一致するときだけ、そのIPモジュールはタイ
ムスタンプを登録する。
タイムスタンプは、正しく調整された32ビットのタイムスタンプで、UT
の午前0時から測ったミリ秒単位である。時間がミリ秒で得られない場
合や、UTの午前0時を基準に提供されない場合は、標準ではない値を使
用していることを示すために、タイムスタンプフィールドの上位ビット
に1をセットして、任意の時間を挿入してよい。
発信元のホストは、予想されるタイムスタンプ情報を全て保持するのに
十分な大きさのタイムスタンプデータ領域をこのオプションに付けなけ
ればならない。このオプションのサイズはタイムスタンプを追加しても
変化しない。初期のタイムスタンプデータ領域の内容は0、あるいはイ
ンターネットアドレス／0の組み合わせにしなければならない。
タイムスタンプデータ領域がすでにフルである（ポインタが長さを越え
ている）場合は、タイムスタンプを挿入せずにデータグラムを転送する
が、オーバーフローカウントを1増加させる。
空きがあっても完全なタイムスタンプを挿入するには足りない場合、あ
るいはオーバーフローカウント自身がオーバーフローしてしまった場合、
元のデータグラムはエラーであるとみなされて廃棄される。どちらの場
合も、ICMPパラメータ問題メッセージが送信元ホストに送信される場合
がある［3］。
タイムスタンプオプションはフラグメンテーション時にコピーされない。
1番目のフラグメントで運ばれる。1つのデータグラムに最大1回だけ現
れる。
パディング： 可変
インターネットヘッダのパディングは、インターネットヘッダが32ビット境
界で終わるようにするために使用される。パディングは0である。
3.2. 議論
プロトコルの実装は堅牢でなければならない。当然、それぞれの実装は他者が
作った他の実装と相互運用しなければならない。この仕様書の目標はプロトコ
ルについて明確にすることであるが、実装が異なる可能性はある。一般的に実
[Page 22]
1981年9月
インターネットプロトコル
仕様
装は、送信側の動作では堅実でなければならず、受信側の動作では寛容でなけ
ればならない。つまり、注意して適切な形のデータグラムを送信しなければな
らないが、解釈可能なデータグラムは全て受け入れなければならない（例えば、
技術的には誤りであっても意図が明らかであれば黙認する）。
基本的なインターネットサービスはデータグラム志向であり、ゲートウェイで
データグラムのフラグメンテーションが提供され、宛先ホストの宛先インター
ネットプロトコルモジュールでリアセンブリが行われる。もちろん、1つのネ
ットワーク内でのデータグラムのフラグメンテーションとリアセンブリ、ある
いは1つのネットワークにあるゲートウェイ同士でのプライベートな合意によ
るフラグメンテーションとリアセンブリも、インターネットプロトコルや上位
プロトコルに対して透過的であるため許される。この透過タイプのフラグメン
テーションとリアセンブリは、「ネットワーク依存」（あるいはイントラネッ
ト）フラグメンテーションと呼ばれ、ここではこれ以上議論しない。
インターネットアドレスは、ホストレベルで送信元と宛先を区別し、プロトコ
ルフィールドも同様に提供する。ホスト内で何らかの多重化を必要とすること
に対して、それぞれのプロトコルがそれに備えていると仮定している。
アドレッシング
アドレスの割当における柔軟性をネットワークに提供し、多数の小・中規模
ネットワークを可能ににするために、アドレスフィールドの実装は、多数の
ホストを持つ少数のネットワーク、中程度の数のホストを持つ中程度の数の
ネットワーク、少数のホストを持つ多数のネットワークを指定できるようコ
ード化されている。さらに、拡張アドレッシングモード用の拡張コードがあ
る。
アドレスフォーマット
上位ビット フォーマット クラス
---------- ---------------------------------- ------
0 ネット部 7ビット、ホスト部24ビット a
10 ネット部14ビット、ホスト部16ビット b
110 ネット部21ビット、ホスト部 8ビット c
111 拡張アドレッシングモード用の拡張部
ネットワークフィールドの値が0の場合、自分のネットワークを意味する。
これは特定のICMPメッセージでのみ使用される。拡張アドレッシングモー
ドは未定義である。これら両者の機能は、将来使用するために予約されて
いる。
ネットワークアドレス用に割り当てられた実際の値は『Assigned Numbers』
［9］で与えられている。
ローカルアドレスは、ローカルネットワークで割り当てられるが、1つの物
理的なホストが複数の区別可能なインターネットホストとしてふるまうこと
を見越しておかなければならない。すなわち、複数のインターネットアドレ
[Page 23]
1981年9月
インターネットプロトコル
仕様
スが1つのインタフェースに対応できるような、インターネットホストアド
レスとネットワーク／ホストインタフェースとの対応付けがなければならな
い。また、1つのホストが複数の物理的なインタフェースを持ち、その中の
いくつかのインターフェースから来たデータグラムを、それら全てが単一の
ホストに宛てられているように処理できなければならない。
インターネットアドレスとARPANETやSATNET、PRNETなどのネットワーク用の
アドレスアドレスとの対応付けは『Address Mappings』［5］で述べられて
いる。
フラグメンテーションとリアセンブリ
インターネット識別子フィールド（ID）は送信元・宛先アドレス、プロトコ
ルフィールドと合わせて、リアセンブリ時のデータグラムフラグメントの識
別に使用する。
フラグメント継続フラグビット（MF）は、データグラムが最後のフラグメン
トでない場合にセットされる。フラグメントオフセットフィールドは、元の
フラグメントされていないデータグラムの先頭からのフラグメントの相対位
置を特定する。フラグメントは8オクテット単位で考えられる。このフラグ
メンテーション方式は、フラグメントされていないデータグラムでは全て0
のフラグメンテーション情報（MF = 0、フラグメントオフセット = 0）とな
るように設計されている。インターネットデータグラムがフラグメントされ
ている場合、そのデータ部分は8オクテット境界で分割されなければならな
い。
このフォーマットは、合計65,536オクテット対して、それぞれ8オクテット
のフラグメントが2**13=8192個が許される。これはデータグラムの全パケッ
ト長フィールドと一致している（もちろん、このヘッダは全パケット長の中
に勘定されてるが、フラグメントでは勘定されない）。
フラグメンテーションが発生したとき、一部のオプションはコピーされるが、
それ以外は最初のフラグメントの中にだけ残る。
全てのインターネットモジュールは、68オクテットのデータグラムをそれ以
上フラグメンテーションしないで転送できなければならない。これは、イン
ターネットヘッダが最大60オクテットまで可能で、 最小のフラグメントが
8オクテットだからである。
全てのインターネットの宛先ポイントは、576オクテットのデータグラムを
一塊で、あるいはフラグメントをリアセンブルして受信できなければならな
い。
[Page 24]
1981年9月
インターネットプロトコル
仕様
フラグメンテーションによって影響するフィールドは以下を含む。
(1) オプションフィールド
(2) フラグメント継続フラグ
(3) フラグメントオフセット
(4) インターネットヘッダ長フィールド
(5) 全パケット長フィールド
(6) ヘッダチェックサム
フラグメント禁止（DF）ビットがセットされた場合、廃棄されても構わない
が、このデータグラムのインターネットフラグメンテーションを“してはい
けない”。これを使用して、受信側ホストがインターネットフラグメントを
リアセンブルするだけの十分なリソースを備えていない場合に、フラグメン
テーションを禁止できる。
フラグメント禁止機能の使用例として、小さなホストの回線負荷の軽減があ
る。小さなホストは、データグラムを受信するブートストラッププログラム
をメモリに格納してから実行することができる。
フラグメンテーションとリアセンブリのプロシージャは、例を使って非常に
容易に説明される。以下のプロシージャは実行例である。
以下の擬似プログラムにおける一般的な表記法は以下のとおりである。"=<"
は「〜より小さいか、〜と等しい」を意味し、"#" は「〜と等しくない」を
意味し、"=" は「〜と等しい」を意味し、"<-" は「〜にセットされる」を
意味する。また、"x to y" は、xを含むがyは含まない。例えば、"4 to 7"
ならば4、5、6を含む（しかし、7は含まない）。
フラグメンテーションプロシージャの例
次のネットワークで転送可能なデータグラムの最大サイズは、最大転送単
位（MTU）と呼ばれる。
全パケット長が最大転送単位以下である場合、このデータグラムは次のス
テップのデータグラム処理に渡される。そうではない場合は、データは2
つのフラグメントに分けられ、最初のフラグメントが最大サイズになり、
2番目のフラグメントが残りのデータグラムになる。最初のフラグメント
は次のステップのデータグラム処理に渡されるが、2番目のフラグメント
は、まだ大きすぎる場合はこのプロシージャに渡される。
表記：
FO - フラグメントオフセット
IHL - インターネットヘッダ長
DF - フラグメント禁止フラグ
MF - フラグメント継続フラグ
TL - 全パケット長
OFO - 旧フラグメントオフセット
[Page 25]
1981年9月
インターネットプロトコル
仕様
OIHL - 旧インターネットヘッダ長
OMF - 旧フラグメント継続フラグ
OTL - 旧全パケット長
NFB - フラグメントブロック数
MTU - 最大転送単位
プロシージャ：
IF TL =< MTU
THEN このデータグラムを次のステップのデータ処理に渡す
ELSE IF DF = 1
THEN データグラム廃棄
ELSE
最初のフラグメントを作る：
(1) 元のインターネットヘッダをコピー;
(2) OIHL <- IHL; OTL <- TL; OFO <- FO; OMF <- MF;
(3) NFB <- (MTU-IHL*4)/8;
(4) 最初のNFB*8データオクテットを添付;
(5) ヘッダ修正：
MF <- 1; TL <- (IHL*4)+(NFB*8);
チェックサム再計算;
(6) このフラグメントを次のステップのデータグラム処理に渡す;
2番目のフラグメントを作る：
(7) インターネットヘッダを取捨選択してコピー（一部のオプション
はコピーされない。オプションの定義を参照せよ）;
(8) 残りのデータを付加;
(9) ヘッダ修正：
IHL <- (((OIHL*4)-(コピーされないオプション長))+3)/4;
TL <- OTL - NFB*8 - (OIHL-IHL)*4);
FO <- OFO + NFB; MF <- OMF; チェックサム再計算;
(10) このフラグメントをフラグメンテーションテストに渡す; DONE.
上記プロシージャでは、各フラグメント（最後のを除く）は許される最大
サイズにされる。別のプロシージャでは、最大サイズのデータグラムより
も小さく作られることもある。例えば、大きなデータグラムを半分に分割
することを、できたフラグメントが最大転送単位のサイズより小さくなる
まで繰り返すようなフラグメンテーションプロシージャを実行することも
可能である。
リアセンブリプロシージャの例
各データグラムに対して、バッファ識別子を送信元フィールド、宛先フィ
ールド、プロトコルフィールド、識別子フィールドの組み合わせとして計
算する。このデータグラムが完全なデータグラム（すなわちフラグメント
オフセットフィールドとフラグメント継続フィールドがともに0）である
場合、このバッファ識別子に関するリアセンブリリソースは解放され、デ
ータグラムは次のステップのデータ処理に進められる。
[Page 26]
1981年9月
インターネットプロトコル
仕様
このバッファ識別子を持つフラグメントが他に待機していないなら、リア
センブリリソースが割り当てられる。リアセンブリリソースは、データバ
ッファ、ヘッダバッファ、フラグメントブロックビットテーブル、全デー
タ長フィールド、タイマーで構成される。フラグメントからのデータは、
そのフラグメントオフセットと長さに対応するデータバッファに格納され、
受信したフラグメントブロックに対応するフラグメントブロックビットテ
ーブルにビットがセットされる。
これが最初のフラグメントである（すなわちフラグメントオフセットが0
である）場合、このフラグメントのヘッダはヘッダバッファに格納される。
これが最後のフラグメントである（すなわちフラグメント継続フィールド
が0である）場合、全データ長が計算される。このフラグメントによって
データグラムが完全になった場合（フラグメントブロックテーブルのビッ
トがセットされていることを確認して判断する）、データグラムは次のス
テップのデータグラム処理に送られる。まだ完全でなければ、現在のタイ
マーの値とこのフラグメントからの生存時間フィールドの値の大きい方を
タイマーにセットする。そしてリアセンブリルーチンは制御を譲る。
タイマーが切れた場合、このバッファ識別子に対する全てのリアセンブリ
リソースが解放される。タイマーの初期設定値はリアセンブリの待ち時間
の下限である。これは、到着フラグメントの生存時間が現在のタイマー値
よりも大きいときには待ち時間を増加させるが、小さいときには減少させ
ないからである。このタイマー値が達することができる最大は、生存時間
の最大（約4.25分）である。タイマーの初期設定値の現時点の推奨値は15
秒である。この値は、このプロトコルが実績を積むにつれて変わっていく
こともあるだろう。このパラメータ値の選択は、利用可能なバッファ容量
と転送媒体のデータ転送速度と関係がある。すなわち、データ転送速度に
時間をかけた値がバッファサイズになる（例：10Kb/s X 15s = 150Kb）。
表記：
FO - フラグメントオフセット
IHL - インターネットヘッダ長
MF - フラグメント継続フラグ
TTL - 生存時間
NFB - フラグメントブロック数
TL - 全パケット長
TDL - 全データ長
BUFID - バッファ識別子
RCVBT - 受信済フラグメントビットテーブル
TLB - タイマー下限値
プロシージャ：
(1) BUFID <- 送信元|宛先|プロトコル|識別子;
(2) IF FO = 0 AND MF = 0
(3) THEN IF BUFIDのバッファが割当済
(4) THEN このBUFIDの全てのリアセンブリをフラッシュ;
[Page 27]
1981年9月
インターネットプロトコル
仕様
(5) データグラムを次のステップに渡す; DONE.
(6) ELSE IF BUFIDのバッファが未割当
(7) THEN BUFIDのリアセンブリリソースを割り当てる;
TIMER <- TLB; TDL <- 0;
(8) フラグメントからBUFIDのデータバッファに
オクテットFO*8〜(TL-(IHL*4))+FO*8のデータを格納;
(9) RCVBTのFO〜FO+((TL-(IHL*4)+7)/8)のビットをセット;
(10) IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
(11) IF FO = 0 THEN ヘッダをヘッダバッファに格納
(12) IF TDL # 0
(13) AND RCVBTの0〜(TDL+7)/8の全ビットがセット済
(14) THEN TL <- TDL+(IHL*4)
(15) データグラムを次のステップに渡す;
(16) このBUFIDの全リアセンブリリソースを
解放; DONE.
(17) TIMER <- MAX(TIMER,TTL);
(18) 次のフラグメントまたはタイマー切れまで制御を手放す;
(19) タイマー切れ: このBUFIDの全リアセンブリをフラッシュ; DONE.
複数のフラグメントが完全に一致する、あるいは部分的に重なるような同
一データを持っている場合、このプロシージャがデータバッファと伝達さ
れるデータグラムに使用するのは、後に到着したコピーの方である。
識別
データグラムの識別子は、個々のデータグラムのフラグメントを一意に特定
できるようにすべきという要求に基づいて選ばれている。フラグメントをア
センブルするプロトコルモジュールは、送信元、宛先、プロトコル、識別子
が同じであれば、フラグメントが同一データグラムに属すると判断する。し
たがって、データグラム（またはそのフラグメント）がインターネットに存
在できる間、この送信元・宛先の組合せとプロトコルに対して一意になるよ
うな識別子を送信側は選ぶ必要がある。
すると、送信側プロトコルモジュールは識別子のテーブルを保持している必
要があり、インターネットに対する最大パケット有効期間の最新の値の間に
通信を行った宛先それぞれに対して1つのエントリーとなるようにしなけれ
ばならないように思えてくる。
しかし、識別子フィールドには65,536個の異なる値が許されるので、ホスト
は単純に宛先とは独立した一意の識別子を使用することも可能である。
上位プロトコルが識別子を選んだ方が適切なものもある。例えば、TCPプロ
トコルモジュールは同一のTCPセグメントを再送することができ、元の転送
と同じ識別が再送でも使われるのなら、元の転送と再送のどちらかのデータ
グラムのフラグメントを使えれば正しいTCPセグメントが構成できるため、
正しく受信される可能性が高くなるだろう。
[Page 28]
1981年9月
インターネットプロトコル
仕様
サービスタイプ
サービスタイプ（TOS）はインターネットサービス品質選択のためのもので
ある。このサービスタイプは、抽象的パラメータである優先度、遅延、スル
ープット、信頼性で指定される。これら抽象的パラメータは、データグラム
が通る個々のネットワークの実際のサービスパラメータに対応付けられるも
のである。
優先度。データグラムの重要性の独自基準である。
遅延。この指示があるデータグラムは、即時配送を重要視する。
スループット。この指示があるデータグラムは、データ転送速度が高いこと
を重要視する。
信頼性。この指示があるデータグラムは、配送を保証しようとする努力レベ
ルが高いことを重要視する。
例えば、ARPANETにはプライオリティビットがあり 、「標準」 メッセージ
（タイプ0） と「制御外」 メッセージ（タイプ3）の選択がある。 （単独
パケットメッセージとマルチパケットメッセージの選択もサービスパラメー
タとみなすことができる）。 制御外メッセージは、配送の信頼性が低く、
許容される遅延が小さいという傾向がある。インターネットデータグラムが
ARPANETを通して送信されるとする。インターネットサービスタイプを次に
ようにしよう。
優先度： 5
遅延： 0
スループット： 1
信頼性： 1
この例において、このパラメータとARPANETで利用可能なものとの対応付け
は、インターネット優先度がその範囲の上半分にあることからARPANETプラ
イオリティビットがオンにセットされ、また、スループットと信頼性要求が
指定されており、かつ遅延は指定されていないので標準メッセージが選ばれ
るだろう。詳細は『Service Mappings』［8］のサービス対応表にある。
生存時間
生存時間は送信側によって設定され、データグラムがインターネットシステ
ムに存在できる最大時間となる。データグラムがインターネットシステムに
存在する時間が生存時間よりも長くなったときは、データグラムを破棄しな
ければならない。
インターネットヘッダを処理する各ポイントで、データグラムの処理にかか
った時間が反映するようにこのフィールドを減らす必要がある。実際にかか
った時間についてローカルの情報が得られないときでも、このフィールドを
1減らさなければならない。この時間は秒単位となっている（すなわち、1と
[Page 29]
1981年9月
インターネットプロトコル
仕様
いう値は1秒を意味する）。したがって、最大生存時間じゃ255秒または4.25
分である。データグラムを処理する全てのモジュールは、たとえデータグラ
ムの処理が1秒以下であってもTTLを少なくとも1減らさなければならないた
め、TTLはデータグラムが存在できる時間の上限でしかないと考えるべきで
ある。TTLの目的は、配送不可能なデータグラムが廃棄されるようにするこ
とと、データグラムの生存時間の最大を定めることである。
上位の信頼性のある接続プロトコルには、同一のデータグラムの古い方は一
定時間が経過したら到達しないという仮定に基づいているものもある。TTL
によって、このようなプロトコルの仮定が確実に満たされるようになる。
オプション
オプションは、それぞれのデータグラムではオプションであるが、実装面で
は必須である。すなわち、オプションを使うか使わないかは送信側の自由で
あるが、それぞれのインターネットモジュールは全てのオプションを解析で
きなければならない。オプションフィールドに複数のオプションがあっても
構わない。
オプションは32ビット境界で終了しなくても良い。インターネットヘッダは
0のオクテットで引き伸ばしてやる必要がある。0のオクテットの最初は、オ
プション終了というオプションと解釈され、以降はインターネットヘッダの
パディングと解釈される。
全てのインターネットモジュールは、全てのオプションに従った動作が可能
でなければならない。セキュリティオプションは、分類、制限、コンパート
メント分けされているトラフィックを通過させるならば必須である。
チェックサム
インターネットヘッダチェックサムは、インターネットヘッダが変更された
ら再計算される。インターネットヘッダの変更は、例えば、制限時間の減少、
インターネットオプションの追加や変更、フラグメンテーションによるもの
などである。インターネットレベルにおけるこのチェックサムの目的は、イ
ンターネットヘッダフィールドを転送エラーから守ることである。
アプリケーションによっては、少々のデータビットエラーは許容されるが、
再送遅延は許容されないものもある。インターネットプロトコルがデータ訂
正を強制したとすると、そのようなアプリケーションがサポートできなくな
ってしまう。
エラー
インターネットプロトコルのエラーはICMPメッセージ［3］で報告すること
ができる。
[Page 30]
1981年9月
インターネットプロトコル
仕様
3.3. インタフェース
IPとのユーザインタフェースの機能説明は、どのオペレーティングシステムも
設備構成は千差万別のため、所詮は虚構の話となってしまう。したがって、IP
の実装が異なれば、異なるユーザインタフェースを持つ可能性があるのだと、
我々は読者に警告しなければならない。しかし、IP実装が同一のプロトコル階
層をサポートできるようにするため、全てのIPは一定の最小サービス群を提供
しなければならない。この節では、全てのIP実装に求められる機能インタフェ
ースを規定する。
インターネットプロトコルは、ローカルネットワーク側と、上位プロトコルま
たはアプリケーションプログラム側にインタフェースを持つ。以下では、上位
プロトコルやアプリケーションプログラムは（さらにゲートウェイプログラム
も）、インターネットモジュールを使用していることから「ユーザ」と呼ぶこ
ととする。インターネットプロトコルはデータグラムプロトコルであるので、
データグラムの転送と転送の間で保たれるメモリや状態は最小限であり、ユー
ザからのインターネットプロトコルモジュールの各呼び出しによって、要求さ
れたサービスを実行するためにIPが必要とする全ての情報が供給される。
上位インタフェースの例
以下の2つの呼び出し例は、インターネットプロトコルモジュール通信に対す
るユーザの必要条件を満たしている（"=>" は戻り値を意味する）。
SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)
ここで、
src = 送信元アドレス
dst = 宛先アドレス
prot = プロトコル
TOS = サービスタイプ
TTL = 生存時間
BufPTR = バッファポインタ
len = バッファ長
Id = 識別子
DF = フラグメント禁止
opt = オプションデータ
result = 応答
OK = データグラム送信正常
Error = 引数のエラーか、ローカルネットワークエラー
優先度はTOSに含まれ、セキュリティ／コンパートメントはオプションとし
て渡すことに注意する。
[Page 31]
1981年9月
インターネットプロトコル
仕様
RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)
ここで、
BufPTR = バッファポインタ
prot = プロトコル
result = 応答
OK = データグラム受信正常
Error = 引数のエラー
len = バッファ長
src = 送信元アドレス
dst = 宛先アドレス
TOS = サービスタイプ
opt = オプションデータ
ユーザがデータグラムを送信するとき、全ての引数を与えてSEND呼び出しを実
行する。インターネットプロトコルモジュールはこの呼び出しを受けて、引数
の確認、準備、メッセージの送信を行う。引数が正しく、データグラムがロー
カルネットワークに受け取ってもらえれば、呼び出しは成功したと返す。引数
のどれかが正しくないか、あるいはデータグラムがローカルネットワークに受
け取ってもらえなかった場合、呼び出しは不成功だと返す。不成功で返る場合、
この問題の原因に関して適当な通知が行われるが、この通知についての細かい
部分は個々の実装次第である。
データグラムがローカルネットワークからインターネットプロトコルモジュー
ルへ到着したときに、宛先ユーザからの保留中のRECV呼び出しがある場合と、
呼び出しが無い場合がある。前者の場合は、データグラムからユーザへ情報を
渡すことによって保留中の呼び出しが完了する。後者の場合は、宛先となって
いるユーザは保留データグラムの通知を受ける。宛先のユーザが存在しない場
合は、ICMPエラーメッセージが送信側に返され、データは廃棄される。
ユーザの通知は、実装されているそれぞれのオペレーティングシステム環境に
適した形の擬似的な割り込みや同様のメカニズムで行うことができる。
このとき、ユーザのRECV呼び出しが保留データグラムによってただちに完了す
る場合と、データグラムが到着するまで呼び出しが保留になる場合がある。
送信側ホストが複数のアドレス（複数の物理的な接続や論理アドレス）を持っ
ている場合に備えて、送信元アドレスはSEND呼び出しに含まれている。インタ
ーネットモジュールは、送信元アドレスがこのホストの正規のアドレスの1つ
であることを確認しなければならない。
実装では、データグラムのクラス（例えば、プロトコルフィールドに特定の値
を持つ全てのデータグラム）に注目していることを示すために、あるいはデー
タグラムのクラスの専用を予約するために、インターネットモジュールへの呼
び出しを許可する、あるいは必須にすることもできる。
この節では、ユーザ\jslash IPインタフェースを機能面で規定した。使用した
[Page 32]
1981年9月
インターネットプロトコル
仕様
表記法は、高級言語で最もよく使われる関数呼び出しのプロシージャと似た形
にしたが、この使用方法は、トラップタイプのサービス呼び出し （例えば、
SVCやUUO、EMTなど）や、それ以外の形のプロセス間通信を認めないと言って
いるわけではない。
[Page 33]
1981年9月
インターネットプロトコル
付録A： 具体例とシナリオ
例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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |サービスタイプ | 全パケット長 = 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 = 111 |Flg=0|フラグメントオフセット= 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 生存時間= 123 | プロトコル= 1 | ヘッダチェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 送信元アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 宛先アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+
インターネットデータグラムの例
図5
注：目盛りはそれぞれ1ビットの位置を示している。
これはインターネットプロトコルのバージョン4のインターネットデータグラ
ムである。インターネットヘッダは5つの32ビットワードで構成され、データ
グラムの全パケット長は21オクテットである。このデータグラムは完全なデー
タグラムである（フラグメントではない）。
[Page 34]
1981年9月
インターネットプロトコル
例2
この例では、最初に中くらいのサイズのインターネットデータグラム（452デ
ータオクテット）を示し、その後で転送が許容される最大サイズが280オクテ
ットの場合にこのデータグラムをフラグメンテーションして得られる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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |サービスタイプ | 全パケット長 = 472 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 = 111 |Flg=0|フラグメントオフセット= 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 生存時間= 123 | プロトコル= 6 | ヘッダチェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 送信元アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 宛先アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
〜 〜
〜 〜
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
インターネットデータグラムの例
図6
[Page 35]
1981年9月
インターネットプロトコル
まず、256データオクテットごとにデータグラムを分割してできた最初のフラ
グメント。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |サービスタイプ | 全パケット長 = 276 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 = 111 |Flg=1|フラグメントオフセット= 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 生存時間= 119 | プロトコル= 6 | ヘッダチェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 送信元アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 宛先アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
〜 〜
〜 〜
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
インターネットフラグメントの例
図7
[Page 36]
1981年9月
インターネットプロトコル
そして、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |サービスタイプ | 全パケット長 = 216 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 = 111 |Flg=0|フラグメントオフセット=32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 生存時間= 119 | プロトコル= 6 | ヘッダチェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 送信元アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 宛先アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
〜 〜
〜 〜
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
インターネットフラグメントの例
図8
[Page 37]
1981年9月
インターネットプロトコル
例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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 8 |サービスタイプ | 全パケット長 = 576 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 = 111 |Flg=0|フラグメントオフセット= 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 生存時間= 123 | プロトコル= 6 | ヘッダチェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 送信元アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 宛先アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. コード=x | Opt. 長さ = 3 | オプション値 | Opt. コード=x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. 長さ = 4 | オプション値 | Opt. コード=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. コード=y | Opt. 長さ = 3 | オプション値 | Opt. コード=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
〜 〜
〜 〜
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
インターネットデータグラムの例
図9[Page 38]
1981年9月
インターネットプロトコル
付録B： データ転送順序
このドキュメントで述べられているヘッダとデータの転送順序は、オクテットレ
ベルに分解される。図でオクテットのグループを示すとき、これらのオクテット
の転送順序は英語で読むときの通常の順序である。例えば以下の図では、オクテ
ットは番号順に転送される。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
バイト転送順序
図10
オクテットが数量を表現するときは、図で左の一番左のビットが上位ビットある
いは最も大きな桁のビットとなる。すなわち、0とラベル付けされたビットが最
も大きな桁のビットである。例えば、以下の図は170（10進数）という値を表現
している。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
ビットの意味
図11
同様に、マルチオクテットのフィールドが数量を表現するときは、フィールド全
体で左の一番左のビットが、最も大きな桁のビットとなる。マルチオクテットの
数量が転送されるとき、最も桁の大きいオクテットが最初に転送される。
[Page 39]
1981年9月
インターネットプロトコル
[Page 40]
1981年9月
インターネットプロトコル
用 語
1822
BBN Report 1822、『The Specification of the Interconnection of
a Host and an IMP』。ホストとARPANETとの間のインターフェースの
仕様書。
ARPANETリーダ
ホスト・IMPインターフェースにおけるARPANETメッセージ上の制御情
報。
ARPANETメッセージ
ARPANETにおいてホストとIMPの間での転送単位。最大サイズは約1012
オクテット（8096ビット）である。
ARPANETパケット
IMP間のARPANETで内部的に使用される転送単位。最大サイズは約126
オクテット（1008ビット）である。
宛先
宛先アドレス。インターネットヘッダフィールド。
DF
フラグフィールドで運ばれるフラグメント禁止ビット。
フラグ
各種制御フラグを運ぶインターネットヘッダフィールド。
フラグメントオフセット
フラグメントがインターネットデータグラム中のどこに位置するかを
示すインターネットヘッダフィールド。
GGP
ゲートウェイ間プロトコル。このプロトコルは主にゲートウェイ間の
ルーティングや他のゲートウェイ機能を制御するのに使用する。
ヘッダ
メッセージやセグメント、データグラム、パケット、データのブロッ
クなどの先頭にある制御情報。
ICMP
インターネット制御メッセージプロトコル。ICMPは、インターネット
モジュールに実装され、ゲートウェイからホストおよびホスト間でエ
ラーの報告とルーティングの指示を与えるために使用される。
[Page 41]
1981年9月
インターネットプロトコル
用語
識別子
識別用の値を運ぶインターネットヘッダフィールド。この値は送信側
によって割り当てられ、データグラムのフラグメントをアセンブルす
る助けとなる。
IHL
インターネットヘッダ長というインターネットヘッダフィールドは、
32ビットワード単位でのインターネットヘッダの長さである。
IMP
インターフェースメッセージプロセッサ。ARPANETのパケットスイッ
チ。
インターネットアドレス
4オクテット（32ビット）の送信元または宛先アドレスで、ネットワ
ークフィールドとローカルアドレスフィールドで構成されている。
インターネットデータグラム
インターネットモジュール同士の間で交換されるデータの単位（イン
ターネットヘッダを含む）。
インターネットフラグメント
インターネットデータグラムのデータの一部にインターネットヘッダ
を付けたもの。
ローカルアドレス
ネットワーク内のホストのアドレス。インターネットローカルアドレ
スからネットワーク内のホストアドレスへの実際の対応付けは非常に
一般的なもので、多数のアドレスに対して1アドレスという対応付け
も可能である。
MF
インターネットヘッダのフラグフィールドで運ばれるフラグメント継
続フラグ。
モジュール
通常はソフトウェアである、プロトコルまたはその他のプロシージャ
の実装。
フラグメント継続フラグ
そのインターネットデータグラムがインターネットデータグラムの最
後の部分を含んでいるかどうかを示すフラグ。インターネットヘッダ
のフラグフィールドで運ばれる。
NFB
インターネットフラグメントのデータ部に格納されているフラグメン
トブロック数。すなわち、データの部分の長さを8オクテット単位で
数えたものである。
[Page 42]
1981年9月
インターネットプロトコル
用語
オクテット
8ビットバイト。
オプション
インターネットヘッダのオプションフィールドは、いくつかのオプシ
ョンを含み、各オプションの長さは数オクテットとなることもある。
パディング
インターネットヘッダのパディングフィールドは、データが32ビット
ワード境界で始まることを保証するために使用する。
プロトコル
このドキュメントでは、1つ上位のプロトコルの識別子となる、イン
ターネットヘッダフィールド。
レスト
インターネットアドレスのローカルアドレス部分。
送信元
送信元アドレス、インターネットヘッダフィールド。
TCP
転送制御プロトコル。インターネット環境において信頼性のある通信
を行うためのホスト間プロトコル。
TCPセグメント
TCPモジュール間で交換されるデータの単位（TCPヘッダを含む）。
TFTP
トリビアルファイル転送プロトコル。UDPに基づいた簡易ファイル転
送プロトコル。
生存時間
そのインターネットデータグラムが存在できる時間の上限を示すイン
ターネットヘッダフィールド。
TOS
サービスタイプ。
全パケット長
インターネットヘッダフィールドである全パケット長は、オクテット
で表したインターネットヘッダとデータを含むデータグラムの長さ。
TTL
生存時間。
[Page 43]
1981年9月
インターネットプロトコル
用語
サービスタイプ
そのインターネットデータグラムに対するサービスのタイプ（あるい
は品質）を示すインターネットヘッダフィールド。
UDP
ユーザデータグラムプロトコル。トランザクション指向のアプリケー
ションのためのユーザレベルのプロトコル。
ユーザ
インターネットプロトコルの使用者。これは上位プロトコルモジュー
ルかアプリケーションプログラム、あるいはゲートウェイプログラム
がなり得る。
バージョン
バージョンフィールドはインターネットヘッダのフォーマットを示す。
[Page 44]
1981年9月
インターネットプロトコル
参考文献
[1] Cerf, V., "The Catenet Model for Internetworking," Information
Processing Techniques Office, Defense Advanced Research Projects
Agency, IEN 48, July 1978.
[2] Bolt Beranek and Newman, "Specification for the Interconnection of
a Host and an IMP," BBN Technical Report 1822, Revised May 1978.
[3] Postel, J., "Internet Control Message Protocol - DARPA Internet
Program Protocol Specification," RFC 792, USC/Information Sciences
Institute, September 1981.
[4] Shoch, J., "Inter-Network Naming, Addressing, and Routing,"
COMPCON, IEEE Computer Society, Fall 1978.
[5] Postel, J., "Address Mappings," RFC 796, USC/Information Sciences
Institute, September 1981.
[6] Shoch, J., "Packet Fragmentation in Inter-Network Protocols,"
Computer Networks, v. 3, n. 1, February 1979.
[7] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and
Newman, August 1979.
[8] Postel, J., "Service Mappings," RFC 795, USC/Information Sciences
Institute, September 1981.
[9] Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences
Institute, September 1981.
[Page 45]
一覧
スポンサーリンク
