要約

  • RFC 9631のCRH-16とCRH-32は実験的なIPv6 Routing Headerで、短いSIDはIPv6アドレス、トポロジー機能、任意の引数を持つローカル表の項目を指す。
  • SIDはノードローカルでもよい。同じ数値でも処理ノードやCRH-FIBの時点が違えば、別の宛先や機能として実行され得る。
  • 経路を主張するには、各ノードの表の版、設定経路、ACL/uRPF判定、宛先書換え、実際の出力、次ノードとアプリケーションの受領を結ぶ必要がある。

短い番号は変わっていなかった。一つ目のルーターでは最小コスト経路を選び、二つ目では特定インターフェースを強制した。どちらもRFCどおりにSIDを検索し、どちらも検索に成功した。

同じラベルを読めたことは、同じ意味を実行した証拠ではない。

RFC 9631が定義するCRH-16とCRH-32は、IPv6の送信元が経路を少ないバイトで指定するための実験である。圧縮によって意味がなくなるのではない。意味の一部がパケットからローカル状態へ移される。

SIDの意味は処理ノードに属する

SIDリストは逆順に置かれる。処理ノードはSegments Leftを減らし、その位置のSIDをCRH-FIBで引く。項目から得るのはIPv6アドレスだけではない。トポロジー機能と、必要ならその引数も得る。機能は最小コスト経路を選ぶことも、指定インターフェースから送ることもできる。

したがって、SIDは完全な経路命令ではなくローカルな検索キーである。RFCは、各SIDがドメイン全体で一意であることを要求しない。現在の宛先アドレスを持つ一台のCRH対応ルーターが、そのSIDを処理するからである。

あるノードの2と別のノードの2が同じ意味である保証はない。同じノードでも、CLI、PCEP、NETCONF、分散ルーティング更新の前後で意味が変わり得る。番号だけを保存しても、どの表が権限を持ったかは復元できない。

必要なのはノード識別、検索時刻、インストール済み表の版、項目、機能、引数、設定元である。パケットキャプチャは入力された番号を示す。ローカル状態の履歴が、その番号に与えられた行為を示す。

正しい形式は転送結果の一歩手前にある

処理規則は、実装が扱えない大きさのヘッダーを拒否する。Routing TypeとSegments Leftから最小長を計算し、不可能な長さ、存在しない項目、途中セグメントのマルチキャストアドレスを拒否する。規定された失敗ではICMPv6 Parameter Problemを送る。

これは重要な適合境界だが、経路の終点ではない。検索後、ノードは表のIPv6アドレスを宛先へコピーし、パケット、機能、引数をIPv6モジュールへ渡す。次ホップや出力インターフェースの決定、実際の送信はその後に起きる。

ICMPv6を見なかったことも成功の証明ではない。エラー自体が失われ、フィルターされ、レート制限されることがある。合法な項目が停止中のリンクを選ぶ場合もある。下流で落ちることも、宛先アプリケーションが使わないこともある。

検証、検索、宛先書換え、次ホップ、出力、下流観測、アプリケーション受領は別々に記録すべきだ。一つの「CRH正常」は、どこまで正常だったかを隠してしまう。

表を作った記録と表が動いた記録

CRH-FIBは、運用者のCLI、PCEPやNETCONFを使うコントローラー、または分散ルーティングプロトコルから供給できる。RFCはその仕組みを定義しない。単一の制御方式を強制しない代わりに、整合性は運用者の責任となる。

コントローラーの成功応答は、ASICへの書込み完了ではない。複数ノードは同時に収束しない。ロールバックがSIDだけを戻し、引数を戻さないこともある。新しい機能と古いパラメーターが一時的に組み合わさることもある。

パケットには表のepochがない。制御意図、候補設定、運用状態、データプレーンへの反映、パケット観測を同じ時系列へ置かなければならない。更新前後の正しいスナップショット二枚だけでは、その間の一個のパケットをどちらが処理したか分からない。

相互運用試験も構文で終われない。RFCが実験報告に求めるのは、実装間で機能と引数が揃い、その意味も同一かという問いである。短い番号を共通に読めても、動作が違えば経路は相互運用していない。

信頼は送信元欄から自動生成されない

RFC 9631では、同じ主体が運用するノード同士を信頼し、受信側は送信元アドレスからその関係を判断する。非信頼送信元からローカル宛に来たCRHはACLで捨てなければならない。

しかし送信元は偽装できる。EFP-uRPFは偽装の一部を除くが、すべてではない。さらに各エッジは、外部から入りながら信頼ノードのインターフェースを名乗るCRHを捨てる必要がある。

信頼判定の証拠は、入力インターフェース、送信元プレフィックス集合、ACLの版と配置、マッチした規則、カウンター、uRPFが参照した経路、処分結果から成る。送信元欄がそれらを代行することはない。

Authentication Headerとの互換性も、外部にある表の履歴を認証しない。AHは自身の鍵と処理文脈でパケットを保護できるが、正しいエッジにACLがあったことや実際の通過経路までは署名しない。

小さいことと速いことは別の測定である

CRHの動機には、ASICがヘッダーをバッファから限られたオンチップメモリーへコピーする費用と、Path MTU Discoveryが完全には信頼されず、多くのホストがIPv6の最小MTUである1280バイト付近を選ぶ現実がある。

これは測定すべき仮説である。効果はパーサー、ヘッダー深度、SID数、ペイロード、MTU、ICMPv6、ハードウェア世代、トラフィック構成で変わる。短い形式でもソフトウェアの遅い経路へ落ちたり、未対応ノードで止まったりする。

性能を語るには、比較基準、同じトラフィック、機器とソフトの版、パケット長分布、損失、遅延、カウンター定義が必要だ。16ビットは仕様値であり、性能向上は観測値である。

「実験的」は結論ではなく検証課題を示す

RFC 9631はStandards Trackではない。実験参加者に、展開負荷、段階導入か全体導入か、設定同期、ハード更新、SIDの範囲、セキュリティ負荷、性能、ACLの効果と費用、FIBの供給方法、規模、相互運用、OAMを報告するよう求めている。

ping、traceroute、tcpdump、WiresharkがCRHを扱えることは観測手段を増やす。しかし、機能の意味が一致したこと、境界が安全だったこと、アプリケーションに届いたことを自動で示さない。

解析器は解析を、表のダンプはその時点の状態を、出力キャプチャは一回の転送を、宛先は到着を証明する。経路の主張は、それらを結んだときだけ成立する。

情報源