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 [DBOBJECTS] informative, with certainly more
certainly more verbose, descriptions of the inetnum: database verbose descriptions, on the inetnum: and inet6num database classes.
classes.
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, the specifications apply to proxies as
proxies as well. Note that all three fields MUST be present. This well. Note that all three fields MUST be present. This means there
means there MUST be exactly two commas in each non-commented line MUST be exactly two commas in each non-commented line delimiting the
delimiting the three fields. The first field MUST NOT be empty on three fields. The first field MUST NOT be empty on lines that are
lines which are not comments, while the second and third field can be not comments, while the second and third field can be empty in
empty in certain scenarios. If both the second and third fields are certain scenarios. If both the second and third fields are empty,
empty, this means that the publisher does not want to disclose any the publisher does not want to disclose any prefix length
prefix length information. 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-prefix entries of a parent
prefix, which needs to be taken into account when processing these prefix; this 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
2019, <https://www.ripe.net/manage-ips-and-
asns/db/support/documentation/ripe-database-documentation/
rpsl-object-types/4-2-descriptions-of-primary-
objects/4-2-3-description-of-the-inet6num-object>.
[INETNUM] RIPE NCC, "Description of the INETNUM Object", June 2020, [DBOBJECTS]
<https://www.ripe.net/manage-ips-and- RIPE NCC, "Descriptions of Primary Objects",
asns/db/support/documentation/ripe-database-documentation/ <https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-
rpsl-object-types/4-2-descriptions-of-primary- of-Primary-Objects>.
objects/4-2-4-description-of-the-inetnum-object>.
[PREFIXLEN-FINDER] [PREFIXLEN-FINDER]
"prefixlen-finder", June 2021, "prefixlen-finder", commit
5f446617796bc17d7e9495513537438ec26ab8e6, May 2026,
<https://github.com/massimocandela/prefixlen-finder>. <https://github.com/massimocandela/prefixlen-finder>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
<https://www.rfc-editor.org/info/rfc959>. <https://www.rfc-editor.org/info/rfc959>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004, DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>. <https://www.rfc-editor.org/info/rfc3912>.
skipping to change at page 20, line 30 skipping to change at line 872
[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
signed by the trust anchor, a CA certificate subordinate to the trust Certificate Revocation List (CRL) signed by the trust anchor, a CA
anchor, a CRL signed by the CA, an end-entity certificate subordinate certificate subordinate to the trust anchor, a CRL signed by the CA,
to the CA for signing the prefixlen file, and a detached signature. an end-entity certificate subordinate 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
address blocks, all IPv6 address blocks, and all Autonomous System address blocks, all IPv6 address blocks, and all Autonomous System
(AS) numbers. (AS) numbers.
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIEQTCCAymgAwIBAgIUEggycNoFVRjAuN/Fw7URu0DEZNAwDQYJKoZIhvcNAQEL MIIEQTCCAymgAwIBAgIUEggycNoFVRjAuN/Fw7URu0DEZNAwDQYJKoZIhvcNAQEL
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMzA5MTkyMDMzMzlaFw0zMzA5 BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMzA5MTkyMDMzMzlaFw0zMzA5
MTYyMDMzMzlaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB MTYyMDMzMzlaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB
skipping to change at page 22, line 35 skipping to change at line 961
JBclMHVd3tXse9If3nXYF4bxRIcir1lXlAbYN+Eo1U3i5qJO+fxouzt7Merk2Dih JBclMHVd3tXse9If3nXYF4bxRIcir1lXlAbYN+Eo1U3i5qJO+fxouzt7Merk2Dih
nsenTeXKzN7tfmuCYZZHCC8viCoJWdH+o1uRM4TiQApZsUJ8sF4TABrrRJmA/Ed5 nsenTeXKzN7tfmuCYZZHCC8viCoJWdH+o1uRM4TiQApZsUJ8sF4TABrrRJmA/Ed5
v0CTBbgqTx7yg0+VarFLPdnjYgtpoCJqwE2C1UpX15rZSaLVuGXtbwXd/cHEg5vF v0CTBbgqTx7yg0+VarFLPdnjYgtpoCJqwE2C1UpX15rZSaLVuGXtbwXd/cHEg5vF
W6QTsMeMQFEUa6hkicDGtxLTUdhckBgmCGoF2nlZii5f1BTWAg== W6QTsMeMQFEUa6hkicDGtxLTUdhckBgmCGoF2nlZii5f1BTWAg==
-----END CERTIFICATE----- -----END CERTIFICATE-----
The CRL issued by the trust anchor. The CRL issued by the trust anchor.
-----BEGIN X509 CRL----- -----BEGIN X509 CRL-----
MIIBjjB4AgEBMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEX MIIBjjB4AgEBMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEX
DTI1MTIwNDEzNDgxMVoXDTI2MDEwMzEzNDgxMVqgLzAtMB8GA1UdIwQYMBaAFMC9 DTI2MDUwNzIxMjI0OVoXDTI2MDYwNjIxMjI0OVqgLzAtMB8GA1UdIwQYMBaAFMC9
Ul2+0niyFuyzo0OV0gYLmQgyMAoGA1UdFAQDAgELMA0GCSqGSIb3DQEBCwUAA4IB Ul2+0niyFuyzo0OV0gYLmQgyMAoGA1UdFAQDAgEMMA0GCSqGSIb3DQEBCwUAA4IB
AQDLltErZwESHDSkwhnL++hFPAJUJf6NapOV9bzUBr5D6vLgs01dke3AFoUNJCng AQCkHXyCcQHejmVdHOL5Diafa3ys4HTb2eRqeNaMzwfY6T1D26hX6XuUyu0C7LV2
15p5EPi7BZnZMx3b+My+Hh8jMOxloKBe6eeZ0impCw5ZveWGwe4u3vH3snl9QkjZ OThlAL8JWiN2afgfs5juBAWdauwY5YSKAvQpXidFeCIXpSWLHmk545p7t9og6qpy
Slz+zxaNidKl/9W5h4rjznwKD98//t75ACa9UFImsE53U5cXwUor0QKd3VDkKLVf 840l+N+J2WnP9iGNCqgKG06CiRAoPtZZQCqqLZVcrELtDAOFNmZF0Bf+cE2SmsZO
nivSzVPaC3hvN85wOXMgC/M3MwD5PCKJ/jEBDfEADfnUIXUbjys13ycH2mX3gBZa 8N/ab/fw05Ptm/IBqN3j+ekaILELFRWUGPaAXMimWYn6sNmzYdihUn2fNff294PZ
svDot/HDgpcQVRZBJC4ecPy9aBfj8EEfmIwidQtS+4vyh7lrR9xKn8wUqvti3Ulx Mygxfw8dpWlA01QQt8d9V+3NklyOKEB3X+X12eA4KYaVDCt4USWMlnlETNO3XwDe
wYTdSdP9LWR+Ha7xdvSMJUiU Cg5BBjoh5EtXzsNWf2ipZTNb
-----END X509 CRL----- -----END X509 CRL-----
The CA certificate is issued by the trust anchor. This certificate The CA certificate is issued by the trust anchor. This certificate
grants authority over one IPv4 address block (192.0.2.0/24), one IPv6 grants authority over one IPv4 address block (192.0.2.0/24), one IPv6
address block(2001:db8::/32), and two AS numbers (64496 and 64497). address block(2001:db8::/32), and two AS numbers (64496 and 64497).
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIE+zCCA+OgAwIBAgIUcyCzS10hdfG65kbRq7toQAvRDMEwDQYJKoZIhvcNAQEL MIIE+zCCA+OgAwIBAgIUcyCzS10hdfG65kbRq7toQAvRDMIwDQYJKoZIhvcNAQEL
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yNTEyMDQxMzQ4MTFaFw0yNjEy BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yNjA1MDcyMTIyNDlaFw0yNzA1
MDQxMzQ4MTFaMDMxMTAvBgNVBAMTKDNBQ0UyQ0VGNEZCMjFCN0QxMUUzRTE4NEVG MDcyMTIyNDlaMDMxMTAvBgNVBAMTKDNBQ0UyQ0VGNEZCMjFCN0QxMUUzRTE4NEVG
QzFFMjk3QjM3Nzg2NDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc QzFFMjk3QjM3Nzg2NDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc
zz1qwTxC2ocw5rqp8ktm2XyYkl8riBVuqlXwfefTxsR2YFpgz9vkYUd5Az9EVEG7 zz1qwTxC2ocw5rqp8ktm2XyYkl8riBVuqlXwfefTxsR2YFpgz9vkYUd5Az9EVEG7
6wGIyZbtmhK63eEeaqbKz2GHub467498BXeVrYysO+YuIGgCEYKznNDZ4j5aaDbo 6wGIyZbtmhK63eEeaqbKz2GHub467498BXeVrYysO+YuIGgCEYKznNDZ4j5aaDbo
j5+4/z0Qvv6HEsxQd0f8br6lKJwgeRM6+fm7796HNPB0aqD7Zj9NRCLXjbB0DCgJ j5+4/z0Qvv6HEsxQd0f8br6lKJwgeRM6+fm7796HNPB0aqD7Zj9NRCLXjbB0DCgJ
liH6rXMKR86ofgll9V2mRjesvhdKYgkGbOif9rvxVpLJ/6zdru5CE9yeuJZ59l+n liH6rXMKR86ofgll9V2mRjesvhdKYgkGbOif9rvxVpLJ/6zdru5CE9yeuJZ59l+n
YH/r6PzdJ4Q7yKrJX8qD6A60j4+biaU4MQ72KpsjhQNTTqF/HRwi0N54GDaknEwE YH/r6PzdJ4Q7yKrJX8qD6A60j4+biaU4MQ72KpsjhQNTTqF/HRwi0N54GDaknEwE
TnJQHgLJDYqww9yKWtjjAgMBAAGjggIjMIICHzAdBgNVHQ4EFgQUOs4s70+yG30R TnJQHgLJDYqww9yKWtjjAgMBAAGjggIjMIICHzAdBgNVHQ4EFgQUOs4s70+yG30R
4+GE78Hil7N3hkIwHwYDVR0jBBgwFoAUwL1SXb7SeLIW7LOjQ5XSBguZCDIwDwYD 4+GE78Hil7N3hkIwHwYDVR0jBBgwFoAUwL1SXb7SeLIW7LOjQ5XSBguZCDIwDwYD
VR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwGAYDVR0gAQH/BA4wDDAKBggr VR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwGAYDVR0gAQH/BA4wDDAKBggr
BgEFBQcOAjBDBgNVHR8EPDA6MDigNqA0hjJyc3luYzovL3Jwa2kuZXhhbXBsZS5u BgEFBQcOAjBDBgNVHR8EPDA6MDigNqA0hjJyc3luYzovL3Jwa2kuZXhhbXBsZS5u
ZXQvcmVwb3NpdG9yeS9leGFtcGxlLXRhLmNybDBOBggrBgEFBQcBAQRCMEAwPgYI ZXQvcmVwb3NpdG9yeS9leGFtcGxlLXRhLmNybDBOBggrBgEFBQcBAQRCMEAwPgYI
KwYBBQUHMAKGMnJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4 KwYBBQUHMAKGMnJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4
YW1wbGUtdGEuY2VyMIG5BggrBgEFBQcBCwSBrDCBqTA+BggrBgEFBQcwCoYycnN5 YW1wbGUtdGEuY2VyMIG5BggrBgEFBQcBCwSBrDCBqTA+BggrBgEFBQcwCoYycnN5
bmM6Ly9ycGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvcnkvZXhhbXBsZS1jYS5tZnQw bmM6Ly9ycGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvcnkvZXhhbXBsZS1jYS5tZnQw
NQYIKwYBBQUHMA2GKWh0dHBzOi8vcnJkcC5leGFtcGxlLm5ldC9ub3RpZmljYXRp NQYIKwYBBQUHMA2GKWh0dHBzOi8vcnJkcC5leGFtcGxlLm5ldC9ub3RpZmljYXRp
b24ueG1sMDAGCCsGAQUFBzAFhiRyc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVw b24ueG1sMDAGCCsGAQUFBzAFhiRyc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVw
b3NpdG9yeS8wLgYIKwYBBQUHAQcBAf8EHzAdMAwEAgABMAYDBADAAAIwDQQCAAIw b3NpdG9yeS8wLgYIKwYBBQUHAQcBAf8EHzAdMAwEAgABMAYDBADAAAIwDQQCAAIw
BwMFACABDbgwIQYIKwYBBQUHAQgBAf8EEjAQoA4wDDAKAgMA+/ACAwD78TANBgkq BwMFACABDbgwIQYIKwYBBQUHAQgBAf8EEjAQoA4wDDAKAgMA+/ACAwD78TANBgkq
hkiG9w0BAQsFAAOCAQEAdgCV/G9f6NIC3MhqAqSoA56/7bJJ2QC3bChnwZH0MB3p hkiG9w0BAQsFAAOCAQEAipx10/ZrY11NYH+iVRtq32hAFGGaXysLWrjFVYd05+25
VjYNhcY99ZFBv9TdsAd0GsPMEL4zGqvxkSQZjrJHSqe6GHJB5Kr4/SDbbyu6vylh 2nPtZYPmtLRf7TWMSwF27AkGPzvonjsRF2a7wdMAPDIW2nKctmDS1nFGWw+6vXyN
QPDNIBnH2o5iXU/34Klx3Wf42ttsi7DAhGcR6OOAR4UrO/7ng19oFXe3tBWDcVLf Di+jhwHm7+FyFWh3u2ilzop+o6ecUiCF8rkE22TWHRkBJforN0eqUjJi0R/o4oaB
Jd6Bqptp8fkfpSyHQEezZ0xA5h/SXeN+qvbL0rOJcI4+Ybbqa7U21+cz/JftAdgw q9sZs+Jr3vTmelRYjvP8Eej3AWRm+rilbP8yW3OOvV3sTvgJc4DmbFNJ2LBJ+cLx
vatxQzGxl47HyvC7IpROI0+8jXB9xwOGKxznBve9/LeIZzMYBRuYV6jVWe4V6ja9 1fjl+Wf/YHPo2kHw8f1TJsgXSI6kYBUradIyXIW1HGrWdiKiY+oXp+jVbf8cMvp/
2crgaoDZaOH78JLjg3Qt+hVSQ667lak3QXZ1FVp1WA== KkLf1UqqCjgdu3GGQuukKjbNHeJPMuHmVw5Qa3iGzg==
-----END CERTIFICATE----- -----END CERTIFICATE-----
The CRL issued by the CA. The CRL issued by the CA.
-----BEGIN X509 CRL----- -----BEGIN X509 CRL-----
MIIBrTCBlgIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEygzQUNFMkNFRjRG MIIBrTCBlgIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEygzQUNFMkNFRjRG
QjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyFw0yNTEyMDQxMzQ4MTFaFw0y QjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyFw0yNjA1MDcyMTIyNDlaFw0y
NjAxMDMxMzQ4MTFaoC8wLTAfBgNVHSMEGDAWgBQ6zizvT7IbfRHj4YTvweKXs3eG NjA2MDYyMTIyNDlaoC8wLTAfBgNVHSMEGDAWgBQ6zizvT7IbfRHj4YTvweKXs3eG
QjAKBgNVHRQEAwIBATANBgkqhkiG9w0BAQsFAAOCAQEAyxbVA6TeFHU8BqciB0q1 QjAKBgNVHRQEAwIBATANBgkqhkiG9w0BAQsFAAOCAQEAFEEWr/QvDz2efRDS9mep
Of81r/Ux/PTKIyhpVznTcVxa4wodsQcaMVNKYxINHNwctCm901Rx3nO61BqZpvaL GSpNS2QPbeV7Oz+rO5sZAIxrpuBZObe0NRlZaMamM0X+lSgKnEai2Ep5Pm4NzG6M
XPdkstlnzG+WaHcfUj09sTx7Eb/r17J1EACr2p9dVq4fTpuw/+Nq7ecj80NM74z6 Z1dHSrp196l65o0CTiPK0r4IqEUfY1Q6tkzXzc/6c9kUxMerE1saY/OlN29yYJ4F
uCiA5iyEjI0PYen4/IOgods0ceUm0QBOCTKNI3cbjZjiAfY9tRgqR1F2eeeproEM IDHrczvK5y1ddK8g3FB7fNjti4RCFAec8RsyizemDwS4JLd1R3y1+olJ5OH6Gvqq
+ulVORW4yfivsMGMHApaeLVnUTnAln9YqnL7mQGMBrRIBwYi2dk76K++iQBhWEP0 uMTSAJHl4LL5DeAZm3WLzL49PJWcaKoNe0oAPDdEalW5GXlAMsbQw9W8mOvBKotP
Ofv22y7UIbfqycrYROuJ9yGdwi5IAhpbKoQIzS5DimN+xykJdGPm0d2jUwNRibPh 5Q9k8VVXaILSFn2+AzPKX7fQXoA954KMVnDAgN0r8Fa743J7TlbFbk+l5+V/+88f
GQ== cA==
-----END X509 CRL----- -----END X509 CRL-----
The end-entity certificate is issued by the CA. This certificate The end-entity certificate is issued by the CA. This certificate
grants signature authority for one IPv4 address block (192.0.2.0/24). grants signature authority for one IPv4 address block (192.0.2.0/24).
Signature authority for the IPv6 address block and the AS numbers is Signature authority for the IPv6 address block and the AS numbers is
not needed for the prefixlen file that will be signed, so these items not needed for the prefixlen file that will be signed, so these items
are not included in the end-entity certificate. are not included in the end-entity certificate.
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZvowDQYJKoZIhvcNAQEL MIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZvswDQYJKoZIhvcNAQEL
BQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdC BQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdC
Mzc3ODY0MjAeFw0yNTEyMDQxMzQ4MTFaFw0yNjA5MzAxMzQ4MTFaMDMxMTAvBgNV Mzc3ODY0MjAeFw0yNjA1MDcyMTIyNDlaFw0yNzAzMDMyMTIyNDlaMDMxMTAvBgNV
BAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM0NUFCRjA1M0ExODcwggEi BAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM0NUFCRjA1M0ExODcwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycTQrOb/qB2W3i3Ki8PhA/DEW MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycTQrOb/qB2W3i3Ki8PhA/DEW
yii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQgtPCVwr62hTQZCIowBN0BL0c yii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQgtPCVwr62hTQZCIowBN0BL0c
K0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZmr5xphXRvE+mzuJVLgu2V1upm K0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZmr5xphXRvE+mzuJVLgu2V1upm
BXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXhaFLe08y4DPfr/S/tXJOBm7QzQp BXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXhaFLe08y4DPfr/S/tXJOBm7QzQp
tmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKGzqTFCcc3EW9l5UFE1MFLlnoEog tmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKGzqTFCcc3EW9l5UFE1MFLlnoEog
qtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQft5w6g6cmxG+aYDdIEB34zrAgMB qtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQft5w6g6cmxG+aYDdIEB34zrAgMB
AAGjggFgMIIBXDAdBgNVHQ4EFgQUkUZSo71RwUQmAZiIn1xFq/BToYcwHwYDVR0j AAGjggFgMIIBXDAdBgNVHQ4EFgQUkUZSo71RwUQmAZiIn1xFq/BToYcwHwYDVR0j
BBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkIwDgYDVR0PAQH/BAQDAgeAMBgGA1Ud BBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkIwDgYDVR0PAQH/BAQDAgeAMBgGA1Ud
IAEB/wQOMAwwCgYIKwYBBQUHDgIwYQYDVR0fBFowWDBWoFSgUoZQcnN5bmM6Ly9y IAEB/wQOMAwwCgYIKwYBBQUHDgIwYQYDVR0fBFowWDBWoFSgUoZQcnN5bmM6Ly9y
cGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvcnkvM0FDRTJDRUY0RkIyMUI3RDExRTNF cGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvcnkvM0FDRTJDRUY0RkIyMUI3RDExRTNF
MTg0RUZDMUUyOTdCMzc3ODY0Mi5jcmwwbAYIKwYBBQUHAQEEYDBeMFwGCCsGAQUF MTg0RUZDMUUyOTdCMzc3ODY0Mi5jcmwwbAYIKwYBBQUHAQEEYDBeMFwGCCsGAQUF
BzAChlByc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNF BzAChlByc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNF
RjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcB RjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcB
BwEB/wQQMA4wDAQCAAEwBgMEAMAAAjANBgkqhkiG9w0BAQsFAAOCAQEAwvEWPwHe BwEB/wQQMA4wDAQCAAEwBgMEAMAAAjANBgkqhkiG9w0BAQsFAAOCAQEAUIykBaqY
VSFYwknmaOJrVeHrDez4BYg/uqpws0ny8LNUApsStUTrvsdkOMYVqJBifFpUtx7y nR/U+AXYzCqRbMqdygFY9R11fiNQubpkf5kEYHFxTut0CZLz9dToxuHRDLbPhjJv
1hfEZDkDIP7TC78pYaiTR5WAxSv/dxr9GuGUNgx7YDmvOST9OAZvfEBrNtj7DC+Z Ci3cDkb2ICy1Fdcit5oi9jFl1MD/sFa4l/FWGM07PhgKY+Isz3DXEw9furF7Al3I
jumMNWxMdTkjsLswXmlUF7dZxQjt01w5Wf5aD/MlV87d6mX49A0rjuaeIRTMglUq gbB0and5HQrvQbO6AnqixSYDffANsnZssojMzlHJIA9OLHIuhGZ66t+yh2VclhwV
EzqmnqSVTHVqtQwWlCG45ltS2Keu788RMnkiRDL2CJUoy8Axy5xcYSpf+keqFE13 7JdS+0EdyA0npIrTGyp//pD5vrigF04y+J4Y61jFXfmbWZbNJF/bMzFeBxD2PKaE
UUyegHcBUEODfk8AP0hnc6YhXC6+oBz72HbgYqTYyjQNYGS+49b58u5nXWqJoMJm uwixf65s3yI0JDjBbXjUtUhqyty0IZqV2HcuWU7MKH9Qc/wvrJDd4K4xTbkWWYgA
yxybgehJbawpCA== ql7bgmJTHpW2Gw==
-----END CERTIFICATE----- -----END CERTIFICATE-----
The end-entity certificate is displayed below in detail. For The end-entity certificate is displayed below in detail. For
brevity, the other two certificates are not. brevity, the other two certificates are not.
0 1110: SEQUENCE { 0 1110: SEQUENCE {
4 830: SEQUENCE { 4 830: SEQUENCE {
8 3: [0] { 8 3: [0] {
10 1: INTEGER 2 10 1: INTEGER 2
: } : }
13 20: INTEGER 13 20: INTEGER
: 27 AD 39 40 83 D7 F2 B5 B9 9B 86 70 C7 75 B2 B9 : 27 AD 39 40 83 D7 F2 B5 B9 9B 86 70 C7 75 B2 B9
: 6E E1 66 FA : 6E E1 66 FB
35 13: SEQUENCE { 35 13: SEQUENCE {
37 9: OBJECT IDENTIFIER 37 9: OBJECT IDENTIFIER
: sha256WithRSAEncryption (1 2 840 113549 1 1 11) : sha256WithRSAEncryption (1 2 840 113549 1 1 11)
48 0: NULL 48 0: NULL
: } : }
50 51: SEQUENCE { 50 51: SEQUENCE {
52 49: SET { 52 49: SET {
54 47: SEQUENCE { 54 47: SEQUENCE {
56 3: OBJECT IDENTIFIER commonName (2 5 4 3) 56 3: OBJECT IDENTIFIER commonName (2 5 4 3)
61 40: PrintableString 61 40: PrintableString
: '3ACE2CEF4FB21B7D11E3E184EFC1E297B3778642' : '3ACE2CEF4FB21B7D11E3E184EFC1E297B3778642'
: } : }
: } : }
: } : }
103 30: SEQUENCE { 103 30: SEQUENCE {
105 13: UTCTime 04/12/2025 13:48:11 GMT 105 13: UTCTime 07/05/2026 21:22:49 GMT
120 13: UTCTime 30/09/2026 13:48:11 GMT 120 13: UTCTime 03/03/2027 21:22:49 GMT
: } : }
135 51: SEQUENCE { 135 51: SEQUENCE {
137 49: SET { 137 49: SET {
139 47: SEQUENCE { 139 47: SEQUENCE {
141 3: OBJECT IDENTIFIER commonName (2 5 4 3) 141 3: OBJECT IDENTIFIER commonName (2 5 4 3)
146 40: PrintableString 146 40: PrintableString
: '914652A3BD51C144260198889F5C45ABF053A187' : '914652A3BD51C144260198889F5C45ABF053A187'
: } : }
: } : }
: } : }
skipping to change at page 28, line 12 skipping to change at line 1220
: } : }
: } : }
: } : }
: } : }
838 13: SEQUENCE { 838 13: SEQUENCE {
840 9: OBJECT IDENTIFIER 840 9: OBJECT IDENTIFIER
: sha256WithRSAEncryption (1 2 840 113549 1 1 11) : sha256WithRSAEncryption (1 2 840 113549 1 1 11)
851 0: NULL 851 0: NULL
: } : }
853 257: BIT STRING 853 257: BIT STRING
: C2 F1 16 3F 01 DE 55 21 58 C2 49 E6 68 E2 6B 55 : 50 8C A4 05 AA 98 9D 1F D4 F8 05 D8 CC 2A 91 6C
: E1 EB 0D EC F8 05 88 3F BA AA 70 B3 49 F2 F0 B3 : CA 9D CA 01 58 F5 1D 75 7E 23 50 B9 BA 64 7F 99
: 54 02 9B 12 B5 44 EB BE C7 64 38 C6 15 A8 90 62 : 04 60 71 71 4E EB 74 09 92 F3 F5 D4 E8 C6 E1 D1
: 7C 5A 54 B7 1E F2 D6 17 C4 64 39 03 20 FE D3 0B : 0C B6 CF 86 32 6F 0A 2D DC 0E 46 F6 20 2C B5 15
: BF 29 61 A8 93 47 95 80 C5 2B FF 77 1A FD 1A E1 : D7 22 B7 9A 22 F6 31 65 D4 C0 FF B0 56 B8 97 F1
: 94 36 0C 7B 60 39 AF 39 24 FD 38 06 6F 7C 40 6B : 56 18 CD 3B 3E 18 0A 63 E2 2C CF 70 D7 13 0F 5F
: 36 D8 FB 0C 2F 99 8E E9 8C 35 6C 4C 75 39 23 B0 : BA B1 7B 02 5D C8 81 B0 74 6A 77 79 1D 0A EF 41
: BB 30 5E 69 54 17 B7 59 C5 08 ED D3 5C 39 59 FE : B3 BA 02 7A A2 C5 26 03 7D F0 0D B2 76 6C B2 88
: 5A 0F F3 25 57 CE DD EA 65 F8 F4 0D 2B 8E E6 9E : CC CE 51 C9 20 0F 4E 2C 72 2E 84 66 7A EA DF B2
: 21 14 CC 82 55 2A 13 3A A6 9E A4 95 4C 75 6A B5 : 87 65 5C 96 1C 15 EC 97 52 FB 41 1D C8 0D 27 A4
: 0C 16 94 21 B8 E6 5B 52 D8 A7 AE EF CF 11 32 79 : 8A D3 1B 2A 7F FE 90 F9 BE B8 A0 17 4E 32 F8 9E
: 22 44 32 F6 08 95 28 CB C0 31 CB 9C 5C 61 2A 5F : 18 EB 58 C5 5D F9 9B 59 96 CD 24 5F DB 33 31 5E
: FA 47 AA 14 4D 77 51 4C 9E 80 77 01 50 43 83 7E : 07 10 F6 3C A6 84 BB 08 B1 7F AE 6C DF 22 34 24
: 4F 00 3F 48 67 73 A6 21 5C 2E BE A0 1C FB D8 76 : 38 C1 6D 78 D4 B5 48 6A CA DC B4 21 9A 95 D8 77
: E0 62 A4 D8 CA 34 0D 60 64 BE E3 D6 F9 F2 EE 67 : 2E 59 4E CC 28 7F 50 73 FC 2F AC 90 DD E0 AE 31
: 5D 6A 89 A0 C2 66 CB 1C 9B 81 E8 49 6D AC 29 08 : 4D B9 16 59 88 00 AA 5E DB 82 62 53 1E 95 B6 1B
: } : }
To allow reproduction of the signature results, the end-entity To allow reproduction of the signature results, the end-entity
private key is provided. For brevity, the other two private keys are private key is provided. For brevity, the other two private keys are
not. not.
-----BEGIN RSA PRIVATE KEY----- -----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEAsnE0Kzm/6gdlt4tyovD4QPwxFsootk4BqPaYAsDvZbCESOmW MIIEpQIBAAKCAQEAsnE0Kzm/6gdlt4tyovD4QPwxFsootk4BqPaYAsDvZbCESOmW
/5Pmkollj/ZEnM5XEILTwlcK+toU0GQiKMATdAS9HCtP+ZNYpiXYuanTN57yrMDP /5Pmkollj/ZEnM5XEILTwlcK+toU0GQiKMATdAS9HCtP+ZNYpiXYuanTN57yrMDP
Ap6EddbwfKUBcK7mZq+caYV0bxPps7iVS4LtldbqZgV7lpaHsprnYellifhg48D1 Ap6EddbwfKUBcK7mZq+caYV0bxPps7iVS4LtldbqZgV7lpaHsprnYellifhg48D1
skipping to change at page 30, line 7 skipping to change at line 1275
PvDXVubRAoGAdqXeSWoLxuzZXzl8rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ PvDXVubRAoGAdqXeSWoLxuzZXzl8rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ
E3ng2j5XPTUWli+aNGFEJGRoNtcQvO60O/sFZUhu52sqq9mWVYZNh1TB5aP8X+pV E3ng2j5XPTUWli+aNGFEJGRoNtcQvO60O/sFZUhu52sqq9mWVYZNh1TB5aP8X+pV
iFcZOLUvQEcN6PA+YQK5FU11rAI1M0Gm5RDnVnUl0L2xfCYxb7FzV6Y= iFcZOLUvQEcN6PA+YQK5FU11rAI1M0Gm5RDnVnUl0L2xfCYxb7FzV6Y=
-----END RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----
Signing of "192.0.2.0/24,32,1" (terminated by CR and LF), yields the Signing of "192.0.2.0/24,32,1" (terminated by CR and LF), yields the
following detached CMS signature. following detached CMS signature.
# RPKI Signature: 192.0.2.0 - 192.0.2.255 # RPKI Signature: 192.0.2.0 - 192.0.2.255
# MIIGQAYJKoZIhvcNAQcCoIIGMTCCBi0CAQMxDTALBglghkgBZQMEAgEwDQYLKoZ # MIIGQAYJKoZIhvcNAQcCoIIGMTCCBi0CAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
# IhvcNAQkQAS+gggRaMIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZv # IhvcNAQkQATmgggRaMIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZv
# owDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR # swDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR
# TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yNTEyMDQxMzQ4MTFaFw0yNjA5MzAx # TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yNjA1MDcyMTIyNDlaFw0yNzAzMDMy
# MzQ4MTFaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM # MTIyNDlaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM
# 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT # 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT
# QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg # QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg
# tPCVwr62hTQZCIowBN0BL0cK0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZm # tPCVwr62hTQZCIowBN0BL0cK0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZm
# r5xphXRvE+mzuJVLgu2V1upmBXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXha # r5xphXRvE+mzuJVLgu2V1upmBXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXha
# FLe08y4DPfr/S/tXJOBm7QzQptmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKG # FLe08y4DPfr/S/tXJOBm7QzQptmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKG
# zqTFCcc3EW9l5UFE1MFLlnoEogqtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQ # zqTFCcc3EW9l5UFE1MFLlnoEogqtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQ
# ft5w6g6cmxG+aYDdIEB34zrAgMBAAGjggFgMIIBXDAdBgNVHQ4EFgQUkUZSo71R # ft5w6g6cmxG+aYDdIEB34zrAgMBAAGjggFgMIIBXDAdBgNVHQ4EFgQUkUZSo71R
# wUQmAZiIn1xFq/BToYcwHwYDVR0jBBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkI # wUQmAZiIn1xFq/BToYcwHwYDVR0jBBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkI
# wDgYDVR0PAQH/BAQDAgeAMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIwYQYDVR # wDgYDVR0PAQH/BAQDAgeAMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIwYQYDVR
# 0fBFowWDBWoFSgUoZQcnN5bmM6Ly9ycGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvc # 0fBFowWDBWoFSgUoZQcnN5bmM6Ly9ycGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvc
# nkvM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdCMzc3ODY0Mi5jcmww # nkvM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdCMzc3ODY0Mi5jcmww
# bAYIKwYBBQUHAQEEYDBeMFwGCCsGAQUFBzAChlByc3luYzovL3Jwa2kuZXhhbXB # bAYIKwYBBQUHAQEEYDBeMFwGCCsGAQUFBzAChlByc3luYzovL3Jwa2kuZXhhbXB
# sZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNFRjRGQjIxQjdEMTFFM0UxODRFRkMxRT # sZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNFRjRGQjIxQjdEMTFFM0UxODRFRkMxRT
# I5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcBBwEB/wQQMA4wDAQCAAEwBgMEAMAAA # I5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcBBwEB/wQQMA4wDAQCAAEwBgMEAMAAA
# jANBgkqhkiG9w0BAQsFAAOCAQEAwvEWPwHeVSFYwknmaOJrVeHrDez4BYg/uqpw # jANBgkqhkiG9w0BAQsFAAOCAQEAUIykBaqYnR/U+AXYzCqRbMqdygFY9R11fiNQ
# s0ny8LNUApsStUTrvsdkOMYVqJBifFpUtx7y1hfEZDkDIP7TC78pYaiTR5WAxSv # ubpkf5kEYHFxTut0CZLz9dToxuHRDLbPhjJvCi3cDkb2ICy1Fdcit5oi9jFl1MD
# /dxr9GuGUNgx7YDmvOST9OAZvfEBrNtj7DC+ZjumMNWxMdTkjsLswXmlUF7dZxQ # /sFa4l/FWGM07PhgKY+Isz3DXEw9furF7Al3IgbB0and5HQrvQbO6AnqixSYDff
# jt01w5Wf5aD/MlV87d6mX49A0rjuaeIRTMglUqEzqmnqSVTHVqtQwWlCG45ltS2 # ANsnZssojMzlHJIA9OLHIuhGZ66t+yh2VclhwV7JdS+0EdyA0npIrTGyp//pD5v
# Keu788RMnkiRDL2CJUoy8Axy5xcYSpf+keqFE13UUyegHcBUEODfk8AP0hnc6Yh # rigF04y+J4Y61jFXfmbWZbNJF/bMzFeBxD2PKaEuwixf65s3yI0JDjBbXjUtUhq
# XC6+oBz72HbgYqTYyjQNYGS+49b58u5nXWqJoMJmyxybgehJbawpCDGCAaowggG # yty0IZqV2HcuWU7MKH9Qc/wvrJDd4K4xTbkWWYgAql7bgmJTHpW2GzGCAaowggG
# mAgEDgBSRRlKjvVHBRCYBmIifXEWr8FOhhzALBglghkgBZQMEAgGgazAaBgkqhk # mAgEDgBSRRlKjvVHBRCYBmIifXEWr8FOhhzALBglghkgBZQMEAgGgazAaBgkqhk
# iG9w0BCQMxDQYLKoZIhvcNAQkQAS8wHAYJKoZIhvcNAQkFMQ8XDTI1MTIwNDEzN # iG9w0BCQMxDQYLKoZIhvcNAQkQATkwHAYJKoZIhvcNAQkFMQ8XDTI2MDUwNzIxM
# DgxMVowLwYJKoZIhvcNAQkEMSIEIGMBdMKw5mjZYL9qP4ivwgMt8g2+qEO0+Dcn # jI0OVowLwYJKoZIhvcNAQkEMSIEIGMBdMKw5mjZYL9qP4ivwgMt8g2+qEO0+Dcn
# N5vQO1bNMA0GCSqGSIb3DQEBAQUABIIBABRER8F8BATarhuti2Zkqv6sxEgV6Kb # N5vQO1bNMA0GCSqGSIb3DQEBAQUABIIBAKzRicWBpSyN5nw39eDNfVai2H1mO0n
# Xjd5NCHiumoD57flhRf68BmdR5agZDq7whq68MpRXxPwwRHWGSCKUXoIOo5O4VX # APgZUmVF/vgSCWtR0da1iZots4qwn0XwvvIgu5eZ7edhn9axLXhjTAOQajT4cOw
# 1xKwAlu8t8Wpx+P+wGmIi1nDuFSPNSHtgw1cMGNSwCYfDzkn18pBB6qKCWyS0Ea # 9+raD7+SYdBIAUgZpuFy3Olnu4HykCd8Ub44lPfZVG1lF1LeN248+rWgozpE7xz
# tTIBp/oqvlUHHOyN4bFsvdbyahEQ5JGmF9yZaSZ8LV73B+X5VbpkjpQP+SL9Lpu # Dv5G83OslbvVzGXaVShJM4fsDfpkpKoQ4LszlBeqguU2yTm3XWVjkxH7VJvTtIT
# mh41Jg2BrPyvnWgJakE2S0G3U/b9dujknHM5JpuQP8fX4guziTVu+3LoF0sD6ux # SzO3jAqwqnCjfu3mnxCoz7LKES4DPZERsFoJv1zyDdHIXjPnfZuTBjjCOubjaQx
# rd3g39IKaRz/hukUI02tMLI0ZpNp4Kjc/ObD4tcwvg2bmOjHF953M5EWGYZE= # rRwgZtQ8Ljz3gpz1VzL9mKAv0pUzcyxtQfakHwdYtxyO33z2InljtTFJCroI=
# 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. 98 change blocks. 
344 lines changed or deleted 335 lines changed or added

This html diff was produced by rfcdiff 1.48.