メインコンテンツまでスキップ

1. はじめに

IPv4では、識別(ID)フィールドはデータグラムのフラグメンテーションと再構成をサポートするための16ビット値です。現在の仕様によると、IDフィールドは、同じ送信元アドレス、宛先アドレス、プロトコルを持つデータグラムに対して、最大セグメント生存時間(MSL)内で一意である必要があります。しかし、現在の実装はこの仕様に厳密に従っておらず、データグラムがフラグメント化されるかどうかに関係なく、各データグラムの一意の識別子としてIDフィールドを扱っています。

IPv4では、トランスポート層およびそれ以上のプロトコルは、TCPシーケンス番号やUDPチェックサムなど、通常16ビットまたは32ビットのフィールドを使用して重複データグラムを検出します。しかし、IPv4のIDフィールドは16ビットしかないため、高速ネットワーク環境では、IDフィールドが短時間で枯渇し、新しいデータグラムに一意のID値を割り当てることができなくなる可能性があります。

IPv6では、フラグメンテーションはソースノードによってのみ実行され、フラグメントヘッダーには32ビットの識別フィールドが含まれています。IPv6仕様では、この識別フィールドは、データグラムがフラグメント化される場合にのみ一意である必要があることが明確に述べられています。対照的に、IPv4のIDフィールドは、フラグメント化されているかどうかに関係なく、すべてのデータグラムに存在します。

本文書は、RFC 791、RFC 1122、およびRFC 2003のIPv4 IDフィールドの仕様を更新し、現在の実践に近づけ、IPv6の処理方法と一致させます。具体的には、本文書は以下の点を明確にします：

  1. アトミックデータグラム: DFフラグ(Don't Fragment)が設定されているデータグラムの場合、IDフィールドは任意の値に設定でき、受信者はフィールドの値を無視する必要があります。

  2. 非アトミックデータグラム: DFフラグが設定されていないデータグラムの場合、IDフィールドは再構成タイムアウト期間中に一意である必要があり、フラグメントの正しい再構成を保証します。

  3. 互換性: 本文書は、これらの変更が既存のデバイスとプロトコルに与える影響について議論し、移行期間の推奨事項を提供します。

ナビゲーション:

に最終更新