要約

  • IANAの台帳では、AFRINIC向けにAS328704–AS329727とAS329728–AS330751という隣接する二つの1,024番号ブロックが登録されている。
  • AFRINICの行データは旧ブロック末尾のAS329727を4月16日、新ブロック冒頭のAS329728–AS329730を4月17日の割当として記録する。日次ファイルへの掲載はそれぞれ翌日の版で確認できる。
  • 9月10日版で旧ブロックに存在するallocated行は972件、存在しない番号値は52件だった。新ブロックでは81件が存在する。最大番号が境界に達しても、手前の全番号が委譲済みとは限らない。
  • 52件を「未使用」「予約」「回収」などと呼ぶ根拠はない。必要なのは個別申請の公開ではなく、ブロック総数と公開状態を再計算できる照合票である。

境界線の両側で帳簿の意味が変わる

AS329727に一を足せばAS329728になる。しかし、この一歩は単なる算数ではない。IANAがAFRINICに渡した上流ブロックの境界でもある。

IANAのAutonomous System Number登録簿は、AS328704からAS329727までを2020年3月5日付でAFRINICに割り当てた範囲としている。その直後のAS329728からAS330751までは、2026年2月25日付の別ブロックだ。いずれも1,024番号で、さらに先のAS330752–AS393215は凍結した登録簿では未割当とされている。

AFRINICは3月27日、新しい範囲をIANAから受領し、自らのインベントリに追加したと告知した。ここで記録されたのはIANAからRIRへの移管である。1,024番号が同日にネットワーク事業者へ配られたという意味ではない。IANA自身も、RIRへブロックを割り当てる行為と、RIRが地域ポリシーに従って事業者へ個別番号を割り当てる行為を区別している。

後者を観察する資料がAFRINICのdelegated statisticsだ。交換フォーマットの仕様によれば、ASN行のstartは番号、valueはその行が含むASN数、dateはファイルを作るRIRが割当または指定を行った日、statusはそのRIRによる行為を示す。別の機関による再指定ではない。

9月10日版を見ると、AS329727は国コードNG、日付20260416、状態allocatedである。直後にAS329728のGH、AS329729のKE、AS329730のTZが並び、三行とも20260417とallocatedを持つ。ここで国コードは保有組織が法的に所在する国を示すにすぎず、番号が実際に使われる場所を確定しない。行の並びはルーティング地図ではない。

日付は一つではない

4月16日、17日、18日の保存ファイルを比べると、公開記録がどのように追いついたかが分かる。

ヘッダーが16日のファイルにはAS329727もAS329728もない。17日版にはAS329727が現れ、その行内の日付は16日になっている。しかしAS329728はまだない。18日版になると、日付17日を持つAS329728、AS329729、AS329730がそろって現れる。

これは矛盾ではない。行内の日付は割当行為の日を示し、ファイルの日付はその公開スナップショットの基準日を示す。日次生成のため、ある日の行為が翌日の公開ファイルで初めて見えることはあり得る。二つを同じ時計として扱うと、根拠のない処理時刻や遅延評価を作ってしまう。

したがって、確認できるのは限定された順序である。旧ブロック末尾は16日付、新ブロック冒頭は17日付。公開ファイルではそれぞれ17日版と18日版に反映された。申請の受付時刻、審査順、請求、内部予約、バッチ処理の順序までは分からない。

最大値ではなく1,024個を数える

AS328704からAS329727までの整数は、両端を含めて1,024個ある。9月10日版からこの範囲の一番号allocated行を抽出すると972件だった。したがって公開行として確認できる割合は94.921875％、行が存在しない割合は5.078125％、個数にして52件である。

52件は末尾に固まっていない。範囲の途中に散在し、最も大きい空白はAS329708だ。その後のAS329709からAS329727まではすべてファイルにある。最大値だけを表示する計器なら、針は旧ブロックの端に達する。その画面からは、背後の52件が完全に消える。

新ブロックも同じ方法で数えられる。AS329728–AS330751の1,024番号のうち、9月10日版にあるallocated行は81件、行がない番号値は943件だ。最初は4月17日付のAS329728、最後は9月8日付のAS329808で、日付差は144日になる。

ただし、この144日を割当需要の速度に読み替えてはならない。ファイルには申請件数、却下、待機時間、選番規則、未公開の内部状態がない。さらにASN行の存在はBGPでの可視性や実ネットワークの稼働を証明しない。逆に、行がないことも利用可能性を証明しない。

52件に名前を付けない強さ

空欄を見ると、人は理由を補いたくなる。未割当、予約、保留、回収、誤記。どれもレジストリ運用ではあり得る語だが、今回の資料は52件をそのどれにも分類していない。

交換仕様は、存在するallocatedまたはassigned行の意味を定める。内部インベントリのあらゆる状態を公開すると約束してはいない。AFRINICの資源管理ページも、管理対象のASNブロックは列挙するが、全番号の個別状態までは示さない。

よって、結論は「9月10日版のdelegated fileに52番号の該当行が存在しない」にとどめるべきだ。これは弱い表現ではない。出典、日付、再計算方法を持つ検証可能な観察である。後日のファイルに番号が追加されても、当時の観察はそのまま保存できる。AFRINICが状態定義を公表すれば、推測をせずに説明を追加できる。

連番がつくる誤った完成感

最大ASNは便利な広報指標だ。短く、変化が分かりやすく、会員の申請内容を漏らさない。一方で、指標の利用者はそこに「残り在庫」を重ねやすい。

本来、少なくとも四つの問いを分けなければならない。番号列はどこまで進んだか。公開委譲行は何件あるか。RIR内部で番号はどの行政状態にあるか。運用上BGPに見えているASNはいくつか。最大番号が答えるのは最初だけだ。delegated fileの集計は二番目に近い。三番目には追加の状態情報が要り、四番目には別の測定系が必要になる。

AFRINICが52件を飛ばして新区間を使い始めた、と断定することさえ慎重であるべきだ。公開行がない理由は分からないからだ。まして、番号が不当に留保された、在庫が枯渇した、申請者が拒まれた、という主張はできない。今回示せるのは、ブロック境界を越えたという順序と、旧ブロックの公開件数が閉じていないという計数が同時に成立することだけである。

公開できる照合票の設計

この空白を埋めるために、個別申請や企業計画を公開する必要はない。ブロックごとの簡潔なreconciliation receiptで足りる。

そこにはIANA上の範囲、1,024という総数、登録日を記す。計算に使ったdelegated fileの日付とハッシュを固定し、allocatedとassignedの件数、行がない番号の件数を示す。番号一覧を出せない場合でも、集合のダイジェストと、プライバシーを害さない理由コード別の合計は公開できる。行内の割当日と、その行が最初に現れた日次ファイルも別々に保存する。

訂正の扱いも必要だ。過去行が追加、削除、変更されたとき、旧ファイルを残し、差分の発効日と承認主体を示す。WHOIS、RDAP、delegated statisticsの同期範囲を説明し、同じ更新が複数の公開面で違う時刻に現れる場合は、その境界を明記する。

最後に、二つの注意書きを標準化する。delegated fileの行は経路広告や稼働を意味しない。行の不在は申請可能な空き番号を意味しない。この二文だけでも、序列、在庫、運用を一つの数字に押し込む誤読は大幅に減る。

4月の境界は、異常事象として煽る必要がない。IANAから受けた新ブロックが下流記録に入り始めた。それと同時に、旧ブロックには説明されていない52件の残差がある。1,024＝972＋52という式を公開資料から再現し、式の各項が意味するところと意味しないところを示す。それが、連番を統治情報に変える最小単位である。

出典