Summary

  • LACNIC has connected member-facing ASPA creation and publication in MiLACNIC with ASPA validation support in its FORT validator.
  • The router handoff has its own switch: FORT 1.7.0.experimental includes RTRv2 support, but its maximum RTR version defaults to zero. A published object, a validated object and a router using it are three different receipts.

The button is live. The router has not necessarily pressed anything.

At LACNIC 46, the registry announced that members holding an ASN can create, configure and publish ASPA objects through MiLACNIC. They can work one object at a time or in bulk, check status and preview objects before publication. LACNIC also announced ASPA validation support in FORT, its open-source RPKI validator. The member portal and the validator now have named jobs in the same routing-security story.

That is meaningful progress. It is also where the easy version of the story ends. “ASPA enabled” can describe several different moments, and each one leaves a different receipt.

First, the resource holder records its authorized transit providers in an ASPA object. MiLACNIC’s preview and status controls give the member a place to inspect that work before publishing it. Second, the object enters the RPKI publication and retrieval path. Third, a relying-party validator checks the signed material. LACNIC says FORT’s core ASPA-validation feature was released in July 2026; its 1.7.0.experimental release lists ASPA and RTRv2 support, including an optional JSON output for valid ASPAs.

Then comes the router handoff. FORT’s release notes say --server.max-rtr-version defaults to zero. Setting it to version 2 means opting into the still-evolving RTRv2 feature; the release calls it experimental. The current IETF documents for the ASPA profile, ASPA verification and RTRv2 are Internet-Drafts, not published RFCs. FORT can validate ASPA data while an operator’s RTR server remains at its default. A validated object in a file is not a router’s received state.

That distinction gives operators a better checklist than one green “ASPA” badge. Can the member see the intended object and its publication status? Can a validator retrieve and validate it? Is ASPA output enabled? Which RTR version does the server offer? Did the router negotiate it and load the customer/provider data? Does the BGP policy consult that data, and what happened to the routes it evaluated?

The public announcement gives no regional adoption count, router-negotiation count or policy-use tally. The useful story is the machinery LACNIC has put within reach of members and operators, and the seams that remain visible between its parts. It is a launch with a working front door and a route to the back room; the final door still has a setting.

Sources