要約

  • AFRINICの現行マニュアルは、IXPのピアリング用アドレスと管理用アドレスを分け、ピアリング専用プールを設けている。隣接する /24 を確保し、/23 まで拡張できる仕組みも定める。一方、AFRINIC-37で職員は、一部会員が二つの用途のプレフィックスを入れ替えており、方針に適合していないと報告した。
  • NAPafricaのAndrew Owensは、ヨハネスブルク拠点がすでに二つの /23 を持ち、/22 の利用上限に近づいていて、さらに必要になれば /21 に達するため二つの /23 を追加する必要があると説明した。また、8年前に始めた改番がまだ終わっていないと述べた。これは一運用者による報告であり、アフリカのIXP全体の需要や標準的な移行期間を示すものではない。
  • /16 の予約を /15 に広げる前に、地域は消費状況と影響を受ける会員のデータに加え、連続した成長ブロックと移行方法を設計する必要がある。予約を増やせば不足を和らげられるかもしれないが、次のブロックが必要な場所にあるとは限らない。

分析

「どれだけ確保するか」だけでは決まらない

AFRINICの現行統合ポリシーマニュアルは、バージョン1.6を現行版とし、公開日は2020年11月17日と記載している。第11節は単に予約量を決めるものではない。参加者が共用の交換設備でトラフィックをやりとりするための連続したブロックであるピアリングLANと、監視、統計、メールなどを担う管理ネットワークを区別する。管理用のアドレスをピアリング用ブロックから割り当てないよう定め、ピアリング専用の公開されたブロックを設ける。さらに、隣の /24 を確保すれば、IXPは別の連続ブロックを受けて改番しなくても /23 まで成長できる、と説明する。同節はピアリング用に /16、これとは別に管理用の同規模の /16 を予約する案を記している。統合ポリシーマニュアル

会議では、地域全体に対する /16 の予約で十分なのか、それとも /15 の方が適切なのかという問いが出た。/15 のアドレス数は /16 の二倍だ。しかし、その算術だけでは連続した形で割り当てられる残量、消費速度、どの申請が制約を受けるかは分からない。AFRINIC職員は、会員が判断できるよう消費量の統計を示すと答えた。別の参加者は、緊急性を決める前に影響を受ける会員数を具体的に示してほしいと求めた。AFRINIC-37の議事録

これは手続き上の添え物ではない。予約は在庫を管理する規則であると同時に、割り当ての規則でもある。総量はどれだけを確保するかを決め、割当単位と隣接性は運用者がネットワークを拡張できるかを左右する。誰が何の用途で受け取り、どれだけ余裕を残しているのかを示す記録は、さらに別の論点だ。最初の問いだけに答えても在庫は増える一方、次の成長段階は未解決のままになりうる。

用途の不一致を見つけても、原因までは分からない

議事録によると、職員は一部会員がピアリング用と管理用のプレフィックスを相互に入れ替えており、方針に沿っていないと説明した。職員は使い方をそろえるよう会員と調整している。これは実施上の問題を示すが、なぜ入れ替えが起きたのか、何会員に及ぶのか、主因が規則、会員記録、事務手続き、それとも運用にあるのかは明らかでない。故障箇所を特定する前に方針を書き換えれば、文面だけが変わって実際の使い方は残る恐れがある。

マニュアルの第5.6.4節と第11節は関連しているが、同じ仕組みではない。前者は重要インフラへのIPv4エンドユーザー割当を扱い、通常は /24 以下としつつ、状況に応じて複数の割当を認める。後者はIXP専用のピアリング用と管理用の予約プールを定め、隣接する /24 で /23 への拡張を可能にする。マニュアルはIXPを、単一の運営主体が動かす物理的なレイヤー2設備で、少なくとも三つのISPが接続し、他者にも開かれた参加方針を持つものと定義する。AFRINICの公開申請条件では、アフリカ域内の法人上の存在、三つ以上のBGPピアのASNと連絡先または署名済みの覚書、公開性と開放性の証明、必要な国での運営ライセンスも求める。AFRINICの申請条件

適格性の確認は、将来需要を数えることでも、使えるブロックが各交換点の成長経路に合うと保証することでもない。用途をまたぐプレフィックスが見つかったとしても、職員がそれを問題化する前に把握する記録や手段を持っているかまでは分からない。

ヨハネスブルクの例が示すのは配置の問題で、地域需要ではない

Owensによると、NAPafricaはヨハネスブルクで二つの /23 を持ち、/22 をほぼ使い切るところにあり、さらに必要なら /21 にするため二つの /23 を追加する必要があった。同氏は、同拠点の改番が8年前に始まったものの未完了だとも説明した。議事録は個別事例を示すが、母数、比較できる他のIXP、独立したコスト見積もり、長期化した理由までは示していない。

それでも、この事例は総アドレス数が見落とすものを示す。四つの /23 が /21 になるのは、必要な境界に合わせて各ブロックが隣接している場合だけだ。ばらばらの割当で成長してきたIXPに要るのは、アドレスの数だけではない。使える隣接ブロックの順序、移行中にサービスを継続する方法、参加ネットワークと調整する時間である。マニュアルの隣接 /24 の仕組みが明確に対象とするのは、まず /23 に伸ばす段階だ。Owensの報告が浮かび上がらせるのは、その先の段階をどう支えるかという問いである。これだけで方針の失敗とは言えないが、次の拡張を当然のように扱わず設計する価値はある。

会議では、デュアルスタック運用の選択肢として RFC 8950 に言及する意見もあった。IETFの標準は、BGPピアが必要な機能を交渉した場合に、IPv6のネクストホップを使ってIPv4経路を広告する方法を定める。技術的な選択肢にはなりうるが、すべてのルートサーバーや参加者が利用可能だと示すものでも、専用IPv4ピアリングLANが不要だと証明するものでもない。RFC 8950

大きな数字を決める前に、根拠を公表する

議事録から分かるのは、地域の予約量と、個々の交換点が繰り返し改番せずに成長する方法という二つの問いが出されたことだ。職員は消費統計の要請を受け止め、関係する数値をメーリングリストで共有すると約束した。本稿のために確認した公開資料からは、その約束がいつ実行されたか、あるいは実行されたかどうかまでは確かめられなかった。これは調査の限界であり、後日数字が出なかったという証拠ではない。

次に有用な資料は、二つの問題を混ぜずに一枚で見せることだろう。ピアリング用と管理用のプールを分けて、開始時の規模、割当、返却、残量を示す。制約を受けた申請数、割当サイズ、その連続性も記載する。承認済みの割当と将来の予測を混同せず、「利用」が割当済み、設備への導入済み、経路として広告済み、あるいは保有しているだけのどれを意味するかを明記したい。日付と算出方法を添えた表は、単独の利用率より判断に役立つ。

そこに移行の道筋も必要だ。方針が認める拡張段階、隣接ブロックをどのように確保するか、連続した割当ができない場合の扱い、改番の調整役、運用上の保護策や例外手続きである。常に隣接ブロックを割り当てられると約束することではない。申請が一件ずつ現実の運用問題になる前に、節約と回避可能な移行コストのせめぎ合いを見えるようにすることだ。

データが、専用の /16 では /23 を割り当て続ける余地が乏しいと示せば、より大きな予約を支持する根拠になりうる。少数の交換点に大型の連続ブロック需要が集中しているなら、別の予約配置や段階的な移行規則の方が適切かもしれない。用途間のプレフィックス交換が中心なら、記録と遵守支援の改善が備蓄の倍増より効果的な可能性がある。議事録だけでどれが正解かは分からない。

責任ある順序は明快だ。プールに何が残っているか、どの申請に応えられないか、方針がどんな成長・移行経路を認めているかを公開する。その後なら、IPv4を増やすのか、予約の形を変えるのか、記録を整えるのか、複数の策を組み合わせるのかを社群が決められる。NAPafricaの例は順番を誤った際のコストを想像させる。どれほど頻繁に起きるかを判断するには、より広い公開データが要る。

出典