Fastly

NL job@fastly.com

OpenBSD

CH tb@openbsd.org

ops RPKI security cryptography X.509 This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to publicly-trusted Trust Anchors (TAs), as implemented in OpenBSD's rpki-client validator. The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope.

Introduction This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to publicly-trusted Trust Anchors (TAs), as implemented in the validator. The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. It is important to emphasize that each Relying Party makes its Trust Anchor inclusion decisions independently, on its own timelines, based on its own inclusion criteria; and that imposed Constraints (if any) are a matter of local configuration. This document is intended to address user (meaning, Network Operator and Relying Party) needs and concerns, and was authored to benefit users and providers of RPKI services by providing a common body of knowledge to be communicated within the global Internet routing system community.

Definitions

Assumed Trust

In the RPKI hierarchical structure, a Trust Anchor is an authority for which trust is assumed and not derived. Assuming trust means that violation of that trust is out-of-scope for the threat model.

Derived Trust

Derived Trust can be automatically and securely computed with subjective logic. In the context of the RPKI, trust is derived according to the rules for validation of RPKI Certificates and Signed Objects.

Constraints

The locally configured union set of IP prefixes, IP address ranges, AS identifiers, and AS identifier ranges for which the Relying Party operator anticipates the Trust Anchor operator to issue cryptographic products.

Required Reading Readers should be familiar with the RPKI, the RPKI repository structure, and the various RPKI objects, uses, and interpretations described in the following: , , , , and .

Considerations on Trust Anchor over-claiming Currently, all five Regional Internet Registries (RIRs) list 'all-resources' (0.0.0.0/0, ::/0, and AS 0-4294967295) as subordinate on their Trust Anchor certificates in order to reduce some potential for risk of invalidation in the case of transient registry inconsistencies . Such 'all-resources' listings demonstrate that - in the course of normal operations - Trust Anchors may claim authority for INRs outside the registry's current resource holdings. The primary reason for transient registry inconsistencies to occur would be when resources are transferred from one registry to another. However, the ability to transfer resources between registries is not universally available: this ability depends on the implementation of registry-specific consensus-driven policy development reciprocated by other registries. Another source of churn would be the inflow of new resources following allocations made by the IANA; but because of IPv4 address exhaustion, IPv6 abundance, and 32-bit ASNs being allocated in large blocks - IANA allocations occur far less often than they used to. Absent a registry's ability to execute inter-registry transfers or frequently receive new allocations from IANA, that registry's set of holdings would be a fairly static list of resources. Therefore, a Relying Party need not trust each and every signed product in a derived trust relationship to any and all INRs subordinate to the registry's Trust Anchor, even when the Trust Anchor certificate lists 'all-resources' as subordinate. Following the widely deployed information security principle of least privilege, constraining a given Trust Anchor's capacity strictly to just that what relates to the their respective current INR holdings, provides some degree of risk reduction for all stakeholders involved. Consequently, knowing a registry's current resource holdings and knowing this set of holdings will not change in the near-term future; following the principle of least privilege, operators can consider applying a restricted-service operating mode towards what otherwise would be an unbounded authority. The principle of constraining Trust Anchors might be useful when for example working with RPKI testbeds , risky Trust Anchors which cover unallocated space with AS0 ROAs , but also in dealings with publicly-trusted registries.

Constraining Trust Anchors by constraining End-Entity Certificates As noted in , publicly-trusted RPKI TA certificates are expected to overclaim in the course of normal operations. However, applying a bespoke implementation of the certification path validation algorithm to CA certificates to prune all possible certificate paths related to INRs not contained within the locally configured Constraints would not be a trivial task. Instead, an alternative and simpler approach operating on EE certificates is proposed. To constrain a Trust Anchor, the IP address and AS number resources listed in a given EE certificate's extensions MUST be fully contained within the locally configured union set of IP prefixes, IP address ranges, AS identifiers, and AS identifier ranges for which the Relying Party operator anticipates the Trust Anchor operator to issue cryptographic products. If a given EE certificate's listed resources are not fully contained within the Constraints, the RP should halt processing and consider the EE certificate invalid. The above described approach applies to all RPKI objects for which an explicit listing of resources is mandated in their respective extensions; such as BGPSec Router Certificates , ROAs , ASPAs , RSCs , and Geofeeds . The approach has no application in context of Signed Objects unrelated to INRs (which thus use 'inherit' elements); such as Ghostbusters records , Signed TALs , and Manifests . The validation of Constraint containment is a check in addition to all the validation checks specified in , , and each Signed Object's profile specification.

Operational Considerations When assessing the feasibility of constraining a Trust Anchor's effective signing abilities to the registry's current set of holdings, it is important to take note of existing policies (or lack thereof) and possible future events which might impact the degree of churn in the registry's holdings. Examples are: The ARIN policy development community abandoned a proposal to allow inter-regional IPv6 resource transfers . Since it's currently not possible to transfer IPv6 resources from ARIN to any other RIR, ARIN's IANA-allocated IPv6 resources should not appear subordinate to any Trust Anchor other than ARIN's own Trust Anchor. The APNIC policy development community has not developed policy to support inter-RIR IPv6 transfers. The LACNIC policy development community has not developed policy to support inter-RIR IPv6 transfers. The RIPE NCC policy development community has not developed policy to support inter-RIR IPv6 transfers. AFRINIC has not ratified an inter-registry transfer policy . The policy proposal indicates implementation is expected to take an additional 12 months after ratification. Since it's not possible to transfer resources into AFRINIC, non-AFRINIC resources should not appear subordinate to AFRINIC's Trust Anchor for the foreseeable future. The RIRs collectively manage only a subset of 0.0.0.0/0 and 2000::/3 ; and have no authority over any parts of 10.0.0.0/8 , 2001:db8::/32 , and AS 64512 - 65534 , for example. Since it's not possible to transfer private internet allocations, documentation prefixes, or private use ASNs into an RIR's management, such resources should not appear subordinate to any RIR's Trust Anchor. In recent times IANA has not made allocations from the Current Recovered IPv4 Pool , and Autonomous System Number allocations are also fairly infrequent . The aforementioned observations suggest there is a lot of operational runway to manage and distribute Trust Anchor Constraints in a timely manner. Maintainers of Constraint lists disseminated as part of an operating system or a third-party software package release process would do well to assume a six month delay for users to update.

Security Considerations The routing security benefits promised by the RPKI are derived from assuming trust in registry operators to run flawless certification services. Assuming such trust exposes users to some potential for and adverse actions by Certificate Authorities . Restricting a Trust Anchor's effective signing abilities to its respective registry's current holdings - rather assuming unbounded trust in such authorities - is a constructive approach to limit some potential for risk.

References Informative References ARIN LACNIC AFRINIC RIPE NCC APNIC This document provides an applicability statement for the use of multiple, over-claiming 'all resources' (0/0) RPKI certificate authorities (CA) certificates used as trust anchors (TAs) operated by the Regional Internet Registry community to help mitigate the risk of massive downstream invalidation in the case of transient registry inconsistencies. Fastly Workonline Carleton College Raytheon Independent This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482. Yandex JetLend Internet Initiative Japan Fastly Vigil Security, LLC Workonline This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its upstream providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. IIJ & Arrcus NTT Google Vigil Security, LLC This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure to authenticate the geofeed data files. This document obsoletes RFC 9092. LACNIC Asia Pacific Network Information Centre Asia Pacific Network Information Centre NLnet Labs Dragon Research Labs A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate a Trust Anchor (TA) Certification Authority (CA) certificate used in RPKI validation. This document defines an RPKI signed object for a Trust Anchor Key (TAK), that can be used by a TA to signal the location(s) of the accompanying CA certificate for the current key to RPs, as well as the successor key and the location(s) of its CA certificate. This object helps to support planned key rolls without impacting RPKI validation. This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK] To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation. This memo provides information for the Internet community. This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK] This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK] This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK] In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This document describes the RPKI Ghostbusters Record containing human contact information that may be verified (indirectly) by a Certification Authority (CA) certificate. The data in the record are those of a severely profiled vCard. [STANDARDS- TRACK] This document describes the reservation of Autonomous System Numbers (ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 of that document. This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end entity (EE) certificates specified by this profile are issued to routers within an AS. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Resource extension. An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this document updates the RPKI Resource Certificates Profile (RFC 6487). This document analyzes actions by or against a Certification Authority (CA) or an independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository manager) and fetched by Relying Parties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data. This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects. This document obsoletes RFC 6486. This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry a general-purpose listing of checksums (a 'checklist'). The objective is to allow for the creation of an attestation, termed an "RPKI Signed Checklist (RSC)", which contains one or more checksums of arbitrary digital objects (files) that are signed with a specific set of Internet Number Resources. When validated, an RSC confirms that the respective Internet resource holder produced the RSC.

Example listings of Constraints This section contains examples of Constraints listings related to ARIN & AFRINIC managed INRs, and INRs allocated for private or non-public use. Constraint suggestions are offered specific to each of the five RIR Trust Anchors. As it's clumsy and error prone to calculate the complement of a block of resources, for efficiency a simple notation in the form of allow and deny keywords is used to indicate INRs which may or may not appear subordinate to a Trust Anchor (rather than merely using lengthy exhaustive allowlists of what INRs may appear under a given Trust Anchor). Denylist entries (entries prefixed with deny) take precedence over allowlist entries (entries prefixed with allow). Denylist entries may not overlap with other denylist entries. Allowlist entries may not overlap with other allowlist entries. The ordering of entries is not significant.

Constraints applicable to AFRINIC's Trust Anchor The below listing is intended to be an exhaustive list of Constraints related to AFRINIC-managed Internet Number Resources. Inter-RIR resource transfers aren't possible into and out of the AFRINIC registry. By placing the below contents in a file named afrinic.constraints next to a Trust Anchor Locator file named afrinic.tal, the implementation will consider all End-Entity certificates invalid which list resources not fully contained within the resources listed in the afrinic.constraints file. # From https://www.iana.org/assignments/ipv4-address-space/ allow 41.0.0.0/8 allow 102.0.0.0/8 allow 105.0.0.0/8 allow 154.0.0.0/8 allow 196.0.0.0/7 # From https://www.iana.org/assignments/ipv6-address-space/ allow 2001:4200::/23 allow 2c00::/12 # From https://www.iana.org/assignments/as-numbers/ allow 36864 - 37887 allow 327680 - 328703 allow 328704 - 329727 # Holes deny 154.1.0.0/16 # ARIN deny 154.2.0.0/15 # ARIN deny 154.4.0.0/14 # ARIN deny 154.8.0.0 - 154.8.47.255 # RIPE deny 154.8.48.0 - 154.8.255.255 # APNIC deny 154.9.0.0/16 # ARIN deny 154.10.0.0/16 # APNIC deny 154.11.0.0/16 # ARIN deny 154.12.0.0/15 # ARIN deny 154.14.0.0/15 # RIPE deny 154.17.0.0/16 # ARIN deny 154.18.0.0/15 # ARIN deny 154.20.0.0/14 # ARIN deny 154.24.0.0/13 # ARIN deny 154.32.0.0/16 # RIPE deny 154.33.0.0 - 154.34.255.255 # APNIC deny 154.35.0.0/16 # ARIN deny 154.36.0.0/14 # ARIN deny 154.40.0.0/13 # ARIN deny 154.48.0.0/12 # ARIN deny 154.64.0.0/16 # ARIN deny 196.1.1.0/24 # APNIC deny 196.1.68.0/24 # APNIC deny 196.1.104.0 - 196.1.106.255 # APNIC deny 196.1.108.0/22 # APNIC deny 196.1.113.0 - 196.1.114.255 # APNIC deny 196.1.134.0/24 # APNIC deny 196.3.65.0/24 # APNIC deny 196.3.72.0/24 # APNIC deny 196.12.32.0/19 # APNIC deny 196.15.16.0/20 # APNIC deny 196.29.64.0/19 # LACNIC deny 196.32.32.0/19 # LACNIC deny 196.32.64.0/19 # LACNIC deny 196.40.0.0 - 196.40.95.255 # LACNIC # From https://www.iana.org/assignments/ipv4-recovered-address-space allow 45.96.0.0 - 45.111.255.255 allow 45.192.0.0 - 45.222.255.255 allow 45.240.0.0 - 45.247.255.255 allow 66.251.128.0 - 66.251.191.255 allow 139.26.0.0 - 139.26.255.255 allow 146.196.128.0 - 146.196.255.255 # 154.16.0.0 - 154.16.255.255 # already contained within 154/8 allow 160.19.36.0 - 160.19.39.255 allow 160.19.60.0 - 160.19.63.255 allow 160.19.96.0 - 160.19.103.255 allow 160.19.112.0 - 160.19.143.255 allow 160.19.152.0 - 160.19.155.255 allow 160.19.188.0 - 160.19.191.255 allow 160.19.192.0 - 160.19.199.255 allow 160.19.232.0 - 160.19.239.255 allow 160.20.24.0 - 160.20.31.255 allow 160.20.112.0 - 160.20.115.255 allow 160.20.213.0 - 160.20.213.255 allow 160.20.217.0 - 160.20.217.255 allow 160.20.221.0 - 160.20.221.255 allow 160.20.226.0 - 160.20.227.255 allow 160.20.252.0 - 160.20.255.255 allow 160.238.11.0 - 160.238.11.255 allow 160.238.48.0 - 160.238.49.255 allow 160.238.50.0 - 160.238.50.255 allow 160.238.57.0 - 160.238.57.255 allow 160.238.101.0 - 160.238.101.255 allow 161.123.0.0 - 161.123.255.255 allow 164.160.0.0 - 164.160.255.255 allow 192.12.110.0 - 192.12.111.255 allow 192.12.116.0 - 192.12.117.255 allow 192.47.36.0 - 192.47.36.255 allow 192.51.240.0 - 192.51.240.255 allow 192.70.200.0 - 192.70.201.255 allow 192.75.236.0 - 192.75.236.255 allow 192.83.208.0 - 192.83.215.255 allow 192.91.200.0 - 192.91.200.255 allow 192.142.0.0 - 192.143.255.255 allow 192.145.128.0 - 192.145.191.255 allow 192.145.230.0 - 192.145.230.255 allow 204.8.204.0 - 204.8.207.255 allow 208.85.156.0 - 208.85.159.255 # From https://web.archive.org/web/20131120040037/http://www.ripe.net/lir-services/resource-management/erx/transferred-resources # From https://afrinic.net/fr/library/policies/220-erx-transfer allow 2561 allow 3208 allow 5536 allow 6127 allow 6713 allow 6879 allow 8524 allow 8770 allow 9129 allow 11380 allow 12455 allow 12556 allow 13224 allow 15399 allow 13569 allow 15475 allow 15706 allow 15804 allow 15825 allow 15834 allow 15964 allow 16058 allow 16214 allow 16284 allow 16853 allow 16907 allow 17652 allow 19676 allow 20294 allow 20484 allow 20858 allow 20928 allow 21003 allow 21152 allow 21242 allow 21271 allow 21278 allow 21280 allow 21391 allow 21452 allow 23549 allow 23889 allow 24736 allow 24757 allow 24788 allow 24801 allow 24835 allow 24863 allow 24878 allow 24987 allow 25163 allow 25250 allow 25362 allow 25364 allow 25543 allow 25568 allow 25576 allow 28683 allow 28698 allow 28913 allow 29091 allow 29338 allow 29340 allow 29428 allow 29495 allow 29544 allow 29571 allow 29614 allow 29674 allow 30896 allow 31065 allow 31245 allow 31619 allow 83.143.24.0 - 83.143.31.255 allow 84.205.96.0 - 84.205.127.255 allow 131.176.0.0 - 131.176.255.255 allow 163.121.0.0 - 163.121.255.255 allow 165.231.0.0 - 165.231.255.255 allow 192.52.232.0 - 192.52.232.255 allow 193.17.215.0 - 193.17.215.255 allow 193.19.232.0 - 193.19.235.255 allow 193.41.146.0 - 193.41.147.255 allow 193.108.23.0 - 193.108.23.255 allow 193.108.28.0 - 193.108.28.255 allow 193.109.66.0 - 193.109.67.255 allow 193.110.104.0 - 193.110.105.255 allow 193.194.128.0 - 193.194.128.255 allow 193.227.128.0 - 193.227.128.255 allow 194.9.64.0 - 194.9.65.255 allow 194.9.82.0 - 194.9.83.255 allow 195.24.80.0 - 195.24.87.255 allow 195.39.218.0 - 195.39.219.255 allow 195.234.120.0 - 195.234.123.255 allow 195.234.168.0 - 195.234.168.255 allow 195.234.185.0 - 195.234.185.255 allow 195.234.252.0 - 195.234.255.255 # From https://www.ripe.net/participate/internet-governance/internet-technical-community/the-rir-system/afrinic/ripe-ncc-to-afrinic-transition allow 30980 allow 30982 - 30999 # From https://afrinic.net/ast/pdf/afrinic-whois-audit-report-full-20210121.pdf # 12.3 Appendix A3 allow 193.188.7.0/24 allow 193.189.0.0/18 allow 193.189.128.0/24 allow 193.194.160.0/19 allow 193.221.218.0/24 # From https://ftp.arin.net/afrinic/afrinic-transfers-by-resource.txt # Feb 21, 2005 allow 1228 - 1232 allow 2018 allow 2905 allow 3067 allow 3068 allow 3741 allow 4178 allow 4571 allow 5713 allow 5734 allow 6083 allow 6089 allow 6149 allow 6180 allow 6187 allow 6351 allow 6529 allow 6560 allow 6968 allow 7020 allow 7154 allow 7231 allow 7390 allow 7420 allow 7460 allow 7971 allow 7972 allow 8094 allow 10247 allow 10262 allow 10331 allow 10393 allow 10474 allow 10505 allow 10540 allow 10575 allow 10798 allow 10803 allow 10898 allow 10922 allow 11125 allow 11157 allow 11201 allow 11259 allow 11265 allow 11569 allow 11645 allow 11744 allow 11845 allow 11909 allow 12091 allow 12143 allow 12258 allow 13402 allow 13519 allow 13854 allow 14029 allow 14115 allow 14331 allow 14360 allow 14429 allow 14516 allow 14988 allow 15022 allow 15159 allow 16416 allow 16547 allow 16630 allow 16637 allow 16800 allow 17148 allow 17220 allow 17260 allow 17312 allow 17400 allow 18775 allow 18922 allow 18931 allow 19136 allow 19232 allow 19711 allow 19832 allow 19847 allow 20011 allow 20086 allow 20095 allow 20180 allow 20459 allow 21739 allow 21819 allow 22354 allow 22355 allow 22386 allow 22572 allow 22690 allow 22735 allow 22750 allow 22939 allow 23058 allow 25695 allow 25726 allow 25793 allow 25818 allow 26106 allow 26130 allow 26422 allow 26625 allow 26754 allow 27576 allow 27598 allow 29918 allow 29975 allow 30073 allow 30306 allow 30429 allow 30619 allow 31810 allow 31856 allow 31960 allow 32017 allow 32279 allow 32398 allow 32437 allow 32653 allow 32714 allow 32717 allow 32842 allow 32860 allow 33567 allow 33579 allow 33762 - 33791 allow 64.57.112.0 - 64.57.127.255 allow 66.8.0.0 - 66.8.127.255 allow 66.18.64.0 - 66.18.95.255 allow 69.63.64.0 - 69.63.79.255 allow 69.67.32.0 - 69.67.47.255 allow 137.158.0.0 - 137.158.255.255 allow 137.214.0.0 - 137.214.255.255 allow 137.215.0.0 - 137.215.255.255 allow 139.53.0.0 - 139.53.255.255 allow 143.128.0.0 - 143.128.255.255 allow 143.160.0.0 - 143.160.255.255 allow 146.64.0.0 - 146.64.255.255 allow 146.141.0.0 - 146.141.255.255 allow 146.182.0.0 - 146.182.255.255 allow 146.230.0.0 - 146.230.255.255 allow 146.231.0.0 - 146.231.255.255 allow 146.232.0.0 - 146.232.255.255 allow 147.110.0.0 - 147.110.255.255 allow 152.106.0.0 - 152.106.255.255 allow 152.107.0.0 - 152.107.255.255 allow 152.108.0.0 - 152.108.255.255 allow 152.109.0.0 - 152.109.255.255 allow 152.110.0.0 - 152.110.255.255 allow 152.111.0.0 - 152.111.255.255 allow 152.112.0.0 - 152.112.255.255 allow 155.159.0.0 - 155.159.255.255 allow 155.232.0.0 - 155.232.255.255 allow 155.233.0.0 - 155.233.255.255 allow 155.234.0.0 - 155.234.255.255 allow 155.235.0.0 - 155.235.255.255 allow 155.236.0.0 - 155.236.255.255 allow 155.237.0.0 - 155.237.255.255 allow 155.238.0.0 - 155.238.255.255 allow 155.239.0.0 - 155.239.255.255 allow 155.240.0.0 - 155.240.255.255 allow 156.8.0.0 - 156.8.255.255 allow 160.115.0.0 - 160.115.255.255 allow 160.116.0.0 - 160.116.255.255 allow 160.117.0.0 - 160.117.255.255 allow 160.118.0.0 - 160.118.255.255 allow 160.119.0.0 - 160.119.255.255 allow 160.120.0.0 - 160.120.255.255 allow 160.121.0.0 - 160.121.255.255 allow 160.122.0.0 - 160.122.255.255 allow 160.123.0.0 - 160.123.255.255 allow 160.124.0.0 - 160.124.255.255 allow 163.195.0.0 - 163.195.255.255 allow 163.196.0.0 - 163.196.255.255 allow 163.197.0.0 - 163.197.255.255 allow 163.198.0.0 - 163.198.255.255 allow 163.199.0.0 - 163.199.255.255 allow 163.200.0.0 - 163.200.255.255 allow 163.201.0.0 - 163.201.255.255 allow 163.202.0.0 - 163.202.255.255 allow 163.203.0.0 - 163.203.255.255 allow 164.88.0.0 - 164.88.255.255 allow 164.146.0.0 - 164.151.255.255 allow 164.155.0.0 - 164.155.255.255 allow 165.3.0.0 - 165.5.255.255 allow 165.8.0.0 - 165.11.255.255 allow 165.25.0.0 - 165.25.255.255 allow 165.143.0.0 - 165.149.255.255 allow 165.165.0.0 - 165.165.255.255 allow 165.180.0.0 - 165.180.255.255 allow 165.233.0.0 - 165.233.255.255 allow 166.85.0.0 - 166.85.255.255 allow 168.76.0.0 - 168.76.255.255 allow 168.80.0.0 - 168.81.255.255 allow 168.89.0.0 - 168.89.255.255 allow 168.128.0.0 - 168.128.255.255 allow 168.142.0.0 - 168.142.255.255 allow 168.155.0.0 - 168.155.255.255 allow 168.164.0.0 - 168.164.255.255 allow 168.167.0.0 - 168.167.255.255 allow 168.172.0.0 - 168.172.255.255 allow 168.206.0.0 - 168.206.255.255 allow 168.209.0.0 - 168.210.255.255 allow 169.129.0.0 - 169.129.255.255 allow 169.202.0.0 - 169.202.255.255 allow 192.33.10.0 - 192.33.10.255 allow 192.42.99.0 - 192.42.99.255 allow 192.48.253.0 - 192.48.253.255 allow 192.68.138.0 - 192.68.138.255 allow 192.70.237.0 - 192.70.237.255 allow 192.82.142.0 - 192.82.142.255 allow 192.84.244.0 - 192.84.244.255 allow 192.94.61.0 - 192.94.61.255 allow 192.94.210.0 - 192.94.210.255 allow 192.94.240.0 - 192.94.240.255 allow 192.94.241.0 - 192.94.241.255 allow 192.94.246.0 - 192.94.246.255 allow 192.96.0.0 - 192.96.255.255 allow 192.100.1.0 - 192.100.1.255 allow 192.101.142.0 - 192.101.142.255 allow 192.102.9.0 - 192.102.9.255 allow 192.133.250.0 - 192.133.250.255 allow 192.136.55.0 - 192.136.55.255 allow 192.136.56.0 - 192.136.56.255 allow 192.136.57.0 - 192.136.57.255 allow 192.157.190.0 - 192.157.190.255 allow 192.188.164.0 - 192.188.167.255 allow 192.189.75.0 - 192.189.75.255 allow 192.189.139.0 - 192.189.140.255 allow 192.231.237.0 - 192.231.237.255 allow 192.231.254.0 - 192.231.254.255 allow 192.245.148.0 - 192.245.148.255 allow 192.251.202.0 - 192.251.202.255 allow 198.54.0.0 - 198.54.255.255 allow 200.16.8.0 - 200.16.15.255 allow 204.12.128.0 - 204.12.143.255 allow 204.87.179.0 - 204.87.179.255 allow 204.152.14.0 - 204.152.15.255 allow 204.235.32.0 - 204.235.43.255 allow 205.159.79.0 - 205.159.79.255 allow 206.223.136.0 - 206.223.136.255 allow 209.203.0.0 - 209.203.63.255 allow 209.212.96.0 - 209.212.127.255 allow 216.236.176.0 - 216.236.191.255 # From rpki.afrinic.net/repository/04E8B0D80F4D11E0B657D8931367AE7D/apnic-to-afrinic.cer # CN=APNICTOAFRINIC/serialNumber=6F1A103E1427FF03483ABFD9E34DACBE1524FF8B # Not Before: Mar 30 14:17:08 2020 GMT / Not After : Mar 30 00:00:00 2025 GMT # SHA256:B6w5P1mkoNyJtM99GfGLaaKkGfSkQ6+4eC4tPijBLyM= allow 202.123.0.0/19 # From rpki.afrinic.net/repository/04E8B0D80F4D11E0B657D8931367AE7D/ripe-to-afrinic.cer # CN=RIPETOAFRINIC/serialNumber=7F7AC180897983E29E937C0A187803C072755545 # Not Before: Mar 30 14:17:12 2020 GMT / Not After : Mar 30 00:00:00 2025 GMT # SHA256:64eh2w7qQrFQVPaQrRJ4kA83gUgE3EDvm0D0AWHCXHM= allow 62.8.64.0/19 allow 62.12.96.0/19 allow 62.24.96.0/19 allow 62.61.192.0/18 allow 62.68.32.0/19 allow 62.68.224.0/19 allow 62.114.0.0/16 allow 62.117.32.0/19 allow 62.135.0.0/17 allow 62.139.0.0/16 allow 62.140.64.0/18 allow 62.173.32.0/19 allow 62.193.64.0/18 allow 62.193.160.0/19 allow 62.240.32.0/19 allow 62.240.96.0/19 allow 62.241.128.0/19 allow 62.251.128.0/17 allow 77.220.0.0/19 allow 80.67.128.0/20 allow 80.72.96.0/20 allow 80.75.160.0/19 allow 80.87.64.0/19 allow 80.88.0.0/20 allow 80.95.0.0/20 allow 80.240.192.0/20 allow 80.246.0.0/20 allow 80.248.0.0/20 allow 80.248.64.0/20 allow 80.249.64.0/20 allow 80.250.32.0/20 allow 81.4.0.0/18 allow 81.10.0.0/17 allow 81.21.96.0/20 allow 81.22.64.0/19 allow 81.26.64.0/20 allow 81.29.96.0/20 allow 81.91.224.0/20 allow 81.192.0.0/16 allow 82.101.128.0/18 allow 82.128.0.0/17 allow 82.129.128.0/17 allow 82.151.64.0/19 allow 82.201.128.0/17 allow 84.36.0.0/16 allow 84.233.0.0/17 allow 87.255.96.0/19 allow 193.95.0.0/17 allow 193.108.214.0/24 allow 193.108.252.0/22 allow 193.189.64.0 - 193.189.65.255 allow 193.194.1.0 - 193.194.5.255 allow 193.194.32.0 - 193.194.95.255 allow 193.227.0.0/18 allow 194.6.224.0/24 allow 194.79.96.0/19 allow 194.204.192.0/18 allow 195.24.192.0/19 allow 195.43.0.0/19 allow 195.166.224.0/19 allow 195.202.64.0/19 allow 195.246.32.0/19 allow 212.0.128.0/19 allow 212.12.224.0/19 allow 212.22.160.0/19 allow 212.49.64.0/19 allow 212.52.128.0/19 allow 212.60.64.0/19 allow 212.85.192.0/19 allow 212.88.96.0/19 allow 212.96.0.0/19 allow 212.100.64.0/19 allow 212.103.160.0/19 allow 212.122.224.0/19 allow 212.217.0.0/17 allow 213.55.64.0/18 allow 213.131.64.0/19 allow 213.136.96.0/19 allow 213.147.64.0/19 allow 213.150.96.0/19 allow 213.150.160.0 - 213.150.223.255 allow 213.152.64.0/19 allow 213.154.32.0 - 213.154.95.255 allow 213.158.160.0/19 allow 213.172.128.0/19 allow 213.179.160.0/19 allow 213.181.224.0/19 allow 213.193.32.0/19 allow 213.212.192.0/18 allow 213.247.0.0/19 allow 213.255.128.0/19 allow 217.14.80.0/20 allow 217.20.224.0/20 allow 217.21.112.0/20 allow 217.29.128.0/20 allow 217.29.208.0/20 allow 217.52.0.0/14 allow 217.64.96.0/20 allow 217.77.64.0/20 allow 217.78.64.0/20 allow 217.117.0.0/20 allow 217.139.0.0/16 allow 217.170.144.0/20 allow 217.199.144.0/20 # From rpki.afrinic.net/repository/04E8B0D80F4D11E0B657D8931367AE7D/arin-to-afrinic.cer # CN=ARINTOAFRINIC/serialNumber=B87C5A75F3D957413AB998646946D4541D511455 # Not Before: Mar 30 14:17:09 2020 GMT / Not After : Mar 30 00:00:00 2025 GMT # SHA256:wmJV3qcwiPcLtEMLBcvvyjs4V1Lz690bK3b8cv5v8F8= allow 129.0.0.0/16 allow 129.18.0.0/16 allow 129.45.0.0/16 allow 129.56.0.0/16 allow 129.122.0.0/16 allow 129.140.0.0/16 allow 129.205.0.0/16 allow 129.232.0.0/16 allow 137.63.0.0 - 137.64.255.255 allow 137.115.0.0/16 allow 137.171.0.0/16 allow 137.196.0.0/16 allow 137.255.0.0/16 allow 155.0.0.0/16 allow 155.11.0.0 - 155.12.255.255 allow 155.89.0.0/16 allow 155.93.0.0/16 allow 155.196.0.0/16 allow 155.251.0.0/16 allow 155.255.0.0 - 156.0.255.255 allow 156.38.0.0/16 allow 156.155.0.0 - 156.255.255.255 allow 160.0.0.0/16 allow 160.77.0.0/16 allow 160.89.0.0 - 160.90.255.255 allow 160.105.0.0/16 allow 160.113.0.0/16 allow 160.152.0.0/16 allow 160.154.0.0 - 160.179.255.255 allow 160.181.0.0 - 160.184.255.255 allow 160.224.0.0 - 160.226.255.255 allow 160.242.0.0/16 allow 160.255.0.0/16 allow 165.0.0.0/16 allow 165.16.0.0/16 allow 165.49.0.0 - 165.63.255.255 allow 165.73.0.0/16 allow 165.90.0.0/16 allow 165.169.0.0/16 allow 165.210.0.0/15 allow 165.255.0.0/16 allow 168.211.0.0 - 168.211.255.255 allow 168.253.0.0/16 allow 169.0.0.0/15 allow 169.159.0.0/16 allow 169.239.0.0/16 allow 169.255.0.0/16 allow 192.109.242.0/24

Constraints applicable to ARIN's Trust Anchor Most of the below constraints relate to IP addresses and ASNs which are not globally unique and not managed by any RIR, as such these INRs are not expected to appear subordinate to any publicly-trusted Trust Anchor. Additionally, since inter-RIR transfers involving ARIN may not include IPv6 addresses; ARIN's Trust Anchor is constrained to just its own IANA allocated IPv6 blocks. By placing the below content in a file named arin.constraints; the associated Trust Anchor reachable via arin.tal is constrained such that any EE certificates listing private-use INRs, or non-ARIN IPv6 blocks, or AFRINIC superblocks, are considered invalid. # From https://www.iana.org/assignments/ipv6-unicast-address-assignments allow 2001:400::/23 allow 2001:1800::/23 allow 2001:4800::/23 allow 2600::/12 allow 2610::/23 allow 2620::/23 allow 2630::/12 # AFRINIC Internet Number Resources cannot be transferred # From https://www.iana.org/assignments/ipv4-address-space/ deny 41.0.0.0/8 deny 102.0.0.0/8 deny 105.0.0.0/8 deny 154.0.0.0/16 deny 154.16.0.0/16 deny 154.65.0.0 - 154.255.255.255 deny 196.0.0.0/16 deny 196.1.0.0/24 # hole for 196.1.1.0/24 deny 196.1.2.0 - 196.1.67.255 # hole for 196.1.68.0/24 deny 196.1.69.0 - 196.1.103.255 # hole for 196.1.104.0 - 196.1.106.255 deny 196.1.107.0/24 # hole for 196.1.108.0/22 deny 196.1.112.0/24 # hole for 196.1.113.0 - 196.1.114.255 deny 196.1.115.0 - 196.1.133.255 # hole for 196.1.134.0/24 deny 196.1.135.0 - 196.3.64.255 # hole for 196.3.65.0/24 deny 196.3.66.0 - 196.3.71.255 # hole for 196.3.72.0/24 deny 196.3.73.0 - 196.12.31.255 # hole for 196.12.32.0/19 deny 196.12.64.0 - 196.15.15.255 # hole for 196.15.16.0/20 deny 196.15.32.0 - 196.29.63.255 # hole for 196.29.64.0/19 deny 196.29.96.0 - 196.32.31.255 # hole for 196.32.32.0/19 # hole for 196.32.64.0/19 deny 196.32.96.0 - 196.39.255.255 # hole for 196.40.0.0 - 196.40.95.255 deny 196.40.96.0 - 197.255.255.254 # From https://www.iana.org/assignments/as-numbers/ deny 36864 - 37887 deny 327680 - 328703 deny 328704 - 329727 # Private use IPv4 & IPv6 addresses and ASNs deny 0.0.0.0/8 # RFC 1122 Local Identification deny 10.0.0.0/8 # RFC 1918 private space deny 100.64.0.0/10 # RFC 6598 Carrier Grade NAT deny 127.0.0.0/8 # RFC 1122 localhost deny 169.254.0.0/16 # RFC 3927 link local deny 172.16.0.0/12 # RFC 1918 private space deny 192.0.2.0/24 # RFC 5737 TEST-NET-1 deny 192.88.99.0/24 # RFC 7526 6to4 anycast relay deny 192.168.0.0/16 # RFC 1918 private space deny 198.18.0.0/15 # RFC 2544 benchmarking deny 198.51.100.0/24 # RFC 5737 TEST-NET-2 deny 203.0.113.0/24 # RFC 5737 TEST-NET-3 deny 224.0.0.0/4 # Multicast deny 240.0.0.0/4 # Reserved deny 23456 # RFC 4893 AS_TRANS deny 64496 - 64511 # RFC 5398 deny 64512 - 65534 # RFC 6996 deny 65535 # RFC 7300 deny 65536 - 65551 # RFC 5398 deny 65552 - 131071 # IANA Reserved deny 4200000000 - 4294967294 # RFC 6996 deny 4294967295 # RFC 7300 # Allow the complement of what is denied allow 0.0.0.0/0 allow 1 - 4199999999

Constraints applicable to APNIC's Trust Anchor Given that ARIN, LACNIC, and RIPE IPv6 resources cannot be transferred to APNIC, only APNIC IPv6 resources should appear subordinate to APNIC's Trust Anchor, private use INRs are not managed by any RIR, and AFRINIC resources of any type cannot be transferred to and from any other RIR; the below constraints can be applied to APNIC Trust Anchor. By placing the below content in files named apnic.constraints; the associated Trust Anchor reachable via apnic.tal is constrained such that any EE certificates or Signed Objects related to out-of-scope resources are considered invalid. # From https://www.iana.org/assignments/ipv6-unicast-address-assignments allow 2001:200::/23 allow 2001:7fa::/32 # APNIC-AP-IX-ASSIGNMENT allow 2001:c00::/23 allow 2001:e00::/23 allow 2001:4400::/23 allow 2001:8000::/19 allow 2001:a000::/20 allow 2001:b000::/20 allow 2400::/12 # AFRINIC Internet Number Resources cannot be transferred # From https://www.iana.org/assignments/ipv4-address-space/ deny 41.0.0.0/8 deny 102.0.0.0/8 deny 105.0.0.0/8 deny 154.0.0.0/16 deny 154.16.0.0/16 deny 154.65.0.0 - 154.255.255.255 deny 196.0.0.0/16 deny 196.1.0.0/24 # hole for 196.1.1.0/24 deny 196.1.2.0 - 196.1.67.255 # hole for 196.1.68.0/24 deny 196.1.69.0 - 196.1.103.255 # hole for 196.1.104.0 - 196.1.106.255 deny 196.1.107.0/24 # hole for 196.1.108.0/22 deny 196.1.112.0/24 # hole for 196.1.113.0 - 196.1.114.255 deny 196.1.115.0 - 196.1.133.255 # hole for 196.1.134.0/24 deny 196.1.135.0 - 196.3.64.255 # hole for 196.3.65.0/24 deny 196.3.66.0 - 196.3.71.255 # hole for 196.3.72.0/24 deny 196.3.73.0 - 196.12.31.255 # hole for 196.12.32.0/19 deny 196.12.64.0 - 196.15.15.255 # hole for 196.15.16.0/20 deny 196.15.32.0 - 196.29.63.255 # hole for 196.29.64.0/19 deny 196.29.96.0 - 196.32.31.255 # hole for 196.32.32.0/19 # hole for 196.32.64.0/19 deny 196.32.96.0 - 196.39.255.255 # hole for 196.40.0.0 - 196.40.95.255 deny 196.40.96.0 - 197.255.255.254 # From https://www.iana.org/assignments/as-numbers/ deny 36864 - 37887 deny 327680 - 328703 deny 328704 - 329727 # Private use IPv4 & IPv6 addresses and ASNs deny 0.0.0.0/8 # RFC 1122 Local Identification deny 10.0.0.0/8 # RFC 1918 private space deny 100.64.0.0/10 # RFC 6598 Carrier Grade NAT deny 127.0.0.0/8 # RFC 1122 localhost deny 169.254.0.0/16 # RFC 3927 link local deny 172.16.0.0/12 # RFC 1918 private space deny 192.0.2.0/24 # RFC 5737 TEST-NET-1 deny 192.88.99.0/24 # RFC 7526 6to4 anycast relay deny 192.168.0.0/16 # RFC 1918 private space deny 198.18.0.0/15 # RFC 2544 benchmarking deny 198.51.100.0/24 # RFC 5737 TEST-NET-2 deny 203.0.113.0/24 # RFC 5737 TEST-NET-3 deny 224.0.0.0/4 # Multicast deny 240.0.0.0/4 # Reserved deny 23456 # RFC 4893 AS_TRANS deny 64496 - 64511 # RFC 5398 deny 64512 - 65534 # RFC 6996 deny 65535 # RFC 7300 deny 65536 - 65551 # RFC 5398 deny 65552 - 131071 # IANA Reserved deny 4200000000 - 4294967294 # RFC 6996 deny 4294967295 # RFC 7300 # Allow the complement of what is denied allow 0.0.0.0/0 allow 1 - 4199999999

Constraints applicable to LACNIC's Trust Anchor Given that ARIN, APNIC, and RIPE IPv6 resources cannot be transferred to LACNIC, only LACNIC IPv6 resources should appear subordinate to LACNIC's Trust Anchor, private use INRs are not managed by any RIR, and AFRINIC resources of any type cannot be transferred to and from any other RIR; the below constraints can be applied to LACNIC Trust Anchor. By placing the below content in files named lacnic.constraints; the associated Trust Anchor reachable via lacnic.tal is constrained such that any EE certificates or Signed Objects related to out-of-scope resources are considered invalid. # From https://www.iana.org/assignments/ipv6-unicast-address-assignments allow 2001:1200::/23 allow 2800::/12 # AFRINIC Internet Number Resources cannot be transferred # From https://www.iana.org/assignments/ipv4-address-space/ deny 41.0.0.0/8 deny 102.0.0.0/8 deny 105.0.0.0/8 deny 154.0.0.0/16 deny 154.16.0.0/16 deny 154.65.0.0 - 154.255.255.255 deny 196.0.0.0/16 deny 196.1.0.0/24 # hole for 196.1.1.0/24 deny 196.1.2.0 - 196.1.67.255 # hole for 196.1.68.0/24 deny 196.1.69.0 - 196.1.103.255 # hole for 196.1.104.0 - 196.1.106.255 deny 196.1.107.0/24 # hole for 196.1.108.0/22 deny 196.1.112.0/24 # hole for 196.1.113.0 - 196.1.114.255 deny 196.1.115.0 - 196.1.133.255 # hole for 196.1.134.0/24 deny 196.1.135.0 - 196.3.64.255 # hole for 196.3.65.0/24 deny 196.3.66.0 - 196.3.71.255 # hole for 196.3.72.0/24 deny 196.3.73.0 - 196.12.31.255 # hole for 196.12.32.0/19 deny 196.12.64.0 - 196.15.15.255 # hole for 196.15.16.0/20 deny 196.15.32.0 - 196.29.63.255 # hole for 196.29.64.0/19 deny 196.29.96.0 - 196.32.31.255 # hole for 196.32.32.0/19 # hole for 196.32.64.0/19 deny 196.32.96.0 - 196.39.255.255 # hole for 196.40.0.0 - 196.40.95.255 deny 196.40.96.0 - 197.255.255.254 # From https://www.iana.org/assignments/as-numbers/ deny 36864 - 37887 deny 327680 - 328703 deny 328704 - 329727 # Private use IPv4 & IPv6 addresses and ASNs deny 0.0.0.0/8 # RFC 1122 Local Identification deny 10.0.0.0/8 # RFC 1918 private space deny 100.64.0.0/10 # RFC 6598 Carrier Grade NAT deny 127.0.0.0/8 # RFC 1122 localhost deny 169.254.0.0/16 # RFC 3927 link local deny 172.16.0.0/12 # RFC 1918 private space deny 192.0.2.0/24 # RFC 5737 TEST-NET-1 deny 192.88.99.0/24 # RFC 7526 6to4 anycast relay deny 192.168.0.0/16 # RFC 1918 private space deny 198.18.0.0/15 # RFC 2544 benchmarking deny 198.51.100.0/24 # RFC 5737 TEST-NET-2 deny 203.0.113.0/24 # RFC 5737 TEST-NET-3 deny 224.0.0.0/4 # Multicast deny 240.0.0.0/4 # Reserved deny 23456 # RFC 4893 AS_TRANS deny 64496 - 64511 # RFC 5398 deny 64512 - 65534 # RFC 6996 deny 65535 # RFC 7300 deny 65536 - 65551 # RFC 5398 deny 65552 - 131071 # IANA Reserved deny 4200000000 - 4294967294 # RFC 6996 deny 4294967295 # RFC 7300 # Allow the complement of what is denied allow 0.0.0.0/0 allow 1 - 4199999999

Constraints applicable to LACNIC's Trust Anchor Given that ARIN, APNIC, and LACNIC IPv6 resources cannot be transferred to RIPE NCC, only RIPE NCC IPv6 resources should appear subordinate to RIPE NCC's Trust Anchor, private use INRs are not managed by any RIR, and AFRINIC resources of any type cannot be transferred to and from any other RIR; the below constraints can be applied to RIPE NCC Trust Anchor. By placing the below content in files named ripe.constraints; the associated Trust Anchor reachable via ripe.tal is constrained such that any EE certificates or Signed Objects related to out-of-scope resources are considered invalid. # From https://www.iana.org/assignments/ipv6-unicast-address-assignments allow 2001:600::/23 deny 2001:7fa::/32 # APNIC-AP-IX-ASSIGNMENT allow 2001:800::/22 allow 2001:1400::/22 allow 2001:1a00::/23 allow 2001:1c00::/22 allow 2001:2000::/19 allow 2001:4000::/23 allow 2001:4600::/23 allow 2001:4a00::/23 allow 2001:4c00::/23 allow 2001:5000::/20 allow 2003::/18 allow 2a00::/12 allow 2a10::/12 # AFRINIC Internet Number Resources cannot be transferred # From https://www.iana.org/assignments/ipv4-address-space/ deny 41.0.0.0/8 deny 102.0.0.0/8 deny 105.0.0.0/8 deny 154.0.0.0/16 deny 154.16.0.0/16 deny 154.65.0.0 - 154.255.255.255 deny 196.0.0.0/16 deny 196.1.0.0/24 # hole for 196.1.1.0/24 deny 196.1.2.0 - 196.1.67.255 # hole for 196.1.68.0/24 deny 196.1.69.0 - 196.1.103.255 # hole for 196.1.104.0 - 196.1.106.255 deny 196.1.107.0/24 # hole for 196.1.108.0/22 deny 196.1.112.0/24 # hole for 196.1.113.0 - 196.1.114.255 deny 196.1.115.0 - 196.1.133.255 # hole for 196.1.134.0/24 deny 196.1.135.0 - 196.3.64.255 # hole for 196.3.65.0/24 deny 196.3.66.0 - 196.3.71.255 # hole for 196.3.72.0/24 deny 196.3.73.0 - 196.12.31.255 # hole for 196.12.32.0/19 deny 196.12.64.0 - 196.15.15.255 # hole for 196.15.16.0/20 deny 196.15.32.0 - 196.29.63.255 # hole for 196.29.64.0/19 deny 196.29.96.0 - 196.32.31.255 # hole for 196.32.32.0/19 # hole for 196.32.64.0/19 deny 196.32.96.0 - 196.39.255.255 # hole for 196.40.0.0 - 196.40.95.255 deny 196.40.96.0 - 197.255.255.254 # From https://www.iana.org/assignments/as-numbers/ deny 36864 - 37887 deny 327680 - 328703 deny 328704 - 329727 # Private use IPv4 & IPv6 addresses and ASNs deny 0.0.0.0/8 # RFC 1122 Local Identification deny 10.0.0.0/8 # RFC 1918 private space deny 100.64.0.0/10 # RFC 6598 Carrier Grade NAT deny 127.0.0.0/8 # RFC 1122 localhost deny 169.254.0.0/16 # RFC 3927 link local deny 172.16.0.0/12 # RFC 1918 private space deny 192.0.2.0/24 # RFC 5737 TEST-NET-1 deny 192.88.99.0/24 # RFC 7526 6to4 anycast relay deny 192.168.0.0/16 # RFC 1918 private space deny 198.18.0.0/15 # RFC 2544 benchmarking deny 198.51.100.0/24 # RFC 5737 TEST-NET-2 deny 203.0.113.0/24 # RFC 5737 TEST-NET-3 deny 224.0.0.0/4 # Multicast deny 240.0.0.0/4 # Reserved deny 23456 # RFC 4893 AS_TRANS deny 64496 - 64511 # RFC 5398 deny 64512 - 65534 # RFC 6996 deny 65535 # RFC 7300 deny 65536 - 65551 # RFC 5398 deny 65552 - 131071 # IANA Reserved deny 4200000000 - 4294967294 # RFC 6996 deny 4294967295 # RFC 7300 # Allow the complement of what is denied allow 0.0.0.0/0 allow 1 - 4199999999

Acknowledgements Thanks to Niels Bakker, Joel Jaeggli, Tony Tauber, and Tom Scholl for their feedback and input.