要約

  • RFC 9531はContent/Dataの復路でNexthop Labelを積み上げ、後続のInterestがそのPath Labelを提示して転送先を選べるようにする。
  • ラベルの先は生成者とは限らずキャッシュでもよい。インターフェースやFIBの変更で失効し、PIT集約やフォールバックで消費者の指定と実際の転送がずれることもある。
  • 重要な判断には、発見交換、ラベルの有効期間、応答主体、コンテンツ検証、測定条件、ローカル方針、実際の結果を結んだ記録が必要である。

最初のDataが戻ったとき、ネットワークは経路ラベルも返した。次のInterestに同じラベルを付けると、再びDataが届いた。運用画面だけを見れば、「同じ経路で同じ相手に到達した」と書きたくなる。

ところがRFCが証明するのは、そこまでではない。

RFC 9531は、CCNxとNDNのための実験的な経路発見・経路誘導を定義する。通常のInterestに対してContent/Dataが戻る際、転送ノードが復路でNexthop Labelを加える。消費者が完成したPath Labelを次のInterestに入れると、各ノードは最上位のラベルを読み、同時に名前の最長プレフィックス一致で得たFIBの候補と照合する。

したがって、ラベルはルーティングを無視して任意のポートを指定する命令ではない。現在のFIBが許す選択肢の中で、過去に実行された選択を試す仕組みである。文書の位置付けも重要だ。これはIRTF ICNRGのExperimental RFCであり、IETF製品でもInternet Standardでもない。

終点は生成者ではなくキャッシュかもしれない

RFC 9531の定義では、Path Labelは消費者から生成者、または要求項目を返せるforwarder cacheまでの経路を示す。両者は同じInterestを満たせるが、証拠上の主体は異なる。

RFC 8569のCCNxは、名前付きコンテンツを固定エンドポイントに結び付けず取得する。FIBはローカルアプリケーション、Content Store、遠隔システムのいずれも指し得る。オブジェクトの真正性や完全性は、署名、MAC、ハッシュ連鎖、弱い整合性検査、あるいは保護なしという別の仕組みで扱う。InterestはKeyIdやオブジェクトハッシュで応答を絞れるが、その鍵を名前空間に対して信頼できるかはさらに別の判断である。

Path Labelは、その検証を代行しない。原生成者か途中のキャッシュか、オブジェクトが新鮮か、署名鍵が妥当か、アプリケーションが受理したかを示さない。記録しているのは、一つの交換で組み立てられた転送文脈である。

経路特性はラベルではなく測定に宿る

この方式では、遅延、損失、帯域、管轄、信頼度といった属性が経路ラベルに明記されない。通常のデータ交換に発見を重ねるため、消費者は観測から特性を推定する。

用途は具体的だ。マルチパスの診断、連続パケットを同じ経路に載せる測定、マルチパス輻輳制御、汚染キャッシュを避ける試みが挙げられる。一方でRFCは、pingやtracerouteの精度がどれだけ上がるか、性能と堅牢性が改善するかを未解決の実験課題として残している。

同じラベルが見えたことと、同じ性能条件が続いたことは等しくない。性能をラベルへ結び付けるなら、測定期間、サンプル数、返されたData、応答主体、途中の状態変化を残さなければならない。

動作中のFIBが古いラベルを無効にする

インターフェースやFIBは変わる。発見時には有効だったNexthop Labelが、後には対象プレフィックスの候補に存在しないことがある。RFC 9531はinvalid path labelのInterestReturn/NACKを定義し、復路で情報を更新して、消費者が失効箇所を把握できるようにする。

FALLBACK_MODEを指定すれば、ノードはエラーの代わりに通常のFIB検索へ戻れる。Dataが届いてサービスは継続しても、指定経路を再現した証明にはならない。送信ラベルと返却ラベルを比較して初めて、逸脱を検出し古い状態を捨てられる。

「Data受信」を「経路再利用成功」と数えると、復旧機能が証明に化ける。正確な誘導とフォールバック成功は別の指標にしなければならない。

ラベル自体も長期IDとして設計されていない。Nexthop Labelは12ビットであり、総当たりの困難さには頼れない。RFCは少なくとも数分ごとの更新を推奨する。短命であることは欠点ではなく安全特性である。

PIT集約は指定を飲み込む

Pending Interest Tableは、Path Labelや発見モードが異なるInterestでも、条件が一致すれば集約し得る。どちらが先に到着したかで挙動が変わる。

発見用Interestが先なら、特定経路を望む後続Interestが集約され、その指定が無視される可能性がある。逆なら、新しい経路を探すInterestが既存状態へ吸収される。並列に複数経路を探したつもりでも、一つのDataが持つ一経路だけを共有する場合がある。管理ツールに一意の名前サフィックスを勧める理由はここにある。

記録すべきなのは、消費者が送った意図、forwarderが採用した状態、実際に戻ったDataの三つである。送信パケットにラベルがあったという事実だけでは、全ノードが従ったことにならない。

暗号化が守るのは転送構造

攻撃者がNexthop Labelを推測し、通常のルーティングが選ばない経路へInterestを誘導する脅威も検討されている。無効ラベルNACKのhop countは診断に役立つ反面、どの段で推測が外れたかを攻撃者へ教える。ラベル更新やhop countの無効化には、可観測性とのトレードオフがある。

RFC 9531は、各ノードが独自の非共有鍵で残りのスタックを暗号化し、現在使う最上位ラベルだけを見せる方式も示す。これは悪意ある誤誘導への防御である。

しかし、暗号化されたPath Labelが生成者を認証するわけではない。Content/Dataの署名検証でも、経路品質の認定でもない。転送トークンを守る暗号を、アプリケーション上の権威へ読み替えてはならない。

判断の根拠を一枚の受領書にする

まず発見交換を残す。消費者、Interestの名前と制約、発見モード、返ったData、検証結果、Path Labelの生バイト、時刻である。続いて保護方式、hop count、分かる範囲の更新期、無効NACK、フォールバック、返却ラベルの差、PIT集約の可能性を記録する。

次に応答主体を区別する。生成者、ローカルアプリ、Content Storeのどれか。どのKeyIdまたはハッシュを確認し、どの信頼規則で鍵と名前を結んだか。測定には手法、期間、母数を付ける。最後に方針の版、決定者、実行した措置、アプリケーション結果を加える。

これはHeng Luが示す現実の層を保つ。設定は実行ではない。ラベルを送ることはラベル通りに進んだことではない。戻った経路は恒久経路ではなく、恒久経路でも生成者IDにはならない。検証済みオブジェクトもアプリケーション判断を自動承認しない。running codeを優先するとは、実行された事実を残すことである。共通仕様を最小限に保てば、必要な証拠水準は各現場で決められる。

資料が示していないこと

閉じた資料群は、特定企業や通信事業者がRFC 9531を導入したとは示していない。採用率、本番性能、実インシデント、汚染キャッシュ回避の成功事例も含まれない。2017年の論文とRFCは設計と評価の基盤であり、製品ニュースの代用品ではない。

結論は限定的だからこそ使える。RFC 9531は、一度実行された転送文脈を消費者へ返し、次のInterestをより制御可能にする。その短期状態を身元、永続性、成果保証へ格上げしないことが、運用と経営の責任である。

情報源