RFC: 791 INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION September 1981 prepared for Defense Advanced Research Projects Agency Information Processing Techniques Office 1400 Wilson Boulevard Arlington, Virginia 22209 by Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, California 90291 目次 序章 1. 導入 1.1 動機 1.2 概要 1.3 インタフェース 1.4 オペレーション 2. 原理 2.1 他のプロトコルとの関係 2.2 オペレーションのモデル 2.3 機能規定 2.4 ゲートウェイ 3. 規約 3.1 インターネットヘッダ形式 3.2 議論 3.3 インタフェース APPENDIX A: 例とシナリオ APPENDIX B: データ転送順番 用語 参照 序文 このドキュメントは、DoD 標準インターネットプロトコルを規定している。こ のドキュメントは、前の 6 つの ARPA インターネットプロトコル規定に基づ いており、現在のテキストはこれらからかなり取り込まれている。概念やテキ ストの両方に関するこの作業に、多くの貢献者が存在した。この版は、アドレ スやエラーの扱い、オプションコードやセキュリティ、優先度、コンパートメ ント、インターネットプロトコルの制限事項の取り扱い、といった面について 改訂している。 Jon Postel Editor 1. 導入 1.1. 動機 インターネットプロトコルは、パケット交換コンピュータ通信ネットワーク 上で相互接続されたシステムで使用する為に設計されている。そのようなな システムは、"catenet" [1] と呼ばれている。インターネットプロトコルは、 データグラムと呼ばれるデータのブロックの、送信元から宛先への送信を提 供する。そこでは、送信元と宛先は固定長アドレスで識別されるホストであ る。インターネットプロトコルは、"小さいパケット (small packet)" ネッ トワークを通じて送信する際、もし必要ならば長いデータグラムの分割や組 立も提供する。 1.2. 適用範囲 インターネットプロトコルは、ネットワークの相互接続されたシステム上で、 ビットのパッケージ (インターネットデータグラム) を送信元から宛先へ配 送するのに必要な機能を提供する範囲に明確に限定している。エンドツーエ ンドのデータ信頼性やフロー制御、順序付け、ホストツーホストプロトコル に通常見られる他のサービスを増やすメカニズムは存在しない。インターネ ットプロトコルは、様々なタイプやサービス品質を提供するために、サポー トするネットワークのサービス上で利用できる。 1.3. インタフェース このプロトコルは、インターネット環境においてホストツーホストプロトコ ルによって呼び出される。このプロトコルは、インターネットデータグラム を次のゲートウェイか宛先ホストに運ぶ為に、自側ネットワークプロトコル を呼ぶ。 例えば、TCP モジュールはインターネットデータグラムのデータ部のTCP セ グメント (TCP ヘッダと利用者データを含む) を取る為に、インターネット モジュールを呼ぶだろう。TCP モジュールは、アドレスとインターネットヘ ッダ中の他のパラメタを、呼び出し時のアーギュメントとしてインターネッ トモジュールに提供するだろう。そして、インターネットモジュールはイン ターネットデータグラムを生成し、インターネットデータグラムを送信する 為に自側ネットワークインターフェースを呼ぶだろう。 ARPANET の場合、例えばインターネットモジュールは、IMP に転送する為の ARPANET メッセージを生成するインターネットデータグラムに、1822 リー ダー [2] を追加する為に自側ネットモジュールを呼ぶ。ARPANET アドレス は、自側ネットワークインタフェースによってインターネットアドレスから 抜き出され、ARPANET 内のあるホストのアドレスになるだろう。 1.4. オペレーション インターネットプロトコルは、2 つの基本機能を実装する。それは、アドレ ス付け (addressing) と分割 (fragmentation) である。 インターネットモジュールは、インターネットデータグラムを宛先に転送す るために、インターネットヘッダで運ばれたアドレスを使用する。転送時の パス選択は、ルーティングと呼ばれる。 インターネットモジュールは、"小さなパケット" ネットワークを通して転 送する際、必要ならばインターネットデータグラムを分割したりや組立する ために、インターネットヘッダ中のフィールドを使用する 処理のモデルでは、インターネットモジュールは、インターネット通信に携 わる各々のホストや、ネットワークを相互接続する各々のゲートウェイに存 在する。これらのモジュールは、アドレスフィールドやインターネットデー タグラムの分割/組み立てを解釈する為に共通の規則を共有する。加えて、 これらのモジュール (特にゲートウェイ) は、ルーティグを決定するための 手続きやその他の機能を持つ。 インターネットプロトコルは、各々のインターネットデータグラムを、他の いかなるインターネットデータグラムとも関連性を持たない独立したエンティ ティとして扱う。コネクション、あるいは論理回線、仮想回線等は存在しな い。 インターネットプロトコルは、そのサービスを提供する際、4 つのキーメカ ニズムを使用する。それは、サービスタイプ、生存時間、オプション、ヘッ ダチェックサムである。 サービスタイプは、望ましいサービスの品質を示すために使用される。サー ビスタイプは、インターネットを形成しているネットワークに提供されるサ ービスの選択を表す、抽象的で一般的なパラメタのセットである。このサー ビスタイプ指定は、ゲートウェイがインターネットデータグラムをルーティ ングする際に、ある特定のネットワークや次のホップ、次のゲートウェイに 対して使用されるネットワークのための、実際の転送パラメタを選択するの に使用されるものである。 生存時間はインターネットデータグラムの生存期間の上限の指定である。そ れはデータグラムの送信者によって設定される、それが処理される経路上の ポイントで減らされる。もしインターネットデータグラムがその宛先に到達 する前に生存時間が 0 になったら、インターネットデータグラムは破棄さ れる。生存時間は、自己破壊制限時間と考えられる。 オプションはある状況では必要で有用だが、大半の一般的な通信では不要で ある制御機能を提供する。オプションは、タイムスタンプや安全性、特殊な ルーティングの提供を含む。 ヘッダチェックサムは、インターネットデータグラムを処理する際に使用さ れる情報が正しく転送されたことを証明する方法を提供する。データは異常 を含むかもしれない。もしヘッダチェックサムが異常ならば、インターネッ トデータグラムは異常を検出したエンティティによって即座に破棄される。 インターネットプロトコルは、信頼できる通信ファシリティを提供しない。 エンドツーエンドかホップツーホップの肯定応答は存在しない。ヘッダチェ ックサムを除いて、データに対する異常制御は存在しない。再送も存在しな い。フロー制御も存在しない。 検出された異常は、インターネット制御メッセージプロトコル (ICMP: Internet Control Message Protocol)[3] を経由して通知されるかもしれな い。ICMP はインターネットプロトコルモジュールに実装される。 2. 原理 2.1. 他のプロトコルとの関係 以下の図は、プロトコル階層の中のインターネットプロトコルの場所を表し ている。 +------+ +-----+ +-----+ +-----+ |Telnet| | FTP | | TFTP| ... | ... | +------+ +-----+ +-----+ +-----+ | | | | +-----+ +-----+ +-----+ | TCP | | UDP | ... | ... | +-----+ +-----+ +-----+ | | | +--------------------------+----+ | Internet Protocol & ICMP | +--------------------------+----+ | +---------------------------+ | Local Network Protocol | +---------------------------+ Protocol Relationships Figure 1. インターネットプロトコルは、一方で上位レベルホストツーホストプロトコ ルに、もう一方でローカルネットワークプロトコルにインタフェースする。 このコンテキストでは、"ローカルネットワーク" とはビル内の小規模ネッ トワーク、あるいは ARPANET のような大規模なネットワークのことを言う。 2.2. オペレーションのモデル データグラムを一方のアプリケーションプログラムから、もう一方のアプリ ケーションプログラムに送信する処理モデルを、以下のシナリオによって説 明する。 ある中間ゲートウェイを経由する送信を想定する。 送信側アプリケーションプログラムはデータを準備し、そのデータをデー タグラムとして送信するために自側のインターネットモジュールを呼び、 宛先アドレスと他のパラメタを呼び出し時のアーギュメントとして渡す。 インターネットモジュールはデータグラムヘッダを準備し、それにデータ を付ける。インターネットモジュールは、このインターネットアドレスの ためのローカルネットワークアドレスを決定する。この場合、それはゲー トウェイのアドレスである。 プログラムは、データグラムとローカルネットワークアドレスをローカル ネットワークインタフェースに送信する。 ローカルネットワークインタフェースはローカルネットワークヘッダを生 成し、データグラムをそれに付ける。そして、その結果として生成された ものをローカルネットワークを経由して送信する。 データグラムは、ローカルネットワークヘッダに包まれたゲートウェイホ ストに到着する。ローカルネットワークインターフェースはこのヘッダを 取り除き、データグラムをインターネットモジュールに渡す。インターネ ットモジュールは、インターネットアドレスを見て、このデータグラムを 2 番目のネットワーク内にある別のホストに転送することを決定する。イ ンターネットモジュールは、宛先ホストのローカルネットワークアドレス を決定する。インターネットモジュールはデータグラムを送信するために、 そのネットワークのローカルネットワークインターフェースを呼ぶ。 このローカルネットワークインタフェースは、ローカルネットワークヘッ ダを生成し、データグラムを付け、その結果として作成されたものを宛先 ホストに送信する。 この宛先ホストで、ローカルネットワークインタフェースによってローカ ルネットワークヘッダからデータグラムが抽出され、インターネットモジュ ールに手渡される。 インターネットモジュールは、そのデータグラムがこのホストのアプリケ ーションのためのものであることを決定する。そして、システムコールの 応答でアプリケーションプログラムにデータを渡し、呼び出しの結果とし て送信元アドレスやその他のパラメタを渡す。 Application Application Program Program \ / Internet Module Internet Module Internet Module \ / \ / LNI-1 LNI-1 LNI-2 LNI-2 \ / \ / Local Network 1 Local Network 2 Transmission Path Figure 2 2.3. 機能規定 インターネットプロトコルの機能や目的は、ネットワークの相互接続された セットを通じてデータグラムを移すことである。これは、宛先に到着するま で、あるインターネットモジュールから別のインターネットモジュールにデ ータグラムを渡すことによって行われる。インターネットモジュールは、イ ンターネットシステムのホストやゲートウェイの中に在る。データグラムは、 インターネットアドレスの解釈に基づく個々のネットワークを通じて、一方 のインターネットモジュールからもう一方のインターネットモジュールへ届 けられる。従って、インターネットプロトコルの 1 つの重要なメカニズム は、インターネットアドレスである。 一方のインターネットモジュールからもう一方のインターネットモジュール へのメッセージのルーティングにおいて、データグラムは、最大パケット長 がデータグラムの長さよりも小さいネットワークを通過する必要があるかも しれない。この難点を解決するために、分割メカニズムがインターネットプ ロトコルに提供される。 Addressing 区別は、名前とアドレスと経路で行われる [4]。名前は私達が求めるもの を示す。アドレスはどこにあるかを示す。経路はどのようにしてそこに到 達するかを示す。インターネットプロトコルは主にアドレスを扱う。名前 からアドレスを対応付けるのは、上位レベルのプロトコル (例えばホスト ツーホストやアプリケーション) の仕事である。インターネットモジュー ルは、インターネットアドレスをローカルネットワークアドレスに対応付 ける。ローカルネットワークアドレスから経路に対応付けるのは、下位レ ベルの手続き (例えばローカルネットやゲートウェイ) の仕事である。 アドレスは 4 オクテット (32bit) の固定長である。アドレスはネットワ ーク番号から始まり、ローカルアドレス ("残りの" フィールドと呼ばれ る) が続く。インターネットアドレスには 3 つの形式やクラスがある。 クラス a では、最上位ビットは 0 であり、続く 7 ビットがネットワー ク番号である。そして残りの 24 ビットがローカルアドレスである。クラ ス b では、最上位の 2 ビットは 1 0 であり、続く 14 ビットがネット ワーク番号である。そして残りの 16 ビットがローカルアドレスである。 クラス c では、最上位の 3 ビットは 1 1 0 であり、続く 21 ビットが ネットワーク番号である。そして残りの 8 ビットがローカルアドレスで ある。 インターネットアドレスをローカルネットワークアドレスにマッピングす る際、次のことを注意しなければならない。一つの物理ホストは、複数の 別個のインターネットアドレスを使用して、あたかも複数の別個のホスト であるかのように動作できなければならない。また、あるホストは複数の 物理インタフェース (マルチホーミング) を持ってもよい。 すなわち、ホストは複数の論理インターネットアドレスを各々持つ、ネッ トワークへの複数の物理インターフェースを持つ準備をしなければならな い。 アドレスマッピングの例は、"Address Mappings"[5] に示されている。 Fragmentation インターネットデータグラムの分割は、それが大きなパケットサイズを許 しているローカルネットワークから起こり、その宛先に到達させる為にパ ケットをより小さいサイズに制限しているローカルネットワークに配送し なければならない時必要である。 インターネットデータグラムは、"分割不可" というマークを付けること ができる。そのマークが付けられているあらゆるインターネットデータグ ラムは、どんな環境下でもインターネット分割が行われない。もし "分割 不可" というマークが付けられているインターネットデータグラムを、分 割せずにその宛先に配送することができなければ、代わりに破棄される。 インターネットプロトコルモジュールに見えないローカルネットワークを 渡る分割、送信、組立は、内部ネットワーク分割と呼ばれ、[6]で使用し てもよい。 インターネット分割や組立手続きは、後で組立できるほとんど任意の個数 の断片に、データグラムを分割できる必要がある。フラグメントの受信者 は、異なるデータグラムのフラグメントが混じらないことを保証するため に識別フィールドを使用する。フラグメントのオフセットフィールドは、 受信側に元のデータグラム中のフラグメントの位置を伝える。フラグメン トのオフセットと長さは、このフラグメントによってカバーされた元のデ ータグラムの位置を決める。more-fragments フラグは、(再設定すること によって) 最後のフラグメントを示す。これらのフィールドは、データグ ラムを組立するために十分な情報を提供している。 識別フィールドは、あるデータグラムのフラグメントを、他のデータグラ ムのものと区別するために使用される。インターネットデータグラムの発 行元プロトコルモジュールは、識別フィールドに、データグラムがインタ ーネットシステム内に生きている間、送信元/宛先ペアとプロトコルに対 してユニークでなければならない値を設定する。完結したデータグラムの 発行元プロトコルモジュールは、more-fragments フラグに 0 を、フラグ メントオフセットに 0 を設定する。 長いインターネットデータグラムを分割するために、インターネットプロ トコルモジュール (例えばゲートウェイ) は、2 つの新しいインターネッ トデータグラムを生成し、インターネットヘッダフィールドの内容を、長 いデータグラムから両方の新しいインターネットヘッダにコピーする。長 いデータグラムのデータは、8 オクテット (64 ビット) 境界で 2 つの部 分に分割される (2 番目の部分は 8 オクテットの整数倍でなくとも良い が、1 番目はそうでなくてはならない)。1番目の部分の 8 オクテットブ ロックの個数を NFB (for Number of Fragment Blocks) と呼ぶ。データ の始めの部分は、1 番目の新しいインターネットデータグラムに置かれる。 そして、全体長フィールドに 1 番目のデータグラムの長さが設定される。 more-fragments フラグは 1 に設定される。データの 2 番目の部分は、2 番目の新しいインターネットデータグラムに置かれる。そして、全体長フィ ールドに2 番目のデータグラムの長さが設定される。more-fragments フ ラグは長いデータグラムと同じ値を運ぶ。2 番目の新しいインターネット データグラムのフラグメントオフセットフィールドには、長いデータグラ ム中のそのフィールドに NFB を加えた値を設定する。 この手続きは 2 方向分割というよりはむしろ n 方向分割として一般化で きる。 インターネットデータグラムのフラグメントを組み立てるために、インタ ーネットプロトコルモジュール (例えば宛先ホスト) は、識別子, 送信 元, 宛先, プロトコル、の 4 つのフィールドについて同じ値を持つ全て のインターネットデータグラムを結合する。結合は、フラグメントのイン ターネットヘッダ内のフラグメントオフセットで示されている相対位置に、 各フラグメントのデータ部分を置くことによって行われる。1 番目のフラ グメントは、フラグメントオフセットが0 であり、最後のフラグメントは、 more-fragments フラグが 0 に再設定されているだろう。 2.4. ゲートウェイ ゲートウェイは、ネットワーク間でデータグラムを転送する為にインターネ ットプロトコルを実装する。ゲートウェイは、ルーティングや他のインター ネット制御情報を調整する為にゲートウェイツーゲートウェイプロトコル (GGP)[7] も実装する。 ゲートウェイでは上位レベルのプロトコルを実装する必要はなく、GGP機能 は IP モジュールに追加される。 +-------------------------------+ | Internet Protocol & ICMP & GGP| +-------------------------------+ | | +---------------+ +---------------+ | Local Net | | Local Net | +---------------+ +---------------+ Gateway Protocols Figure 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example Internet Datagram Header Figure 4. 区切りマークは 1 ビットを示す。 Version: 4 bits バージョンフィールドは、インターネットヘッダの形式を示す。このドキュ メントはバージョン 4 について説明する。 IHL: 4 bits インターネットヘッダ長 (IHL: Internet Header Length) は、32 ビット 単位のインターネットヘッダの長さであり、データの始点を示す。正しい ヘッダの最小値は 5 である。 Type of Service: 8 bits サービスタイプは、望まれたサービス品質の抽象的なパラメタの指定を提 供する。これらのパラメタは、ある特定のネットワークを通じてデータグ ラムを転送する時の、実際のサービスパラメタの選択を手引するために使 用される。いくつかのネットワークは、サービスの優先度を提供する。そ れは、優先度の高いトラフィックを他のトラフィックよりも重要なものと してある程度扱う (一般的に、負荷の高い時間に、ある優先度以上のトラ フィックのみを受け入れることによって行う)。重要な選択は、低遅延と 高信頼性と高スループットの 3 つの点のトレードオフである。 Bits 0-2: Precedence. Bit 3: 0 = Normal Delay, 1 = Low Delay. Bits 4: 0 = Normal Throughput, 1 = High Throughput. Bits 5: 0 = Normal Relibility, 1 = High Relibility. Bit 6-7: Reserved for Future Use. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | | | | PRECEDENCE | D | T | R | 0 | 0 | | | | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ Precedence 111 - Network Control 110 - Internetwork Control 101 - CRITIC/ECP 100 - Flash Override 011 - Flash 010 - Immediate 001 - Priority 000 - Routine 遅延とスループットと信頼性の指定の使用は、(ある場合) サービスのコ ストを増やすかもしれない。多くのネットワークでは、これらのパラメタ の 1 個に対してより良いパフォーマンスを実現すると、別の点に関連す るパフォーマンスがより悪くなるだろう。非常に稀な場合を除いて、これ らの 3 つの指示のうち 2 つは大抵設定すべきである。 サービスのタイプは、インターネットシステムを通じてそれを転送してい る間のデータグラムの扱いを指定する為に使用される。インターネットの サービスタイプと、例えば AUTODIN II, ARPANET, SATNET, PRNET のよう な、ネットワーク上で提供される実際のサービスへのマッピングの 例は、"Service Mapping" [8] で示されている。 ネットワーク制御の優先度の指定は、1 つのネットワークだけの範囲内で 使用されることを意図している。その指定の実際の使用と制御は、各ネッ トワークまでである。相互ネットワーク制御の指定は、ゲートウェイの制 御元によってのみ使用されることを意図している。もし、これらの優先度 の指定を実際に使用することが、ある特定のネットワークで重要ならば、 それらの優先度指定へのアクセスや使用を制御することは、そのネットワ ークの責任である。 Total Length: 16 bits 全体長はデータグラムの長さであり、オクテット単位で算出され、インタ ーネットヘッダとデータを含む。このフィールドは、最大 65535オクテッ トまでのデータグラムの長さが可能である。そのようなな長いデータグラ ムは、大半のホストやネットワークに対して非実践的である。全てのホス トは、最大 576 オクテットまでのデータグラムを受信する準備をしなけ ればならない (受信するものが全体であれ、フラクセメントであれ)。も し宛先がより大きいデータグラムを受信する準備を行っている保証がある ならば、ホストは 576 オクテットよりも大きいデータグラムを送信する ことが推奨される。 576 という数字は、必要なヘッダ情報に加え、効率的なサイズのデータブ ロックを転送することを可能にするために選択されている。例えば、この サイズは 1 つのデータグラムに合わせるために、512 オクテットと 64 ヘッダオクテットのデータブロックを可能にする。最大のインターネット ヘッダは 60 オクテットであり、通常のインターネットヘッダは 20 オク テットである。上位レベルプロトコルのヘッダのために余裕を持たすこと ができる。 Identification: 16 bits データグラムのフラグメントの組み立てを補助するために、送信者によっ て割り当てられた識別値。 Flags: 3 bits 様々な制御フラグ。 Bit 0: reserved, must be zero Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ Fragment Offset: 13 bits このフィールドは、データグラム中のどこにこのフラグメントが属するか を示す。フラグメントオフセットは、8 オクテット (64 ビット)単位で算 出される。1 番目のフラグメントのオフセットは 0 である。 Time to Live: 8 bits このフィールドは、データグラムがインターネットシステムに残ることが 許される最大時間を示す。もしこのフィールドが値 0 を含むならば、そ のデータグラムを破棄しなければならない。このフィールドは、インター ネットヘッダ処理で更新される。時間は秒単位で計測されるが、データグ ラムを処理する全てのモジュールは、たとえデータグラムを 1 秒以下で 処理したとしても、TTL を少なくとも 1 減らさなければならないので、 TTL はデータグラムが存在してもよい時間の上限の値だけを考慮しなけれ ばならない。このフィールドの意図は、配送できないデータグラムを破棄 することであり、最大データグラム生存時間を割り当てることである。 Protocol: 8 bits このフィールドは、インターネットデータグラムのデータ部で使用される 次のレベルのプロトコルを示す。様々なプロトコルに対する値は、"番号 割り当て" [9] で規定されている。 Header Checksum: 16 bits ヘッダだけのチェックサム。あるヘッダフィールド (例えば生存時間フィ ールド) は値が変わるので、インターネットヘッダが処理される各々の箇 所で再計算され、照合される。 チェックサムアルゴリズム: チェックサムフィールドは、ヘッダ中の全ての 16 ビットワードの1 の 補数の合計の、16 ビットの 1 の補数である。チェックサムを算出する 目的では、チェックサムフィールドの値は 0 とみなす。 チェックサムを算出することは簡単であり、実験上の証拠はそれが適当で あることを示している。しかし、それは備えであり、将来の経験によって は CRC の手続きに置き代わるかもしれない。 Source Address: 32 bits 送信元のアドレス。3.2 節参照。 Destination Address: 32 bits 宛先のアドレス。3.2 節参照。 Options: variable オプションはデータグラム中に表れてもよいし、表れなくてもよい。全て の IP モジュール (host も gateway も) は、それらを実装しなければな らない。オプションなのは、ある特定のデータグラム中での転送であり、 それらの実装ではない。 ある環境では、セキュリティオプションが全てのデータグラム中に要求さ れるかもしれない。 オプションフィールドは、可変長である。0 個以上のオプションがある。 オプションの形式は 2 種類ある。 Case 1: オプションタイプの単一オクテット Case 2: オプションタイプオクテット、オプションの長さオクテット、 そして実際オプションデータ値 オプションの長さオクテットはオプションデータ値だけでなく、オプショ ンタイプオクテットとオプションの長さオクテットもカウントする。 オプションタイプオクテットは、3 つのフィールドを持つものとして見ら れる。 1 bit コピーフラグ 2 bits オプションクラス 5 bits オプション数 コピーフラグは、このオプションが分割された全てのフラグメントに複写 されることを示す。 0 = コピーしない 1 = コピーする オプションクラスは、 0 = 制御 (control) 1 = 将来の使用の為に予約 (reserved for future use) 2 = デバックと計測 (debugging and measurement) 3 = 将来の使用の為に予約 (reserved for future use) 以下のインターネットオプションが定義されている。 CLASS NUMBER LENGTH DESCRIPTION ----- ------ ------ ----------- 0 0 - オプションリストの最終。このオプションは 1 オクテットのみ使用し、長さオクテットは持たな い。 0 1 - 処理無し。このオプションは 1 オクッテトのみ 使用し、長さオクテットは持たない。 0 2 11 セキュリティ。セキュリティ、コンパートメント、 ユーザグループ (TCC)、DOD 要件互換の制限コー ド操作、を送信するために使用される。 0 3 可変 厳密でない送信元と経路記録。送信元によって提 供された情報に基づいて、インターネットデータ グラムを振り分けるために使用される。 0 9 可変 厳密な送信元と経路記録。送信元によって提供さ れた情報に基づいて、インターネットデータグラ ムを振り分けるために使用される。 0 7 可変 経路記録。インターネットデータグラムが辿る経 路をトレースするために使用される。 0 8 4 ストリーム ID。ストリーム識別子を送信するた めに使用される。 2 4 可変 インターネットタイムスタンプ。 特定のオプション定義 End of Option List +--------+ |00000000| +--------+ Type=0 このオプションは、オプションリストの最終を示す。これは、インタ ーネットヘッダ長に従った最終とは一致しないかもしれない。これは、 全てのオプションの最後で使用され、オプションの最後がインターネ ットヘッダの最終とは一致しない場合に限り必要である。 あるいは、その他何らかの理由により、フラグメントに複写、追加、 削除してもよい。 No Operation +--------+ |00000001| +--------+ Type=1 このオプションは、例えば後続するオプションの開始を 32 ビット境 界に調整する為に、オプションとオプションの間で使用してもよい。 あるいは、その他何らかの理由により、フラグメントに複写、追加、 削除してもよい。 Security このオプションは、ホストがセキュリティやコンパートメント、制限 操作、TCC (閉じたユーザグループ) パラメタを送信する方法を提供 する。このオプションの形式は、以下の通りである。 +--------+--------+---//---+---//---+---//---+---//---+ |10000010|00001011|SSS SSS|CCC CCC|HHH HHH| TCC | +--------+--------+---//---+---//---+---//---+---//---+ Type=130 Length=11 Security (S field): 16 bits 16 レベル (その内の 8 個は、将来の使用のために予約) のセキュ リティの一つを示す。 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 - (将来の使用のために予約) Compartments (C field): 16 bits 転送される情報がコンパートメントされない時は、全て 0 の値が 使用される。コンパートメントフィールドで使用される他の値は、 Defense Intelligence Agency から取得される。 Handling Restrictions (H field): 16 bits 制御と解放のマークのための値はアルファベットの二連字であり、 Defense Intelligence Agency Manual DIAM 65-19 の "Standard Security Markings" で定義される。 Transmission Control Code (TCC field): 24 bits トラフィックを隔離し、購読者の間で興味のある制御された通信を 定義するための手段を提供する。TCC の値は三連字で、HQ DCA コ ード 530 から利用できる。 フラグメントにコピーしなければならない。このオプションは一つの データグラム中に一回現れる。 Loose Source and Record Route +--------+--------+--------+---------//--------+ |10000011| length | pointer| route data | +--------+--------+--------+---------//--------+ Type=131 厳密でない送信元と経路記録 (LSRR: loose source and record route) オプションは、インターネットデータグラムの送信元が、デ ータグラムを宛先に転送する際にゲートウェイが使用する経路情報を 付与し、経路情報を記録する手段を提供する。 このオプションは、オプションタイプコードから開始される。二番目 のオクテットはオプション長であり、オプションタイプコードや長さ オクテット、ポインタオクテット、経路データの長さ -3 のオクテッ トを含む。三番目のオクテットは、処理される次の送信元アドレスで 始まるオクテットを示す経路データへのポインタである。そのポイン タはこのオプションからの相対で、このポインタとして最も小さい正 しい値は 4 である。 経路データは、一連のインターネットアドレスで構成される。各々の インターネットアドレスは、32 ビット、または 4 オクテットである。 もしこのポインタがその長さよりも大きいならば、その送信元経路は 空 (記録された経路は一杯) であり、経路は宛先アドレスフィールド に基づく。 もし宛先フィールド中のアドレスに到達し、そのポインタが長さより も小さいならば、送信元経路の次のアドレスを、宛先アドレスフィー ルドのアドレスに置き換え、経路記録アドレスをちょうど使用した送 信元アドレスに置き換え、ポインタを 4 加算する。 経路記録アドレスは、このデータグラムが転送される環境で知られる インターネットモジュール自身のインターネットアドレスである。 送信元経路を経路記録に置き換えるこの手続きは (順番の逆転になる が、送信元の経路として使用しなければならない)、インターネット を通じてデータグラムが進んでも、このオプション (とIP ヘッダ全 体) は固定の長さのままであることを意味する。 ゲートウェイかホストの IP は、経路中の次のアドレスに到達させる ために、他の中間ゲートウェイの如何なる経路も使用することが許さ れているので、このオプションは厳密でない送信元経路である。 フラグメントにコピーしなければならない。このオプションは一つの データグラム中に一回現れる。 Strict Source and Record Route +--------+--------+--------+---------//--------+ |10001001| length | pointer| route data | +--------+--------+--------+---------//--------+ Type=137 厳密な送信元と経路記録 (SSRR: strict source and record route) オプションは、インターネットデータグラムの送信元が、データグラ ムを宛先に転送する際にゲートウェイが使用する経路情報を供給し、 経路情報を記録する手段を提供する。 このオプションは、オプションタイプコードから開始される。二番目 のオクテットはオプション長であり、オプションタイプコードや長さ オクテット、ポインタオクテット、経路データの長さ -3 のオクテッ トを含む。三番目のオクテットは、処理される次の送信元アドレスで 始まるオクテットを示す経路データへのポインタである。そのポイン タはこのオプションからの相対で、このポインタとして最も小さい正 しい値は 4 である。 経路データは、一連のインターネットアドレスで構成される。各々の インターネットアドレスは、32 ビット、または 4 オクテットである。 もしこのポインタがその長さよりも大きいならば、その送信元経路は 空 (記録された経路は一杯) であり、経路は宛先アドレスフィールド に基づく。 もし宛先フィールド中のアドレスに到達し、そのポインタが長さより も小さいならば、送信元経路の次のアドレスを、宛先アドレスフィー ルドのアドレスに置き換え、経路記録アドレスをちょうど使用した送 信元アドレスに置き換え、ポインタを 4 加算する。 経路記録アドレスは、このデータグラムが転送される環境で知られる インターネットモジュール自身のインターネットアドレスである。 送信元経路を経路記録に置き換えるこの手続きは (順番の逆転になる が、送信元の経路として使用しなければならない)、インターネット を通じてデータグラムが進んでも、このオプション (とIP ヘッダ全 体) は固定の長さのままであることを意味する。 ゲートウェイかホストの IP は、次アドレスで示された直接接続され たネットワークを通じて、データグラムを送信元経路中の次のアドレ スに直接送信しなければならないので、このオプションは厳密な送信 元経路である。 フラグメントにコピーしなければならない。このオプションは一 つのデータグラム中に最大一回現れる。 Record Route +--------+--------+--------+---------//--------+ |00000111| length | pointer| route data | +--------+--------+--------+---------//--------+ Type=7 経路記録オプションは、インターネットデータグラムの経路を記録す る手段を提供する。 このオプションは、オプションタイプコードから開始される。二番目 のオクテットはオプション長であり、オプションタイプコードや長さ オクテット、ポインタオクテット、経路データの長さ -3 のオクテッ トを含む。三番目のオクテットは、処理される次の送信元アドレスで 始まるオクテットを示す経路データへのポインタである。そのポイン タはこのオプションからの相対で、このポインタとして最も小さい正 しい値は 4 である。 経路データは、一連のインターネットアドレスで構成される。各々の インターネットアドレスは、32 ビット、または 4 オクテットである。 もしこのポインタがその長さよりも大きいならば、経路記録データ領 域は一杯である。発行元のホストは、予期される全てのアドレスを保 持するのに十分な大きさの経路データ領域で、このオプションを構成 しなければならない。このオプションのサイズは、アドレスを追加す るために変更しない。経路データ領域の初期内容は、0 でなければな らない。 インターネットモジュールがデータグラムを振り分ける時、経路記録 オプションが存在するか否かチェックする。もし存在するならば、こ のデータグラムが転送される環境で知られるインターネットモジュー ル自身のインターネットアドレスを、ポインタによって示されている オクテットで始まる経路記録に挿入し、ポインタを 4 加算する。 もし経路データ領域が既に一杯 (ポインタが長さを超える) ならば、 経路記録にアドレスを挿入せずにデータグラムを転送する。もし領域 はあるが、アドレスを挿入するのに十分な大きさでないならば、元の データグラムは異常だと見なされ、破棄される。いずれのケースでも、 ICMP パラメタ問題メッセージを送信元ホストに送信してもよい [3]。 フラグメントにはコピーされず、最初のフラグメントにのみ存在する。 このオプションはデータグラム中で最大一回現れる。 Stream Identifier +--------+--------+--------+--------+ |10001000|00000010| Stream ID | +--------+--------+--------+--------+ Type=136 Length=4 このオプションは、16 ビット SATNET ストリーム識別子を、ストリ ームの概念をサポートしていないネットワークを通じて送信するため の方法を提供する。 フラグメントにコピーしなければならない。このオプションはデータ グラム中に最大一回現れる。 Internet Timestamp +--------+--------+--------+--------+ |01000100| length | pointer|oflw|flg| +--------+--------+--------+--------+ | internet address | +--------+--------+--------+--------+ | timestamp | +--------+--------+--------+--------+ | . | . . Type = 68 オプション長は、タイプ、長さ、ポインタ、オーバーフロー/フラグ オクテットを含むオプション中のオクテットの数である (最大長は 40)。 ポインタは、このオプションの開始からタイムスタンプ + 1 まで (すなわち、次のタイムスタンプ領域から始まるオクテットを指す) のオクテットの数である。最も小さい正しい値は 5 である。ポイン タが長さよりも大きい場合、タイムスタンプ領域は一杯である。 オーバフロー (oflw) [4 ビット] は、領域不足のためにタイムスタ ンプを登録できない IP モジュールの数である。 フラグ (flg) [4 bits] の値は、 0 -- タイムスタンプのみで、連続した 32 ビットワードに格納さ れる。 1 -- 各タイムスタンプの前に、登録するエンティティのインター ネットアドレスが付く。 3 -- インターネットアドレスフィールドが前に指定される。IP モ ジュールは、もし自分自身のアドレスが次に指定されたイン ターネットアドレスに一致した場合にのみ、自身のタイムス タンプを登録する。 タイムスタンプは夜中の UT からの公正な、ミリ秒単位の 32 ビット タイムスタンプである。もし、時間がミリ秒単位で表現できないか、 夜中の UT からの相対で提供できないならば、非標準の値の使用を示 すためにタイムスタンプフィールドの高次ビットに1 を設定して、タ イムスタンプとして挿入してもよい。 発行元のホストは、予期される全てのタイムスタンプ情報を保持する のに十分な大きさのタイムスタンプデータ領域で、このオプションを 構成しなければならない。このオプションのサイズは、タイムスタン プを追加するために変更しない。タイムスタンプデータ領域の初期内 容は 0 か、インターネットアドレス/0 のペアでなければならない。 もしタイムスタンプデータ領域が既に一杯 (ポインタが長さを超え る) ならば、タイムスタンプを挿入せずにデータグラムを転送する。 しかし、オーバフロー数は 1 加算される。 もし領域はあるが、タイムスタンプを挿入するのに十分な大きさでな いか、オーバフローの個数自体がオーバフローするならば、元のデー タグラムは異常だと見なされ、破棄される。いずれのケースにおいて も、ICMP パラメタ問題メッセージを送信元ホストに送信してもよい [3]。 タイムスタンプオプションは、フラグメントにコピーされない。最初 のフラグメントで送信される。このオプションはデータグラム中で最 大一回現れる。 Padding: 可変 インターネットヘッダパディングは、インターネットヘッダが 32 ビット 境界で終了することを保証するために使用される。パディングは 0 であ る。 3.2. 議論 プロトコルの実装は強固でなければならない。各々の実装は、別の人によっ て作成された他の実装と相互動作することを考慮しなければならない。この 規約の目標はプロトコルに関して明確化することであるが、異なって解釈さ れる可能性はある。一般的に、実装は送信動作においては慎重で、受信動作 においては寛大でなければならない。すなわち、正しく形成されたデータグ ラムを送信するよう、注意深くなければならないが、解釈可能な如何なるデ ータグラムも受信できなければならない (意味することがまだはっきりして いる技術的な異常は反対しない等)。 基本的なインターネットサービスはデータグラム型であり、ゲートウェイで データグラムの分割を提供し、宛先ホストにある宛先インターネットプロト コルモジュールで組立する。もちろんネットワーク内、あるいはネットワー クのゲートウェイ間の私的な同意によるデータグラムの分割と組立もまた許 されている。なぜならば、これはインターネットプロトコルや上位レベルプ ロトコルに透過的であるから。この透過的な分割や組立のタイプは、"ネッ トワーク依存" (またはイントラネット) のフラグメント化と呼ばれ、ここ ではこれ以上論じない。 インターネットアドレスはホストレベルで送信元と宛先を区別し、プロトコ ルフィールドも提供する。各プロトコルは、ホスト内部で多重化必要なもの は何でも提供するものと想定される。 Addressing ネットワークへのアドレス割り当てに柔軟性をもたらすために、そして大 量の小中規模サイズのネットワークを可能にするために、アドレスフィー ルドの解釈は、少数のホストを持つ小規模ネットワークや、中程度のホス トを持つ中規模るネットワーク、少数のホストを持つ大規模ネットワーク を指定するためにコード化される。加えて、拡張アドレスモードのための エスケープコードがある。 Address Formats: 最上位ビット 形式 クラス --------------- ------------------------------- ----- 0 7 bits of net, 24 bits of host a 10 14 bits of net, 16 bits of host b 110 21 bits of net, 8 bits of host c 111 escape to extended addressing mode ネットワークフィールドの値 0 は、このネットワークを意味する。こ れは、ある ICMP メッセージでのみ使用される。拡張アドレスモードは 未定義である。これらの役割はどちらも将来の使用のために予約されて いる。 ネットワークアドレスに割り当てられた実際の値は、"番号割り当て (Assigned Numbers)" [9] で示されている。 ローカルなネットワークで割り当てられたローカルなアドレスは、単一の 物理ホストが幾つかの別々のホストとして動作することを許さなければな らない。すなわち、幾つかのインターネットアドレスが 1つのインタフェ ースに対応できるようにする、インターネットホストアドレスとネットワ ーク/ホストインタフェース間のマッピングが存在しなければならない。1 つのホストが幾つかの物理インタフェースを持ち、それらの幾つかから来 たデータグラムをあたかもそれらが皆、単一のホストにアドレス付けされ ているかのように扱うことも可能にしなければならない。 インターネットアドレスと ARPANET, SATNET, PRNET, その他のネットワ ークのアドレス間のアドレスマッピングは、"Address Mappings" [5] に 規定されている。 Fragmentation and Reassembly. インターネット識別子フィールド (ID) は、組立用にデータグラムのフラ グメントを識別するために、送信元と宛先のアドレスやプロトコルフィー ルドと一緒に使用される。 More Fragments フラグビット (MF) は、もしデータグラムが最後のフラ グメントでなければ設定される。フラグメントオフセットフィールドは、 元の分割されていないデータグラムの最初の位置から相対のフラグメント の位置を示す。フラグメントは 8 オクテット単位で数えられる。この分 割方法は、分割されていないデータグラムが全て 0の フラグメント情報 (MF=0, offset=0) を持つように設計されている。もしインターネットデ ータグラムが分割されているならば、そのデータ部は 8 オクテット境界 で分割しなければならない。 この形式では、各々 8 オクテットで 2 の 13 乗 = 8192 フラグメント、 トータルで 65536 オクテットまで可能である。これは、データグラムの 全体長フィールドと首尾一貫していることに注意されたい(もちろんヘッ ダはフラグメントではなく、長さフィールドにカウントされる)。 分割が発生する時、いくつかのオプションはコピーされるが、それ以外の オプションは一番最初のフラグメントだけである。 全てのインターネットモジュールは、もう分割化されることのない68 オ クテットのデータグラムを送信できなければならない。これは、インター ネットヘッダの最大が 60 オクテットで、フラグメントの最小が 8 オク テットだからである。 あらゆるインターネット宛先は、1 個あるいは組立されるフラグメントの いずれかで、576 オクテットのデータグラムを受信できなければならない。 分割によって影響があるかもしれないフィールドは以下を含む。 (1) options field (2) more fragments flag (3) fragment offset (4) internet header length field (5) total length field (6) header checksum もし、Don't Fragment (DF) フラグビットが設定されているならば、これ を破棄してもよいが、このデータグラムのインターネット分割は許されな い。これは、受信側のホストがインターネットフラグメントを組立するの に十分な資源を持たない場合に、分割を禁止するために使用できる。 Don't Fragment の機能を使用する 1 つの例は、小さなホストの回線負荷 を下げることである。小さなホストは、データグラムを受信するブートス トラッププログラムに、データグラムをメモリに蓄積してから、それを実 行させることができるだろう。 分割化と組立の手続きは、例で非常に易しく説明されている。以下の手続 きは、実装例である。 以下の疑似プログラム中の一般記法は: "=<" は "以下" "#" は "等しくない" "=" は "等しい" "<-" は "に設定される" をそれぞれ意味する。また、"x to y" は、x を含み y を除く。 例えば、"4 to 7" は 4, 5, 6 を含む (7 は含まない)。 An Example Fragmentation Procedure 次のネットワーク通じて送信できる最大長のデータグラムは、最大転送 単位 (MTU : maximum transmission unit) と呼ばれる。 もし全体長が最大転送単位以下ならば、このデータグラムをデータグラ ム処理の次のステップに送る。さもなくば、データグラムを 2つのフラ グメントに切る。1 番目のフラグメントは最大長であり、2 番目のフラ グメントは残りのデータグラムである。1 番目のフラグメントは、デー タグラム処理の次のステップに送られ、2 番目のフラグメントはまだ大 きい場合、この手続きに送られる。 Notation: FO - フラグメントオフセット IHL - インターネットヘッダ長 DF - Don't Fragment フラグ MF - More Fragments フラグ TL - 全体長 OFO - 前のフラグメントオフセット OIHL - 前のインターネットヘッダ長 OMF - 前の More Fragments フラグ OTL - 前の全体長 NFB - フラグメントブロックの個数 MTU - 最大転送単位 Procedure: IF TL =< MTU THEN このデータグラムをデータグラム処理の次のステップに送る ELSE IF DF = 1 THEN このデータグラムを破棄 ELSE 1 番目のフラグメント生成するために、 (1) 元のインターネットヘッダをコピーする (2) OIHL <- IHL; OTL <- TL; OFO <- FO; OMF <- MF; (3) NFB <- (MTU-IHL*4)/8; (4) 1 番目の 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) このフラグメントを分割テストに送る 上記の手続きでは、各々のフラグメントは (最後を除く) 許される最大 長で作成される。上記の手続きとは別の方法では、データグラムの最大 長以下で作成するかもしれない。例えば、フラグメントが最大転送単位 のサイズ以下になるまで、大きいサイズのデータグラムを半分の単位に 繰り返し分割するような分割化手続きを実装することもあり得る。 An Example Reassembly Procedure 各々のデータグラムに対して、送信元、宛先、プロトコル、識別子フィ ールドの連結時にバッファ識別子が算出される。もしこれがデータグラ ム全体であれば (すなわち、フラグメントオフセットとmore fragments フィールドが 0)、このバッファ識別子に割り付けられたあらゆる組立 資源が解放され、そのデータグラムは次のデータグラム処理のステップ に送られる。 もし、このバッファ識別子を持つ他のフラグメントが手元にないならば、 組立資源が割り当てられる。組立資源はデータバッファ、ヘッダバッ ファ、フラグメントブロックビットテーブル、全体データ長フィールド、 タイマから構成される。フラグメントからのデータは、そのフラグメン トオフセットと長さに従ってデータバッファに置かれる。そして、受信 されたフラグメントブロックに対応するフラグメントブロックビットテ ーブルにビットが設定される。 もしこれが一番最初のフラグメント (すなわちフラグメントオフセット が 0) ならば、このヘッダはヘッダバッファに置かれる。もしこれが一 番最後のフラグメント (すなわち More フラグメントフィールドが 0) ならば、全体データ長が算出される。もしこのフラグメントがデータグ ラムを完了させているならば (フラグメントプロックテーブルに設定さ れたビットをチェックすることによって検査される)、そのデータグラ ムはデータグラム処理の次のステップに送信される。さもなくば、現タ イマ値とこのフラグメントの生存時間フィールドの値のうち大きい値を タイマに設定し、組立ルーチンは制御を放棄する。 もしタイマが満了したら、このバッファ識別子のための全ての組立資源 は解放される。タイマの初期設定は組立待ちタイマの下限境界である。 これは、もし到達したフラグメントの生存時間が現在のタイマ値よりも 大きければ待ち時間が加算されるが、もし小さければ減算されないから である。このタイマ値が達し得る最大値は、最大生存時間である (およ そ 4.25 分)。初期タイマ設定の現在の推奨値は 15 秒である。これは、 このプロトコルを用いて築かれた経験に従って変更してもよい。このパ ラメタ値の選択は、利用可能なバッファの受容力と転送媒体のデータ速 度に関係する。すなわちデータ速度時間タイマ値はバッファサイズと等 しい (例えば 10Kb/s×15s = 150Kb)。 Notation: FO - フラグメントオフセット IHL - インターネットヘッダ長 MF - More Fragments フラグ TTL - 生存時間 NFB - フラグメントブロックの個数 TL - 全体長 TDL - 全体データ長 BUFID - バッファ識別子 RCVBT - 受信フラグメントビットテーブル TLB - タイマ下限境界 Procedure: (1) BUFID <- 送信元 | 宛先 | プロトコル | 識別子; (2) IF FO = 0 AND MF = 0 (3) THEN IF BUFID のバッファが割り当てられている (4) THEN この BUFID の全ての組立をフラッシュする (5) データグラムを次のステップに発行して完了 (6) ELSE IF BUFID のバッファが割り当てられていない (7) THEN BUFID の組立資源を割り当てる TIMER <- TLB; TDL <- 0; (8) BUFID のデータバッファにオクテット FO から オクテ ット (TL-(IHL*4))+FO*8 までのデータを格納する (9) FO から FO+((TL-(IHL*4)+7)/8) までの RCVBT ビット を設定する (10) IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8) (11) IF FO = 0 THEN ヘッダをヘッダバッファに格納する (12) IF TDL # 0 (13) AND 0 から (TDL+7)/8 までの RCVBT ビットが全て設 定されていたら (14) THEN TL <- TDL+(IHL*4) (15) データグラムを次のステップに発行する (16) この BUFID に対する全ての組立資源を解放し て完了 (17) TIMER <- MAX(TIMER,TTL); (18) 次のフラグメントが来るかタイマが満了するまで放棄 する (19) タイマ満了: この BUFID に対する全ての組立資源を解放して完 了 2 つ以上のフラグメントが、完全にあるいは一貫して同じデータを含む ならば、この手続きはデータバッファと送信されたデータグラムとして、 より最近到達したコピーを使用するだろう。 Identification データグラムの識別子の選択は、特定のデータグラムのフラグメントをユ ニークに識別するための方法を提供する必要性に基づく。フラグメントを 組み立てるプロトコルモジュールは、もしフラグメントが同一の送信元、 宛先、プロトコル、識別子を持っていたら、同じデータグラムに属してい ると判定する。従って送信者は、データグラム (あるいはそのフラグメン ト) がインターネット内で生存している間、送信元/宛先/プロトコルの組 み合わせでユニークな識別子を選択しなければならない。 送信側プロトコルモジュールは、識別子のテーブルを保持する必要があり そうである。それは、インターネットの最後の最大パケット生存時間で、 通信している各々の宛先に対して一つのエントリを持つ。 しかし、識別子フィールドは 65536 個の異なる値がとれるので、あるホ ストは宛先に依存しないユニークな識別子を単純に使用できるかもしれな い。 ある上位レベルのプロトコルが識別子を選択することは適切である。例え ば、TCP プロトコルモジュールは、同じ TCP セグメントを再送するかも しれない。もし再送が元の送信と同じ識別子を運ぶならば、正常に受信さ れる可能性が増すだろう。なぜなら、どちらかのデータグラムのフラグメ ントは正しい TCP セグメントを作成するのに使用できるからである。 Type of Service サービスタイプ (TOS: type of service) は、インターネットのサービス 品質の選択である。サービイタイプは優先度、遅延、スループット、信頼 性の抽象的なパラメタによって指定される。これらの抽象的なパラメタは、 データグラムが流れる特定のネットワークの実際のサービスパラメタにマ ッピングされる。 優先度: このデータグラムの重要性の独自の尺度 遅延: これが指定されたデータグラムは、即座に配送することが重要であ る スループット: これが指定されたデータグラムは高いデータ転送率が重要 である。 信頼性: これが指定されたデータグラムは、配送を保証する高レベルの努 力が重要である 例えば、ARPANET は優先度ビットと、"標準" メッセージ (タイプ 0)と " 非管理" メッセージ (タイプ 3) の選択 (単一パケットと複数メッセージ の選択もまたサービスパラメタを考慮できる) がある。非管理メッセージ は信頼性が高くない送信で、遅延を受けやすい。インターネットデータグ ラムが ARPANET を通じて送信されると仮定する。インターネットのサー ビスタイプは以下のものとなる。 信頼性: 5 遅延: 0 スループット: 1 信頼性: 1 この例では、ARPANET で利用可能なパラメタにこれらのパラメタをマッピ ングすることは、インターネットの優先度がそのフィールドの上位半分に あたるので ARPANET 優先度ビットに設定することになり、スループット と信頼性の要件は指定され、遅延は指定されないので、標準メッセージを 選択することになるだろう。詳細は、"サービスマッピング" [8]のサービ スマッピングに記述されている。 Time to Live 生存時間は、送信者がデータグラムがインターネットシステムに存在する ことを許す最大時間を設定する。もしデータグラムが生存時間よりも長い 間インターネットシステムに存在していたら、そのデータグラムを破棄し なければならない。 このフィールドは、データグラムの処理に費やされた時間を反映してイン ターネットヘッダが処理される各々の点で、値が減らされる。実際に費や された時間な対して何のローカルな情報も利用可能ではなくとも、このフィ ールドを 1 減らさなければならない。時間は秒単位で計測される (例え ば、値 1 は 1 秒を意味する)。従って、最大生存時間は 255 秒、あるい は 4.25 分である。データグラムを処理するモジュールは、たとえそのデ ータグラムの処理に 1 秒かかっていなくとも、少なくとも 1 を TTL か ら減らさなければならないので、TTL はデータグラムが存在し得る時間の 上位境界のみを想定しなければならない。配送できないデータグラムを破 棄し、データグラムに生存時間を割り当てる意図がある。 ある高レベルの信頼性を持つコネクションプロトコルは、古い重複したデ ータグラムはある時間が経過したら到達しないだろうという仮定に基づい ている。TTL は、そのようなプロトコルの仮定に適合する保証を持つため の手段である。 Options オプションは各々のデータグラムで任意であるが、実装は必要要件である。 すなわち、オプションの提供、又は省略は送信者の選択だが、各々のイン ターネットモジュールは全てのオプションを解釈できなければならない。 オプションフィールドで提供される幾つかのオプションがある。 オプションは 32 ビット境界で終了しないかもしれない。そのインターネ ットヘッダは 0 のオクテットで満たさなければならない。これらの第一 番目はオプション最終のオプションとして解釈され、残りはインターネッ トヘッダのパディングである。 全てのインターネットモジュールは、全てのオプションに基づいて動作し なければならない。セキュリティオプションは、明確化された、あるいは 制限された、あるいはコンパートメント化されたトラフィックが通過され る場合に必要である。 Checksum インターネットヘッダチェックサムは、もしインターネットヘッダが変更 されたら再計算される。例えば、生存時間の減少、インターネットオプショ ンの追加や変更、あるいはフラグメント化による。インターネットレベル におけるチェックサムは、インターネットヘッダフィールドを、転送エラ ーから防護する意図を持つ。 再送遅延は無いが、二、三のデータビットエラーを受け入れるアプリケー ションは幾つか存在する。もしインターネットプロトコルがデータの修正 を強制したら、そのようなアプリケーションはサポートできないだろう。 Errors インターネットプロトコルエラーは、ICMP メッセージ [3] によって通知 される。 3.3. インタフェース IP へのユーザインタフェースの機能的な説明は、全てのオペレーティング システムは異なる設備を持つので、ほとんど虚構である。結論を言えば、異 なる IP 実装は異なるユーザインタフェースを持つかもしれないことに、注 意しなければならない。しかし、全ての IP 実装が同じプロトコルの階層を サポートできることを保証するために、全ての IP はある最低限のサービス セットを提供しなければならない。このセクションは、全ての IP 実装で必 要とされる機能的インタフェースを規定する。 インターネットプロトコルは一方でローカルネットワークへのインタフェー スがあり、もう一方で上位レベルプロトコルやアプリケーションプログラム へのインタフェースがある。後述したように上位レベルプロトコルかアプリ ケーションプログラムは (あるいはゲートウェイプログラムでさえも)、イ ンターネットモジュールを使用しているので "ユーザ"と呼ばれる。インタ ーネットプロトコルはデータグラムプロトコルなので、データグラムの転送 間に維持されるメモリや状態は最低限のものであり、ユーザによって各々の インターネットプロトコルモジュールを呼び出す際に、要求されたサービス を実現するために IP で必要な全ての情報を供給する。 上位レベルインタフェースの例 以下の二つの呼び出し例は、ユーザがインターネットプロトコルモジュール と通信する要件を満足させる ("=>" は返却結果を意味する)。 SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result) src = 送信元アドレス dst = 宛先アドレス prot = プロトコル TOS = サービス種別 TTL = 生存時間 BufPTR = バッファポインタ len = バッファ長 Id = 識別子 DF = フラグメント不可 opt = オプションデータ result = 応答 OK = データグラム送信 OK Error = アーギュメントエラー、又はローカルネットワークエラー 注記: 優先度は TOS に含まれ、セキュリティ/コンパートメントはオプショ ンで渡される。 RECV (BufPTR, prot, => result, src, dst, TOS, len, opt) BufPTR = バッファポインタ prot = プロトコル result = 結果応答 OK = データグラム受信 OK Error = アーギュメントエラー len = バッファ長 src = 送信元アドレス dst = 宛先アドレス TOS = サービス種別 opt = オプションデータ ユーザがデータグラムを送信する時、全てのアーギュメントを指定してSEND コールを実行する。インターネットプロトコルモジュールは、このコールを 受信したらアーギュメントをチェックし、メッセージを準備して送信する。 もしアーギュメントが正しく、データグラムが自側ネットワークによって受 諾されたならば、この呼び出しは成功する。もしアーギュメントに誤りがあ るか、自側ネットワークによって受諾されなければ、この呼び出しは失敗す る。失敗で戻ったら、その問題の原因に関して効果的な通知を行わなければ ならないが、その通知の詳細については個々の実装に任される。 自側ネットワークからインターネットプロトコルにデータが到達したとき、 アドレス付けされたユーザによる未処理の RECV 呼び出しが存在するか、存 在しないかのどちらかである。前者の場合、未処理のコールはデータグラム からの情報をユーザに渡すことによって完了する。後者の場合、アドレス付 けされたユーザが未処理のデータグラムを通知される。もしアドレス付けさ れたユーザが存在しなければ、ICMP エラーメッセージが送信者に返却され、 そのデータは破棄される。 実装体の特定のオペレーティング環境で適切に、擬似的な中断や同様なメカ ニズムによってユーザに通知してもよい。 ユーザの RECV コールはデータグラムを保留することによって直ぐに完了し てもよいし、データグラムが到達するまでコールが保留になってもよい。 送信元アドレスは、送信側ホストが複数のアドレス (複数の物理コネクショ ンやローカルアドレス) を持っている場合に SEND コールに含まれる。イン ターネットモジュールは、送信元アドレスがこのホストにとって正しいアド レスの一つであるかをチェックしなければならない。 実装体は、データグラムのクラス (例えばプロトコルフィールドのある値を 持つ全て) の排他的な使用に興味を示したり予約するために、インターネッ トモジュールへのコールを可能にするか必要としてもよい。 このセクションは、USER/IP インタフェースを機能的に特徴づける。使用さ れる記法は、上位レベル言語の関数呼び出しの大半の手続きと同様である。 しかしこの使用方法はトラップタイプのサービスコール (例えば、SVC, UUO, EMT) や、内部プロセス間通信の他の形式を除外することは意味しない。 APPENDIX A: 例とシナリオ Example 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 |Type of Service| Total Length = 21 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification = 111 |Flg=0| Fragment Offset = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time = 123 | Protocol = 1 | header checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+ Figure 5 - インターネットデータグラムの例 区切りマークは 1 ビットを示す。 これは、インターネットプロトコルのバージョン 4 のインターネットデー タグラムであり、インターネットヘッダが 5 個の 32 ビットワードから成 り、データグラムの全体長が 21 オクテットである。このデータグラムは完 全なデータグラムである (フラグメントではない)。 Example 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 |Type of Service| Total Length = 472 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification = 111 |Flg=0| Fragment Offset = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time = 123 | Protocol = 6 | header checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | \ \ \ \ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 - インターネットデータグラムの例 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 |Type of Service| Total Length = 276 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification = 111 |Flg=1| Fragment Offset = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time = 119 | Protocol = 6 | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | \ \ \ \ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 - インターネットデータグラムの例 二番目のフラグメント 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 |Type of Service| Total Length = 216 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification = 111 |Flg=0| Fragment Offset = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time = 119 | Protocol = 6 | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | \ \ \ \ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 - インターネットデータグラムの例 Example 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 |Type of Service| Total Length = 576 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification = 111 |Flg=0| Fragment Offset = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time = 123 | Protocol = 6 | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt. Code = x | Opt. Len.= 3 | option value | Opt. Code = x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt. Len. = 4 | option value | Opt. Code = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt. Code = y | Opt. Len. = 3 | option value | Opt. Code = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | \ \ \ \ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 - インターネットデータグラムの例 APPENDIX 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10 - バイトの転送順番 オクテットが数値の量を表す場合、データグラムの最も左のビットが高位、あ るいは最上位ビットである。すなわち、ラベル 0 のビットが最上位ビットで ある。例えば、以下のデータグラムは 170 (10進) を表す。 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1 0 1 0 1 0 1 0| +-+-+-+-+-+-+-+-+ Figure 11 - ビットの意味 同様に、複数オクテットのフィールドが数値の量を表す場合、フィールド全体 の最も左のビットが最上位ビットである。複数オクテットの量が送信される時、 最上位オクテットが一番最初に送信される。 用語 1822 BBN Report 1822 "ホストと IMP の相互接続規約"。ホストと ARPANET 間のインタフェースの規約。 ARPANET リーダー ホスト-IMP インタフェースにおける ARPANET メッセージの制御情 報。 ARPANET メッセージ ARPANET におけるホストと IMP 間の転送単位。最大サイズは約 1012 オクテット (8096ビット) である。 ARPANET パケット ARPANET と IMP 間で内部的に使用される転送単位。最大サイズは 約 126 オクテット (1008 ビット) である。 宛先 インターネットヘッダフィールドの宛先アドレス。 DF フラグフィールドで運ばれる Don't Fragment ビット。 フラグ 様々な制御フラグを運ぶインターネットヘッダフィールド。 フラグメントオフセット このインターネットヘッダフィールドは、インターネットデータグ ラムのどこにフラグメントが属するかを示す。 GGP ルーティングや他のゲートウェイ機能を制御するために、主にゲー トウェイ間で使用されるゲートウェイツーゲートウェイプロトコル。 ヘッダ メッセージ、セグメント、データグラム、パケット、データブロッ クの開始の制御情報。 ICMP インターネットモジュールで実装されるインターネット制御メッセ ージプロトコル (ICMP: Internet Control Message Protocol)。 ICMP は、エラーを通知したりルーティングの提案を行うために、 ゲートウェイからホストやホスト間で使用される。 識別子 データグラムのフラグメントの組立を補助するために、送信者が割 り当てる識別値を運ぶインターネットヘッダフィールド。 IHL インターネットヘッダフィールドのインターネットヘッダ長(IHL: Internet Header Length) は、32 ビットワードで算出されるイン ターネットヘッダの長さである。 IMP ARPANET のパケット交換であるインターネットメッセージプロセッ サ (IMP: Interface Message Processor)。 インターネットアドレス ネットワークフィールドとローカルアドレスフィールドで構成され る、4 オクテット (32 ビット) の送信元/宛先アドレス。 インターネットデータグラム インターネットモジュールのペア間で交換されるデータの単位 (イ ンターネットヘッダを含む)。 インターネットフラグメント インターネットヘッダを持つインターネットデータグラムのデータ の一部。 ローカルアドレス ネットワーク内のホストのアドレス。インターネットローカルアド レスをネットワーク中のホストアドレスにマッピングすることは極 めて一般的であり、複数を一つにマッピングすることも可能である。 MF インターネットヘッダのフラグフィールドで運ばれる More- Fragments フラグ。 モジュール プロトコルや他の手続きの実装体、通常はソフトウェア。 more-fragments フラグ インターネットデータグラムがインターネットデータグラムの最後 を含むか否かを示すフラグで、インターネットヘッダのフラグフィ ールドで運ばれる。 NFB インターネットフラグメントのデータ部の中のフラグメントブロッ クの数。すなわち、データ部の長さは 8 オクテット単位で算出さ れる。 オクテット 8 ビットバイト オプション インターネットヘッダオプションフィールドは幾つかのオプション を含んでもよく、各々のオプションは複数オクテット長であっても よい。 パディング データが 32 ビット境界から開始されることを保証するために使用 されるインターネットヘッダパディングフィールド。パディングは 0 である。 プロトコル このドキュメントでは、インターネットヘッダの次の上位プロトコ ルの識別子。 残り インターネットアドレスのローカルアドレス部。 送信元 インターネットヘッダフィールドの送信元アドレス。 TCP 転送制御プロトコル (TCP: Transmission Control Protocol)。信 頼できる通信のホストツーホストプロトコル。 TCP セグメント TCP モジュール間で交換されるデータの単位 (TCP ヘッダを含む)。 TFTP 簡易ファイル転送プロトコル。(TFTP: Trivial File Transfer Protocol)。UDP 上に設けられた簡単なファイル転送プロトコル。 生存時間 このデータグラム存在してもよい時間の上位境界を示すインターネ ットヘッダフィールド。 TOS サービス種別。 全体長 インターネットヘッダフィールドの全体長は、インターネットヘッ ダとデータを含むオクテット単位のデータグラムの長さである。 TTL 生存時間 サービス種別 このインターネットデータグラムのサービスの種別 (品質) を示す インターネットヘッダフィールド。 UDP ユーザデータグラムプロトコル (UDP: User Datagram Protocol)。 トランザクション型アプリケーションのユーザレベルのプロトコル。 ユーザ インターネットプロトコルの利用者。これは、アプリケーションプ ログラムやゲートウェイプログラムといった、上位レベルのプロト コルモジュールである。 バージョン インターネットヘッダの形式を示すバージョンフィールド。 参照 [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.