要約

  • RFC 9812 は、IETFが保留するIPv6空間の将来の非定常利用について、IESG Approval を IETF Review に置き換える。変わるのは次の判断に必要な公開審査の経路である。
  • RFCがIANAに直接求めるのは登録手続の更新であり、プレフィックス、用途、RIRへの委譲、経路広告、実装を決めてはいない。
  • 常設方針、後の申請、IETF判断、正確な登録簿変更、委譲、運用観測を分ける「保留から利用までの受領記録」が必要だ。これはDaniel Kadeの編集提案でありRFCの項目ではない。

IANAの表にある一行は、資源が動いたように見えやすい。IPv6 Address Space 登録簿は RFC 9812 を参照し、多くの範囲を Reserved by IETF と表示する。そこに「より厳格な審査」という説明が加わると、IETFが巨大なアドレス範囲を新たに開放したかのような物語が生まれる。

実際に変わったのは、将来その判断をするための入口である。従来の IESG Approval は、必ずしもRFCを必要としない個別承認を許した。IETF Review では、IETF streamのRFC、IETF Last Call、IETFの合意を確認するIESG承認が要る。証拠の面は広がったが、審査対象となる具体的な申請はRFC 9812には存在しない。

保留は利用可能という意味ではない

現在のグローバルユニキャスト用範囲は 2000::/3 であり、IANAからの割当は別のGlobal Unicast登録簿に記録される。RFC 9812 が扱うのは、それ以外に大量に残るIETF保留空間を将来非定常に使う場合の方針である。

Reserved by IETF は状態と権限の所在を示す。申請可能、民間所有、RIRへ委譲済み、経路到達可能、あるいは将来開放する約束を意味しない。実際、IANAの頂点表には、保留範囲の内部に部分的な特殊用途や過去の用途があるとの注記もある。一つの見出しから、その下の全ビットが同じ運用状態だとは言えない。

RFCは全空間のおよそ八分の七が保留されると説明する。この規模は重要だが、厳格な門の後ろに置かれた量であって、門を交換した時に外へ出た量ではない。

二つの方針は異なる証拠を要求する

RFC 8126 によれば、IESG Approval は例外的な後備手段である。RFCがなくてもIESGが個別に承認でき、必要に応じて資料や意見募集を求められる。しかし、他の公開審査を回避する常用経路ではない。

IETF Review では、割当はIETF stream RFCを通じてのみ行われる。文書はワーキンググループまたはAD-sponsoredとしてIESGへ導かれ、IETF Last Callを経て、IETFの合意としてIESGに承認される。Standards Trackである必要はない。新しいアドレス範囲を開く判断には共同体審査が必要でも、新プロトコル標準を定義しない場合があるからだ。

従ってRFC 9812が強めたのは、権限を証明する最低条件である。将来の用途を事前承認したのでも、IESGからIETFへアドレスの所有権を移したのでもない。具体的な申請には、資源、目的、登録簿操作を記した別の文書が必要になる。

5f00::/16 は過去の例である

RFC 9812 は RFC 9602 を例に挙げる。RFC 9602 は 5f00::/16 をSRv6 Segment Identifiers向けに割り当て、IPv6 Special-Purpose Address Registryへ追加した。ワーキンググループ文書として処理されたため、後に明文化されたより厳しい経路を既に満たしていた。

日付を保てば意味は明瞭になる。RFC 9602 は2024年10月、RFC 9812は2025年10月に公開された。後者が 5f00::/16 を割り当てたのではない。SRv6の用途やブロック幅を将来の標準形にしたわけでもない。既に完了した事例を、今後の常設ルールを説明する証拠として使った。

このプレフィックスは先例として記録すべきであり、RFC 9812の新規成果として数えてはならない。

方針の行は実行履歴ではない

IANA登録簿には、現在の処分、参照文書、日付、将来変更のための方針が同居する。それらは関連するが、同じイベントではない。

RFC 9812 の IANA Considerations が直接求めるのは、IPv6 Address Space登録簿の手続きを IETF Review に更新することだ。その変更が完了すれば、登録簿は次の申請に適用される基準を証明する。申請が存在することは証明しない。

後のIETF RFCが具体的プレフィックスを承認したなら、そのRFCが指示の証拠になる。IANAの行が変われば実行の証拠になる。さらにIANAからRIRへの委譲、BGP広告、到達性、製品対応があるなら、それぞれ別の出典と日時が必要だ。

これを「IETFがIPv6を割り当てた」とまとめると、RFC 9812 が強めた公開審査の所在も、実際の運用状況も見えなくなる。参照番号は、フィルターが範囲を通すことも、実装が用途を支えることも証明しない。

古い文書の分類修正が示すもの

RFC 9812 は RFC 1881 の分類も正す。1995年の文書はIABとIESGの共同出版でIETF Last Callを経ていたが、RFC indexではLegacyと誤表示されていた。後のRFC series規則に照らせばIETF Streamに属する。

表示の訂正は1995年の判断を再実行せず、その後の割当も変更しない。権限の由来を正しく読めるよう、記録を修復する。手続の実態とメタデータがずれること、そして訂正自体も元の決定と区別すべきことを示している。

新しい方針も同様だ。どの登録簿のどの欄が、どのRFCによって、いつ変わったかを残す。手続ラベルから資源移動を推測しない。

「保留から利用まで」の受領記録

ここで提案する reservation-to-use receipt は、RFC 9812 の要件でもIANAへの新しい指示でもない。判断の段階を混同しないための編集・運用上の証拠枠である。

第1層は常設状態を保存する。正確な登録簿、保留範囲、適用方針、根拠文書、観測時刻である。第2層は後の申請を保存する。対象プレフィックス、用途、文書、stream、sponsor、ワーキンググループ状態、変更予定の元と先の登録簿を含む。

判断層では Last Call、重要な改訂、合意判断、IESG承認、最終RFCを分ける。実行層ではIANAの変更ごとに旧行、新行、参照、日付、作成・移動・分割・再分類の別を残す。RFC公開だけで実行完了としない。

運用層はさらに独立する。RIRへの委譲、経路広告、フィルタ観測、実装や展開の主張を、それぞれの証拠へ接続する。approved but not registered、registered but not delegated、announced but not broadly reachable は正当な中間状態である。

こうすれば、「方針が変わった」「申請が審査された」「文書が承認された」「IANAが行を更新した」「運用が始まった」という動詞を、その動詞だけの証拠で閉じられる。

問責は段階の間にある

RFC 9812 は直接のセキュリティ影響はないとしつつ、慎重に審査された割当機構が運用上のアドレス問責に必要だと述べる。公開審査が必ず正解を出すという意味ではない。後から権限と目的を再構成できない割当のコストを指している。

厳しい手続でも、誇張の誘因は残る。制度側は方針変更を実装成果に見せたい。提案側は合意を普及に見せたい。登録簿は簡潔な現状表示を優先し、運用者は割当を普遍的利用可能性と読みたくなる。

必要なのは不足か豊富かという物語ではなく、帰属できる状態遷移である。RFC 9812 が完了したのは最初の一歩、すなわち大きな判断のルール変更だ。その先の各状態は、別々に獲得されなければならない。

出典