RFC 5135：SSM のグループ変更が必要になる NAT の送信元衝突

要約

SSM の選択単位は、送信元アドレス S とグループ G の組 (S,G) である。
二つのプライベート送信元は、S が異なるため同じ G を使っても内側では区別できる。
RFC 5135 は、内側から外側へ出るマルチキャストの送信元を NAT の外側アドレスへ書き換えるよう求める。
両方が同じ外側アドレスで表現されれば、二つの内側チャネルが同じ公開 (S,G) に収束する。
RFC は、この条件ではトラフィックを一意に識別できず、受信者側で混在し得ると説明する。
一般解は将来の検討に残され、利用者が SSM グループを変更できることが暫定策とされている。
グループ変更機能は、衝突検知、新値の通知、全受信者の採用、旧値の廃止を自動的には証明しない。
IGMPv3 プロキシの集約は制御状態を正しくするが、データ面で失われた送信元差分を復元しない。
Endpoint-Independent Mapping は宛先に左右されない変換規則であり、各送信元の公開上の一意性ではない。
スコープ制御、TTL、転送カウンターは到達範囲や移動を示すが、誰のストリームかは示さない。
RTP の SSRC や CNAME は別の識別層になり得るが、生成から受信処理まで独立した検証が必要である。
完了条件は、内側の送信元から公開通知を経て、受信者が選び実際に出力した結果までの証拠連鎖である。

暫定策から読む設計上の限界

標準が「グループを変更できるようにする」と書くと、実装項目は単純に見える。設定画面に入力欄を置き、別の G を保存できれば満たしたように見える。しかし RFC 5135 が扱う問題は入力欄の不足ではない。NAT が複数のプライベート送信元を一つの公開送信元に表現した結果、SSM の識別に使う組そのものが衝突することである。

内側の送信元を A と B、共通のグループを G とする。内側では (A,G) と (B,G) なので、ルータや受信者は区別できる。外側で両方の送信元が NAT のアドレス N に置換されれば、どちらも (N,G) になる。パケット転送が成功しても、公開 IP 層には元の差分が残らない。

そこで一方を G2 に変えれば、(N,G) と (N,G2) に分かれる。理屈は明確である。ただし、その変更はローカルな調整作業を大量に生む。衝突を誰が検知するのか。新しいグループを誰が選ぶのか。セッション記述をどの版に更新するのか。オフラインの受信者、キャッシュ、フィルター、許可リスト、録画装置はいつ追随するのか。

「変更可能」は能力の証拠にすぎない。「変更済み」は操作の証拠であり、「全受信者が新しい対象だけを受け取った」はさらに別の証拠である。標準が一般解を将来の検討に残した以上、運用者はこの差を UI のチェックボックスで埋めてはならない。

SSM の一意性は組の両辺に依存する

SSM が提供する選択性は G だけから生まれない。S と G の組み合わせがチャネルである。したがって、送信元アドレスの変換は単なるヘッダー整形ではなく、選択キーの一部を書き換える操作になる。

RFC 5135 の Appendix A は、同じ G を選んだ複数の内側 SSM 送信元が、外側インターフェースでは一意に識別できなくなり、受信側でトラフィックが混ざる可能性を示す。これはすべてのアプリが必ず誤動作するという統計ではない。条件が成立したとき、公開 (S,G) だけではプライベートな出自を証明できないという機構上の限界である。

この違いは障害判定を変える。NAT の外側でパケットを観測した、レートが期待値に近い、受信ソケットにデータが届いた——それらは移動の証拠である。しかし、期待した A のみが届き、B が混在していないことの証明にはならない。欠けているのは可用性ではなく系譜である。

NAT 要件を成果保証へ膨らませない

2008 年 2 月の BCP 135 である RFC 5135 は、IGMP プロキシを持つ IPv4 NAT/NAPT における ASM と SSM を対象にする。PIM-SM と IPv6 は範囲外である。この限定は、準拠という言葉が何を含まないかを知るために重要だ。

外側から内側へ向かうマルチキャストでは、宛先 IP と宛先ポートを変更せず、加入している内側受信者へ UDP を転送する必要がある。内側から外側へ向かう場合は送信元 IP を外側アドレスへ書き換える。NAPT では送信元ポートも変わり得て、応答が必要ならマッピングを作る。

Endpoint-Independent Mapping は、同じ内部エンドポイントのマッピングが相手先によって変わらないことを求める。複数の公開アドレスがある場合の paired address pooling は、一つの内部エンドポイントに同じ外側アドレスを使うことを勧める。どちらも予測可能性を高めるが、異なる内部送信元を常に異なる公開送信元へ割り当てる保証ではない。

内側発の UDP マルチキャスト転送は必要だが、無効化手段も必要である。マルチホーム環境では複数経路から同じ公開トラフィックが出る恐れがあるからだ。ただし、一つの流れが二重に出ることと、二つの流れが一つに見えることは異なる。ログは両者を同じ「重複」として処理してはならない。

範囲の正しさと送信元の正しさ

標準はアドレス範囲の境界も定める。239.0.0.0/8 の管理スコープはデフォルトで外へ出してはならず、224.0.0.0/24 のローカル制御ブロックも外部へ転送してはならない。さらに TTL が 1 なら、ローカルルータを越えない。

これらは強い安全弁だが、問うているのは「どこまで届くか」である。許可されたパケットがどの内側送信元を代表するかは別の問いになる。範囲ゲートを通過したことを、身份の検証済み印として扱うと、制御の目的を取り違える。

IGMP 集約が守るもの

IGMP プロキシは、下流ホストの報告をそのまま外へ流す装置ではない。各ホストの加入状態と送信元フィルターを集約し、上流に対して一つの報告者として振る舞う。RFC 5135 は IGMPv1 を任意、IGMPv2 を必須、IGMPv3 を推奨とし、IGMPv3 を実装するなら SSM と対応するフィルター動作を必須とする。

集約を行わず、複数ホストの状態変更を単純に交互送信すると、一つの報告者としては不正な順序になり得る。一方が参加し、別の一方が離脱する時、短時間のブラックホールも起こり得る。プロキシは私有側の複数状態機械を計算し直してから上流へ表現する。

この正しさは重要だが、データパケットの送信元書き換えとは別である。外側のフィルターは外側で見える N を使う。A と B が N に収束した後、正しい IGMPv3 状態が秘密の A/B 識別子を追加するわけではない。制御面が健全でデータ面の身份が曖昧、という状態は成立する。

RTP を万能な救済にしない

RTP の SSRC と CNAME は、IP アドレスの上に別の参加者識別を提供し得る。RFC 5135 は、多数の NAT が同じ RFC 1918 空間を再利用するため、適切な CNAME 生成を促している。受信アプリがこの情報を正しく使えば、公開アドレスが共通でも参加者を区別できる場合がある。

ただし、送信側の生成、パケットやシグナリングでの伝達、受信側の検査、衝突規則、業務上の対象への結び付けが必要だ。SSRC 衝突はアプリ層の問題であり、SSM の IP 層エイリアスとは同一ではない。片方のログからもう片方の解決を推測してはならない。

ASM と RTP については、マッピング期限切れで変換後のトランスポートアドレスが変わり、衝突検出が発動する問題も扱われる。RFC は 60 分の保持と離脱時の破棄を勧め、資源逼迫時でも RFC 4787 の最小値を下回らないよう求める。タイマーは NAT 状態の寿命であり、受信内容の意味の寿命ではない。

移行を事実にする証拠

まず内側で、送信者の運用上の身份、私有アドレス、グループ、設定世代、有効期間、実測 (S,G) を記録する。境界では、外側アドレス、ポート、マッピング世代、プール選択、期限を保存する。IGMP の版、下流加入、フィルター、上流集約は別の台帳として関連付ける。

外側では、セッション記述が通知した組、受信者が要求した組、実際のパケットを比較する。同じ公開組に複数の内側源が寄与していないかを検出する。グループ変更時は新旧の併存期間と旧チャネルの停止を確認する。アプリ識別を使うなら、その値から受信結果までの結合も残す。

最終証拠は受信者が持つ。どの論理送信元を選び、何を受け入れ、何を捨て、混在があったか、時刻条件を満たしたか、何を表示・保存・実行したか。ここまで到達して初めて、設定変更は現実の変更になる。

「グループを変えられる」は解決ではない：RFC 5135 がアプリ側に残した仕事

なぜ重要か

要約

暫定策から読む設計上の限界

SSM の一意性は組の両辺に依存する

NAT 要件を成果保証へ膨らませない

範囲の正しさと送信元の正しさ

IGMP 集約が守るもの

RTP を万能な救済にしない

移行を事実にする証拠

出典

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説