Voluntary Transfer Lock

Summary of proposal

The war in Ukraine has highlighted the fear of some resource holders that resources may be transferred to an aggressor under duress. It would be a great comfort to some resource holders if it was possible to signal to the RIPE NCC in advance that transfers should not occur for a predetermined period. Not all resource holders want this, so it is not a solution for everybody, but it is a solution for some.

While the situation in Ukraine was the trigger to write this policy, it does not exclusively apply to that situation. There are other situations where a resource holder may want to lock their resources to protect them from transfer, such as protecting specific resources from being transferred by mistake, or to make sure a disgruntled employee can’t cause problems. This proposal doesn’t list all possible reasons someone could use this policy, it merely offers the possibility for those who want it.

The important part is that this is a voluntary lock, not something that is forced on RIPE NCC Members or other resource holders. This proposal does not tell RIPE NCC to unilaterally limit any right that a resource holder has, but it gives resource holders the extra right to ask the RIPE NCC not to process any resource transfers for a certain amount of time.

Policy text

a. Current policy text (if modification):

There is no policy, but on request of the community, the RIPE NCC implemented a temporary voluntary lock mechanism following the RIPE NCC Executive Board resolution EB#163-R-02 ^[1].

The form to request this can be found at:
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/registry-lock-request-form.

If this new policy is accepted, it will replace or succeed the current temporary solution.

b. New policy text:

Abstract

This document defines the guiding policy for the RIPE NCC to offer a Voluntary Transfer Lock to resource holders. It applies to all transferable resource types (IPv4, IPv6 and ASN) registered with the RIPE NCC. It explicitly does not apply to sub-allocations and assignments made by LIRs. It also does not apply to legacy resources.

The transfer lock option provided by this policy is completely voluntary and will not affect resources where a lock has not been explicitly requested by its resource holder.

Goal

This policy allows any resource holder whose resources are registered with the RIPE NCC to inform them which of these resources must not be transferred for a certain amount of time. The RIPE NCC will then respect the resource holder’s wishes and prevent those resources from being transferred, despite any requests to the opposite, during the time of the lock.

Scope

This policy only defines the constraints on the implementation of a Voluntary Transfer Lock. It explicitly does not prescribe a specific implementation by RIPE NCC. When requesting a Voluntary Transfer Lock, the procedural documentation published by the RIPE NCC is leading. These procedures must comply with the constraints set by this policy.

All the Constraints defined below must be followed during the implementation of the policy by the RIPE NCC. All Recommendations should be followed unless there is a strong reason to deviate from them. The Implementation choices explicitly give the RIPE NCC leeway. The RIPE NCC may implement them if they so choose, provided that the choices are explicitly documented.

Constraints

• RIPE NCC must offer all its resource holders the option to temporarily lock their resources from transfer.
• The operational procedures to request a lock must be made publicly available.
• All transferable resource types (IPv4, IPv6 and ASN) registered with the RIPE NCC are lockable.
• Resource holders must only be able to lock their own resources.
• It must be possible for a resource holder to only lock certain resources.
• Only a whole allocation or assignment can be locked, not a part of it.
• The resource holder must explicitly state which resources to lock.
• Resource transfer requests received during the duration of the lock will not be processed by the RIPE NCC.
• A Voluntary Transfer Lock is an agreement between a resource holder and the RIPE NCC.
• The lock’s start and end date must be explicitly agreed between the RIPE NCC and the holder.
• From the start date onward, locked resources are irrevocably locked until the end date. Resource holders must explicitly acknowledge their understanding of this fact.

Recommendations

• At least 1 month before the lock expires, the RIPE NCC should notify the resource holder with the option to extend it or enter into a new locking agreement.
• The RIPE NCC should offer lock durations of 6, 12 and 24 months.
• Locks expire automatically if an extension is not explicitely requested.
• The RIPE NCC should publish all active locks on its website.

Implementation choices

• The RIPE NCC may offer additional lock durations in addition to the ones mentioned above.
• The RIPE NCC may be unable to enforce the lock in certain situations such as mergers and acquisitions or due to restrictions from any applicable laws or regulations. These situations may have practical and/or legal reasons, although the RIPE NCC should keep the number of exceptions as small as possible.
• All such exceptional situations must be clearly defined in the RIPE NCC procedure referenced in the locking agreement.
• In cases where a resource is involved in conflicting situations, the RIPE NCC will act in accordance with existing policies and procedures.

Rationale

a. Arguments supporting the proposal:

• There have been requests from parts of the community to implement this option.
• The policy gives resource holders an option they can use, it doesn’t affect those who don’t want to use it.
• The policy solves a real-world problem for some resource holders.

b. Arguments opposing the proposal:

• It is unclear how many resource holders are actually going to use this option.
• The policy may only be useful for a small subset of resource holders.
• This policy doesn’t solve all possible cases of duress.

The author of this policy proposal feels that the arguments supporting the proposal outweigh the arguments opposing the proposal. No single policy will every fix all possible scenarios, but if an option like this is never offered, we will never know how many resource holders would have used it. In the author’s opinion, considering the current situation in our service region, the risk of asking the RIPE NCC to spend money to implement a policy that is not widely used is outweighed by the peace of mind it may offer resource holders in distress.

Rationale for moving from Discussion to Review phase:

During the discussion phase it was considered whether a policy proposal was the right way to define this option for resource holders. After deliberations with the responsible RIPE NCC staff, we have decided to go ahead and propose this policy. Although others felt it was unnecessary, the RIPE NCC made it clear that it could not implement this option without a policy. Rather than debate it, we believe it is better for the community to use our bottom-up processes to achieve the desired outcome.

Another issue raised was whether this policy proposal belonged in the RIPE NCC Services Working Group or in the Address Policy Working Group, as it affects a policy (the transfer policy) defined in the latter working group. We decided to leave it in the RIPE NCC Services Working Group as the content of the policy mainly concerns a service that the community wants the RIPE NCC to provide. We added a small update ^[2] to the transfer policy (ripe-682) to refer to this new service in order to avoid any contradiction between the texts of the policy.

The final change made to this proposal between the Discussion Phase and the Review Phase is to make it clear what is meant with “Constraints”, “Recommendations” and “Implementation choices”. They roughly correspond to the MUST, SHOULD and MAY terminology as used in the IETF. Text has been added to define their meaning without referring to external documents.

[1] RIPE NCC Executive Board resolution EB#163-R-02[2] Amendments to the existing policy document ripe-682 “RIPE Resource Transfer Policies”

Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy might have if the proposal is accepted and implemented.

A. RIPE NCC's Understanding of the Proposed Policy

It is the RIPE NCC’s understanding that this proposal, if accepted, will offer resource holders the option to request that the RIPE NCC prevent transfers of specific complete blocks of IPv4 and IPv6 addresses (allocations and PI assignments) and AS Numbers for a certain period of time. 

This “Voluntary Transfer Lock” will be applicable to transferable resources with the exception of legacy resources, and it will not be applicable to sub-allocations and assignments made from allocations. This lock will not prevent resources from being transferred due to later mergers and acquisitions or due to any applicable laws or regulations, nor it will affect changes of sponsoring LIR for independent resources.  

The RIPE NCC will not process policy transfer requests for locked resources that are submitted during the period in which the resources are locked. Voluntary transfer locks will expire automatically if an extension is not requested.

The requirements for transferring unlocked resources will remain the same as in the current transfer policies.

The RIPE NCC will define the processes and procedures for requesting a transfer lock and will publish a list of all resources under an active voluntary lock.

The text of the RIPE Policy document ripe-682 “RIPE Resource Transfer Policies” will be updated with a reference to the new policy.

B. Impact of Policy on Registry and Addressing System

Address/Internet Number Resource Consumption:
After analysing the data that is currently available, the RIPE NCC does not anticipate any significant impact in this area if this proposal is implemented.

Fragmentation/Aggregation:
After analysing the data that is currently available, the RIPE NCC does not anticipate any significant impact in this area if this proposal is implemented.

C. Impact of Policy on RIPE NCC Operations/Services

Software Engineering:
Software development will be needed to:

• Prevent policy transfers of resources for which a transfer lock has been requested, while still allowing other services, such as LIR account consolidations and mergers and acquisitions.
• Automatically include the resources for which the temporary transfer lock is active in a public list and remove them from the list once the lock has expired.

Registration Services:
When receiving transfer lock requests, manual intervention will be required from Registration Services to perform due diligence checks and to support Software Engineering in identifying locked resources in order to prevent transfers for the duration of the lock while allowing other services, such as LIR account consolidations and mergers and acquisitions. 

In addition, at least one month before the voluntary lock expires, the RIPE NCC will send the resource holder a notification informing them of the possibility of extending the active transfer lock or entering into a new locking agreement.
The impact of the additional workload will depend on how many lock requests are submitted. One indication of the possible impact is the number of requests that have been submitted since the RIPE NCC Executive Board approved a temporary voluntary registry lock at the end of December 2022. As of today, around six months later, a total of three requests have been submitted. There might be an increase in demand for this service due to political or economic developments that could arise within our service region. 

D. Legal Impact of Policy

If this policy proposal is accepted, it will allow Internet number resource holders to request that their resources be irrevocably blocked from transfers for a defined period of time. The RIPE NCC will then have a mandate from the RIPE community and a clear basis under this policy to refuse transfers of locked resources (even if this is requested by an authorised representative of the resource holder). 

The scope 

It is our understanding that the voluntary transfer lock (the “Lock”) will only affect transfers of Internet number resources. All other rights and obligations of RIPE NCC Members and End Users (as per the SSA and other relevant RIPE Policies and RIPE NCC procedures) will not be affected.

As per the policy proposal, the Lock will only apply to transfers from one legal entity/natural person to another legal entity/natural person. 

All other situations, such as transfers due to a change in the member's business structure (e.g. mergers and acquisitions), modifications to the (contractual) relationship between sponsoring LIRs and End Users, sub-allocations to downstream network operators and assignments to End Users will not be affected by the Lock. 

There might be situations where the RIPE NCC cannot enforce the Lock. If the RIPE NCC receives a legally binding decision/order related to Internet number resources under a Lock, the RIPE NCC will have to comply with the order. The RIPE NCC might also not be able to enforce the Lock if it is against any applicable laws or regulations.

Due diligence 

As with any checks related to requests the RIPE NCC receives after the registration of Internet number resources, the Due Diligence Procedure will be followed for Lock requests (currently ripe-791).

As per the above procedure, the RIPE NCC reserves the right to perform additional checks on the correctness or validity of submitted documentation if needed (including the right to request the notarisation of documents). 

The RIPE NCC will work on creating or updating the appropriate legal framework under which the Lock can be requested. The framework will clearly explain the implications and conditions under which the Lock can be requested and maintained. Resource holders will be made aware of and must agree with the conditions before the Lock is enforced.

The RIPE NCC will be able to cancel the Lock for reasons clearly defined in the framework (such as if the requesting party provided falsified/incorrect information). 

As per the policy proposal, the text of the RIPE Policy document ripe-682 “RIPE Resource Transfer Policies” will be updated. Following that, the RIPE NCC will review and evaluate whether the RIPE NCC’s transfer procedures (currently ripe-758 and ripe-757) and other relevant documents need to be updated and aligned with the new provisions in the RIPE Resource Transfer Policy. 

E. Implementation

With the information currently available, it is expected that implementation of the proposal would have a medium impact in terms of the software development needed to facilitate the policy changes in the RIPE NCC’s internal systems. Internal and external processes and documentation would also need to be updated and approved internally for publication.