SIDR Operations J. Gersch Internet-Draft Invykta LLC Intended status: Experimental 18 September 2026 Expires: 22 March 2027 Route Origin Authorization via Protected Delegation of Internet Number Resources draft-gersch-sidrops-sovereign-roots-00 Abstract The Resource Public Key Infrastructure (RPKI) provides cryptographic route-origin authorization, but its hierarchical authority model does not provide a way for a superior authority to permanently divest itself of control over a delegated resource. Even after delegation, superior authority remains part of the authorization hierarchy. This document explores a different property: an address-space holder may elect a protected delegation boundary beyond which superior authorities can no longer reclaim the resource, suppress the holder's effective origin authorizations, or create competing allocation or route-origin authority. The document specifies a hierarchical IPv4 and IPv6 resource registry that enforces this property at the state-transition boundary and derives Validated ROA Payloads (VRPs) for conventional Route Origin Validation (ROV). It also defines conflict and precedence rules that permit protected resources to coexist with RPKI-derived authority while leaving routers and the RPKI itself unchanged. The mechanism can provide origin authorization for resources not currently protected by RPKI, including legacy resources, but does not depend on such resources remaining outside RPKI. It is intended for experimental deployment alongside RPKI rather than as a replacement for RPKI or the Regional Internet Registry system. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Gersch Expires 22 March 2027 [Page 1] Internet-Draft Protected Delegation September 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Observed Coverage Gap . . . . . . . . . . . . . . . . . . 6 3.2. Legacy Resources and Contractual Mechanisms . . . . . . . 7 3.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 7 4. Hierarchical Resource Registry Model . . . . . . . . . . . . 8 4.1. Canonical Prefix Representation . . . . . . . . . . . . . 9 4.2. Origin Authorizations . . . . . . . . . . . . . . . . . . 9 4.3. Controlling Principals and Authentication of Writes . . . 10 5. Protected Delegations . . . . . . . . . . . . . . . . . . . . 11 5.1. Provisional Protection Window . . . . . . . . . . . . . . 13 5.2. Nested and Partial Delegation . . . . . . . . . . . . . . 13 5.3. Holder-Controlled Recovery . . . . . . . . . . . . . . . 13 5.4. Who May Grant Protection . . . . . . . . . . . . . . . . 14 6. Bounded Protected-Range Conflict Detection . . . . . . . . . 15 7. Provenance and Holder Confirmation . . . . . . . . . . . . . 16 8. Finality and Canonical State . . . . . . . . . . . . . . . . 16 9. Deriving VRPs and Route Origin Validation . . . . . . . . . . 17 10. Coexistence with RPKI . . . . . . . . . . . . . . . . . . . . 17 10.1. What Coexistence Claims, and What It Does Not . . . . . 18 10.2. Protected-Range Precedence . . . . . . . . . . . . . . . 19 10.3. Outside Protected Ranges . . . . . . . . . . . . . . . . 19 Gersch Expires 22 March 2027 [Page 2] Internet-Draft Protected Delegation September 2026 10.4. Why Plain Union Is Insufficient . . . . . . . . . . . . 19 10.5. Conveying Protected Ranges to Relying Parties . . . . . 20 10.6. Trust Conveyed by a Filter Artifact . . . . . . . . . . 21 10.7. Incremental Deployment . . . . . . . . . . . . . . . . . 21 11. Trust, Governance, and Upgradeability . . . . . . . . . . . . 21 12. Transfers, Re-parenting, and Ordinary Recovery . . . . . . . 22 13. Availability and Replication . . . . . . . . . . . . . . . . 22 14. Implementation Considerations . . . . . . . . . . . . . . . . 23 15. Security Considerations . . . . . . . . . . . . . . . . . . . 23 16. Operational Considerations . . . . . . . . . . . . . . . . . 24 17. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 19. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 21. Normative References . . . . . . . . . . . . . . . . . . . . 25 22. Informative References . . . . . . . . . . . . . . . . . . . 26 Appendix A. Comparison with Alternative Approaches . . . . . . . 27 A.1. A Relying-Party Precedence Rule . . . . . . . . . . . . . 27 A.2. A Separate Trust Anchor for the Holder . . . . . . . . . 28 A.3. Locally Configured Trust Anchor Constraints . . . . . . . 29 Appendix B. Conformance Vectors for the Enumeration Bound . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction The Resource Public Key Infrastructure (RPKI) [RFC6480] provides a widely deployed mechanism for binding Internet number resources to route-origin authorizations. Its hierarchical certificate model intentionally permits an issuing authority to remain an authority over resources delegated below it. A superior authority can therefore revoke or allow a subordinate certificate to expire, and the certificate hierarchy does not express that the superior authority has permanently divested itself of the delegated resource. For many deployments this is an appropriate operational model. Contractual, policy, and registry mechanisms can also reduce the practical risk of superior-authority action. This document addresses a narrower technical question: how can an address-space holder elect a delegation for which superior revocation and conflicting issuance are no longer capabilities of the authorization system itself? The mechanism specified here, referred to as a protected delegation, records the delegation in a replicated, cryptographically authorized state machine. Once the protection has become irreversible, the state-transition rules refuse conflicting allocation and origin- authorization writes from outside the protected subtree, refuse superior recovery of the protected allocation, and terminate authority traversal at the protected boundary. The holder remains Gersch Expires 22 March 2027 [Page 3] Internet-Draft Protected Delegation September 2026 able to suballocate, authorize route origins, transfer control, and voluntarily release the resource according to the rules of the registry. The same state model is also a hierarchical IPv4 and IPv6 resource registry. Each allocation identifies an address prefix, a controlling principal, and a delegating parent. Suballocations form a containment-constrained hierarchy. Transfers of control and changes of delegation are authenticated state transitions. The term controlling principal is used deliberately: a protocol-level control record does not by itself assert legal title to an Internet number resource. The initial deployment objective is coexistence with RPKI. Routers continue to consume ordinary VRPs over RTR and perform ordinary ROV. A Protected-Registry-Aware Consumer derives VRPs from protected state that is in Final State and Confirmed State and applies explicit source-precedence rules before exporting a single VRP set to routers. 1.1. Scope This document specifies origin authorization and hierarchical address-resource delegation. It does not authenticate the BGP AS_PATH, secure packet forwarding, replace ASPA or BGPsec, allocate Autonomous System Numbers, or define legal ownership of number resources. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology * Allocation: a registry record identifying an IPv4 or IPv6 prefix, its controlling principal, its delegating parent, and its operational state. * Controlling Principal: the account recorded against an allocation as holding write authority over it, identified by the credential or set of credentials that the registry verifies when a write to that allocation is attempted. Section 4.3 specifies how writes are authenticated against it. This term does not imply legal ownership. Gersch Expires 22 March 2027 [Page 4] Internet-Draft Protected Delegation September 2026 * Protected Delegation: an allocation for which the protocol has divested superior authorities of specified capabilities, including reclaim, conflicting issuance, and validity suppression from above. * Protected Range: the IPv4 or IPv6 prefix of a Protected Delegation. * Protected Subtree: the Protected Delegation and allocations validly delegated beneath it. * Ordinary Delegation: an allocation for which the parent retains normal recovery and hierarchical validity authority. * Route-Origin Authorization (ROA): in this document, and except where the term is qualified as "RPKI ROA", a registry authorization tuple consisting of an issuing allocation, prefix, maximum length, and origin AS. It is conceptually equivalent to the origin-authorization content that produces an RPKI VRP, but is not an [RFC9582] CMS object. * VRP: a tuple of prefix, maximum length, and origin AS consumed by ROV. * Asserted State: registry authority derived from an external source, such as an RIR, RDAP, WHOIS or RPKI import, that the named controlling principal has not yet exercised or attested. * Confirmed State: registry authority that has been cryptographically exercised or attested by the controlling principal, rather than merely imported or asserted by a registry operator. * Final State: registry state that satisfies the deployment's explicit consensus finality rule and is therefore eligible to influence exported routing authority. This term concerns consensus finality only. A Protected Delegation that is in Final State may still be within the provisional interval of Section 5.1, during which the grantor can reverse it. * Authority Traversal Boundary: a Protected Delegation at which validation ceases to depend on ancestors above that allocation. * Protected-Registry-Aware Consumer: a relying-party or aggregation component that validates registry state, applies protected-range conflict semantics, and exports VRPs. Gersch Expires 22 March 2027 [Page 5] Internet-Draft Protected Delegation September 2026 3. Problem Statement A conventional hierarchical delegation establishes that a child is authorized by a parent; it does not necessarily remove the parent's authority over the same resource. In RPKI, resource certificate validation establishes resource containment through a certification path [RFC3779]. A parent can cease to validate a subordinate path, and the hierarchy can contain other authorizations over resources that numerically overlap a subordinate allocation. This document does not assume that superior authorities will misuse those capabilities. The problem is structural rather than an allegation about registry behavior. Some resource holders or deployments may require a technical property stronger than contractual non-interference: after an elective protected delegation becomes irreversible, the authorization system itself must no longer accept superior actions that recreate authority inside the protected range or make the holder's valid state depend on an ancestor above the protected boundary. A second problem arises during coexistence. A simple union of VRPs from independent authority systems can authorize two conflicting origins simultaneously. Therefore a second source of origin authority is not safe merely because it can emit syntactically valid VRPs; the consuming system needs deterministic source-precedence semantics. 3.1. Observed Coverage Gap Route-origin authorization coverage is not uniform across the address space. The following measurements were taken on 23 August 2026 against public RPKI repositories and public BGP data, and are reproducible from those sources. * 1,525 prefixes within Apple's legacy /8 allocation were announced from AS714. No RPKI ROA covered any of them, so every such announcement evaluates as NotFound under [RFC6811]. * The United States Department of Defense legacy /8 allocations carried 4,325 announced routes covering approximately 218 million addresses, with no RPKI coverage. Gersch Expires 22 March 2027 [Page 6] Internet-Draft Protected Delegation September 2026 * Within that uncovered space, one /24 was announced from AS27651, an autonomous system registered in Chile, and four prefixes within another Department of Defense legacy /8 were announced from AS64140, an autonomous system registered in Colombia. Because no covering RPKI ROA exists for that space, origin validation classifies these announcements identically to any other announcement within it. These figures are stated as measurements of origin-validation coverage. This document does not assert why any particular holder has or has not published RPKI ROAs, and does not characterise the conduct of any registry or holder. The measurements establish only that a substantial quantity of address space remains outside origin- validation coverage, and that announcements within such space cannot be distinguished by [RFC6811] from announcements made by the registered holder. 3.2. Legacy Resources and Contractual Mechanisms Legacy address resources are a motivating deployment case, but the protocol does not depend on any claim that a particular contract, including a legacy registration services agreement, is inadequate. Contractual protections and protocol-enforced divestiture address different layers. A holder may consider contractual protection sufficient; another may require that superior authority be absent from the technical state machine. Registration agreements are also revised over time, and a holder's assessment of them may change accordingly; the population for which the contractual layer is insufficient is therefore not fixed. The mechanism is elective. 3.3. Design Goals * Preserve existing router-side ROV and RTR behavior. * Represent IPv4 and IPv6 allocation, suballocation, control, and route-origin authority as first-class registry state. * Permit ordinary hierarchical delegations and elective Protected Delegations in the same registry. * Prevent both addition of conflicting authority and subtraction of protected-holder authority from above. * Require holder-confirmed provenance before registry state can influence routing. * Provide deterministic coexistence with RPKI-derived VRPs. Gersch Expires 22 March 2027 [Page 7] Internet-Draft Protected Delegation September 2026 * Make finality, recovery, governance, and failure modes explicit. 4. Hierarchical Resource Registry Model This section defines the minimum registry state model required to express the protected-delegation invariant specified in Section 5. It is not a proposal to replace the registry operations of the Regional Internet Registries, and it does not define number-resource allocation policy. Allocation policy remains the responsibility of the registry system within which a deployment operates. The authoritative registry is a replicated ordered state machine. The replication technology is not itself the protocol objective; a permissioned distributed ledger is one implementation because it provides ordered multi-writer state, cryptographic write authorization, deterministic execution, and an auditable history. A registry operated as a conventional database can apply the same admission rule and will reach the same refusals. What it does not obtain are three properties that follow from replicated execution. The rule is evaluated identically for every party, including the operator of the registry itself. Its application to a particular record is observable by parties other than the one that wrote the record. The cost of evaluating it falls on the party attempting the write rather than on the registry operator, so a registry does not bear a cost that grows with the number of parties it constrains. The separate property that the evaluation itself is bounded is a consequence of Section 6, not of replication. The first of these is why the choice of substrate is not merely operational. A holder electing a Protected Delegation is constraining the authority of a party that would, in a conventionally operated registry, also be the party operating the registry and applying the rule to itself. Replicated execution separates the two roles. A deployment that does not separate them can still conform to this specification, but it asks a protected holder to rely on the continued good behaviour of the party whose capability the protection is intended to remove. The registry MUST support IPv4 and IPv6 allocations. Each allocation MUST identify a canonical prefix, a controlling principal, a parent allocation, an active/inactive state, and any expiration semantics used by the deployment. A child allocation MUST be numerically contained by its parent at the time the child is created or re- parented, except for a distinguished virtual root used only to anchor the registry. Gersch Expires 22 March 2027 [Page 8] Internet-Draft Protected Delegation September 2026 Two live allocations MUST NOT cover the same address space unless one is an ancestor of the other in the delegation hierarchy. A deployment that permits overlapping allocations that are not in an ancestor-descendant relationship MUST define which allocation is authoritative for origin authorization within the overlapping space. Without such a rule the VRP derivation described in Section 9 admits two independent authorities over the same prefix. A parent controlling principal MAY create an Ordinary Delegation within its resource. A controlling principal MAY create further suballocations within its own allocation. Repeating this operation represents a hierarchy such as IANA to RIR to ISP to organization to customer, without requiring the protocol to assert that those administrative roles must be occupied by particular institutions. The registry MUST distinguish transfer of control from re-parenting. A control transfer changes the controlling principal while preserving the delegation parent. Re-parenting changes the delegation parent and MUST require authorization sufficient to prevent unilateral movement of a resource into another authority subtree. The registry's 'owner' or equivalent implementation field identifies protocol control. Implementations and user interfaces SHOULD describe this as a controlling principal, holder, or controller unless legal ownership is actually established by an external process. 4.1. Canonical Prefix Representation IPv4 and IPv6 prefixes MUST have a single canonical representation. Host bits outside the prefix length MUST be zero. IPv4 and IPv6 identifier spaces MUST remain distinct even if represented in a common fixed-width storage type. 4.2. Origin Authorizations A controlling principal MAY create a route-origin authorization for a prefix contained by its allocation. The authorization MUST include an origin AS and maximum prefix length. The maximum length MUST be no shorter than the authorized prefix and MUST NOT exceed the width of the address family. AS 0 retains the semantics described by [RFC6483]. The registry does not require the address holder to control the origin AS; this follows the RPKI ROA model. Gersch Expires 22 March 2027 [Page 9] Internet-Draft Protected Delegation September 2026 4.3. Controlling Principals and Authentication of Writes Control over an allocation is expressed as an account. An implementation SHOULD support accounts that are threshold or multi- signature and that permit credential rotation and recovery, so that loss or compromise of a single credential does not imply irrecoverable loss of the resource. This document does not mandate a particular account scheme. Every write to the registry MUST be authenticated against the account recorded as the controlling principal of the affected allocation, and MUST be refused otherwise. Write authority is therefore held in exactly one place, and the rules of Section 5 and Section 6 determine what that authority may do. A conforming registry provides no second path by which a record may be created or altered. Authority under this document is proven when a record is written and is not carried by the record afterwards. This differs from RPKI and the difference should be stated rather than inferred. An RPKI ROA is a signed object that a relying party verifies offline against a certification path, long after issuance and without trusting the party that supplied it. A record in this registry is authenticated when it is written; a consumer that reads registry state directly, or that operates a node, re-executes that check. A consumer that reads only an exported VRP set does not, and is therefore trusting the exporter: the export carries no signature of the holder's, and this document defines none. A consumer that requires proof rather than trust MUST obtain it from registry state, by operating a node or by verifying a proof of inclusion against a committed state root. Where a protected holder holds a Protected Delegation for which no recovery policy is in force, loss of the controlling credentials is unrecoverable. Section 5.3 requires a recovery policy to be recorded before protection becomes irreversible, so a conforming deployment does not produce this state; it is described here because it is the consequence the requirement exists to prevent, and because a deployment that relaxes the requirement will produce it. This follows from the guarantee rather than from an oversight: no ancestor may reclaim an irreversible Protected Delegation, so no ancestor can reassign it to a holder that has lost its credentials. The allocation persists and its authorizations continue to be served while they remain valid. When they lapse nothing replaces them, because only the holder may create an authorization, release the allocation, or delegate it further. The range is thereafter neither usable nor recoverable by any party. Gersch Expires 22 March 2027 [Page 10] Internet-Draft Protected Delegation September 2026 A deployment MUST make this consequence plain to a holder before protection is granted, and SHOULD treat the provisional interval of Section 5.1 as the last point at which a holder can reconsider. Implementations MUST NOT offer single-credential control of a Protected Delegation, and SHOULD make threshold accounts with rotation and recovery the default rather than an option. 5. Protected Delegations A Protected Delegation is an elective state transition that removes specified superior-authority capabilities for one address range. Protection becomes irreversible only after the delegation has reached Final State, has been confirmed under Section 7, and any provisional interval under Section 5.1 has elapsed. These are three separate conditions and all of them apply. A conforming implementation MUST enforce the protected-delegation invariant at write time. For a candidate allocation or route-origin authorization whose effective scope intersects a live Protected Range, the write MUST be refused unless the candidate authority originates within the corresponding Protected Subtree and the candidate operation is authorized by the controlling principal or a valid delegate in that subtree. The invariant applies to both allocations and origin authorizations. Applying it to only one leaves a path for a superior authority to recreate the other form of authority. A superior authority MUST NOT be able to recover or transfer an irreversible Protected Delegation to itself merely by virtue of being its former or numerical ancestor. The protected holder MAY transfer control, establish holder-controlled recovery, suballocate, and voluntarily release the resource. When validating state below a Protected Delegation, authority traversal MUST terminate at that Protected Delegation for capabilities protected by this specification. The Protected Delegation is therefore the Authority Traversal Boundary for everything delegated beneath it. Expiration, suspension, removal, or other state changes in ancestors above the boundary MUST NOT invalidate otherwise valid protected-holder origin authority. These rules jointly deny two distinct capabilities: addition of competing authority from above and subtraction of the holder's authority through ancestor state changes. Gersch Expires 22 March 2027 [Page 11] Internet-Draft Protected Delegation September 2026 The necessity of denying both capabilities can be shown by applying [RFC6811] at each step of a sequence available to an ancestor. Consider a holder announcing 192.0.2.128/25 from AS64496 under a covering authorization for 192.0.2.0/24 to AS64496 with a maximum length of 25, issued under the ordinary hierarchy. +=========================+=======================+==========+ | Step | Covering VRPs | Verdict | +=========================+=======================+==========+ | 1. Holder publishes | 192.0.2.0/24, | Valid | | its authorization | AS64496, maxLength 25 | | +-------------------------+-----------------------+----------+ | 2. Ancestor withdraws | none | NotFound | | the holder's authority | | | +-------------------------+-----------------------+----------+ | 3. Ancestor authorizes | 192.0.2.0/24, AS 0, | Invalid | | 192.0.2.0/24 to AS 0 | maxLength 25 | | +-------------------------+-----------------------+----------+ Table 1: Effect of each ancestor action under RFC 6811 Step 2 alone does not remove the route. The holder's authorization ceases to contribute a VRP, so the announcement reverts to NotFound, an outcome that relying parties and routers predominantly still accept. Withdrawal removes the holder's protection rather than its reachability. Step 3 removes the route. With none of the holder's VRPs remaining, the ancestor's authorization over the same range is uncontradicted, and every announcement it covers evaluates as Invalid. An AS 0 authorization [RFC6483] is the most direct form. It is not the only one: an authorization naming the holder's own origin AS with a maximum length shorter than the holder's announcements produces the same verdict and is indistinguishable from a common misconfiguration. The order is material. Performing step 3 without step 2 leaves both authorizations covering the announcement, and because [RFC6811] treats an announcement as Valid when any covering VRP authorizes it, the route remains Valid. This is what distinguishes an ancestor from an unrelated party. An unrelated party can only add an authorization, which any-match neutralises. Only an ancestor can remove the holder's own. A Protected Delegation denies the two steps by different means. Step 2 has no counterpart, because an allocation is removable only by its own controlling principal and there is no ancestor-side withdrawal to perform. Step 3 is refused when the record is written, so the conflicting authorization never reaches the VRP set. The protected Gersch Expires 22 March 2027 [Page 12] Internet-Draft Protected Delegation September 2026 holder's authorizations therefore survive both the deactivation of every ancestor above the protected boundary and any attempt by an ancestor to record authority over the same range. 5.1. Provisional Protection Window A deployment MAY provide a bounded provisional interval after creation of a Protected Delegation during which the grantor can correct an erroneous grant. If such an interval exists, its duration and semantics MUST be part of the public registry rules. After the interval expires, superior recovery MUST be refused. The elapse of this interval is a separate condition from Final State, which concerns consensus finality alone. 5.2. Nested and Partial Delegation A Protected Delegation MAY contain Ordinary Delegations or further Protected Delegations. The same write-time invariant applies recursively. A holder MAY delegate only part of its range while retaining control of the remainder. No child protection can grant authority outside the parent's resource. 5.3. Holder-Controlled Recovery Protection from superior recovery MUST NOT be interpreted as a requirement for unrecoverable single-key control. Deployments MUST support holder-controlled recovery, by mechanisms such as threshold multisignature, pre-authorized recovery principals, signer rotation, or successor-transfer procedures. Such recovery MUST be established by the protected holder and MUST NOT restore a unilateral recovery capability to an ancestor unless the holder explicitly authorized that capability. A Protected Delegation MUST NOT become irreversible unless a recovery policy for it has been recorded. The policy identifies the credentials, threshold, approvers or successor by which control can be re-established, and it is recorded as registry state before the protection becomes irreversible, so that a consumer or a subsequent holder can determine from the record that a path exists. A deployment MUST refuse the transition to irreversible protection where no such policy is present. The purpose of this requirement is to bound the consequence described in Section 4.3 without returning any capability to an ancestor. A recovery policy makes credential loss recoverable by a party the holder selected; it does not make the resource reclaimable by the party whose authority the protection removed. These are different outcomes and this specification permits only the first. Gersch Expires 22 March 2027 [Page 13] Internet-Draft Protected Delegation September 2026 A recovery policy MAY include a succession condition that is triggered by holder inactivity. In one form, the holder records a successor together with an interval, and where no operation authorized by the holder is recorded for that resource within the interval, the successor becomes able to assume control. The interval and the successor are fixed when the policy is recorded, and the successor MUST NOT be an ancestor of the Protected Delegation unless the holder named that ancestor expressly. A succession condition is evaluated from recorded registry state and MUST NOT depend on an assertion made by any party at the time the condition is exercised. A deployment MAY permit a holder to record, at the time protection is elected, a bounded term after which the protection lapses. Where such a term is recorded it is a property of the holder's election, evaluated from recorded state. A deployment MUST NOT impose a term, a renewal requirement, or any other recurring action as a condition of continued protection, because a protection that lapses unless periodically renewed restores to the party controlling admission of records the ability to end the protection by declining to admit the renewal. 5.4. Who May Grant Protection Protection is created by a state transition that some existing authority must be able to make. In a deployment whose hierarchy is rooted in an incumbent registry structure, the capability to grant a Protected Delegation therefore rests initially with the operator of the root, or with the holder of an ancestor allocation. This specification does not remove that asymmetry, and it is structurally similar to the condition described in Section 3: a party outside the eventual protected boundary determines whether the boundary comes into existence. The asymmetry is bounded in one respect. A grant is exercised once and, once the protection has become irreversible, cannot be revisited by the granting authority, whereas a retained revocation capability persists for the lifetime of the delegation. The two are therefore not equivalent in duration, even though both originate with a superior party. A deployment MUST state which principals may grant Protected Delegations. A deployment MUST also state whether any path exists by which a holder can obtain protection without the cooperation of an ancestor or root operator. A deployment in which no such path exists SHOULD state that explicitly, rather than describing the resulting delegations as independent of superior authority without qualification. Gersch Expires 22 March 2027 [Page 14] Internet-Draft Protected Delegation September 2026 6. Bounded Protected-Range Conflict Detection An implementation MUST be able to determine whether a candidate allocation or authorization intersects a Protected Range without requiring work proportional to the total number of Protected Delegations. For prefix address spaces, one implementation maintains (1) a mapping keyed by canonical prefix identifying an exact live Protected Delegation and (2) a mapping keyed by canonical prefix summarizing the number of live Protected Delegations strictly below that prefix. Creation or removal updates the exact-prefix entry and the summaries of strict ancestors. A candidate operation enumerates at most the finite set of ancestor prefixes of the candidate and consults the descendant summary at the candidate prefix. This bounds the prefix- containment portion of the check by address-family bit depth rather than protected-population size. The two tests are exhaustive for prefix-structured identifiers, because two prefixes that overlap are necessarily nested: a Protected Range overlapping a candidate either contains the candidate or lies strictly within it. An implementation that extends this approach to an identifier space in which two resources may overlap partially cannot rely on that property and MUST use a structure that detects partial overlap directly. The upward enumeration may be shortened. Where the requesting holder's own resource contains the candidate, any Protected Range no longer than the holder's resource also contains the holder's resource and therefore cannot cause a refusal, so the enumeration may begin one bit below the prefix length of the holder's resource. This shortening is valid only while its premise holds. Where a registry uses a distinguished virtual root whose resource is a placeholder rather than a real prefix, a resource recorded directly beneath that root is not contained by its holder's resource, and an implementation MUST begin the enumeration at prefix length zero in that case. An implementation that applies the shortening unconditionally can fail to refuse a candidate in a different address family from the Protected Range it should have matched. Equivalent tries, interval structures, authenticated indexes, bitmaps, or range indexes MAY be used if they enforce the same invariant and provide bounded or otherwise operationally safe evaluation. A Boolean 'protected descendant exists' result is not sufficient for every route-origin authorization. When maximum-length semantics [RFC9319] cause an authorization's effective scope to cover more- Gersch Expires 22 March 2027 [Page 15] Internet-Draft Protected Delegation September 2026 specific prefixes, the index MUST return or permit retrieval of enough information to determine semantic intersection, such as the protected-prefix identity, depth, range endpoints, implicated-record reference, or a verifiable conflict witness. 7. Provenance and Holder Confirmation Imported registry data is not equivalent to holder-authorized state. A deployment that seeds allocations from RIR, RDAP, WHOIS, RPKI, or other external data is asserting what it believes the allocation state to be; the named holder has not necessarily authorized the corresponding registry principal. Each allocation that can contribute routing authority MUST therefore have a provenance state. At minimum, implementations MUST distinguish Asserted State from Confirmed State. Asserted State is externally derived and has not been cryptographically exercised by the named controlling principal. Confirmed State has been attested by an action of that principal or by an equivalent holder- verification procedure defined by the deployment. An authoritative VRP export produced under this document MUST contain only Confirmed State. Asserted allocations MAY be exposed through a separate diagnostic or onboarding interface, but MUST NOT influence router ROV by default. A deployment MUST publish the provenance of genesis or bulk-import data, including source, date, derivation method, and responsible importing authority. Cryptographic replication can prove what was recorded and when; it cannot prove that an initial external assertion was correct. 8. Finality and Canonical State A VRP MUST NOT be exported merely because a transaction appeared in a recent block or log entry. Each deployment MUST define an explicit finality rule identifying the canonical state eligible to influence routing. The finality rule MUST specify how a consumer determines a finalized checkpoint, how conflicting histories are detected or resolved, and what a consumer does when finality cannot be established. A consumer that cannot establish finality MUST retain its last known finalized state or withdraw protected-registry-derived authority according to a documented fail-safe policy; it MUST NOT silently select an arbitrary competing history. Gersch Expires 22 March 2027 [Page 16] Internet-Draft Protected Delegation September 2026 A permissioned deployment MAY use a Byzantine-fault-tolerant or other consensus protocol with deterministic finality. A chain with probabilistic or operational finality MUST define a confirmation rule and the residual reorganization risk. Terms such as 'effectively final' are not sufficient for interoperable behavior. Validator control and resource control are distinct. Validators order and replicate authorized state transitions; they MUST NOT be treated as resource holders merely because they participate in consensus. A validator quorum can nevertheless censor, halt, or equivocate depending on the consensus protocol, and these are security properties of the deployment. 9. Deriving VRPs and Route Origin Validation A Protected-Registry-Aware Consumer builds a validated view of allocations and origin authorizations from Final, Confirmed State. An authorization contributes a VRP only when its issuing allocation is valid under the applicable authority traversal rules. For Ordinary Delegations, the consumer validates the allocation chain through its parent hierarchy, including active and expiration state. For a Protected Delegation, traversal for protected capabilities terminates at the protected boundary; state above that boundary cannot suppress the protected holder's otherwise valid authorization. The resulting tuple is an ordinary VRP: prefix, maximum length, and origin AS. Router-side origin validation remains the ROV algorithm [RFC6811] used for RPKI-derived VRPs. No new router validation state is defined by this document. A trie or other prefix index MAY be used to derive containing allocations and covering origin authorizations. Such a structure is a relying-party implementation choice and is not authoritative registry state. Derived databases, caches, and tries MUST be rebuildable from authoritative finalized state. 10. Coexistence with RPKI The mechanism specified in this document is intended to coexist with RPKI. The router-facing interface remains a VRP set delivered through RTR [RFC8210] or another existing VRP distribution mechanism. The router does not need to know the provenance of each VRP. The relying-party or aggregation layer is not provenance-blind. It MUST know which ranges are Protected Ranges and MUST apply the conflict rules below before exporting a combined set. Therefore this document does not claim that an arbitrary unmodified RP can safely Gersch Expires 22 March 2027 [Page 17] Internet-Draft Protected Delegation September 2026 concatenate the two sources. Existing RP and aggregation software may be usable through configuration, SLURM, VRP-set aggregation and relay tooling, or equivalent mechanisms, but a Protected-Registry- Aware Consumer or equivalent aggregation step is required. Operators that do not adopt the mechanism are unaffected. Adoption of a Protected Range is also local to the consuming operator: trusting a protected registry's root or feed is a deliberate relying- party policy decision analogous in consequence, though not identical in mechanism, to selecting a trust anchor. 10.1. What Coexistence Claims, and What It Does Not This document describes the mechanism as coexisting with RPKI rather than replacing it. That claim is made at the level of the system and is not valid at the level of an individual prefix. At the system level it holds without qualification. RPKI is unmodified, no RPKI object is deprecated, no relying-party behaviour is changed, no router sees anything new, and every resource whose holder has not elected protection continues to derive its authority from its existing registry exactly as before. No flag day and no migration is required of anyone. Within a Protected Range the relationship is different, and that difference is the purpose of the range. A consumer applying the precedence rules below is excluding RPKI-derived authority for that range and using the protected registry's authority instead. For those prefixes, and only those, the protected registry is authoritative and RPKI is not. That relationship is substitutive rather than complementary, and a deployment MUST NOT describe it otherwise to a consumer that is being asked to apply protected-range precedence. Three properties bound what is substituted, and together they are why the system-level statement survives the prefix-level one. The holder elects, per range, and only for its own resources. The consumer elects, per deployment, because the exclusion takes effect only where protected-range precedence has been deliberately enabled. Outside Protected Ranges the incumbent source is preferred, so the substitution cannot spread through error. Stated briefly: the mechanism is additive to RPKI as a system, and authoritative in place of it for ranges that a holder has elected and a consumer has agreed to honour. Gersch Expires 22 March 2027 [Page 18] Internet-Draft Protected Delegation September 2026 10.2. Protected-Range Precedence Inside a Protected Range, the protected registry is authoritative for origin authorization. Before combining sources, a conforming consumer MUST ensure that no RPKI-derived VRP contributes origin authorization for any prefix within a Protected Range, unless that VRP was independently accepted under the protected registry's authority. The effective scope calculation MUST account for both the VRP prefix and its maximum length. The exclusion MUST be scoped to the Protected Range. Where the effective authorization scope of an RPKI-derived VRP covers prefixes both inside and outside a Protected Range, a conforming consumer MUST NOT discard that VRP in its entirety. The consumer MUST instead suppress only the portion of the VRP's effective scope that falls within the Protected Range, for example by emitting one or more replacement VRPs covering the remaining scope, or by evaluating the exclusion per candidate announcement rather than per VRP. Discarding the entire VRP would withdraw origin authority from address space that the Protected Delegation does not cover, and can cause announcements outside the Protected Range that would otherwise evaluate as Valid to evaluate as NotFound. After this exclusion, only Final, Confirmed protected-registry authority determines origin authorization inside that range. 10.3. Outside Protected Ranges Outside all Protected Ranges, RPKI remains the preferred authority source for ordinary RPKI-covered space. A default deployment SHOULD export protected-registry-derived VRPs only for Protected Ranges unless the operator has explicitly enabled an ordinary-registry coexistence policy. An implementation that exports ordinary protected-registry VRPs outside Protected Ranges MUST define deterministic conflict handling and MUST NOT allow a plain union to create unintended additional valid origins where the two sources disagree. 10.4. Why Plain Union Is Insufficient ROV considers an announcement Valid when at least one covering VRP authorizes the origin and prefix length. Consequently, unioning two conflicting authority sources can make both origins acceptable. Protected-range precedence is therefore a security rule, not merely an operator preference. Gersch Expires 22 March 2027 [Page 19] Internet-Draft Protected Delegation September 2026 10.5. Conveying Protected Ranges to Relying Parties The precedence rule above requires a consumer to know which ranges are Protected Ranges. A deployment SHOULD therefore publish, alongside its VRP export, a filter artifact identifying the current set of live Protected Ranges. In one profile that artifact is a SLURM [RFC8416] file whose validationOutputFilters.prefixFilters member contains one entry per live Protected Range, giving the range as the prefix and omitting asn, so that the entry matches every RPKI-derived payload covering the range irrespective of origin. Authority for that range is then supplied by the protected-registry export alone. A holder that publishes in both systems is unaffected: filtering removes its RPKI- derived payloads for the range and the protected-registry export supplies equivalents. Where this profile is used, the file MUST contain one entry in validationOutputFilters.prefixFilters for each live Protected Range, with asn absent. The file MUST NOT use locallyAddedAssertions, because protected-registry authority is supplied by the VRP export and not by SLURM assertions. Entries for ranges that are no longer live MUST be removed rather than retained. The file SHOULD be refreshed whenever the set of live Protected Ranges changes, and a consumer SHOULD treat a stale filter artifact as it treats a stale VRP set. A consumer that does not implement this profile sees a syntactically ordinary SLURM file and, if it loads the file at all, obtains the intended exclusions. The profile constrains what a producer writes and requires nothing of a consumer beyond [RFC8416] conformance. This profile has a limitation that a deployment MUST account for. A SLURM prefix filter removes payloads whose prefix lies within the filter prefix. It therefore does not remove a less-specific RPKI- derived payload whose authorization scope extends into a Protected Range from outside it. That payload is precisely the case that Section 10.2 requires to be suppressed in part rather than discarded, so a deployment relying on prefix filters alone does not satisfy that requirement. Such a deployment MUST either supply the scoped replacement payloads described in Section 10.2 or use a conveyance mechanism able to express partial suppression. Gersch Expires 22 March 2027 [Page 20] Internet-Draft Protected Delegation September 2026 10.6. Trust Conveyed by a Filter Artifact Loading a filter artifact is a stronger act than loading additional payloads, and a deployment MUST NOT present the two as equivalent. Additional payloads can only move a route from NotFound toward Valid or Invalid for resources that RPKI does not cover. A filter causes RPKI-derived payloads to be discarded, so an erroneous or hostile filter artifact can suppress legitimate RPKI authority for the range it names, which is a denial of service against the incumbent system. A consumer that loads the artifact is electing to treat the protected holder's assertion as authoritative over the incumbent registry's for that range. That election is local policy. This document specifies the mechanism and the default; it does not require any consumer to make that election. 10.7. Incremental Deployment A deployment MAY expose its validated VRP set as JSON for existing aggregation software, as SLURM [RFC8416] local assertions and filters, or directly over RTR. These are deployment mechanisms rather than new router protocols. A native consumer MAY instead read and validate authoritative registry state directly. 11. Trust, Governance, and Upgradeability The registry does not eliminate trust anchors; it changes their representation and the constraints placed on them. A deployment MUST identify the principals authorized to create top-level delegations, the validator set or consensus governance, and the software or state- transition rules that define valid writes. If the state-transition implementation is upgradeable, the deployment MUST state whether an upgrade can remove protected-delegation guarantees. A deployment claiming irreversible protection MUST provide a mechanism by which the relevant invariant becomes non- upgradeable, or an equivalent governance rule whose violation is detectable and causes consumers to reject the changed system. Consumers SHOULD pin or otherwise authenticate the deployment identity, rule version, and finalized checkpoint mechanism they trust. A software upgrade, chain migration, or fork MUST NOT silently convert a Protected Delegation into an Ordinary Delegation. Migration procedures MUST preserve protected boundaries or require an explicit new trust decision by consumers. Gersch Expires 22 March 2027 [Page 21] Internet-Draft Protected Delegation September 2026 A protected registry intentionally limits emergency intervention. Abuse, legal process, or operational disputes do not create a protocol exception unless such an exception was part of the protected capability set when the holder elected protection. This consequence MUST be disclosed to holders and operators. 12. Transfers, Re-parenting, and Ordinary Recovery An Ordinary Delegation retains the recovery model of the hierarchy in which it sits. A deployment MAY provide an operation by which the holder of a parent allocation reassigns the controlling principal of an Ordinary Delegation beneath it, for use on credential loss, expiry, or administrative error. Where such an operation exists, the deployment MUST publish the conditions under which it may be invoked. The operation MUST be refused where the target allocation is an irreversible Protected Delegation, which is the distinction between the two delegation kinds. A transfer of control SHOULD use a two-party or otherwise receiver- confirmed mechanism so that an allocation cannot be pushed to a principal unable to exercise it. Transfer of control does not by itself change the allocation's parent. Re-parenting moves an allocation between authority subtrees. It MUST verify that the new parent contains the resource and that all applicable protected-range rules remain satisfied. A Protected Delegation MUST NOT be re-parented in a way that restores superior capabilities that protection removed. Cross-registry or cross-root transfer can therefore be represented without deleting and recreating the resource or its child allocations. Implementations SHOULD preserve dependent origin authorizations when the transfer leaves their authorization semantics valid. 13. Availability and Replication A replicated registry replaces retrieval from multiple publication repositories with replication of a single ordered state machine; it does not eliminate distributed-systems failure modes. Nodes can lag, consensus can halt, networks can partition, and software versions can disagree. A consumer SHOULD validate against a local or independently operated replica when practical. Derived services SHOULD identify the finalized checkpoint from which their VRP set was built. Multiple independent consumers can then compare checkpoint identity as well as VRP content. Gersch Expires 22 March 2027 [Page 22] Internet-Draft Protected Delegation September 2026 Availability and correctness are separate. Replication improves availability of recorded state, while cryptographic authorization, deterministic execution, protected-range admission rules, and finality determine whether that state is acceptable. 14. Implementation Considerations A proof-of-concept implementation uses a permissioned Ethereum- compatible state machine, Solidity contracts, multisignature and passkey-controlled accounts, an event indexer, an in-memory Patricia trie, a JSON VRP projection, and RTR delivery through existing tooling. These choices demonstrate feasibility but are not normative requirements of this specification. Implementations SHOULD separate authoritative state from derived presentation and validation data. Human-readable organization names, login credentials, cached RDAP information, portal configuration, and derived indexes do not confer number-resource authority. Operational limits such as maximum authorizations per allocation, transaction gas limits, batch sizes, and index-rebuild procedures are deployment-specific. They MUST NOT create a condition in which a holder can make a required release or recovery operation permanently unexecutable through unbounded self-created state. 15. Security Considerations The primary security objective is preservation of the Protected Delegation invariant. Implementations must consider conflicting issuance, ancestor suppression, superior recovery, stale or unconfirmed provenance, consensus equivocation, reorganization before finality, unauthorized key use, index inconsistency, upgrade bypass, migration downgrade, and source-merging errors. A compromised protected-holder key can authorize malicious origin changes within that holder's authority. Protection deliberately prevents a superior authority from acting as an automatic recovery mechanism. Holder-controlled threshold and recovery mechanisms are therefore strongly recommended. A compromised or colluding validator quorum may censor writes, halt progress, or present competing histories depending on the consensus protocol. Independent validation of state-transition rules does not by itself solve canonical-history selection; this is why explicit finality is REQUIRED. Gersch Expires 22 March 2027 [Page 23] Internet-Draft Protected Delegation September 2026 Incorrect genesis or imported holder data can be made tamper-evident without becoming true. Only Confirmed State is eligible for authoritative VRP export under this specification. Incorrect merging of RPKI-derived and protected-registry-derived authority can broaden valid origin sets. Consumers MUST apply protected-range semantic filtering before union. Prefix-only filtering that ignores maximum-length authorization scope can fail to remove a conflicting authorization. A consumer that ingests only an exported VRP set relies on the exporter rather than on the registry, because an export carries no holder signature. Section 4.3 states the conditions under which a consumer obtains proof instead of trust. This mechanism provides route-origin authorization only. It does not validate AS_PATH, prevent route leaks, authenticate forwarding, or guarantee reachability. 16. Operational Considerations Operators should introduce the system as an additional relying-party authority source and inspect the combined VRP set before applying it to production routers. Protected-range selection should be explicit and auditable. The system should expose the finalized checkpoint, protected-range set, confirmation state, and resulting VRPs in forms suitable for independent comparison. Operators should alert on unexpected changes to any of those inputs. Because protected delegation intentionally removes superior recovery, organizations should establish recovery procedures before protection becomes irreversible. A deployment may enforce a provisional interval to permit correction of erroneous grants, but that interval must not be represented as final protection. Electing protection changes which source supplies origin authority inside the Protected Range. Because conforming consumers suppress RPKI-derived authority within that range, a holder whose Protected Delegation carries no Final, Confirmed origin authorizations will cause announcements inside the range to evaluate as NotFound for those consumers, even where valid RPKI ROAs exist for the same space. A holder SHOULD publish protected-registry origin authorizations before, or in the same operation as, the protection becoming irreversible. A deployment SHOULD warn a holder that elects protection for a range having no corresponding origin authorizations. Gersch Expires 22 March 2027 [Page 24] Internet-Draft Protected Delegation September 2026 The protocol does not require a holder to leave RPKI. A holder may maintain RPKI objects for compatibility while protected-range consumers apply the precedence rules in this document. 17. Implementation Status At the time of this -00 document, a proof-of-concept implementation has been exercised on a permissioned proof-of-authority chain. Implemented components include hierarchical IPv4/IPv6 allocations and suballocations, route-origin authorizations, control transfer, parent-initiated recovery for Ordinary Delegations, Protected Delegations, protected-range write guards, authority-boundary validation, re-parenting, provenance/confirmation handling, an event- derived read model, prefix-trie validation, a JSON VRP feed, and RTR delivery through existing tooling. The implementation also includes a prefix-decomposed protected-range index and an upgrade/backfill path. Deployment-specific account systems and web interfaces are not part of this specification. Work remaining for broader experimentation includes interoperable native consumers, independent implementations, explicit production consensus/finality profiles, operational measurements at Internet scale, and experience with holder onboarding and recovery. 18. IANA Considerations This document requests no IANA actions. 19. Privacy Considerations Internet number-resource allocations and route-origin authorizations are normally public operational data. Implementations should nevertheless avoid placing authentication credentials, personal contact data, or unnecessary organizational metadata into immutable authoritative state. Human identity and login information should remain outside the public registry unless required for a separately defined purpose. 20. Acknowledgements The author thanks ARIN for early technical feedback on the concepts described in this document. 21. Normative References Gersch Expires 22 March 2027 [Page 25] Internet-Draft Protected Delegation September 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, 1997, . [RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, 2012, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, 2017, . [RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, 2017, . [RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified Local Internet Number Resource Management with the RPKI (SLURM)", RFC 8416, 2018, . [RFC9582] Snijders, J. and T. Harrison, "A Profile for Route Origin Authorizations (ROAs)", RFC 9582, 2024, . 22. Informative References [I-D.ietf-sidrops-constraining-rpki-trust-anchors] Snijders, J., Buehler, T., and L. Qin, "Constraining RPKI Trust Anchors", Work in Progress, Internet-Draft, draft- ietf-sidrops-constraining-rpki-trust-anchors-02, 16 September 2026, . [I-D.nro-sidrops-ta-constraints] Harrison, T., Bruijnzeels, T., Martinez-Cagnazzo, C., Kosters, M., and Y. Chadee, "RPKI Trust Anchor Constraints", Work in Progress, Internet-Draft, draft-nro- sidrops-ta-constraints-00, October 2025, . Gersch Expires 22 March 2027 [Page 26] Internet-Draft Protected Delegation September 2026 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, 2004, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, 2012, . [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, 2012, . [RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. Bruijnzeels, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 8630, 2019, . [RFC9319] Gilad, Y., Goldberg, S., Sriram, K., Snijders, J., and B. Maddison, "The Use of maxLength in the RPKI", RFC 9319, 2022, . Appendix A. Comparison with Alternative Approaches The property specified in Section 5 could be pursued within RPKI rather than by a separate registry. This appendix records the strongest forms of that argument, and what each does and does not resolve. One of them, described in Appendix A.3, is sufficient on its own for a class of holders. A.1. A Relying-Party Precedence Rule A relying party could prefer a more-specific authorization and discard a covering authorization naming a different origin. This is not viable, because that shape is ordinary delegation: a provider authorizing an aggregate while a customer authorizes a more-specific prefix inside it. Measured over a global rpki-client validated set for IPv4 in July 2026, 958,366 such combinations of covering authorization, more- specific authorization, and differing origin occur. A rule of this form would discard 33,501 covering VRPs, approximately 4.5 percent of all IPv4 VRPs. Prefix relationships alone therefore do not separate a conflicting authorization from normal operation. Gersch Expires 22 March 2027 [Page 27] Internet-Draft Protected Delegation September 2026 A.2. A Separate Trust Anchor for the Holder The most direct alternative is structural: give the holder its own trust anchor, so that it is not subordinate to a Regional Internet Registry. A relying party installing the holder's Trust Anchor Locator [RFC8630] obtains the holder's authority directly, with no ancestor in the certification path able to reissue over it. A separate trust anchor on its own does not produce exclusivity, because it removes nothing. Appendix A.3 describes the case where a consumer additionally constrains the incumbent trust anchor, which does. Absent such a constraint, trust anchor certificates assert the entire resource space. Retrieved 23 August 2026, ARIN's trust anchor certificate carried all IPv4 address space, IPv6 ::/0, and Autonomous System Numbers 0-4294967295, and the RIPE NCC, LACNIC and AFRINIC trust anchors likewise asserted all IPv4 address space. This is deliberate: an all-resources trust anchor need not be reissued as allocations change. A trust anchor has no issuer above it, so under [RFC6487] its resource extension is authoritative rather than checked for containment. Installing a holder's Trust Anchor Locator therefore adds an issuer without removing the existing one. The incumbent trust anchor still covers the holder's prefixes, may still issue a subordinate certificate and an authorization over them, and that path validates. A relying party evaluates each trust anchor independently and emits the union, and [RFC6811] treats a route as Valid on any match. The outcome is two simultaneously valid origins for the same prefix, with no state in [RFC6811] distinguishing them. [I-D.nro-sidrops-ta-constraints], authored by staff of all five Regional Internet Registries, records the same condition. Its problem statement observes that "for example, one TA could issue a Route Origin Authorization (ROA) for resources that have actually been assigned to another TA". It proposes constraint validation performed by the relying party against consensus objects published by a group of trust anchors, and states that "[t]he constraint validation process must operate in such a way that TAs can continue to enumerate the complete set of INRs, notwithstanding that constraint validation will apply additional restrictions with respect to the set of INRs for which a given TA may make statements". Trust anchor certificates therefore remain as they are. The two approaches differ in where a constraint is enforced, and by whom. Gersch Expires 22 March 2027 [Page 28] Internet-Draft Protected Delegation September 2026 * Constraint validation applies when authority is read, by relying parties that have deployed the mechanism and are consulting a current consensus object. The mechanism in this document applies the constraint when authority is written, so no conflicting record is created and none is distributed. * Constraint validation derives a holder's exclusivity from the agreement of a consensus group of trust anchors, and [I-D.nro-sidrops-ta-constraints] notes that "[a] consensus group may effectively revoke any other TA". For a holder whose requirement is that no other party be able to withdraw its authority, that relocates the requirement rather than satisfying it. * A trust anchor for each holder scales with the number of holders, each requiring distribution to every relying party, key rollover, and inclusion in relying-party software. A protected registry carries any number of Protected Delegations behind a single feed and enforces exclusivity within the registry rather than in each relying party's configuration. A separate trust anchor remains useful, and Appendix A.3 sets out the conditions under which it is sufficient on its own. A.3. Locally Configured Trust Anchor Constraints A relying party can constrain the effective authority of a trust anchor locally, without agreement among trust anchors. [I-D.ietf-sidrops-constraining-rpki-trust-anchors] specifies such an approach, in which a relying party applies a locally configured set of Internet number resources to a trust anchor and accepts subordinate products only where their resources fall within that set. This is a stronger alternative than the consensus-group form discussed in Appendix A.2, because a single operator can apply it unilaterally and it therefore does not derive a holder's exclusivity from the agreement of other trust anchors. Where a holder operates its own trust anchor and consumers locally constrain the incumbent trust anchor away from that holder's resources, the holder obtains exclusivity at those consumers without any mechanism from this document. For such deployments the approach described here is unnecessary. Three differences remain, and they concern where the constraint lives rather than whether it works. Gersch Expires 22 March 2027 [Page 29] Internet-Draft Protected Delegation September 2026 * The constraint is configured and applied by each consumer. Exclusivity holds only at consumers that have configured it, and a holder cannot determine from registry state which consumers those are. The invariant in this document is applied once, at the point of record, and holds for every consumer of that registry's export. * Local configuration scales with the number of constrained trust anchors multiplied by the number of consumers, because each consumer must obtain and maintain the resource set for each trust anchor it constrains. [I-D.nro-sidrops-ta-constraints] exists in part to supply that input at scale, which reintroduces the consensus group discussed in Appendix A.2. * A constraint limits what a trust anchor may validly assert to a constraining consumer. It does not prevent the assertion from being created or published. The conflicting object continues to exist and continues to validate for any consumer that has not applied the constraint. The practical consequence is that the two approaches address different holders. Where a holder's obstacle to RPKI participation is the terms of a registration agreement, a separate trust anchor together with locally configured constraints is likely to be sufficient, and requires none of the mechanism described in this document. The mechanism specified here addresses the narrower case in which a holder requires that the capability be absent from the authorization system itself, rather than constrained at each consumer that chooses to constrain it. Appendix B. Conformance Vectors for the Enumeration Bound The following vectors distinguish a conforming implementation of Section 6 from a plausible but incorrect one. Each gives the registry state, the candidate record and its writer, and the required verdict. An implementation reaching a different verdict on any of them does not conform and will diverge from one that does. The vectors assume a registry using a distinguished virtual root whose resource is a placeholder representing all IPv4 address space, as described in Section 4. In the table below, M is the controlling principal of the Protected Delegation named in the state column, and H6 is the controlling principal of an allocation outside the corresponding Protected Subtree. Gersch Expires 22 March 2027 [Page 30] Internet-Draft Protected Delegation September 2026 +===+======================+=============================+=========+ | # | State | Writer and candidate | Verdict | +===+======================+=============================+=========+ | 1 | 2001:db8::/32 | H6 records an allocation of | REFUSE | | | protected, held by M | 2001:db8:1::/48 | | +---+----------------------+-----------------------------+---------+ | 2 | as vector 1 | M records an authorization | ACCEPT | | | | for 2001:db8:1::/48 | | +---+----------------------+-----------------------------+---------+ | 3 | ::/0 protected | the virtual root records an | REFUSE | | | | allocation of 2001:db8::/32 | | +---+----------------------+-----------------------------+---------+ Table 2: Vectors for the upward enumeration in IPv6 For IPv4 the upward enumeration is bounded at 33 lookups; for IPv6 it is bounded at 129. An implementation that has hard-coded the smaller figure, or sized an index by it, can satisfy every IPv4 case and fail vectors 1 through 3. Vector 3 is the case in which the shortened enumeration described in Section 6 MUST NOT be taken. The virtual root's resource is a placeholder representing all IPv4 address space, so it does not contain an IPv6 candidate. The premise for beginning one bit below the holder's prefix length therefore fails, and an implementation that begins there regardless does not examine prefix length zero, misses the Protected Range, and wrongly accepts the record. Author's Address Joseph Gersch Invykta LLC Email: jgersch@invykta.com Gersch Expires 22 March 2027 [Page 31]