要約

  • 現行APNIC-127はIPv4委任の最小を/24、103/8から一アカウントが受けられる合計上限を/23とする。一方、初期LIRの適格性では/24の即時需要と、一年以内に少なくとも/23を使う詳細計画を同時に求める。
  • APNIC 62で議論予定のprop-169は、固定/23を「評価されているIPv4委任」に置き換える。公開された射程はneeds assessment、conservation、現行上限を維持し、新たな権利を作らず、より広い委任、移転、waiting listの論点を開き直さない。
  • 文言を長持ちさせるには、申請した値、審査に用いた値、登録簿へ最終記録した値を別々に残す必要がある。顧客や構成図を公開せず、保護された証拠と限定的な集計だけで反復可能性を確保できる。

プレフィックス長の数字は直感と逆に動く

/24は256アドレス、/23は512アドレスである。スラッシュの後の数字が一つ小さくなると、ブロックは二倍になる。したがって「一つ違うだけ」という読み方は、需要評価では危険である。

現行のAPNIC Internet Number Resource Policiesを見ると、この二つが同じ適格性テストに入っている。6.1節は最小を/24、103/8からの合計最大を/23とする。6.2.1節では、初期LIRが上流から得た/24を使用済みであるか、その即時需要を示すこと、過去の資源を適切に管理したこと、そして一年以内に少なくとも/23を使う詳細計画を示すことを求める。

審査対象が/23なら、この組合せは説明できる。申請が/24なら、計画の役割が曖昧になる。512アドレスの予測は、256アドレスを受ける資格の一部なのか、将来の上限までの成長を測るのか、それとも古い文言が残っただけなのか。

APNIC-127のプレーンテキストは、現時点の規則を版に固定する。文書はversion 015、2025年2月20日付、Activeと自己識別し、/24、/23、一年計画の三点をそのまま載せている。Prop-169の文章はまだここにない。

提案が公開されたこと、分かりやすい説明が出たこと、運用規則が変わったことは同じではない。この記事ではその時計を混ぜない。

Prop-169は過剰に広げず、数字だけを直す

Policy SIG公開メールに保存されたprop-169によれば、修正対象は6.2.1節の最後の一文である。「少なくとも/23」をやめ、適用されるAPNIC-127の上限の下で、「評価されているIPv4委任」を一年以内に使う詳細計画へ置き換える。

この方向は妥当だ。一つの固定値で最小と最大の双方を扱う代わりに、案件ごとの値を参照する。一年という時間軸は残り、最大量を自動的な権利にもしない。

ただし現在の状態はAPNIC 62 OPMでの議論待ちである。version 1がPolicy SIGへ出たのは2026年7月13日。会議、consensus、最終コメント、ECの行為、編集版、運用開始は別々の出来事である。

保存された提案の射程は意図的に狭い。固定/23に触れる審査メモ、ガイダンス、申請者向け資料は見直す一方、needs assessment、conservation、現在の上限は残す。新たな権利を作らず、より広い委任、移転、waiting listの論点も開き直さない。

文言だけの小さな修正でも、判断記録が保持すべき内容は変わり得る。最終プレフィックスのデータ型が同じでも、それを選んだ分母と証拠は申請・審査記録にしか残らないことがある。

NOG Allianceの中立トラッカーはprop-169を「To be discussed at APNIC 62」と記録する。これは将来の会議状態であって結果ではない。/24の例が文言のずれを示し、それ以外のIPv4政策は今回の修正範囲に入らない。

そこで残る論点は政策の大転換ではない。「評価中」の対象を、後から同じ値として読み戻せるかである。

文法上の「その」は、取引上のIDではない

英語の定冠詞も、日本語の「その委任」も、対象が一つに決まっている印象を与える。しかし申請処理には少なくとも三つの値がある。

第一は申請プレフィックス。申請者が提出した値である。第二は評価プレフィックス。審査者が一年計画の分母に使った値である。第三は委任プレフィックス。APNICまたはNIRが最終的に登録し、アカウントに付与した値である。

標準的な案件では、/24→/24→/24かもしれない。その場合でも三フィールドは無駄ではない。same-as-requestedと記録できれば、通常経路が明示され、例外だけが高コストになる。

異なる場合の重要性は明らかだ。申請は/23、評価は/24かもしれない。質疑後に申請者が値を改めるかもしれない。既存保有量から計算する残余上限が最終量を制約するかもしれない。公開資料は、これらが実際に起きたとも、頻繁だとも示していない。だから事実として主張しない。将来の規則が状態を区別できるか、という設計問題である。

残余上限は四番目の取引値ではない。適用上限から関連保有量を引いた計算である。申請を制約し得るが、申請者の希望や審査者の証拠判断そのものではない。

同じAPNIC-127は、隣接するmultihoming経路でより明示的な書き方を使う。6.2.2節は、requested addressesの25%を即時、50%を一年以内に使えることを求める。初期LIRとは別の基準なので、その割合を流用してはならない。比較から分かるのは、テスト対象を「申請された数量」と明記する文法がすでに存在することだけだ。

Prop-169が必要とするのは新しい割合ではない。値の由来、固定時点、変更記録である。

即時、一年、二年は同じ予測ではない

5.2.1節は、委任申請に即時、一年、二年の使用見積りと裏付け文書を求める。一般的な目安として即時25%、一年50%を示す。二年需要を確信を持って予測できないend userには、APNICまたはNIRが一年需要に足りる量だけを委任できるともいう。

ここでは三つのものを混同してはならない。予測の期間、証拠の確信度、決定されるプレフィックスである。二年予測が不確実でも、即時需要が偽になるわけではない。一年分だけ委任したとしても、二年計画の不正を意味しない。

「評価されている委任」がいつ固定されるかを示さなければ、提出時の申請値、即時需要を見た後の候補値、二年予測を割り引いた最終値のいずれにも読める。

subsequent delegationの7節は参考になる。過去利用、文書化された計画、コンプライアンスにより最長一年の需要を満たし、より短い期間を採用するならLIRへ期間と理由を知らせる。変数を狭めたなら、その値と理由を残す。この原則をプレフィックスにも適用すればよい。

公開案内の役割は、個別判断の再現ではない

APNICのIPv4 post-exhaustion案内は、103/8からの合計最大が/23であり、最大まで受け取れば追加は得られないと説明する。最大未満の既存MemberはMyAPNICから申請でき、/23を超える需要にはtransferを案内する。

これは利用者に必要な入口情報である。だが個別申請で提出された値、審査分母、部分的な結果の理由までは表示しない。表示しないこと自体は欠陥ではない。公開ガイダンスと保護された判断記録は別の仕事をする。

希少なfree poolでは理由の違いが重要になる。小さいブロックになった原因は、残余上限、適格性、証拠不足、申請者の修正で意味が異なる。結果を一語に畳むと、後の審査者が誤った先例を学ぶ。

2019年、上限だけが/23になった

JPNICのインターネット歴史年表は、APNIC 47でprop-127がconsensusとなり、その後施行された経緯を記録する。JPNICは返却在庫からの最大/22割り振りを終了し、この経路を/23へ合わせた。現在の/24最小値は、この年表ではなく保存された現行政策が根拠である。

これは現在の二つのサイズが制度上並ぶ理由を説明する。ただし、古い一年計画文が残った動機や、個別申請の扱いを証明するものではない。

2023年には別案もあった。Prop-152は、当時のavailable poolが尽きた後に最大を/24へ下げ、新規アカウントだけへ委任する案だった。APNIC 56でconsensusに至らず、2024年2月にabandonedとなった。現在の最大はこれによって変わっていない。

そのimpact assessmentは、生の在庫数を政策文へ埋め込むと議論中にも変わり得る、と指摘した。ここから導ける教訓は限定的である。固定数を変数にするのはよい。ただし変数には出典、版、固定時点が必要だ。

十六項目で十分である

審査を再現可能にするために、ネットワーク設計書を公開する必要はない。保護領域に証拠を置き、公開部分はスキーマ、限定的な理由コード、集計に絞ればよい。

必要な記録は次の十六項目である。

  1. 申請IDと時刻。 安定したrequest ID、提出時刻、改訂・置換された申請へのリンクを持つ。
  2. 規則のID。 APNIC-127の版、条項、発効日、判断に使った実装版を保存する。
  3. 判断主体。 APNICかNIRか、審査ロール、委任経路を明示し、「システム」で責任を消さない。
  4. 申請者区分と適格経路。 initial LIR、multihoming、critical infrastructure、IXPなどを区別する。
  5. 関連保有量。 103/8保有、その他の関連空間、残余上限計算と各入力の政策範囲を記録する。
  6. 申請プレフィックス。 プレフィックス長、アドレス数、申請改訂を一体の値として保存する。
  7. 即時需要の基準。 数量と機能を保護された証拠参照へ結び付け、一種類の構成図を正解にしない。
  8. 一年計画の分母。 評価対象のプレフィックスとアドレス数を明記する。新文言の中心となる欄である。
  9. 二年予測の状態。 提出済み、確信を持って見積り不能、非該当を区別し、根拠条項を持つ。
  10. 証拠の保管。 文書ID、hash、アクセス区分、保存期間、privacy処理、訂正履歴を残す。
  11. 評価プレフィックス。 正確な量、それが判断分母になった時刻、許容した規則を記録する。
  12. 差異コード。 申請と評価が異なるなら限定的理由を事実に結び付け、同じならsame-as-requestedとする。
  13. 質疑履歴。 重要な質問、回答、時刻と、それにより変わった項目を残す。
  14. 最終委任プレフィックス。 最終量、実プレフィックス、登録イベント、時刻、評価値との差を結ぶ。
  15. 結果と訂正経路。 granted、partially granted、declined、withdrawn、pendingを分け、理由とreview結果を持つ。
  16. privacy-safeな集計。 申請→評価→委任の経路、処理時間帯、差異理由、撤回、訂正を個人非識別で数える。

これはbusiness planの公開台帳ではない。Hashは原文公開を意味せず、remaining-entitlement-limitという理由コードに顧客名は要らない。秘密を守ることと判断を再現することは両立する。

共通記録を厳密にし、ネットワークは現場へ返す

Minimum Initial Specificationは、共通層を小さくすることと曖昧にすることを区別する。共有が必要な最少事実だけを、厳密に定義する。後の運用判断はrunning networkの側に残す。

申請ID、規則版、数量、判断主体、登録状態遷移は共通事実である。顧客構成、ルータ、アドレス設計、移行方式、製品、商用時期は運用者の領域だ。APNICが希少な未委任プールの需要を確認するとしても、証拠様式をアーキテクチャ承認へ拡大する必要はない。

この境界は申請者にも効く。「将来成長」だけでは数量を証明できない。審査者にも効く。「詳細が必要」というだけで無制限に私的情報を求められない。質問も結論も、同じ規則と数量へ戻らなければならない。

APNICのPolicy Development Processはopen、transparent、bottom-upを掲げ、政策議論と結果を公的記録にする。プロセスを通る対象が途中で別の値になれば、手続の透明性だけでは足りない。変数の文章へのconsensusは、非公開の全ての代入方法へのconsensusではない。

政策本文は短くてよい。実施記録は正確でなければならない。

出典

分からないことを残す

公開資料には、固定/23文のためにAPNICまたはNIRが特定の申請を拒否、遅延、縮小した事例はない。申請値、評価値、委任値ごとの件数も、現行の内部フォームも示されない。したがって、ここで確認できるのは文面と記録設計の穴であり、不正な運用の実績ではない。

APNIC 62の結果も未確定である。新versionが対象をより明確にする、現行案を維持する、範囲を変える、いずれもあり得る。会議前の文章を、会議後の事実として書いてはならない。