Summary

  • ARIN removes transferred resources and associated ROAs from the source certificate at completion; remaining source ROAs stay with remaining resources.
  • An enrolled recipient gets certificate coverage automatically, but creates its own ROAs. A recipient outside RPKI must enroll first.

ARIN can move an address block into a recipient's resource certificate without writing the recipient's route-origin authorization. That is the oddly split handoff in its own transfer and RPKI instructions. At completion, ARIN removes the transferred resources from the source's certificate and removes associated ROAs. The source's certificate is rerolled around any remaining resources, and their ROAs are retained. If the recipient already holds an ARIN RPKI certificate, ARIN automatically renews it to include the new resources. The new ROA belongs to the recipient's to-do list.

A certificate and a ROA answer different questions. The certificate names the resources over which an organization can make signed assertions. A ROA states which origin AS may announce a particular prefix and with what maximum length. ARIN's automation moves the right to make the assertion; it does not choose a new origin AS on behalf of the recipient. The registry can know who received the block without knowing how that organization intends to announce it. That separation is sound bookkeeping, but the publication sequence has an exposed human step.

ARIN's 2025 transfer best-practices article is unusually direct about the step. A recipient with an existing certificate gets that certificate renewed automatically, yet must create new ROAs for the transferred resources. A recipient outside ARIN's RPKI service must enroll; the transfer itself does not sign it up. ARIN's RPKI best-practices page says newly added resources enter an existing certificate without changing existing ROAs. The previous holder's authorization leaves with the resource, while the new holder's origin statement appears only when the new holder acts.

The source side is also conditional on what remains. If it transfers only part of its certified space, ARIN keeps ROAs for the remainder and rerolls the certificate accordingly. If it transfers the entirety of its agreement-covered IPs and ASNs, ARIN removes the current certificate; ROAs referencing those resources are deleted from the repository. That is a clean registry severance. The recipient-side work is deliberately less automatic. Someone must decide which AS to authorize, which prefix to cover and what maxLength to set. Those are operational choices, not fields a registry should invent from an asset-transfer form.

The parties therefore need a transfer-day sequence, not just a signed deal. The source can check affected ROAs before completion. The recipient can have its RPKI participation and intended origin statements ready for the moment the certified resource set changes. After completion, it must inspect the renewed certificate and publish the ROAs it actually wants. ARIN also asks recipients to review IRR objects and reverse DNS settings; a transfer of registered control does not itself update every operational declaration around the block.

ARIN's official pages describe a process, not a particular route failure. A dated ROA repository snapshot and route-validation observation would establish how long a specific handoff was exposed and whether traffic was affected. The governing point is already evident. ARIN runs the mechanical half of the transfer; the recipient writes the network claim. The registry's automatic certificate renewal is a useful beginning, but it is not the final line in a routing-security handover.

ARIN