RFC 9877

Registration Data Access Protocol (RDAP) Extension for Geofeed Data

📅 published October 2025, from ietf

RFC 9877: Registration Data Access Protocol (RDAP) Extension for Geofeed Data 🎀

  • Organization: Internet Engineering Task Force (IETF)
  • Request for Comments: 9877
  • Authors: J. Singh (ARIN) and T. Harrison (APNIC)
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: October 2025
  • Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates

(part 1 of 2 💖)

Abstract 🌸

okay so this doc brings in a brand-new Registration Data Access Protocol (RDAP) extension called "geofeed1" 🦋 Its whole job is to say "hey, this RDAP server hosts geofeed URLs for its IP network objects!" It also introduces a new media type and a new link relation type for the link objects that show up in responses ✨

Status of This Memo 📜

ok this part is the boring-but-important bit, so bear with me 💅

This is an Internet Standards Track document. It's a product of the IETF, so it basically represents the consensus of the whole IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841.

Want the latest status, any errata, or a way to send feedback? Head to https://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, since they spell out your rights and restrictions for 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 they come without warranty as described in the Revised BSD License 🌈

Table of Contents 🗺️

1.  Introduction
2.  Specification
  2.1.  Media Type for a Geofeed Link
  2.2.  Geofeed Link
  2.3.  Extension Identifier
  2.4.  Example
3.  Operational Considerations
4.  Privacy Considerations
5.  Security Considerations
6.  IANA Considerations
  6.1.  RDAP Extensions Registry
  6.2.  Link Relations Registry
  6.3.  Media Types Registry
  6.4.  Structured Syntax Suffixes Registry
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🌸

okay so [RFC8805] and [RFC9632] are the docs that detail the IP geolocation feed file format (commonly called a 'geofeed') and the mechanisms for accessing it. [RFC9632] explains how a registry can make geofeed URLs available through a Routing Policy Specification Language (RPSL) [RFC2622] service. BUT the Regional Internet Registries (RIRs) have deployed Registration Data Access Protocol (RDAP) ([RFC7480], [RFC7481], [RFC9082], [RFC9083]) services as the successors to RPSL for Internet number resource registrations. Keeping feature parity between the two helps clients transition from RPSL to RDAP in this context 🦋

So this document specifies how geofeed URLs can be accessed through RDAP. It defines a new RDAP extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP network objects. It also defines a new media type and a new link relation type for the associated link objects ✨

Fetching and actually using geofeed data? Not this doc's job 🙈 For that, go read [RFC8805] and [RFC9632].

Quick key word check 💅 The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, just like that.

Indentation and whitespace in the examples are only there to show how the elements relate. They aren't required features of this specification 🎀

... in examples is shorthand for elements defined outside of this document 🧚

2. Specification 💖

[RFC9632] says a geofeed file has 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, text/csv looks like a great candidate for a geofeed file, since it supports the "#" comments needed for the RPKI signature 👀

Here's the twist though. The CSV geofeed data could be viewed directly by a user, which would make text/csv appropriate. But the most common use case is an application processing it first, so it can do IP address lookup operations. That's why using a new "application" media type with a "geofeed" subtype (Section 4.2.5 of [RFC6838]) for the geofeed data is the better choice over text/csv 💅

To that end, this document registers a new "application/geofeed+csv" media type in the IANA "Media Types" registry (see Section 6.3), and a new "+csv" suffix in the IANA "Structured Syntax Suffixes" registry (see Section 6.4) 🦋

An RDAP server that hosts geofeed URLs for its IP network objects (Section 5.4 of [RFC9083]) may include link objects for those geofeed URLs in IP network objects in its responses. These link objects get added to the "links" member of each object (Section 4.2 of [RFC9083]) ✨

In RDAP, the "value", "rel", and "href" JSON members are required for any link object. On top of that, for a geofeed link object, the "type" JSON member is RECOMMENDED. Here are the geofeed-specific components of a link object, like so:

  • "rel": The link relation type is set to "geofeed". This is a new link relation type for IP geolocation feed data, registered in the IANA "Link Relations" registry (see Section 6.2) by this document.
  • "href": The target URL is set to the HTTPS URL of the geofeed file (Section 6 of [RFC9632]) for an IP network.
  • "type": "application/geofeed+csv" (see Section 2.1).

An IP network object returned by an RDAP server MAY contain zero or more geofeed link objects, though typically an IP network will have either zero or only one. The scenario where more than one geofeed link object could come back is when the server can represent that data in multiple languages. In that case, the server SHOULD provide "hreflang" members for the geofeed link objects. Outside of the multiple-languages scenario, the server SHOULD NOT return more than one geofeed link object 💖

2.3. Extension Identifier 🎀

This document defines a new extension identifier, "geofeed1", for use by servers that host geofeed URLs for their IP network objects and include geofeed URL link objects in their responses to clients, in accordance with Section 2.2. A server that uses this extension identifier MUST include it in the "rdapConformance" array (Section 4.1 of [RFC9083]) for any lookup or search response containing an IP network object, as well as in the help response. Here's an elided example of that inclusion:

{
    "rdapConformance": [ "rdap_level_0", "geofeed1", ... ],
    ...
}

If the server includes "geofeed1" in the "rdapConformance" array, then for any response about a particular IP network object for which the server has a geofeed URL and is able to return it to the client (i.e., the server isn't compelled to omit it due to regulatory constraints or similar), the server MUST include a corresponding geofeed link object in the response 🔥

An RDAP server may use the "application/geofeed+csv" media type and the "geofeed" link relation defined in this specification in its responses without including the "geofeed1" extension identifier in those responses. That's because RDAP servers are free to use any registered media type or link relation in a standard response without implementing any particular extension. The extra value of including the extension identifier in the "rdapConformance" array is that it signals to the client that the server hosts geofeed URLs for its IP network objects. That's useful when a client gets an IP network object without a geofeed link object, since the client can infer that no geofeed data is available for that object, because 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, defining new RDAP extensions for those media types lets the server tell clients it will make data for that type accessible. That's exactly 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 extension will use different extension identifiers 🌸

2.4. Example 🧚

Here's 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"
        },
        ...
    ],
    ...
}

(part 1 of 2 · section 3 is up next 🦋)

3. Operational Considerations ✨

okay so bestie, when an RDAP client does an IP network lookup (per Section 3.1.1 of [RFC9082]), the RDAP server is required to return the most-specific IP network object that covers the IP address range the client gave it 🧐. That object might not have an associated geofeed link, but a less-specific IP network object could totally have one 👀. So clients trying to grab geofeed data for an IP range through RDAP should consider whether to retrieve the parent object of the initial response (and so on, recursively) if that first response has no geofeed data 🔍. And on the flip side, server operators should consider interface options for resource holders so they can provision geofeed links for all networks covered by the associated data 💅.

It's super common for a resource holder to keep one single geofeed file with the geofeed data for all of their resources 📁. Then they update each of their network object registrations to refer to that one file 🫶. Just like geofeed references in inetnum: objects (per [RFC9632]), clients who find a geofeed link object inside an IP network object and decide to retrieve the data from that link MUST ignore any entry where the entry's IP address range is outside the IP network object's address range 🚫. Not me ignoring the boundaries, periodt 🙅‍♀️.

Section 3.2 of [RFC8805] recommends that consumers of geofeed data verify that the publisher of the data is authoritative for the relevant resources 🧾. The RDAP bootstrap process [RFC9224] helps clients with this, since a client following that process gets directed to the RDAP server that can make authoritative statements about the disposition of the relevant resources 🎀. Iconic teamwork 🤝.

To prevent undue load on RDAP and geofeed servers, clients fetching geofeed data using these mechanisms MUST NOT do frequent real-time lookups 🛑. Please don't be that client 😭. See Section 6 of [RFC9632] for further details 📖.

4. Privacy Considerations 🔒

All the privacy considerations from Section 7 of [RFC9632] apply to this document 💜. Especially this one: the service provider publishing the geofeed file MUST take care not to expose the location of any individual 🙈. Nobody's home address goes in the feed, bestie.

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 they operate in permits implementation of the functionality defined in this document 🌍. Check the rules before you ship, no cap ✨.

5. Security Considerations 🛡️

Sections 6 and 9 of [RFC9632] document several security considerations that are equally relevant in the RDAP context 🚨. Read them, they're giving serious threat-model energy 💀.

A geofeed file MUST be referenced with an HTTPS URL, per Section 6 of [RFC9632] 🔐. No plain HTTP, not even once 😤. The geofeed file may also contain an RPKI signature, per Section 5 of [RFC9632] 🦋.

Besides that, this document does not introduce any new security considerations past those already discussed in the RDAP protocol specifications ([RFC7481], [RFC9560]) 🌸. Already covered, so we're clean 🧼.

6. IANA Considerations 📋

6.1. RDAP Extensions Registry 🧚

IANA has registered the following value in the "RDAP Extensions" registry at [RDAP-EXTENSIONS] 🎀:

Extension Identifier:  geofeed1
Registry Operator:  Any
Specification:  RFC 9877
Contact:  IETF <iesg@ietf.org>
Intended Usage:  This extension describes version 1 of a method to
   access the IP geolocation feed data through RDAP.

IANA has registered the following value in the "Link Relations" registry at [LINK-RELATIONS] ✨:

Relation Name:  geofeed
Description:  Refers to a resource with IP geofeed location
   information related to the link context.
Reference:  RFC 9877

6.3. Media Types Registry 🍓

IANA has registered the following media type in the "Media Types" registry at [MEDIA-TYPES] 💖:

Type name:  application

Subtype name:  geofeed+csv

Required parameters:  N/A

Optional parameters:  "charset" is an optional parameter for "text/
   csv", but it is not used for "application/geofeed+csv" because the
   geofeed content is always in UTF-8 (Section 2.1 of [RFC8805]).

Encoding considerations:  See Section 2 of [RFC9632].

Security considerations:  See Section 5 of RFC 9877.

Interoperability considerations:  There are no known interoperability
   problems regarding this media format.

Published specification:  RFC 9877.

Applications that use this media type:  Implementations of the
   Registration Data Access Protocol (RDAP) Extension for Geofeed
   Data.  Furthermore, any application that processes the CSV geofeed
   data.

Additional information:  This media type is a product of the IETF
   REGEXT Working Group.  The REGEXT charter, information on the
   REGEXT mailing list, and other documents produced by the REGEXT
   Working Group can be found at [REGEXT].

Person & email address to contact for further information:
   REGEXT Working Group <regext@ietf.org>

Intended usage:  COMMON

Restrictions on usage:  None

Authors:  Tom Harrison, Jasdip Singh

Author/Change controller:  IETF

6.4. Structured Syntax Suffixes Registry 💅

IANA has registered the following value in the "Structured Syntax Suffixes" registry at [STRUCTURED-SYNTAX-SUFFIXES] 🌈:

Name:  Comma-Separated Values (CSV)

+suffix:  +csv

References:  [RFC4180], [RFC7111]

Encoding Considerations:  Same as "text/csv".

Interoperability Considerations:  Same as "text/csv".

Fragment Identifier Considerations:  The syntax and semantics of
   fragment identifiers specified for +csv SHOULD be as specified for
   "text/csv".

   The syntax and semantics for fragment identifiers for a specific
   "xxx/yyy+csv" SHOULD be processed as follows:

   *  For cases defined in +csv, where the fragment identifier
      resolves per the +csv rules, then as specified for +csv.
   *  For cases defined in +csv, where the fragment identifier does
      not resolve per the +csv rules, then as specified for
      "xxx/yyy+csv".
   *  For cases not defined in +csv, then as specified for
      "xxx/yyy+csv".

Security Considerations:  Same as "text/csv".

Contact:  IETF <iesg@ietf.org>

Author/Change controller:  IETF

7. References 📚

7.1. Normative References 👑

These are the must-reads, the load-bearing ones 🫶:

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
           10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
           2003, <https://www.rfc-editor.org/info/rfc3629>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9082]  Hollenbeck, S. and A. Newton, "Registration Data Access
           Protocol (RDAP) Query Format", STD 95, RFC 9082,
           DOI 10.17487/RFC9082, June 2021,
           <https://www.rfc-editor.org/info/rfc9082>.

[RFC9083]  Hollenbeck, S. and A. Newton, "JSON Responses for the
           Registration Data Access Protocol (RDAP)", STD 95,
           RFC 9083, DOI 10.17487/RFC9083, June 2021,
           <https://www.rfc-editor.org/info/rfc9083>.

[RFC9224]  Blanchet, M., "Finding the Authoritative Registration Data
           Access Protocol (RDAP) Service", STD 95, RFC 9224,
           DOI 10.17487/RFC9224, March 2022,
           <https://www.rfc-editor.org/info/rfc9224>.

[RFC9632]  Bush, R., Candela, M., Kumari, W., and R. Housley,
           "Finding and Using Geofeed Data", RFC 9632,
           DOI 10.17487/RFC9632, August 2024,
           <https://www.rfc-editor.org/info/rfc9632>.

7.2. Informative References 🦋

These are the bonus reads for when you want the full lore 🧠:

[LINK-RELATIONS]
           IANA, "Link Relations",
           <https://www.iana.org/assignments/link-relations/>.

[MEDIA-TYPES]
           IANA, "Media Types",
           <https://www.iana.org/assignments/media-types/>.

[RDAP-EXTENSIONS]
           IANA, "RDAP Extensions",
           <https://www.iana.org/assignments/rdap-extensions/>.

[REGEXT]   IETF, "Registration Protocols Extensions (regext)",
           <https://datatracker.ietf.org/wg/regext/>.

[RFC2622]  Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
           Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
           "Routing Policy Specification Language (RPSL)", RFC 2622,
           DOI 10.17487/RFC2622, June 1999,
           <https://www.rfc-editor.org/info/rfc2622>.

[RFC4180]  Shafranovich, Y., "Common Format and MIME Type for Comma-
           Separated Values (CSV) Files", RFC 4180,
           DOI 10.17487/RFC4180, October 2005,
           <https://www.rfc-editor.org/info/rfc4180>.

[RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
           Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
           February 2012, <https://www.rfc-editor.org/info/rfc6480>.

[RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
           Specifications and Registration Procedures", BCP 13,
           RFC 6838, DOI 10.17487/RFC6838, January 2013,
           <https://www.rfc-editor.org/info/rfc6838>.

[RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
           Morris, J., Hansen, M., and R. Smith, "Privacy
           Considerations for Internet Protocols", RFC 6973,
           DOI 10.17487/RFC6973, July 2013,
           <https://www.rfc-editor.org/info/rfc6973>.

[RFC7111]  Hausenblas, M., Wilde, E., and J. Tennison, "URI Fragment
           Identifiers for the text/csv Media Type", RFC 7111,
           DOI 10.17487/RFC7111, January 2014,
           <https://www.rfc-editor.org/info/rfc7111>.

[RFC7480]  Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
           Registration Data Access Protocol (RDAP)", STD 95,
           RFC 7480, DOI 10.17487/RFC7480, March 2015,
           <https://www.rfc-editor.org/info/rfc7480>.

[RFC7481]  Hollenbeck, S. and N. Kong, "Security Services for the
           Registration Data Access Protocol (RDAP)", STD 95,
           RFC 7481, DOI 10.17487/RFC7481, March 2015,
           <https://www.rfc-editor.org/info/rfc7481>.

[RFC8805]  Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
           Kumari, "A Format for Self-Published IP Geolocation
           Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
           <https://www.rfc-editor.org/info/rfc8805>.

[RFC9560]  Hollenbeck, S., "Federated Authentication for the
           Registration Data Access Protocol (RDAP) Using OpenID
           Connect", RFC 9560, DOI 10.17487/RFC9560, April 2024,
           <https://www.rfc-editor.org/info/rfc9560>.

[STRUCTURED-SYNTAX-SUFFIXES]
           IANA, "Structured Syntax Suffixes",
           <https://www.iana.org/assignments/media-type-structured-
           suffix/>.

Acknowledgements 🫶

Huge thank you to Mark Kosters, who provided initial support and encouragement for this work, along with the authors of [RFC9632] 🌷. Gavin Brown suggested using a web link instead of a simple URL string to specify a geofeed file URL, which is genius 💡.

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 Vyncke provided valuable feedback for this document 👑✨. Main character reviewers, all of them 🥹.

Authors' Addresses 🎀

Jasdip Singh ARIN Email: jasdips@arin.net

Tom Harrison APNIC Email: tomh@apnic.net

📦 where this page comes from