Summary

  • APNIC policy can establish that an ASN transfer has moved the legitimate registered holding from a source to a recipient, but that event alone does not establish the state of every routing or authorization surface that refers to the number.
  • The handover record should keep registry facts, authenticated acts, published policy objects and observed BGP behavior distinct, then connect them with timestamps and predecessor-successor evidence.
  • Public sources do not show that every transferred ASN is active in BGP, has an IRR aut-num object or appears in a ROA; the ledger therefore needs explicit “not applicable”, “not observed” and “unknown” states rather than assumed completion.

An ASN is unusually easy to mistake for a portable label. It looks like an identifier, appears in databases as a number and can be queried independently of the routers that use it. Yet its operational meaning is not just numerical. RFC 1930 describes an Autonomous System as a connected group of prefixes operated under a single and clearly defined routing policy. The number identifies that policy domain to the rest of the Internet.

That distinction matters when the registered holder changes. APNIC’s current Internet Number Resource Policies permit transfers of ASNs between APNIC resource holders and, where a counterpart registry has a compatible policy, between regions. For an intra-APNIC transfer, the ASN must be administered by APNIC and assigned to a current account holder. The source must be the currently registered holder and must not be in dispute over the resource. The recipient becomes subject to current policy and must meet the criteria for an ASN assignment.

Those are consequential controls. They determine whether APNIC will recognise and record the transfer. APNIC’s public transfer guidance describes a transfer as movement of number resources from one legal entity to another and says the Whois Database is updated to reflect the result. Its account-to-account procedure also separates two authenticated acts: the source initiates the request in MyAPNIC and the recipient acknowledges it.

But a completed registry transaction answers a bounded question. It establishes the registry’s accepted holder state under the applicable process. It does not, without additional evidence, establish that a live BGP speaker has changed hands, that routing-policy records identify the recipient correctly, that a contact has been replaced, or that every authorization involving the ASN has been created, withdrawn or reconfirmed.

The public evidence does not justify assuming those surfaces exist in every case. An ASN can be transferred while unused. Not every ASN necessarily has an Internet Routing Registry aut-num object. A ROA is issued by a prefix holder to authorize an origin ASN, so ownership of the ASN and authority over a prefix are different facts. Observed BGP announcements show use at a time and vantage point, not legal title. A defensible handover ledger must preserve those distinctions.

The first entry in that ledger should be the registry decision itself. It needs a durable transfer identifier, the exact ASN, source and recipient account identities as recognised by the registry, the policy version applied, the source initiation receipt, the recipient acknowledgement receipt, the decision state and effective time. Where the transfer is inter-RIR, it should also retain the counterpart registry, the compatibility basis and the two regional completion references. Sensitive commercial terms do not need to be made public for the control record to exist.

The second entry should be a registration snapshot pair. RFC 9082 defines the RDAP autnum query used to retrieve autonomous-system registration data. A snapshot immediately before the effective event and another after it can show what the public registration service actually returned, including holder-facing names, contacts, status and event timestamps where present. Each snapshot needs its query, observation time, response hash and service identity. A later database correction should create a new observation rather than silently replacing the evidence used at handover.

The third entry is the routing-policy identity. RFC 1930’s definition makes the policy surface central: the recipient should be able to state whether it will continue the existing external routing policy, operate a transition policy or retire the ASN. If an IRR aut-num object exists, the ledger should identify its source database, object key, maintainers and predecessor-successor hashes. It should not say “updated” unless an attributable update receipt and a post-change read prove that state. If no such object exists, the correct value is “not observed” or “not applicable”, not a fabricated completion mark.

The fourth entry covers route-origin authorizations that refer to the ASN. A transfer of the ASN does not transfer the address space whose holders create those ROAs. Each relevant prefix holder remains the authority for its own origin authorization. RFC 6907’s transfer use cases apply a make-before-break principle to the timing of RPKI object creation and revocation, while RFC 8206 shows why ASN migration can require new ROAs for routes moving to a replacement ASN. The ledger should therefore list each known authorization dependency, its resource holder, old and new state, publication evidence and validation observation.

It should never infer authority over a prefix merely from receipt of the ASN.

The fifth entry is observed operation. If the ASN is expected to remain active, the record can preserve time-bounded BGP observations from identified collectors: origin presence, relevant paths, first and last observation under the transition, and any divergence from the declared plan. These are observations, not registry judgments. Absence from one collector is not proof that the ASN is unused; presence is not proof that the speaker is authorized. The ledger becomes useful precisely because it does not collapse those different claims.

A compact state model can keep the sequence legible. REQUESTED means the registry has received a transfer request. SOURCE_CONFIRMED and RECIPIENT_ACKNOWLEDGED represent attributable acts, not inferred consent. REGISTRY_EFFECTIVE means the registry has completed the holder change. DEPENDENCIES_IN_TRANSITION means identified routing, contact or authorization surfaces are being reconciled. HANDOVER_OBSERVED means the planned operational state has been checked against defined evidence. EXCEPTION_OPEN means a material discrepancy has an owner and next action. None of the later states should be backfilled merely because the registry state is effective.

Closure needs a named criterion rather than a green badge. For an unused ASN, registry completion and accurate contacts may be enough, with routing and RPKI dependencies explicitly marked not applicable. For an active ASN, closure may require a declared routing-policy state, control of relevant credentials, reconciled IRR objects where used, reviewed ROA dependencies and an observation window. The criterion should be fixed before completion so that missing evidence cannot be reclassified after the event.

This design does not ask a registry to certify the whole routing system. The registry remains authoritative for its registration decision. Prefix holders remain authoritative for their ROAs. IRR operators publish the objects in their databases. Network operators control routers and policy. Collectors provide observations. The ledger supplies the connective tissue: a versioned record of which authority asserted what, when it was observed and what remained unknown.

That is the governance value of treating an ASN as a routing identity rather than a transferable serial number. The transaction can be valid while the operational transition is incomplete; the transition can be successful while some optional surface does not apply. A handover ledger makes both statements possible without weakening the registry’s decision or overstating what it proves.

Sources