要約

  • RFC 3171 は、動的選択、SSM、GLOP、管理スコープのアドレスで用件を満たせない場合に限って、IANA が希少なグローバル IPv4 マルチキャスト値を追加割当する構造を示した。登録行は調整の記録であり、実装や配送の証明ではない。
  • 文書は年次レビューと、可能な場合の誤割当・世界的に未使用な値の回収または再割当を求めた。ただし特定のレビューや回収実績は記録しておらず、義務を実施済みの証拠としては扱えない。
  • 後に RFC 5771 がこの指針を置き換えた。残る教訓は、静かな行を権利にも空き地にも即断せず、割当理由、実装、経路、トラフィック、依存関係、移行判断を別々に記録することにある。

一覧表は通信を観測していない

IANA の表でアドレスとプロトコル名が並んでいれば、ある時点で意味が調整されたことは分かる。しかし、そのソフトウェアが今も保守されているか、経路が存在するか、送信者がパケットを出すか、受信者が正しい内容を得るかは分からない。

2001 年 8 月の Best Current Practice である RFC 3171 は、IPv4 マルチキャスト割当の管理をこの限界から組み立てた。利用可能なアドレスは、追加の恒久割当を無条件に続けられるほど豊富ではない。そこで、より狭い調整方式が適合しない場合にだけ IANA 割当を検討することにした。

候補は四つあった。SDP/SAP 専用領域での動的なランダム選択、送信元とグループを組にする SSM、AS 番号から値を導く GLOP、そして 239/8 の管理スコープである。仕組みは異なるが、中央の一行を消費せずに衝突を避けられる点は共通していた。

したがって、申請の中心は「番号が空いているか」ではなく、「なぜ他の方式では足りないのか」だった。最終行だけを保存し、その比較を失えば、当時の例外は理由なしの恒久占有に見えてしまう。

個別承認がない領域にも用途制約があった

SDP/SAP ブロックでは未使用の値をランダムに選び、個別の IANA 割当を必要としなかった。しかし用途は SDP/SAP に限定され、一般用のアドレス棚ではない。

GLOP は ASN から 233/8 の一部をアルゴリズムで割り当てた。個別審査が不要でも、その値が ASN 保有者の所有物になるわけではなく、ルートやパケットが存在する証明にもならない。

管理スコープ領域はドメイン内で運用される。アドレスが意図を表し、ルータの境界設定が実際の封じ込めを作る。登録ポリシーと転送実行は別の証拠面である。

SSM は (S,G) により識別空間を広げた。適切なアプリケーションなら ASM の恒久グループを減らせる。ただし、既存システムが信号方式、受信処理、設定を変えずに移行できるとは限らない。

RFC 3171 は万能な代替方式を選べとは言わない。世界的な例外を求める側に、適合しない理由を残すよう求めた。その理由こそ、後の見直しで条件が変わったかを判定する基準になる。

アドレスブロックごとに審査の意味が違った

Local Network Control と Internetwork Control の割当は Standards Action を必要とした。AD-HOC ブロックについて、RFC 3171 は原則として新規割当を避けるべきだとしたが、特別な場合には Expert Review、IESG Approval、Standards Action の経路があった。

一方、ランダム選択、GLOP の導出、ローカル管理は別の調整権限を使う。これらは所有権の強弱ではなく、同じビットが同じ調整範囲で異なる意味を持たないための方法である。

管理スコープ領域内の relative offset は 256 個しかなく、インフラを支えるサービスに限って割り当てるべきだとされた。外側のアドレスがローカルでも、複数のローカル領域で同じ意味を持たせる小さな数値は共有資源になる。

監査では、値だけでなく、ブロック、手続、適用 RFC、判断者、責任連絡先を残す必要がある。「登録済み」という一語では、どこまで調整され、何が審査されたかを説明できない。

年次レビューは事務上の永続性を拒んだ

RFC 3171 の第 10 節は、IANA に既存割当の年次レビューを求めた。誤って割り当てられたアドレスは、可能なら回収または再割当する。AD-HOC、DIS Transient Groups、ST Multicast Groups についても、SSM、GLOP、管理スコープへ移せるものや、世界的に経路制御されていないものを確認するよう求めた。

ここでは、台帳の継続性と各行の不変性が切り分けられている。信頼できる台帳は、古い判断を守るだけでなく、誤りや不要な例外を訂正できなければならない。

ただし RFC は年次監査報告書ではない。特定のアドレスが使われていないと測定したわけでも、回収例を示したわけでもない。「レビューすべきだ」という規範と、「このレビューを行った」という証跡は別である。

後者を主張するには、観測範囲、期間、経路データ、維持者との照会、異議、判断、変更結果が必要になる。標準に義務が書かれているだけで、実施が自動的に証明されることはない。

見えないことには観測範囲がある

グループは私設網だけで使われることがある。年に一度の訓練や障害時だけ動くこともある。スコープ境界、フィルタ、収集地点の偏りによって、実在するトラフィックが観測されない場合もある。

逆に、パケットが見えたからといって登録されたアプリケーションのものとは限らない。誤設定、走査、別用途が同じ宛先を使える。経路は内容の正しさを示さず、join は配送を示さず、受信は利用価値を示さない。

レビューでは、どこで、いつ、何を見たかを明示する必要がある。元申請と適用ポリシーを回収し、仕様、コード、設定、連絡先を調べ、複数の経路・パケット面を観測し、低頻度や閉域の依存を探し、反証の機会を設ける。

RFC 3171 自体はこの完全な運用手順を規定しなかった。それでも「世界的に使われているか」を保持条件にしたことで、登録行だけでは回答できないことを明確にした。

「可能なら」は安全な移行を要求する

古い実装が眠っている間に同じアドレスを新しい用途へ渡せば、後日二つのシステムが衝突しうる。閉じていたネットワークが接続され、古い設定が広い範囲へ現れることもある。

そのため回収は削除操作ではない。誤割当、連絡先の失効、保守停止、コールドスタンバイ、閉域利用、世界的サービスを区別する必要がある。通知、異議期間、移行先、限定的な併用、再利用前の隔離、衝突監視、ロールバックを組み合わせる。

これらは RFC 3171 の逐語的な手順ではなく、「可能なら」という条件を可逆的な変更に変換するための実務である。保管者が訂正できることと、影響を無視して処分できることは同じではない。

また、この IPv4 マルチキャスト規則をすべてのインターネット識別子へ一般化してはならない。契約、導入規模、障害範囲は資源ごとに違う。引き継げるのは、行政上の惰性も短期的な沈黙も、それだけでは結論にならないという方法論である。

後継文書は過去の政策時点を消さない

RFC 5771 は RFC 3171 を廃止扱いにし、IPv4 マルチキャスト割当指針を更新した。したがって 2001 年文書を現在の完全なルールとして示すことはできない。一方、当時の例外、見直し、回収という設計を理解する史料価値は残る。

RFC 8126 は登録ポリシーの一般語彙を後に整理した。Standards Action や Expert Review を説明する助けにはなるが、過去の個別審査を実施済みと証明しない。

現在の IANA 登録ページも、今日公開される台帳面である。各行の元申請、全レビュー、実装一覧、流量履歴を自動的には含まない。継続性には、適用ルール、例外理由、後継ルール、運用依存、判断履歴をつなぐ時間軸が要る。

この鎖がなければ、同じ行が「永久権」と「即時再利用可能」という正反対の誤読に使われる。登録は出発点であって、結論ではない。

割当の後から保管責任が始まる

検証可能な記録には、アドレス、ブロック、目的、日付、手続、責任者、依存するコードと設定、代替策が不適合だった理由を残す。宣言した限界の中で経路、パケット、受信、アプリケーション結果を観測する。

保持、移行、隔離、回収の判断には、異議、依存、移行先、隔離期間、復帰条件、変更後の確認を付ける。

登録は意味の調整を示す。コードは参照を示す。経路は転送準備を示す。パケットは観測を示す。受信者は到達を示す。アプリケーションは有用性を示す。レビュー記録は、なぜ行動したかを示す。

RFC 3171 は最初の証跡を残り全部の代用品にしなかった。番号を割り当てた後こそ、その理由とネットワークの現実を継続的に結び直す仕事が始まる。

出典