要約

  • RFC 5384 の Join Attribute Hello option は、type 1 の Encoded-Source Address を受け取れることだけを示す。そこに入る全属性タイプの意味を理解するという宣言ではない。
  • 同じタイプの異なる属性集合が複数の下流隣接から届くと、属性固有の手順がない限り、数値の小さい隣接 IP アドレスが選ばれる。IPv6 ではリンクローカルアドレス、同一アドレスではインターフェース番号が決め手になる。これは再現可能な選択であり、業務上の権限やデータ配信の証拠ではない。

合意がなくても答えは一つになる

二台の下流ルーターが、同じ送信元・グループで表される木への Join を送る。どちらのメッセージも正しく、同じ属性タイプを持つ。しかし値は異なる。受信した上流ルーターは、二つの排他的な要求を一つの現行値として上流へ送ることはできない。

RFC 5384 は内容ではなく供給元を並べる。PIM 隣接の IP アドレスを数値順に比較し、小さい方の属性を採用する。IPv6 の比較対象はリンクローカルアドレスであり、アドレスまで同じならインターフェース番号を使う。個別属性の仕様は別の競合解決手順を定義でき、その場合は固有手順が優先する。

この規則が保証するのは決定性である。同じ入力を見た実装が同じ状態に到達しやすい。しかし、小さいアドレスがサービス所有者であるとも、最新の変更承認を持つとも、優れた経路を提示したとも書かれていない。

運用画面に一つの値だけが残ると、競合は消えたように見える。実際には、機械が競合を安定した順序に折り畳んだだけである。「値が決まった」と「組織が決めた」を区別しなければならない。

封筒を扱えることと中身を理解すること

PIM Join は、グループアドレスの文脈にある Encoded-Source Address によって配信木を識別する。RFC 5384 は encoding type 1 を割り当て、木に TLV 形式の Join Attribute を結び付けられるようにした。type 1 には少なくとも一属性が必要で、属性なしは type 0 で表す。

ルーターは、インターフェース上の全 PIM 隣接が Hello に Join Attribute option を含めていなければ type 1 を送ってはならない。上流隣接だけが対象ではない。Join 抑止や上書きに参加する他の隣接にも解析能力が必要だからである。

ただし、その option は属性一般の理解を約束しない。RFC 5384 は、送信したルーターが全ての属性タイプを理解するとは限らないと明記する。タイプごとの汎用 Hello option は用意されない。

したがって、観測できたのは「type 1 の外形を受信できる」という能力である。RFC 6420 は MT-ID 用に別の capability、妥当性確認、競合規則を追加する。RFC 6807 の Population Count にも独自の option がある。RFC 7887 は同じ値をメッセージ、グループ、送信元の各階層で圧縮するが、意味は変えない。

受け入れ試験では、type 1 の解析、利用する各属性タイプ、ソフトウェア版、インターフェース範囲、ローカルポリシーを別々に記録すべきである。「Join Attribute 対応」という一行では、意味の共有を証明できない。

新しい Join は差分ではなく全状態である

属性集合の更新は特に注意を要する。ある隣接が同じ木について新しい Join を送り、以前と完全に同じ集合でなければ、新しい集合が全体を置き換える。以前あったのに新しい Join にない属性は撤回されたものと扱う。空集合は type 0 になる。Prune も、その隣接が供給していた属性を撤回する。

たとえば以前は A と B、次は B だけだったとする。独立した「A を削除」という TLV は届かない。それでも A は消えている。受信した新規値だけを追記するログは、存在しない A を残し、実際とは異なるポリシーを再構成してしまう。

RFC 7887 の階層表現では、値の適用範囲がメッセージ全体、グループ、個別送信元に分かれる。圧縮効率が上がっても証跡要件は軽くならない。広い階層の誤値は多くの送信元に及ぶ。各範囲で変更前後の完全な集合を保存し、欠落によって何が撤回されたかを示す必要がある。

理解しない属性も先へ進み得る

F-bit は、未知タイプを受けたルーターの行動を決める。F=1 の transitive 属性は転送しなければならない。F=0 の non-transitive 属性は破棄する。他の属性は残り、全てなくなれば type 0 Join を上流へ送る。

属性が上流に残ったという事実は、途中の全ルーターが意味を検証した証拠ではない。あるノードは理解しないまま、転送義務だけを果たした可能性がある。

さらに、そのノードが同じ未知タイプの競合集合を複数隣接から受けることもある。インスタンス数と各バイトが同一でなければ、一般競合手順が必要になる。意味を知らない装置が、アドレス順で意味の候補を選ぶことになる。

監査記録には、受信、外形解析、タイプ理解、未知転送、未知破棄、候補選択を別のイベントとして残す。「検証済み」という表現は、意味と権限を実際に確認した場合に限る。

状態の出所は隣接に結び付く

属性処理が木の構築や上流へ送る集合に影響するなら、RFC 5384 は属性と受信元隣接との対応状態を保持するよう求める。この対応によって、Prune や隣接失効時に正しい値を撤回できる。

選ばれなかった属性を記憶してもよい。勝者を供給した隣接が消えたとき、優先順の次候補を直ちに使える。周期更新を待たずに収束できる利点がある。

一方で、有効な制御意図は変化する。次候補は新しい要求ではなく、以前から抑止されていた要求かもしれない。転送が継続していても、木を支配する値が切り替わる。最終値しか保存しない監視では、承認された変更と隣接障害による昇格を区別できない。

完全な候補集合、供給元アドレス、受信インターフェース、適用手順、勝者、敗者、遷移理由を保持することが必要である。

認証は発言者を示すが、決定権は作らない

RFC 5384 は属性の安全性を PIM パケットの安全性に依存させ、各属性固有の検討を別仕様へ委ねる。RFC 5796 によるリンクローカル PIM 認証は、送信元と完全性を確認する手掛かりになる。

それでも、認証された二隣接が競合することはある。暗号は「誰がこのバイト列を送ったか」を答えるが、「誰がこのサービスについて決めるべきか」は答えない。小さいアドレスに組織上の上位権限を付与することもない。

権限は別のポリシーで定義する必要がある。主体、送信元・グループ範囲、許可タイプと値、ローカル設定の優先、競合時のエスカレーション、承認記録を結び付ける。RFC 6420 の MT-ID ではローカル設定が優先し得るため、その設定と変更履歴が権限証跡になる。

木の制御とサービス結果は別物である

正しく解釈され選択された属性も、制御面の証拠にとどまる。上流隣接や RPF トポロジーを変えるかもしれないが、マルチキャスト状態の実装、期待経路、重複回避、受信者の認可、アプリケーション到達を証明しない。

証拠は段階ごとに分ける。設定意図、capability、受信 Join、属性解釈、競合選択、上流 Join、実装状態、パケット観測、受信者とアプリケーション結果である。前段の成功を次段の成功として再利用してはならない。

既存の RFC 9798 記事は Receiver RLOC、ETR のグループ選択、ITR の複製と配信証拠を扱う。RFC 9739 記事は PIM Light における Hello、DR、Assert、障害撤回の欠落を扱う。本稿の対象は RFC 5384 の一般競合手順だけである。

敗者を消さない試験

実験環境に二つの下流隣接と一台の上流ルーターを置く。インターフェースの全隣接で type 1 capability を確認し、仕様が公開された属性タイプを選ぶ。Join の原文、木キー、隣接アドレス、インターフェース、時刻を収集する。

同じタイプで異なる値を送る。属性固有規則の有無を確認し、なければ最小アドレスが勝つことを検証する。値を変えずアドレス順だけを変え、結果が移ることを示す。勝者隣接を失効させ、記憶された次候補と上流 Join の変化を見る。

A+B を B のみに置換し、A の撤回を確かめる。未知 transitive と unknown non-transitive を分け、転送と破棄を観測する。最後にパケットトレースと受信者 canary を別証跡として照合する。

報告書は「規則 Y により X を選択した」と書けなければならない。同じ一文を「X は認可された」や「配信に成功した」に置換してはならない。

出典