Summary

  • RIPE-806 gives holders of RIPE NCC-registered IPv4, IPv6 and ASNs a way to request a lock against transfers of whole allocations or assignments. Legacy resources and LIR sub-allocations or downstream assignments are excluded. RIPE NCC and the holder agree the start and end dates; during the lock, ordinary transfer requests are not processed.
  • The current request procedure offers six, twelve and twenty-four months. Approval starts the period; the holder cannot cancel it once implemented, and a new request is needed after automatic expiry. An authorised signer, recent registration papers or identity verification, and a named list of resources are required.
  • Section 5.1 of RIPE-831 reserves RIPE NCC's right not to enforce even an approved lock, including where resources move because of a change in a member's business structure or seizure. The policy allows narrow, documented exceptions. A holder's inability to cancel and the registry's exceptional non-enforcement are different rules.

The most consequential word in a transfer lock is irrevocable. A company asks RIPE NCC to freeze the transfer of specified number resources. Once the registry approves the request, the company cannot change its mind before the agreed end date. That promise is useful when a rogue request, an internal authority dispute or an opportunistic sale could move a block out of its control. It is less absolute than the word suggests. The registry's procedure keeps an exception for changes in business structure and for seizures.

The governing policy, RIPE-806, was published on 30 October 2023. It covers transferable IPv4 and IPv6 resources and ASNs registered with RIPE NCC. A holder can select certain eligible allocations or assignments, but must lock each whole allocation or assignment rather than a slice of one. The lock does not extend to legacy resources or to sub-allocations and assignments made by LIRs. These limits define which asset is protected, and which row in a board's inventory remains outside the arrangement.

The mechanism begins with the holder, not the registry acting on its own. The holder identifies the resources and enters a time-bound agreement with RIPE NCC. The operator instructions require a request listing the resources, a choice of six, twelve or twenty-four months, recent registration documents for a legal person or identity verification for an individual, a form signed by a legally authorised representative, and evidence of that authority. A member's registered LIR-account user submits through the portal. For an End User, the sponsoring LIR submits the request on the End User's behalf. RIPE NCC evaluates it and the lock starts on approval, not on the day someone fills out the form.

During the agreed period, RIPE-806 says RIPE NCC will not process transfer requests for the locked resources. The current procedure says an implemented lock cannot be cancelled by the holder and ends automatically at the agreed date. Continuing it calls for a new application. The policy recommends warning the holder at least a month before expiry, but the holder must expressly renew. A locked resource is therefore both harder to move and less liquid by the holder's own later choice. That can be exactly the point of an anti-fraud safeguard, or an expensive surprise if an acquisition depends on prompt transfer.

The exception sits in plain sight. RIPE-831, section 5.1 says RIPE NCC may reject a lock request that conflicts with policies, procedures or applicable law. It also reserves the right not to enforce a lock after approval. The examples are transfers due to a change in a member's business structure, discussed in section 3.6, and transfers due to seizure, discussed in section 3.7. The policy itself anticipates mergers, acquisitions and legal constraints as reasons a lock might be unenforceable, and requires such exceptional situations to be defined in the procedure.

That language does not make every merger an automatic key. RIPE NCC says it may decline enforcement. It can distinguish a genuine legal succession from a paper transaction, examine the documents and apply the relevant transfer procedure. The important point for the holder is narrower and harder: the holder cannot cancel an approved lock to complete an ordinary sale, while the registry has retained a documented discretion to let a resource move in specified organizational or legal circumstances. The registry is not merely storing a frozen bit in a database. It decides whether an event fits the exception.

There is a further scope distinction. RIPE-831 says its member procedure does not describe voluntary transfer locks for independent resources assigned to End Users; those use a separate contractual-relationship procedure. The public request page explains that a sponsoring LIR submits for an End User. A board holding independent resources should not copy the member-specific sequence or exception examples into its own situation without checking that separate procedure. The broad policy covers eligible holders; the procedural route depends on the holder's relationship with RIPE NCC.

RIPE NCC promises to publish active locks. At this research check, its public active-lock page displayed “n/a” under IPv4, IPv6 and AS. That is the state of one public page at one time, not a lifetime count of applications or a list of rejected requests. The disclosure surface matters even when empty: an acquirer can inspect the list, but still needs the holder's signed agreement and the registry's confirmation of the exact resource and end date.

The asymmetry has a rational security use. A safeguard that the holder could lift with a quick message would be weak against a forged message or a compromised account. Irrevocability forces a cooling-off period. The same design gives RIPE NCC an authority test, a public record and a say over exceptional transfers. That is a broader role than an address book. The lock is a contract with a registry that adjudicates who can speak for the holder and what counts as a change of control.