3. 仕様 (Specification)
この章では、ヘッダ形式、詳細なフィールド説明、運用手順、およびインターフェース定義を含む、インターネットプロトコル (Internet Protocol, IP) の完全な仕様を提供します。
3.1. インターネットヘッダ形式 (Internet Header Format)
インターネットヘッダの内容の要約は次のとおりです:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
インターネットデータグラムヘッダの例 (図4)
各目盛りは1ビット位置を表すことに注意してください。
フィールド説明
Version (バージョン): 4ビット
Versionフィールドは、インターネットヘッダの形式を示します。本ドキュメントはバージョン4について説明します。
IHL (Internet Header Length, インターネットヘッダ長): 4ビット
インターネットヘッダ長は、32ビットワード単位のインターネットヘッダの長さであり、したがってデータの開始位置を示します。正しいヘッダの最小値は5であることに注意してください。
Type of Service (サービスタイプ): 8ビット
サービスタイプは、希望するサービス品質の抽象的なパラメータを示します。これらのパラメータは、特定のネットワークを通じてデータグラムを送信する際に、実際のサービスパラメータの選択をガイドするために使用されます。
ビット0-2: 優先度 (Precedence)
ビット 3: 0 = 通常の遅延 (Normal Delay), 1 = 低遅延 (Low Delay)
ビット 4: 0 = 通常のスループット, 1 = 高スループット
ビット 5: 0 = 通常の信頼性, 1 = 高信頼性
ビット6-7: 将来の使用のために予約
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | |
| PRECEDENCE | D | T | R | 0 | 0 |
| | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
優先度の値 (Precedence Values):
- 111 - ネットワーク制御 (Network Control)
- 110 - インターネットワーク制御 (Internetwork Control)
- 101 - CRITIC/ECP
- 100 - Flash Override
- 011 - Flash
- 010 - Immediate
- 001 - Priority
- 000 - Routine
Total Length (総長): 16ビット
総長は、インターネットヘッダとデータを含む、オクテット単位で測定されるデータグラムの長さです。このフィールドにより、データグラムの長さは最大65,535オクテットまで可能です。すべてのホストは、最大576オクテットまでのデータグラムを受け入れる準備をしなければなりません (must)。宛先が大きなデータグラムを受け入れる準備ができているという保証がある場合にのみ、ホストは576オクテットを超えるデータグラムを送信することが推奨されます (recommended)。
Identification (識別): 16ビット
データグラムのフラグメントの再構築を支援するために送信者によって割り当てられる識別値です。
Flags (フラグ): 3ビット
さまざまな制御フラグです。
- ビット0: 予約済み、ゼロでなければならない (must)
- ビット1: (DF) 0 = 分割可 (May Fragment), 1 = 分割禁止 (Don't Fragment)
- ビット2: (MF) 0 = 最後のフラグメント, 1 = さらにフラグメントあり
Fragment Offset (フラグメントオフセット): 13ビット
このフィールドは、データグラム内でこのフラグメントが属する位置を示します。フラグメントオフセットは、8オクテット (64ビット) 単位で測定されます。最初のフラグメントのオフセットはゼロです。
Time to Live (生存時間): 8ビット
このフィールドは、データグラムがインターネットシステム内に留まることが許可される最大時間を示します。このフィールドがゼロの値を含む場合、データグラムは破棄されなければなりません (must)。このフィールドは、インターネットヘッダ処理で変更されます。時間は秒単位で測定されますが、データグラムを処理するすべてのモジュールは、1秒未満でデータグラムを処理する場合でも、TTLを少なくとも1減少させなければならない (must) ため、TTLはデータグラムが存在する可能性がある (may) 時間の上限としてのみ考える必要があります (must)。
Protocol (プロトコル): 8ビット
このフィールドは、インターネットデータグラムのデータ部分で使用される次のレベルのプロトコルを示します。さまざまなプロトコルの値は「Assigned Numbers」[9]で指定されています。
一般的な値:
- 1 = ICMP
- 6 = TCP
- 17 = UDP
Header Checksum (ヘッダチェックサム): 16ビット
ヘッダのみのチェックサムです。一部のヘッダフィールド (例: 生存時間) が変更されるため、インターネットヘッダが処理される各ポイントで再計算および検証されます。
チェックサムアルゴリズムは次のとおりです: チェックサムフィールドは、ヘッダ内のすべての16ビットワードの1の補数和の16ビット1の補数です。チェックサムを計算する目的で、チェックサムフィールドの値はゼロです。
Source Address (送信元アドレス): 32ビット
送信元アドレスです。
Destination Address (宛先アドレス): 32ビット
宛先アドレスです。
Options (オプション): 可変長
オプションは、データグラムに表示される場合もされない場合もあります (may)。すべてのIPモジュール (ホストとゲートウェイ) によって実装されなければなりません (must)。オプションであるのは、特定のデータグラムでの送信であり、実装ではありません。
3.2. 考察 (Discussion)
アドレッシング (Addressing)
ネットワークへのアドレス割り当ての柔軟性を提供し、小規模から中規模の多数のネットワークを可能にするために、アドレスフィールドの解釈は、少数のホストが多数のホストを持つネットワーク、適度な数のホストを持つ適度な数のネットワーク、および少数のホストを持つ多数のネットワークを指定するようにコード化されています。
アドレス形式:
|| 上位ビット | 形式 | クラス | ||------------|------|--------| || 0 | 7ビットのネットワーク、24ビットのホスト | a | || 10 | 14ビットのネットワーク、16ビットのホスト | b | || 110 | 21ビットのネットワーク、8ビットのホスト | c | || 111 | 拡張アドレッシングモードへのエスケープ | - |
分割と再構築 (Fragmentation and Reassembly)
インターネット識別フィールド (ID) は、送信元アドレスと宛先アドレス、およびプロトコルフィールドとともに、再構築のためにデータグラムフラグメントを識別するために使用されます。
More Fragmentsフラグビット (MF) は、データグラムが最後のフラグメントでない場合に設定されます。Fragment Offsetフィールドは、元の分割されていないデータグラムの先頭に対する相対的なフラグメントの位置を識別します。フラグメントは8オクテット単位でカウントされます。
すべてのインターネットモジュールは、さらなる分割なしで68オクテットのデータグラムを転送できなければなりません (must)。これは、インターネットヘッダが最大60オクテットまで可能であり、最小フラグメントが8オクテットであるためです。
すべてのインターネット宛先は、1つのピースまたは再構築されるフラグメントのいずれかで、576オクテットのデータグラムを受信できなければなりません (must)。
3.3. インターフェース (Interfaces)
IPへのユーザーインターフェースの機能的説明は、せいぜい架空のものです。なぜなら、すべてのオペレーティングシステムが異なる機能を持つからです。ただし、すべてのIPは、すべてのIP実装が同じプロトコル階層をサポートできることを保証するために、最小限のサービスセットを提供しなければなりません (must)。
上位レベルインターフェースの例
次の2つの例の呼び出しは、ユーザーからインターネットプロトコルモジュールへの通信の要件を満たします (「=>」は戻り値を意味します):
SEND (送信)
SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)
ここで:
- src = 送信元アドレス
- dst = 宛先アドレス
- prot = プロトコル
- TOS = サービスタイプ
- TTL = 生存時間
- BufPTR = バッファポインタ
- len = バッファの長さ
- Id = 識別子
- DF = 分割禁止 (Don't Fragment)
- opt = オプションデータ
- result = 応答
- OK = データグラム送信成功
- Error = 引数エラーまたはローカルネットワークエラー
RECV (受信)
RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)
ここで:
- BufPTR = バッファポインタ
- prot = プロトコル
- result = 応答
- OK = データグラム受信成功
- Error = 引数エラー
- len = バッファの長さ
- src = 送信元アドレス
- dst = 宛先アドレス
- TOS = サービスタイプ
- opt = オプションデータ
まとめ (Summary)
この仕様は、インターネットプロトコルバージョン4 (IPv4) を定義し、次のものを提供します:
- コネクションレスデータグラム配送
- ベストエフォートサービス (信頼性の保証なし)
- 分割と再構築 機能
- アドレッシング 最大2^32ホスト向け
- ルーティング 相互接続されたネットワークを通じた
- サービスタイプ の指示
- 生存時間 管理
- オプション 特別な処理のための
このプロトコルは、シンプルでスケーラブルかつ柔軟に設計されており、インターネットが多様なアプリケーションとネットワーク技術をサポートできるようにします (can)。
すべてのIPオプション、分割手順、再構築アルゴリズム、および実装要件の完全な詳細については、RFC 791の全文を参照してください。
注記: これはRFC 791セクション3の簡約版です。詳細なオプション形式、分割/再構築の擬似コード、およびすべてのエッジケースを含む完全な仕様については、公式のRFC 791ドキュメントを参照してください。