要点

  • 2018年のAFRINIC実装経験報告には、順番に資源を埋める規則と同時に必要な冗長性の衝突が一件記録されている。匿名のEnd Userは第2データセンター用に追加/24を求めたが、全体利用率が90%に達せず不適格とされた。
  • Last Call中のAFPUB-2026-IPv4-002-DRAFT02は、既存資源では実用的に処理できない技術目的について90%条件を免除できるようにする。ただし、共通の証明規則は「十分に文書化された正当化」にとどまり、会議でも全案件共通の書類一覧は置かないと説明された。
  • 必要なのはネットワーク設計を固定する様式ではない。規則版、通常計算、技術分類、証拠の保管、審査の往復、理由コード、訂正・不服申立てを残す、保護された版付き受領票である。

2018年に止まった第2拠点

提案の出発点をたどると、2026年より前に行き着く。AFRINICのAFRINIC-29 Policy Implementation Experience Reportは、Hostmasterが直面した事例を一枚のスライドに置いている。

End User会員がデータセンター冗長化のため追加のIPv4 /24を申請した。既存割当ての利用合計は90%未満だった。Soft Landingに対する当時の運用解釈では追加資源を受けられず、第2データセンターを設置できない、と報告は述べる。

この記録から読める範囲は狭い。会員名、国、工事日程、元のプレフィックス、電源や回線の分離、別設計を退けた理由、その後の判断は分からない。すべての冗長拠点に新しい/24が必要だとも証明しない。

それでも、規則の測定対象がずれていることは分かる。利用率は既に持つアドレスの状態を測る。冗長性は、片側が故障する前にもう片側が動いているという同時性を求める。前者を順番の条件にすると、後者を作る入口そのものを閉じる場合がある。

例外は提案されたが、まだ政策ではない

NOG Allianceの中立的な提案トラッカーはAFPUB-2026-IPv4-002-DRAFT02を、より広いUnder discussionとして収録している。一方、AFRINIC-37の会議録画には、共同議長がrough consensusを認定しLast Callへ進めた記録がある。Draft 1は2026年5月6日、Draft 2は6月16日付で、6月24日に提示された。8月23日時点でも、採択・実装済みの例外ではない。

通常の90%条件は残る。Exhaustion Phaseで追加のIPv4 allocationまたはassignmentを受けるLIRとEnd Userは、以前に受けたすべてのIPv4資源について90%以上の利用を示す。既存資源を持たない新規申請者の最初のrequestは従来どおり対象外だ。

Draft 2が加えるのは例外である。既存プールでは実用的に処理できない、または既存プールに技術的制約を生じさせる、立証された重要な技術目的があれば利用率条件を免除できる。冗長性、高可用性、IPv6移行機構、新拠点への展開が例として挙がる。この条項上、該当requestは最初のallocationまたはassignmentとして扱われる。

最後に、濫用を防ぐ証明条件が一文だけ置かれる。正当化は、AFRINICが適合を検証できるよう十分に文書化されなければならない。

単にhigh availabilityと書くより厳しい。申請者は根拠を出し、AFRINICは確かめる。しかし「十分」が満たされたとき、どの事実を最低限残すのかは見えない。

百分率は明示され、例外の型は明示されない

現行Consolidated Policy Manualはv1.6をcurrentとする。90%という通常条件に加え、申請証拠の一般原則もある。engineering、subnetting、topology、routing planを提出でき、予測は現実的で説明可能でなければならない。規則と実務は所在地、国籍、規模などによらず公平に適用されるべきである。公開登録に不要な商業情報には秘密保持が求められる。

したがって、証拠を扱う土台がないわけではない。欠けているのは新しい例外の型だ。

同じ利用率の二社を考える。一社は顧客契約上の都合で別都市を好む。もう一社は、電源と経路の共通障害を避けるため二つの翻訳機能を同時に起動しなければならない。両社とも申請書に「冗長化」と書ける。既存資源が本当に使えないか、constraintがtechnicalかoperationalかは、名詞の下の事実でしか区別できない。

共通項目は専門判断を自動化しない。専門判断が何を見て終わったかを保存する。その役割に絞れば、柔軟性と再現性は対立しない。

書類を一種類にしないことと、記録形式を持たないことは別だ

AFRINIC-37の会議録画では、90%未満の複数拠点申請にどんな技術文書が必要かという質問が出た。提案者は、IPv6移行とmulti-site deploymentでは必要証拠が違うため、単一の一覧は作れないと答えた。審査はスタッフとのinput/outputの対話になるという。

これは合理的だ。データセンターのトポロジー図はtranslator poolの容量を証明しない。機器の発注書は障害領域の独立性を証明しない。トラフィック予測はrouting dependencyを示さない。

一方、提案を支持する参加者からも、冗長性や高可用性を言えば誰でも追加資源を求められるほど文言が広いとの懸念が出た。提案者は、例を細かく並べれば正当な新設計を排除し、スタッフをmicromanageすると反論した。Head of Member Servicesは、対象となり得るtechnical constraintと、対象外のoperational constraintを明確に分ける必要があると述べた。

つまり、会議は万能チェックリストも無構造な裁量も選んでいない。だが、その間をつなぐ共通インターフェースもまだ書いていない。

共同議長は会議でrough consensusを認定し、Last Callへ進めた。録画にはSecretariatがその段階でutilisationの定義を共有するともある。中立トラッカーは広い状態表示のままで、本稿の公開証拠からはratification、implementation、項目単位の例外schemaを確認できない。別の場所に定義が一度も出なかったという断定ではない。提案文と会議記録だけでは判断構造を復元できない、という限定した観察である。

safeguardはメールの中に置かれた

提案の発表と議論は、「十分な文書化」という語にsafeguardを置いている。

候補文は二つの関係を要求する。technical requirementが示されること。そして、そのrequirementが既存資源では実用的に処理できないことだ。構造にすると次のようになる。

技術機能 → 既存資源では処理不能 → 追加IPv4 slice

機能は何か。どの既存blockを検討したか。再利用、renumbering、配置変更がなぜ現実的でないか。新しいsliceはどのsiteまたはfailure domainに対応するか。並行稼働はいつまで必要か。どの事実が説明を反証するか。これらを残さなければ、safeguardはticket内の会話としてしか存在しない。

discretion、理由、不服申立てを分ける

会議記録は審査を万能書類ではなくinput/outputの対話として描く。判断がfinalだとも、特定の法的appeal権があるとも証明していない。専門的discretion、残すreason、適用される訂正・review経路は、別々の設計選択である。

ここでは三つの機能を区別できる。Discretionは機械判定できない事実を評価する余地。Reasonはその余地をどう使ったかの記録。Appealは規則、事実、reasonの接続を検査する経路である。

最初の機能を保つために、後二つを消す必要はない。決定記録のない訂正・reviewは、同じ会話を別の席で再開するだけになる。Architecture、既存資源の再利用可能性、request size、証拠の品質、constraint分類、rule versionのどれが問題だったのか、双方が同じ記録を見られなければならない。

multi-PoPの例は自動的な権利ではない

提案発表はmulti-PoPの464XLAT deploymentを動機となる例に使う。これは設計scenarioであって、会員networkの監査でも、新規資源への自動的な権利でも、普遍的topologyでもない。示せるのはより狭い点だ。総利用率が順番型の閾値に届く前に、技術機能を複数のfailure domainで同時稼働させる必要はあり得る。

RFC 6877の464XLATは、core側のstateful translationとedge側のstateless translationを組み合わせ、IPv6-only networkから限定的なIPv4 connectivityを提供する。Informational RFCであり、四PoP、各site二台、特定prefix sizeを義務付ける文書ではない。

共通規則が尋ねるべきなのは製品名ではない。どのtranslation functionとfailure domainを新資源が支えるのか、既存sliceではなぜ足りないのか、需要をどう見積もったのかである。配置とrouting designはoperatorに残せる。

最小仕様は薄い曖昧さではなく、狭く厳しい仕様だ

Lu HengのMinimum Initial Specificationは、共有しなければならないdeterministicな最低事項と、running operatorに残す将来選択を分ける。

有限なIPv4 poolを管理するAFRINICには、追加delegationのneedを確かめる正当な役割がある。Uniqueness、registration accuracy、公平な適用にはcommon ruleが要る。しかしdata-centre vendor、NAT64製品、内部経路、工事順序までcommon invariantになるわけではない。

解は、厚い設計規則でも形容詞一語でもない。全決定に共通する項目だけを固定し、値とattachmentは各architectureに合わせる。機密資料は保護し、外部にはschema versionとprivacy-safeな集計だけを出す。

例外受領票の十八項目

以下は本稿が提案するminimum interfaceであり、既存のAFRINIC formではない。

  1. Requestまたはticket ID。 一件の申請と証拠、対話、結果を結ぶ。
  2. 規則のidentity。 Policy、draft、implementation versionと適用paragraphを保存する。
  3. 申請者とrequest type。 LIR／End User、allocation／assignment、initial／additionalを区別する。
  4. 通常baseline。 本来適用されるportfolio snapshotと90%計算を凍結する。
  5. Exception class。 冗長性、高可用性、IPv6移行、新site、その他のtechnical purposeを明記する。
  6. Functional unit。 保護記録ではsite、PoP、機能を特定し、公開時は仮名または集計labelにする。
  7. Requested slice。 Prefixまたは数量を各site・functionへ対応付ける。
  8. Concurrency window。 同時導入が必要な理由と新旧資源の併存期間を記す。
  9. Impracticality relation。 Topology、routing、translation、failure domainのどれが既存資源の利用を妨げるか説明する。
  10. Address plan。 各sliceのcurrent／forecast use、単位、期間を残す。
  11. Unused-space analysis。 未使用保有資源を列挙し、reuse、renumbering、別配置を退けた理由を記す。
  12. Evidence custody。 File、hash、controller、access boundary、retentionを定め、機密topologyを公開metadataにしない。
  13. Dialogue history。 Reviewer question、applicant reply、timestampを上書きせず追加保存する。
  14. Classificationとreason。 Technical、operational、mixedをreason codeと文章で示す。
  15. Decisionとcondition。 Approval／denial、granted size、条件、期限、follow-up reviewを記す。
  16. Correctionとappeal。 Notice、事実訂正経路、deadline、適用される不服申立てを結ぶ。
  17. Supersession。 後のpolicy・procedure versionへlinkし、決定当時のruleも残す。
  18. Public aggregate。 会員名やtopologyを出さず、件数、分類、処理時間帯、結果、訂正を監査可能にする。

十八項目は四PoP設計の真偽を自動判定しない。判断を再現可能にする。次のreviewerは同じportfolio、同じconstraint、同じ未回答事項を見る。Applicantは履歴を書き換えず誤情報を訂正できる。AFRINICはclass、member size、review processによる説明不能な差を集計できる。

例外を運用する前に、残すものを決める

Draft 2が扱う方向は妥当である。第1拠点が90%近く埋まるまで第2failure domainを待たせれば、冗長性は故障後にしか作れない。2018年の記録は、その順番が実際の申請評価で問題になったことを示す。

同時に、technical purposeは宣言ではなく立証でなければならない。問題はprofessional judgmentの存在ではない。Judgmentが終わった後に何が残るかを、共有規則がまだ述べていないことだ。

「十分に文書化」は対話の開始条件にはなる。Scarce resource exceptionの永続記録にはならない。Waiverがoperationalになる前に、AFRINICはminimum fields、protected evidence、reason codeを公開すべきだ。そうすればregistryはnetworkを設計せずpoolを守れ、operatorは証拠規則を自作せずnetworkを設計できる。

情報源