要約

  • バージョン2は広範な再評価を意図的に外し、提案者も、必要量が変わらない既存保有者には影響がないと説明した。
  • 必要量が増えれば、次のnibble境界への拡張、または連続空間がない場合の新規割り当てと6か月以内の旧割り当て返却が問題になる。
  • 14項目の移行記録と5本のテストベクトルで境界を共有し、トポロジー、顧客情報、移行手順はローカルまたは保護領域に残すべきだ。

変わらない九本と、一本の申請

2025年3月、ある参加者は、自分のネットワークが異なる九本の/48 PI割り当てを持つと述べ、できればリナンバリングなしで統合したいと書いた。データベースオブジェクトとDNSの双方に触れている。

これは本人に帰属する発言であって、現在の保有状況を第三者が検証した結果ではない。九本が地域全体で一般的だとも、不正・浪費・規約違反だとも言えない。

それでも例として有用なのは、旧状態に厚みがあるからだ。九本のプレフィックスは、経路、逆引き、ACL、監視、アプリケーション設定に別々の履歴を残している可能性がある。将来一本の大きな割り当てができても、その行だけでは古い九本がどう扱われたか分からない。

動かさないことも明示的な設計である

2025年10月のバージョン2告知は、初版から何を削ったかを明記した。提案されていたEnd Siteの定義と、追加・拡大申請時の必要量再評価を外し、文章を簡潔にしたという。偶然の欠落ではない。

翌年3月、複数PIを持つものの必要量が増えない保有者の扱いが問われた。提案者の回答は、必要量が変わらなければ既存保有者に影響はない、というものだった。

この不介入は重要だ。新しい政策の形に合わせるためだけに、正当に動いているネットワークへ移行リスクを課してはならない。レジストリは番号資源を調整するが、各ルーターやDNSゾーンの作業日程を所有しない。

問題は、静止状態を守ることではない。そこから出るイベントを、誰でも同じように読めるかである。

追加需要が境目を作る

第7.1.2節をめぐる議論では、一つ以上のPIを持つ主体が追加空間を必要とした場合、次のnibble境界への拡張を求める流れが示される。既存割り当ての隣に十分な空間がなければ、新しい割り当てを受け、旧割り当てを6か月のリナンバリング期間内に返す。参加者はその文言を引用し、6か月では短いのではないかと論じた。

本稿は6か月、12か月、24か月のどれが正しいかを決めない。期限超過や障害が実際に起きたとも述べない。確認できるのは、申請が次の状態列を起動することだ。

旧集合 → 需要変更 → 連続性判定 → 拡張または置換 → 新旧併存 → 返却。

最終行だけを見ても、起点となった申請、適用版、旧集合の範囲、連続性判定の時点、返却時計の開始、訂正の履歴は復元できない。

まだ実装済みの政策ではない

2026年6月15日、共同議長は8人の支持とReview Phaseへ進める合意を報告した。軽微な編集を反映し、影響分析と政策案を公開するとしている。

このメールが証明するのは次段階へ進む意図であり、その後の開始、合意、採択、実装ではない。本稿の証拠集合から、それ以上は断定できない。

だからこそ今が設計の時間である。最初の本番案件の処理方法が、結果として共通仕様になる前に、移行の意味と証拠を政策文書と影響分析へ書ける。

六か月は一個の時計ではない

RFC 4192は、IPv6リナンバリングを一斉切替ではなく、make-before-breakとして説明する。新しいプレフィックスを準備し、アドレスを追加し、経路・DNS・DHCP・設定を段階的に更新し、新旧を並行稼働させ、検証後に旧側を外す。

RFC 5887は、その作業が今も難しい理由を挙げる。静的アドレスは各所に埋まり、利用者の障害報告まで見つからないことがある。併存中はポリシーと監視が双方を扱う必要があり、複数プレフィックスをうまく扱えない運用ツールもある。

両RFCはRIPEの政策を規定しない。ただし、レジストリの返却日と現場の移行が同じイベントの別レイヤーであることは示す。共通記録は両者を結ぶべきであり、レジストリが現場を支配するためのものではない。

境界を監査モデルにする

時点付きの旧PI集合をP0、それまでの需要をN0、追加・拡大申請をq、適用文書をHとする。予約・連続性の結果をC(q, P0)、選ばれた拡張・置換経路をT、結果資源をP1、併存・返却・完了をDと置く。

監査対象は次のように書ける。

E = G(P0, N0, q, H, C, T, P1, D)。

これはTheo Marchの分析モデルで、RIPE NCCが公開したスキーマではない。q以前のP0は動かさない。q以後は、どの要素も切り離さず、訂正があれば旧記録を残して差し替える。

14項目の成長移行記録

  1. 記録票の識別子。 安定IDとスキーマ版。
  2. 適用規則。 提案・政策番号、文書版、真正なダイジェスト、状態、発効日。
  3. 旧状態の基準時。 旧集合を観測した日時とタイムゾーン。
  4. 保有者と申請。 公開可能な参照、案件ID、認証済み提出時刻。私的連絡先は除く。
  5. トリガー種別。 変更なし、追加、拡大、訂正の別と、第7.1.2節が適用される理由。
  6. 旧PI集合。 順序付きオブジェクトID、長さ、状態、レコードダイジェスト。
  7. 需要評価。 承認・拒否・未確定、政策上の単位、限定的な理由コード。生のトポロジーは保護できる。
  8. Nibble目標。 申請値、評価値、差がある場合の理由。
  9. 連続性証拠。 予約スナップショットID、調査した隣接範囲、時刻、決定的結果。無関係資源は露出しない。
  10. 選択経路。 拡張、新規置換、現状維持、拒否、追加証拠要求。
  11. 結果資源。 割り当てID、プレフィックス、オブジェクト版、稼働開始時刻。
  12. 併存時計。 開始、返却期限、タイムゾーン、規則に基づく停止・延長ID。
  13. 返却集合と終結。 各旧割り当ての状態、完了証拠、未解決例外。
  14. 訂正連鎖。 決定主体、見直し・訂正経路、差し替え元、最終状態。

公開部分は限定コードと識別子で足りる。顧客、詳細トポロジー、機器一覧、利用証拠を外へ出す必要はない。

本番より先に五つのテストを置く

  1. 複数の旧PI、需要増なし。 トリガーなし、返却時計なし。
  2. 連続拡張可能。 旧集合、予約判定、拡張後オブジェクトが一つの記録になる。
  3. 連続拡張不能。 新規割り当て、明示的な返却集合、併存期間を出力する。
  4. 稼働前の申請撤回。 新資源が有効になる前なら、返却時計を起動せず終結する。
  5. 旧集合または開始時刻の訂正。 静かな上書きではなく、追記型の差し替えを行う。

共通にするのは結果の意味であって、実装言語や画面ではない。別のツールでも同じ入力なら同じ境界を出せるようにする。

共通層を小さく保つ

HENG.LU Note 64にならえば、共有すべきものは識別、相互運用、安全に必要な最小限でよい。旧新資源、規則版、トリガー、連続性、分岐、時計、終結、訂正がそれに当たる。

トポロジー、トラフィック、顧客、利用資料、機器、商業目的、作業順序はローカルまたは保護領域に残る。コミュニティが規則を決め、RIPE NCCが自らの判断を記録し、保有者が事実を提出してネットワークを動かす。第三者は検証できるが、割り当てや経路変更の権限を得ない。

そして、必要が変わらない保有者は移行しない。記録票のために統合を強いるのではなく、権限ある移行が生じたときだけ、その意味を持ち運べるようにする。

出典

証拠の限界

確認済み：バージョン2は広範な再評価を削除した。提案者は需要不変なら影響なしと述べた。議論文には成長時の拡張・置換と6か月がある。共同議長は次段階への意図を示した。IPv6リナンバリングには併存状態がある。

推論：最終プレフィックスだけでは、トリガー、連続性、返却集合、時計を再構成できない。

提案：14項目の記録票と5本のテストベクトルを実装前に公開する。

不明：Review文書、影響分析、最終期限、起算イベント、例外・延長、内部案件スキーマ、対象数、本番実装。