1. はじめに (Introduction)

ネットワーク層の観点から、フロー (flow) は、特定のソースから特定のユニキャスト、エニーキャスト、またはマルチキャスト宛先に送信されるパケットのシーケンスであり、ノードがフローとしてラベル付けすることを望むものです。上位層の観点から、フローは特定のトランスポート接続またはメディアストリームの一方向のすべてのパケットで構成される場合があります。ただし、フローは必ずしもトランスポート接続に1:1でマッピングされるわけではありません。

従来、フロー分類器は、送信元アドレス、宛先アドレス、送信元ポート、宛先ポート、およびトランスポートプロトコルタイプの5タプルに基づいていました。ただし、これらのフィールドの一部は、フラグメンテーションまたは暗号化のために使用できない場合があり、IPv6拡張ヘッダーのチェーンを超えてそれらを見つけることは非効率的である可能性があります。さらに、分類器がIPレイヤーヘッダーのみに依存する場合、代替トランスポート層プロトコルの後の導入が容易になります。

フローラベル (Flow Label)、送信元アドレス (Source Address)、および宛先アドレス (Destination Address) フィールドの3タプルの使用により、固定位置のIPv6メインヘッダーフィールドのみが使用される効率的なIPv6フロー分類が可能になります。

フローラベルは、ステートレスシナリオとステートフルシナリオの両方で使用できます。ステートレスシナリオとは、フローラベルを何らかの方法で処理するノードが、パケットが処理される前後にフローに関する情報を保存する必要がないシナリオです。ステートフルシナリオとは、フローラベル値を処理するノードが、フローラベル値を含むフローに関する情報を保存する必要があるシナリオです。ステートフルシナリオでは、フローラベルが特定の方法で使用されていることをダウンストリームノードに通知し、ネットワーク内にフロー状態を確立するためのシグナリングメカニズムも必要になる場合があります。たとえば、RSVP [RFC2205] およびGeneral Internet Signaling Transport (GIST) [RFC5971] は、フローラベル値をシグナリングできます。

フローラベルは、ステートレスシナリオで最も簡単に使用できます。この仕様は、ステートレスモデルとそれをデフォルトメカニズムとして使用する方法に焦点を当てています。ステートフルモデル、シグナリング、特定のフロー状態確立方法、およびそれらに関連するサービスモデルの詳細は、この仕様の範囲外です。ステートフルモデルの基本要件は、セクション4で説明されています。

IPv6フローサポートの最小レベルは、フローのラベリングで構成されます。特定の目標は、さまざまな形式のステートレス負荷分散、特にEqual Cost Multi-Path (ECMP) および/またはLink Aggregation Group (LAG) パス全体でのフローラベルの使用を有効にし、奨励することです。ECMPとLAGは、個々の物理リンクの帯域幅よりも大きい提供負荷を運ぶために必要な容量を調達するために使用される複数の物理リンクを結合する方法です。詳細については、別の文書 [RFC6438] を参照してください。IPv6ソースノードは、ノード自体がフロー固有の処理を必要としない場合でも、既知のフロー (例: TCP接続とアプリケーションストリーム) にラベルを付けることができる必要があります (SHOULD)。ステートレスフローラベリングのノード要件は、セクション3で示されています。

この文書は、[RFC3697] および [RFC2460] のセクション6と付録Aに取って代わります。変更の根拠は [RFC6436] に記録されています。この文書には、フローラベルに関する [RFC2205] への修正も含まれています。

この文書のキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、[RFC2119] に記載されているように解釈されるものとします。