Summary
- RFC 2375 では恒久的なサービスの意味を複数のスコープに置けたが、スコープだけが異なるアドレスは別グループであり、ノードは個別に参加する必要があった。
- レジストリの割り当てが証明したのは名前空間の調整であって、リスナー、転送状態、許可された送信元、アプリケーションへの配送ではない。
最初の表は、完成表ではなかった
1998年の IPv6 にはマルチキャスト形式があった。だが実装者には、全ノード、全ルータ、ルーティングプロトコル、時刻サービス、会議システムなどを同じ値で理解するための共有表も必要だった。
RFC 2375 は IPv4 の割り当てをそのまま複製しなかった。IPv6 に関係すると判断したものだけを移し、関係しないものは移さず、変換への意見を求め、表にない値を予約した。「初期割り当て」という位置づけは、将来の追加と修正を前提にしていた。
この表は衝突を避けるための共通語彙だった。そこに名前があることは、どこかでサービスが稼働していることを意味しなかった。
X は無限の到達範囲ではない
固定スコープのアドレスは、指定された範囲だけで有効だった。可変スコープの表記ではスコープ欄に X が置かれ、同じ恒久グループ番号を任意の合法スコープに組み込めた。
しかし RFC 2375 は、それらを一つの巨大なグループとはしなかった。スコープだけが違う IPv6 マルチキャストアドレスは異なるグループであり、ノードは各グループに別々に参加しなければならない。
RFC 2373 の NTP 例では、同じ番号がノード内、リンク内、サイト内、グローバルの NTP サーバを表せた。意味は共通でも、完全な宛先と対象集合は別だった。番号は境界を越えても、参加状態は越えない。
スコープも宛先の一部だった
スコープは表示用の注記ではない。グループの位相的な範囲を定め、ルータはその外へパケットを転送してはならなかった。インターフェース上の「全ルータ」と、リンク上あるいはサイト上の「全ルータ」は、それぞれ異なる問いである。
一時的なグループでは関係がさらに弱い。あるサイトの一時アドレスは、別サイトの同じ値とも、別スコープの同じグループ ID とも、同じ ID を持つ恒久グループとも必然的な関係を持たない。
ビット列が似ているだけでは同一性の証拠にならない。完全なアドレス、スコープ、実行中の状態を合わせて初めて対象が決まる。
レジストリにはリスナーがいない
恒久割り当ては、「この値はこのサービスを意味する」という最初の受領証だった。アプリケーションに受信を要求させるわけでも、インターフェースを選ぶわけでも、隣接ルータにリスナーの存在を知らせるわけでもない。
RFC 2710 の Multicast Listener Discovery は、その次の事実を扱った。ルータは直結リンクで関心を持たれているアドレスを発見し、ホストはアドレスとインターフェースごとに状態を持ち、問い合わせと報告によって参加の変化を知らせた。
IANA の記録とリスナー報告は別の証拠である。前者は意味を安定させ、後者は特定の場所と時刻で受信者が存在することを示す。その後にもマルチキャスト経路、送信元フィルタ、パケット到着、アプリケーション処理が続く。
恒久性は一種類ではなかった
RFC 3307 は、恒久マルチキャストアドレス、恒久グループ ID、動的アドレスを分けた。完全な恒久アドレスを IANA が割り当てる場合もあれば、多数のサーバとスコープで同じサービスを示す恒久 ID を用いる場合もある。動的割り当ては一時的な選択を担った。
いずれも衝突を減らす仕組みであり、メンバーを作る仕組みではない。サービスとして動くには、スコープを選び、完全なアドレスを作り、アプリケーションが受信を要求し、インターフェースが参加し、転送状態が保たれなければならない。
RFC 3306 のユニキャストプレフィックス連動方式では、マルチキャストのスコープは埋め込まれたプレフィックスの範囲を超えられず、寿命もその有効期間を超えるべきではなかった。再利用可能な ID にも場所と時間の条件が残った。
生きた台帳はトラフィック計ではない
RFC 4291 は後継の IPv6 アドレス体系でもスコープ別グループを維持した。RFC 7346 は後に値3を Realm-Local と定義し、用語を整理した。現在の IANA レジストリも、スコープ、固定スコープアドレス、可変スコープ、ユニキャストベース ID、動的 ID を分けている。
これは調整制度が更新され続けた証拠である。1998年の各行に現在も通信がある証拠ではない。実装が消えても名前は予約されたままになり得るし、新しいサービスは何年も後に追加される。
台帳が示すのは衝突なく名付けられる対象である。稼働中のネットワークだけが、実際の聞き手を示す。
権威の範囲を狭く保つ
Lu Heng の最小初期仕様という視点では、RFC 2375 は必要な分だけ共通空間を開き、残りを予約し、経験による修正を認めた点に価値がある。ランニングコード優先の原則は、その次の権威を参加イベント、報告、転送表、観測パケットに置く。
現実のレイヤーを分ければ、登録された意味、グループ ID、スコープ、完全なアドレス、インターフェースの参加、ルータが学んだ状態、経路、許可された送信元、受信パケット、アプリケーション結果は混同されない。
RFC 2375 は初期グループに名前を与えた。だが、安定した名前が聞き手を連れてくるとは言わなかった。
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

