要約

  • 2026年9月3日に取得した LACNIC の公開 geofeed は、13,569行に13,546個の異なるプレフィックスを含んでいた。同じプレフィックスが二度現れる組は23件で、9件は行の内容も同一、14件は所在地の記載が異なった。
  • その14件のうち4件で国コードが食い違う。170.51.97.0/24 の二つの行は、それぞれウルグアイとパラグアイを示す。同じ長さの同じ範囲なので、最長一致によって片方を優先することはできない。
  • 2回の取得内容はバイト単位で一致したが、実際の所在地、申告者、記録の新旧、利用者側の処理や被害は確認していない。集約ファイルの整理と地理情報の正しさを証明することを混同してはならない。

一つのキーで読み込んだときに消えるもの

表を辞書に変換するのは簡単だ。IP アドレスのプレフィックスをキーにし、国や都市を値にすればよい。難しいのは、同じキーに異なる値があるとき、その簡単さが何を捨てるかである。

LACNIC の公開 geofeed では、取得したファイルの2,631行目に 170.51.97.0/24,UY,UY-MO,Montevideo, がある。12,633行目には 170.51.97.0/24,PY,PY-ASU,Asuncion, が現れる。国コードの UY はウルグアイ、PY はパラグアイだ。同じ /24 が、別々の国と都市を伴っている。

仮に最初の行を残すプログラムならウルグアイを取り、最後の行で上書きするプログラムならパラグアイを取る。これは処理方法を比べるための仮定であり、実在する利用者の実装を調べた結果ではない。どちらのプログラムも一つの答えを出せる。しかし、ファイルの順序だけでは、どちらの国が正しいかは分からない。行番号は更新日時ではない。

geofeed は、ネットワーク側が IP アドレスの使用地域を知らせるための仕組みだ。一つのデータに答えが二つある状態を、一つしか答えがなかった状態へ黙って変えてしまうと、後段の利用者は矛盾そのものを見失う。問題の中心はここにある。今回の観測は、二つの国のどちらかを裁定する材料にはなっていない。

23件を同じ問題として数えない

調査したのは9月3日の二つの取得結果である。取得要求の開始はそれぞれ10時31分23秒と10時45分12秒（UTC）だった。成功した二つのファイルはともに438,145バイトで、内容は完全に一致した。その間に二つの要求がタイムアウトしたことから、サービス全体の稼働状況を推定することはできない。ここで示すのは同じ内容を二度確認したという範囲の結果であり、長期にわたる障害や変化の履歴ではない。

ファイルには IPv4 の10,782行と IPv6 の2,787行、計13,569行があった。プレフィックスを正規化して照合すると、異なる範囲は13,546個。同じプレフィックスを持つ23組、46行があり、重複分は23行となる。すべてのプレフィックスは IPv4 または IPv6 の正規の範囲として解析でき、ホスト部のビットが立った表記もなかった。プレフィックス文字列そのものをまとめる別の集計でも同じ件数を得た。これは同じ調査者による方法の照合であり、独立した第三者監査ではない。

同じプレフィックスを持つ組の分類 組数
所在地を含む行の内容が同一 9
国コードが異なる 4
国は同じで地域または都市が異なる 4
国は同じで所在地の記載の詳しさが異なる 6

9組の同一行は、情報の内容よりも重複出力の問題として扱える。例えば 200.123.12.0/24,PE,PE-LIM,Lima, は連続して二度現れる。片方を通常の出力から省いても、その行が述べる所在地は変わらない。ただし、後から経緯を調べるための記録まで消す必要はない。

残る14組は同一行ではない。そのうち国コードが異なるのは、冒頭の /24 と 181.238.0.0/24、181.239.32.0/24、186.182.0.0/24 の四つである。後の三つは PY と AR、すなわちパラグアイとアルゼンチンの食い違いだった。

国が同じでも地理的な主張が同じとは限らない。200.63.248.0/21 はエクアドルの Ibarra と Quito に対応する異なる地域・都市の組を持つ。一方、200.80.255.0/24 の一方には AR,AR-B,Buenos Aires, があり、もう一方は AR,,, だった。後者はアルゼンチン以外の情報を空欄にしている。これを「別の都市を主張した」と数えるのは誤りだ。記載が詳しいほうが新しい、あるいは正確だとも言えない。

これらの件数は、組織数、利用者数、経路数を表していない。同じ組織が複数のプレフィックスを持つ可能性も、異なる事情で重複が生じた可能性も残る。行の集計をそのまま地理情報全体の正解率に置き換えることはできない。

より長いプレフィックスという解決策が使えない

geofeed の形式を記述する RFC 8805 は、この区別を理解する手掛かりになる。2020年8月の Informational 文書であり、それ自体が法律上の義務を定めるものではない。2.1.3節では同じプレフィックスの重複をエラーとして管理者の確認につなげる扱いと、異なる長さの範囲が包含関係になる場合を区別している。後者には最長一致という原則が使える。

実際のファイルには 177.126.48.0/22 と 177.126.48.0/24 の両方がある。/24 は /22 の一部なので、その /24 内のアドレスに対して細かな指定を使うという読み方ができる。範囲が重なること自体は、完全に同じプレフィックスが重複することと同義ではない。

だが 170.51.97.0/24 と 170.51.97.0/24 は同じ範囲で、どちらも同じ長さである。最長一致は同点を崩せない。RFC に「先に現れた国を選べ」「最後の国を選べ」という裁定規則があるわけでもない。

同じ文書は、項目によって空欄を認めている。したがって、都市が未記入であることと、異なる都市が記載されていることも分けなければならない。形式を確認する処理が、いつの間にか所在地を選ぶ処理になれば、確認できた事実よりも強い結論を出してしまう。

集約する価値と、集約だけでは届かない範囲

LACNIC の geofeed サービス案内 は、会員の管理者が MiLACNIC を通じて国、地域、都市を登録し、その情報を公開 CSV に集約する仕組みを説明している。案内の英語版の掲載日は2020年9月7日であり、新たに始まった2026年のサービスではない。任意の申告をまとめて入手できることには実務的な意味がある。利用者は、それぞれのネットワークの説明を個別に探し続けずに済む。

その役割を、所在地を保証する役割へ膨らませる必要はない。LACNIC の IP geolocation 解説 は、Whois の連絡先や契約上の地域が、アドレスの実際の使用場所と同じとは限らないことを説明している。geofeed は使用地域を示し、必要に応じて範囲を細分化するために使える。一方、商用の地理情報データベースを LACNIC が管理するわけではない。

RFC 8805 も geofeed を所在地を判断するための手掛かりとして扱い、利用者に他の情報源を優先する余地を残す。情報を出す権限の確認と、記載された所在地が正しいかどうかは別の問題である。今回の集計は、権限を検証した調査でも、地上の位置を測定した調査でもない。

申告者、変更時刻、重複が生まれた理由は、このファイルだけでは分からない。複数地域に正当に分散して利用している可能性も否定できない。会員のアカウントや非公開ログにはアクセスしておらず、商用データベースの採用状況や利用者への影響も測定していない。記録の不一致から、不正な保有、RPKI の失敗、検閲、通信障害を推定することはできない。

それでも改善できる部分はある。同じ行の二重出力は、経緯を保存したうえで通常の提供データから整理できる。異なる所在地を持つ同一プレフィックスは、どちらかを黙って捨てるのではなく、確認対象として区別できる。無関係な正常レコードまで止める理由はない。利用者側も、用途に応じて「不明」と扱う、別の証拠と照合する、判断を保留するという選択肢を持てる。地理情報が未解決であることは、アドレス割り当てや経路を無効にする根拠ではない。