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

3. The IPv4 ID Field (IPv4 IDフィールド)

IPはデータグラムのフラグメンテーションをサポートしており, 大きなデータグラムは, 最大伝送単位 (MTU) が制限されたリンクを通過するために, より小さな構成要素に分割されます。フラグメントはIPv4とIPv6で異なる方法で示されます:

  • IPv4では, フラグメントは基本ヘッダの4つのフィールド, つまりIdentification (ID), Fragment Offset, "Don't Fragment" (DF) フラグ, および "More Fragments" (MF) フラグを使用して示されます [RFC791]。
  • IPv6では, フラグメントは, IPv4の対応するものと同様のID, Fragment Offset, およびM (more fragments) フラグを含む拡張ヘッダで示されます [RFC2460]。

IPv6のフラグメンテーションは, いくつかの重要な点でIPv4のフラグメンテーションと異なります。IPv6のフラグメンテーションは送信元でのみ発生するため, 下流のデバイスがフラグメンテーションを開始するのを防ぐためにDFビットは必要ありません (つまり, IPv6は常にDF=1であるかのように動作します)。IPv6フラグメントヘッダは, データグラムがフラグメンテーションされた場合, または送信元が, パスが必要な最小1280バイトのIPv6 MTUをサポートできず, したがって変換の対象となることを示す "packet too big" ICMPv6エラーメッセージを受信した場合にのみ存在します [RFC2460] [RFC4443]。後者のケースは, IPv4への変換後の後続のフラグメンテーションをサポートするためにIPv4宛先に送信されるIPv6データグラムにのみ関連します。

これら2つのケースを除いて, IDフィールドはフラグメンテーションされていないデータグラムには存在しません。したがって, それはすでにフラグメンテーションされたデータグラム, またはIPv4変換の一部としてフラグメンテーションされることを意図したデータグラムに対してのみ意味を持ちます。最後に, IPv6 IDフィールドは32ビットであり, IPv6では送信元/宛先アドレスのペアごとに一意であることが要求されますが, IPv4ではわずか16ビットであり, 送信元アドレス/宛先アドレス/プロトコルのタプルごとに一意であることが要求されます。

本文書はIPv4 IDフィールドの問題に焦点を当てます。なぜなら, IPv6ではフィールドがより大きく, フラグメントにのみ存在するからです。

3.1. Uses of the IPv4 ID Field (IPv4 IDフィールドの用途)​

IPv4 IDフィールドはもともとフラグメンテーションと再組み立てを目的としていました [RFC791]。特定の送信元アドレス, 宛先アドレス, およびプロトコル内では, 元のデータグラムのフラグメントは, それらのIPv4 IDに基づいて照合されます。これは, フラグメンテーションが可能な場合 (例えば, DF=0), またはすでに発生している場合 (例えば, frag_offset>0 または MF=1) に, IDが送信元アドレス/宛先アドレス/プロトコルのタプル内で一意であることを必要とします。

IPv4 IDフィールドには他の用途も想定されてきました。このフィールドは, 例えば輻輳したルータ ([RFC1122] のセクション3.2.1.5に記載) やネットワークアクセラレータにおいて, 重複したデータグラムを検出および除去する方法として提案されてきました。同様に, エンドホストで, 重複が上位層プロトコルに与える影響 (例えば, TCPでの追加処理, またはUDPでのアプリケーション層の重複抑制の必要性) を軽減するために使用することも提案されています。これについてはセクション5.1でさらに論じます。

IPv4 IDフィールドは, 一部の診断ツールで, ネットワークパスに沿ったさまざまな場所で測定されたデータグラムを関連付けるために使用されています。IPv6では, フラグメンテーションされていないデータグラムにはIDがないため, これはすでに不十分であり, したがってこれらのツールは, IDフィールドへのそのような依存を避けるためにすでに更新されつつあります。これについてもセクション5.1でさらに論じます。

IDは, フラグメンテーションと再組み立てをサポートするために (MDL内で, 送信元アドレス/宛先アドレス/プロトコルのタプル内で) 一意である必要があることは明らかですが, すべてのデータグラムがフラグメンテーションされるわけでも, フラグメンテーションを許可するわけでもありません。本文書はフラグメンテーション以外の用途を非推奨とし, それらのケースでは (MDL内で, 送信元アドレス/宛先アドレス/プロトコルのタプル内で) IDを繰り返すことを許可します。

3.2. Background on IPv4 ID Reassembly Issues (IPv4 ID再組み立て問題の背景)​

以下は, 以前に提起された [RFC4963], 高速環境におけるIPv4フラグメント再組み立ての問題の要約です。読者は, これらの問題のより詳細な議論のためにRFC 4963を参照することをお勧めします。

最大IPv4データグラムサイズが64 KBの場合, 120秒以内に繰り返されない16ビットのIDフィールドは, 2つのIPエンドポイント間の特定のプロトコルのすべてのTCP接続の合計がおよそ286 Mbpsに制限されることを意味します。より典型的な1500バイトのMTUでは, この速度は6.4 Mbpsに低下します [RFC791] [RFC1122] [RFC4963]。この制限は現在, フラグメンテーションが有効か抑制されているか, およびデータグラムがフラグメンテーションされているかどうかに関係なく, 2つのIPアドレス間の単一プロトコル (つまり, IPv4プロトコルフィールド) 内のすべてのIPv4データグラムに適用されます。

IPv6は, 典型的なMTUでも, より大きな32ビットのIDフィールドのおかげで (そして, IPv4プロトコルフィールドに相当するIPv6次ヘッダフィールドがフラグメントの区別において考慮されないという事実により), すべてのプロトコルにわたる合計として, 2つのIPエンドポイント間でフラグメンテーションを伴う18.7 Tbpsが可能です。フラグメンテーションが使用されない場合, フィールドは存在せず, その場合IPv6の速度はIDフィールドの一意性によって制限されません。

また, 120秒はMDLの推定値にすぎないことに注意してください。それは, 下限としての再組み立てタイムアウトと, 上限としてのTCP Maximum Segment Lifetimeに関連しています (いずれも [RFC1122] に記載されています)。ネットワーク遅延は他の方法でも発生します。例えば衛星リンクは, Time to Live (TTL) が対応する量だけデクリメントされなくても, 数秒の遅延を追加する可能性があります。したがって, 120秒より古いデータグラムが破棄されることを保証する強制メカニズムはありません。

ワイヤレスインターネットデバイスはしばしば54 Mbpsを超える速度で接続され, 1 Gbpsの有線リンクは数年前からデフォルトとなっています。多くのエンドツーエンドのトランスポートパスは輻輳によって制限されていますが, これらのデバイスはLAN上で100 Mbps以上のアプリケーション層スループット (例えば, ディスク間のファイル転送速度) を容易に達成し, 広域パス上のCommercial-Off-The-Shelf (COTS) システムによる多数のスループット実証が10年以上にわたってこれらの速度を示してきました。これは, IPv4 IDの一意性が長い間無意味であったことを強く示唆しています。