rfc9977.original   rfc9977.txt 
Network Working Group O. Gasser Internet Engineering Task Force (IETF) O. Gasser
Internet-Draft IPinfo Request for Comments: 9977 IPinfo
Intended status: Standards Track R. Bush Category: Standards Track R. Bush
Expires: 20 June 2026 IIJ Research & Arrcus ISSN: 2070-1721 IIJ Research & Arrcus
M. Candela M. Candela
NTT NTT
R. Housley R. Housley
Vigil Security Vigil Security
17 December 2025 May 2026
Publishing End-Site Prefix Lengths Publishing End-Site Prefix Lengths
draft-ietf-opsawg-prefix-lengths-14
Abstract Abstract
This document specifies how to augment the Routing Policy This document specifies how to augment the Routing Policy
Specification Language (RPSL) inetnum: class to refer specifically to Specification Language (RPSL) inetnum: class to refer specifically to
prefixlen files which are comma-separated values (CSV) files used to prefixlen files, which are Comma-Separated Values (CSV) files used to
specify end-site prefix lengths. This document also describes an specify end-site prefix lengths. This document also describes an
optional mechanism that uses the Resource Public Key Infrastructure optional mechanism that uses the Resource Public Key Infrastructure
(RPKI) to authenticate the prefixlen files. (RPKI) to authenticate the prefixlen files.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 20 June 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9977.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Please review these documents carefully, as they describe your rights carefully, as they describe your rights and restrictions with respect
and restrictions with respect to this document. Code Components to this document. Code Components extracted from this document must
extracted from this document must include Revised BSD License text as include Revised BSD License text as described in Section 4.e of the
described in Section 4.e of the Trust Legal Provisions and are Trust Legal Provisions and are provided without warranty as described
provided without warranty as described in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language
3. prefixlen Files . . . . . . . . . . . . . . . . . . . . . . . 3 3. prefixlen Files
3.1. End-site prefix length without CGN or proxies . . . . . . 4 3.1. End-Site Prefix Length Without CGN or Proxies
3.2. End-site prefix length with CGN or proxies . . . . . . . 4 3.2. End-Site Prefix Length with CGN or Proxies
3.3. Longest prefix matching . . . . . . . . . . . . . . . . . 5 3.3. Longest Prefix Matching
3.4. Not specifying any end-site prefix length . . . . . . . . 5 3.4. Not Specifying Any End-Site Prefix Length
3.5. Processing prefixlen files . . . . . . . . . . . . . . . 6 3.5. Processing prefixlen Files
4. inetnum: Class . . . . . . . . . . . . . . . . . . . . . . . 6 4. inetnum: Class
5. Fetching prefixlen Data . . . . . . . . . . . . . . . . . . . 8 5. Fetching prefixlen Data
6. Authenticating prefixlen Data (Optional) . . . . . . . . . . 9 6. Authenticating prefixlen Data (Optional)
7. Operational Considerations . . . . . . . . . . . . . . . . . 12 7. Operational Considerations
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 8. Implementation Status
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 11. References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.2. Informative References
12.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. ASN.1 Module
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Example
Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 21 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses
1. Introduction 1. Introduction
Internet service providers (ISPs) delegate IP addresses or entire IP Internet Service Providers (ISPs) delegate IP addresses or entire IP
prefixes to their users. Similarly, cloud providers assign customers prefixes to their users. Similarly, cloud providers assign customers
who use their services such as virtual machines a prefix of a who use their services, such as virtual machines (VMs), a prefix of a
specific size. Therefore, there are a multitude of variations of specific size. Therefore, there are many variations of end-site
different end-site prefix length present in the Internet. Currently, prefix lengths present in the Internet. Currently, there is no easy
there is no easy way for content providers to know the end-site way for content providers to know the end-site prefix size of someone
prefix size of someone accessing their service. Knowing the correct accessing their service. Knowing the correct end-site's prefix size
end-site's prefix size has multiple implications such as: has multiple implications such as:
* Blocklisting/throttling: In IPv4, IP addresses can be blocked Blocklisting/throttling: In IPv4, IP addresses can be blocked using
using variable prefix lengths for different prefixes, such as /22 variable prefix lengths for different prefixes, such as /22 for
for prefix A, /27 for prefix B, or /32 to block a single IPv4 prefix A, /27 for prefix B, or /32 to block a single IPv4 address.
address. Due to the large address space in IPv6, blocking at, Due to the large address space in IPv6, blocking at, e.g., the /48
e.g., the /48 or /56 level could lead to overblocking (throwing or /56 level could lead to overblocking (throwing multiple VMs
multiple VMs from different users into the same bucket), while from different users into the same bucket), while blocking at more
blocking at more fine-granular levels, e.g., /64, /96, or even fine-granular levels, e.g., /64, /96, or even /128, to block a
/128 to block a single IPv6 address would lead to filling up space single IPv6 address would lead to filling up space in the
in the blocklist pretty quickly. The use of temporary addresses blocklist pretty quickly. The use of temporary addresses in IPv6
in IPv6 [RFC8981] might lead to unwanted unblocking when addresses [RFC8981] might lead to unwanted unblocking when addresses are
are blocked at a too fine-granular level (e.g., /128). All these blocked at a too-fine-granular level (e.g., /128). All these
issues apply to throttling as well. issues apply to throttling as well.
* Rate limiting/CAPTCHAs: A similar issue arises on the Web, where Rate limiting/CAPTCHAs: A similar issue arises on the Web, where
neighboring prefixes might be thrown together (e.g., in the same neighboring prefixes might be thrown together (e.g., in the same
/48 or /56, even though the ISP hands out /64s), which leads to /48 or /56 even though the ISP hands out /64s), which leads to
people "jointly" running into rate limits and then either being people "jointly" running into rate limits and then either being
blocked from a service or having to solve annoying CAPTCHAs. blocked from a service or having to solve annoying CAPTCHAs.
* Geolocation: Getting the right prefix size for geolocation is Geolocation: Getting the right prefix size for geolocation is
similarly hard, especially for IPv6. If you aggregate too much, similarly difficult, especially for IPv6. If you aggregate too
you throw together different clients in different locations, and much, you throw together different clients in different locations;
if you aggregate too little, you fill up the geolocation database if you aggregate too little, you fill up the geolocation database
with unnecessary entries. with unnecessary entries.
This document specifies how to augment the Routing Policy This document specifies how to augment the Routing Policy
Specification Language (RPSL) [RFC2725] inetnum: class to refer Specification Language (RPSL) [RFC2725] inetnum: class to refer
specifically to prefixlen files and how to use them. In all places specifically to prefixlen files and how to use the files. In all
inetnum: is used, inet6num: must also be assumed [RFC4012]. places where inetnum: is used, inet6num: must also be assumed
[RFC4012].
The reader may find [INETNUM] and [INET6NUM] informative, and The reader may find [INETNUM] and [INET6NUM] informative, and
certainly more verbose, descriptions of the inetnum: database certainly more verbose descriptions of the inetnum: database classes
classes. exist in those documents.
An optional means for authenticating prefixlen data is also defined An optional means for authenticating prefixlen data is also defined
in Section 6. in Section 6.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. prefixlen Files 3. prefixlen Files
prefixlen files are CSV (Comma Separated Values) files [RFC4180] in prefixlen files are CSV files [RFC4180] in text format with UTF-8
text format with UTF-8 encoding [RFC3629], excluding problematic code encoding [RFC3629], excluding problematic code points as described in
points as described in [RFC9839]. Lines MUST be delimited by a line [RFC9839]. Lines MUST be delimited by a line break (CRLF), and blank
break (CRLF), and blank lines MUST be ignored. Text from a '#' lines MUST be ignored. Text from a '#' character to the end of the
character to the end of the current line MUST be treated as a comment current line MUST be treated as a comment only and is similarly
only and is similarly ignored. The first field of each non-ignored ignored. The first field of each line that is not ignored specifies
line specifies the prefix in question, the second field the end-site the prefix in question, the second the end-site prefix length within
prefix length within that prefix as an integer, and the third field that prefix as an integer, and the third the number of end-sites
the number of end-sites within an end-site prefix length for networks within an end-site prefix length for networks using Carrier-Grade NAT
using Carrier-Grade NAT (CGN) [RFC6598] or proxies. In all places (CGN) [RFC6598] or proxies. In all places Carrier-Grade NAT or CGN
Carrier-Grade NAT or CGN is used in this document, this applies to is used in this document, this applies to proxies as well. Note that
proxies as well. Note that all three fields MUST be present. This all three fields MUST be present. This means there MUST be exactly
means there MUST be exactly two commas in each non-commented line two commas in each non-commented line delimiting the three fields.
delimiting the three fields. The first field MUST NOT be empty on The first field MUST NOT be empty on lines that are not comments,
lines which are not comments, while the second and third field can be while the second and third field can be empty in certain scenarios.
empty in certain scenarios. If both the second and third fields are If both the second and third fields are empty, the publisher does not
empty, this means that the publisher does not want to disclose any want to disclose any prefix length information.
prefix length information.
3.1. End-site prefix length without CGN or proxies 3.1. End-Site Prefix Length Without CGN or Proxies
If an ISP delegates /56 IPv6 prefixes of the 2001:db8::/32 range, and If an ISP delegates /56 IPv6 prefixes of the 2001:db8::/32 range and
/32 IPv4 prefixes (i.e., a single IPv4 address) of the 192.0.2.0/24 /32 IPv4 prefixes (i.e., a single IPv4 address) of the 192.0.2.0/24
range to its customers without the use of Carrier-Grade NAT (CGN) range to its customers without the use of CGN [RFC6598] or proxy
[RFC6598] or proxy techniques, it would create a prefix length file techniques, it would create a prefix length file containing the
containing the following example entries: following example entries:
2001:db8::/32,56,1 2001:db8::/32,56,1
192.0.2.0/24,32,1 192.0.2.0/24,32,1
Note the third field being set to '1', which signals the absence of Note the third field being set to '1', which signals the absence of
CGN or proxies. This has the same meaning as the third field being CGN or proxies. This has the same meaning as the third field being
left empty in this scenario. left empty in this scenario.
3.2. End-site prefix length with CGN or proxies 3.2. End-Site Prefix Length with CGN or Proxies
prefixlen files can also be used to signal the presence of Carrier- prefixlen files can also be used to signal the presence of CGN
Grade NAT (CGN) [RFC6598] or proxies in networks. This is especially [RFC6598] or proxies in networks. This is especially useful for
useful for cases where multiple end-sites behind a CGN or proxy cases where multiple end-sites behind a CGN or proxy service
service accessing a service at the same time might run into rate accessing a service at the same time might run into rate-limiting
limiting issues by service providers. In case a prefixlen file issues by service providers. If a prefixlen file signals the
signals the presence of a CGN, service providers can treat these presence of a CGN, service providers can treat these prefixes in a
prefixes in a way that rate limits are adjusted. To signal the way that rate limits are adjusted. To signal the presence of a CGN,
presence of a CGN, the number of CGN end-sites are specified in the the number of CGN end-sites is specified in the third field. For
third field. For example, a CGN prefix 192.0.2.0/24 containing 4000 example, a CGN prefix 192.0.2.0/24 containing 4000 CGN end-sites
CGN end sites would be specified as follows: would be specified as follows:
192.0.2.0/24,24,4000 192.0.2.0/24,24,4000
Note the second field in the above example set to '24', signaling Note the second field in the above example is set to '24', signaling
that the 4000 CGN end-sites are present in the complete 192.0.2.0/24 that the 4000 CGN end-sites are present in the complete 192.0.2.0/24
prefix. prefix.
If on the other hand these 4000 CGN end-sites are distributed 1000 On the other hand, if these 4000 CGN end-sites are distributed 1000
each in the four /26 sub-prefixes within 192.0.2.0/24, this is each in the four /26 sub-prefixes within 192.0.2.0/24, this is
specified as follows: specified as follows:
192.0.2.0/24,26,1000 192.0.2.0/24,26,1000
It is important to note that the third field denoting the number of It is important to note that the third field denoting the number of
CGN end-sites is referring to the prefix length specified in the CGN end-sites is referring to the prefix length specified in the
second field. second field.
Note that this specification can be applied to IPv6 networks as well. Note that this specification can be applied to IPv6 networks as well.
3.3. Longest prefix matching 3.3. Longest Prefix Matching
Prefix length files can contain sub-prefixes entries of a parent Prefix length files can contain sub-prefixes entries of a parent
prefix, which needs to be taken into account when processing these prefix, which needs to be taken into account when processing these
files. For example, if a cloud provider assigns /120 IPv6 prefixes files. For example, if a cloud provider assigns /120 IPv6 prefixes
to each customer VM and a /64 prefix to premium customers, it would to each customer VM and a /64 prefix to premium customers, it would
create a prefix length file containing the following example entries: create a prefix length file containing the following example entries:
2001:db8::/32,120, 2001:db8::/32,120,
2001:db8:abcd::/48,64, 2001:db8:abcd::/48,64,
Note that the second entry in the above example is a subprefix of the Note that the second entry in the above example is a subprefix of the
first entry. Therefore, longest prefix matching has to be performed first entry. Therefore, longest prefix matching has to be performed
when parsing prefixlen files. when parsing prefixlen files.
3.4. Not specifying any end-site prefix length 3.4. Not Specifying Any End-Site Prefix Length
If an ISP delegates /32 IPv4 prefixes (i.e., a single IPv4 address) If an ISP delegates /32 IPv4 prefixes (i.e., a single IPv4 address)
of the 192.0.2.0/24 range to its customers without the use of of the 192.0.2.0/24 range to its customers without the use of CGN,
Carrier-Grade NAT (CGN), and it has a special sub-prefix 192.0.2.0/28 and it has a special sub-prefix 192.0.2.0/28 where this policy does
where this policy does not apply, it can signal so with the following not apply, it can signal so with the following prefix length file:
prefix length file:
192.0.2.0/24,32, 192.0.2.0/24,32,
192.0.2.0/28,, 192.0.2.0/28,,
If both the second and third fields are empty, this means that the If both the second and third fields are empty, the publisher does not
publisher does not want to disclose any prefix length information. want to disclose any prefix length information. Any prefix length
Any prefix length information from covering prefixes (192.0.2.0/24 in information from covering prefixes (192.0.2.0/24 in our example) MUST
our example) MUST be discarded for sub-prefixes specified in be discarded for sub-prefixes specified in prefixlen files
prefixlen files (192.0.2.0/28 in our example). (192.0.2.0/28 in our example).
3.5. Processing prefixlen files 3.5. Processing prefixlen Files
Multiple entries with exactly the same prefix MUST be considered an Multiple entries with exactly the same prefix MUST be considered an
error, and consumer implementations SHOULD log the repeated entries error, and consumer implementations SHOULD log the repeated entries
for further administrative review. Publishers MUST take measures to for further administrative review. Publishers MUST take measures to
ensure there is one and only one entry per prefix. ensure there is one and only one entry per prefix.
Upon encountering an erroneous entry in a prefixlen file, consumer Upon encountering an erroneous entry in a prefixlen file, consumer
implementations MUST skip that entry, log the error, and continue implementations MUST skip that entry, log the error, and continue
processing the remaining entries. processing the remaining entries.
Content providers and other parties who wish to differentiate Content providers and other parties who wish to differentiate
services based on end site prefixes need to find the relevant services based on end-site prefixes need to find the relevant
prefixlen data. In Section 4, this document specifies how to find prefixlen data. Section 4 specifies how to find the relevant
the relevant prefixlen file given an IP address. prefixlen file given an IP address.
prefixlen data for large providers administrating a large number of prefixlen data for large providers administrating a large number of
networks and end-sites can contain millions of entries. The size of networks and end-sites can contain millions of entries. The size of
a file can be even larger if an unsigned prefixlen file combines data a file can be even larger if an unsigned prefixlen file combines data
for many prefixes, if dual IPv4/IPv6 spaces are represented, etc. for many prefixes, if dual IPv4/IPv6 spaces are represented, etc.
This document also suggests an optional signature to strongly This document also suggests an optional signature to strongly
authenticate the data in the prefixlen files. The same approach to authenticate the data in the prefixlen files. The same approach to
signatures is used in this document that was used in [RFC9632]. signatures is used in this document that was used in [RFC9632].
4. inetnum: Class 4. inetnum: Class
The original RPSL specifications ([RIPE81], [RIPE181], and a trail of The original RPSL specifications ([RIPE81], [RIPE181], and a trail of
subsequent documents) were written by the RIPE community. The IETF subsequent documents) were written by the RIPE community. The IETF
standardized RPSL in [RFC2622] and [RFC4012]. Since then, it has standardized RPSL in [RFC2622] and [RFC4012]. Since then, it has
been modified and extensively enhanced in the Regional Internet been modified and extensively enhanced in the Regional Internet
Registry (RIR) community, mostly by RIPE [RIPE-DB]. At the time of Registry (RIR) community, mostly by RIPE [RIPE-DB]. At the time of
publishing this document, change control of RPSL effectively lies in publication, change control of RPSL effectively lies in the operator
the operator community. community.
The RPSL, and [RFC2725] and [RFC4012] used by the Regional Internet The RPSL, and [RFC2725] and [RFC4012] used by the RIRs, specify the
Registries (RIRs), specify the inetnum: database class. Each of inetnum: database class. Each of these objects describes an IP
these objects describes an IP address range and its attributes. The address range and its attributes. The inetnum: objects form a
inetnum: objects form a hierarchy ordered on the address space. hierarchy ordered on the address space.
Ideally, RPSL would be augmented to define a new RPSL prefixlen: Ideally, RPSL would be augmented to define a new RPSL prefixlen:
attribute in the inetnum: class. Absent implementation of the attribute in the inetnum: class. Absent implementation of the
prefixlen: attribute in a particular RIR database, this document prefixlen: attribute in a particular RIR database, this document
defines the syntax of a prefixlen remarks: attribute, which contains defines the syntax of a prefixlen remarks: attribute, which contains
an HTTPS URL of a prefixlen file. The format of the inetnum: an HTTPS URL of a prefixlen file. The format of the inetnum:
prefixlen remarks: attribute MUST be as in this example, "remarks: prefixlen remarks: attribute MUST be as in this example, "remarks:
Prefixlen ", where the token "Prefixlen" MUST be case-sensitive, Prefixlen ", where the token "Prefixlen" MUST be case-sensitive,
followed by a URL that will vary, but it MUST refer only to a single followed by a URL that will vary but that MUST refer only to a single
prefixlen file. prefixlen file.
inetnum: 192.0.2.0/24 # example inetnum: 192.0.2.0/24 # example
remarks: Prefixlen https://example.com/prefixlen remarks: Prefixlen https://example.com/prefixlen
While we leave global agreement of RPSL modification to the relevant While we leave global agreement of RPSL modification to the relevant
parties, we specify that a proper prefixlen: attribute in the parties, we specify that a proper prefixlen: attribute in the
inetnum: class MUST be "prefixlen:" and MUST be followed by a single inetnum: class MUST be "prefixlen:" and MUST be followed by a single
URL that will vary, but it MUST refer only to a single prefixlen URL that will vary, but it MUST refer only to a single prefixlen
file. file.
inetnum: 192.0.2.0/24 # example inetnum: 192.0.2.0/24 # example
prefixlen: https://example.com/prefixlen prefixlen: https://example.com/prefixlen
The URL uses HTTPS, so the WebPKI provides authentication, integrity, The URL uses HTTPS, so the Web Public Key Infrastructure (WebPKI)
and confidentiality for the fetched prefixlen file. However, the provides authentication, integrity, and confidentiality for the
WebPKI cannot provide authentication of IP address space assignment. fetched prefixlen file. However, the WebPKI cannot provide
In contrast, the RPKI (see [RFC6481]) can be used to authenticate IP authentication of IP address space assignment. In contrast, the RPKI
space assignment; see optional authentication in Section 6. (see [RFC6481]) can be used to authenticate IP space assignment; see
optional authentication in Section 6.
Until all producers of inetnum: objects, i.e., the RIRs, state that Until all producers of inetnum: objects, i.e., the RIRs, state that
they have migrated to supporting the prefixlen: attribute, consumers they have migrated to supporting the prefixlen: attribute, consumers
looking at inetnum: objects to find prefixlen URLs MUST be able to looking at inetnum: objects to find prefixlen URLs MUST be able to
consume the remarks: and prefixlen: forms. consume the remarks: and prefixlen: forms.
The migration not only implies that the RIRs support the prefixlen: The migration not only implies that the RIRs support the prefixlen:
attribute, but that all registrants have migrated any inetnum: attribute, but that all registrants have migrated any inetnum:
objects from remarks: to prefixlen:. objects from remarks: to prefixlen:.
skipping to change at page 8, line 28 skipping to change at line 340
than one registry. than one registry.
When fetching, the most specific inetnum: object with a prefixlen When fetching, the most specific inetnum: object with a prefixlen
reference MUST be used. reference MUST be used.
It is significant that prefixlen data may have finer granularity than It is significant that prefixlen data may have finer granularity than
the inetnum: that refers to them. For example, an inetnum: object the inetnum: that refers to them. For example, an inetnum: object
for an address range P could refer to a prefixlen file in which P has for an address range P could refer to a prefixlen file in which P has
been subdivided into one or more longer prefixes. been subdivided into one or more longer prefixes.
Backward compatibility issues regarding the implementation of new Backward-compatibility issues regarding the implementation of new
RPSL attributes are covered by Section 10.2 of [RFC2622]. RPSL attributes are covered by Section 10.2 of [RFC2622].
5. Fetching prefixlen Data 5. Fetching prefixlen Data
This document provides a guideline for how interested parties should This document provides a guideline for how interested parties should
fetch and read prefixlen files. fetch and read prefixlen files.
To minimize the load on RIRs' WHOIS [RFC3912] services, the RIR's To minimize the load on RIRs' WHOIS [RFC3912] services, the RIR's
bulk download services SHOULD be used for large-scale access to bulk-download services SHOULD be used for large-scale access to
gather inetnum: instances with prefixlen references. This uses gather inetnum: instances with prefixlen references. This uses
efficient bulk access instead of fetching via brute-force search efficient bulk access instead of fetching via brute-force search
through the IP space. When using bulk download services they MUST be through the IP space. When using bulk-download services, they MUST
accessed using HTTPS [RFC9110], FTP [RFC0959] MUST NOT be used. be accessed using HTTPS [RFC9110]; FTP [RFC0959] MUST NOT be used.
On the other hand, RIRs are converging on RDAP support which includes On the other hand, RIRs are converging on RDAP support, which
geofeed data, see [RFC9877]. It is hoped that this will be extended, includes geofeed data; see [RFC9877]. It is hoped that this will be
or generalized, to support prefixlen data. extended, or generalized, to support prefixlen data.
When reading data from a prefixlen file, one MUST ignore data outside When reading data from a prefixlen file, one MUST ignore data outside
the referring inetnum: object's address range. This is to avoid the referring inetnum: object's address range. This is to avoid
importing data about ranges not under the control of the operator. importing data about ranges not under the control of the operator.
Note that signed files MUST only contain prefixes within the Note that signed files MUST only contain prefixes within the
referring inetnum:'s range as mandated in Section 6. referring inetnum:'s range as mandated in Section 6.
If prefixlen files are fetched, other prefix length information from If prefixlen files are fetched, other prefix length information from
the inetnum: MUST be ignored. the inetnum: MUST be ignored.
skipping to change at page 9, line 19 skipping to change at line 379
with a prefixlen reference MUST be used to fetch the prefixlen file. with a prefixlen reference MUST be used to fetch the prefixlen file.
For example, if the fetching party finds the following inetnum: For example, if the fetching party finds the following inetnum:
objects: objects:
inetnum: 192.0.2.0/24 # example inetnum: 192.0.2.0/24 # example
remarks: Prefixlen https://example.com/prefixlen_1 remarks: Prefixlen https://example.com/prefixlen_1
inetnum: 192.0.2.0/26 # example inetnum: 192.0.2.0/26 # example
remarks: Prefixlen https://example.com/prefixlen_2 remarks: Prefixlen https://example.com/prefixlen_2
An application looking for prefixlen data for 192.0.2.0/29, MUST An application looking for prefixlen data for 192.0.2.0/29 MUST
ignore data in prefixlen_1 because 192.0.2.0/29 is within the more ignore data in prefixlen_1 because 192.0.2.0/29 is within the more
specific 192.0.2.0/26 inetnum: covering that address range and that specific 192.0.2.0/26 inetnum: covering that address range and that
inetnum: does have a prefixlen reference. inetnum: does have a prefixlen reference.
6. Authenticating prefixlen Data (Optional) 6. Authenticating prefixlen Data (Optional)
The question arises whether a particular prefixlen data set is valid, The question arises whether a particular prefixlen data set is valid,
i.e., is authorized by the "owner" of the IP address space and is i.e., is authorized by the "owner" of the IP address space and is
authoritative in some sense. The inetnum: that points to the authoritative in some sense. The inetnum: that points to the
prefixlen file provides some assurance. Unfortunately, the RPSL in prefixlen file provides some assurance. Unfortunately, the RPSL in
some repositories is weakly authenticated at best. An approach where some repositories is weakly authenticated at best. An approach where
RPSL was signed per [RFC7909] would be good, except it would have to RPSL was signed per the guidance in [RFC7909] would be good, except
be deployed by all RPSL registries, and there is a fair number of it would have to be deployed by all RPSL registries, and there is a
them. fair number of them.
The remainder of this section specifies an optional authenticator for The remainder of this section specifies an optional authenticator for
the prefixlen data set that follows the Signed Object Template for the prefixlen data set that follows the Signed Object Template for
the Resource Public Key Infrastructure (RPKI) [RFC6488]. the Resource Public Key Infrastructure (RPKI) [RFC6488].
A single optional authenticator MAY be appended to a prefixlen file. A single optional authenticator MAY be appended to a prefixlen file.
It is a digest of the main body of the file signed by the private key It is a digest of the main body of the file signed by the private key
of the relevant RPKI certificate for a covering address range. The of the relevant RPKI certificate for a covering address range. The
following format bundles the relevant RPKI certificate with a following format bundles the relevant RPKI certificate with a
signature over the prefixlen text. signature over the prefixlen text.
The canonicalization procedure converts the data from their internal The canonicalization procedure converts the data from their internal
character representation to the UTF-8 [RFC3629] character encoding, character representation to the UTF-8 character encoding (see
and the <CRLF> sequence MUST be used to denote the end of each line [RFC3629]), and the <CRLF> sequence MUST be used to denote the end of
of text. A blank line is represented solely by the <CRLF> sequence. each line of text. A blank line is represented solely by the <CRLF>
For robustness, any non-printable characters MUST NOT be changed by sequence. For robustness, any non-printable characters MUST NOT be
canonicalization. Trailing blank lines MUST NOT appear at the end of changed by canonicalization. Trailing blank lines MUST NOT appear at
the file. That is, the file must not end with multiple consecutive the end of the file. That is, the file must not end with multiple
<CRLF> sequences. Any end-of-file marker used by an operating system consecutive <CRLF> sequences. Any end-of-file marker used by an
is not considered to be part of the file content. When present, such operating system is not considered to be part of the file content.
end-of-file markers MUST NOT be covered by the digital signature. When present, such end-of-file markers MUST NOT be covered by the
digital signature.
If the authenticator is not in the canonical form described above, If the authenticator is not in the canonical form described above,
then, the authenticator is invalid, which means that it is treated in then the authenticator is invalid, which means that it is treated in
the same manner as an unauthenticated prefixlen data. the same manner as an unauthenticated prefixlen data.
Borrowing detached signatures from [RFC5485], after file Borrowing detached signatures from [RFC5485], after file
canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652] is canonicalization, the CMS (see [RFC5652]) is used to create a
used to create a detached DER-encoded signature that is then Base64 detached DER-encoded signature that is then Base64-encoded with
encoded with padding (as defined in Section 4 of [RFC4648]) and line padding (as defined in Section 4 of [RFC4648]) and line wrapped to 72
wrapped to 72 or fewer characters. The same digest algorithm MUST be or fewer characters. The same digest algorithm MUST be used for
used for calculating the message digest of the content being signed, calculating the message digest of the content being signed, which is
which is the prefixlen file, and for calculating the message digest the prefixlen file, and for calculating the message digest on the
on the SignerInfo SignedAttributes [RFC8933]. The message digest SignerInfo SignedAttributes (see [RFC8933]). The message digest
algorithm identifier MUST appear in both the CMS SignedData algorithm identifier MUST appear in both the CMS SignedData
DigestAlgorithmIdentifiers and the SignerInfo DigestAlgorithmIdentifiers and the SignerInfo
DigestAlgorithmIdentifier [RFC5652]. The RPKI certificate covering DigestAlgorithmIdentifier [RFC5652]. The RPKI certificate covering
the prefixlen inetnum: object's address range is included in the CMS the prefixlen inetnum: object's address range is included in the CMS
SignedData certificates field [RFC5652]. SignedData certificates field [RFC5652].
The address range of the signing certificate MUST cover all prefixes The address range of the signing certificate MUST cover all prefixes
in the signed prefixlen file. If not, the authenticator is invalid. in the signed prefixlen file. If not, the authenticator is invalid.
The signing certificate MUST NOT include the Autonomous System The signing certificate MUST NOT include the Autonomous System
Identifier Delegation certificate extension [RFC3779]. If it is Identifier Delegation certificate extension [RFC3779]. If it is
present, the authenticator is invalid. present, the authenticator is invalid.
As with many other RPKI signed objects, the IP Address Delegation As with many other RPKI signed objects, the IP Address Delegation
certificate extension MUST NOT use the "inherit" capability defined certificate extension MUST NOT use the "inherit" capability defined
in Section 2.2.3.5 of [RFC3779]. If "inherit" is used, the in Section 2.2.3.5 of [RFC3779]. If "inherit" is used, the
authenticator is invalid. authenticator is invalid.
An IP Address Delegation extension using "inherit" would complicate An IP Address Delegation certificate extension using "inherit" would
processing. The implementation would have to build the certification complicate processing. The implementation would have to build the
path from the end-entity to the trust anchor, then validate the path certification path from the end-entity to the trust anchor and then
from the trust anchor to the end-entity, and then the parameter would validate the path from the trust anchor to the end-entity. Then, the
have to be remembered when the validated public key was used to parameter would have to be remembered when the validated public key
validate a signature on a CMS object. Having to remember things from was used to validate a signature on a CMS object. Having to remember
certification path validation for use with CMS object processing things from certification-path validation for use with CMS object
would be quite complex and error-prone. And, the certificates do not processing would be quite complex and error-prone. And, the
get that much bigger by repeating the information. certificates do not get that much bigger by repeating the
information.
An address range A "covers" address range B if the range of B is An address range A "covers" address range B if the range of B is
identical to or a subset of A. "Address range" is used here because identical to or a subset of A. "Address range" is used here because
inetnum: objects and RPKI certificates need not align on Classless inetnum: objects and RPKI certificates need not align on Classless
Inter-Domain Routing (CIDR) [RFC4632] prefix boundaries, while those Inter-Domain Routing (CIDR) [RFC4632] prefix boundaries, while those
of the lines in a prefixlen file do align. of the lines in a prefixlen file do align.
The Certification Authority (CA) MUST generate a new End Entity (EE) The Certification Authority (CA) MUST generate a new End Entity (EE)
certificate for each signing of a particular prefixlen file. The certificate for each signing of a particular prefixlen file. The
private key associated with the EE certificate SHOULD sign only one private key associated with the EE certificate SHOULD sign only one
skipping to change at page 11, line 42 skipping to change at line 485
party performing signature validation. Validation of the CMS party performing signature validation. Validation of the CMS
signature over the prefixlen file involves: signature over the prefixlen file involves:
1. Obtaining the signer's certificate from the CMS SignedData 1. Obtaining the signer's certificate from the CMS SignedData
CertificateSet [RFC5652]. The certificate SubjectKeyIdentifier CertificateSet [RFC5652]. The certificate SubjectKeyIdentifier
extension [RFC5280] MUST match the SubjectKeyIdentifier in the extension [RFC5280] MUST match the SubjectKeyIdentifier in the
CMS SignerInfo SignerIdentifier [RFC5652]. If the key CMS SignerInfo SignerIdentifier [RFC5652]. If the key
identifiers do not match, then validation MUST fail. identifiers do not match, then validation MUST fail.
2. Validating the signer's certificate MUST ensure that it is part 2. Validating the signer's certificate MUST ensure that it is part
of the current [RFC9286] manifest and that all resources are of the current manifest per [RFC9286] and that all resources are
covered by the RPKI certificate. covered by the RPKI certificate.
3. Construct and validate the certification path for the signer's 3. Constructing and validating the certification path for the
certificate. All of the needed certificates are expected to be signer's certificate. All of the needed certificates are
readily available in the RPKI repository. The certification path expected to be readily available in the RPKI repository. The
MUST be valid according to the validation algorithm in [RFC5280] certification path MUST be valid according to the validation
and the additional checks specified in [RFC3779] associated with algorithm in [RFC5280] and the additional checks specified in
the IP Address Delegation certificate extension. If [RFC3779] associated with the IP Address Delegation certificate
certification path validation is unsuccessful, then validation extension. If certification path validation is unsuccessful,
MUST fail. then validation MUST fail.
4. Validating the CMS SignedData as specified in [RFC5652] using the 4. Validating the CMS SignedData as specified in [RFC5652] using the
public key from the validated signer's certificate. If the public key from the validated signer's certificate. If the
signature validation is unsuccessful, then validation MUST fail. signature validation is unsuccessful, then validation MUST fail.
5. Confirming that the eContentType object identifier (OID) is id- 5. Confirming that the eContentType Object IDentifier (OID) is id-
ct-prefixlenCSVwithCRLF (1.2.840.113549.1.9.16.1.TBD). This OID ct-prefixlenCSVwithCRLF (1.2.840.113549.1.9.16.1.57). This OID
MUST appear within both the eContentType in the encapContentInfo MUST appear within both the eContentType in the encapContentInfo
object and the ContentType signed attribute in the signerInfo object and the ContentType signed attribute in the signerInfo
object (see [RFC6488]). object (see [RFC6488]).
6. Verifying that the IP Address Delegation certificate extension 6. Verifying that the IP Address Delegation certificate extension
[RFC3779] covers all of the address ranges of the prefixlen file. [RFC3779] covers all of the address ranges of the prefixlen file.
If all of the address ranges are not covered, then validation If all of the address ranges are not covered, then validation
MUST fail. MUST fail.
All of the above steps MUST be successful to consider the prefixlen All of the above steps MUST be successful to consider the prefixlen
file signature as valid. file signature to be valid.
The authenticator MUST be hidden as a series of "#" comments at the The authenticator MUST be hidden as a series of "#" comments at the
end of the prefixlen file. The following simple example is end of the prefixlen file. The following simple example is
cryptographically incorrect: cryptographically incorrect:
# RPKI Signature: 192.0.2.0 - 192.0.2.255 # RPKI Signature: 192.0.2.0 - 192.0.2.255
# MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ # MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
# IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu # IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
... ...
# imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa # imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
skipping to change at page 13, line 30 skipping to change at line 571
replaced with another certificate, then the signature in the replaced with another certificate, then the signature in the
prefixlen file MUST be updated so that it can be properly validated prefixlen file MUST be updated so that it can be properly validated
with the new certificate. with the new certificate.
It is good key hygiene to use a given key for only one purpose. To It is good key hygiene to use a given key for only one purpose. To
dedicate a signing private key for signing a prefixlen file, an RPKI dedicate a signing private key for signing a prefixlen file, an RPKI
Certification Authority (CA) may issue a subordinate certificate Certification Authority (CA) may issue a subordinate certificate
exclusively for the purpose shown in Appendix B. exclusively for the purpose shown in Appendix B.
Harvesting and publishing aggregated prefixlen data outside of the Harvesting and publishing aggregated prefixlen data outside of the
RPSL model SHOULD be avoided as it can have the effect that more RPSL model SHOULD be avoided: it can have the effect that more
specifics from one aggregatee could undesirably affect the less specifics from one aggregatee could undesirably affect the less
specifics of a different aggregatee. Moreover, publishing aggregated specifics of a different aggregatee. Moreover, publishing aggregated
prefixlen data prevents the reader of the data to perform the checks prefixlen data prevents the reader of the data to perform the checks
described in Section 5 and Section 6. described in Sections 5 and 6.
An anonymized version of bulk WHOIS data is openly available for all An anonymized version of bulk WHOIS data is openly available for all
RIRs except ARIN, which requires an authorization. However, for RIRs except ARIN, which requires an authorization. However, for
users without such authorization, the same result can be achieved users without such authorization, the same result can be achieved
with extra RDAP effort. There is open-source code to pass over such with extra RDAP effort. There is open-source code to pass over such
data across all RIRs, collect all prefixlen references, and process data across all RIRs, collect all prefixlen references, and process
them [PREFIXLEN-FINDER]. them [PREFIXLEN-FINDER].
To prevent undue load on RPSL and prefixlen servers, entity-fetching To prevent undue load on RPSL and prefixlen servers, entity-fetching
prefixlen data using these mechanisms MUST NOT do frequent real-time prefixlen data using these mechanisms MUST NOT do frequent real-time
lookups. prefixlen servers SHOULD send an HTTP Expires header lookups. prefixlen servers SHOULD send an HTTP Expires header
[RFC9111] to signal when prefixlen data should be refetched. If an [RFC9111] to signal when prefixlen data should be refetched. If an
HTTP Expires or Cache-Control header is present, it MUST be honored HTTP Expires or Cache-Control header is present, it MUST be honored
by clients. As the data change very infrequently, in the absence of by clients. As the data change very infrequently, in the absence of
such an HTTP header signal, collectors SHOULD NOT fetch more such an HTTP header signal, collectors SHOULD NOT fetch more
frequently than weekly. It would be polite not to fetch at magic frequently than weekly. It would be polite not to fetch at magic
times such as midnight UTC, the first of the month, etc., because too times such as midnight UTC, the first of the month, etc., because too
many others are likely to do the same. many others are likely to do the same.
8. Implementation Status 8. Implementation Status
In November 2025, the prefixlen: attribute in inetnum objects has As of November 2025, the prefixlen: attribute in inetnum objects has
been implemented by the RIPE NCC database. been implemented by the RIPE NCC database.
Registrants in databases which do not yet support the prefixlen: Registrants in databases that do not yet support the prefixlen:
attribute are using the remarks:, or equivalent, attribute. attribute are using the remarks:, or equivalent, attribute.
At the time of publishing this document, the registry data published At the time of publication, the registry data published by ARIN are
by ARIN are not the same RPSL as that of the other registries (see not the same RPSL as that of the other registries (see [RFC7485] for
[RFC7485] for a survey of the WHOIS Tower of Babel); therefore, when a survey of the WHOIS Tower of Babel); therefore, when fetching via
fetching via bulk WHOIS over HTTPS [RFC9110], WHOIS [RFC3912], the bulk WHOIS over HTTPS [RFC9110], WHOIS [RFC3912], the Registration
Registration Data Access Protocol (RDAP) [RFC9083], etc., the Data Access Protocol (RDAP) [RFC9083], etc., the "NetRange" or "ip
"NetRange" or "ip network" attribute/key must be treated as network" attribute/key must be treated as "inetnum" and the "Comment"
"inetnum", and the "Comment" attribute must be treated as "remarks". attribute must be treated as "remarks".
9. Security Considerations 9. Security Considerations
The consumer of prefixlen data SHOULD fetch and process the data The consumer of prefixlen data SHOULD fetch and process the data
themselves. Importing datasets produced and/or processed by a third themselves. Importing datasets produced and/or processed by a third
party places significant trust in the third party. party places significant trust in the third party.
As mentioned in Section 6, some RPSL repositories have weak, if any, As mentioned in Section 6, some RPSL repositories have weak, if any,
authentication. This allows spoofing of inetnum: objects pointing to authentication. This allows spoofing of inetnum: objects pointing to
malicious prefixlen files. Section 6 suggests an unfortunately malicious prefixlen files. Section 6 suggests an unfortunately
complex method for stronger authentication based on the RPKI. complex method for stronger authentication based on the RPKI.
For example, if an inetnum: for a wide address range (e.g., a /16) For example, if an inetnum: for a wide address range (e.g., a /16)
points to an RPKI-signed prefixlen file, a customer or attacker could points to an RPKI-signed prefixlen file, a customer or attacker could
publish an unsigned equal or narrower (e.g., a /24) inetnum: in a publish an unsigned equal or narrower (e.g., a /24) inetnum: in a
WHOIS registry that has weak authorization, abusing the rule that the WHOIS registry that has weak authorization, abusing the rule that the
most-specific inetnum: object with a prefixlen reference MUST be most-specific inetnum: object with a prefixlen reference MUST be
used. used.
If signatures were mandatory, the above attack would be stymied, but If signatures were mandatory, the above attack would be stymied, but,
of course that is not happening anytime soon. of course, that is not happening anytime soon.
The RPSL providers have had to throttle fetching from their servers The RPSL providers have had to throttle fetching from their servers
due to too-frequent queries. Usually, they throttle by the querying due to too-frequent queries. Usually, they throttle by the querying
IP address or block. Similar defenses will likely need to be IP address or block. Similar defenses will likely need to be
deployed by prefixlen file servers. deployed by prefixlen file servers.
As prefixlen files disclose which parts of a prefix belong to an end As prefixlen files disclose which parts of a prefix belong to an end-
site, attackers could better focus DDoS traffic towards a website site, attackers could better focus DDoS traffic towards a website
hosted by a cloud provider by overwhelming only IP addresses from hosted by a cloud provider by overwhelming only IP addresses from
that specific end site. Furthermore, information collected from that specific end-site. Furthermore, information collected from
prefixlen files could allow for more targeted IPv6 scanning/ prefixlen files could allow for more targeted IPv6 scanning/
reconnaissance, where scanners (be it benevolent or malicious ones) reconnaissance, where scanners (be it benevolent or malicious ones)
can target specific sub-prefixes which they deem more interesting. can target specific sub-prefixes that they deem more interesting.
It is possible for publishers of prefixlen data to specify incorrect It is possible for publishers of prefixlen data to specify incorrect
prefixlen data about their prefixes. This could either be done by prefixlen data about their prefixes. This could be done either by
mistake or on purpose. One example could be a malicious network mistake or on purpose. One example could be a malicious network
operator trying to overflow the storage of databases that consume operator trying to overflow the storage of databases that consume
prefixlen data by setting a very specific prefix size (e.g., /128 for prefixlen data by setting a very specific prefix size (e.g., /128 for
large blocks of IPv6 address space). In another example a network large blocks of IPv6 address space). In another example, a network
operator might annotate their prefixes as using CGN to go around operator might annotate their prefixes as using CGN to go around
legitimate blocking or throttling. A third example would be a legitimate blocking or throttling. A third example would be a
malicious provider publishing fake small allocations, so on receipt malicious provider publishing fake small allocations, so on receipt
of complaints, they could plausibly respond by saying that they of complaints, they could plausibly respond by saying that they
stopped the actions of a bad customer and move their malicious stopped the actions of a bad customer and move their malicious
activities to a different prefix. As a fourth example, network activities to a different prefix. As a fourth example, network
operators could overwhelm consumers by publishing prefixlen files operators could overwhelm consumers by publishing prefixlen files
containing millions or even billions of entries (e.g., enumerating containing millions or even billions of entries (e.g., enumerating
all possible /96 subprefixes of a /32 IPv6 prefix). Therefore, care all possible /96 subprefixes of a /32 IPv6 prefix). Therefore, care
should be taken when processing prefixlen data, as with any external should be taken when processing prefixlen data, as with any external
third-party data. third-party data.
10. IANA Considerations 10. IANA Considerations
IANA is asked to register an object identifier for one ASN.1 Module IANA has registered an object identifier for one ASN.1 Module in the
in the "SMI Security for S/MIME Module Identifier "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)"
(1.2.840.113549.1.9.16.0)" registry as follows: registry as follows:
Description OID Reference
-----------------------------------------------------------------
id-mod-prefixlen-2025 1.2.840.113549.1.9.16.0.TBD0 [RFC-TBD]
The SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0) registry is located at:
https://www.iana.org/assignments/smi-numbers/smi-
numbers.xhtml#security-smime-0. On publication of this document, the
[RFC-TBD] reference needs to be changed to the RFC number assigned to
this document.
IANA is asked to register an object identifiers for one content type +=======================+============================+===========+
in the "SMI Security for S/MIME CMS Content Type | Description | OID | Reference |
(1.2.840.113549.1.9.16.1)" registry as follows: +=======================+============================+===========+
| id-mod-prefixlen-2025 | 1.2.840.113549.1.9.16.0.87 | RFC 9977 |
+-----------------------+----------------------------+-----------+
Description OID Reference Table 1
------------------------------------------------------------------
id-ct-prefixlenCSVwithCRLF 1.2.840.113549.1.9.16.1.TBD1 [RFC-TBD]
The SMI Security for S/MIME Content Type Identifier IANA has registered an object identifier for one content type in the
(1.2.840.113549.1.9.16.1) registry is located at: "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)"
https://www.iana.org/assignments/smi-numbers/smi- registry as follows:
numbers.xhtml#security-smime-1. On publication of this document, the
[RFC-TBD] reference needs to be changed to the RFC number assigned to
this document.
11. Acknowledgments +==========================+============================+=========+
|Description | OID |Reference|
+==========================+============================+=========+
|id-ct-prefixlenCSVwithCRLF| 1.2.840.113549.1.9.16.1.57 |RFC 9977 |
+--------------------------+----------------------------+---------+
Thanks to the authors of [RFC8805] and [RFC9632] and the folk they Table 2
acknowledge from whom ideas and text have been liberally
expropriated. Thanks to John R. Levine for providing useful
feedback on the draft.
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622, "Routing Policy Specification Language (RPSL)", RFC 2622,
DOI 10.17487/RFC2622, June 1999, DOI 10.17487/RFC2622, June 1999,
skipping to change at page 18, line 33 skipping to change at line 786
[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski, [RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure "Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022, (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
<https://www.rfc-editor.org/info/rfc9286>. <https://www.rfc-editor.org/info/rfc9286>.
[RFC9839] Bray, T. and P. Hoffman, "Unicode Character Repertoire [RFC9839] Bray, T. and P. Hoffman, "Unicode Character Repertoire
Subsets", RFC 9839, DOI 10.17487/RFC9839, August 2025, Subsets", RFC 9839, DOI 10.17487/RFC9839, August 2025,
<https://www.rfc-editor.org/info/rfc9839>. <https://www.rfc-editor.org/info/rfc9839>.
[X680] ITU-T, "Information technology -- Abstract Syntax Notation [X680] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>. <https://www.itu.int/rec/T-REC-X.680>.
12.2. Informative References 11.2. Informative References
[INET6NUM] RIPE NCC, "Description of the INET6NUM Object", October [INET6NUM] RIPE NCC, "Description of the INET6NUM Object", October
2019, <https://www.ripe.net/manage-ips-and- 2019, <https://www.ripe.net/manage-ips-and-
asns/db/support/documentation/ripe-database-documentation/ asns/db/support/documentation/ripe-database-documentation/
rpsl-object-types/4-2-descriptions-of-primary- rpsl-object-types/4-2-descriptions-of-primary-
objects/4-2-3-description-of-the-inet6num-object>. objects/4-2-3-description-of-the-inet6num-object>.
[INETNUM] RIPE NCC, "Description of the INETNUM Object", June 2020, [INETNUM] RIPE NCC, "Description of the INETNUM Object", June 2020,
<https://www.ripe.net/manage-ips-and- <https://www.ripe.net/manage-ips-and-
asns/db/support/documentation/ripe-database-documentation/ asns/db/support/documentation/ripe-database-documentation/
skipping to change at page 20, line 30 skipping to change at line 878
[RFC9877] Singh, J. and T. Harrison, "Registration Data Access [RFC9877] Singh, J. and T. Harrison, "Registration Data Access
Protocol (RDAP) Extension for Geofeed Data", RFC 9877, Protocol (RDAP) Extension for Geofeed Data", RFC 9877,
DOI 10.17487/RFC9877, October 2025, DOI 10.17487/RFC9877, October 2025,
<https://www.rfc-editor.org/info/rfc9877>. <https://www.rfc-editor.org/info/rfc9877>.
[RIPE-DB] RIPE NCC, "RIPE Database Documentation", [RIPE-DB] RIPE NCC, "RIPE Database Documentation",
<https://www.ripe.net/manage-ips-and- <https://www.ripe.net/manage-ips-and-
asns/db/support/documentation/ripe-database- asns/db/support/documentation/ripe-database-
documentation>. documentation>.
[RIPE181] RIPE NCC, "Representation Of IP Routing Policies In A [RIPE181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J.,
Routing Registry", October 1994, Karrenberg, D., Terpstra, M., and J. Yu, "Representation
Of IP Routing Policies In A Routing Registry", RIPE-181,
October 1994,
<https://www.ripe.net/publications/docs/ripe-181>. <https://www.ripe.net/publications/docs/ripe-181>.
[RIPE81] RIPE NCC, "Representation Of IP Routing Policies In The [RIPE81] Bates, T., Jouanigot, J., Karrenberg, D., Lothberg, P.,
RIPE Database", February 1993, and M. Terpstra, "Representation Of IP Routing Policies In
The RIPE Database", RIPE-081, February 1993,
<https://www.ripe.net/publications/docs/ripe-081>. <https://www.ripe.net/publications/docs/ripe-081>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
This appendix provides an ASN.1 Module [X680] for the CMS content This appendix provides an ASN.1 Module [X680] for the CMS content
type used for the prefixlen file. type used for the prefixlen file.
CONTENT-TYPE is imported from the ASN.1 Module in [RFC6268]. CONTENT-TYPE is imported from the ASN.1 Module in [RFC6268].
<CODE BEGINS> <CODE BEGINS>
PrefixLengthsModule-2025 PrefixLengthsModule-2025
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) mod(0) TBD0 } pkcs(1) pkcs9(9) smime(16) mod(0) 87 }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS ALL -- -- EXPORTS ALL --
IMPORTS IMPORTS
CONTENT-TYPE CONTENT-TYPE
FROM CryptographicMessageSyntax-2010 -- in [RFC6268] FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ; pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;
ContentSet CONTENT-TYPE ::= { ct-prefixlenCSVwithCRLF, ... } ContentSet CONTENT-TYPE ::= { ct-prefixlenCSVwithCRLF, ... }
ct-prefixlenCSVwithCRLF CONTENT-TYPE ::= ct-prefixlenCSVwithCRLF CONTENT-TYPE ::=
{ TYPE UTF8String IDENTIFIED BY id-ct-prefixlenCSVwithCRLF } { TYPE UTF8String IDENTIFIED BY id-ct-prefixlenCSVwithCRLF }
id-ct-prefixlenCSVwithCRLF OBJECT IDENTIFIER ::= id-ct-prefixlenCSVwithCRLF OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) ct(1) TBD1 } pkcs-9(9) smime(16) ct(1) 57 }
END END
<CODE ENDS> <CODE ENDS>
Appendix B. Example Appendix B. Example
This appendix provides an example, including a trust anchor, a CRL This appendix provides an example, including a trust anchor, a CRL
signed by the trust anchor, a CA certificate subordinate to the trust signed by the trust anchor, a CA certificate subordinate to the trust
anchor, a CRL signed by the CA, an end-entity certificate subordinate anchor, a CRL signed by the CA, an end-entity certificate subordinate
to the CA for signing the prefixlen file, and a detached signature. to the CA for signing the prefixlen file, and a detached signature.
The trust anchor is represented by a self-signed certificate. As The trust anchor is represented by a self-signed certificate. As
usual in the RPKI, the trust anchor has authority over all IPv4 usual in the RPKI, the trust anchor has authority over all IPv4
skipping to change at page 30, line 42 skipping to change at line 1315
# iG9w0BCQMxDQYLKoZIhvcNAQkQAS8wHAYJKoZIhvcNAQkFMQ8XDTI1MTIwNDEzN # iG9w0BCQMxDQYLKoZIhvcNAQkQAS8wHAYJKoZIhvcNAQkFMQ8XDTI1MTIwNDEzN
# DgxMVowLwYJKoZIhvcNAQkEMSIEIGMBdMKw5mjZYL9qP4ivwgMt8g2+qEO0+Dcn # DgxMVowLwYJKoZIhvcNAQkEMSIEIGMBdMKw5mjZYL9qP4ivwgMt8g2+qEO0+Dcn
# N5vQO1bNMA0GCSqGSIb3DQEBAQUABIIBABRER8F8BATarhuti2Zkqv6sxEgV6Kb # N5vQO1bNMA0GCSqGSIb3DQEBAQUABIIBABRER8F8BATarhuti2Zkqv6sxEgV6Kb
# Xjd5NCHiumoD57flhRf68BmdR5agZDq7whq68MpRXxPwwRHWGSCKUXoIOo5O4VX # Xjd5NCHiumoD57flhRf68BmdR5agZDq7whq68MpRXxPwwRHWGSCKUXoIOo5O4VX
# 1xKwAlu8t8Wpx+P+wGmIi1nDuFSPNSHtgw1cMGNSwCYfDzkn18pBB6qKCWyS0Ea # 1xKwAlu8t8Wpx+P+wGmIi1nDuFSPNSHtgw1cMGNSwCYfDzkn18pBB6qKCWyS0Ea
# tTIBp/oqvlUHHOyN4bFsvdbyahEQ5JGmF9yZaSZ8LV73B+X5VbpkjpQP+SL9Lpu # tTIBp/oqvlUHHOyN4bFsvdbyahEQ5JGmF9yZaSZ8LV73B+X5VbpkjpQP+SL9Lpu
# mh41Jg2BrPyvnWgJakE2S0G3U/b9dujknHM5JpuQP8fX4guziTVu+3LoF0sD6ux # mh41Jg2BrPyvnWgJakE2S0G3U/b9dujknHM5JpuQP8fX4guziTVu+3LoF0sD6ux
# rd3g39IKaRz/hukUI02tMLI0ZpNp4Kjc/ObD4tcwvg2bmOjHF953M5EWGYZE= # rd3g39IKaRz/hukUI02tMLI0ZpNp4Kjc/ObD4tcwvg2bmOjHF953M5EWGYZE=
# End Signature: 192.0.2.0 - 192.0.2.255 # End Signature: 192.0.2.0 - 192.0.2.255
Acknowledgments
Thanks to the authors of [RFC8805] and [RFC9632] and the folk they
acknowledge from whom ideas and text have been liberally
expropriated. Thanks to John R. Levine for providing useful feedback
on the document.
Authors' Addresses Authors' Addresses
Oliver Gasser Oliver Gasser
IPinfo IPinfo
Email: oliver@ipinfo.io Email: oliver@ipinfo.io
Randy Bush Randy Bush
IIJ Research & Arrcus IIJ Research & Arrcus
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
United States of America United States of America
Email: randy@psg.com Email: randy@psg.com
Massimo Candela Massimo Candela
NTT NTT
Siriusdreef 70-72 Siriusdreef 70-72
 End of changes. 81 change blocks. 
253 lines changed or deleted 249 lines changed or added

This html diff was produced by rfcdiff 1.48.