ARIN

jasdips@arin.net

APNIC

tomh@apnic.net

ART regext 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 a new link relation type for the associated link objects included in responses.

Status of This Memo 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 at .

Copyright Notice 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 () 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.

Table of Contents

• .  Introduction
• .  Specification
  • .  Media Type for a Geofeed Link
  • .  Geofeed Link
  • .  Extension Identifier
  • .  Example
• .  Operational Considerations
• .  Privacy Considerations
• .  Security Considerations
• .  IANA Considerations
  • .  RDAP Extensions Registry
  • .  Link Relations Registry
  • .  Media Types Registry
  • .  Structured Syntax Suffixes Registry
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction and detail the IP geolocation feed (commonly known as 'geofeed') file format and associated access mechanisms. While describes how a registry can make geofeed URLs available by way of a Routing Policy Specification Language (RPSL) service, the Regional Internet Registries (RIRs) have deployed Registration Data Access Protocol (RDAP) (, , , ) services as successors to RPSL for Internet number resource registrations, and maintaining feature parity between the two services supports client transition from RPSL to RDAP in this context. To that end, 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, 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 and 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 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 required features of this specification. "..." in examples is used as shorthand for elements defined outside of this document.

Specification

Media Type for a Geofeed Link requires a geofeed file to be a UTF-8 comma-separated values (CSV) file, with a series of "#" comments at the end for the optional Resource Public Key Infrastructure (RPKI) signature. At first glance, the "text/csv" media type seems like a good candidate for a geofeed file, since it supports the "#" comments needed for including the RPKI signature. However, although the CSV geofeed data could be viewed directly by a user such that the "text/csv" media type was appropriate, the most common use case will involve it being processed by some sort of application first, in order to facilitate subsequent IP address lookup operations. Therefore, using a new "application" media type with a "geofeed" subtype () 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 (see ), and a new "+csv" suffix in the IANA "Structured Syntax Suffixes" registry (see ).

Geofeed Link An RDAP server that hosts geofeed URLs for its IP network objects () may include link objects for those geofeed URLs in IP network objects in its responses. These link objects are added to the "links" member of each object (). In RDAP, the "value", "rel", and "href" JSON members are required for any link object. Additionally, for a geofeed link object, the "type" JSON member is RECOMMENDED. The geofeed-specific components of a link object are 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 ) by this document.

"href":

The target URL is set to the HTTPS URL of the geofeed file () for an IP network.

"type":

"application/geofeed+csv" (see ).

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 be returned is when the server is able to represent that data in multiple languages. In such a case, the server SHOULD provide "hreflang" members for the geofeed link objects. Except for the multiple-languages scenario, the server SHOULD NOT return more than one geofeed link object.

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 . A server that uses this extension identifier MUST include it 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 of this inclusion: { "rdapConformance": [ "rdap_level_0", "geofeed1", ... ], ... } If the server includes "geofeed1" in the "rdapConformance" array, then for any response concerning a particular IP network object for which the server possesses a geofeed URL and is able to return it to the client (i.e., the server is not 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 make use of 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, because RDAP servers are free to use any registered media type or link relation in a standard response without implementing any particular extension. The additional 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. This is useful where a client receives an IP network object without a geofeed link object, because in that case the client can infer that no geofeed data 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 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. 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 extension will use different extension identifiers.

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

Operational Considerations When an RDAP client performs an IP network lookup, per , the RDAP server is required to return the most-specific IP network object that covers the IP address range provided by the client. That IP network object may not 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 retrieve the parent object for the initial response (and so on, recursively) in the event that the initial response does not contain geofeed data. Conversely, server operators should consider interface options for resource holders in order to support 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 their resources. The resource holder then updates each of their network object registrations to refer to that single geofeed file. As with geofeed references in inetnum: objects (per ), clients who find a geofeed link object within an IP network object and opt to retrieve the data from the associated link MUST ignore any entry where the entry's IP address range is outside the IP network object's address range. recommends that consumers of geofeed data verify that the publisher of the data is authoritative for the relevant resources. The RDAP bootstrap process helps clients with this recommendation, since a client following that process will be directed to the RDAP server that is able to make authoritative statements about the disposition of the relevant resources. To prevent undue load on RDAP and geofeed servers, clients fetching geofeed data using these mechanisms MUST NOT do frequent real-time lookups. See for further details.

Privacy Considerations All the privacy considerations from apply to this document. In particular, the service provider publishing the geofeed file MUST 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 . Given that, registry operators should ascertain whether the regulatory environment in which they operate permits implementation of the functionality defined in this document.

Security Considerations Sections and of document several security considerations that are equally relevant in the RDAP context. A geofeed file MUST be referenced with an HTTPS URL, per . The geofeed file may also contain an RPKI signature, per . Besides that, this document does not introduce any new security considerations past those already discussed in the RDAP protocol specifications (, ).

IANA Considerations

RDAP Extensions Registry IANA has registered the following value in the "RDAP Extensions" registry at :

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.

Link Relations Registry IANA has registered the following value in the "Link Relations" registry at :

Relation Name:

geofeed

Description:

Refers to a resource with IP geofeed location information related to the link context.

Reference:

RFC 9877

Media Types Registry IANA has registered the following media type in the "Media Types" registry at :

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 ().

Encoding considerations:

See .

Security considerations:

See 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 .

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

Structured Syntax Suffixes Registry IANA has registered the following value in the "Structured Syntax Suffixes" registry at :

Name:

Comma-Separated Values (CSV)

+suffix:

+csv

References:

,

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

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482. This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. This document obsoletes RFC 7484. This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to geofeed comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the geofeed data files. This document obsoletes RFC 9092. Informative References IANA IANA IANA IETF RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK] This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv". This memo provides information for the Internet community. This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. This memo defines URI fragment identifiers for text/csv MIME entities. These fragment identifiers make it possible to refer to parts of a text/csv MIME entity identified by row, column, or cell. Fragment identification can use single items or ranges. This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP. This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location. Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds. This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated. The Registration Data Access Protocol (RDAP) provides Representational State Transfer (RESTful) web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such, it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server operator present management challenges for both clients and servers, whereas a federated authentication system would make it easier to operate and use RDAP without the need to maintain server-specific client credentials. This document describes a federated authentication system for RDAP based on OpenID Connect. IANA

Acknowledgements provided initial support and encouragement for this work, along with the authors of . suggested using a web link instead of a simple URL string to specify a geofeed file URL. , , , , , , , , , , , , , and provided valuable feedback for this document.

Authors' Addresses ARIN

jasdips@arin.net

APNIC

tomh@apnic.net