要約

  • RFC 9877 は geofeed1、リンク関係 geofeed、メディアタイプ application/geofeed+csv を定義し、RDAP の IP ネットワークオブジェクトから HTTPS の geofeed を示せるようにした。
  • リンクは、ある応答で取得経路が提示されたことを示す。ファイル内の位置が最新であること、機器がそこにあること、まして個人の所在地を示すものではない。
  • 実務では参照元オブジェクトの範囲を保存し、範囲外の行を除き、発行者の権限と鮮度を確認したうえで、用途を別に承認しなければならない。

ある IP アドレスを引くと、最も具体的なネットワークオブジェクトが返る。そこに geofeed はない。親オブジェクトまでたどると、今度はリンクがある。このとき「位置情報が見つかった」と一言で片づけると、すでに三つの事実が混ざる。

子にリンクがなかったこと、親にリンクがあったこと、その先のファイルに地理的な申告があることは、それぞれ別の証拠だ。

2025 年 10 月に IETF Standards Track として公開された RFC 9877 は、この発見層を標準化する。RDAP 応答の通常の links に geofeed 関係を置き、HTTPS URL を示し、application/geofeed+csv を推奨する。geofeed1 は、その振る舞いをサーバーが提供することをクライアントへ伝える識別子である。

標準化の価値は大きい。一方、RFC は geofeed の取得と利用を明確に対象外としている。案内板の形式を統一しても、案内先の申告が現地確認済みになるわけではない。

geofeed1 が作る限定的な推論

rdapConformance に geofeed1 を掲げるサーバーは、IP ネットワークオブジェクトを含む検索・照会応答と help 応答にその識別子を含める。対象オブジェクトの geofeed URL を保持し、クライアントへ返せるなら、対応するリンクを含めなければならない。ただし、規制上の事情などで返せない場合はある。

したがって、準拠を表明したサーバーの応答にリンクがなければ、「その条件下で、そのサーバーから、そのオブジェクト用の geofeed は利用できない」と推論できる。親にもない、他の公開手段もない、当該プレフィックスに地理的属性がない、とは言えない。

逆向きの例外もある。登録済みのリンク関係とメディアタイプは、geofeed1 を掲げずに通常の RDAP 応答で使える。実装は準拠配列と実際のリンクを別々に読む必要がある。片方だけを真偽値にしてはならない。

HTTPS は通信路の完全性と Web エンドポイントの認証に役立つ。しかし、そのエンドポイントが CSV の全プレフィックスを代表できるかは別問題である。安全に取得できたことと、資源について発言する権限があることは同義ではない。

親へ上がるほど、参照範囲を忘れやすい

RFC 9082 により、IP 照会は対象を覆う最も具体的なネットワークオブジェクトを返す。RFC 9877 は、リンクがより広い親オブジェクトにだけ存在する場合を想定し、再帰的な親の取得を検討できるとしている。

そこで重要なのが境界である。親オブジェクトが示したファイルに別の資源まで収録されていても、参照元オブジェクトのアドレス範囲外の行は必ず無視する。正規の URL から届いた一つのファイルが、全行について発言権を得るわけではない。

RFC 8805 は、発行者が関連資源について権限を持つことの確認を勧める。RFC 9224 のブートストラップは、資源の割り当て状態について権威ある説明が可能な RDAP サービスへ導く。これはポインターの来歴を強めるが、都市名の現況や通信の出口、利用者の居場所までは保証しない。

geofeed は、資源保持者がプレフィックス単位で公表する運用上の地理情報である。粒度を粗くすることも合理的だ。設備移転とキャッシュ更新には時間差があり、anycast、移動網、複数地域をまたぐ企業網は単一地点という理解を崩す。「ある時点に、ある範囲について申告された運用地理」と記録すべきで、「人を特定した」と書くべきではない。

強い署名でも判断権限までは生まれない

RFC 9092 を廃止・更新した RFC 9632 は、任意の RPKI 認証を示す。有効な署名は、対象アドレス空間を覆う証明書とファイルの関係を強化する。それでも各所在地の意味的な正しさや鮮度、アクセス制限などへの利用可否は決めない。

状態は細分化して残す必要がある。リンク発見、取得成功、通信路確認、参照範囲保存、行の除外、発行権限確認、署名判定、鮮度計算、プライバシー根拠、用途承認、結果観測である。最後に「位置確定」しか残らない設計では、訂正が届いても影響範囲を追えない。

取得頻度にも限界がある。RFC 9877 はサービスへ過度な負荷を与える頻繁なリアルタイム照会を禁じる。RFC 9632 は HTTP の鮮度情報に従い、それがなければ週一回を超えて取得しないよう勧める。今 API を呼んだという事実は、元データの時刻を新しくしない。

プライバシーはさらに明確だ。発行者は個人の場所を露出しないよう注意し、レジストリ運営者は規制環境が機能の提供を許すか確認する。発見が容易になったことは、目的外利用を容易にしてよいという意味ではない。