要約

  • draft-ietf-pim-pfm-forwarding-enhancements-08では、未知のGSI Sub-TLVを無視して外側のGSI処理を続ける。さらに混在能力インターフェースではGSIをGSHへ変換し、グループ、ソース、holdtimeだけを残してSub-TLVを落とす。
  • Relaxed-RPFは並列リンクの複数送信を一つの実装依存選択へ減らすため、能力、解釈、変換、選択状態、初回受信、定期更新、転送結果を分離して記録しなければならない。

エラーのない意味欠落

新しいSub-TLVを追加したチームは、旧ソフトウェアがGSIそのものを拒否すると予想していた。実際の仕様は逆である。知らない型は無視し、同じGSIの既知部分と残りのSub-TLVを処理し続ける。

これは拡張可能なプロトコルに必要な寛容さだ。新機能が基本のソース発見を止めない。一方、運用画面が「GSI成功」だけを表示すれば、意味を理解したかどうかは見えない。成功したのは封筒の処理であって、中身すべての解釈ではない。

第08版は2026年8月25日に公開され、2027年2月26日に失効する。PIM WGの有効なInternet-Draftで、想定ステータスはExperimentalである。WG文書一覧ではRFC Editorキューに入り、編集担当待ちとされる。まだRFCでも、実装調査でも、相互接続試験でもない。

草案は、RFC 8364のPFMに二つの実験的拡張を加える。一つはフロー固有情報を持つGSI、もう一つは並列リンク上の重複処理を減らすRelaxed-RPFである。どちらも効率を高めるが、メッセージ数だけでは結果を説明できなくする。

GSHの共通核とGSIの追加意味

従来のGroup Source Holdtime TLVは、グループ、ソース、保持時間を運ぶ。新しいGroup Source Info TLVは一つの(S,G)に対応し、追加のフロー情報をSub-TLVとして含められる。

したがって、同じソース発見状態にも階層がある。共通核が生きていることと、追加属性が生きていることは別である。未知型を無視する規則は、その区別をプロトコル自身が認めている。

受信証跡には、外側GSIの受理だけでなく、認識したSub-TLV型、無視した型、値の解釈結果を残す必要がある。そうしなければ、新属性を使うポリシーは実行されていないのに、監視上は完全成功になる。

能力はHelloと設定の積で決まる

GSI対応はPIM Helloオプションで通知する。実装は利用を無効にする設定も備えなければならず、無効時にはHelloオプションを広告せず、GSIも生成してはならない。

ソフトウェアにコードがあること、昨日Helloを見たこと、今このインターフェースで有効なことは同じではない。能力証跡には観測時刻とローカル設定を含める必要がある。

出力インターフェースの全隣接がGSI対応なら、対応FHRはGSIを使う。一つでも非対応ならGSHを使う。中継ルーターも、全対応インターフェースにはGSIをそのまま転送し、混在側ではGSHへ変換する。

この変換はグループ、ソース、holdtimeを保存し、Sub-TLVを無視する。同じ起点メッセージが、経路ごとに異なる意味の濃さで届く。

正当な変換でも情報は戻らない

GSIとGSHは同じPFMメッセージに共存できる。同じ(S,G)ではGSIが優先され、GSHは非対応隣接のフォールバックになる。共存は移行を支えるが、特定隣接がどちらを理解したかまでは証明しない。

GSIからGSHへの変換で、Sub-TLVは別の場所に保管されない。無視される。改ざんでも故障でもなく、互換性のために認められた損失である。

だから変換点は監査対象になる。入力GSI、出力インターフェース、隣接能力集合、出力GSH、削除された型を保存すべきだ。下流の三フィールドだけを上流と比較しても、元の意味が同じだったことは分からない。

同一グループの複数(S,G)を一つのGSHへ集約するのはSHOULDでありMUSTではない。準拠実装間でパケット形状が違い得るため、TLV数だけを完全性指標にしてはならない。

複数リンクを一つの論理隣接にする

転送最適化にはRFC 6395のRouter-IDが必要である。PIM VRF内では全インターフェースで同じ4オクテットIDを広告し、隣接IDをキャッシュする。ドメイン内で一意という前提が崩れると、最適化は適用できない。

別のHelloオプションが最適化対応を示す。各Router-IDについて、唯一のPIM隣接であり、その隣接がオプションを広告するインターフェースだけがPFM_OPT_IFに入る。共有LANは対象外である。

Relaxed-RPFでは、送信側が集合から一つを選ぶ。方法は実装依存である。受信側は標準RPFを求めた上で、双方対応時には集合内の別インターフェースからのメッセージも受理できる。

一つ届いたという事実は、その時の候補集合、選択理由、故障時の切替速度を示さない。Router-IDが論理関係を示し、物理リンク選択は別の状態である。

後の更新は最初の空白を埋めない

三つのコピーを一つにすれば処理は減る。その代わり、集合の正しさとリンク障害検出への依存が増える。草案は、選択直後にリンクが落ち、集合更新が間に合わず、メッセージが失われたり遅れたりする過渡状態を明記する。

定期PFMが後で状態を更新する。これはソフトステートの回復であり、初回トリガーメッセージが届いた証拠ではない。新ソースの最初のパケットを必要とする受信者には、その差が重要である。

隣接追加・削除、能力変化、設定変更、トポロジー変更、アップグレード、ダウングレードのたびにPFM_OPT_IFを更新する必要がある。最終状態だけでなく、変更中の候補と選択を記録しなければ、空白時間の原因を説明できない。

起点への返送抑止は別の条件

最適化有効時、唯一の隣接のRouter-IDがメッセージ起点IDと一致するなら、そのリンクへ送り返してはならない。この規則では隣接が最適化オプションを広告する必要はなく、Router-IDだけで足りる。

これはRelaxed-RPFの相互能力確認とは違う。単一の「最適化中」フラグでは、起点への返送を止めたのか、並列リンクを一つ選んだのか説明できない。

Router-IDは暗号学的主体でもない。一意性は運用前提であり、正しい形式のHelloが重複IDや古い対応を防ぐわけではない。

認証された各ホップでも意味は減る

草案は正しいRouter-IDと能力広告、PIM Helloの完全性に依存する。RFC 8364は、リンクローカルPFMを隣接間で認証できても、起点情報を信頼するには経路上の全ルーターが前ホップを正しく認証したと信頼する必要があるとする。

これは隣接ごとの保管連鎖である。全ホップの認証が成功しても、中間で仕様どおりGSH変換が行われ、Sub-TLVが消えることはある。認証は正当な変換を禁止しない。

IANA登録も同じ範囲にとどまる。番号はフィールドを識別可能にするが、実装、設定、経路上の保存、利用結果は証明しない。

必要な九つの証跡

完全な判断には、次を分けて残す。

  1. 草案版と標準化状態。
  2. VRF、起点、Router-ID、インターフェース、時点。
  3. GSI/最適化Helloとローカル設定。
  4. 全Sub-TLVを含む元GSI。
  5. インターフェースごとの無変換転送またはGSH変換。
  6. PFM_OPT_IF、標準RPF結果、選択リンク。
  7. 初回トリガー受信と後続定期更新。
  8. 消費側が理解し、導入した状態。
  9. SPT参加、複製、パケット観測、アプリケーション結果。

新しいGSHは、縮小形式の新しさを証明する。GSI属性の保存は証明しない。定期更新は後の収束を証明する。最初の到着は証明しない。

資料が証明しないこと

凍結資料は第08版の規則、変換、Router-ID前提、リンク選択、定期回復を支える。採用、製品実装、性能向上、相互接続、障害、攻撃、配送結果は支えない。

RFC 8364にある原PFMの試作・限定試験は、新しいGSI/Sub-TLVとRelaxed-RPFの試験ではない。過去の成功を新拡張の本番証明にしてはならない。

Heng Luの記録と権限の区別に従えば、正常なテーブルが語れるのは保持した事実だけである。削除した意味について語る権限は変換記録に、動作結果について語る権限は実行中のネットワークに残る。

出典