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

6. Updates to Existing Standards (既存標準の更新)

以下のセクションでは, 本文書によって示される既存のプロトコルへの具体的な変更について述べます。

6.1. Updates to RFC 791 (RFC 791の更新)​

RFC 791は次のように述べています:

インターネットデータグラムの発信元プロトコルモジュールは, identificationフィールドを, そのデータグラムがインターネットシステム内でアクティブである間, その送信元-宛先ペアおよびプロトコルに対して一意でなければならない値に設定します。

その後, 次のように述べています:

したがって, 送信者は, データグラム (またはそのいずれかのフラグメント) がインターネット内で生存しうる間, この送信元, 宛先ペアおよびプロトコルに対して一意となるようにIdentifierを選択しなければなりません。

その場合, 送信プロトコルモジュールは, インターネットの最後の最大データグラム生存時間内に通信した各宛先に対して1つのエントリを持つIdentifierのテーブルを保持する必要があるように思われます。

しかし, Identifierフィールドは65,536の異なる値を許容するため, 一部のホストは宛先に依存しない一意の識別子を単純に使用できる場合があります。

一部の上位レベルプロトコルが識別子を選択することが適切です。例えば, TCPプロトコルモジュールは同一のTCPセグメントを再送信することがあり, 再送信が元の送信と同じ識別子を運ぶ場合, どちらのデータグラムのフラグメントも正しいTCPセグメントを構築するために使用できるため, 正しい受信の確率が高まります。

本文書はRFC 791を次のように変更します:

  • IPv4 IDの一意性は非アトミックデータグラムにのみ適用されます。
  • 再送信される非アトミックIPv4データグラムは, ID値を再利用することがもはや許可されません。

6.2. Updates to RFC 1122 (RFC 1122の更新)​

RFC 1122はセクション3.2.1.5 ("Identification: RFC 791 Section 3.2") で次のように述べています:

以前のデータグラムの同一のコピーを送信する場合, ホストはオプションでコピー内に同じIdentificationフィールドを保持してもよい (MAY)。

DISCUSSION:

一部のインターネットプロトコルの専門家は, ホストが以前のデータグラムの同一のコピーを送信するとき, 新しいコピーは元のものと同じIdentification値を含むべきであると主張してきました。2つの利点が提案されています: (1) データグラムがフラグメンテーションされ, 一部のフラグメントが失われた場合, 受信者は元のものとコピーのフラグメントから完全なデータグラムを再構築できる可能性があります。(2) 輻輳したゲートウェイが, IP Identificationフィールド (およびFragment Offset) を使用して, キューから重複データグラムを破棄する可能性があります。

本文書はRFC 1122を次のように変更します:

  • IPv4 IDフィールドは, 重複検出に使用することがもはや許可されません。これはアトミックデータグラムと非アトミックデータグラムの両方に適用されます。
  • 再送信される非アトミックIPv4データグラムは, ID値を再利用することがもはや許可されません。

6.3. Updates to RFC 2003 (RFC 2003の更新)​

本文書は, IPv4-in-IPv4トンネルがIPv4外側ヘッダのIPv4 ID値を生成する方法を更新します [RFC2003] が, それは他の任意のIPv4データグラム送信元とまったく同じ方法に限られます。具体的には, RFC 2003は次のように述べており, ここで [10] はRFC 791を指します:

Identification, Flags, Fragment Offset

これらの3つのフィールドは, [10] で規定されているように設定されます...

本文書はRFC 2003を次のように変更します:

  • IPv4 IDフィールドは, RFC 6864で許可されているように設定されます。