Summary

  • LACNIC’s 9 September 2026 ASPA explainer says published ASPAs cover “around 2.9%” of global ASN space. The live report it cites is transparent about its current integers, but it does not retain the state behind the prose.
  • The accepted report capture shows 2,663 routed ASNs covered out of 88,158, or 3.02%; it also shows 2,970 ASPA records. Records, Customer ASes and routed ASNs are related measures, not interchangeable units.
  • A small adoption receipt would make the statistic durable: observation time, collector boundary, numerator, denominator, object and Customer-AS counts, RIR attribution, draft versions, validation rules, digest and corrections.

A useful number with a missing time

On 9 September, LACNIC Blog published Carlos Martínez’s introduction to ASPA. It does something valuable before reaching for a percentage: it separates RPKI, ROAs, Route Origin Validation and ASPA. A ROA says which AS may originate a prefix. ASPA describes which provider ASes a customer AS authorises, supplying data for reasoning about an AS path rather than its origin alone. The post also says plainly that ASPA is still Internet-Draft work. LACNIC Blog — Una introducción a ASPA

Near the end, the post says that published ASPAs cover around 2.9% of global ASN space. An approximate figure is entirely sensible in introductory prose. Adoption changes; routing tables change; a two-decimal dashboard is not a constitution. The post helps readers by linking the source rather than leaving the claim unsupported. Its WordPress source record also fixes the publication identity and time of the article itself.

But the source link points to a current-state report. In the accepted 10 September capture, Hurricane Electric’s RPKI & ASPA Adoption Report displays 3.02% global ASN coverage. It gives the arithmetic inputs: 2,663 routed ASNs with ASPA out of 88,158 ASNs in the global routing table. Divide the former by the latter and the result is 3.0207%, which rounds to the displayed 3.02%. The page labels its update “08 Sep 2026 13:43 PDT.”

Nothing here proves 2.9% was wrong. The author may have seen an earlier state, used another extraction boundary or rounded a nearby observation more loosely. The live page may have moved between research and publication. The public record simply does not say. It preserves the prose and it preserves today’s dashboard, but not the dashboard state that generated the prose.

That distinction matters because the link looks stronger than it is. It verifies that a relevant measurement exists. It does not let a later reader reproduce the cited observation.

Three denominators hiding in one sentence

The dashboard contains another figure: 2,970 total ASPA records. That is 307 more than the 2,663 routed ASNs counted as covered. It is tempting to give the difference a neat explanation. The page does not supply one, and the standards documents make neatness unsafe.

The ASPA profile draft 29 defines an ASPA as a signed object created for a Customer AS and listing one or more authorised Provider ASes. It says a holder should maintain only one ASPA object for a Customer AS, containing all providers. It also defines how relying parties merge multiple ASPA objects for the same Customer AS into a union provider set. The recommendation and the merge rule can coexist: one describes preferred publication practice; the other defines behaviour when the observed repository state is messier.

So an object, a distinct Customer AS and a routed ASN are not definitionally the same thing. An object is a publication unit. A Customer AS is the subject of the provider authorisation. A routed ASN belongs to the report’s routing-table denominator. A provider entry is one relationship inside an object or merged set. Invalid or excluded material may introduce yet another boundary, depending on the report’s validation rules.

The 307 difference therefore remains an observation, not a diagnosis. It must not be labelled duplicates, invalid objects, unrouted ASNs or repository failures without evidence. The profile proves only that record count cannot automatically stand in for distinct Customer-AS coverage.

This is why “2.9% of ASN space” needs a measurement note. Does the numerator count valid objects, unique Customer ASes, routed Customer ASes, or something else? Does the denominator mean allocated ASNs, visible routed ASNs or a snapshot from selected collectors? In the current report the displayed global ratio is reproducible as routed covered ASNs divided by all ASNs in the chosen global routing table. The LACNIC post does not retain those integers beside its estimate.

The regional row is a second measurement

The same report shows a LACNIC row: 135 ASPA records, 135 routed ASNs with ASPA, 12,643 total routed ASNs and 1.07% coverage. The displayed percentage can again be checked: 135 divided by 12,643 is 1.0678%, rounding to 1.07%.

That row is useful because it prevents a global headline from being mistaken for a uniform regional condition. Yet it raises its own provenance questions. How is a routed ASN attributed to an RIR? Which routing collectors define visibility? Is the value recomputed from the same instant as the global total? What happens when an ASN is transferred or appears in more than one operational context? The current page may have stable internal answers. A reader citing the number needs a retained public answer tied to the cited observation.

Nor does a published ASPA prove that a network uses the data to validate paths. Publication, validation, local routing policy and an observed security outcome are separate steps. An adoption statistic measures one part of the chain. It cannot, by itself, establish route rejection, route-leak prevention or a reduction in incidents.

Drafts are moving too

The measurement is not the only mutable layer. The accepted SIDROPS document listing shows ASPA profile draft 29 dated 29 July 2026 and verification draft 28 dated 24 August 2026. Both remain Internet-Drafts and are listed at “WG Consensus: Waiting for Write-Up : Proposed Standard.”

LACNIC’s warning that ASPA is not yet an RFC is therefore accurate. That does not make experimentation premature. Internet protocols are often tested before standards reach their final documentary state. It does mean an adoption observation should preserve the draft versions that shaped object construction and verification at the time. A future reader otherwise sees a percentage beside specifications that may no longer describe the same operational assumptions.

The NRO Strategy Document 2026–2028, republished by LACNIC, includes ASPA deployment among planned work across the RIR system. That establishes direction, not uniform execution. It does not give every RIR the same publication interface, deployment date, object volume, validator behaviour or router policy. Strategy belongs in the context column of an adoption receipt, not in the numerator.

The adoption receipt

The missing object can be small. Next to any quoted adoption percentage, retain an observation timestamp and time zone; the routing-table source and collector boundary; the numerator of distinct routed Customer ASes with usable ASPA data; the denominator of routed ASNs; and the method used to attribute an ASN to an RIR.

Then record total valid ASPA objects separately from distinct Customer ASes, with provider-entry counts and treatment of AS 0 where relevant. Name the profile and verification draft versions. State repository-validation rules and exclusions. Preserve either the extract or a content digest. If a definition or collection fault is later corrected, append the correction instead of silently replacing the old number.

This is Theo March’s editorial recommendation, not a requirement announced by LACNIC, Hurricane Electric, the IETF or the NRO. It would not freeze adoption. It would freeze the evidence required to understand one observation while the system continues to move.

Sources