要約

  • RFC 9977 は、端点のプレフィックス長と、CGN/プロキシの場合の端点数を CSV で公開する方法を定める。
  • その数値、HTTPS、RPKI 署名のどれも、個々の要求の正当性やレート制限を変える義務を示さない。

4,000 という数字は、RFC 9977 が CGN 配下の /24 を説明するために置いた例である。コンテンツ提供者は、ある IP を一人として扱うべきか、多数の利用者を含む塊として扱うべきか、しばしば分からない。ブロック、スロットリング、CAPTCHA、位置推定では、その粒度が問題になる。RFC は入力形式を与える。実在する加入者数も、緩和すべき制御も決めない。

ファイルの解釈規則

行にはプレフィックス、端点プレフィックス長、必要なら CGN/プロキシの端点数がある。後ろ二欄を空にすれば、発行者は情報を出さない意思を示す。その場合、より広い親プレフィックスからの推論は捨てる。利用者は最長一致を採用し、同一プレフィックスの重複や誤った行は飛ばして処理を続ける。これはデータの優先順位の規則であり、発行内容の真偽の保証ではない。

参照先は prefixlen:、移行中は remarks: Prefixlen に記される。HTTPS はファイル取得を保護するが、IP 資源の割当認証とは別物である。

RPKI が狭く保証するもの

任意の認証子では、署名証明書がファイル内の全プレフィックスを覆い、検証者は証明書経路、マニフェスト、CMS 署名、型、資源範囲を確かめる。RFC 6481 の資源証明書は、公開鍵を列挙された IP/ASN に結び付け、署名によってその資源の保有関係を示せるようにする。

それでも、端点数の調査、現在性、ユーザーの同定、優遇処理の根拠にはならない。RFC 9977 自身が、正当な遮断や制限を避けるために CGN と偽って記す運用者を想定している。巨大または極端に細かいファイルが利用者を圧迫する危険も挙げる。したがって、署名成功は結論ではなく、別途評価すべき一つの観測である。

判断は受信側に残る

CGN 信号があればレート制限を調整「できる」と RFC は言う。調整するかは、受信側が鮮度、矛盾、要求行動、被害、方針、可逆性を見て決める。共通フォーマットは共通の手掛かりにとどめるべきであり、Heng Lu のいう局所的な将来判断を発行者に明け渡してはならない。