Summary

  • ACSP Suggestion 2026.3 reported that ARIN’s duplicate-ROA example described a /16 with maxLength /24 too broadly, and proposed an explicit boundary: masks /16 through /24 rejected for the same Origin AS, /25 through /32 still creatable.
  • ARIN closed the suggestion as completed, but the current FAQ replaces that testable interval with “any prefix covered in the existing ROA,” a phrase that does not itself distinguish address containment from authorization through maxLength.
  • A small, versioned semantic-test receipt could prove the web, REST and OT&E behavior without exposing code, credentials or customer data.

A quick closure deserves credit

The easy version of this story would begin with a documentation failure. The fairer version begins with a response. On 13 January 2026, Chris Woodfield submitted ACSP Suggestion 2026.3 after testing the answer to a deceptively simple question: can a customer create a duplicate Route Origin Authorization?

The report was unusually useful. It reproduced the disputed wording, described an observed boundary, supplied replacement copy and explained the operational value. ARIN replied on 18 February that it had updated the FAQ to address the confusion, then closed the suggestion as completed. A public institution received a concrete complaint and acted in about five weeks. That is a healthy feedback loop, not an administrative footnote.

There is also a sound product reason to reject authority-equivalent records. ARIN’s hosted ROAs now renew automatically. An operator no longer needs a second, overlapping object merely to keep an authorization alive while an older one approaches expiry. Fewer redundant objects can mean a cleaner interface, fewer maintenance mistakes and less ambiguity about which record should be changed or removed. A help page need not reproduce a standards manual every time it explains that choice.

The question is therefore not whether ARIN should have accepted the suggestion, or whether it may impose a stricter admission rule than the RPKI object format requires. It did accept the suggestion, and it can operate such a rule. The question is what public evidence shows that the reported ambiguity was actually resolved.

The proposed fix contained its own test

The old example described in the suggestion started with a ROA containing a /16 and a maxLength of /24. It said another ROA for any prefix within that /16, using the same Origin AS, would be prevented. The submitter said this was not exactly what testing showed.

The distinction was numerical. For the same Origin AS, a proposed prefix with a mask from /16 through /24 was said to be disallowed because the existing authorization already permitted it. A prefix more specific than /24—from /25 through /32 in IPv4—was said to remain creatable, because it was outside the authority granted by the existing maxLength. The suggested replacement used “redundant” rather than the looser “overlapping” and retained both halves of the boundary.

That counterexample did important work. It prevented the reader from treating every subnet geometrically contained inside the /16 as the same thing. It also made the claim reproducible: try one prefix on each side of /24 with the same Origin AS and compare the results.

The current RPKI FAQ keeps part of the repair. It says auto-renew deprecated the need for duplicate ROAs and that ROAs can no longer overlap. Its example says an existing /16 with maxLength /24 will prevent another ROA with the same Origin AS and “any prefix covered in the existing ROA.” What is missing is the interval. The page no longer says /16 through /24 are the blocked cases or that /25 through /32 form the proposed countercase.

This comparison does not prove that the live system behaves incorrectly. The January account was the submitter’s reported test, not a fresh authenticated experiment. ARIN may have internal tests that perfectly capture the intended rule. “Covered in” may be intended as plain-language shorthand for “already authorized.” The public text simply does not preserve the part that would let an outside operator tell.

“Covered” and “matched” are not interchangeable

The wording becomes more consequential because RPKI already has a precise vocabulary for adjacent concepts. RFC 6811 defines a route prefix as Covered by a Validated ROA Payload when the VRP prefix is identical to it or less specific and the relevant address bits agree. maxLength is not part of that coverage test. A route is Matched only when it is covered, its prefix length does not exceed the VRP maximum length, and its Origin ASN equals the VRP ASN.

The FAQ does not capitalize “covered” or announce that it is invoking the RFC definition. It may not intend to. But an operator reading RPKI documentation cannot safely assume that address coverage and authorization-equivalent coverage mean the same thing.

Take the suggestion’s example. A /25 nested inside the /16 is address-covered by a /16 VRP. Yet it is not matched by a /16 whose maximum length is /24, even when the Origin ASN is the same. That is exactly why the omitted /25 countercase carries more information than the word “covered.”

RFC 6482 supplies the object-level view. It defines maxLength as the longest prefix the named AS is authorized to advertise. With no maxLength, only the exact prefix is authorized. It also says a valid ROA may contain an address prefix encompassed by another entry, and may even contain identical prefix entries, although an authority-inferior duplicate is not recommended because it adds no privilege.

That does not require ARIN to accept every construction its hosted service could encode. Protocol validity, routing meaning and product admission are three different layers. ARIN can reasonably keep a cleaner subset. Precisely because it is a product rule rather than a self-evident property of the object syntax, however, its boundary should be stated and tested as a product rule.

Three public surfaces stop short of the predicate

The current ROA guide says a ROA consists of an Origin AS, a prefix and a maximum length. It also says duplicate and overlapping ROAs are no longer allowed, then sends the reader to the FAQ. The guide does not provide a boundary matrix of its own.

The RPKI RESTful API guide is explicit about payload structure. A unified transaction can create, modify and delete ROAs, and can be combined atomically with ASPA changes so that all operations succeed or fail together. Each proposed resource can carry startAddress, cidrLength and maxLength. The page refers failed calls to ARIN’s general error documentation. In the frozen page, it does not spell out the duplicate-or-overlap predicate.

That omission matters most in a mixed transaction. Suppose a client deletes an older ROA and creates a replacement in one atomic request. Is redundancy evaluated against the state before the transaction, the intended state after it, or an ordered intermediate state? A correct implementation will choose one coherent model. An automation author needs to know which model, especially when an entire transaction fails together.

The Operational Test and Evaluation environment is the natural place to learn. ARIN says OT&E has the same feature set as production, permits test ROA creation and lets API clients validate RPKI transaction payloads before changing live configurations. It is separate from production and refreshed from a snapshot monthly; email is not supported and the environment is not actively monitored by staff.

OT&E is useful, but an experiment performed there is not a durable specification. A monthly refresh can change the starting state. A future service release can change behavior. Two operators can choose different prefixes and receive different results. Testing becomes institutional evidence only when the tested tuples, expected outcomes, environment version and date are preserved.

The missing object is a semantic-test receipt

ARIN does not need to publish source code to finish the evidence chain. It needs a small receipt that joins the suggestion, the documentation revision and the behavior being claimed.

The receipt should identify the closure number, documentation revision, service-rule version and effective date. Each test row should state the channel—web, REST or OT&E—the existing Origin AS, prefix and maxLength, the proposed Origin AS and prefix length, the expected accept-or-reject result and a stable reason code. It should record the environment build and test date, then link later corrections or superseding rules.

Five rows would expose most of the boundary. First, the same prefix and same AS. Second, a more-specific prefix whose length remains within maxLength. Third, a more-specific prefix beyond maxLength. Fourth, the same address tuple with a different Origin AS, because the FAQ itself makes the AS relation material. Fifth, a mixed atomic transaction that removes an old authorization and adds its replacement.

The result need not reveal a real organization, production API key or customer route. Documentation prefixes and reserved ASNs are enough. Nor does it force the FAQ itself to become long. The help answer can remain concise while linking to a machine-readable matrix for people writing preflight logic.

Such a receipt would also preserve a valuable distinction: “the documentation changed” is an editorial fact; “the service accepts and rejects these tuples” is a behavioral fact; “this closure delivered the requested clarification” is an accountability claim joining the two. One sentence should not have to carry all three.