要約

  • IPv6 フローラベルは固定ヘッダー内の20ビットで、送信元・宛先アドレスと組み合わせれば、トランスポートポートを探さずに分類キーを作れる。
  • 同一フロー内での安定性とフロー間での分散は必要だが、一意性、認証、優先権、経路保証は与えない。
  • RFC 6437 の再設計を基礎に、RFC 6438 はトンネルの ECMP/LAG、RFC 7098 はサーバーファームの負荷分散を扱った。

一意でないからこそ決めるべきこと

フローラベルがゼロなら、パケットはラベル付けされていない。非ゼロなら、送信元は一つのフローに属するすべてのパケットへ同じ値を設定することが推奨される。多数のフローを見たときには、値が離散的な一様分布に近づき、予測しにくいことが望ましい。

生成方法は固定されていない。5タプルを20ビットへハッシュする方法や、送信元に最小限の状態を持たせて擬似乱数を割り当てる方法は例にすぎない。連番は分布と予測可能性の両面から推奨されない。

ここでいうフローは、必ずしもトランスポート接続と一対一ではない。ただし RFC 6437 は、無関係な接続やアプリケーションストリームを通常は別のフローにするよう勧めている。同じアドレス間の二つの同時フローが同じラベルを得れば、ラベルに基づく装置は両者へ同じ処理を行う。衝突は消えず、設計はそれを許容している。

非ゼロの値は途中で変えずに届くことが期待される。転送装置がゼロを補う機能も認められるが、設定可能で、初期状態では無効でなければならない。フローを最も理解しやすい送信元が値を置くことが優先される。

ポートが見えない場所で残るもの

負荷分散は、しばしばアドレスとトランスポートポートをハッシュする。しかし IPv6 では、非先頭フラグメントにポートが存在しなかったり、拡張ヘッダー列の先にあったり、暗号化によって読めなかったりする。フローラベルは固定ヘッダーの定位置にある。ポートやペイロードの意味を復元するのではなく、別の分類材料を提供する。

この性質が RFC 6438 のトンネル問題につながる。IP-in-IPv6 トンネルでは、多数の内側フローが同じ外側の送信元・宛先を共有しうる。外側アドレスだけを使う ECMP やリンク集約は、トラフィックを一つの経路へ偏らせる可能性がある。

送信側トンネル終端は、内側の2タプルまたは5タプルから外側ラベルを導き、内側フローの間はその値を保てる。中間ルーターは内側セッションを解析せず、異なるラベルをハッシュ材料にできる。衝突した二つのユーザーフローは同じ経路処理を受けるが、同一の通信になったわけではない。

RFC 7098 は、レイヤー3/4のサーバー負荷分散にも同じ考え方を示す。送信元アドレスとラベル、または宛先・送信元アドレスとラベルをセッションキーにできる。ステートレス装置はキーをハッシュし、一つのフローを同じサーバーへ送る。ステートフル装置はキーとサーバーの対応を保存する。ゼロラベルは従来のトランスポートヘッダー処理へ回せる。

ただし状態を保存しても、同じアドレスとラベルを再利用した新しいトランスポートセッションは、キーだけでは旧セッションと区別できない。維持されるのは処理の親和性であり、アプリケーションのライフサイクルではない。

RFC 3697 からの方向転換

RFC 6437 は RFC 3697 を置き換え、非ゼロ値、ステートレスな生成、均等な分布を強く促した。途中で非ゼロ値を変えない原則は保ちつつ、ゼロ値の代理設定だけを限定的に許した。

この変化は、ラベルに豊かな意味を持たせるより、単純で利用可能なハッシュ入力にする方向への転換と読める。これは RFC の仕組みに基づく編集上の解釈であり、現在の導入率を示す調査結果ではない。

今回の三資料には、ベンダー別対応、運用ネットワークの普及率、性能比較は含まれない。したがって、普遍的な非ゼロ化や処理性能の向上を断定することはできない。

出典