要約

  • LACNICが2026年5月27日に掲載した研究は、RRC15とRRC24から「2026年3月に該当するすべての更新」を使ったとし、続く段落では48時間にわたり22億2,200万件超のBGPメッセージを統合したと説明する。
  • 安定性表の総数は2,222,981,835件。IPv4とIPv6の更新数159,964,848件、693,016,987件を足すと852,981,835件となり、差はちょうど1,370,000,000件である。
  • アドレス族別の接頭辞数は総接頭辞数1,436,539に、四つのASN分類は総ASN数86,398に完全に一致する。残る差は範囲やメッセージ種別、処理段階の違いかもしれず、誤集計の証拠ではない。
  • 観測期間と処理時間、コレクターのピア集合、MRTファイル、ソフトウェア、計数定義、中間件数、訂正履歴を結ぶ版管理済み照合票があれば、研究を地域全体の国勢調査のように扱わず再検証できる。

合う小計が、合わない小計を際立たせる

LACNICの記事は、ASNのchurn rateを中央値と平均で区切り、「安定」「落ち着かない」「騒がしい」「重大」の四群に分類した。まず注目すべきは、この表の内部整合性だ。43,199、41,650、1,530、19を加えると86,398となり、記事のユニークASN総数と一致する。

接頭辞も同じである。IPv4の1,146,937とIPv6の289,602は、ユニーク接頭辞総数1,436,539に一致する。読者は電卓だけで、個別表から総表への接続を確認できる。

ところが更新数は異なる。IPv4の159,964,848とIPv6の693,016,987の合計は852,981,835。安定性表にあるBGPメッセージ総数2,222,981,835との差は1,370,000,000になる。

この差を「13億7,000万件のミス」と呼ぶ根拠はない。一方はBGPメッセージ、もう一方は更新と表記されている。生のMRT/BGPレコードとフィルター後のUPDATE、あるいはメッセージと接頭辞動作を数えている可能性がある。撤回、空の更新、重複、マルチプロトコル情報、解析できなかったレコードの扱いでも数字は変わる。公開ページが示していないのは、正解そのものではなく、二つの集計段階の対応関係である。

3月と48時間は同じ時間軸なのか

データ源の節は、モンテビデオのRRC24とサンパウロのRRC15を挙げ、2026年3月に該当するすべての更新を対象にしたと記す。次の処理節はPython 3、mrtparser、pandas、NumPy、Matplotlibを挙げ、48時間で22億2,200万件超を統合・分類したとする。

48時間が計算に要した時間なら、3月という観測範囲と矛盾しない。48時間がデータの期間なら、3月全体との関係を説明する必要がある。二日間の抽出、二コレクター分の日数、あるいは月内の限定区間かもしれない。「3月全部」は探索したアーカイブを指し、最終入力は別なのかもしれない。英語、スペイン語、ブラジル・ポルトガル語の各版からは決められない。

観測の時計と処理の時計は分けるべきだ。一か月には保守、週末、障害、ピア集合の変化が含まれる。二日間でも外れ値の発見には有効だが、時間的代表性は同じではない。計算時間ならネットワークの状態を一切表さない。

結論にある「0.02%のspeakerが不安定性の大半を生む」という表現も、この枠内で読む必要がある。19は86,398のおよそ0.02%で、割合は再計算できる。しかし、その19 ASNが別期間・別ピア・別閾値でも同じ位置にいるとは限らない。「重大」は限定された分析上の状態であり、運用者への恒久的評価ではない。

公開アーカイブは実行履歴ではない

RIPE RISの公開性は強い。文書によれば、データはroute collectorごとに保存され、そのコレクターが各ピアから受け取った情報が一つのファイル群に入る。ファイル名はrrcXX/YYYY.MM/TYPE.YYYYMMDD.HHmm.gz。通常、bviewは8時間ごと、updatesは5分ごとに作成される。RRC15とRRC24の2026年3月ディレクトリにも両者が見える。

それでも、公開棚からどのファイルを取り出したかは研究者にしか分からない。部分ファイルや欠損、解析エラーをどう扱ったか、ピアが途中で増減したか、bviewを初期状態だけに使ったか、総数にも含めたかはディレクトリから復元できない。

観測地点の違いも重要だ。RIPE NCCはRRC15をサンパウロのPTTMetro-SP、RRC24をモンテビデオのLACNIC Multihopとして掲げる。両者は固有のピア集合から見る測定装置であり、LACNIC会員、地域の全ルーター、通信量、利用者、障害を数える装置ではない。

数える単位はコードの中で決まる

RFC 4271にはOPEN、UPDATE、KEEPALIVE、NOTIFICATIONという異なるBGPメッセージがある。RFC 6396にはTABLE_DUMP、BGP4MPメッセージ、BGP4MP状態変化など異なるMRT型がある。RIS Liveはピア状態のメタデータも区別する。

これらはLACNICの実装を説明しない。しかし「メッセージ」という語だけでは実装が決まらないことを示す。一つのUPDATEが複数接頭辞を共有属性とともに運び、公告と撤回やマルチプロトコル情報を含むことがある。生レコード、復号メッセージ、UPDATE、NLRI、接頭辞動作、ピア別観測は、それぞれ違う正当な件数になる。

IPv4とIPv6への割り当ても規則を要する。両方に触れるUPDATEは二重計上するのか。フィルター後にNLRIが残らないものはどうするのか。multi-origin、AS_SET、不正なAS_PATHをどのASNに帰属させるのか。二つのコレクターで同じ接頭辞を見たとき、どの段階で重複を除くのか。churn rateの分子と分母は、こうした判断で決まる。

一枚の照合票で足りる

最初にUTCの観測開始・終了と、処理開始・終了を別欄に置く。48時間がどちらかを明示し、3月が全入力か候補範囲かを示す。

次にRRC15/RRC24の正確なMRTファイル名、ハッシュ、バイト数、ピア集合の集約スナップショット、欠損と失敗を記録する。bviewの用途も分離する。

中央には計数辞書を置く。MRTレコード、BGPメッセージ、UPDATE、公告、撤回、NLRI、接頭辞出現、ユニーク接頭辞を定義し、各フィルター前後の件数を示す。アドレス族、空更新、重複、解析失敗、multi-origin、ASN帰属の規則には版番号を付ける。

最後に入力から出力までの中間表を作る。2,222,981,835と852,981,835が異なる母集団なら、1,370,000,000がどの段階にあり、なぜ家族別表に入らないかを一行で説明できる。Pythonとmrtparser等の版、コード改訂、設定ハッシュ、run ID、訂正履歴も残す。

再現性は観測された側も守る

元記事は、ソフトウェア不具合、設定ミス、機器、電源、攻撃を一般的な原因として挙げる。19 ASNについて原因を立証したわけではない。高い更新数だけで悪意、利用者被害、回避可能な怠慢を推定することもできない。

照合票があれば、あるASNが一ピアからだけ見えたのか、短い事象だったのか、期間を通じて続いたのかを検討できる。ピア集合を変えた再分析とも比較できる。方法の訂正が必要になっても、研究全体への非難ではなく、限定された処理変更として示せる。

LACNICの測定は大きく、集中度という有用な問いを投げかけた。だからこそ、既に公開した数字を結ぶ小さな記録に価値がある。次に必要なのはランキングの追加ではなく、ランキングまでの道筋だ。

出典