Summary

  • LAC-2026-3, listed on 12 August and still under discussion, would require an organization requesting additional IPv4 or IPv6 resources to show at least 80% valid ROA coverage across resources allocated or distributed to it by LACNIC.
  • The proposal uses a future allocation request as leverage over an existing address portfolio. It does not say that holders below 80% immediately lose resources, and it has not become policy.
  • The decisive implementation questions are how coverage is counted, whether IPv4 and IPv6 must pass separately, how long a correction may take, and who reviews a disputed calculation.

The check arrives when a network wants to grow

The independent RIR proposal index records LAC-2026-3 as under discussion, with a 12 August 2026 change date. Its operative idea is more consequential than a general appeal to deploy RPKI: an organization asking LACNIC for additional IPv4 or IPv6 resources would first need 80% valid ROA coverage over the address resources already allocated or distributed to it by the registry.

That timing selects the affected population. A holder that is not asking for more space does not encounter the proposed gate at that moment. A growing access network, hosting provider, enterprise or public network does. The rule therefore places the maintenance deadline at the point where delay has a business cost.

The distinction also limits what can be reported now. The proposal does not describe an automatic withdrawal of existing address space from an organization below 80%. It is not adopted policy. The news is a proposed eligibility condition on the next request, not a completed sanction.

Eighty per cent needs a denominator

A percentage becomes enforceable only after the counted unit is fixed. The Cloudflare Radar coverage design offers both the share of covered prefixes and the share of covered IP address space, and shows IPv4 and IPv6 separately. Those choices can produce materially different answers for the same organization.

Consider a holder with one large IPv4 block and several small blocks. Counting prefixes gives each block one unit. Counting addresses gives the large block much more weight. Counting only announced space raises another question: should reserved, unannounced or customer-assigned space sit inside the denominator? A neat score can move even though no route or ROA changed, simply because the measurement rule changed.

The address-family language needs the same precision. “IPv4 and IPv6” could mean one combined score, two scores that must each reach 80%, or a rule applied only where an organization holds that family. A combined address-count formula would be especially hard to interpret because IPv4 and IPv6 quantities are not economically or operationally comparable.

These are not excuses to avoid a target. They are the specification that turns a target into a reproducible decision.

A ROA authorizes an origin; it does not certify an organization

RFC 6482 defines a Route Origin Authorization as a signed object that identifies an AS authorized to originate one or more prefixes. It can also carry a maxLength that determines which more-specific announcements are covered. Cloudflare's operational explanation describes the practical result: networks can verify the prefix-to-origin-AS association and use it in route filtering.

That is valuable evidence. It is also narrow evidence. A valid ROA object does not prove that every live route is configured correctly, that every relying party has current data, or that a route will be accepted by every network. Conversely, a missing ROA is not proof of a hijack. The proposal should preserve these distinctions when it defines “valid coverage.”

The correction path matters because ordinary operations change the inputs. An ASN may change during migration. A new more-specific may exceed an old maxLength. A customer may originate a suballocation. A ROA can expire or be replaced. If the 80% calculation is taken at a single instant, a temporary publication or synchronization problem could delay an otherwise valid resource request.

The incentive is real because the transaction matters

The proposal's attraction is straightforward. Training and exhortation can leave RPKI maintenance behind other work. Tying the score to a resource request gives an applicant a concrete reason to inventory its prefixes, remove stale authorizations and create missing ROAs. The benefit extends beyond the applicant when other networks perform route-origin validation.

But an incentive becomes an eligibility decision when the registry can pause a request. The NRS description of LACNIC places address allocation, registration and regional policy within the registry's remit. LAC-2026-3 would connect that allocation role to evidence about route-origin hygiene across previously issued resources.

The connection may be defensible, especially when the cure is cheap and the score is reproducible. It is still a new institutional step. A false negative is no longer just a dashboard blemish. It can become an expansion delay.

Lu Heng's Policy Mirror supplies the useful boundary. A thin registry rule keeps resource records accurate and makes legitimate control legible. A thicker rule conditions access to scarce resources on a wider judgment about conduct. Here the conduct is technically related to the resources, but the mechanism remains conditional leverage. That makes due process part of routing-security design, not a separate legal decoration.

A credible threshold needs a cure and a review

The next text should answer five questions before asking the community to approve the number.

First, publish the numerator and denominator for every calculation. Second, state whether IPv4 and IPv6 pass separately. Third, identify the observation time and the authoritative validation snapshot. Fourth, give the applicant a correction period long enough to distinguish a stale ROA from a repository incident. Fifth, provide a named review route for disagreements about holdings, suballocations, origin ASes or validator output.

Exceptions should be narrow and evidenced, not discretionary favours. An organization that cannot issue a ROA for a specific, documented reason should know whether the resource is excluded from the denominator, counted as uncovered or sent to review. Staff should record reason codes so the community can see whether failures reflect neglected security work, ambiguous policy or measurement defects.

The 80% figure may prove to be a useful floor. The current status does not prove that yet. LAC-2026-3 has identified a powerful moment for improving RPKI coverage: the moment an organization wants to grow. The policy test is whether that moment produces verifiable correction rather than an unexplained veto.

Sources