要約

  • PLI を有効にした受信インターフェースは、送信元の Hello を見ていなくても Join/Prune を処理する。通常の隣接管理、DR 選出、Assert は付いてこない。
  • 受信者の要求を境界の外へ出す装置と、上流から届く一つの有効なフローを選ぶ判断は別である。片方を決めても、もう片方の重複防止は証明できない。
  • 属性の処理能力、障害通知から OIF を撤去する動作、TCP PORT の接続先と能動・受動の役割は、設定と構成で明確にする必要がある。

分析

冗長な境界ルーターを一台追加したとき、同じ Join がもう一つの経路を通れるようになる。受信要求が失われにくくなるようには見える。しかし、要求を送る側の二台と、データを供給できる上流側の二台は、同じ選出で整理できるとは限らない。要求の代表者を一人にしても、データの送り手が一人になるとは限らないからだ。

これは設計上の仮定であり、特定の運用障害を報告しているのではない。RFC 9739 を読む際の焦点はここにある。2025年3月に標準化過程の文書として公開された PIM Light は、完全な PIM 隣接関係が成立しにくい、または望ましくない媒体で使う PIM Light Interface、PLI を定義した。境界を越えて状態を交換するために Hello を省く。省いた仕組みが担っていた判断は、境界の外に残る。

要求の代表者とデータの送り手

RFC 9739 の BIER の例では、受信者側の PIM ドメインにある冗長な境界ルーターは、通常の PIM 隣接関係を維持して Designated Router、DR を選ぶ必要がある。受け取った Join/Prune を BIER トンネルへ転送するのは、その DR だけである。PLI 自身は Hello を送受信せず、DR を選出しない。コアをまたぐ隣接関係を省くことと、受信要求の代表者を決める場所までなくすことは違う。

通常の PIM には、データの重複を扱う別の仕組みもある。RFC 7761 の4.6節 の Assert は、共有媒体で複数のルーターが同じデータを転送する状況を整理する。Assert の勝者と DR は同一の役割ではない。

PIM Light は Assert を処理しない。RFC 9739 は、パケットの重複をアプリケーションまたはネットワーク構成で防ぐことを要求する。重複した後に PLI が選び直して解決するという約束ではない。

BIER の例では、下流の境界装置がトポロジーから上流候補を識別し、最小または最大の IP アドレスなど、一意の規則で一台を選ぶ方法が示される。選択した装置が使えなくなったときの代替アルゴリズムは、文書の詳細な範囲外である。この例をあらゆる構成の必須アルゴリズムや、障害復旧の実測値として扱うことはできない。

受入試験を設計するなら、DR が正常なまま選択済みの上流境界が失われる場合と、その逆を分ける必要がある。復帰時にも、前の選択と新しい選択が同時に有効にならないかを観察する。一意の選択規則があるだけでは、切替中の二重転送まで検証したことにはならない。本稿はこの試験を実施したと主張しない。

隣接関係のない受理は、無制限の受理ではない

RFC 7761 の4.5節 では、送信元の Hello を受信していない Join/Prune は、一般に破棄すべきものとして扱われる。一部の古いポイントツーポイント実装との相互運用例外は限定的で、既定で有効にすべきではない。

PLI では、未知のルーターからでも明示的に Join/Prune を受け入れ、マルチキャスト経路表に状態を作る。ただし、通常の隣接データベースを作り、その情報から能力や選出結果を得るわけではない。RFC 9739 は、入力インターフェースで PLI が有効でなければ、既知の隣接相手からではない Join/Prune を破棄するよう要求する。

下位層の仕組みが論理 PLI を自動的に有効にする場合もある。その場合でも、どの到達関係、カプセル化、インターフェースの組に許可を与えたかは識別できなければならない。自動化はすべての入力を許可するという意味ではない。検証案としては、同じメッセージを指定した PLI と通常のインターフェースへ送り、受理境界が違うことを確かめられる。

処理できるメッセージも限定される。Register（1）、Register Stop（2）、Join/Prune（3）、Candidate RP Advertisement（8）、Packed Null-Register（13.0）、Packed Register-Stop（13.1）と、宛先がユニキャスト IP アドレスになる将来の型が対象で、それ以外は処理してはならない。IANA の登録表 は番号を確認する資料であり、製品の対応を証明するものではない。

BIER の例が Join/Prune だけを利用していても、PIM Light 全体がそれしか運べないわけではない。適用範囲は PIM-SSM を含む PIM-SM であり、PIM-DM と BIDIR-PIM は対象外である。スパースモードの状態には (*,G)、(S,G)、(S,G,rpt) がある。SSM の試験だけで共有木の処理まで合格とするのは範囲を広げすぎる。

属性の能力をどこで確認するか

RFC 5384 の Join Attributes は、共通の形式と個々の属性の意味を分けている。符号化型1の送信元アドレスを解析できることは、そこに載るすべての属性を理解できることではない。通常の Hello オプションも、共通形式への対応を通知するのであって、各属性の意味を一括して保証するものではない。

PIM Light はその通知も持たない。そのため RFC 9739 は、隣接相手が属性を処理できると設定で分かっている場合、または該当する場面を RFC や Internet-Draft が明示的に認める場合を除き、属性付き Join を送るべきではないとしている。

例外を設定するなら、対象の属性、能力が確認された相手、協調が必要な範囲を残す必要がある。「PIM 拡張対応」という一般的な説明では足りない。装置やソフトウェアが変わっても普通の Join は受理され続けるかもしれない。Hello がないこと自体は正常なので、かつて例外を正当化した能力が失われても、その不一致を自動的に交渉で発見できるとは限らない。これは設計から導く変更管理上の含意であり、実際の障害記録ではない。

障害を検出した後に、どの OIF を消すのか

Hello による隣接確認をなくすと、PLI の障害が発見されず、上流へ Prune が送られないまま、出力インターフェース、OIF の状態が期限切れになるまでトラフィックが続く可能性がある。RFC 9739 は、この問題と実装依存の対処例を記す。

BFD はすべての実装に必須の保護ではない。文書の BFD の例では、遠端 PLI へのセッションが落ち、上流ルーターの (S,G) の OIF リストにその PLI があるなら、PIM はそれをリストから外さなければならない。BIER が自動的に作るインターフェースの例では、下流境界への到達性喪失を使って、送信元方向へ (S,G) の Prune を送れる場合がある。

必要なのは検出器の名前ではなく、監視対象と状態変更の結び付きである。遠端装置、経路、セッションのどれを見ているのか。その通知をどの動作が受け、どのインターフェースをどの状態から削除するのか。警報が出ても PIM への通知が届かなければ、撤去は別の依存関係として残る。

検証案では、境界装置の故障、経路の故障、通知経路の断絶を分けるべきだ。資料には、あらゆる実装に共通する復旧時間、数値的なタイマー設定、導入効果や費用測定はない。時間の約束には、その構成で実際に状態が変わる観測が必要になる。

PORT の接続は選出の代わりにならない

RFC 6559 は、TCP または SCTP の宛先ポート8471を使って Join/Prune を運ぶ PORT を定めた2012年の実験的文書である。通常の PORT では、Hello が能力と Connection ID を広告する。この ID は接続確立に使う IPv4 または IPv6 アドレスであり、QUIC のような不透明な識別子でも、認証情報でもない。

通常の TCP の手順はアドレスの比較で能動・受動の開設を決めるが、オンデマンド接続の例外もある。SCTP は同時開設の衝突を処理できる。PLI は Hello を持たないため、RFC 9739 は Connection ID の設定を認め、TCP PORT では両端の能動・受動の役割を明示的かつ正しく設定することを求める。

接続の維持と復旧も別の仕事である。RFC 6559 は、無通信の TCP では遠端の喪失がすぐ分からない場合を説明し、Keep-Alive や接続失効の仕組みを設ける。ただし、共通の既定 Holdtime を強制していない。再接続したら、関連する Join/Prune 状態全体を送り直す必要がある。接続喪失は、更新されない関連 OIF 状態の期限切れを開始させるが、通常の Join/Prune データグラムへ自動的に戻してよい理由にはならない。

TCP が開いたという証拠だけでは、無通信時の検出、完全な状態再同期、PLI 撤去は分からない。そして、どれが正しくても代替上流を選ぶ判断を実装したことにはならない。

この資料から言える範囲

RFC 9739 は、望ましい (S,G) を処理するポリシーを推奨し、それ以外を破棄するよう要求する。これは受理する状態の制限であって、送信者の認証ではない。メッセージ保護には RFC 5796 の IPsec ESP、必要に応じた AH を参照する。RFC 4607 も、SSM で送信元を指定するだけでは強い認証を得られないと説明する。

RFC 8279 の BIER は、中間コアでフローごとの状態や従来の木構築を避ける理由を示す。境界の PIM 状態まで消すわけではない。2026年9月13日に確認した BIER-PIM 文書の公式状態 は、2025年3月3日付の第13版を期限切れの草案として示す。RFC 9739 が例として参照していても、別の完成した標準や現在の配備を証明しない。

したがって結論は限定的である。Hello のない境界で状態を交換することは規定されている。その成立を支える選出、能力の知識、障害後の動作は、PLI が行わないからこそ場所と条件を特定する必要がある。

出典

画像は AI で制作した編集上の比喩であり、検証済みの構成図や実際の配備記録ではない。