Summary

  • A 16 September 2026 study by two LACNIC authors defines an ASN-Only organisation as one with an ASN but no IPv4 or IPv6 prefixes of its own. It reports 522 organisations; 216 ASNs are visible in the default-free zone under its observation, and the conclusion describes 306 as invisible there.
  • The study also counts 1,133 prefixes advertised by ASN-Only ASNs, allocated across all five RIRs. Holding an ASN and holding the addresses it originates are different relationships; the RIR of a prefix does not identify the contract or operator behind an announcement.
  • LACNIC’s ASN policy allows revocation after six months if an assigned ASN has not been used, but says “may,” not “must.” The study does not identify individual holders, observation windows or interconnection records sufficient to turn DFZ nonappearance into a finding of non-use.
  • The published counts use adjacent but unreconciled units—215 announcing ASNs beside 216 DFZ-visible ASNs, for example. This limits the precision of any inference. It is not proof that the study is wrong or that any particular ASN is improperly held.

The word “only” describes a registry record

Imagine an organisation that needs its own routing policy but has no address block registered in its name. An address holder can authorise that organisation’s AS to originate a prefix; the ASN holder does not have to become the prefix holder. The arrangement may be commercial, institutional or technical. The public study does not tell us which arrangement applies to any particular entry, and none should be inferred from the label alone.

That distinction is the finding in LACNIC’s September study. It defines ASN-Only by what the organisation holds: an autonomous-system number, but neither IPv4 nor IPv6 prefixes. It then asks what those ASNs announce. Among 522 organisations in its cohort, the article reports 215 ASNs announcing IPv4 or IPv6 and 216 visible in the DFZ. Its table counts 1,069 IPv4 and 64 IPv6 prefixes, 1,133 in all. Most—905—were allocated by LACNIC; 158 came from ARIN, 64 from RIPE NCC, five from AFRINIC and one from APNIC.

The table does not show that the ASN holders own those prefixes. Nor does a cross-RIR line imply a breach. It shows that the registry which allocated the address block and the registry of the observed ASN may differ. The useful question is who is entitled to authorise origination and what the observed route actually says, not whether two registry labels match.

RFC 9582 gives the technical boundary: a Route Origin Authorization is a signed assertion by an IP address block holder permitting a specified AS to originate routes to specified prefixes. The authorised AS need not hold the address block. A ROA, however, is not a complete commercial contract and cannot reveal every operational dependency. Conversely, RFC 6811 defines Valid, Invalid and NotFound for a route compared with a set of validated authorisations. None of those route states is a general verdict on whether an ASN is in use, much less whether its holder deserves to keep it.

What a DFZ view can see

The study’s conclusion calls 306 of the 522 ASN-Only cases invisible in the default-free zone. That is an observation with a boundary, not an accusation. Public route collection sees routes received from particular peers at particular times. RIPE RIS documents how its collectors depend on peering sessions, and its MRT documentation distinguishes a routing-table snapshot from a stream of updates. Those documents do not identify LACNIC’s exact collector set for this study. They explain why any route-visibility result must be tied to vantage and time before it is turned into an assertion about an individual network.

An ASN could lack an observed origin because it is used in an interconnection not reflected in the sampled DFZ, because a different AS originates its address space, because it sits in a path rather than at the origin, because its planned use has not begun, or because it genuinely has no current operational role. These are possibilities, not explanations assigned to the 306. The published aggregate does not separate them. Equating “not seen as an origin here” with “unused” would skip precisely the inquiry needed to decide among them.

The study has an internal boundary too. One paragraph gives 215 ASNs announcing prefixes while another gives 216 visible in the DFZ. It reports 1,069 advertised IPv4 prefixes in its general table and 1,067 in the DFZ section. Its IPv4 RPKI status buckets add to 1,066, one short of the latter figure. The RPKI discussion says 138 announcing ASNs have at least one valid ROA, while the conclusion says 120 validate their prefixes. These may be different cohorts, times or tests; the public text does not supply the bridge. A reader should preserve the separate figures rather than silently repair them or turn the gaps into an allegation of error.

The important boundary for this article is that no aggregate number identifies an individual non-user.

The policy question is narrower than the chart

LACNIC’s authoritative Policy Manual, section 3, asks an ASN applicant to need interconnection with independent ASes now or within six months and to describe its routing policy, peers and addresses to be announced. After that period, LACNIC may revoke an assigned ASN if it has not been used. The verb matters. The rule creates a possible case-specific decision; it does not say a missing route in one DFZ study automatically establishes non-use or commands revocation.

The strongest case for looking at invisible ASNs is practical. ASNs are finite identifiers, and a registry should know whether an allocation still serves its stated purpose. A public BGP observation can point to a question worth asking. It can also expose mistaken contact details or a stalled deployment. Declining to turn the observation into a verdict is not a demand for registries to ignore resources. It is a demand that the evidence match the consequence.

An individual inquiry would begin with the application’s intended interconnection and subsequent updates, ask the holder how and where the ASN is used, and compare dated routing observations with that account. The holder should be able to correct a missing or stale record. A collector’s negative result is one input, and a valid ROA is another; neither is a substitute for the holder’s explanation or the registry’s documented decision under its own rule. The LACNIC blog does not say that LACNIC is revoking any of the 306, and this article does not claim it is.

A label should not acquire enforcement power by accident

The ASN-Only category is analytically useful precisely because it isolates a real arrangement: routing identity can be separate from address ownership. The 1,133 advertised prefixes show the category is not merely a waiting room for networks that have yet to operate. The 306 invisible cases are useful too, as a defined area of uncertainty. Neither figure deserves to become a list of presumed violators.

Registration, observation and permission have different owners. LACNIC maintains the ASN allocation record and applies its policy. Address holders control authorisations for their prefixes. Operators run the networks and bear continuity costs. Collectors see selected routes. Combining those views can produce a stronger finding; substituting one for another produces administrative certainty without operational proof. The September study can start that inquiry. Its published aggregate cannot finish it.

Sources