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

4. Updates to the IPv4 ID Specification (IPv4 ID仕様の更新)

本文書は, 以降のサブセクションで論じるように, 3つの異なる方法でIPv4 IDフィールドの仕様を更新します:

  • IPv4 IDフィールドをフラグメンテーションのみに使用する
  • IPv4 IDフィールドが使用される際に安全な動作を促す
  • IPv4 IDフィールドが使用される際のパフォーマンスへの影響を回避する

2種類のデータグラムがあり, 以下で定義され, 以降の議論で使用されます:

  • アトミックデータグラムとは, まだフラグメンテーションされておらず, それ以上のフラグメンテーションが抑制されているデータグラムです。
  • 非アトミックデータグラムとは, すでにフラグメンテーションされているか, またはフラグメンテーションが依然として可能なデータグラムです。

この同じ定義は, 一般的な論理演算子 (等しいは ==, 論理 'and' は &&, 論理 'or' は ||, より大きいは >, そして括弧関数が一般的に使用されます) を使用して, 次のように擬似コードで表現できます:

  • アトミックデータグラム: (DF==1)&&(MF==0)&&(frag_offset==0)
  • 非アトミックデータグラム: (DF==0)||(MF==1)||(frag_offset>0)

非アトミックデータグラムのテストは, アトミックデータグラムのテストの論理否定です。したがって, すべての可能性が考慮されます。

4.1. IPv4 ID Used Only for Fragmentation (フラグメンテーションのみに使用されるIPv4 ID)​

RFC 1122は, IPv4 IDフィールドがデータグラムの重複排除を含む他の用途を持つことを示唆していますが, そのような用途は, IDを変化させない送信元の既知の実装とはすでに相互運用できません。したがって本文書は, このフィールドの値をフラグメンテーションと再組み立てのみに対して定義します:

IPv4 IDフィールドは, フラグメンテーションと再組み立て以外の目的で使用してはなりません (MUST NOT)。

データグラムの重複排除は, IDフィールドが存在しない場合 (IPv6のフラグメンテーションされていないデータグラム) にはハッシュベースの重複検出を使用して依然として達成でき, これはIDフィールドを利用せずにIPv4のアトミックデータグラムにも適用できます [RFC6621]。

アトミックデータグラムでは, IPv4 IDフィールドは意味を持ちません。したがって, 任意の値に設定でき, つまり, 送信元アドレス/宛先アドレス/プロトコルのタプル内でIDを繰り返さないという要件は, アトミックデータグラムにはもはや要求されません:

送信元は, アトミックデータグラムのIPv4 IDフィールドを任意の値に設定してもよい (MAY)。

第二に, 中間ルータ, 宛先ホスト, またはその他のデバイス (例えば, NATおよびその他のアドレス共有メカニズム, ファイアウォール, トンネル出口) にあるかどうかにかかわらず, すべてのネットワークノードは, アトミックデータグラムのフィールドに依存できません:

IPv4ヘッダを検査するすべてのデバイスは, アトミックデータグラムのIPv4 IDフィールドを無視しなければなりません (MUST)。

したがって, IPv4 IDフィールドは非アトミックデータグラムに対してのみ意味を持ちます -- すでにフラグメンテーションされたデータグラム, またはフラグメンテーションが依然として許可されているデータグラムのいずれかです。アトミックデータグラムは, セクション4で説明するように, それらのDF, MF, およびフラグメンテーションオフセットフィールドによって検出されます。なぜなら, そのようなテストは完全に後方互換であるからです。したがって, 本文書は, 0を含め, いかなるIPv4 ID値も特別なものとして予約しません。

再組み立て以外の用途でのIPv4 IDフィールドの使用を非推奨にすることは, ほとんど -- もしあったとしても -- 影響を与えないはずです。IPv4 IDはすでに頻繁に繰り返されており, 例えば中程度に高速な接続でも, またIDをまったく変化させない一部の送信元からも繰り返されており, 悪影響は観察されていません。重複抑制が提案され [RFC1122], 一部のプロトコルアクセラレータに実装されていますが, これまでIPv4 IDの再利用の影響は指摘されていません。ルータは特定のタイムスケールでICMPを発行することを要求されていないため, IPv4 IDの繰り返しは検証目的で使用されるべきではありませんでした。このシナリオは観察されていません。さらに, 繰り返しはすでに発生しており, 気づかれていたはずです [RFC1812]。トンネル入口でのICMPリレーは, データグラムキャッシュではなくソフトステートを使用するように規定されています。同様の理由で, 後者が使用される場合, これも気づかれていたはずです [RFC2003]。これらのおよびその他のレガシーな問題については, セクション5.1でさらに論じます。

4.2. Encouraging Safe IPv4 ID Use (安全なIPv4 ID使用の促進)​

本文書はまた, IPv4 IDフィールドの安全な使用を促すために, その仕様を変更します。

RFC 1122で論じられているように, TCPがセグメントを再送信する場合, IPv4 IDを再利用することが可能な場合があります (セクション6.2を参照)。これは, 送信元が受信したフラグメントに対してIPv4 IDの繰り返しを避けることを困難にする可能性があります。RFC 1122は, この動作が "is not useful" であると結論付けています。本文書はその結論を次のように定式化します:

以前の非アトミックデータグラムのコピーを送信する際に, 非アトミックデータグラムのIPv4 IDを再利用してはなりません (MUST NOT)。

RFC 1122はまた, フラグメントが重複する可能性があることを示唆しています。このような重複は, 連続する再送信が異なる方法でフラグメンテーションされても, 同じ再組み立てIPv4 IDを持つ場合に発生する可能性があります。この重複は, データグラムを再送信する際にIPv4 IDを再利用した結果として指摘されており, 本文書はこれを非推奨とします。しかし, それはネットワーク内でのデータグラムの重複の結果でもあり, これは依然として発生する可能性があります。その結果, 本文書は, 受信者が重複するフラグメントをサポートする必要性を変更しません。

4.3. IPv4 ID Requirements That Persist (存続するIPv4 ID要件)​

本文書は, 非アトミックデータグラムに対する [RFC791] のIPv4 IDフィールドの一意性要件を緩和しません。つまり:

非アトミックデータグラムを送信する送信元は, 特定の送信元アドレス/宛先アドレス/プロトコルのタプルに対して, 1つのMDL内でIPv4 ID値を繰り返してはなりません (MUST NOT)。

そのような送信元には, 発信元ホスト, トンネル入口, およびNAT (その他のアドレス共有メカニズムを含む) が含まれます (セクション5.3を参照)。

本文書は, すべてのネットワークデバイスがDFビットを尊重するという要件を緩和しません。つまり:

DF=1のIPv4データグラムはフラグメンテーションしてはなりません (MUST NOT)。

IPv4データグラム中継デバイスは, DFビットをクリアしてはなりません (MUST NOT)。

具体的には, DF=1はアトミックデータグラムのフラグメンテーションを防ぎます。DF=1はまた, 受信したフラグメントのさらなるフラグメンテーションを防ぎます。ネットワーク内でのフラグメンテーションはDF=0の場合にのみ許可されます。本文書はその要件を変更しません。