要約

  • FORTのASPAプロバイダー数の既定上限は4,000だ。調べた合併処理は、二つの現在の一覧の長さを足して判定した後で、重複を除く。
  • 合計が上限を超えると、プロバイダーのポインターをヌル、件数をゼロにする。型の説明では撤回に使う結果だが、実際の顧客への影響、ルーターに届いた撤回、資源登録の取消しは観測していない。

同じ顧客ASについて、各2,500件のプロバイダーASを並べた一覧が二つあるとする。中身が全く同じなら、和集合に含まれるASは2,500だ。ところが、固定したFORTのコードが先に比較する長さの合計は5,000になる。

これは実在する二つのASPA公開を見つけた話ではない。他の検査を通り、同じ顧客の合併関数に入った二つの整列済み一覧についての条件付き推論だ。数千の上流が通常あると主張するためではなく、上限がどの段階の数量を測るのかを確かめるための例である。

LACNICが2026年9月9日に公表したASPAの解説は、既存の実装の一つとしてFORTを挙げる。ASPAは顧客ASが認めるプロバイダー関係の情報を与え、経路の起源だけを検査するROVとは役割が異なる。今回の焦点は普及率やルーターとのプロトコル交渉ではなく、重なり合う一覧を受け入れる際の数え方だ。

対象は7月16日公開の1.7.0.experimentalで、タグの参照先をc67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7eに固定している。9月の検討であって9月の新リリースではない。現在の全インストールも調べていない。FORTの実行、本番への照会、合成ASPAの公開は行っていない。

一つの設定が二つの場所で使われる

利用ガイドはaspa.max-providersの既定値を4,000、整数の設定範囲をゼロから16,380とする。引数またはJSONで指定でき、各検証周期に全RPKIツリーを通じて顧客が宣言するプロバイダー数を制限すると説明する。超過した顧客は無効になるとも記す。設定コードも値を確認できる。この記事はこれらを規格上の上限と認定せず、ゼロを無制限の指定とも扱わない。

最初の検査は個々のオブジェクトにある。parse_providersは一つの一覧が設定値を超えると、配列の確保や後続への受け渡しより前に拒否する。ASIDは昇順で、一覧内の重複や顧客自身を認めない。したがって、二つの一覧の間の重なりは、一つの一覧の中の重複とは違う。一覧の形だけで署名や証明書の全条件が成立するわけでもない。

もう一つの検査は顧客をキーとするデータベースの合併にある。既存の同じ顧客の項目を置き換える際、add_aspaはmerge_providersを呼ぶ。この関数はまずold->countとnew->countを足し、mとする。既存のプロバイダーポインターがヌルか、合計が設定上限を超えれば、ヌルと件数ゼロを返す。

その条件を通過して初めて、合計の容量を確保し、整列済み一覧を重複排除しながら統合する。小さくなった和集合の件数は、先ほどの判定に間に合わない。add_aspaは返された結果を新しい顧客項目へ設定し、置き換えた領域を解放する。型のヘッダーはヌルとゼロを撤回に用いると説明している。

各2,500件の同一一覧なら、2,500種類に統合できる前に5,000が4,000を超える。この算術は、実際の顧客が拒否された証拠でもネットワーク障害の報告でもない。

周期全体の元の件数とは限らない

既存一覧の件数は、以前の重複排除を反映している場合がある。元の全オブジェクトの長さを保持し続ける累積カウンターではない。

健康な一つの対象へ、各1,500件の同一一覧を三つ順番に統合すると仮定する。最初の二つは合計3,000で、重複排除後は1,500。三つ目を加えても判定時の合計はまた3,000だ。元の三一覧が4,500件だから、この特定の順序が必ず4,000を超えるとは言えない。

これも条件付きの関数列で、実際のツリーの処理単位を保証しない。元の件数、現在の二入力の容量、異なるASの件数は、別々の量になる。「プロバイダー数」だけではどれを指すのか分からなくなる。

数値条件は上限より大きい場合だ。等しい場合はその数値分岐に入らないが、他の検査は残る。ヌル結果も超過だけを意味しない。既存ポインターがヌルという別条件がある。全ての合併順序を監査したり、無効マーカーが常に回復不能だと主張したりはしていない。

守る容量を説明する

この順序は防御的な領域確保の予算と整合する。直後に確保する容量が入力の合計だからだ。最終集合が小さくても、中間容量を抑える理由はあり得る。ただし、コード構造からの解釈であり、保守者が確認した意図や性能測定ではない。それだけで欠陥と決められない。

一方、運用者が結果から数えやすいのは異なるASだ。説明を明確にするなら、二入力の中間容量を守るのか、最終的な異なるメンバーを制限したいのかを区別したい。文言を変える判断と処理順序を変える判断は別だ。どちらも採用されたとは報じず、単純な上限引き上げも勧めない。

ヌル結果と撤回の約束だけで、ルーターのセッションが何を受け取り、どの方針を適用し、トラフィックがどう変わったかは分からない。キャッシュによる提供者情報の扱いは、顧客のASNや資源登録の取消しでもない。示しているのはソフトウェア結果への情報の受け入れ規則である。

出典

  1. LACNICのASPA解説
  2. FORT 1.7.0.experimentalの公開情報
  3. 固定コミットの引数ガイド
  4. ASPAオブジェクトのプロバイダー解析
  5. 顧客項目の統合と計数順序
  6. 設定の既定値と範囲
  7. プロバイダー型と撤回の約束