要約

  • ACSP Suggestion 2026.3は、既存ROAが/16、maxLength /24なら、同じOrigin ASの/16から/24は冗長として拒否され、/25から/32は作成できるという試験結果を報告した。
  • ARINはFAQを更新して提案を完了扱いにしたが、現行例は「any prefix covered」と記すだけで、拒否される長さと許容される反例を明示していない。
  • 文書を長文化せずとも、Web、REST、OT&Eで共通の5ケースを版付きの意味試験レシートとして示せば、完了の中身を再現可能にできる。

速い応答は、それ自体が成果である

Chris WoodfieldがACSP Suggestion 2026.3を提出したのは2026年1月13日だった。内容は単なる不満ではない。問題のFAQ文を引用し、試した挙動を説明し、どこが曖昧かを切り分け、修正文案まで提示していた。

ARINは2月18日、混乱を解くためFAQを更新したと回答し、案件を完了として閉じた。約5週間である。公開の改善窓口としては良好な動きだ。提案者の名前も、元の主張も、組織の返答も残っている。無期限の「検討中」に送らず、実際の文書変更まで進めた点は軽視すべきではない。

重複ROAを受け付けないという設計にも合理性がある。ARINのHosted RPKIではROAが自動更新されるため、期限切れを避ける目的で同じ権限を持つオブジェクトを先にもう一つ作る必要はなくなった。権限を増やさないレコードを減らせば、一覧は読みやすくなり、変更・削除の対象を誤る余地も小さくなる。初心者向けFAQを短く保つことにも価値がある。

したがって論点は、ARINが厳しい受付規則を設けてよいかどうかではない。RPKIオブジェクト形式が許すものを、ホステッドサービスがすべて受け入れる義務はない。論点は、受け入れた指摘と「完了」という結論の間を、公開情報が検証可能な形で結んでいるかである。

元の提案には境界値テストが埋め込まれていた

提案ページが再掲する旧例は、/16のプレフィックスとmaxLength /24を持つROAから始まる。同じOrigin ASを使い、その/16内にある別のプレフィックスなら作成を阻止すると説明していた。提案者は、試験結果はそこまで広くないと述べた。

報告された分岐は明快だ。同じASで、新しいプレフィックス長が/16から/24なら、既存ROAがすでに同じ起点権限を与えているため冗長となる。一方、/25から/32はアドレス空間としては/16の内側にあるが、既存のmaxLengthを越える。提案者の試験では、こちらは別のROAとして作成できた。

提案文は「overlapping」より「redundant」を使い、拒否側と許容側の両方を明記していた。ここで許容例は飾りではない。「/16の内側」という幾何学的な包含と、「既存ROAがすでに与えた権限」を分ける役割を果たす。/24の両側を一件ずつ試せば、説明を受け入れ試験に変えられる。

現在のRPKI FAQは、自動更新によって重複ROAの必要がなくなり、ROAはもはや重なれないと述べる。例も/16とmaxLength /24、同一Origin ASという骨格を維持している。だが結論は「any prefix covered in the existing ROA」に短縮され、/16〜/24という拒否範囲と、/25〜/32という許容例は書かれていない。

この比較が示すのは文章上の欠落だけで、現在の実装ミスではない。本稿では顧客アカウントにログインしておらず、本番で作成要求も送っていない。1月の挙動は提案者による報告である。ARIN内部の試験が正確で、現在の「covered in」が「すでに権限内にある」という平易な省略表現である可能性は十分ある。問題は、その読みを外部から確定する材料が公開面にないことだ。

RPKIの「Covered」と「Matched」は別の関係だ

RFC 6811では、経路プレフィックスがVRPに Covered される条件は、VRPのプレフィックスが同じかより短く、該当ビットが一致することだ。この段階では最大長を見ない。Matched になるには、さらに経路長がVRPの最大長以下で、Origin ASNも一致しなければならない。

FAQはcoveredを規範語として大文字表記しているわけではない。それでもRPKIの説明を読む技術者には、通常語と規格語の二つの読みが生じる。/16内の/25はアドレス上はCoveredだが、maxLength /24のVRPにはMatchedしない。同じOrigin ASNでも変わらない。消えた反例は、この二つを最短距離で分けていた。

RFC 6482は署名オブジェクトの側からmaxLengthを定める。指定したASが広告できる最長のプレフィックス長であり、省略時は完全一致のプレフィックスだけが許可される。同RFCは、一つの有効なROAに、別の項目に包含されるプレフィックスを入れることも、同一プレフィックスを複数入れることも認める。ただし権限を何も増やさない短いmaxLengthの重複は推奨しない。

これはARINの規則がRFC違反だという意味ではない。オブジェクトの妥当性、VRPによる経路判定、ARINサービスの入力受付は別の層である。ARINは運用上きれいな部分集合を選べる。だからこそ、その選択は「規格上当然」とせず、サービス規則として境界を示すべきだ。

公開されている三つの面は材料までしか示さない

ARINのROAガイドは、ROAの要素をOrigin AS、プレフィックス、最大長と説明し、重複・重なりは許可されないと記す。詳細はFAQへ委ねられ、境界値表はない。

RPKI RESTful API User Guideは入力構造を詳しく示す。単一トランザクションでROAの作成・変更・削除ができ、ASPA操作とも原子的に組み合わせられる。すべて成功するか、すべて失敗する。リソースにはstartAddress、cidrLength、任意のmaxLengthがある。エラーは一般のエラーコード文書へ案内されるが、今回保存したページには重複判定式そのものはない。

原子性にはFAQの一例だけでは解けない問いがある。古いROAを削除し、代替ROAを作る要求を同じトランザクションに入れたとき、冗長性は開始前の状態、意図した完了後の状態、それとも内部の途中状態に対して評価されるのか。実装は一つを選んでいるはずだ。クライアントの事前検査も同じ状態モデルを使わなければ、全体を不要に失敗させる。

ARINのOT&E環境は、本番を変えずにこの境界を調べる場所を提供する。ARINは、本番サービスと同じ機能セットがあり、テストROAの作成やRPKIトランザクション・ペイロードの検証ができると説明する。一方で本番とは接続されず、データは毎月のスナップショットで更新され、メールは使えず、スタッフが常時監視する環境でもない。

OT&Eは再現の場であって、版付き仕様そのものではない。月次更新で初期状態が変わり、リリースで挙動も変わり得る。入力、期待値、ビルド、日付を残さない試験は、次の更新後には経験談に戻る。

5行のレシートで「完了」を検査できる

必要なのはソースコード公開ではない。提案番号、文書改訂、サービス規則の版と発効日をヘッダーに置き、各行にチャネル、既存AS・プレフィックス・maxLength、新規AS・長さ、期待される許可／拒否、安定した理由コードを記録する。OT&Eの版と実行日、後継版へのリンクも付ければよい。

行は五つで足りる。同一プレフィックス・同一AS、maxLength内のより具体的なプレフィックス、maxLengthを越えるプレフィックス、別Origin AS、旧ROAの削除と代替の追加を同時に行う原子トランザクションである。文書用プレフィックスと予約ASNなら、顧客データも本番鍵も不要だ。

FAQは短いままでよい。説明ページは入口、テストレシートは精度を担当する。こうすれば「文章を変更した」「サービスがこの組を受け付ける」「提案で求められた明確化を届けた」という三つの主張を、混ぜずに確かめられる。