要約

  • NAPafricaは2026年6月のAFRINIC-37で、ヨハネスブルクの再番号付けが開始から8年後も終わっていないと説明した。地域全体の移行期間を示す統計ではない。
  • AFRINICは最初の拡張用に隣接アドレスを確保する。ただし確保には条件があり、全体の予備枠を倍にするだけでは次の拡張を約束できない。

接続先がいくつもあるネットワークでは、自分の準備ができた日を全員の切り替え日にできるとは限らない。インターネット交換拠点、IXPのアドレス変更にも、その難しさがある。

IXPでは、参加するネットワークが共通の設備を通じてトラフィックを交換する。使うアドレスを変える際には、拠点側だけでなく参加者側の設定や作業日程も調整する必要が生じ得る。アドレスの割り当ては移動先を決める手続きであって、移動そのものではない。

2026年6月24日のAFRINIC-37で、NAPafricaのAndrew Owensはヨハネスブルクの事例を挙げた。8年前に始めた再番号付けが、会議時点でも完了していないという。議事録はその発言を記録しているが、遅れの全工程や費用までは示していない。8年間サービスが止まっていたという話でもない。

しかも、次の拡張が必要になりつつあった。Owensによると、ヨハネスブルクはすでに二つの/23を使い、/22相当の利用量に近づいていた。/21まで広げるには、さらに二つの/23が必要になる。彼はその余地を先に確保してほしいと求めた。追加割り当てが承認されたわけではない。

数が合っても、隣が空いているとは限らない

/23には512個のアドレスがある。四つなら2,048個で、/21と同じ数になる。ただし、一つの/21にまとめるには四つが連続し、適切な境界にそろっていなければならない。ここで数えているのはアドレスであり、接続できる事業者数ではない。

予備のアドレスが別々の場所に残っていても、今使っているブロックの横へそのまま広がれるとは限らない。総数を見るだけでは、拡張後も元の場所にいられるのか、それとも移動の準備が必要なのかが分からない。

AFRINICの現行ポリシーマニュアル11.4節は、この違いを最初の拡張で考慮している。IXPのピアリング用ブロックに隣接する/24を確保し、別のブロックへ移らず/23へ拡張できるようにする仕組みだ。

しかし、確保は永久ではない。専用の/16プールから/23を割り当てられなくなると、それまで将来の成長用に取っておいた空間を新規申請に使える。既存のIXPを育てる一方、新しいIXPにも入口を残すための条件である。この条文だけから、現在すでにその段階に達したとはいえない。

職員は会議で、/23まで成長したIXPがさらに先を必要としていると説明した。最初の一歩を支える規則はあっても、次の一歩まで同じように進めるとは限らない。

予備枠の用途を混ぜない

ポリシーでは、ピアリング用に/16、管理用にそれとは別の/16相当を確保する。前者は参加ネットワーク同士がトラフィックを交換するためのアドレスだ。後者は監視、統計、メール、問い合わせ対応などを支える。管理用アドレスをピアリング用ブロックから出してはならない。

会議では、この二つの用途を入れ替えて使う会員がおり、職員が規則に沿うよう調整しているとの報告もあった。何件あり、なぜ起きたのかは該当箇所に記されていない。用途や記録が違っている場合、予備枠を増やすだけでは直らない可能性がある。

申請資格の確認も、将来の需要予測とは別だ。IXPの申請基準には、アフリカでの法的な存在の証明、少なくとも三つのBGPピアのASNと連絡先、および／または署名済みの合意文書、公開・開放的な運営の証明が挙げられている。未登録のIXPは別の組織が代表できる。これらで申請者を確認できても、数年先の規模までは決まらない。

また、5.6.4.1節の/24はプレフィックス長の制限であり、「最大256アドレス」という意味ではない。短いプレフィックスほど大きなブロックを表し、一定の場合には複数の割り当ても可能だ。ただし、希望する大きさが自動的に認められるわけではない。

大きな予備枠を選ぶ前に

Paul Hjulは、/16ではなく/15の確保が適切ではないかと質問した。アドレス数は倍になる。James Chirwaはコミュニティで検討する問題だと答え、職員から消費状況の統計を提供するとした。Gregoire Ehoumiは影響を受ける会員数を求めた。これは拡大を決めた議決ではなく、判断材料を求める議論だった。

統計は、全体の不足と隣接ブロックの不足、用途の不整合を見分けるために役立つ。本記事の確認では、その後の統計公開時期は確定できていない。約束が果たされなかったと断定するものではない。

技術面では、Jordi PaletがRFC 8950の検討を提案した。IPv4の経路を通知するとき、次の転送先をIPv6アドレスで示せる規格だ。利用前には、BGPの相手が必要な機能に対応していることを確認しなければならない。規格があることと、参加ネットワークや経路サーバーがそろって使えることは同じではない。

ヨハネスブルクの一例から、アフリカ全体に必要な予備枠を算出することはできない。それでも、ネットワークを集めることに成功したIXPが、その先の拡張をどう計画できるかは問える。何個残すかに加え、どこに、いつまで残すか。そして移るなら誰と調整するか。AFRINICの成長支援は、そこまで含めて初めて運用の計画になる。

**訂正、2026年10月21日：**5.6.4.1節の/24の意味を修正し、隣接空間の確保条件を追記した。IXP申請表に誤って帰属させていた免許要件も削除したが、適用される国内法の免除を意味しない。元のURLと公開日は変更していない。