要約

  • RFC 9812 は、IETF 予約 IPv6 空間の大規模かつ非定型な解放について、IETF Stream の RFC、IETF Last Call、IESG による合意確認を必須にした。
  • その手続が証明するのは上位レジストリ変更の権限であり、事業者への割当、到達可能な経路、製品実装、世界的な政治的委任ではない。

RFC 8126 の Reserved は、日常語の予約とは違う。値は割り当てられておらず、割当に利用できない。将来の特別用途や名前空間の拡張に備えて留保される。予約済みの席ではなく、まだ客席に出していない区画に近い。

RFC 4291 が定める IPv6 空間では、現在のグローバルユニキャスト割当は 2000::/3 に限定される。RFC 7249 は全体のおよそ八分の七を IETF 予約と説明した。IANA の上位レジストリにも、Global Unicast と Reserved by IETF が別々に並ぶ。

ところが、その巨大な留保を開く規則は IESG approval だった。RFC 1881 は IANA に IPv6 アドレス管理を委ねたが、将来の解放手続を定めなかった。後に表示された IESG Approval は、RFC 8126 上、RFC の発行を必須としない。

IESG は資料を求められるが、必ず求めるわけではない。この手続は他の方法が間に合わない場合などの例外的な逃し弁で、公開レビューを回避するためのものではない。RFC 9812 が問題にしたのは、違反の実例ではなく、例外の裁量が予備空間の標準的な入口として見えていた構造だった。

RFC 9812 は登録手続を IETF Review に変更した。割当案はワーキンググループ文書または Area Director Sponsored 文書として IETF Stream に入り、IETF Last Call を経て、IESG が IETF 合意を確認する。相互運用性を壊すか、不適切なプロトコル拡張になるかを公開の場で検討できる。

重要なのは「コミュニティ」という語ではなく、残る記録である。正確なプレフィクス、目的、文書版、スポンサー、Last Call、異論、修正、IESG の処分、最終 RFC、IANA 指示、更新時刻が一つの連鎖になる。文書化が任意の説明から許可条件へ変わった。

さらに RFC 9812 は Standards Action を選ばなかった。Standards Action は Standards Track または BCP の RFC に限定される。一方 IETF Review は、原則として Informational や Experimental など他の IETF Stream RFC も認める。新しい範囲を開くことが、新しいプロトコル標準を必要とするとは限らないからだ。

重要な決定を何でも標準化と呼べば、文書の意味が壊れる。RFC 9812 は、レビューの強さと文書分類を分離した。RFC なしでも可能な執行部裁量は弱すぎる。標準文書だけに限定するのは狭すぎる。その間に IETF Review を置いた。

実例が 5f00::/16 である。RFC 9602 は SRv6 SID 用の範囲を求め、6MAN ワーキンググループと IETF プロセスを通過した。IANA は IPv6 Special-Purpose Address Registry に記録した。RFC 9812 は、この先行例が IETF Review の実行可能性を示したとする。

ただし、レジストリ行は運用の証明ではない。RFC 9602 は Globally Reachable を False とし、運用慣行は今後の作業としている。ベンダー実装、BGP 受理、フィルタ解除、パケット配送は別に確認しなければならない。子の /16 が特別用途になっても、親の予約範囲全体が一般利用へ開くわけではない。

IPv6 Global Unicast Address Space が別レジストリなのも、主張が違うためだ。上位状態、特別用途、RIR 割当、ROA、route object、BGP 観測は、それぞれ別の証拠である。

RFC 7020 は番号資源システムの役割を分ける。IANA は割当階層の頂点を管理し、RIR は地域サービスを担う。RFC 7249 は非予約のグローバルユニキャスト割当を RIR の手続に置く。RFC 9812 は日常の RIR 政策を IETF に移していない。予約状態を変える、その前段だけを対象にする。

RFC 2860 に照らせば、IANA は IETF 方針に沿って技術パラメータを登録する。その更新は方針を忠実に実行した証跡であって、所有権でも、事業者の同意でも、稼働証明でもない。

Heng Lu のマルチステークホルダーの蜃気楼は、参加と委任を区別する。IETF Review も世界の利用者を代表する議会ではない。正当化できるのは、共有プロトコル空間の変更が IPv6 実装の相互運用性に影響するため、技術的な公開レビューを課すところまでである。

最小初期仕様の観点では、RFC 9812 は共通層を細く保つ。予約空間を開く手続だけを共通化し、製品、フィルタ、経路、採用は各運用主体に残す。

現実の層で並べれば、提案、合意、RFC、IANA 更新、下流割当、ROA、経路受理、パケット結果は連続するが同一ではない。稼働コード優先は、最後の意味を実装と観測に戻す。

RFC 9812 は RFC 1881 の索引分類も正した。Legacy と表示されていたが、IETF Last Call を経た IAB・IESG 共同文書で、RFC 8729上は IETF Stream に属する。索引修正は過去の委任を新設せず、出所を正しくする。

セキュリティ節は直接の影響を主張しない。慎重な割当手続が運用上のアドレス説明責任に必要だと述べるだけで、将来の用途を安全と認定しない。この抑制こそ記事の境界でもある。

RFC 9812 は、八分の七を配った文書ではない。大きな留保を動かすなら、公開され再検証できる手続を通せ、と定めた文書である。そしてその手続が終わっても、ネットワークの仕事はまだ始まっていない。

情報源