要約

  • 同一ホストは同一IPアドレスから最大2台、BGPで見える同一プレフィックスから最大4台のソフトウェアプローブを接続できる。ホスト横断ではIPv4プレフィックスで32台、IPv6で64台が上限となる。
  • 方針は基盤コスト、密集配置による追加情報の乏しさ、例外、上限変更の可能性を説明している。一方、ある時点のBGP状態を特定の保留集団へ結び付ける再現可能な記録は公開資料から確認できない。
  • 影響を受けるホスト向けの非公開記録には、決定時刻、経路観測範囲、解決されたプレフィックス、台数、発火した閾値、解除条件、例外審査をまとめ、公開面では安全な集計値だけを示すのがよい。

2、4、32、64は別々の問いである

RIPE Atlasに必要なのは、単なる台数ではなく観測点の違いだ。接続中のプローブは中央基盤の資源を使う。同じネットワークと場所にソフトウェアプローブが密集すれば、結果が似通い、追加の情報量が小さくなる場合もある。同時に、ホストは稼働時間に応じて測定用クレジットを得る。参加を促す仕組みが、同一環境での台数競争にならないための制御が要る。

2026年4月29日の導入告知は、その制御を四つの数字で示した。同一ホストは同一IPアドレスから2台まで、同じホストが「BGPで見える」同一IPプレフィックスから4台まで接続できる。ホストをまたいだ総数は、一つのIPv4プレフィックスで32台、IPv6プレフィックスで64台までだ。上限を超えたソフトウェアプローブは、同じ集団から別のプローブが抜けるまで接続を許可されない。

これは一つの検査を四段階にしたものではない。2台の規則はホストとアドレスを組み合わせる。4台の規則はホストと経路プレフィックスを組み合わせる。32台と64台はホストを横断してプレフィックス全体を数え、アドレス族を分ける。したがって、ある保留を説明するには、単なる違反ラベルではなく、どの母集団にどの上限を当てたかが必要になる。

RIPE NCCは数字を不変とはしていない。上限は将来調整し得る。同一利用者のプローブが同じネットワークから出ているように見えても、実際には地理的に広く分散している場合があるとして、メールで事情を説明し緩和を求める道も設けた。告知時点の推計は13ホスト、71プローブである。これは4月29日の導入見込みであって、現在値でも、71台すべてが実際に保留されたという記録でもない。

重要なのは「BGPで見える」という修飾だ。レジストリ上の割り振り、ASN全体、ホストが入力した場所をそのまま運用ネットワークとみなさず、観測可能な経路を境界にする。ただしBGPプレフィックスは機器に貼り付いた属性ではない。より具体的な広告が現れ、集約に戻り、経路が撤回され、起点が変わることがある。観測地点ごとに見え方が異なる場合もある。機器も契約も場所も変わらないまま、数えられる仲間だけが変わり得る。

これはネットワークの仕組みから導く可能性であり、RIPE Atlasで確認された事故ではない。BGP変更だけを理由に特定プローブが保留または解除された事例は、今回の資料にない。どの経路データ、コレクター、可視性基準、時刻、プレフィックス選択規則を使うかも公開資料からは分からない。分からない部分を不具合と呼ぶべきではないが、決定時の座標として保存する価値はある。

大規模アクセス網からの異議

公開スレッドでRobert Scheckは、AS3209やAS3320への影響を尋ねた。過去の調査では、BGPで同じプレフィックスに見える複数のプローブが異なる挙動を示し、問題の切り分けに役立ったという。

この経験だけで追加の全プローブが有用だとは言えない。それでも、同一プレフィックス所属と測定上の交換可能性が同義でないことは分かる。大規模なアクセス網では、一つの外部広告の内側に、別々の内部経路、集約装置、方針、障害範囲が存在し得る。

RIPE NCCは公式の返信データで、当時その種の大規模ネットワークに通常接続されている台数へ影響しないよう上限を選んだと答えた。状況を監視し、将来は大きなプレフィックスに余裕を与えるようアルゴリズムを拡張する可能性も示した。これは調整対象を認めた回答であり、特定ASNへの恒久的な特例ではない。

同じやり取りでは、ホストが理由を見られるか、それとも「Disconnected」とだけ表示されるかも問われた。RIPE NCCは専用タグを追加し、推計13ホストへ実施前に連絡すると答えた。7月15日のウェブ版更新には、farming violationのためプローブが保留中であることを概要画面がホストへ知らせる、と記載されている。

原因名の表示は実務上の前進だ。ファイアウォールや回線、コントローラーの障害と、意図的な接続制御を区別できる。しかしラベルだけでは決定を再現できない。2、4、32、64のどれか、どのプレフィックスか、当時何台だったか、いつ再計算されるかは残らない。

公開プレフィックスと決定証拠の差

現在のプローブ管理FAQは四つの上限、BGPプレフィックス、地理的分散への例外手続きを繰り返している。ホスト向けFAQは動機も明確にする。アクティブなプローブはクレジットを生み、RIPE Atlasはトポロジー上の多様性を求め、credit farmingを抑えようとしている。

公開のプローブ一覧APIはprefix_v4とprefix_v6を定義する。記述的な状態として有用だが、今回確認した資料には、個々の保留についてプレフィックス、経路時刻、台数、閾値、審査を結ぶ公開オブジェクトはない。また、対策の全詳細を公開する必要もない。正確な送信元IP、アカウントの関係、回避を試しやすくする情報は保護すべきだ。

必要なのは二層の説明である。RIPE NCCと影響を受けるホストには、決定を再現できる非公開の証拠が要る。研究者と一般利用者には、個別設置を特定しない集計値があれば政策の影響を評価できる。透明性と機密性を同じ画面で解決する必要はない。

RIPEstatのBGP State文書は、Atlasの内部実装を示すものではなく、経路証拠の書き方を示す例だ。経路観測には対象資源、時刻、選択したコレクター、情報源ID、問い合わせ時刻を持たせられる。集中対策がRIPEstat、RIS、全RISコレクター、同じ計算を使うという証拠はない。「BGPで見える」を検証可能な座標へ分解できる、という点だけを借りればよい。

回避方法を公開しない決定記録

非公開記録の冒頭には、決定時刻、アドレス族、保護された送信元アドレス表現を置く。次に、その時点で解決されたプレフィックス、経路状態の時刻、観測範囲を保存する。競合する広告や複数の包含経路があったなら、選択規則も残す。

続いて発火した層を示す。同一ホスト・同一IPの3台目か、同一ホスト・同一プレフィックスの5台目か、IPv4集団の33台目か、IPv6集団の65台目か。決定直前の台数と有効上限は対で記録する。同時接続があれば、順序の決め方も必要だ。

最後は解除経路である。「他のプローブが抜けるまで」は方針説明として分かりやすいが、再計算の時期、BGP変更による再評価、待ち行列の有無、実際の解除イベントまでは示さない。例外申請は時刻、理由区分、判断、審査者、期限を記録し、センシティブな説明本文は公開しない。

公開統計なら、アドレス族・閾値別の保留と解除、待ち時間分布、例外件数と結果、上限変更の影響、BGP境界変更後の再評価件数で足りる。少数データは期間をまとめたり、遅らせたりできる。

これはTheo Marchの編集提案であり、RIPE NCCに内部ログがないと決めつけるものではない。閾値に当たったホストを不正者とも呼ばない。製品上のfarming violationは制御状態の名称であって、人の意図の認定ではない。

情報源