要約

  • IETF Datatrackerは2026年9月3日にdraft-ietf-pim-gaap-23を記録し、文書をAD Followupに移した。これは現在もExperimentalのInternet-Draftであり、承認済みRFCではない。
  • 第23版はIPv4に239.0.0.0/10、IPv6にRFC 10028のExperimental Use範囲を指定し、別々に書かれた実装が同じ空間を使えるようにした。
  • 同時に、分断の片側が同じグループ名の+1候補、もう片側が+2候補を選ぶと、アドレス同士が異なるため衝突を検出できず、復旧後もグループが分裂したままになり得ると記した。
  • 「衝突なし」は消極的な観測にすぎず、名前とアドレスが収束して参加者が再び合流した証明にはならない。
  • ローカルなグループ名収束レシートを残せば、その証拠を保てる。これはDaniel Kadeの分析案であり、IETFや草案の要件ではない。

まず計算の土台を一つにした

GAAPの履歴によると、第23版は9月3日に提出された。同日、文書のサブステートはRevised I-D NeededからAD Followupへ移り、IANAレビューはVersion Changed - Review Neededへ戻った。Datatrackerの文書ページが示しているのは、審査中の作業文書である。IESGの承認やRFC化を意味する動きではない。

第23版の変更履歴は、Éric VynckeによるIESGのDISCUSSとCOMMENTに対応したと説明する。重要なのはラベルの変化よりも、本文に現れた二つの異なる収束問題だ。一つは共通ルールで閉じられ、もう一つは開いた問題として残った。

GAAPは、中央の割り当てサービスを置かずにマルチキャストのグループアドレスを得る実験的な仕組みである。アプリケーションがグループ名を渡すと、プロトコルはSHA-256を使い、元の名前と、末尾に+1、+2、+3を付けた計四つだけを候補にする。ノードは最初の候補についてClaimを送り、周期一回分、およそ1分待つ。別のグループ名が同じネットワーク層アドレスを要求していなければ、そのアドレスを使い始められる。衝突すれば次の候補へ進む。

全参加者の割り当て表を保持しないことも設計の一部だ。他ノードのClaimをキャッシュする義務はなく、各ノードは自分のアプリケーションに関する割り当てとタイマーだけを追う。再起動時にはClaimをやり直してソフトステートを組み立てる。軽量さを保つ一方、異なる実装が同じ入力条件を共有しなければ、そもそも相互運用できない。

第22版と第23版の公式差分は、その入口を修正したことを示す。従来はアプリケーション用アドレス範囲を運用者が設定する形だった。新しい説明では、設定可能な範囲は同じ設定の実装との間でしか確実に動かない。運用者は自組織で動くアプリケーションを選べても、それぞれが組み込む独立したGAAP実装までは支配できないからだ。

IPv4実装は今後、239.0.0.0/10を必ず使う。草案は、Organization-Localスコープの拡張用ブロックを示すRFC 2365と、IPv4マルチキャスト割り当て指針のRFC 5771を根拠に挙げる。IPv6ではRFC 10028のExperimental Use Group ID、0xFE000000–0xFEFFFFFFを使う。この空間はGAAP専用ではなく、他の実験プロトコルも利用できる。

範囲の固定は明確な相互運用上の前進である。準拠した二つの製品が、互いに交わらないアドレス空間で計算を始める事態を防ぐ。ただし、共通の盤面に立つことと、同じグループ名で同じ駒を選ぶことは別である。

物理的に戻っても論理的には二つのまま

第23版が説明する分断修復は、見える衝突に対応する。分断の両側が同じグループ名に同じアドレスを使った場合、接続が戻るとClaimが届き合い、手順に従って状態を整理できる。

新たに明記されたのは、衝突に見えない分裂だ。片側で無関係なローカル衝突が起き、共通のグループ名が基本候補から+1へ移ったとする。反対側では別の衝突が起き、同じ名前が+2を選ぶ。それぞれは閉じた候補リストに従い、分断中のローカル環境では正しい選択になり得る。

接続が戻ったとき、一方はアドレスA、他方はアドレスBをClaimする。GAAPが衝突と定義する「同じアドレスを異なる名前が使う」状態ではない。そのため何も衝突せず、草案の表現どおりグループは復旧後も分裂したままとなる。解決方法は実験の未解決課題とされた。

Vynckeは以前のIESG ballotで、分断された二つのネットワークが+1と+2を使ったら検出できるのか、全員は収束するのかと質問していた。第23版は問いを仕様の境界に取り込んだ。しかし問いを記載することと、答えを実装することは同じではない。

ここでは、衝突件数ゼロが正反対の状態を表す。一つの名前が一つのアドレスを指し、参加者が合流している場合もゼロだ。一つの名前が二つのアドレスを指し、参加者が二群に分かれている場合もゼロになる。衝突がないことは負の事象を観測しなかったというだけで、ランデブーという正の性質を証明しない。

GAAPが参照するRFC 10019は、中央調整のないマルチキャスト割り当てについて、ネットワーク分断中に発生したアドレス衝突を検出し、穏当に解消することを求めている。その課題は重要だ。今回の境界は隣接する別物で、同じ名前に二つの非衝突アドレスが残る。したがって「衝突を解消した」と「名前が収束した」は別々に記録すべき結果になる。

実験が必要とするのは合流の積極的証拠

草案は成熟度を誇張していない。分散型のハッシュベース割り当ては未導入であり、だからExperimentalとしている。実験では、衝突検出と解決が実運用に十分か、規模ごとの衝突率がどうなるか、多数ノードの周期Claimがどこまで拡張できるかを確かめる。運用経験がStandards Trackへの移行を支えるか、基本的な限界が見つかって改訂が必要になれば、実験の結論になる。

同名異址の分裂も、その評価対象に含める必要がある。衝突カウンターは、別名が同じアドレスで出会った回数は数えられる。しかし一つの名前が二つのアドレスに残った回数は、そもそも衝突として入力されない。分断前後の名前、候補、アドレスと、アプリケーション参加者が再び通信できたかを直接観測しなければならない。

証拠を残すことは、中央割り当て台帳を新設することではない。実験ごとにローカルな「グループ名収束レシート」を作ればよい。必要以上に名前を開示しない識別子、分断の両側にいた試験群、各側の候補番号、選択アドレス、分断と復旧の時刻、検出経路、復旧後の到達性、修復判断と結果を結ぶ。レビュー結果は「収束を観測」「分裂を観測」「観測不足」の三つに限定できる。

このレシートは私の編集上の提案であり、GAAP、IETF、IANA、PIMワーキンググループの要求ではない。狙いは一つだけだ。悪い事象が見えなかったことを、良い性質が確認されたことにすり替えない。

Lu HengのMinimum Initial Specification, Localized Future Decisionに照らせば、固定範囲は独立実装が出会うための最小共通ルールである。希少な分裂を見つけ、記録し、直す方法は実験ごとに発展させられる。ただし結果の比較可能性と保存は共通条件にすべきだ。

Running Code Primaryは、制度上の進展と動作証拠を分ける。IANAの割り当て、文書の状態変更、DISCUSSの解消だけでは、別々のローカル衝突に遭った実装が再接続後に一つの対応へ戻ることを示せない。分断を作り、+1と+2を発生させ、回線を戻し、各ノードが実際に使った結果を保存する試験が必要だ。

第23版は、解けた問題と解けていない問題を同じ文書に並べた点で前進した。次に必要なのは、固定範囲の導入を成功の代理指標にすることではない。収束そのものを観測可能な結果にすることである。

情報源

  1. GAAP Datatracker文書ページ
  2. GAAP文書履歴
  3. GAAP第23版
  4. GAAP第22版
  5. 第22版から第23版への公式差分
  6. GAAPのIESG ballot
  7. RFC 10019：ゼロ構成マルチキャストアドレス割り当ての課題
  8. RFC 10028：IPv6動的マルチキャストGroup ID
  9. RFC 2365：管理スコープIPマルチキャスト
  10. RFC 5771：IPv4マルチキャストアドレスのIANA指針
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision
  12. Lu Heng — Running Code Primary