要約

  • RFC 3956 は、IPv6 グループアドレス内のプレフィックス長、ユニキャストプレフィックス、短い識別子から一つの PIM-SM RP を導出した。
  • そのグループは任意の利用者が渡し得るため、妥当な導出は RP の存在、到達性、権限、送信元状態、受信者への配信を保証しなかった。

宛先が制御面の行き先も決めた

受信アプリケーションは、設定やディレクトリ、ウェブページからグループアドレスを得る。RFC 3956 は一部の IPv6 マルチキャストアドレスに別の役割を持たせた。PIM Sparse Mode が使う Rendezvous Point の再構成材料である。

背景には IPv6 のドメイン間 ASM があった。IPv4 で使われた MSDP は IPv6 向けに規定されず、Source-Specific Multicast も当時の全用途を直ちに置き換えるものではなかった。各ルーターが宛先だけから同じ RP を得られれば、別の対応表を配布せずに済む。

この設計は設定を消したのではなく、外から渡されるアドレスへ移した。

二つの128ビットは一つに入らない

グループの識別を残したまま、完全な128ビットRPを埋め込むことはできない。RFC 3956 は RFC 3306 のユニキャストプレフィックス型形式を拡張した。フラグが embedded-RP を示し、plen とネットワークプレフィックス、4ビットの RIID が制約付きのRPアドレスを組み立てる。

RIIDのゼロは予約された。同一プレフィックスの下で複数の非ゼロ値を使えるが、完成した一つのグループアドレスは一つの候補へ写る。Group ID の一意な割り当ては仕様外である。全ルーターの計算一致は、管理者間のグループ割り当て合意まで意味しない。

対象範囲ではこの対応が最長一致として他の group-to-RP 手段より優先された。競合する答えを避ける規則であり、選ばれたRPの稼働を保証する規則ではない。

信頼されない入力がJoinを動かした

受信者が MLD を送ると、指定ルーターは導出RPへ PIM Join を始める。送信元側の指定ルーターは初期データを Register に包んで同じ候補へ送れる。利用者が持ち込んだグループが、ルーターの状態と制御トラフィックを発生させる。

RFC 3956 はこの情報を信頼されないソース由来と明記する。インターネット上の任意の利用者がグループを指定できるからだ。実装は他の方法で学習したRPと同等以上の妥当性検査を行い、少なくとも fe80::/10、::/16、ff00::/8 に導かれる結果を除外する。

検査通過は候補として許容できることを示すだけである。グループ提供者、プレフィックス運用者、送信元、受信者を認証せず、参加や送信の権限も与えない。構文はルーティング入力になったが、資格情報にはならなかった。

規格は存在さえ保証できないと書いた

PIM-SM は、学習または設定したRPがドメイン内で到達可能であることを求める。RFC 3956 はその「到達可能」の証明が一般にはできず、外部の埋め込みRPなら存在さえ保証できないと認める。

ルートがあることは次ホップ候補を示す。PIMプロセス、Register受理、送信元状態、資源、応答までは示さない。Join状態は途中の制御判断であり、データ到着ではない。マッピングキャッシュは過去の計算であり、現在の健康ではない。

アドレスに現れたRPは単一障害点としても見えやすい。見える対象は監視しやすく攻撃もしやすい。MSDP広告から隠すことがアクセス制御でなかったように、embedded-RPにもスコープと境界ポリシーが必要だった。

周辺の記録は統合されなかった

RFC 4601 は後に PIM-SM の Join、Register、共有木を詳述し、RFC 3810 は MLDv2 を定義した。ローカル会員報告、上流状態、RP状態、受信パケットは別々の証拠である。

RFC 4607 の SSM は送信元とグループを指定してRPを避ける。RFC 3956 は重要な選択肢としたが、即時の全面代替とは見なさなかった。より詳しい名前も、実際の転送を自動では証明しない。

RFC 7371 は後に IPv6 マルチキャストアドレス体系を更新した。RFC Editor の記録とErrataは文書履歴であり、個別ネットワークの採用証明ではない。

embedded-RP の強みは候補を再現可能にしたことだった。その再現性は設定差を減らす。しかし候補は候補のままである。アドレスは試す方向を示し、経路、PIM応答、送信元状態、カウンター、受信観測がその後を証明した。

出典