要約

  • APNICの告知は、2026年９月29日10時から12時（UTC+10）に、DASH、notification.apnic.net、REx、AS0 ROA Serviceが利用するGCPネットワーク環境を更新すると記す。「停止は見込まない」は将来の作業についての見通しであり、障害の発生報告でも、公開データの鮮度保証でもない。
  • 現行のAPNIC資源ポリシー第5.1.4節は、AvailableまたはReservedの未委任アドレスについてAS0 ROAを作り、委任時にはそのプレフィックスを外すと定める。ただし同節は2026年の所要時間を示していない。
  • 2020年の導入説明には、通常の状況で委任後５分未満の除外と再公開を目指したとある。当時の実装を知る手掛かりではあるが、現在のSLAや今月の実績ではない。
  • AS0には通常のRPKIとは別のTALがあり、利用者が明示的に導入する。APNICは自動的なBGP経路遮断ではなく、助言や警告としての利用を強く勧めている。経路への影響は各ネットワークの採用と設定に左右される。

「応答した」だけでは終わらない

サービス更新一覧によれば、告知が掲載されたのは９月24日である。予定された作業はその５日後だ。本文は対象４サービスを列記し、停止を見込まないと述べる。それ以上の詳細な構成図はない。４サービスが同じデータベース、同じ署名工程、同じ障害点を共有すると断定することはできない。末尾の定型的な「outage」に関する謝罪文も、まだ起きていない事故の証拠にはならない。

４つの名前を同じ監視方法で扱うと、重要な差が消える。DASHやRExの画面が開くか、notificationの入口が応答するかはそれぞれ確認できる。しかしAS0では、署名されたオブジェクトを取得できることと、その中身が新しい資源状態を反映していることは別である。取得可能な古い主張という状態は論理的にあり得る。この作業でそうなると示す証拠はないが、起きたかどうかを判断できる観測点をあらかじめ決める価値はある。

2025年７月31日の保守告知にも同じ４サービスが並ぶ。そちらはKubernetesの更新で、停止しない見通しだった。連続する一覧から、APNICがAS0を保守対象のサービスとして継続的に知らせていることまでは分かる。１年前の一覧から現在のネットワーク経路やバックエンドまで復元することはできない。

署名が指す資源状態

AS0 ROAの意味を取り違えると、鮮度の問題も見えなくなる。RFC 6483第４節は、origin AS 0のROAを、対象プレフィックスとその下位プレフィックスについて経路の起点になるべきではないという否認として説明する。APNICの現行ポリシーは、自ら管理する未委任のIPv4・IPv6空間にこれを適用する。拡張版の委任統計でAvailableまたはReservedとされる空間だ。資源を口座保有者へ委任したなら、そのプレフィックスは「未委任」という公開の主張から外さなければならない。

この操作がいつ行われるかについて、APNIC 50での2020年実装報告は具体的だった。当時は登記の委任イベントを主系統とAS0のRPKI状態に５分以内に反映し、公開リポジトリをクラウドに置くと説明した。ブログも、通常時５分未満でAS0から除く設計が実装されたと記している。現在も同じ目標や構成だと読み替えてはならない。現行ポリシーは除外すべきことを明記する一方、今回確認した公開文書は2026年の所要時間を定めていない。

観測すべき時間は少なくとも四つある。まず権威ある登録簿で委任が成立した時刻。次にAS0の対象からそのプレフィックスを外した状態が生成された時刻。その署名オブジェクトが公開された時刻。最後に、別TALを使う外部の検証者が新しい版を取得した時刻だ。発行側が管理するのは最初の三つの範囲であり、各ネットワークの検証器がいつ再取得するかまでは管理しない。検証器の遅れをそのままAPNICの公開遅延とみなすのも、APNIC内部の公開時刻だけで外部可視性を証明するのも誤りになる。

対象となる委任が２時間の間に一件もなければ、AS0オブジェクトに変化がないのは自然だろう。同じハッシュを二度見たことは、更新経路が５分以内に働いた証拠でも、故障の証拠でもない。試験に必要なのは実際の状態変更である。告知だけから委任が発生すると想定してはならない。

TALの分離と経路判断の分離

APNICの注意書きは、AS0のために別の信頼アンカーロケーターを用意し、知らないうちに通常の検証へ取り込まれないようにしている。この分離は採用判断をネットワーク側に残す。物理的な独立や、GCP保守の影響を一切受けない構成を示すものではない。2020年の報告にクラウド上の公開点が登場し、2026年の告知にGCPネットワーク環境が登場することから、現在の細部まで断定することもできない。

仮に新規委任の後も古いAS0がプレフィックスを覆った場合、追加TALを選んだ検証器は古い否認を読み得る。しかし、経路が最終的にどの検証状態になるかには他の該当ROAも関わり、転送から除外するかは事業者のローカルポリシーが決める。APNICは設定次第で誤りが経路の中断につながり得ると警告し、自動フィルタではなく警告用途を推奨する。この告知から実際のInvalid判定、経路遮断、利用者被害は一つも導けない。

作業後の説明には、到達可能性と内容更新を分ける方法がある。対象サービスのアクセス状況に加え、AS0について更新を要する委任イベントがあったか、あれば登録・生成・公開の版と時刻をどう対応させたかを示す。イベントがなければ、鮮度の経路はこの窓では試されなかったと言えばよい。これは検証可能性を高めるための編集上の提案で、APNICがその報告を約束したという意味でも、内部監視をしていないという主張でもない。

「停止なし」が結果として正しかったとしても、AS0の品質を言い尽くしたことにはならない。未委任という主張の対象から資源が抜ける瞬間に、公開された文書も変わるか。その小さく具体的な問いを残すことが、誇張した障害物語より運用に役立つ。

出典