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

12. Summary of changes required in IP and TCP (IP および TCP で必要な変更の概要)

12. Summary of changes required in IP and TCP (IP および TCP で必要な変更の概要)

本文書は、ECN のための IP ヘッダーの 2 ビットを規定しています。not-ECT コードポイントは、トランスポートプロトコルが CE コードポイントを無視することを示します。これは ECN コードポイントのデフォルト値です。ECT コードポイントは、トランスポートプロトコルが ECN に参加する意思があり、参加できることを示します。

ルーターは、エンドノードに輻輳を示すために CE コードポイントを設定します。パケットヘッダーの CE コードポイントをルーターがリセットしてはなりません。

TCP は ECN に対して 3 つの変更が必要です。セットアップフェーズと TCP ヘッダーの 2 つの新しいフラグです。ECN-Echo フラグは、データ受信者が CE パケットを受信したことをデータ送信者に通知するために使用されます。Congestion Window Reduced (CWR) フラグは、データ送信者が輻輳ウィンドウを削減したことをデータ受信者に通知するために使用されます。

ECN (明示的輻輳通知) を使用する場合、IP トンネル内で生成された輻輳表示がトンネル出口で失われないことが求められます。私たちは、IP トンネルを経由して転送されるフローが ECN を使用できるようにするために、カプセル化およびカプセル化解除中の ECN フィールド処理に対する IP プロトコルへの軽微な変更を規定しています。

トンネル内の ECN に対して 2 つのオプションが規定されています。

  1. 制限された機能オプション (limited-functionality option)。IP トンネル内で ECN を使用せず、外部ヘッダーの ECN フィールドを not-ECT に設定し、カプセル化解除時に内部ヘッダーを変更しません。

  2. 完全な機能オプション (full-functionality option)。内部ヘッダーの ECN フィールドに基づいて、外部ヘッダーの ECN フィールドを not-ECT または ECT コードポイントの 1 つに設定します。カプセル化解除時に、外部ヘッダーに CE コードポイントが設定されており、内部ヘッダーが ECT コードポイントの 1 つに設定されている場合、CE コードポイントを内部ヘッダーにコピーします。

IPsec トンネルの場合、本文書は IPsec トンネル内での ECN 使用のネゴシエーションを可能にするオプションの IPsec Security Association (SA) 属性、および SA でのトンネルモードで ECN が許可されているかどうかを示す Security Association Database のオプションフィールドも定義しています。ECN 使用のための IPsec トンネルに必要な変更は、IPsec アーキテクチャを定義し、その実装の特定の側面を指定する RFC 2401 [RFC2401] を変更します。新しい IPsec SA 属性は、[RFC2407] のセクション 4.5 ですでに定義されている属性を補完するものです。

本文書は、ECN をインターネットコミュニティの実験プロトコルとして定義した RFC 2481「A Proposal to add Explicit Congestion Notification (ECN) to IP」を廃止します。本セクションの残りの部分では、本文書とその前身との関係について説明します。

RFC 2481 には、ECN とカプセル化されたパケットの使用に関する簡単な議論が含まれており、当時 (1999 年 1 月) の IPsec 仕様では、フローが IPsec トンネルを通過する場合、安全に ECN を使用できないことが指摘されていました。RFC 2481 は、ECN と互換性を持たせるために IPsec トンネル仕様に対して行うことができる変更についても説明していました。

本文書はまた、RFC 2481 以降に完了した作業を統合しています。最初は IPsec トンネルへの変更の詳細な説明と、ECN のセキュリティへの影響に関する広範な議論です (現在は本文書のセクション 18 および 19 として含まれています)。2 番目は、IPsec トンネルの議論をすべての IP トンネルを含むように拡張することです。古い IP トンネルがフローの ECN 使用と互換性がないため、インターネットでの ECN の展開により、制限された機能オプションまたは完全な機能オプションを使用して、古い IP トンネルを ECN 互換バージョンに更新する強い圧力が生まれます。

本文書は、MPLS、GRE、L2TP、PPTP などの非 IP トンネルに ECN を含めることの問題には対処していません。MPLS に ECN サポートを追加することに関する初期の予備文書は進められませんでした。

RFC2481 以降の 3 番目の新しい作業は、再送パケットの ECN 手順の説明、つまり再送パケットに ECT コードポイントを設定すべきではないことです。この追加仕様の動機は、既存の TCP 接続に対するサービス拒否攻撃の可能な経路を排除することです。以前に展開されたいくつかの ECN 対応 TCP は、再送パケットに ECT コードポイントを設定しないという (新しい) 要件に準拠していない可能性があります。私たちは、これが実際に重大な問題を引き起こすとは考えていません。

本文書はまた、SYN パケットを使用した ECN ネゴシエーションの仕様をわずかに拡張しています。以前に展開されたいくつかの ECN 対応 TCP は、本文書で規定されている要件に準拠していない可能性がありますが、私たちは、これが TCP 実装の組み合わせを持つエンドポイントの TCP 接続のパフォーマンスまたは互換性の問題を引き起こすとは考えていません。

本文書には、ECN nonce の実装の一部として TCP が使用できる ECT(1) コードポイントの仕様も含まれています。