RFC: 791
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
September 1981
TABLE OF CONTENTS
序文
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
インターネットプロトコルは、パケット交換コンピュータ通信ネットワーク上で相互接続されたシステムで使用する為に設計されている。そのようななシステムは、"catenet" [1] と呼ばれている。インターネットプロトコルは、データグラムと呼ばれるデータのブロックの、送信元から宛先への送信を提供する。そこでは、送信元と宛先は固定長アドレスで識別されるホストである。インターネットプロトコルは、"小さいパケット (small packet)" ネットワークを通じて送信する際、もし必要ならば長いデータグラムの分割や組立も提供する。
インターネットプロトコルは、ネットワークの相互接続されたシステム上で、ビットのパッケージ (インターネットデータグラム) を送信元から宛先へ配送するのに必要な機能を提供する範囲に明確に限定している。エンドツーエンドのデータ信頼性やフロー制御、順序付け、ホストツーホストプロトコルに通常見られる他のサービスを増やすメカニズムは存在しない。インターネットプロトコルは、様々なタイプやサービス品質を提供するために、サポートするネットワークのサービス上で利用できる。
このプロトコルは、インターネット環境においてホストツーホストプロトコルによって呼び出される。このプロトコルは、インターネットデータグラムを次のゲートウェイか宛先ホストに運ぶ為に、自側ネットワークプロトコルを呼ぶ。
例えば、TCP モジュールはインターネットデータグラムのデータ部の TCP セグメント (TCP ヘッダと利用者データを含む) を取る為に、インターネットモジュールを呼ぶだろう。TCP モジュールは、アドレスとインターネットヘッダ中の他のパラメタを、呼び出し時のアーギュメントとしてインターネットモジュールに提供するだろう。そして、インターネットモジュールはインターネットデータグラムを生成し、インターネットデータグラムを送信する為に自側ネットワークインターフェースを呼ぶだろう。
ARPANET の場合、例えばインターネットモジュールは、IMP に転送する為の ARPANET メッセージを生成するインターネットデータグラムに、1822 リーダー [2] を追加する為に自側ネットモジュールを呼ぶ。ARPANET アドレスは、自側ネットワークインタフェースによってインターネットアドレスから抜き出され、ARPANET 内のあるホストのアドレスになるだろう。
インターネットプロトコルは、2 つの基本機能を実装する。それは、アドレス付け (addressing) と分割 (fragmentation) である。
インターネットモジュールは、インターネットデータグラムを宛先に転送するために、インターネットヘッダで運ばれたアドレスを使用する。転送時のパス選択は、ルーティングと呼ばれる。
インターネットモジュールは、"小さなパケット" ネットワークを通して転送する際、必要ならばインターネットデータグラムを分割したりや組立するために、インターネットヘッダ中のフィールドを使用する
処理のモデルでは、インターネットモジュールは、インターネット通信に携わる各々のホストや、ネットワークを相互接続する各々のゲートウェイに存在する。これらのモジュールは、アドレスフィールドやインターネットデータグラムの分割/組み立てを解釈する為に共通の規則を共有する。加えて、これらのモジュール (特にゲートウェイ) は、ルーティグを決定するための手続きやその他の機能を持つ。
インターネットプロトコルは、各々のインターネットデータグラムを、他のいかなるインターネットデータグラムとも関連性を持たない独立したエンティティとして扱う。コネクション、あるいは論理回線、仮想回線等は存在しない。
インターネットプロトコルは、そのサービスを提供する際、4 つのキーメカニズムを使用する。それは、サービスタイプ、生存時間、オプション、ヘッダチェックサムである。
サービスタイプは、望ましいサービスの品質を示すために使用される。サービスタイプは、インターネットを形成しているネットワークに提供されるサービスの選択を表す、抽象的で一般的なパラメタのセットである。このサービスタイプ指定は、ゲートウェイがインターネットデータグラムをルーティングする際に、ある特定のネットワークや次のホップ、次のゲートウェイに対して使用されるネットワークのための、実際の転送パラメタを選択するのに使用されるものである。
生存時間はインターネットデータグラムの生存期間の上限の指定である。それはデータグラムの送信者によって設定される、それが処理される経路上のポイントで減らされる。もしインターネットデータグラムがその宛先に到達する前に生存時間が 0 になったら、インターネットデータグラムは破棄される。生存時間は、自己破壊制限時間と考えられる。
オプションはある状況では必要で有用だが、大半の一般的な通信では不要である制御機能を提供する。オプションは、タイムスタンプや安全性、特殊なルーティングの提供を含む。
ヘッダチェックサムは、インターネットデータグラムを処理する際に使用される情報が正しく転送されたことを証明する方法を提供する。データは異常を含むかもしれない。もしヘッダチェックサムが異常ならば、インターネットデータグラムは異常を検出したエンティティによって即座に破棄される。
インターネットプロトコルは、信頼できる通信ファシリティを提供しない。エンドツーエンドかホップツーホップの肯定応答は存在しない。ヘッダチェックサムを除いて、データに対する異常制御は存在しない。再送も存在しない。フロー制御も存在しない。
検出された異常は、インターネット制御メッセージプロトコル (ICMP: Internet Control Message Protocol)[3] を経由して通知されるかもしれない。ICMP はインターネットプロトコルモジュールに実装される。
以下の図は、プロトコル階層の中のインターネットプロトコルの場所を表している。
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | | TFTP| ... | ... |
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | UDP | ... | ... |
+-----+ +-----+ +-----+
| | |
+--------------------------+----+
| Internet Protocol & ICMP |
+--------------------------+----+
|
+---------------------------+
| Local Network Protocol |
+---------------------------+
Protocol Relationships
Figure 1.
インターネットプロトコルは、一方で上位レベルホストツーホストプロトコルに、もう一方でローカルネットワークプロトコルにインタフェースする。このコンテキストでは、"ローカルネットワーク" とはビル内の小規模ネットワーク、あるいは ARPANET のような大規模なネットワークのことを言う。
データグラムを一方のアプリケーションプログラムから、もう一方のアプリケーションプログラムに送信する処理モデルを、以下のシナリオによって説明する。
ある中間ゲートウェイを経由する送信を想定する。
送信側アプリケーションプログラムはデータを準備し、そのデータをデータグラムとして送信するために自側のインターネットモジュールを呼び、宛先アドレスと他のパラメタを呼び出し時のアーギュメントとして渡す。
インターネットモジュールはデータグラムヘッダを準備し、それにデータを付ける。インターネットモジュールは、このインターネットアドレスのためのローカルネットワークアドレスを決定する。この場合、それはゲートウェイのアドレスである。
プログラムは、データグラムとローカルネットワークアドレスをローカルネットワークインタフェースに送信する。
ローカルネットワークインタフェースはローカルネットワークヘッダを生成し、データグラムをそれに付ける。そして、その結果として生成されたものをローカルネットワークを経由して送信する。
データグラムは、ローカルネットワークヘッダに包まれたゲートウェイホストに到着する。ローカルネットワークインターフェースはこのヘッダを取り除き、データグラムをインターネットモジュールに渡す。インターネットモジュールは、インターネットアドレスを見て、このデータグラムを 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
インターネットプロトコルの機能や目的は、ネットワークの相互接続されたセットを通じてデータグラムを移すことである。これは、宛先に到着するまで、あるインターネットモジュールから別のインターネットモジュールにデータグラムを渡すことによって行われる。インターネットモジュールは、インターネットシステムのホストやゲートウェイの中に在る。データグラムは、インターネットアドレスの解釈に基づく個々のネットワークを通じて、一方のインターネットモジュールからもう一方のインターネットモジュールへ届けられる。従って、インターネットプロトコルの 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 に再設定されているだろう。
ゲートウェイは、ネットワーク間でデータグラムを転送する為にインターネットプロトコルを実装する。ゲートウェイは、ルーティングや他のインターネット制御情報を調整する為にゲートウェイツーゲートウェイプロトコル (GGP) [7] も実装する。
ゲートウェイでは上位レベルのプロトコルを実装する必要はなく、GGP 機能は IP モジュールに追加される。
+-------------------------------+
| Internet Protocol & ICMP & GGP|
+-------------------------------+
| |
+---------------+ +---------------+
| Local Net | | Local Net |
+---------------+ +---------------+
Gateway Protocols
Figure 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 | |
| Bits 3 | 0 = Normal Delay | 1 = Low Delay |
| Bits 4 | 0 = Normal Throughput | 1 = High Throughput |
| Bits 5 | 0 = Normal Relibility | 1 = High Relibility |
| Bits 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 | Precedence | |
| 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: 可変
オプションはデータグラム中に表れてもよいし、表れなくてもよい。全ての 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 | 8 | 可変 | インターネットタイムスタンプ。 |
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 である。
プロトコルの実装は強固でなければならない。各々の実装は、別の人によって作成された他の実装と相互動作することを考慮しなければならない。この規約の目標はプロトコルに関して明確化することであるが、異なって解釈される可能性はある。一般的に、実装は送信動作においては慎重で、受信動作においては寛大でなければならない。すなわち、正しく形成されたデータグラムを送信するよう、注意深くなければならないが、解釈可能な如何なるデータグラムも受信できなければならない (意味することがまだはっきりしている技術的な異常は反対しない等)。
基本的なインターネットサービスはデータグラム型であり、ゲートウェイでデータグラムの分割を提供し、宛先ホストにある宛先インターネットプロトコルモジュールで組立する。もちろんネットワーク内、あるいはネットワークのゲートウェイ間の私的な同意によるデータグラムの分割と組立もまた許されている。なぜならば、これはインターネットプロトコルや上位レベルプロトコルに透過的であるから。この透過的な分割や組立のタイプは、"ネットワーク依存" (またはイントラネット) のフラグメント化と呼ばれ、ここではこれ以上論じない。
インターネットアドレスはホストレベルで送信元と宛先を区別し、プロトコルフィールドも提供する。各プロトコルは、ホスト内部で多重化必要なものは何でも提供するものと想定される。
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] に規定されている。
インターネット識別子フィールド (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 は含まない)。
次のネットワーク通じて送信できる最大長のデータグラムは、最大転送単位 (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) このフラグメントを分割テストに送る
上記の手続きでは、各々のフラグメントは (最後を除く) 許される最大長で作成される。上記の手続きとは別の方法では、データグラムの最大長以下で作成するかもしれない。例えば、フラグメントが最大転送単位のサイズ以下になるまで、大きいサイズのデータグラムを半分の単位に繰り返し分割するような分割化手続きを実装することもあり得る。
各々のデータグラムに対して、送信元、宛先、プロトコル、識別子フィールドの連結時にバッファ識別子が算出される。もしこれがデータグラム全体であれば (すなわち、フラグメントオフセットと 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]によって通知される。
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) や、内部プロセス間通信の他の形式を除外することは意味しない。
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 - インターネットデータグラムの例
このドキュメントに記述されているヘッダとデータの転送順番は、オクテットレベルで解決される。図がオクテットのグループを示す場合は、それらのオクテットの転送順番は英語を読むのと同じ通常の順番である。例えば、以下の図ではオクテットは番号付けされた順番で送信される。
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.