rfc9977xml2.original.xml   rfc9977.xml 
<?xml version="1.0"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.2119.xml">
<!ENTITY RFC2622 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.2622.xml">
<!ENTITY RFC2725 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.2725.xml">
<!ENTITY RFC3629 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.3629.xml">
<!ENTITY RFC3779 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.3779.xml">
<!ENTITY RFC4012 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.4012.xml">
<!ENTITY RFC4180 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.4180.xml">
<!ENTITY RFC4648 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.4648.xml">
<!ENTITY RFC5280 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.5280.xml">
<!ENTITY RFC5652 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.5652.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.8174.xml">
<!ENTITY RFC6481 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.6481.xml">
<!ENTITY RFC6487 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.6487.xml">
<!ENTITY RFC6488 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.6488.xml">
<!ENTITY RFC6598 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.6598.xml">
<!ENTITY RFC8805 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.8805.xml">
<!ENTITY RFC8933 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.8933.xml">
<!ENTITY RFC8981 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.8981.xml">
<!ENTITY RFC9110 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.9110.xml">
<!ENTITY RFC9286 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.9286.xml">
<!ENTITY RFC0959 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.0959.xml">
<!ENTITY RFC3912 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.3912.xml">
<!ENTITY RFC4632 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.4632.xml">
<!ENTITY RFC5485 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.5485.xml">
<!ENTITY RFC6268 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.6268.xml">
<!ENTITY RFC7485 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.7485.xml">
<!ENTITY RFC7909 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.7909.xml">
<!ENTITY RFC9083 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.9083.xml">
<!ENTITY RFC9111 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.9111.xml">
<!ENTITY RFC9632 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.9632.xml">
<!ENTITY RFC9839 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.9839.xml">
<!ENTITY RFC9877 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.9877.xml">
]>
<?rfc sortrefs="yes"?> <!DOCTYPE rfc [
<?rfc subcompact="no"?> <!ENTITY nbsp "&#160;">
<?rfc symrefs="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc toc="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc tocdepth="3"?> <!ENTITY wj "&#8288;">
<?rfc compact="yes"?> ]>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-opsawg-prefix-lengths-14" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
submissionType="IETF" consensus="true" ipr="trust200902" tf-opsawg-prefix-lengths-14" number="9977" updates="" obsoletes="" submissionTyp
version="2" > e="IETF" consensus="true" ipr="trust200902" version="3" sortRefs="true" symRefs=
"true" tocInclude="true" tocDepth="3" xml:lang="en">
<front> <front>
<title abbrev="Publishing End-Site Prefix Lengths">Publishing End-Site Prefi x Lengths</title> <title abbrev="Publishing End-Site Prefix Lengths">Publishing End-Site Prefi x Lengths</title>
<seriesInfo name="RFC" value="9977"/>
<author fullname="Oliver Gasser" initials="O." surname="Gasser"> <author fullname="Oliver Gasser" initials="O." surname="Gasser">
<organization>IPinfo</organization> <organization>IPinfo</organization>
<address> <address>
<email>oliver@ipinfo.io</email> <email>oliver@ipinfo.io</email>
</address> </address>
</author> </author>
<author fullname="Randy Bush" initials="R." surname="Bush"> <author fullname="Randy Bush" initials="R." surname="Bush">
<organization>IIJ Research &amp; Arrcus</organization> <organization>IIJ Research &amp; Arrcus</organization>
<address> <address>
<postal> <postal>
<street>5147 Crystal Springs</street> <street>5147 Crystal Springs</street>
<city>Bainbridge Island</city> <city>Bainbridge Island</city>
<region>Washington</region> <region>Washington</region>
<code>98110</code> <code>98110</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
skipping to change at line 73 skipping to change at line 34
<postal> <postal>
<street>5147 Crystal Springs</street> <street>5147 Crystal Springs</street>
<city>Bainbridge Island</city> <city>Bainbridge Island</city>
<region>Washington</region> <region>Washington</region>
<code>98110</code> <code>98110</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>randy@psg.com</email> <email>randy@psg.com</email>
</address> </address>
</author> </author>
<author fullname="Massimo Candela" initials="M." surname="Candela"> <author fullname="Massimo Candela" initials="M." surname="Candela">
<organization>NTT</organization> <organization>NTT</organization>
<address> <address>
<postal> <postal>
<street>Siriusdreef 70-72</street> <street>Siriusdreef 70-72</street>
<city>Hoofddorp</city> <city>Hoofddorp</city>
<code>2132 WT</code> <code>2132 WT</code>
<country>Netherlands</country> <country>Netherlands</country>
</postal> </postal>
<email>massimo@ntt.net</email> <email>massimo@ntt.net</email>
</address> </address>
</author> </author>
<author fullname="Russ Housley" initials="R." surname="Housley">
<author fullname="Russ Housley" initials="R" surname="Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<postal> <postal>
<street>516 Dranesville Road</street> <street>516 Dranesville Road</street>
<city>Herndon</city> <city>Herndon</city>
<region>VA</region> <region>VA</region>
<code>20170</code> <code>20170</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<date month="May" year="2026"/>
<date /> <keyword>prefix</keyword>
<keyword>allocation</keyword>
<keyword>prefix</keyword> <keyword>RPSL</keyword>
<keyword>allocation</keyword> <keyword>inetnum</keyword>
<keyword>RPSL</keyword> <abstract>
<keyword>inetnum</keyword> <t>
This document specifies how to augment the Routing Policy Specification Language
<abstract> (RPSL) inetnum: class to refer specifically to prefixlen files, which are Comma
<t> -Separated Values (CSV) files used to specify end-site prefix lengths. This docu
This document specifies how to augment the Routing Policy Specification Language ment also describes an optional mechanism that uses the Resource Public Key Infr
(RPSL) inetnum: class to refer specifically to prefixlen files which are comma- astructure (RPKI) to authenticate the prefixlen files.
separated values (CSV) files used to specify end-site prefix lengths. This docum </t>
ent also describes an optional mechanism that uses the Resource Public Key Infra </abstract>
structure (RPKI) to authenticate the prefixlen files.
</t>
</abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
Internet service providers (ISPs) delegate IP addresses or entire IP p Internet Service Providers (ISPs) delegate IP addresses or entire IP p
refixes to their users. refixes to their users.
Similarly, cloud providers assign customers who use their services suc Similarly, cloud providers assign customers who use their services, su
h as virtual machines a prefix of a specific size. ch as virtual machines (VMs), a prefix of a specific size.
Therefore, there are a multitude of variations of different end-site p
refix length present in the Internet.
Currently, there is no easy way for content providers to know the end-
site prefix size of someone accessing their service.
Knowing the correct end-site's prefix size has multiple implications s
uch as:
<ul spacing="normal"> <!--[rfced] Please review our updates to the following to ensure we've maintaine
<li> d your intended meaning:
Blocklisting/throttling: In IPv4, IP addresses can be blocked using
variable prefix lengths for different prefixes, such as /22 for prefix A, /27 fo
r prefix B, or /32 to block a single IPv4 address. Due to the large address spac
e in IPv6, blocking at, e.g., the /48 or /56 level could lead to overblocking (t
hrowing multiple VMs from different users into the same bucket), while blocking
at more fine-granular levels, e.g., /64, /96, or even /128 to block a single IPv
6 address would lead to filling up space in the blocklist pretty quickly. The us
e of temporary addresses in IPv6 <xref target="RFC8981" format="default"/> might
lead to unwanted unblocking when addresses are blocked at a too fine-granular l
evel (e.g., /128). All these issues apply to throttling as well.
</li>
<li> Original:
Rate limiting/CAPTCHAs: A similar issue arises on the Web, where nei Therefore, there are a multitude of variations of different end-site
ghboring prefixes might be thrown together (e.g., in the same /48 or /56, even t prefix length present in the Internet.
hough the ISP hands out /64s), which leads to people "jointly" running into rate
limits and then either being blocked from a service or having to solve annoying
CAPTCHAs.
</li>
<li> Current:
Geolocation: Getting the right prefix size for geolocation is similar Therefore, there are many variations of end-site prefix lengths present in the I
ly hard, especially for IPv6. If you aggregate too much, you throw together diff nternet.
erent clients in different locations, and if you aggregate too little, you fill -->
up the geolocation database with unnecessary entries. Therefore, there are many variations of end-site prefix lengths presen
</li> t in the Internet.
</ul> Currently, there is no easy way for content providers to know the end-
site prefix size of someone accessing their service.
Knowing the correct end-site's prefix size has multiple implications s
uch as:
</t> </t>
<dl spacing="normal">
<dt>Blocklisting/throttling:</dt><dd>In IPv4, IP addresses can be blocke
d using variable prefix lengths for different prefixes, such as /22 for prefix A
, /27 for prefix B, or /32 to block a single IPv4 address. Due to the large addr
ess space in IPv6, blocking at, e.g., the /48 or /56 level could lead to overblo
cking (throwing multiple VMs from different users into the same bucket), while b
locking at more fine-granular levels, e.g., /64, /96, or even /128, to block a s
ingle IPv6 address would lead to filling up space in the blocklist pretty quickl
y. The use of temporary addresses in IPv6 <xref target="RFC8981" format="default
"/> might lead to unwanted unblocking when addresses are blocked at a too-fine-g
ranular level (e.g., /128). All these issues apply to throttling as well.
</dd>
<dt>Rate limiting/CAPTCHAs:</dt><dd>A similar issue arises on the Web, w
here neighboring prefixes might be thrown together (e.g., in the same /48 or /56
even though the ISP hands out /64s), which leads to people "jointly" running in
to rate limits and then either being blocked from a service or having to solve a
nnoying CAPTCHAs.
</dd>
<dt>Geolocation:</dt><dd>Getting the right prefix size for geolocation i
s similarly difficult, especially for IPv6. If you aggregate too much, you throw
together different clients in different locations; if you aggregate too little,
you fill up the geolocation database with unnecessary entries.
</dd>
</dl>
<t> <t>
This document specifies how to augment the Routing Policy This document specifies how to augment the Routing Policy
Specification Language (RPSL) <xref target="RFC2725" Specification Language (RPSL) <xref target="RFC2725" format="default"/>
format="default"/> inetnum: class to refer specifically to inetnum: class to refer specifically to
prefixlen files and how to use them. In all places prefixlen files and how to use the files. In all places where
inetnum: is used, inet6num: must also be assumed <xref inetnum: is used, inet6num: must also be assumed <xref target="RFC4012"
target="RFC4012" format="default"/>. format="default"/>.
</t> </t>
<t> <t>
The reader may find <xref target="INETNUM" format="default"/> The reader may find <xref target="INETNUM" format="default"/>
and <xref target="INET6NUM" format="default"/> informative, and and <xref target="INET6NUM" format="default"/> informative, and
certainly more verbose, descriptions of the inetnum: database certainly more verbose descriptions of the inetnum: database
classes. classes exist in those documents.
</t> </t>
<t> <t>
An optional means for An optional means for
authenticating prefixlen data is also defined in <xref authenticating prefixlen data is also defined in <xref target="auth"/>.
target="auth"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>
<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"MAY", and "OPTIONAL" in this document are to be interpreted as RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref format="default" pageno="false" "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
target="RFC2119"/> <xref format="default" pageno="false" be interpreted as
target="RFC8174"/> when, and only when, they appear in all described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
</t> </t>
</section> </section>
<section anchor="pl" numbered="true" toc="default"> <section anchor="pl" numbered="true" toc="default">
<name>prefixlen Files</name> <name>prefixlen Files</name>
<!-- Note to PE:
[RFC4180] has mixed use of "Comma-Separated Values" and "Comma seperated values"
-->
<t> <t>
prefixlen files are CSV (Comma Separated Values) files <xref target="RFC 4180" format="default"/> in text format with prefixlen files are CSV files <xref target="RFC4180" format="default"/> in text format with
UTF-8 encoding <xref target="RFC3629" format="default"/>, excluding prob lematic code points as described in <xref target="RFC9839" format="default"/>. UTF-8 encoding <xref target="RFC3629" format="default"/>, excluding prob lematic code points as described in <xref target="RFC9839" format="default"/>.
Lines MUST be delimited by a line break (CRLF), and blank lines MUST be Lines <bcp14>MUST</bcp14> be delimited by a line break (CRLF), and blank
ignored. lines <bcp14>MUST</bcp14> be ignored.
Text from a '#' character to the end of the current line MUST be treated Text from a '#' character to the end of the current line <bcp14>MUST</bc
as a comment only and is similarly ignored. p14> be treated as a comment only and is similarly ignored.
The first field of each non-ignored line specifies the prefix in questio The first field of each line that is not ignored specifies the prefix in
n, the second field the end-site prefix length within that prefix as an integer, question, the second the end-site prefix length within that prefix as an intege
and the third field the number of end-sites within an end-site prefix length fo r, and the third the number of end-sites within an end-site prefix length for ne
r networks using Carrier-Grade NAT (CGN) <xref target="RFC6598" format="default" tworks using Carrier-Grade NAT (CGN) <xref target="RFC6598" format="default"/> o
/> or proxies. r proxies.
<!--[rfced] Please clarify the antecedent of "this":
Original:
In all places Carrier-Grade NAT or CGN is used in this document, this
applies to proxies as well.
-->
In all places Carrier-Grade NAT or CGN is used in this document, this ap plies to proxies as well. In all places Carrier-Grade NAT or CGN is used in this document, this ap plies to proxies as well.
Note that all three fields MUST be present. Note that all three fields <bcp14>MUST</bcp14> be present.
This means there MUST be exactly two commas in each non-commented line d This means there <bcp14>MUST</bcp14> be exactly two commas in each non-c
elimiting the three fields. ommented line delimiting the three fields.
The first field MUST NOT be empty on lines which are not comments, while The first field <bcp14>MUST NOT</bcp14> be empty on lines that are not c
the second and third field can be empty in certain scenarios. omments, while the second and third field can be empty in certain scenarios.
If both the second and third fields are empty, this means that the publi If both the second and third fields are empty, the publisher does not wa
sher does not want to disclose any prefix length information. nt to disclose any prefix length information.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>End-site prefix length without CGN or proxies</name> <name>End-Site Prefix Length Without CGN or Proxies</name>
<t> <t>
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 range to its 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) <xref target="RFC6598" for customers without the use of CGN <xref target="RFC6598" format="default"/> or pr
mat="default"/> or proxy techniques, it would create a prefix length file contai oxy techniques, it would create a prefix length file containing the following ex
ning the following example entries: ample entries:
<sourcecode type="csv"> <![CDATA[ </t>
<sourcecode type="csv"><![CDATA[
2001:db8::/32,56,1 2001:db8::/32,56,1
192.0.2.0/24,32,1 192.0.2.0/24,32,1]]></sourcecode>
]]></sourcecode>
<t>
Note the third field being set to '1', which signals the absence of CGN or p roxies. Note the third field being set to '1', which signals the absence of CGN or p roxies.
This has the same meaning as the third field being left empty in this scenar io. This has the same meaning as the third field being left empty in this scenar io.
</t>
</section>
<section numbered="true" toc="default">
<name>End-Site Prefix Length with CGN or Proxies</name>
<t>
prefixlen files can also be used to signal the presence of CGN <xref tar
get="RFC6598" format="default"/> or proxies in networks.
This is especially useful for cases where multiple end-sites behind a CG
N or proxy service accessing a service at the same time might run into rate-limi
ting issues by service providers.
If a prefixlen file signals the presence of a CGN, service providers can
treat these prefixes in a way that rate limits are adjusted.
To signal the presence of a CGN, the number of CGN end-sites is specifie
d in the third field.
For example, a CGN prefix 192.0.2.0/24 containing 4000 CGN end-sites wou
ld be specified as follows:
</t> </t>
</section> <sourcecode type="csv"><![CDATA[
192.0.2.0/24,24,4000]]></sourcecode>
<t>
Note the second field in the above example is set to '24', signaling that th
e 4000 CGN end-sites are present in the complete 192.0.2.0/24 prefix.
</t>
<t>
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 specified as follows:
<section numbered="true" toc="default"> </t>
<name>End-site prefix length with CGN or proxies</name> <sourcecode type="csv"><![CDATA[
<t> 192.0.2.0/24,26,1000]]></sourcecode>
prefixlen files can also be used to signal the presence of Carrier-Grade <t>
NAT (CGN) <xref target="RFC6598" format="default"/> or proxies in networks. It is important to note that the third field denoting the number of CGN end-
This is especially useful for cases where multiple end-sites behind a CG sites is referring to the prefix length specified in the second field.
N or proxy service accessing a service at the same time might run into rate limi </t>
ting issues by service providers. <t>
In case a prefixlen file signals the presence of a CGN, service provider Note that this specification can be applied to IPv6 networks as well.
s can treat these prefixes in a way that rate limits are adjusted. </t>
To signal the presence of a CGN, the number of CGN end-sites are specifi </section>
ed in the third field. <section numbered="true" toc="default">
For example, a CGN prefix 192.0.2.0/24 containing 4000 CGN end sites wou <name>Longest Prefix Matching</name>
ld be specified as follows:
<sourcecode type="csv"> <![CDATA[ <!--[rfced] We had a few questions about the following text:
192.0.2.0/24,24,4000
]]></sourcecode>
</t>
<t> Original:
Note the second field in the above example set to '24', signaling that the 4 Prefix length files can contain sub-prefixes entries of a parent
000 CGN end-sites are present in the complete 192.0.2.0/24 prefix. prefix, which needs to be taken into account when processing these
</t> files.
<t> a) Please confirm the use of the plural "sub-prefixes".
If on the other hand these 4000 CGN end-sites are distributed 1000 each in t
he four /26 sub-prefixes within 192.0.2.0/24, this is specified as follows:
<sourcecode type="csv"> <![CDATA[ Perhaps:
192.0.2.0/24,26,1000 Prefix length files can contain sub-prefix entries of a parent
]]></sourcecode> prefix,..
It is important to note that the third field denoting the number of CGN end- b) Might this sentence be rephrased as:
sites is referring to the prefix length specified in the second field.
</t>
<t> Perhaps:
Note that this specification can be applied to IPv6 networks as well. Prefix length files can contain sub-prefix entries of a parent prefix; this need
</t> s to be taken into account when processing these files.
</section>
<section numbered="true" toc="default"> -->
<name>Longest prefix matching</name>
<t> <t>
Prefix length files can contain sub-prefixes entries of a parent prefix, whi ch needs to be taken into account when processing these files. Prefix length files can contain sub-prefixes entries of a parent prefix, whi ch needs to be taken into account when processing these files.
For example, if a cloud provider assigns /120 IPv6 prefixes to each customer VM and a /64 prefix to premium customers, it would create a prefix length file containing the following example entries: For example, if a cloud provider assigns /120 IPv6 prefixes to each customer VM and a /64 prefix to premium customers, it would create a prefix length file containing the following example entries:
<sourcecode type="csv"> <![CDATA[ </t>
<sourcecode type="csv"><![CDATA[
2001:db8::/32,120, 2001:db8::/32,120,
2001:db8:abcd::/48,64, 2001:db8:abcd::/48,64,]]></sourcecode>
]]></sourcecode> <t>
Note that the second entry in the above example is a subprefix of the first entry. Note that the second entry in the above example is a subprefix of the first entry.
Therefore, longest prefix matching has to be performed when parsing prefixle n files. Therefore, longest prefix matching has to be performed when parsing prefixle n files.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section numbered="true" toc="default"> <name>Not Specifying Any End-Site Prefix Length</name>
<name>Not specifying any end-site prefix length</name>
<t> <t>
If an ISP delegates /32 IPv4 prefixes (i.e., a single IPv4 address) of 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 Carrier-Grade NAT (C the 192.0.2.0/24 range to its customers without the use of CGN, and it has a sp
GN), and it has a special sub-prefix 192.0.2.0/28 where this policy does not app ecial sub-prefix 192.0.2.0/28 where this policy does not apply, it can signal so
ly, it can signal so with the following prefix length file: with the following prefix length file:
<sourcecode type="csv"> <![CDATA[ </t>
<sourcecode type="csv"><![CDATA[
192.0.2.0/24,32, 192.0.2.0/24,32,
192.0.2.0/28,, 192.0.2.0/28,,]]></sourcecode>
]]></sourcecode> <t>
If both the second and third fields are empty, this means that the publisher If both the second and third fields are empty, the publisher does not want t
does not want to disclose any prefix length information. o disclose any prefix length information.
Any prefix length information from covering prefixes (192.0.2.0/24 in our ex Any prefix length information from covering prefixes (192.0.2.0/24 in our ex
ample) MUST be discarded for sub-prefixes specified in prefixlen files (192.0.2. ample) <bcp14>MUST</bcp14> be discarded for sub-prefixes specified in prefixlen
0/28 in our example). files (192.0.2.0/28 in our example).
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section numbered="true" toc="default"> <name>Processing prefixlen Files</name>
<name>Processing prefixlen files</name> <t>
<t> Multiple entries with exactly the same prefix <bcp14>MUST</bcp14> be con
Multiple entries with exactly the same prefix MUST be considered an erro sidered an error, and consumer implementations <bcp14>SHOULD</bcp14> log the rep
r, and consumer implementations SHOULD log the repeated entries for further admi eated entries for further administrative review.
nistrative review. Publishers <bcp14>MUST</bcp14> take measures to ensure there is one and
Publishers MUST take measures to ensure there is one and only one entry only one entry per prefix.
per prefix. </t>
</t> <t>
Upon encountering an erroneous entry in a prefixlen file, consumer imple
<t> mentations <bcp14>MUST</bcp14> skip that entry, log the error, and continue proc
Upon encountering an erroneous entry in a prefixlen file, consumer imple essing the remaining entries.
mentations MUST skip that entry, log the error, and continue processing the rema </t>
ining entries. <t>
</t>
<t>
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 <xref target="inetnum" format="default"/>, prefixlen data. <xref target="inetnum" format="default"/>
this document specifies how to find the relevant prefixlen file specifies how to find the relevant prefixlen file
given an IP address. given an IP address.
</t> </t>
<t> <t>
prefixlen data for large providers administrating a large number of netw orks prefixlen data for large providers administrating a large number of netw orks
and end-sites can contain millions of entries. The size of a and end-sites can contain millions of entries. The size of a
file can be even larger if an unsigned prefixlen file combines file can be even larger if an unsigned prefixlen file combines
data for many prefixes, if dual IPv4/IPv6 spaces are data for many prefixes, if dual IPv4/IPv6 spaces are
represented, etc. represented, etc.
</t> </t>
<t> <t>
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 authenticate the data in the prefixlen files. The same approach
to signatures is used in this document that was used in <xref target="RF C9632"/>. to signatures is used in this document that was used in <xref target="RF C9632"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="inetnum" numbered="true" toc="default"> <section anchor="inetnum" numbered="true" toc="default">
<name>inetnum: Class</name> <name>inetnum: Class</name>
<t> <t>
The original RPSL specifications (<xref The original RPSL specifications (<xref target="RIPE81" format="default"
target="RIPE81" format="default"/>, <xref target="RIPE181" />, <xref target="RIPE181" format="default"/>, and a trail of subsequent documen
format="default"/>, and a trail of subsequent documents) were ts) were
written by the RIPE community. The IETF standardized RPSL in written by the RIPE community. The IETF standardized RPSL in
<xref target="RFC2622" format="default"/> and <xref <xref target="RFC2622" format="default"/> and <xref target="RFC4012" for
target="RFC4012" format="default"/>. Since then, it has been mat="default"/>. Since then, it has been
modified and extensively enhanced in the Regional Internet modified and extensively enhanced in the Regional Internet
Registry (RIR) community, mostly by RIPE <xref target="RIPE-DB" Registry (RIR) community, mostly by RIPE <xref target="RIPE-DB" format="
format="default"/>. At the time of publishing this document, default"/>. At the time of publication,
change control of RPSL effectively lies in the operator change control of RPSL effectively lies in the operator
community. community.
</t> </t>
<t> <t>
The RPSL, and <xref target="RFC2725" format="default"/> and The RPSL, and <xref target="RFC2725" format="default"/> and
<xref target="RFC4012" format="default"/> used by the Regional <xref target="RFC4012" format="default"/> used by the RIRs, specify the
Internet Registries (RIRs), specify the inetnum: database class. inetnum: database class.
Each of these objects describes an IP address range and its Each of these objects describes an IP address range and its
attributes. The inetnum: objects form a hierarchy ordered on attributes. The inetnum: objects form a hierarchy ordered on
the address space. the address space.
</t> </t>
<t> <t>
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 defines the syntax of a prefixlen remarks: attribute, which
contains an HTTPS URL of a prefixlen file. The format of the contains an HTTPS URL of a prefixlen file. The format of the
inetnum: prefixlen remarks: attribute MUST be as in this example, inetnum: prefixlen remarks: attribute <bcp14>MUST</bcp14> be as in this
"remarks: Prefixlen ", where the token "Prefixlen" MUST be example,
case-sensitive, followed by a URL that will vary, but it MUST refer "remarks: Prefixlen ", where the token "Prefixlen" <bcp14>MUST</bcp14> b
e
case-sensitive, followed by a URL that will vary but that <bcp14>MUST</b
cp14> refer
only to a single prefixlen file. only to a single prefixlen file.
</t> </t>
<sourcecode type="rpsl"><![CDATA[
<sourcecode type="rpsl"> <![CDATA[
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]]></sourcecode>
]]></sourcecode>
<t> <t>
While we leave global agreement of RPSL modification to the While we leave global agreement of RPSL modification to the
relevant parties, we specify that a proper prefixlen: attribute in relevant parties, we specify that a proper prefixlen: attribute in
the inetnum: class MUST be "prefixlen:" and the inetnum: class <bcp14>MUST</bcp14> be "prefixlen:" and
MUST be followed by a single URL that will vary, <bcp14>MUST</bcp14> be followed by a single URL that will vary,
but it MUST refer only to a single prefixlen file. but it <bcp14>MUST</bcp14> refer only to a single prefixlen file.
</t> </t>
<sourcecode type="rpsl"><![CDATA[ <sourcecode type="rpsl"><![CDATA[
inetnum: 192.0.2.0/24 # example inetnum: 192.0.2.0/24 # example
prefixlen: https://example.com/prefixlen prefixlen: https://example.com/prefixlen]]></sourcecode>
]]></sourcecode>
<t> <t>
The URL uses HTTPS, so the WebPKI provides authentication, The URL uses HTTPS, so the Web Public Key Infrastructure (WebPKI) provid es authentication,
integrity, and confidentiality for the fetched prefixlen file. integrity, and confidentiality for the fetched prefixlen file.
However, the WebPKI cannot provide authentication of IP address However, the WebPKI cannot provide authentication of IP address
space assignment. In contrast, the RPKI (see <xref space assignment. In contrast, the RPKI (see <xref target="RFC6481" for
target="RFC6481" format="default"/>) can be used to authenticate mat="default"/>) can be used to authenticate
IP space assignment; see optional authentication in <xref IP space assignment; see optional authentication in <xref target="auth"
target="auth" format="default"/>. format="default"/>.
</t> </t>
<t> <t>
Until all producers of inetnum: objects, i.e., the RIRs, state Until all producers of inetnum: objects, i.e., the RIRs, state
that they have migrated to supporting the prefixlen: attribute, that they have migrated to supporting the prefixlen: attribute,
consumers looking at inetnum: objects to find prefixlen URLs MUST consumers looking at inetnum: objects to find prefixlen URLs <bcp14>MUST </bcp14>
be able to consume the remarks: and prefixlen: forms. be able to consume the remarks: and prefixlen: forms.
</t> </t>
<t> <t>
The migration not only implies that the RIRs support the The migration not only implies that the RIRs support the
prefixlen: attribute, but that all registrants have migrated any prefixlen: attribute, but that all registrants have migrated any
inetnum: objects from remarks: to prefixlen:. inetnum: objects from remarks: to prefixlen:.
</t> </t>
<t> <t>
Any particular inetnum: object SHOULD have, at most, one prefixlen Any particular inetnum: object <bcp14>SHOULD</bcp14> have, at most, one prefixlen
reference, whether a remarks: or prefixlen: attribute reference, whether a remarks: or prefixlen: attribute
when it is implemented. As the remarks: form cannot be when it is implemented. As the remarks: form cannot be
formally checked by the RIR, this cannot be formally enforced. formally checked by the RIR, this cannot be formally enforced.
A prefixlen: attribute is preferred, of course, if the RIR A prefixlen: attribute is preferred, of course, if the RIR
supports it. If there is more than one type of attribute in the supports it. If there is more than one type of attribute in the
inetnum: object, the prefixlen: attribute MUST be prioritized inetnum: object, the prefixlen: attribute <bcp14>MUST</bcp14> be prior itized
over the remarks: attribute. over the remarks: attribute.
</t> </t>
<t> <t>
For inetnum: instances covering the same address range, a signed prefixle n For inetnum: instances covering the same address range, a signed prefixle n
file MUST be preferred over an unsigned file. If none are file <bcp14>MUST</bcp14> be preferred over an unsigned file. If none are
signed, or more than one is signed, the (signed) inetnum: with signed, or more than one is signed, the (signed) inetnum: with
the most recent last-modified: attribute MUST be preferred. the most recent last-modified: attribute <bcp14>MUST</bcp14> be preferred .
</t> </t>
<t> <t>
If a prefixlen file describes multiple disjoint ranges of IP If a prefixlen file describes multiple disjoint ranges of IP
address space, there are likely to be prefixlen references from address space, there are likely to be prefixlen references from
multiple inetnum: objects. Files with prefixlen references from multiple inetnum: objects. Files with prefixlen references from
multiple inetnum: objects are not compatible with the signing multiple inetnum: objects are not compatible with the signing
procedure in <xref target="auth" format="default"/>. procedure in <xref target="auth" format="default"/>.
</t> </t>
<t> <t>
An unsigned, and only an unsigned, prefixlen file MAY be An unsigned, and only an unsigned, prefixlen file <bcp14>MAY</bcp14> be
referenced by multiple inetnum: instances and MAY contain prefixes from referenced by multiple inetnum: instances and <bcp14>MAY</bcp14> contain
prefixes from
more than one registry. more than one registry.
</t> </t>
<t> <t>
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 <bcp14>MUST</bcp14> be used.
</t> </t>
<t> <t>
It is significant that prefixlen data may have finer granularity It is significant that prefixlen data may have finer granularity
than the inetnum: that refers to them. For example, an inetnum: than the inetnum: that refers to them. For example, an inetnum:
object for an address range P could refer to a prefixlen file in object for an address range P could refer to a prefixlen file in
which P has been subdivided into one or more longer prefixes. which P has been subdivided into one or more longer prefixes.
</t> </t>
<t> <t>
Backward compatibility issues regarding the implementation of new RPSL a ttributes are covered by Section 10.2 of <xref target="RFC2622"/>. Backward-compatibility issues regarding the implementation of new RPSL a ttributes are covered by <xref target="RFC2622" section="10.2"/>.
</t> </t>
</section> </section>
<section anchor="fetch" numbered="true" toc="default"> <section anchor="fetch" numbered="true" toc="default">
<name>Fetching prefixlen Data</name> <name>Fetching prefixlen Data</name>
<t> <t>
This document provides a guideline for how interested This document provides a guideline for how interested
parties should fetch and read prefixlen files. parties should fetch and read prefixlen files.
</t> </t>
<t> <t>
To minimize the load on RIRs' WHOIS <xref target="RFC3912"/> To minimize the load on RIRs' WHOIS <xref target="RFC3912"/>
services, the RIR's bulk download services SHOULD services, the RIR's bulk-download services <bcp14>SHOULD</bcp14>
be used for large-scale access to gather inetnum: instances with prefixl en be used for large-scale access to gather inetnum: instances with prefixl en
references. This uses efficient bulk access instead of fetching references. This uses efficient bulk access instead of fetching
via brute-force search through the IP space. via brute-force search through the IP space.
When using bulk download services they MUST be accessed using HTTPS <xre f target="RFC9110" format="default"/>, FTP <xref target="RFC0959"/> MUST NOT be used. When using bulk-download services, they <bcp14>MUST</bcp14> be accessed using HTTPS <xref target="RFC9110" format="default"/>; FTP <xref target="RFC0959 "/> <bcp14>MUST NOT</bcp14> be used.
</t> </t>
<t> <t>
On the other hand, RIRs are converging on RDAP support which On the other hand, RIRs are converging on RDAP support, which
includes geofeed data, see <xref includes geofeed data; see <xref target="RFC9877"/>. It is hoped that th
target="RFC9877"/>. It is hoped that this is
will be extended, or generalized, to support prefixlen data. will be extended, or generalized, to support prefixlen data.
</t> </t>
<t> <t>
When reading data from a prefixlen file, one MUST ignore When reading data from a prefixlen file, one <bcp14>MUST</bcp14> ignore
data outside the referring inetnum: object's address range. data outside the referring inetnum: object's address range.
This is to avoid importing data about ranges not under the This is to avoid importing data about ranges not under the
control of the operator. Note that signed files MUST only control of the operator. Note that signed files <bcp14>MUST</bcp14> onl y
contain prefixes within the referring inetnum:'s range as contain prefixes within the referring inetnum:'s range as
mandated in <xref target="auth"/>. mandated in <xref target="auth"/>.
</t> </t>
<t> <t>
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: <bcp14>MUST</bcp14> be ignored.
</t> </t>
<t> <t>
Given an address range of interest, the most specific inetnum: Given an address range of interest, the most specific inetnum:
object with a prefixlen reference MUST be used to fetch the object with a prefixlen reference <bcp14>MUST</bcp14> be used to fetch t he
prefixlen file. For example, if the fetching party finds prefixlen file. For example, if the fetching party finds
the following inetnum: objects: the following inetnum: objects:
<sourcecode type="rpsl"> <![CDATA[ </t>
<sourcecode type="rpsl"><![CDATA[
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]]></sourcecode>
]]></sourcecode> <t>
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 <bcp14>MUST<
/bcp14>
ignore data in prefixlen_1 because 192.0.2.0/29 is within the 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 more specific 192.0.2.0/26 inetnum: covering that address range
and that inetnum: does have a prefixlen reference. and that inetnum: does have a prefixlen reference.
</t> </t>
</section> </section>
<section anchor="auth" numbered="true" toc="default"> <section anchor="auth" numbered="true" toc="default">
<name>Authenticating prefixlen Data (Optional)</name> <name>Authenticating prefixlen Data (Optional)</name>
<t> <t>
The question arises whether a particular prefixlen The question arises whether a particular prefixlen
data set is valid, i.e., is authorized by the data set is valid, i.e., is authorized by the
"owner" of the IP address space and is authoritative in some "owner" of the IP address space and is authoritative in some
sense. The inetnum: that points to the prefixlen sense. The inetnum: that points to the prefixlen
file provides some assurance. Unfortunately, file provides some assurance. Unfortunately,
the RPSL in some repositories is weakly authenticated at best. the RPSL in some repositories is weakly authenticated at best.
An approach where RPSL was signed per <xref target="RFC7909"/> An approach where RPSL was signed per the guidance in <xref target="RFC79 09"/>
would be good, except it would have to be deployed by all RPSL would be good, except it would have to be deployed by all RPSL
registries, and there is a fair number of them. registries, and there is a fair number of them.
</t> </t>
<t> <t>
The remainder of this section specifies an optional The remainder of this section specifies an optional
authenticator for the prefixlen data set that follows the Signed authenticator for the prefixlen data set that follows the Signed
Object Template for the Resource Public Key Infrastructure Object Template for the Resource Public Key Infrastructure
(RPKI) <xref target="RFC6488"/>. (RPKI) <xref target="RFC6488"/>.
</t> </t>
<t> <t>
A single optional authenticator MAY be appended to a prefixlen A single optional authenticator <bcp14>MAY</bcp14> be appended to a prefi xlen
file. It is a digest of the main body file. It is a digest of the main body
of the file signed by the private key of the relevant RPKI of the file signed by the private key of the relevant RPKI
certificate for a covering address range. The following format certificate for a covering address range. The following format
bundles the relevant RPKI certificate with a signature over the bundles the relevant RPKI certificate with a signature over the
prefixlen text. prefixlen text.
</t> </t>
<t> <t>
The canonicalization procedure converts the data from their The canonicalization procedure converts the data from their
internal character representation to the UTF-8 <xref internal character representation to the UTF-8 character encoding (see <x
target="RFC3629"/> character encoding, and the &lt;CRLF&gt; ref target="RFC3629"/>), and the &lt;CRLF&gt;
sequence MUST be used to denote the end of each line of text. A sequence <bcp14>MUST</bcp14> be used to denote the end of each line of te
xt. A
blank line is represented solely by the &lt;CRLF&gt; sequence. blank line is represented solely by the &lt;CRLF&gt; sequence.
For robustness, any non-printable characters MUST NOT be changed For robustness, any non-printable characters <bcp14>MUST NOT</bcp14> be c
by canonicalization. Trailing blank lines MUST NOT appear at hanged
by canonicalization. Trailing blank lines <bcp14>MUST NOT</bcp14> appear
at
the end of the file. That is, the file must not end with the end of the file. That is, the file must not end with
multiple consecutive &lt;CRLF&gt; sequences. Any end-of-file multiple consecutive &lt;CRLF&gt; sequences. Any end-of-file
marker used by an operating system is not considered to be part marker used by an operating system is not considered to be part
of the file content. When present, such end-of-file markers of the file content. When present, such end-of-file markers
MUST NOT be covered by the digital signature. <bcp14>MUST NOT</bcp14> be covered by the digital signature.
</t> </t>
<t> <t>
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.
</t> </t>
<t> <t>
Borrowing detached signatures from <xref target="RFC5485"/>, Borrowing detached signatures from <xref target="RFC5485"/>,
after file canonicalization, the Cryptographic Message Syntax after file canonicalization, the CMS (see <xref target="RFC5652"/>) is us
(CMS) <xref target="RFC5652"/> is used to create a detached ed to create a detached
DER-encoded signature that is then Base64 encoded with padding DER-encoded signature that is then Base64-encoded with padding
(as defined in Section 4 of <xref target="RFC4648"/>) and line (as defined in <xref target="RFC4648" section="4"/>) and line
wrapped to 72 or fewer characters. The same digest algorithm wrapped to 72 or fewer characters. The same digest algorithm
MUST be used for calculating the message digest of the content <bcp14>MUST</bcp14> be used for calculating the message digest of the con tent
being signed, which is the prefixlen file, and for calculating the being signed, which is the prefixlen file, and for calculating the
message digest on the SignerInfo SignedAttributes <xref message digest on the SignerInfo SignedAttributes (see <xref target="RFC8
target="RFC8933"/>. The message digest algorithm identifier 933"/>). The message digest algorithm identifier
MUST appear in both the CMS SignedData <bcp14>MUST</bcp14> appear in both the CMS SignedData
DigestAlgorithmIdentifiers and the SignerInfo DigestAlgorithmIdentifiers and the SignerInfo
DigestAlgorithmIdentifier <xref target="RFC5652"/>. The RPKI DigestAlgorithmIdentifier <xref target="RFC5652"/>. The RPKI
certificate covering the prefixlen inetnum: object's address range certificate covering the prefixlen inetnum: object's address range
is included in the CMS SignedData certificates field <xref is included in the CMS SignedData certificates field <xref target="RFC565
target="RFC5652"/>. 2"/>.
</t> </t>
<t> <t>
The address range of the signing certificate MUST cover all The address range of the signing certificate <bcp14>MUST</bcp14> cover al l
prefixes in the signed prefixlen file. If not, the authenticator prefixes in the signed prefixlen file. If not, the authenticator
is invalid. is invalid.
</t> </t>
<t> <t>
The signing certificate MUST NOT include the Autonomous System The signing certificate <bcp14>MUST NOT</bcp14> include the Autonomous Sy
Identifier Delegation certificate extension <xref stem
target="RFC3779"/>. If it is present, the authenticator is Identifier Delegation certificate extension <xref target="RFC3779"/>. If
it is present, the authenticator is
invalid. invalid.
</t> </t>
<t> <t>
As with many other RPKI signed objects, the IP Address As with many other RPKI signed objects, the IP Address
Delegation certificate extension MUST NOT use the "inherit" Delegation certificate extension <bcp14>MUST NOT</bcp14> use the "inheri
capability defined in Section 2.2.3.5 of <xref t"
target="RFC3779"/>. If "inherit" is used, the authenticator is capability defined in <xref target="RFC3779" section="2.2.3.5"/>. If "i
nherit" is used, the authenticator is
invalid. invalid.
</t> </t>
<t> <t>
An IP Address Delegation extension using "inherit" would An IP Address Delegation certificate extension using "inherit" would
complicate processing. The implementation would have to build complicate processing. The implementation would have to build
the certification path from the end-entity to the trust anchor, the certification path from the end-entity to the trust anchor and
then validate the path from the trust anchor to the end-entity, then validate the path from the trust anchor to the end-entity.
and then the parameter would have to be remembered when the Then, the parameter would have to be remembered when the
validated public key was used to validate a signature on a CMS validated public key was used to validate a signature on a CMS
object. Having to remember things from certification path object. Having to remember things from certification-path
validation for use with CMS object processing would be quite validation for use with CMS object processing would be quite
complex and error-prone. And, the certificates do not get that complex and error-prone. And, the certificates do not get that
much bigger by repeating the information. much bigger by repeating the information.
</t> </t>
<t> <t>
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 identical to or a subset of A. "Address range" is used here
because inetnum: objects and RPKI certificates need not align on because inetnum: objects and RPKI certificates need not align on
Classless Inter-Domain Routing (CIDR) <xref target="RFC4632"/> Classless Inter-Domain Routing (CIDR) <xref target="RFC4632"/>
prefix boundaries, while those of the lines in a prefixlen file do prefix boundaries, while those of the lines in a prefixlen file do
align. align.
</t> </t>
<t> <t>
The Certification Authority (CA) MUST generate a new End Entity (EE) The Certification Authority (CA) <bcp14>MUST</bcp14> generate a new End Entit y (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 <bcp14>SHOULD</bcp14> sign onl
prefixlen file. That is, a new key pair SHOULD be generated for each y one
prefixlen file. That is, a new key pair <bcp14>SHOULD</bcp14> be generated fo
r each
new version of a particular prefixlen file. When the EE certificate is new version of a particular prefixlen file. When the EE certificate is
used in this fashion, it is termed a "one-time-use" EE certificate used in this fashion, it is termed a "one-time-use" EE certificate
(see Section 3 of <xref target="RFC6487"/>). (see <xref target="RFC6487" section="3"/>).
</t> </t>
<t> <t>
On the other hand, verifying the signature has no similar On the other hand, verifying the signature has no similar
complexity; the certificate, which is validated in the RPKI, complexity; the certificate, which is validated in the RPKI,
contains the needed public key. The RPKI trust anchors for the contains the needed public key. The RPKI trust anchors for the
RIRs are available to the party performing signature validation. RIRs are available to the party performing signature validation.
Validation of the CMS signature over the prefixlen file Validation of the CMS signature over the prefixlen file
involves: involves:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> <li>
Obtaining the signer's certificate from the CMS SignedData Obtaining the signer's certificate from the CMS SignedData
CertificateSet <xref target="RFC5652"/>. The certificate CertificateSet <xref target="RFC5652"/>. The certificate
SubjectKeyIdentifier extension <xref target="RFC5280"/> MUST SubjectKeyIdentifier extension <xref target="RFC5280"/> <bcp14>MUST</bc p14>
match the SubjectKeyIdentifier in the CMS SignerInfo match the SubjectKeyIdentifier in the CMS SignerInfo
SignerIdentifier <xref target="RFC5652"/>. If the key SignerIdentifier <xref target="RFC5652"/>. If the key
identifiers do not match, then validation MUST fail. identifiers do not match, then validation <bcp14>MUST</bcp14> fail.
</li> </li>
<li>
<li> Validating the signer's certificate <bcp14>MUST</bcp14> ensure that it
Validating the signer's certificate MUST ensure that it is is
part of the current <xref target="RFC9286"/> manifest and that part of the current manifest per <xref target="RFC9286"/> and that
all resources are covered by the RPKI certificate. all resources are covered by the RPKI certificate.
</li> </li>
<li>
<li> Constructing and validating the certification path for the signer's
Construct and validate the certification path for the signer's
certificate. All of the needed certificates are expected to be certificate. All of the needed certificates are expected to be
readily available in the RPKI repository. The certification path readily available in the RPKI repository. The certification path
MUST be valid according to the validation algorithm in <xref target="RFC52 80"/> <bcp14>MUST</bcp14> be valid according to the validation algorithm in <xre f target="RFC5280"/>
and the additional checks specified in <xref target="RFC3779"/> associated with and the additional checks specified in <xref target="RFC3779"/> associated with
the IP Address Delegation certificate extension. the IP Address Delegation certificate extension.
If certification path validation is unsuccessful, then validation If certification path validation is unsuccessful, then validation
MUST fail. <bcp14>MUST</bcp14> fail.
</li> </li>
<li>
<li> Validating the CMS SignedData as specified in <xref target="RFC5652"/>
Validating the CMS SignedData as specified in <xref using the public key from the validated
target="RFC5652"/> using the public key from the validated
signer's certificate. If the signature validation is signer's certificate. If the signature validation is
unsuccessful, then validation MUST fail. unsuccessful, then validation <bcp14>MUST</bcp14> fail.
</li> </li>
<li>
<li> Confirming that the eContentType Object IDentifier (OID) is
Confirming that the eContentType object identifier (OID) is id-ct-prefixlenCSVwithCRLF (1.2.840.113549.1.9.16.1.57). This
id-ct-prefixlenCSVwithCRLF (1.2.840.113549.1.9.16.1.TBD). This OID <bcp14>MUST</bcp14> appear within both the eContentType in the
OID MUST appear within both the eContentType in the
encapContentInfo object and the ContentType signed attribute encapContentInfo object and the ContentType signed attribute
in the signerInfo object (see <xref target="RFC6488"/>). in the signerInfo object (see <xref target="RFC6488"/>).
</li> </li>
<li>
<li>
Verifying that the IP Address Delegation certificate Verifying that the IP Address Delegation certificate
extension <xref target="RFC3779"/> covers all of the address extension <xref target="RFC3779"/> covers all of the address
ranges of the prefixlen file. If all of the address ranges are ranges of the prefixlen file. If all of the address ranges are
not covered, then validation MUST fail. not covered, then validation <bcp14>MUST</bcp14> fail.
</li> </li>
</ol> </ol>
<t> <t>
All of the above steps MUST be successful to consider the All of the above steps <bcp14>MUST</bcp14> be successful to consider the
prefixlen file signature as valid. prefixlen file signature to be valid.
</t> </t>
<t> <t>
The authenticator MUST be hidden as a series of "#" comments at the The authenticator <bcp14>MUST</bcp14> be hidden as a series of "#" commen ts 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:
</t> </t>
<sourcecode type=""><![CDATA[ <sourcecode type=""><![CDATA[
# 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
# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk= # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
# End Signature: 192.0.2.0 - 192.0.2.255 # End Signature: 192.0.2.0 - 192.0.2.255]]></sourcecode>
]]></sourcecode>
<t> <t>
A correct and full example is in Appendix A. A correct and full example is in <xref target="asn1"/>.
</t> </t>
<t> <t>
The CMS signature does not cover the signature lines. The CMS signature does not cover the signature lines.
</t> </t>
<t> <t>
The bracketing "# RPKI Signature:" and "# End Signature:" MUST The bracketing "# RPKI Signature:" and "# End Signature:" <bcp14>MUST</bc p14>
be present as shown in the example. The RPKI Signature's IP be present as shown in the example. The RPKI Signature's IP
address range MUST match that of the prefixlen URL in the inetnum: address range <bcp14>MUST</bcp14> match that of the prefixlen URL in the inetnum:
that points to the prefixlen file. that points to the prefixlen file.
</t> </t>
</section> </section>
<section anchor="ops" numbered="true" toc="default"> <section anchor="ops" numbered="true" toc="default">
<name>Operational Considerations</name> <name>Operational Considerations</name>
<t> <t>
To create the needed inetnum: objects, an operator wishing to register To create the needed inetnum: objects, an operator wishing to register
the location of their prefixlen file needs to coordinate with their the location of their prefixlen file needs to coordinate with their
Regional Internet Registry (RIR) or National Internet Registry (NIR) Regional Internet Registry (RIR) or National Internet Registry (NIR)
and/or any provider Local Internet Registry (LIR) that has assigned and/or any provider Local Internet Registry (LIR) that has assigned
address ranges to them. RIRs/NIRs provide means for assignees to address ranges to them. RIRs/NIRs provide means for assignees to
create and maintain inetnum: objects. They also provide means of create and maintain inetnum: objects. They also provide means of
assigning or sub-assigning IP address resources and allowing the assigning or sub-assigning IP address resources and allowing the
assignee to create WHOIS data, including inetnum: objects, thereby assignee to create WHOIS data, including inetnum: objects, thereby
referring to prefixlen files. referring to prefixlen files.
</t> </t>
<t> <t>
The prefixlen files MUST be published via and fetched using The prefixlen files <bcp14>MUST</bcp14> be published via and fetched usi ng
HTTPS <xref target="RFC9110" format="default"/>. HTTPS <xref target="RFC9110" format="default"/>.
</t> </t>
<t> <t>
When using data from a prefixlen file, one MUST ignore data When using data from a prefixlen file, one <bcp14>MUST</bcp14> ignore da ta
outside the referring inetnum: object's inetnum: attribute outside the referring inetnum: object's inetnum: attribute
address range. address range.
</t> </t>
<t> <t>
If and only if the prefixlen file is not signed per <xref target="auth" If and only if the prefixlen file is not signed per <xref target="auth"
format="default"/>, then multiple inetnum: objects MAY format="default"/>, then multiple inetnum: objects <bcp14>MAY</bcp14>
refer to the same prefixlen file, and the consumer MUST refer to the same prefixlen file, and the consumer <bcp14>MUST</bcp14>
use only lines in the prefixlen file where the prefix is covered by the use only lines in the prefixlen file where the prefix is covered by the
address range of the inetnum: object's URL it has followed. address range of the inetnum: object's URL it has followed.
</t> </t>
<t> <t>
If the prefixlen file is signed, and the signer's certificate If the prefixlen file is signed, and the signer's certificate
is replaced with another certificate, then the signature in is replaced with another certificate, then the signature in
the prefixlen file MUST be updated so that it can be properly the prefixlen file <bcp14>MUST</bcp14> be updated so that it can be prop erly
validated with the new certificate. validated with the new certificate.
</t> </t>
<t> <t>
It is good key hygiene to use a given key for only one purpose. 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 To dedicate a signing private key for signing a prefixlen file, an
RPKI Certification Authority (CA) may issue a subordinate RPKI Certification Authority (CA) may issue a subordinate
certificate exclusively for the purpose shown in <xref certificate exclusively for the purpose shown in <xref target="example"
target="example" format="default"/>. format="default"/>.
</t> </t>
<t> <t>
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 <bcp14>SHOULD</bcp14> 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 specifics of a different aggregatee. Moreover, publishing
aggregated prefixlen data prevents the reader of the data to aggregated prefixlen data prevents the reader of the data to
perform the checks described in <xref target="fetch"/> and <xref perform the checks described in Sections <xref target="fetch" format="co
target="auth"/>. unter"/> and <xref target="auth" format="counter"/>.
</t> </t>
<t> <t>
An anonymized An anonymized
version of bulk WHOIS data is openly available for all RIRs except version of bulk WHOIS data is openly available for all RIRs except
ARIN, which requires an authorization. However, for users ARIN, which requires an authorization. However, for users
without such authorization, the same result can be achieved with without such authorization, the same result can be achieved with
extra RDAP effort. There is open-source code to pass over such extra RDAP effort. There is open-source code to pass over such
data across all RIRs, collect all prefixlen references, and data across all RIRs, collect all prefixlen references, and
process them <xref target="PREFIXLEN-FINDER" format="default"/>. process them <xref target="PREFIXLEN-FINDER" format="default"/>.
</t> </t>
skipping to change at line 760 skipping to change at line 668
</t> </t>
<t> <t>
An anonymized An anonymized
version of bulk WHOIS data is openly available for all RIRs except version of bulk WHOIS data is openly available for all RIRs except
ARIN, which requires an authorization. However, for users ARIN, which requires an authorization. However, for users
without such authorization, the same result can be achieved with without such authorization, the same result can be achieved with
extra RDAP effort. There is open-source code to pass over such extra RDAP effort. There is open-source code to pass over such
data across all RIRs, collect all prefixlen references, and data across all RIRs, collect all prefixlen references, and
process them <xref target="PREFIXLEN-FINDER" format="default"/>. process them <xref target="PREFIXLEN-FINDER" format="default"/>.
</t> </t>
<t> <t>
To prevent undue load on RPSL and prefixlen servers, To prevent undue load on RPSL and prefixlen servers,
entity-fetching prefixlen data using these mechanisms MUST entity-fetching prefixlen data using these mechanisms <bcp14>MUST
NOT do frequent real-time lookups. prefixlen servers SHOULD send an NOT</bcp14> do frequent real-time lookups. prefixlen servers <bcp14>SHO
HTTP Expires header <xref ULD</bcp14> send an
target="RFC9111" format="default"/> to signal when prefixlen data HTTP Expires header <xref target="RFC9111" format="default"/> to signal
when prefixlen data
should be refetched. If an HTTP Expires or Cache-Control header is should be refetched. If an HTTP Expires or Cache-Control header is
present, it MUST be honored by clients. As the data change very infreque ntly, in present, it <bcp14>MUST</bcp14> be honored by clients. As the data chang e very infrequently, in
the absence of such an HTTP header signal, collectors the absence of such an HTTP header signal, collectors
SHOULD NOT fetch more frequently than weekly. It <bcp14>SHOULD NOT</bcp14> fetch more frequently than weekly. It
would be polite not to fetch at magic times such as midnight would be polite not to fetch at magic times such as midnight
UTC, the first of the month, etc., because too many others are UTC, the first of the month, etc., because too many others are
likely to do the same. likely to do the same.
</t> </t>
</section> </section>
<!--[rfced] Please confirm that the Implementation Status section
should remain in the document for publication (see RFC 7942). -->
<section anchor="impl" numbered="true" toc="default"> <section anchor="impl" numbered="true" toc="default">
<name>Implementation Status</name> <name>Implementation Status</name>
<t> <t>
In November 2025, the prefixlen: attribute As of November 2025, the prefixlen: attribute
in inetnum objects has been implemented by the RIPE NCC database. in inetnum objects has been implemented by the RIPE NCC database.
</t> </t>
<t> <t>
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.
</t> </t>
<!-- Note to PE: I couldn't find any instance of "Tower of Babel" in [RFC7485]:
Current:
At the time of publishing this document, the registry data published
by ARIN are not the same RPSL as that of the other registries (see
[RFC7485] for a survey of the WHOIS Tower of Babel);...
-->
<t> <t>
At the time of publishing this document, the registry data At the time of publication, the registry data
published by ARIN are not the same RPSL as that of the other published by ARIN are not the same RPSL as that of the other
registries (see <xref target="RFC7485" format="default"/> for a registries (see <xref target="RFC7485" format="default"/> for a
survey of the WHOIS Tower of Babel); therefore, when fetching survey of the WHOIS Tower of Babel); therefore, when fetching
via bulk WHOIS over HTTPS <xref target="RFC9110" format="default"/>, via bulk WHOIS over HTTPS <xref target="RFC9110" format="default"/>,
WHOIS <xref target="RFC3912" format="default"/>, the WHOIS <xref target="RFC3912" format="default"/>, the
Registration Data Access Protocol (RDAP) <xref target="RFC9083" Registration Data Access Protocol (RDAP) <xref target="RFC9083" format="
format="default"/>, etc., the "NetRange" or "ip network" attribute/key m default"/>, etc., the "NetRange" or "ip network" attribute/key must be
ust be treated as "inetnum" and the "Comment" attribute must be
treated as "inetnum", and the "Comment" attribute must be
treated as "remarks". treated as "remarks".
</t> </t>
</section> </section>
<section anchor="seccons" numbered="true" toc="default"> <section anchor="seccons" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
The consumer of prefixlen data SHOULD fetch and process the data The consumer of prefixlen data <bcp14>SHOULD</bcp14> fetch and process t he data
themselves. Importing datasets produced and/or processed by a themselves. Importing datasets produced and/or processed by a
third party places significant trust in the third party. third party places significant trust in the third party.
</t> </t>
<t> <t>
As mentioned in <xref target="auth" format="default"/>, some As mentioned in <xref target="auth" format="default"/>, some
RPSL repositories have weak, if any, authentication. This RPSL repositories have weak, if any, authentication. This
allows spoofing of inetnum: objects pointing to malicious allows spoofing of inetnum: objects pointing to malicious
prefixlen files. <xref target="auth" format="default"/> suggests prefixlen files. <xref target="auth" format="default"/> suggests
an unfortunately complex method for stronger authentication an unfortunately complex method for stronger authentication
based on the RPKI. based on the RPKI.
</t> </t>
<t> <t>
For example, if an inetnum: for a wide address range (e.g., a For example, if an inetnum: for a wide address range (e.g., a
/16) points to an RPKI-signed prefixlen file, a customer or /16) points to an RPKI-signed prefixlen file, a customer or
attacker could publish an unsigned equal or narrower (e.g., a attacker could publish an unsigned equal or narrower (e.g., a
/24) inetnum: in a WHOIS registry that has weak authorization, /24) inetnum: in a WHOIS registry that has weak authorization,
abusing the rule that the most-specific inetnum: object with a abusing the rule that the most-specific inetnum: object with a
prefixlen reference MUST be used. prefixlen reference <bcp14>MUST</bcp14> be used.
</t> </t>
<t> <t>
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.
</t> </t>
<t> <t>
The RPSL providers have had to throttle fetching from their The RPSL providers have had to throttle fetching from their
servers due to too-frequent queries. Usually, they throttle by servers due to too-frequent queries. Usually, they throttle by
the querying IP address or block. Similar defenses will likely the querying IP address or block. Similar defenses will likely
need to be deployed by prefixlen file servers. need to be deployed by prefixlen file servers.
</t> </t>
<t> <t>
As prefixlen files disclose which parts of a prefix belong to an end sit As prefixlen files disclose which parts of a prefix belong to an end-sit
e, attackers could better focus DDoS traffic towards a website hosted by a cloud e, attackers could better focus DDoS traffic towards a website hosted by a cloud
provider by overwhelming only IP addresses from that specific end site. provider by overwhelming only IP addresses from that specific end-site.
Furthermore, information collected from prefixlen files could allow for Furthermore, information collected from prefixlen files could allow for
more targeted IPv6 scanning/reconnaissance, where scanners (be it benevolent or more targeted IPv6 scanning/reconnaissance, where scanners (be it benevolent or
malicious ones) can target specific sub-prefixes which they deem more interestin malicious ones) can target specific sub-prefixes that they deem more interesting
g. .
</t> </t>
<t> <t>
It is possible for publishers of prefixlen data to specify incorrect pre fixlen data about their prefixes. It is possible for publishers of prefixlen data to specify incorrect pre fixlen data about their prefixes.
This could either be done by mistake or on purpose. This could be done either by mistake or on purpose.
One example could be a malicious network operator trying to overflow the storage of databases that consume prefixlen data by setting a very specific pre fix size (e.g., /128 for large blocks of IPv6 address space). One example could be a malicious network operator trying to overflow the storage of databases that consume prefixlen data by setting a very specific pre fix size (e.g., /128 for large blocks of IPv6 address space).
In another example a network operator might annotate their prefixes as u sing CGN to go around legitimate blocking or throttling. In another example, a network operator might annotate their prefixes as using CGN to go around legitimate blocking or throttling.
A third example would be a malicious provider publishing fake small allo cations, so on receipt of complaints, they could plausibly respond by saying tha t they stopped the actions of a bad customer and move their malicious activities to a different prefix. A third example would be a malicious provider publishing fake small allo cations, so on receipt of complaints, they could plausibly respond by saying tha t they stopped the actions of a bad customer and move their malicious activities to a different prefix.
As a fourth example, network operators could overwhelm consumers by publ ishing prefixlen files containing millions or even billions of entries (e.g., en umerating all possible /96 subprefixes of a /32 IPv6 prefix). As a fourth example, network operators could overwhelm consumers by publ ishing prefixlen files containing millions or even billions of entries (e.g., en umerating all possible /96 subprefixes of a /32 IPv6 prefix).
Therefore, care should be taken when processing prefixlen data, as with any external third-party data. Therefore, care should be taken when processing prefixlen data, as with any external third-party data.
</t> </t>
</section> </section>
<section anchor="iana" numbered="true" toc="default"> <section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t> <t>
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 "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16 in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16
.0)" .0)" registry as follows:
registry as follows:
</t> </t>
<table>
<thead>
<tr>
<th>Description</th>
<th>OID</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>id-mod-prefixlen-2025</td>
<td>1.2.840.113549.1.9.16.0.87</td>
<td>RFC 9977</td>
</tr>
</tbody>
</table>
<figure> <!--[rfced] FYI - we have cut the following text as we believe that
<artwork><![CDATA[ this is referring to updating the Reference column. If there was
Description OID Reference some other intent (e.g., adding this document as a reference for
id-mod-prefixlen-2025 1.2.840.113549.1.9.16.0.TBD0 [RFC-TBD] the entire registry), please let us know.
]]></artwork>
</figure>
<t>
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-s
mime-0.
On publication of this document, the [RFC-TBD] reference needs to be
changed to the RFC number assigned to this document.
</t>
<t> Original:
IANA is asked to register an object identifiers for one content On publication of this document,
type in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1. the [RFC-TBD] reference needs to be changed to the RFC number
9.16.1)" assigned to this document.
registry as follows:
</t> and
On publication of this document,
the [RFC-TBD] reference needs to be changed to the RFC number
assigned to this document.
-->
<figure>
<artwork><![CDATA[
Description OID Reference
id-ct-prefixlenCSVwithCRLF 1.2.840.113549.1.9.16.1.TBD1 [RFC-TBD]
]]></artwork>
</figure>
<t>
The SMI Security for S/MIME Content Type Identifier (1.2.840.113549.1.9.1
6.1)
registry is located at:
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-s
mime-1.
On publication of this document, the [RFC-TBD] reference needs to be
changed to the RFC number assigned to this document.
</t>
</section>
<section title="Acknowledgments" anchor="acks">
<t> <t>
Thanks to the authors of <xref target="RFC8805"/> and <xref target="RFC9 IANA has registered an object identifier for one content
632"/> and the folk type in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.
they acknowledge from whom ideas and text have been liberally 9.16.1)" registry as follows:
expropriated. Thanks to John R. Levine for providing useful
feedback on the draft.
</t> </t>
<table>
<thead>
<tr>
<th>Description</th>
<th>OID</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>id-ct-prefixlenCSVwithCRLF</td>
<td>1.2.840.113549.1.9.16.1.57</td>
<td>RFC 9977</td>
</tr>
</tbody>
</table>
</section> </section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
622.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
725.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
629.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
779.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
012.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
180.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
652.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
268.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
481.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
487.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
488.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
933.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
110.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
286.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
839.xml"/>
<references title="Normative References"> <reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680">
&RFC2119;
&RFC2622;
&RFC2725;
&RFC3629;
&RFC3779;
&RFC4012;
&RFC4180;
&RFC4648;
&RFC5280;
&RFC5652;
&RFC8174;
&RFC6268;
&RFC6481;
&RFC6487;
&RFC6488;
&RFC8933;
&RFC9110;
&RFC9286;
&RFC9839;
<reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680">
<front> <front>
<title>Information technology -- Abstract Syntax Notation One (ASN.1 ): Specification of basic notation</title> <title>Information technology - Abstract Syntax Notation One (ASN.1) : Specification of basic notation</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.680"/> <seriesInfo name="ITU-T Recommendation" value="X.680"/>
<seriesInfo name="ISO/IEC" value="8824-1:2021"/> <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
</reference> </reference>
</references>
<references title="Informative References"> </references>
&RFC0959; <references>
&RFC3912; <name>Informative References</name>
&RFC4632; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
&RFC5485; 959.xml"/>
&RFC6598; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
&RFC7485; 912.xml"/>
&RFC7909; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
&RFC8805; 632.xml"/>
&RFC8981; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
&RFC9083; 485.xml"/>
&RFC9111; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
&RFC9632; 598.xml"/>
&RFC9877; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
485.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
909.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
805.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
981.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
083.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
111.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
632.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
877.xml"/>
<!-- [rfced] FYI: We made some formatting edits to [RIPE81]
and [RIPE181] to include the authors for those documents in the
reference entries.
Original:
[RIPE181] RIPE NCC, "Representation Of IP Routing Policies In A
Routing Registry", October 1994,
<https://www.ripe.net/publications/docs/ripe-181>.
[RIPE81] RIPE NCC, "Representation Of IP Routing Policies In The
RIPE Database", February 1993,
<https://www.ripe.net/publications/docs/ripe-081>.
Current:
[RIPE181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J.,
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>.
[RIPE81] Bates, T., Jouanigot, J., Karrenberg, D., Lothberg, P.,
and M. Terpstra, "Representation Of IP Routing Policies In
The RIPE Database", RIPE-081, February 1993,
<https://www.ripe.net/publications/docs/ripe-081>.
-->
<reference anchor="RIPE81" target="https://www.ripe.net/publications/doc s/ripe-081"> <reference anchor="RIPE81" target="https://www.ripe.net/publications/doc s/ripe-081">
<front> <front>
<title>Representation Of IP Routing Policies In The RIPE Database</t itle> <title>Representation Of IP Routing Policies In The RIPE Database</t itle>
<author> <author fullname="Tony Bates"/>
<organization>RIPE NCC</organization> <author fullname="Jean-Michel Jouanigot"/>
</author> <author fullname="Daniel Karrenberg"/>
<author fullname="Peter Lothberg"/>
<author fullname="Marten Terpstra"/>
<date month="February" year="1993"/> <date month="February" year="1993"/>
</front> </front>
<refcontent>RIPE-081</refcontent>
</reference> </reference>
<reference anchor="RIPE181" target="https://www.ripe.net/publications/do cs/ripe-181"> <reference anchor="RIPE181" target="https://www.ripe.net/publications/do cs/ripe-181">
<front> <front>
<title>Representation Of IP Routing Policies In A Routing Registry</ title> <title>Representation Of IP Routing Policies In A Routing Registry</ title>
<author> <author fullname="Tony Bates"/>
<organization>RIPE NCC</organization> <author fullname="Elise Gerich"/>
</author> <author fullname="Laurent Joncheray"/>
<author fullname="Jean-Michel Jouanigot"/>
<author fullname="Daniel Karrenberg"/>
<author fullname="Marten Terpstra"/>
<author fullname="Jessica Yu"/>
<date month="October" year="1994"/> <date month="October" year="1994"/>
</front> </front>
<refcontent>RIPE-181</refcontent>
</reference> </reference>
<reference anchor="RIPE-DB" target="https://www.ripe.net/manage-ips-and- asns/db/support/documentation/ripe-database-documentation"> <reference anchor="RIPE-DB" target="https://www.ripe.net/manage-ips-and- asns/db/support/documentation/ripe-database-documentation">
<front> <front>
<title>RIPE Database Documentation</title> <title>RIPE Database Documentation</title>
<author> <author>
<organization>RIPE NCC</organization> <organization>RIPE NCC</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<!-- [rfced] Regarding reference entries [INET6NUM] and [INETNUM]:
The original URLs for [INET6NUM] and [INETNUM] point to a page with an
"Sorry, we can't seem to find the page you're looking for" error
message.
We found the following URL that seems to contain the information from
the original URLs:
https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-of-Primary-Objects
Is this the appropriate URL for these references?
-->
<reference anchor="INETNUM" target="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-4-description-of-the-inetnum-object"> <reference anchor="INETNUM" target="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-4-description-of-the-inetnum-object">
<front> <front>
<title>Description of the INETNUM Object</title> <title>Description of the INETNUM Object</title>
<author> <author>
<organization>RIPE NCC</organization> <organization>RIPE NCC</organization>
</author> </author>
<date month="June" year="2020"/> <date month="June" year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="INET6NUM" target="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"> <reference anchor="INET6NUM" target="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">
<front> <front>
<title>Description of the INET6NUM Object</title> <title>Description of the INET6NUM Object</title>
<author> <author>
<organization>RIPE NCC</organization> <organization>RIPE NCC</organization>
</author> </author>
<date month="October" year="2019"/> <date month="October" year="2019"/>
</front> </front>
</reference> </reference>
<!-- [rfced] Regarding reference entry [PREFIXLEN-FINDER:] Please review. Refere
nces to GitHub
repositories require a commit hash (see:
https://www.rfc-editor.org/styleguide/part2/#ref_repo). The original
date for this reference - June 2021 - does not appear in this
repositories commit history
(https://github.com/massimocandela/prefixlen-finder/commits/main/). May
we update this reference to use the most recent commit date and commit
hash?
Current:
[PREFIXLEN-FINDER]
"prefixlen-finder", June 2021,
<https://github.com/massimocandela/prefixlen-finder>.
Perhaps:
[PREFIXLEN-FINDER]
"prefixlen-finder", commit fa70e6b, 3 June 2025,
<https://github.com/massimocandela/prefixlen-finder>.
-->
<reference anchor="PREFIXLEN-FINDER" target="https://github.com/massimoc andela/prefixlen-finder"> <reference anchor="PREFIXLEN-FINDER" target="https://github.com/massimoc andela/prefixlen-finder">
<front> <front>
<title>prefixlen-finder</title> <title>prefixlen-finder</title>
<author> <author>
<organization></organization> <organization/>
</author> </author>
<date month="June" year="2021"/> <date month="June" year="2021"/>
</front> </front>
</reference> </reference>
</references>
</references> </references>
<section anchor="asn1">
<section title="ASN.1 Module" anchor="asn1"> <name>ASN.1 Module</name>
<t> <t>
This appendix provides an ASN.1 Module <xref target="X680"/> for the This appendix provides an ASN.1 Module <xref target="X680"/> for the
CMS content type used for the prefixlen file.</t> CMS content type used for the prefixlen file.</t>
<t>
<t>
CONTENT-TYPE is imported from the ASN.1 Module in CONTENT-TYPE is imported from the ASN.1 Module in
<xref target="RFC6268" format="default"/>.</t> <xref target="RFC6268" format="default"/>.</t>
<sourcecode type="asn.1" markers="true"><![CDATA[
<t><sourcecode type="asn.1"><![CDATA[
<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]]></sourcecode>
<CODE ENDS>
]]></sourcecode></t>
</section> </section>
<section anchor="example">
<section title="Example" anchor="example"> <name>Example</name>
<t> <t>
This appendix provides an example, including a trust anchor, This appendix provides an example, including a trust anchor,
a CRL signed by the trust anchor, a CA certificate subordinate to a CRL signed by the trust anchor, a CA certificate subordinate to
the trust anchor, a CRL signed by the CA, an end-entity certificate the trust anchor, a CRL signed by the CA, an end-entity certificate
subordinate to the CA for signing the prefixlen file, and a detached subordinate to the CA for signing the prefixlen file, and a detached
signature.</t> signature.</t>
<t>
<t>
The trust anchor is represented by a self-signed certificate. As usual in The trust anchor is represented by a self-signed certificate. As usual in
the RPKI, the trust anchor has authority over all IPv4 address blocks, the RPKI, the trust anchor has authority over all IPv4 address blocks,
all IPv6 address blocks, and all Autonomous System (AS) numbers.</t> all IPv6 address blocks, and all Autonomous System (AS) numbers.</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIEQTCCAymgAwIBAgIUEggycNoFVRjAuN/Fw7URu0DEZNAwDQYJKoZIhvcNAQEL MIIEQTCCAymgAwIBAgIUEggycNoFVRjAuN/Fw7URu0DEZNAwDQYJKoZIhvcNAQEL
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMzA5MTkyMDMzMzlaFw0zMzA5 BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMzA5MTkyMDMzMzlaFw0zMzA5
MTYyMDMzMzlaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB MTYyMDMzMzlaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDQprR+g/i4JyObVURTp1JpGM23vGPyE5fDKFPqV7rw AQUAA4IBDwAwggEKAoIBAQDQprR+g/i4JyObVURTp1JpGM23vGPyE5fDKFPqV7rw
M1Amm7cnew66U02IzV0X5oiv5nSGfRX5UxsbR+vwPBMceQyDgS5lexFiv4fB/Vjf M1Amm7cnew66U02IzV0X5oiv5nSGfRX5UxsbR+vwPBMceQyDgS5lexFiv4fB/Vjf
DT2qX/UjsLL9QOeaSOh7ToJSLjmtpa0D9iz7ful3hdxRjpMMZiE/reX9/ymdpW/E DT2qX/UjsLL9QOeaSOh7ToJSLjmtpa0D9iz7ful3hdxRjpMMZiE/reX9/ymdpW/E
dg0F6+T9WGZE1miPeIjl5OZwnmLHCftkN/aaYk1iPNjNniHYIOjC1jSpABmoZyTj dg0F6+T9WGZE1miPeIjl5OZwnmLHCftkN/aaYk1iPNjNniHYIOjC1jSpABmoZyTj
sgrwLE2F1fIRkVkwASqToq/D5v9voXaYYaXUNJb4H/5wenRuvT5O/n6PXh70rMQy sgrwLE2F1fIRkVkwASqToq/D5v9voXaYYaXUNJb4H/5wenRuvT5O/n6PXh70rMQy
F5yzLs96ytxqg5gGX9kabVnvxFU8nHfPa0rhlwfTJnljAgMBAAGjggGHMIIBgzAd F5yzLs96ytxqg5gGX9kabVnvxFU8nHfPa0rhlwfTJnljAgMBAAGjggGHMIIBgzAd
skipping to change at line 1098 skipping to change at line 1077
ZXQvbm90aWZpY2F0aW9uLnhtbDAwBggrBgEFBQcwBYYkcnN5bmM6Ly9ycGtpLmV4 ZXQvbm90aWZpY2F0aW9uLnhtbDAwBggrBgEFBQcwBYYkcnN5bmM6Ly9ycGtpLmV4
YW1wbGUubmV0L3JlcG9zaXRvcnkvMCcGCCsGAQUFBwEHAQH/BBgwFjAJBAIAATAD YW1wbGUubmV0L3JlcG9zaXRvcnkvMCcGCCsGAQUFBwEHAQH/BBgwFjAJBAIAATAD
AwEAMAkEAgACMAMDAQAwIQYIKwYBBQUHAQgBAf8EEjAQoA4wDDAKAgEAAgUA//// AwEAMAkEAgACMAMDAQAwIQYIKwYBBQUHAQgBAf8EEjAQoA4wDDAKAgEAAgUA////
/zANBgkqhkiG9w0BAQsFAAOCAQEAa9eLY9QAmnlZOIyOzbpta5wqcOUQV/yR7o/0 /zANBgkqhkiG9w0BAQsFAAOCAQEAa9eLY9QAmnlZOIyOzbpta5wqcOUQV/yR7o/0
1zkEZaSavKBt19lMK6AXZurx1T5jyjIwG7bEtZZThjtH2m80V5kc2tsFjSq/yp7N 1zkEZaSavKBt19lMK6AXZurx1T5jyjIwG7bEtZZThjtH2m80V5kc2tsFjSq/yp7N
JBclMHVd3tXse9If3nXYF4bxRIcir1lXlAbYN+Eo1U3i5qJO+fxouzt7Merk2Dih JBclMHVd3tXse9If3nXYF4bxRIcir1lXlAbYN+Eo1U3i5qJO+fxouzt7Merk2Dih
nsenTeXKzN7tfmuCYZZHCC8viCoJWdH+o1uRM4TiQApZsUJ8sF4TABrrRJmA/Ed5 nsenTeXKzN7tfmuCYZZHCC8viCoJWdH+o1uRM4TiQApZsUJ8sF4TABrrRJmA/Ed5
v0CTBbgqTx7yg0+VarFLPdnjYgtpoCJqwE2C1UpX15rZSaLVuGXtbwXd/cHEg5vF v0CTBbgqTx7yg0+VarFLPdnjYgtpoCJqwE2C1UpX15rZSaLVuGXtbwXd/cHEg5vF
W6QTsMeMQFEUa6hkicDGtxLTUdhckBgmCGoF2nlZii5f1BTWAg== W6QTsMeMQFEUa6hkicDGtxLTUdhckBgmCGoF2nlZii5f1BTWAg==
-----END CERTIFICATE----- -----END CERTIFICATE-----
]]></artwork></figure> ]]></artwork>
<t>
<t>
The CRL issued by the trust anchor.</t> The CRL issued by the trust anchor.</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
-----BEGIN X509 CRL----- -----BEGIN X509 CRL-----
MIIBjjB4AgEBMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEX MIIBjjB4AgEBMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEX
DTI1MTIwNDEzNDgxMVoXDTI2MDEwMzEzNDgxMVqgLzAtMB8GA1UdIwQYMBaAFMC9 DTI1MTIwNDEzNDgxMVoXDTI2MDEwMzEzNDgxMVqgLzAtMB8GA1UdIwQYMBaAFMC9
Ul2+0niyFuyzo0OV0gYLmQgyMAoGA1UdFAQDAgELMA0GCSqGSIb3DQEBCwUAA4IB Ul2+0niyFuyzo0OV0gYLmQgyMAoGA1UdFAQDAgELMA0GCSqGSIb3DQEBCwUAA4IB
AQDLltErZwESHDSkwhnL++hFPAJUJf6NapOV9bzUBr5D6vLgs01dke3AFoUNJCng AQDLltErZwESHDSkwhnL++hFPAJUJf6NapOV9bzUBr5D6vLgs01dke3AFoUNJCng
15p5EPi7BZnZMx3b+My+Hh8jMOxloKBe6eeZ0impCw5ZveWGwe4u3vH3snl9QkjZ 15p5EPi7BZnZMx3b+My+Hh8jMOxloKBe6eeZ0impCw5ZveWGwe4u3vH3snl9QkjZ
Slz+zxaNidKl/9W5h4rjznwKD98//t75ACa9UFImsE53U5cXwUor0QKd3VDkKLVf Slz+zxaNidKl/9W5h4rjznwKD98//t75ACa9UFImsE53U5cXwUor0QKd3VDkKLVf
nivSzVPaC3hvN85wOXMgC/M3MwD5PCKJ/jEBDfEADfnUIXUbjys13ycH2mX3gBZa nivSzVPaC3hvN85wOXMgC/M3MwD5PCKJ/jEBDfEADfnUIXUbjys13ycH2mX3gBZa
svDot/HDgpcQVRZBJC4ecPy9aBfj8EEfmIwidQtS+4vyh7lrR9xKn8wUqvti3Ulx svDot/HDgpcQVRZBJC4ecPy9aBfj8EEfmIwidQtS+4vyh7lrR9xKn8wUqvti3Ulx
wYTdSdP9LWR+Ha7xdvSMJUiU wYTdSdP9LWR+Ha7xdvSMJUiU
-----END X509 CRL----- -----END X509 CRL-----
]]></artwork></figure> ]]></artwork>
<t>
<t>
The CA certificate is issued by the trust anchor. This The CA certificate is issued by the trust anchor. This
certificate grants authority over one IPv4 address block certificate grants authority over one IPv4 address block
(192.0.2.0/24), one IPv6 address block(2001:db8::/32), and (192.0.2.0/24), one IPv6 address block(2001:db8::/32), and
two AS numbers (64496 and 64497).</t> two AS numbers (64496 and 64497).</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIE+zCCA+OgAwIBAgIUcyCzS10hdfG65kbRq7toQAvRDMEwDQYJKoZIhvcNAQEL MIIE+zCCA+OgAwIBAgIUcyCzS10hdfG65kbRq7toQAvRDMEwDQYJKoZIhvcNAQEL
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yNTEyMDQxMzQ4MTFaFw0yNjEy BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yNTEyMDQxMzQ4MTFaFw0yNjEy
MDQxMzQ4MTFaMDMxMTAvBgNVBAMTKDNBQ0UyQ0VGNEZCMjFCN0QxMUUzRTE4NEVG MDQxMzQ4MTFaMDMxMTAvBgNVBAMTKDNBQ0UyQ0VGNEZCMjFCN0QxMUUzRTE4NEVG
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
skipping to change at line 1153 skipping to change at line 1128
b24ueG1sMDAGCCsGAQUFBzAFhiRyc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVw b24ueG1sMDAGCCsGAQUFBzAFhiRyc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVw
b3NpdG9yeS8wLgYIKwYBBQUHAQcBAf8EHzAdMAwEAgABMAYDBADAAAIwDQQCAAIw b3NpdG9yeS8wLgYIKwYBBQUHAQcBAf8EHzAdMAwEAgABMAYDBADAAAIwDQQCAAIw
BwMFACABDbgwIQYIKwYBBQUHAQgBAf8EEjAQoA4wDDAKAgMA+/ACAwD78TANBgkq BwMFACABDbgwIQYIKwYBBQUHAQgBAf8EEjAQoA4wDDAKAgMA+/ACAwD78TANBgkq
hkiG9w0BAQsFAAOCAQEAdgCV/G9f6NIC3MhqAqSoA56/7bJJ2QC3bChnwZH0MB3p hkiG9w0BAQsFAAOCAQEAdgCV/G9f6NIC3MhqAqSoA56/7bJJ2QC3bChnwZH0MB3p
VjYNhcY99ZFBv9TdsAd0GsPMEL4zGqvxkSQZjrJHSqe6GHJB5Kr4/SDbbyu6vylh VjYNhcY99ZFBv9TdsAd0GsPMEL4zGqvxkSQZjrJHSqe6GHJB5Kr4/SDbbyu6vylh
QPDNIBnH2o5iXU/34Klx3Wf42ttsi7DAhGcR6OOAR4UrO/7ng19oFXe3tBWDcVLf QPDNIBnH2o5iXU/34Klx3Wf42ttsi7DAhGcR6OOAR4UrO/7ng19oFXe3tBWDcVLf
Jd6Bqptp8fkfpSyHQEezZ0xA5h/SXeN+qvbL0rOJcI4+Ybbqa7U21+cz/JftAdgw Jd6Bqptp8fkfpSyHQEezZ0xA5h/SXeN+qvbL0rOJcI4+Ybbqa7U21+cz/JftAdgw
vatxQzGxl47HyvC7IpROI0+8jXB9xwOGKxznBve9/LeIZzMYBRuYV6jVWe4V6ja9 vatxQzGxl47HyvC7IpROI0+8jXB9xwOGKxznBve9/LeIZzMYBRuYV6jVWe4V6ja9
2crgaoDZaOH78JLjg3Qt+hVSQ667lak3QXZ1FVp1WA== 2crgaoDZaOH78JLjg3Qt+hVSQ667lak3QXZ1FVp1WA==
-----END CERTIFICATE----- -----END CERTIFICATE-----
]]></artwork></figure> ]]></artwork>
<t>
<t>
The CRL issued by the CA.</t> The CRL issued by the CA.</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
-----BEGIN X509 CRL----- -----BEGIN X509 CRL-----
MIIBrTCBlgIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEygzQUNFMkNFRjRG MIIBrTCBlgIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEygzQUNFMkNFRjRG
QjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyFw0yNTEyMDQxMzQ4MTFaFw0y QjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyFw0yNTEyMDQxMzQ4MTFaFw0y
NjAxMDMxMzQ4MTFaoC8wLTAfBgNVHSMEGDAWgBQ6zizvT7IbfRHj4YTvweKXs3eG NjAxMDMxMzQ4MTFaoC8wLTAfBgNVHSMEGDAWgBQ6zizvT7IbfRHj4YTvweKXs3eG
QjAKBgNVHRQEAwIBATANBgkqhkiG9w0BAQsFAAOCAQEAyxbVA6TeFHU8BqciB0q1 QjAKBgNVHRQEAwIBATANBgkqhkiG9w0BAQsFAAOCAQEAyxbVA6TeFHU8BqciB0q1
Of81r/Ux/PTKIyhpVznTcVxa4wodsQcaMVNKYxINHNwctCm901Rx3nO61BqZpvaL Of81r/Ux/PTKIyhpVznTcVxa4wodsQcaMVNKYxINHNwctCm901Rx3nO61BqZpvaL
XPdkstlnzG+WaHcfUj09sTx7Eb/r17J1EACr2p9dVq4fTpuw/+Nq7ecj80NM74z6 XPdkstlnzG+WaHcfUj09sTx7Eb/r17J1EACr2p9dVq4fTpuw/+Nq7ecj80NM74z6
uCiA5iyEjI0PYen4/IOgods0ceUm0QBOCTKNI3cbjZjiAfY9tRgqR1F2eeeproEM uCiA5iyEjI0PYen4/IOgods0ceUm0QBOCTKNI3cbjZjiAfY9tRgqR1F2eeeproEM
+ulVORW4yfivsMGMHApaeLVnUTnAln9YqnL7mQGMBrRIBwYi2dk76K++iQBhWEP0 +ulVORW4yfivsMGMHApaeLVnUTnAln9YqnL7mQGMBrRIBwYi2dk76K++iQBhWEP0
Ofv22y7UIbfqycrYROuJ9yGdwi5IAhpbKoQIzS5DimN+xykJdGPm0d2jUwNRibPh Ofv22y7UIbfqycrYROuJ9yGdwi5IAhpbKoQIzS5DimN+xykJdGPm0d2jUwNRibPh
GQ== GQ==
-----END X509 CRL----- -----END X509 CRL-----
]]></artwork></figure> ]]></artwork>
<t>
<t>
The end-entity certificate is issued by the CA. This The end-entity certificate is issued by the CA. This
certificate grants signature authority for one IPv4 address block certificate grants signature authority for one IPv4 address block
(192.0.2.0/24). Signature authority for the IPv6 address block (192.0.2.0/24). Signature authority for the IPv6 address block
and the AS numbers is not needed for the prefixlen file that will and the AS numbers is not needed for the prefixlen file that will
be signed, so these items are not included in the end-entity be signed, so these items are not included in the end-entity
certificate.</t> certificate.</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZvowDQYJKoZIhvcNAQEL MIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZvowDQYJKoZIhvcNAQEL
BQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdC BQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdC
Mzc3ODY0MjAeFw0yNTEyMDQxMzQ4MTFaFw0yNjA5MzAxMzQ4MTFaMDMxMTAvBgNV Mzc3ODY0MjAeFw0yNTEyMDQxMzQ4MTFaFw0yNjA5MzAxMzQ4MTFaMDMxMTAvBgNV
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
skipping to change at line 1208 skipping to change at line 1179
BzAChlByc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNF BzAChlByc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNF
RjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcB RjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcB
BwEB/wQQMA4wDAQCAAEwBgMEAMAAAjANBgkqhkiG9w0BAQsFAAOCAQEAwvEWPwHe BwEB/wQQMA4wDAQCAAEwBgMEAMAAAjANBgkqhkiG9w0BAQsFAAOCAQEAwvEWPwHe
VSFYwknmaOJrVeHrDez4BYg/uqpws0ny8LNUApsStUTrvsdkOMYVqJBifFpUtx7y VSFYwknmaOJrVeHrDez4BYg/uqpws0ny8LNUApsStUTrvsdkOMYVqJBifFpUtx7y
1hfEZDkDIP7TC78pYaiTR5WAxSv/dxr9GuGUNgx7YDmvOST9OAZvfEBrNtj7DC+Z 1hfEZDkDIP7TC78pYaiTR5WAxSv/dxr9GuGUNgx7YDmvOST9OAZvfEBrNtj7DC+Z
jumMNWxMdTkjsLswXmlUF7dZxQjt01w5Wf5aD/MlV87d6mX49A0rjuaeIRTMglUq jumMNWxMdTkjsLswXmlUF7dZxQjt01w5Wf5aD/MlV87d6mX49A0rjuaeIRTMglUq
EzqmnqSVTHVqtQwWlCG45ltS2Keu788RMnkiRDL2CJUoy8Axy5xcYSpf+keqFE13 EzqmnqSVTHVqtQwWlCG45ltS2Keu788RMnkiRDL2CJUoy8Axy5xcYSpf+keqFE13
UUyegHcBUEODfk8AP0hnc6YhXC6+oBz72HbgYqTYyjQNYGS+49b58u5nXWqJoMJm UUyegHcBUEODfk8AP0hnc6YhXC6+oBz72HbgYqTYyjQNYGS+49b58u5nXWqJoMJm
yxybgehJbawpCA== yxybgehJbawpCA==
-----END CERTIFICATE----- -----END CERTIFICATE-----
]]></artwork></figure> ]]></artwork>
<t>
<t>
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.</t> brevity, the other two certificates are not.</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
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 FA
35 13: SEQUENCE { 35 13: SEQUENCE {
37 9: OBJECT IDENTIFIER 37 9: OBJECT IDENTIFIER
skipping to change at line 1396 skipping to change at line 1365
: BB 30 5E 69 54 17 B7 59 C5 08 ED D3 5C 39 59 FE : BB 30 5E 69 54 17 B7 59 C5 08 ED D3 5C 39 59 FE
: 5A 0F F3 25 57 CE DD EA 65 F8 F4 0D 2B 8E E6 9E : 5A 0F F3 25 57 CE DD EA 65 F8 F4 0D 2B 8E E6 9E
: 21 14 CC 82 55 2A 13 3A A6 9E A4 95 4C 75 6A B5 : 21 14 CC 82 55 2A 13 3A A6 9E A4 95 4C 75 6A B5
: 0C 16 94 21 B8 E6 5B 52 D8 A7 AE EF CF 11 32 79 : 0C 16 94 21 B8 E6 5B 52 D8 A7 AE EF CF 11 32 79
: 22 44 32 F6 08 95 28 CB C0 31 CB 9C 5C 61 2A 5F : 22 44 32 F6 08 95 28 CB C0 31 CB 9C 5C 61 2A 5F
: FA 47 AA 14 4D 77 51 4C 9E 80 77 01 50 43 83 7E : FA 47 AA 14 4D 77 51 4C 9E 80 77 01 50 43 83 7E
: 4F 00 3F 48 67 73 A6 21 5C 2E BE A0 1C FB D8 76 : 4F 00 3F 48 67 73 A6 21 5C 2E BE A0 1C FB D8 76
: E0 62 A4 D8 CA 34 0D 60 64 BE E3 D6 F9 F2 EE 67 : E0 62 A4 D8 CA 34 0D 60 64 BE E3 D6 F9 F2 EE 67
: 5D 6A 89 A0 C2 66 CB 1C 9B 81 E8 49 6D AC 29 08 : 5D 6A 89 A0 C2 66 CB 1C 9B 81 E8 49 6D AC 29 08
: } : }
]]></artwork></figure> ]]></artwork>
<t>
<t>
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 private key is provided. For brevity, the other two private
keys are not.</t> keys are not.</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
-----BEGIN RSA PRIVATE KEY----- -----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEAsnE0Kzm/6gdlt4tyovD4QPwxFsootk4BqPaYAsDvZbCESOmW MIIEpQIBAAKCAQEAsnE0Kzm/6gdlt4tyovD4QPwxFsootk4BqPaYAsDvZbCESOmW
/5Pmkollj/ZEnM5XEILTwlcK+toU0GQiKMATdAS9HCtP+ZNYpiXYuanTN57yrMDP /5Pmkollj/ZEnM5XEILTwlcK+toU0GQiKMATdAS9HCtP+ZNYpiXYuanTN57yrMDP
Ap6EddbwfKUBcK7mZq+caYV0bxPps7iVS4LtldbqZgV7lpaHsprnYellifhg48D1 Ap6EddbwfKUBcK7mZq+caYV0bxPps7iVS4LtldbqZgV7lpaHsprnYellifhg48D1
zt0YlwXowazhTV4WhS3tPMuAz36/0v7VyTgZu0M0KbZmzy2LRn6a2LuOZYhRaqj/ zt0YlwXowazhTV4WhS3tPMuAz36/0v7VyTgZu0M0KbZmzy2LRn6a2LuOZYhRaqj/
eFHi6SEn13d+gChs6kxQnHNxFvZeVBRNTBS5Z6BKIKraC6CgAbdCJDhRingvxIHm eFHi6SEn13d+gChs6kxQnHNxFvZeVBRNTBS5Z6BKIKraC6CgAbdCJDhRingvxIHm
gXVi3uOvXXQva0H7ecOoOnJsRvmmA3SBAd+M6wIDAQABAoIBAQCyB0FeMuKm8bRo gXVi3uOvXXQva0H7ecOoOnJsRvmmA3SBAd+M6wIDAQABAoIBAQCyB0FeMuKm8bRo
18aKjFGSPEoZi53srIz5bvUgIi92TBLez7ZnzL6Iym26oJ+5th+lCHGO/dqlhXio 18aKjFGSPEoZi53srIz5bvUgIi92TBLez7ZnzL6Iym26oJ+5th+lCHGO/dqlhXio
pI50C5Yc9TFbblb/ECOsuCuuqKFjZ8CD3GVsHozXKJeMM+/o5YZXQrORj6UnwT0z pI50C5Yc9TFbblb/ECOsuCuuqKFjZ8CD3GVsHozXKJeMM+/o5YZXQrORj6UnwT0z
ol/JE5pIGUCIgsXX6tz9s5BP3lUAvVQHsv6+vEVKLxQ3wj/1vIL8O/CN036EV0GJ ol/JE5pIGUCIgsXX6tz9s5BP3lUAvVQHsv6+vEVKLxQ3wj/1vIL8O/CN036EV0GJ
skipping to change at line 1431 skipping to change at line 1398
FGSli+3KxQhCNIJJfgWzq4bE0ioAMjdGbYXzIYQFAoGBAM6tuDJ36KDU+hIS6wu6 FGSli+3KxQhCNIJJfgWzq4bE0ioAMjdGbYXzIYQFAoGBAM6tuDJ36KDU+hIS6wu6
O2TPSfZhF/zPo3pCWQ78/QDb+Zdw4IEiqoBA7F4NPVLg9Y/H8UTx9r/veqe7hPOo O2TPSfZhF/zPo3pCWQ78/QDb+Zdw4IEiqoBA7F4NPVLg9Y/H8UTx9r/veqe7hPOo
Ok7NpIzSmKTHkc5XfZ60Zn9OLFoKbaQ40a1kXoJdWEu2YROaUlAe9F6/Rog6PHYz Ok7NpIzSmKTHkc5XfZ60Zn9OLFoKbaQ40a1kXoJdWEu2YROaUlAe9F6/Rog6PHYz
vLE5qscRbu0XQhLkN+z7bg5bAoGBAKDsbDEb/dbqbyaAYpmwhH2sdRSkphg7Niwc vLE5qscRbu0XQhLkN+z7bg5bAoGBAKDsbDEb/dbqbyaAYpmwhH2sdRSkphg7Niwc
DNm9qWa1J6Zw1+M87I6Q8naRREuU1IAVqqWHVLr/ROBQ6NTJ1Uc5/qFeT2XXUgkf DNm9qWa1J6Zw1+M87I6Q8naRREuU1IAVqqWHVLr/ROBQ6NTJ1Uc5/qFeT2XXUgkf
taMKv61tuyjZK3sTmznMh0HfzUpWjEhWnCEuB+ZYVdmO52ZGw2A75RdrILL2+9Dc taMKv61tuyjZK3sTmznMh0HfzUpWjEhWnCEuB+ZYVdmO52ZGw2A75RdrILL2+9Dc
PvDXVubRAoGAdqXeSWoLxuzZXzl8rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ PvDXVubRAoGAdqXeSWoLxuzZXzl8rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ
E3ng2j5XPTUWli+aNGFEJGRoNtcQvO60O/sFZUhu52sqq9mWVYZNh1TB5aP8X+pV E3ng2j5XPTUWli+aNGFEJGRoNtcQvO60O/sFZUhu52sqq9mWVYZNh1TB5aP8X+pV
iFcZOLUvQEcN6PA+YQK5FU11rAI1M0Gm5RDnVnUl0L2xfCYxb7FzV6Y= iFcZOLUvQEcN6PA+YQK5FU11rAI1M0Gm5RDnVnUl0L2xfCYxb7FzV6Y=
-----END RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----
]]></artwork></figure> ]]></artwork>
<t>
<t>
Signing of "192.0.2.0/24,32,1" (terminated by CR and LF), Signing of "192.0.2.0/24,32,1" (terminated by CR and LF),
yields the following detached CMS signature.</t> yields the following detached CMS signature.</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
# RPKI Signature: 192.0.2.0 - 192.0.2.255 # RPKI Signature: 192.0.2.0 - 192.0.2.255
# MIIGQAYJKoZIhvcNAQcCoIIGMTCCBi0CAQMxDTALBglghkgBZQMEAgEwDQYLKoZ # MIIGQAYJKoZIhvcNAQcCoIIGMTCCBi0CAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
# IhvcNAQkQAS+gggRaMIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZv # IhvcNAQkQAS+gggRaMIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZv
# owDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR # owDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR
# TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yNTEyMDQxMzQ4MTFaFw0yNjA5MzAx # TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yNTEyMDQxMzQ4MTFaFw0yNjA5MzAx
# MzQ4MTFaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM # MzQ4MTFaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM
# 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT # 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT
# QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg # QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg
# tPCVwr62hTQZCIowBN0BL0cK0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZm # tPCVwr62hTQZCIowBN0BL0cK0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZm
# r5xphXRvE+mzuJVLgu2V1upmBXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXha # r5xphXRvE+mzuJVLgu2V1upmBXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXha
skipping to change at line 1474 skipping to change at line 1439
# mAgEDgBSRRlKjvVHBRCYBmIifXEWr8FOhhzALBglghkgBZQMEAgGgazAaBgkqhk # mAgEDgBSRRlKjvVHBRCYBmIifXEWr8FOhhzALBglghkgBZQMEAgGgazAaBgkqhk
# 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
]]></artwork></figure> ]]></artwork>
</section>
<section anchor="acks" numbered="false">
<name>Acknowledgments</name>
<t>
Thanks to the authors of <xref target="RFC8805"/> and <xref target="RFC9
632"/> and the folk
they acknowledge from whom ideas and text have been liberally
expropriated. Thanks to <contact fullname="John R. Levine"/> for providi
ng useful
feedback on the document.
</t>
</section> </section>
<!--[rfced] We had the following questions/comments related to
abbreviation use throughout the document:
a) May we expand CRL as Certificate Revocation List per RFC 5280?
b) FYI - we have removed subsequent expansions of abbreviations per
the guidance at
https://www.rfc-editor.org/styleguide/part2/#exp_abbrev.
-->
<!--[rfced] We had the following questions/comments related to terminology used
throughout the document:
a) we have used the hyphenated end-site throughout; please let us know any objec
tions.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 232 change blocks. 
629 lines changed or deleted 679 lines changed or added

This html diff was produced by rfcdiff 1.48.