5. Impact of Proposed Changes (提案された変更の影響)
このセクションでは, 提案された変更が, レガシーデバイス, 更新されたデバイスでのデータグラム生成, ミドルボックス, およびヘッダ圧縮に与える影響について論じます。
5.1. Impact on Legacy Internet Devices (レガシーインターネットデバイスへの影響)
IPv4 IDフィールドのレガシーな用途は, フラグメント生成, フラグメント再組み立て, 重複データグラム検出, および "その他の" 用途で構成されます。
現在のデバイスはすでに, 現在推定されているインターネットMDLである2分未満で, 送信元アドレス/宛先アドレス/プロトコルのタプル内で再利用されるID値を生成しています。それらは, エンドツーエンドパス上のMDLがはるかに低いと仮定しています。
既存のデバイスは, ほぼ10年間, アトミックデータグラムに対して変化しないIDを生成することが知られており, 特に一部の携帯電話がそうです。このような一定のID値は, ROHC [RFC5225] の最適化としてそれらがサポートされる理由です。これについてはセクション5.4でさらに論じます。一定の (ゼロ) IDを持つIPv4データグラムの生成は, IP/ICMP変換標準 [RFC6145] の一部としても記述されています。
現在の多くのデバイスは, IPv4 Don't Fragment (DF) ビットを無視するフラグメンテーションをサポートしています。そのようなデバイスはすでに, IDを再利用する送信元からのトラフィックを通過させています。同じID (送信元アドレス/宛先アドレス/プロトコルのタプル内) を再利用する異なるデータグラムのフラグメントが宛先にインターリーブされて到着した場合, フラグメンテーションは失敗し, トラフィックは破棄されるでしょう。再組み立てエラーの重大な発生は報告されていないため, そのようなインターリーブがまれであるか, そのようなデバイスからのトラフィックがこれらのDF無視デバイスを広く通過していないかのいずれかです。DF無視デバイスは既存の標準に準拠しておらず, それらを準拠として許可するように標準を更新することは現実的ではありません。
IDフィールドは, セクション4.1で論じたように, 重複検出での使用が想定されてきました。本文書は現在, アトミックデータグラムに対するIPv4 IDの再利用を許可していますが, そのような再利用はすでに一般的です (上記のように)。プロトコルアクセラレータはIPv4重複検出を実装することが知られていますが, そのようなデバイスは, より高いエンドツーエンドパフォーマンスを達成するために他のインターネット標準に違反することも知られています。これらのデバイスは, この現在のトラフィックに対してすでに誤ったドロップを示しているはずであり, これは報告されていません。
IDフィールドには, 診断目的など, 他の潜在的な用途があります。そのような用途は, IDフィールドが再利用されたアトミックデータグラムに対応する必要がすでにあります。そのような用途が, IDを再利用する現在のデータグラムで問題を抱えているという報告はありません。
したがって, 以前の要件の結果として, 本文書は, IPv4の重複検出および診断メカニズムがIPv6互換の方法, つまりIDフィールドに依存しない方法 (例えば, [RFC6621] で提案されているように) を適用することを推奨します。これは, IDフィールドを再組み立てのみに使用することの結果であり, また, 既存のデバイスがすでにIDフィールドを再利用しているという既知の危険性の結果でもあります。
5.2. Impact on Datagram Generation (データグラム生成への影響)
以下は, IPv4 IDフィールド仕様への以前の変更の結果としての推奨事項の要約です。
アトミックデータグラムは任意のIPv4 ID値を使用できるため, それらのケースではIDフィールドがパフォーマンスへの影響を課すことはなくなりました。しかし, 非アトミックデータグラムではパフォーマンスへの影響が残ります。その結果:
非アトミックIPv4データグラムの送信元は, IDの一意性要件に準拠するために, その出力をレート制限しなければなりません (MUST)。そのような送信元には, 特にUDP上のDNS [RFC2671] が含まれます。
MDLの厳密な定義がないため, IPv4 IDの再利用間隔や再組み立てタイムアウトに関係なく, 再組み立ての危険性が存在します。その結果:
上位層プロトコルは, IPv4データグラムの整合性を検証すべきです (SHOULD)。例えば, 再組み立てエラーを検出できるチェックサムまたはハッシュを使用します (UDPおよびTCPのチェックサムはこの点で弱いですが, 何もないよりはましです)。
追加の整合性チェックは, Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320], IPsec [RFC4301], またはStream Control Transmission Protocol (SCTP) [RFC4960] でサポートされているように, トンネルを使用して採用できます。そのようなチェックは, UDPおよびTCPのチェックサムを使用する場合 [RFC4963], またはUDP-Lite [RFC3828] のように部分チェックサムを使用する場合に発生しうる再組み立ての危険性を回避できます。そのような整合性チェックは再組み立てエラーの影響を回避できるため:
強力な整合性チェックを使用する非アトミックIPv4データグラムの送信元は, 典型的なMDL値より短い間隔でIDを再利用してもよい (MAY)。
ただし, そのような頻繁な再利用は, 上位層プロトコルに再組み立てエラーを伝播させることはないものの, 依然として再組み立ての破損と低いスループットをもたらす可能性があることに注意してください。
5.3. Impact on Middleboxes (ミドルボックスへの影響)
ミドルボックスには, ネットワークアドレス変換装置 (NAT), ネットワークアドレス/ポート変換装置 (NAPT), およびその他のアドレス共有メカニズム (ASM) などの書き換えデバイスが含まれます。また, アクセラレータやファイアウォールなど, ルータではないがデータグラムを検査およびフィルタリングするデバイスも含まれます。
本文書で提案された変更は, ミドルボックスによって実装されない可能性があります。しかし, これらの変更は, それらのデバイスが提供するサービスに影響を与えるよりも, 現在のミドルボックスの動作を準拠させる可能性が高いです。
5.3.1. Rewriting Middleboxes (書き換えミドルボックス)
NATおよびNAPTはIPフィールドを書き換え, トンネル入口 (IPv4カプセル化を使用) は一部のIPv4フィールドをコピーおよび変更します。したがって, これらはすべてデータグラム送信元と見なされ, 任意のデータグラムの送信元アドレス/宛先アドレス/プロトコル/IDのタプルの任意の部分を書き換えるデバイスも同様です [RFC3022]。これは, IPv4 Residual Deployment (4rd) [De11], IVI [RFC6219], および "A+P" (address plus port) ファミリ [Bo11] のその他のものを含む他のASMにも当てはまります。これは他のデータグラム書き換えメカニズムにも同様に当てはまります。その結果, 指摘されているように, それらは任意のデータグラム送信元のすべての要件の対象となります。
NAT/ASM/書き換え装置は, フラグメンテーションにとって特に困難な状況をもたらします。それらは両方向で再組み立てタプルの一部を上書きするため, タプルの一意性を破壊し, 再組み立ての危険性をもたらす可能性があります。IPv4の送信元アドレス, 宛先アドレス, またはプロトコルフィールドが変更されるたびに, NAT/ASM/書き換え装置は, 受信データグラムから単にコピーするのではなく, IDフィールドが適切に生成されることを保証する必要があります。
具体的には:
アドレス共有または書き換えデバイスは, アドレスまたはプロトコルが変換されるデータグラムのIPv4 IDフィールドが, あたかもそのデータグラムがそのデバイスから送信されたかのように, これらの要件に準拠することを保証しなければなりません (MUST)。
この準拠は, NAT/ASM/書き換え装置で変換される非アトミックデータグラムのIPv4 IDフィールドが, 任意のIPv4データグラム送信元の一意性要件に従う必要があることを意味します。残念ながら, 変換されたフラグメントは, 特定の送信元アドレス/宛先アドレス/プロトコルのタプルに対してMDL内でIPv4 IDを繰り返すため, すでにその要件に違反しています。
NAT/ASM/書き換え装置を通じてフラグメントを送信する際のこのような問題はすでに知られています。変換は通常, そもそも最初のフラグメントにのみ存在するトランスポートポート番号に基づいています [RFC3022]。本文書は, 変換には再組み立て (および場合によっては後続のフラグメンテーション) が必要なだけでなく, それがIPv4 IDの一意性に関する問題を回避するために使用できるという点を強調します。
NAT/ASMは, パブリック側でデータグラムを送信する際にすでに特別な注意を払う必要があることに注意してください。なぜなら, 多数の送信元からのデータグラムを単一の送信元アドレスにマージすると, IPv4 IDの衝突が発生する可能性があるからです。この状況は本文書より前から存在し, 本文書の影響を受けません。それは大規模な, いわゆる "carrier grade" NAT [Pe11] において悪化します。
トンネル入口は最も外側のヘッダの送信元として機能しますが, トンネルは内側のヘッダ (つまり, トンネル入口に到着したときのデータグラム) に対してルータとして機能します。入口は, 外側のヘッダの発信元として常にフラグメンテーションできます。なぜなら, それらはそのIPv4 IDフィールドの一意性と外側のヘッダのDFの値を, 内側の (到着したデータグラムの) ヘッダ上のそれらの値とは独立に制御するからです。
5.3.2. Filtering Middleboxes (フィルタリングミドルボックス)
ミドルボックスにはまた, ネットワークアクセラレータやファイアウォールなど, データグラムをフィルタリングするデバイスも含まれます。そのようないくつかのデバイスは, 重複を識別するためにIP IDの一意性に依存するデータグラムの重複排除を備えていると報告されており, これについてはセクション5.1で論じました。
5.4. Impact on Header Compression (ヘッダ圧縮への影響)
ヘッダ圧縮アルゴリズムはすでに, 連続するデータグラム間でIPv4 IDが変化するさまざまな方法に対応しています [RFC1144] [RFC2508] [RFC3545] [RFC5225]。そのようなアルゴリズムは現在, IPv4 IDがエンドツーエンドで保存されると仮定しています。一部のアルゴリズムは, IDが変化しないという仮定をすでに許可しており (例えば, ROHC [RFC5225]), 他のものはゼロデルタを介して変化しないIDを含めます (例えば, Enhanced Compressed RTP (ECRTP) [RFC3545])。
圧縮がデフォルトとして変化するIDを仮定する場合, 変化しないIDを持つと圧縮の効率が低下する可能性があります。そのような変化しないIDは, さまざまなRFCで記述されています (例えば, [RFC1144] の脚注21およびcRTP [RFC2508])。圧縮が変化しないIPv4 IDを仮定できる場合 -- ROHCやECRTPのように -- 効率を高めることができます。
5.5. Impact of Network Reordering and Loss (ネットワークの並べ替えと損失の影響)
ネットワークの並べ替えと損失に対する耐性は, インターネットアーキテクチャの重要な特徴です。現在のほとんどのIPネットワークはそのような不要なイベントを避けていますが, 並べ替えと損失の両方が発生する可能性があり, 実際に発生します。データグラムはすでに並べ替えられるか失われることが意図されており, それらのエラーからの回復 (サポートされている場合) はすでにトランスポート層またはより上位のプロトコル層で行われます。
並べ替えは通常, ルーティングの過渡状態, またはフローが複数のパスに分割される場合に関連します。損失は通常, パスの輻輳またはリンク障害 (部分的または完全) に関連します。そのようなイベントの影響は, アトミックデータグラムと非アトミックデータグラムで異なり, 以下で論じます。要約すると, 本文書の推奨事項は, 非アトミックデータグラムに対するIDの一意性の要件を強調し, これらの要件が両方のエンドポイントとデータグラム中継デバイスに与える影響をより明確に示すことにより, インターネットを並べ替えと損失に対してより堅牢にします。
5.5.1. Atomic Datagrams Experiencing Reordering or Loss (並べ替えまたは損失が発生するアトミックデータグラム)
DFビットが正しく尊重される場合, 順序の復元はデータグラムヘッダに依存しないため, ID値の再利用はアトミックデータグラムに影響しません。TCPはトランスポートヘッダのシーケンス番号を使用し, 他のいくつかのプロトコルでは, シーケンスはアプリケーション層で示され, 復元されます。
DF=1が無視される場合, 並べ替えまたは損失によって異なるデータグラムのフラグメントがインターリーブされ, その結果, 誤って再組み立てされて破棄される可能性があります。本文書で許可されているようにアトミックデータグラムでID値を再利用すると, そのような場合にデータグラムの損失が増加する可能性があります。アトミックデータグラムに一定のIDを使用する既知のデバイス (一部の携帯電話) があり, DF=1を無視する既知のデバイスもあるため, このような状況はすでに存在する可能性がありますが, 対応する高い損失は報告されていません。そのような報告がないことは, そのような場合に並べ替えや損失がないか, 結果として生じる損失に対する耐性があるかのいずれかを示しています。そのような問題が報告された場合, (DF=1を無視する) 非準拠デバイスに対処する方がより生産的です。なぜなら, それらの仕様を無視するデバイスを許容するようにインターネット仕様を定義することは非現実的であるからです。これが, 本文書がDF=1を尊重する必要性を強調する理由であり, またデータグラム中継デバイスが受信したままのDFビットを保持する (つまり, クリアするのではなく) 必要がある理由でもあります。
5.5.2. Non-atomic Datagrams Experiencing Reordering or Loss (並べ替えまたは損失が発生する非アトミックデータグラム)
非アトミックデータグラムは, フラグメントの並べ替えに耐えるためにID値の一意性に依存しており, 特にそのような並べ替えの結果として異なるデータグラムのフラグメントがインターリーブされる場合にそうです。フラグメントの損失は, 異なる元のデータグラムからのフラグメントの再組み立てをもたらす可能性があり, これが, 非アトミックデータグラムでのIDの再利用が, 予想される並べ替えのインターリーブだけでなく, データグラム (フラグメント) の最大生存時間に基づいている理由です。
本文書は, 非アトミックデータグラムにおけるIDの一意性の要件を変更しないため, そのような並べ替えや損失に対するそれらの耐性に影響しません。本文書は, 書き換えミドルボックスを含むすべてのデータグラム送信元に対するIDの一意性の必要性, IDの一意性を確保するために送信元をレート制限する必要性, 再送信されるデータグラムに対してIDを再利用しない必要性, および再組み立てエラーを防ぐために上位層の整合性チェックを使用する必要性を強調します -- これらはすべて, 並べ替えや損失イベントに対するより高い耐性をもたらします。