| RFC 9877 | RDAP Geofeed | October 2025 |
| Singh & Harrison | Standards Track | [Page] |
This document defines a new Registration Data Access Protocol (RDAP) extension, "geofeed1", for indicating that an RDAPserver hosts geofeed URLs for its IP network objects. It also defines a new media type and a new link relation type forthe associated link objects included in responses.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9877.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC8805] and[RFC9632] detail the IP geolocation feed (commonly known as 'geofeed') file format and associatedaccess mechanisms. While[RFC9632] describes how a registry can make geofeed URLs available by way of a RoutingPolicy Specification Language (RPSL)[RFC2622] service, the Regional Internet Registries (RIRs) have deployedRegistration Data Access Protocol (RDAP) ([RFC7480],[RFC7481],[RFC9082],[RFC9083]) services as successors toRPSL for Internet number resource registrations, and maintaining feature parity between the two services supports clienttransition from RPSL to RDAP in this context. To that end, this document specifies how geofeed URLs can be accessedthrough RDAP. It defines a new RDAP extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for itsIP network objects, as well as a new media type and a new link relation type for the associated link objects.¶
Fetching and making use of geofeed data is out of scope for the purposes of this document. See[RFC8805] and[RFC9632] for further details.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Indentation and whitespace in examples are provided only to illustrate element relationships and are not requiredfeatures of this specification.¶
"..." in examples is used as shorthand for elements defined outside of this document.¶
[RFC9632] requires a geofeed file to be a UTF-8[RFC3629] comma-separated values (CSV) file, with a series of "#"comments at the end for the optional Resource Public Key Infrastructure (RPKI)[RFC6480] signature. At first glance,the "text/csv" media type seems like a good candidate for a geofeed file, since it supports the "#" comments needed forincluding the RPKI signature.¶
However, although the CSV geofeed data could be viewed directly by a user such that the "text/csv" media type wasappropriate, the most common use case will involve it being processed by some sort of application first, in order tofacilitate subsequent IP address lookup operations. Therefore, using a new "application" media type with a "geofeed"subtype (Section 4.2.5 of [RFC6838]) for the geofeed data is preferable to using "text/csv".¶
To that end, this document registers a new "application/geofeed+csv" media type in the IANA "Media Types" registry (seeSection 6.3), and a new "+csv" suffix in the IANA "Structured Syntax Suffixes" registry (seeSection 6.4).¶
An RDAP server that hosts geofeed URLs for its IP network objects (Section 5.4 of [RFC9083]) may include link objectsfor those geofeed URLs in IP network objects in its responses. These link objects are added to the "links" member ofeach object (Section 4.2 of [RFC9083]).¶
In RDAP, the "value", "rel", and "href" JSON members are required for any link object. Additionally, for a geofeed linkobject, the "type" JSON member isRECOMMENDED. The geofeed-specific components of a link object are like so:¶
An IP network object returned by an RDAP serverMAY contain zero or more geofeed link objects, though typically an IPnetwork will have either zero or only one. The scenario where more than one geofeed link object could bereturned is when the server is able to represent that data in multiple languages. In such a case, the serverSHOULDprovide "hreflang" members for the geofeed link objects. Except for the multiple-languages scenario, the serverSHOULD NOT return more than one geofeed link object.¶
This document defines a new extension identifier, "geofeed1", for use by servers that host geofeed URLs for their IPnetwork objects and include geofeed URL link objects in their responses to clients in accordance withSection 2.2. Aserver that uses this extension identifierMUST include it in the "rdapConformance" array (Section 4.1 of [RFC9083]) forany lookup or search response containing an IP network object, as well as in the help response. Here is an elidedexample of this inclusion:¶
{ "rdapConformance": [ "rdap_level_0", "geofeed1", ... ], ...}¶If the server includes "geofeed1" in the "rdapConformance" array, then for any response concerning a particular IPnetwork object for which the server possesses a geofeed URL and is able to return it to the client (i.e., the server is notcompelled to omit it due to regulatory constraints or similar), the serverMUST include a corresponding geofeed linkobject in the response.¶
An RDAP server may make use of the "application/geofeed+csv" media type and the "geofeed" link relation defined in thisspecification in its responses without including the "geofeed1" extension identifier in those responses, because RDAPservers are free to use any registered media type or link relation in a standard response without implementing anyparticular extension. The additional value of including the extension identifier in the "rdapConformance" array is thatit signals to the client that the server hosts geofeed URLs for its IP network objects. This is useful where a clientreceives an IP network object without a geofeed link object, because in that case the client can infer that no geofeeddata is available for that object, since the server would have provided it if it were available.¶
Although a server may use registered media types in its link objects without any restrictions, it is useful to definenew RDAP extensions for those media types in order for the server to communicate to clients that it will make data forthat type accessible. This is what the server does with the "geofeed1" extension identifier.¶
The "1" in "geofeed1" denotes that this is version 1 of the geofeed extension. New versions of the geofeed extensionwill use different extension identifiers.¶
The following is an elided example of an IP network object with a geofeed link object:¶
{ "objectClassName": "ip network", "handle": "XXXX-RIR", "startAddress": "2001:db8::", "endAddress": "2001:db8:0:ffff:ffff:ffff:ffff:ffff", "ipVersion": "v6", "name": "NET-RTR-1", "type": "DIRECT ALLOCATION", "country": "AU", "parentHandle": "YYYY-RIR", "status": [ "active" ], "links": [ { "value": "https://example.net/ip/2001:db8::/48", "rel": "self", "href": "https://example.net/ip/2001:db8::/48", "type": "application/rdap+json" }, { "value": "https://example.net/ip/2001:db8::/48", "rel": "geofeed", "href": "https://example.com/geofeed", "type": "application/geofeed+csv" }, ... ], ...}¶When an RDAP client performs an IP network lookup, perSection 3.1.1 of [RFC9082], the RDAP server is required to returnthe most-specific IP network object that covers the IP address range provided by the client. That IP network object maynot have an associated geofeed link, but it is possible that a less-specific IP network object does have such a link.Clients attempting to retrieve geofeed data for a given IP address range via RDAP should consider whether to retrievethe parent object for the initial response (and so on, recursively) in the event that the initial response does notcontain geofeed data. Conversely, server operators should consider interface options for resource holders in order tosupport the provisioning of geofeed links for all networks covered by the associated data.¶
It is common for a resource holder to maintain a single geofeed file containing the geofeed data for all of theirresources. The resource holder then updates each of their network object registrations to refer to that single geofeedfile. As with geofeed references in inetnum: objects (per[RFC9632]), clients who find a geofeed link object within anIP network object and opt to retrieve the data from the associated linkMUST ignore any entry where the entry's IPaddress range is outside the IP network object's address range.¶
Section 3.2 of [RFC8805] recommends that consumers of geofeed data verify that the publisher of the data isauthoritative for the relevant resources. The RDAP bootstrap process[RFC9224] helps clients with thisrecommendation, since a client following that process will be directed to the RDAP server that is able to makeauthoritative statements about the disposition of the relevant resources.¶
To prevent undue load on RDAP and geofeed servers, clients fetching geofeed data using these mechanismsMUST NOT dofrequent real-time lookups. SeeSection 6 of [RFC9632] for further details.¶
All the privacy considerations fromSection 7 of [RFC9632] apply to this document. In particular, the service providerpublishing the geofeed fileMUST take care not to expose the location of any individual.¶
Many jurisdictions have laws or regulations that restrict the use of "personal data", per the definition in[RFC6973].Given that, registry operators should ascertain whether the regulatory environment in which they operate permitsimplementation of the functionality defined in this document.¶
Sections6 and9 of[RFC9632]document several security considerations that are equally relevant in the RDAP context.¶
A geofeed fileMUST be referenced with an HTTPS URL, perSection 6 of [RFC9632]. The geofeed file may also contain anRPKI signature, perSection 5 of [RFC9632].¶
Besides that, this document does not introduce any new security considerations past those already discussed in the RDAPprotocol specifications ([RFC7481],[RFC9560]).¶
IANA has registered the following value in the "RDAP Extensions" registry at[RDAP-EXTENSIONS]:¶
IANA has registered the following value in the "Link Relations" registry at[LINK-RELATIONS]:¶
IANA has registered the following media type in the "Media Types" registry at[MEDIA-TYPES]:¶
IANA has registered the following value in the "Structured Syntax Suffixes" registryat[STRUCTURED-SYNTAX-SUFFIXES]:¶
The syntax and semantics of fragment identifiers specified for +csvSHOULD be as specified for "text/csv".¶
The syntax and semantics for fragment identifiers for a specific "xxx/yyy+csv"SHOULD be processed as follows:¶
Mark Kosters provided initial support andencouragement for this work, along with the authors of[RFC9632].Gavin Brown suggested using a web link insteadof a simple URL string to specify a geofeed file URL.Andy Newton,James Gould,Scott Hollenbeck,Mario Loffredo,Orie Steele,Alexey Melnikov,Mark Nottingham,Rifaat Shekh-Yusef,Dale R. Worley,Dhruv Dhody,Mohamed Boucadair,Mahesh Jethanandani,Ketan Talaulikar, andÉric Vynckeprovided valuable feedback for this document.¶