Generalized RPSL External Reference

The Routing Policy Specification Language (RPSL), which has operationally evolved since standardization in , has recently added a geofeed: attribute to the inetnum: and inet6num: classes to reference data external to RPSL. There is now a proposal add another attribute, prefixlen: referencing exterbal data. This document describes a more general and extensible mechanism for external references to augment the RPSL inetnum: class to refer to external data. In all places inetnum:, , is used, inet6num:, , should also be assumed.

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.

RPSL, , as used by the Regional Internet Registries (RIRs), has been augmented with the inetnum: and the inet6num: classes; each of which describes an IP address range and its attributes. Ongoing work has added and/or proposes to add multiple attributes to RPSL to reference objects external to RPSL. descrbes how to reference geofeed files () from an RPSL inetnum: class. It is widely deployed. proposes to refrence prefixlen files from an RPSL inetnum: class. This way lies chaos. Where there are two, there will be more. This will cause continuing problems for work such as .

This document describes a generalized mechanism for external references. RPSL would be augmented to define a new RPSL extref: attribute in the inetnum: class. For example, given the two sub-types described above:

inetnum: 192.0.2.0/24 # example extref: Geofeed https://example.com/geofeed extref: Prefixlen https://example.com/prefixlen Any particular inetnum: class MAY have at most one extref: of a particular sub-type. inetnum: classes form a hierarchy, see Section 4.2.4.1, Hierarchy of INETNUM Objects. extref references SHOULD be at the lowest applicable inetnum: class. When fetching, the most specific inetnum: class with an extref reference of a particular sub-type MUST be used. When extref: references are provided by multiple inetnum: classes which have identical address ranges, then the extref: reference on the inetnum: with the most recent last-modified: attribute SHOULD be preferred.

To create the needed inetnum: classes, an operator wishing to register extref: attributes needs to coordinate with their RIR/NIR and/or any provider LIR which has assigned prefixes to them. RIRs/NIRs provide means for assignees to create and maintain inetnum: classes. They also provide means of [sub-]assigning IP address resources and allowing the assignee to create whois data, including inetnum: classes, and thereby using extref: attributes. For a particular sub-type, the RFC defining it SHOULD specify the transport over which the reference SHOULD or MUST be fetched. Multiple inetnum: classes MAY refer to the same external resource.

It would be generally prudent for a consumer of extref data to also use other sources to cross-validate the data. All of the Security Considerations of the RFC defining a sub-type apply here as well. Many RPSL repositories have weak if any authentication. This would allow spoofing of inetnum: classes pointing to malicious extref files. If an inetnum: for a wide prefix (e.g. a /16) points to an external file, a customer or attacker could publish an equal or narrower (e.g. a /24) inetnum: in a whois registry which has weak authorization. The RPSL providers have had to throttle fetching from their servers due to too-frequent queries. Usually they throttle by the querying IP address or block. Similar defenses will likely need to be deployed by extref file servers. Directing users and programs to external data has legal and technical risk exposure. Hence adding to the IANA SubTypee registry requires an RFC. One should still be cautious following links to or using external data.

The IANA is requested to create an "rpsl-extref-subtype: registry as follows:

SubType Reference ------- ---------------- Geofeed RFC9632 Registration of new SubTypes is by RFC per Section 4.

Thanks to the authors of , , and and the folk they acknowledge from whom ideas and text have been liberally expropriated.