Internet-Draft rdap-geofeed April 2024
Singh & Harrison Expires 21 October 2024 [Page]
Registration Protocols Extensions (regext)
Intended Status:
Standards Track
J. Singh
T. Harrison

An RDAP Extension for Geofeed Data


This document defines a new Registration Data Access Protocol (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 link relation type for the associated link objects included in responses.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 21 October 2024.

Table of Contents

1. Introduction

[RFC8805] and [I-D.ietf-opsawg-9092-update] (obsoletes [RFC9092]) detail the IP geolocation feed (commonly known as 'geofeed') file format and associated access mechanisms. 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 networks, as well as a media type and a link relation type for the associated link objects.

1.1. Requirements Language

The keywords "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 a REQUIRED feature of this protocol.

"..." in examples is used as shorthand for elements defined outside of this document.

2. Specification

2.3. Extension Identifier

An RDAP server that returns geofeed link objects in accordance with this specification is RECOMMENDED to include the "geofeed1" extension identifier in the "rdapConformance" array for any lookup or search response containing an IP network object, as well as in the help response. Here is an elided example for this inclusion:

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

Extension identifier inclusion is not mandatory, because RDAP does not require that an extension identifier be included in responses merely to make use of new media types or link relation types. An RDAP server that includes the "geofeed1" identifier is signalling to clients that it hosts geofeed URLs and will return those URLs in accordance with this specification where they are available. The main benefit of including the identifier is that it permits a client to determine that a server does host geofeed URLs, which is useful where a client receives an IP network object without a geofeed URL, for example.

Although a server may use registered media types in its link objects without any restrictions, it may be useful to define new RDAP extensions for those media types in order for the server to communicate to clients that it will make data for that type accessible, in the same way that the server does with the "geofeed1" extension identifier.

2.4. Example

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" ],
            "value": "",
            "rel": "self",
            "href": "",
            "type": "application/rdap+json"
            "value": "",
            "rel": "geo",
            "href": "",
            "type": "application/geofeed+csv"

3. Privacy Considerations

When including a geofeed file URL in an IP Network object, an RDAP server operator SHOULD follow the guidance from Section 7 of [I-D.ietf-opsawg-9092-update] to not accidentally expose the location of an 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 permits implementation of the functionality defined in this document.

4. Security Considerations

[I-D.ietf-opsawg-9092-update] requires an HTTPS URL for a geofeed file. The geofeed file may also contain an RPKI signature. Besides that, this document does not introduce any new security considerations past those already discussed in the RDAP protocol specifications.

5. IANA Considerations

5.1. RDAP Extensions Registry

IANA is requested to register the following value in the RDAP Extensions Registry at

  • Extension identifier: geofeed1
  • Registry operator: Any
  • Published specification: This document.
  • Contact: IETF
  • Intended usage: This extension describes version 1 of a method to access the IP geolocation feed data through RDAP.

5.3. Media Types Registry

IANA is requested to register the following value in the Media Types Registry at

  • Type name: application
  • Subtype name: geofeed+csv
  • Required parameters: N/A
  • Optional parameters: N/A
  • Encoding considerations: See Section 2 of [I-D.ietf-opsawg-9092-update].
  • Security considerations: See Section 4 of this document.
  • Interoperability considerations: There are no known interoperability problems regarding this media format.
  • Published specification: This document.
  • 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
  • Person & email address to contact for further information: IETF
  • Intended usage: COMMON
  • Restrictions on usage: None
  • Authors: Tom Harrison, Jasdip Singh
  • Change controller: IETF
  • Provisional Registration: No

5.4. Structured Syntax Suffixes Registry

IANA is requested to register the following value in the Structured Syntax Suffixes Registry at

  • 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 in +csv.

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

For cases not defined in +csv, then as specified in "xxx/yyy+csv".

6. Acknowledgements

Mark Kosters provided initial support and encouragement for this work, along with the [RFC9092] authors. Gavin Brown suggested using a web link instead of a simple URL string to specify a geofeed file URL. Andy Newton, James Gould, and Scott Hollenbeck also provided valuable feedback for this document.

7. Change History

7.1. Changes from 00 to 01

  • Now using a web link instead of a simple URL string to specify a geofeed file URL.
  • Renamed the extension as "geofeed1" instead of "geofeedv1".
  • Introduced the new "geo" link relation type.
  • Introduced the new "application/geofeed+csv" media type.

7.2. Changes from 01 to 02

  • Updated the "Requirements Language" section for examples.
  • Added an example for RDAP conformance.
  • Updated the rationale for using the new "application/geofeed+csv" media type.
  • Updated the "Applications that use this media type" section for the "application/geofeed+csv" registration.

7.3. Changes from 02 to 03

  • Removed "value" and "hreflang" explanations from the "Geofeed Link" section. Further, clarified the cardinality of geofeed link objects.
  • Updated extensibility verbiage in the "Media Type for a Geofeed Link" section.
  • In the "Example" section, updated the domain in "href" of the geofeed link object to contrast with the domain in "value" to highlight that "href" is for a geofeed file hosted at a network operator site whereas "value" is for an IP network object from an RDAP server.
  • Removed the "Redaction" section since the geofeed files are public to start with.
  • Added URLs for various IANA registries.

7.4. Changes from 03 to 04

  • Updated the criteria for including the extension identifier in "rdapConformance".

7.5. Changes from 04 to 05

  • Made various editorial changes.

8. References

8.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, , <>.
Shafranovich, Y., "Common Format and MIME Type for Comma-Separated Values (CSV) Files", RFC 4180, DOI 10.17487/RFC4180, , <>.
Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, , <>.
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <>.
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, , <>.
Hausenblas, M., Wilde, E., and J. Tennison, "URI Fragment Identifiers for the text/csv Media Type", RFC 7111, DOI 10.17487/RFC7111, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
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, , <>.
Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, , <>.
Bush, R., Candela, M., Kumari, W., and R. Housley, "Finding and Using Geofeed Data", RFC 9092, DOI 10.17487/RFC9092, , <>.

8.2. Informative References

Bush, R., Candela, M., Kumari, W. A., and R. Housley, "Finding and Using Geofeed Data", Work in Progress, Internet-Draft, draft-ietf-opsawg-9092-update-11, , <>.
Shafranovich, Y., "Common Format and MIME Type for Comma-Separated Values (CSV) Files", Work in Progress, Internet-Draft, draft-shafranovich-rfc4180-bis-06, , <>.

Authors' Addresses

Jasdip Singh
Tom Harrison