要約

  • RFC 2365は239.0.0.0から239.255.255.255までを管理スコープIPv4マルチキャスト空間とした。アドレス自体に遮断能力はなく、境界ルーターがインターフェースごとの定義を読み込み、双方向に適用しなければならない。
  • 境界はデータパケットだけの規則ではない。dense modeでは境界をpruneし、sparse modeでは対象範囲のJoinを受け付けない。設定ミスや実装不良があれば越境し得るため、スコープはファイアウォールや機密保持の証明にならない。

監査画面に並ぶ宛先がすべて239で始まっている。設計書では「組織内」とされ、変更管理にも異常はない。この三つを並べれば、ストリームが外へ出ないと結論したくなる。

それでも、どの出口に境界が載っているかは分からない。予備経路が同じ定義を持つか、ラインカードが最新状態を実行したか、Joinが境界を越えていないかも分からない。パケットの宛先は分類を示すが、転送結果は示さない。

1998年7月にBCP 23として発行されたRFC 2365は、この空白を設計の中心に置いた。239/8を覚えるだけでは、文書の半分しか読んだことにならない。

TTLは寿命と地理を兼ねていた

MBONEでは、インターフェースにTTLしきい値を置いて配信範囲を近似する運用が一般的だった。残りTTLがしきい値を上回らなければ転送しない。無限周回を防ぐ寿命フィールドが、サイトや地域を表す政策言語にもなった。

RFC 2365は、その二重用途が信頼しにくい理由を説明した。TTLで失効またはしきい値不合格になったパケットを捨てたルーターは、上流に安全なpruneを返せない。次のパケットが別経路を通り、より大きなTTLで同じ地点へ来るかもしれないからだ。下流に受信者がいなくても、その地点までトラフィックが流れ続ける場合がある。

管理スコープは、残りホップ数から政策を推測する方法をやめた。アドレスがローカルな空間を選び、明示した境界がその空間の終点を決める。

239/8は壁を内蔵しなかった

RFCは239/8全体を管理スコープとし、239.255.0.0/16をIPv4 Local Scope、239.192.0.0/14をOrganization Local Scopeとした。他の範囲は拡張用に残された。後年のRFC 5771は239/8をドメイン内で使うブロックとし、通常のIANA割り当て方針を不要とした。現在のIANAレジストリもRFC 2365との関係を保持している。

それはアドレス分類の記録であって、稼働中ルーターの証明ではない。管理境界を越えて一意である必要がないため、別の領域が同じグループ番号を再利用できる。漏えいすれば、別のローカル用途と衝突したり、余分な帯域や受信状態を生んだりする。

アドレスには組織名も送信者の本人性も受信権限も入っていない。「プライベート・マルチキャスト」という通称を使うなら、ファイアウォールや暗号の意味を持たないことを同時に示す必要がある。

境界はインターフェースに置かれた

境界ルーターは、インターフェースごとにスコープ範囲を設定できなければならない。定義に一致するパケットは、どちら向きにもそのインターフェースを越えない。双方向検査は、multi-access networkで一回の到来方向から内外を固定的に決めないために重要だった。

制御面も同じ境界に従う。dense-mode groupは境界で常にpruneされ、sparse-mode groupについては遮断範囲のJoinを受け付けない。観測したデータパケットだけをACLで捨てても、グループ状態が境界をまたぐならRFCの全体動作にはならない。

スコープ領域は接続され、凸でなければならない。内部の二点を結ぶ経路が領域外へ出て戻る形は不適切である。境界ルーターは共通定義を持ち、領域がトポロジー上交差するならアドレス範囲まで交差させないことが推奨された。一台の正しい設定は、別出口の欠落を補えない。

設定は実行前の受領証にすぎない

運用では証拠を分ける。宛先が予定範囲か、政策が領域と責任者を定めたか、全インターフェースに正確な設定が載ったか、pruneまたはJoin拒否があるか、転送表とハードウェアが実行したか、両側からの試験で越境がないかを別々に残す。機密性には暗号と鍵管理の記録が要る。

候補設定が正しくてもASICが古い状態を持つことがある。主経路の試験成功はバックアップ経路を証明しない。ゼロのカウンターは遮断成功ではなく、試験パケット未到達かもしれない。外側のキャプチャが空でも、送信元が沈黙していただけかもしれない。

Running-Code Primacy、Minimum Initial Specification、Reality Layersは後年の編集上の視点であり、RFC 2365の要件でも著者の意図の証拠でもない。ただし、共通のアドレス意味、ローカルなトポロジー選択、実行状態、観測結果を別の層に保つ読み方を与える。

セキュリティ節は安堵を許さなかった

RFC 2365は、機密データが組織外へ出ないことを管理スコープに依存してはならないと明記した。境界ルーターの設定ミス、スコープ処理コードのバグ、その他の問題によって、正しい領域の外へ転送され得るからである。機密情報には暗号など別の保護が必要だとした。

さらに、境界ルーターは必ずしもファイアウォール機能を提供しない。送信者認証、受信者の権限、鍵配布、アプリケーション到達は別の問題である。ここで証明できるのは、正しく設定・実行したルーターが転送範囲を制限したことだけだ。

古いRFCが残した実務的な教訓は明確である。名前空間は「どこまで」を表せるが、それを現実にするのは機器と設定である。封じ込めを主張するなら、アドレス、境界、実行、観測を結ばなければならない。秘密を守るなら、さらに独立した暗号が要る。

情報源