Summary

  • RFC 9877 defines geofeed1, the geofeed link relation and application/geofeed+csv, allowing an RDAP response to point from an IP network object to an HTTPS geofeed.
  • The link proves a discovery path in a particular response. It does not by itself prove that every row is current, that a device is physically present in the named place, or that an individual has been located.
  • A defensible use records object scope, filters out-of-range rows, checks publisher authority and freshness, protects privacy and keeps the downstream policy decision separate.

Ask an RDAP server about one address. The server returns the most-specific network object, but that object has no geofeed link. Move one level outward to its parent and a link appears. Which result is the location fact: the missing child link, the present parent link, or a row inside the file at the end of that link?

None of them, yet. Each is evidence about a different layer.

That is the useful discipline behind RFC 9877, an IETF Standards Track document published in October 2025. It defines a standard way for an RDAP server to expose geofeed URLs for IP network objects. The extension identifier is geofeed1; the link relation is geofeed; the registered media type is application/geofeed+csv. This is a real improvement over consumers having to guess how a registration service presents a pointer.

The improvement is discovery, not omniscience. RFC 9877 expressly leaves fetching and use of the geofeed outside its scope. A client that treats the appearance of the link as the end of its inquiry has promoted metadata into a verdict.

What the conformance signal actually commits

RDAP responses have an rdapConformance array. A server that claims geofeed1 must include that identifier in lookup or search responses containing IP network objects, as well as in its help response. When the server possesses a geofeed URL for a particular object and is able to return it, the server must include the corresponding link. The qualification matters: regulatory or similar constraints may require omission.

This creates a useful negative inference. If a geofeed1 server returns an object without a geofeed link, a client may infer that geofeed data are not available from that server for that object under the current conditions. It cannot infer that the address has no operational geography, that no parent object carries a link, that no other data source exists, or that the resource holder has never published a feed.

There is another asymmetry. A server may use the registered geofeed relation and media type without advertising geofeed1, because registered link relations and media types are available to ordinary RDAP responses. Clients must therefore inspect both the conformance claim and the actual link objects. One field does not substitute for the other.

The link itself uses the normal RDAP links structure. Its target is an HTTPS URL. HTTPS can protect the retrieval channel and authenticate the web endpoint; it does not, by itself, prove that the endpoint controls the address space described by every row.

The parent-object problem is an authority problem

RFC 9082 requires an IP lookup to return the most-specific network object covering the query. RFC 9877 recognizes that this object may have no geofeed while a less-specific parent does. A client may choose to retrieve parents recursively.

That traversal changes the evidence boundary. If the parent object covers a /16 and its file also contains unrelated prefixes, a consumer following the parent's link must ignore every row outside the parent's address range. If it later finds a more-specific authoritative feed, precedence and conflict handling must be explicit. A file is not licensed to speak for an address merely because it arrived through a valid URL.

RFC 8805 recommends verifying that the publisher is authoritative for the relevant resources. The RDAP bootstrap process in RFC 9224 helps by directing the client to the registration service able to make authoritative statements about resource disposition. That is stronger provenance for the pointer. It is not a guarantee that a city field is fresh, that network traffic exits there, or that a user is there.

Geofeeds are publisher-supplied statements about prefix geography. They can legitimately be coarse. Infrastructure can move while caches remain. An anycast service can make a single physical reading misleading. A corporate allocation can serve users in several places. The evidence should be described as claimed operational geography at a recorded time, with a recorded scope—not as the coordinates of a person.

Authentication strengthens one link in the chain

RFC 9632, which obsoletes RFC 9092, describes geofeed discovery and an optional RPKI-based authenticator. A valid signature can strengthen the claim that the data were authorized through a covering address-space certificate. It does not make each location semantically accurate or approve every use of it.

The difference should appear in system states: link discovered; file fetched; transport verified; referring range recorded; rows filtered; publisher authority checked; signature status recorded; freshness evaluated; privacy basis established; local use authorized; outcome observed. Collapsing those states into located=true destroys both auditability and the ability to correct errors.

Freshness also has an operational cost. RFC 9877 says clients must not perform frequent real-time lookups that create undue load. RFC 9632 recommends respecting HTTP freshness information and, without it, not fetching more often than weekly. A location decision made every second cannot honestly claim that a weekly source is real-time. The system must expose the age of the evidence instead of hiding it behind a live API call.

Privacy sets a harder boundary. RFC 9877 applies RFC 9632's privacy considerations and says the publisher must take care not to expose the location of any individual. Registry operators must also assess whether their regulatory environment permits the function. A convenient link does not waive purpose limitation, proportionality or local law.