RIPE Resource Transfer Policies
This policy proposal has been accepted
The new RIPE Document is: ripe-682
You're looking at an older version: 2
The current (published) version is 4- State:
- Accepted
- Publication date
- Affects
- Draft document
- Draft documents relating to "RIPE Resource Transfer Policies"
- Author
- Proposal Version
- 4.0 - 07 Sep 2016
- All Versions
-
- Accepted
- 14 Mar 2017
- Working Group
- Address Policy Working Group
- Proposal type
-
- New
- Modify
- Policy term
- Indefinite
- New RIPE Document
Summary of Proposal
The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources.
Removing all transfer-related policy text from the allocation and assignment policies and keeping this in one document will make it easier for people to find the information they are looking for. This will also make it easier to maintain the various policies in future.
The following policy documents currently have text relating to transfers:
- "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"
- "IPv6 Address Allocation and Assignment Policy"
- "Autonomous System (AS) Number Assignment Policies"
- "Policy for Inter-RIR Transfers of Internet Resources"
The final transfer document will aim to generalise the policy text as much as possible. It will explain specific restrictions or exceptions relating to the various types of Internet number resources as required.
The proposal covers changes of holdership via transfers as well as mergers and acquisitions.
When scarce resources change holdership (whether by transfer, merger or acquisition), a holding period is activated which prevents them from being transferred for 24 months. A scarce resource under this restriction may still change holdership at any time as part of a merger or acquisition.
The proposal also adds mergers and acquisitions to the statistics that the RIPE NCC publishes.
Policy Text
[The following policy will replace:
- Sections 5.5 and 6.4 in ripe-649, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"
- Section 4.0 in ripe-638, "Autonomous System (AS) Number Assignment Policies"
- Section 8. in ripe-655, "IPv6 Address Allocation and Assignment Policy"
- ripe-644, "Policy for Inter-RIR Transfers of Internet Resources"
Accordingly, these sections or policy documents will be deleted.]
Content
1.0 Scope
2.0 Transfers within the RIPE NCC Service Region
2.1 Transfer Requirements
2.2 Transfer Restrictions
3.0 Inter-RIR Transfers
3.1 General
3.2 Transferring Internet Number Resources to the RIPE NCC Service Region
3.3 Transferring Internet Number Resources from the RIPE NCC Service Region
4.0 Transfer Statistics
5.0 Attribution
1.0 Scope
This policy outlines:
- The rules for Internet number resource transfers within the RIPE NCC services region
- The rules for Internet number resource transfers (including legacy resources) to and from the RIPE NCC service region (often referred to as inter-RIR transfers)
2.0 Transfers within the RIPE NCC Service Region
Any legitimate resource holder is allowed to transfer complete or partial blocks of address space or number resources (IPv4, IPv6 and AS Numbers) that were previously allocated or assigned to them by the RIPE NCC or otherwise through the Regional Internet Registry (RIR) system. Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC.
Resources may only be transferred to an entity that has a contractual relationship with the RIPE NCC or with a RIPE NCC member.
2.1 Transfer Requirements
Transfers must be reflected in the RIPE Database. Transfers can be on a permanent or non-permanent basis.
The original resource holder remains responsible for an Internet number resource until the transfer to the receiving party is completed. In the case of a temporary transfer, the original resource holder re-assumes responsibility when the resource is returned. The current resource holder must ensure that all relevant policies are applied.
Transferred resources are no different from allocations or assignments made directly by the RIPE NCC and so must be used by the receiving party in accordance with the respective policy documents.
To complete the transfer, the RIPE NCC will update the registration records of the Internet number resource to reflect the change in holdership.
2.2 Transfer Restrictions
Scarce resources, which are understood as those resources that are allocated or assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs), cannot be transferred for 24 months from the date the resource was received by the resource holder.
3.0 Inter-RIR Transfers
3.1 General
Any type of Internet number resource can be transferred to or from the RIPE NCC service region. This includes legacy resources, in spite of the fact there are no specific rules for legacy resource transfers within the RIPE NCC service region.
Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC.
RIPE Policies will apply while the transfer is in process, for as long as the Internet number resources are registered within the RIPE NCC service region.
3.2 Transferring Internet Number Resources to the RIPE NCC Service Region
The RIPE NCC shall accept all transfers of Internet number resources to its service region, provided they comply with the policies relating to transfers within its service region.
For transfers from RIR service regions that require the receiving region to have needs-based policies, recipients must provide a plan to the RIPE NCC for the use of at least 50% of the transferred resources within five years.
3.3 Transferring Internet Number Resources from the RIPE NCC Service Region
When transferring Internet number resources to another RIR, the RIPE NCC will follow the transfer policies that apply within its own service region. The RIPE NCC will also comply with any commitments imposed by the receiving RIR in order to facilitate the transfer.
4.0 Transfer Statistics
The RIPE NCC will publish a list of all holdership changes. This publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses.
This list will contain information about approved changes. The following information will be published:
- The name of the offering party
- The resource originally held by the offering party
- The name(s) of the receiving party or parties
- Each subdivided prefix (each partial block derived from that original block) or resource received
- The date each resource changed holder in the registry.
- Whether it was a transfer or merger/acquisition
5.0 Attribution
This document is developed by the RIPE community.
The following people actively contributed by making proposals through the RIPE Policy Development Process:
Erik Bais
Rationale
a. Arguments supporting the proposal
- The goal of this proposal is to reduce the amount of documents where various parts of a transfer policy can be found, based on the type of number resource. When the initial transfer policies were written, it was already intended to move the new policy text to a dedicated transfer policy document.
- To improve transparency, the transfer statistics now include insight into all holdership changes under the policy.
b. Arguments opposing the proposal
- The document implements a couple of slight wording changes into the documents to make the writing more generic.
- The document proposes to include the transfer restrictions to mergers and acquisitions. This is done to make the policy more in line with the intention of the transfer policy restrictions when proposed.
Impact Analysis
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 will remove all transfer-related text from the various resource policy documents (for IPv4 PA and PI, IPv6 PA and PI, AS Numbers) and combine this into one document.
Most of the requirements for transfers will remain the same as they are in the current transfer policies and accordingly the related procedures will also remain the same.
This analysis will focus on the changes that this proposal introduces.
Entities That Can Receive a Transfer
The proposal text includes the following sentence:
“Resources may only be transferred to an entity that has a contractual relationship with the RIPE NCC or with a RIPE NCC member.”
As this is currently written, it could be interpreted as making it possible for allocated resources to be transferred to End User organisations that are not members of the RIPE NCC, but do have a contractual relationship with a member of the RIPE NCC. Since the RIPE NCC would no longer have a direct contractual relationship with the new holder of the allocation, this could represent a significant risk to the integrity of the RIR system.
If this is not the proposer’s intention, we would recommend that they clearly differentiate the requirements for allocated and independent resources.
Resources Excluded from Transfers
The proposed policy change excludes resources that are required to be returned to the RIPE NCC by the policies governing their issue. Currently this would apply to the following resources:
- IPv4 IXP - "This space will be used to run an IXP peering LAN; other uses are forbidden. [...] New IXPs will be assigned a /24. Should they require a larger assignment, they must return their current assignment (or existing PI used as an IXP peering LAN) ..."
IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region - Section 6.1
While the policy specifies the return requirement for the situation where an IXP needs a larger assignment, it is the RIPE NCC's established understanding that this requirement also applies to situations where the IXP is not in need of the assignment anymore.
- IPv6 Anycast - "Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for infrastructure providing authoritative TLD or ENUM Tier 0/1 DNS lookup services any longer."
IPv6 Address Allocation and Assignment Policy - Section 6 - IPv6 for Internet Root Servers - "If a root server stops operating within the RIPE region, the address space will be returned to the RIPE NCC and marked as "reserved" for a suitably long period of time."
IPv6 Addresses for Internet Root Servers in the RIPE Region - Temporary Assignments - "The RIPE NCC may assign number resources to End Users on a temporary deployment basis for a specific time-limited purpose. [...] The number resources will be automatically de-registered and returned to the appropriate reservation pool at the end of the approved assignment period."
Temporary Internet Number Assignment Policies - Section 2.1
If a policy change removes or adds a return requirement for an Internet resource, the list of resources excluded from transfers will be adjusted accordingly.
Holding Period for Scarce Resources
The RIPE NCC understands “scarce resources” to include IPv4 PA, IPv4 PI and 16-bit AS Numbers. If the community declares other resources to be scarce, the list of resources for which the holding period will apply will be adjusted accordingly.
The proposal introduces a 24-month holding period from the moment an Internet resource has been registered by the RIPE NCC to a resource holder. Within this period, it will not be possible to transfer the resource under RIPE Policies.
Company mergers and network acquisitions that include Internet resources are possible at any time as they are not regulated by RIPE Policies.
The holding period of 24 months will start from the moment the RIPE NCC registers the resource to the holder in the RIPE Database. This applies whether the resource was received:
- Directly from the RIPE NCC
- Via a policy transfer
- Via a company merger/takeover
- Via a network acquisition
If a legal entity has multiple LIRs and decides to consolidate these accounts or to move resources from one LIR account to another of its LIR accounts, this move of resources into a single account would not re-start the 24-month holding period as there is no change of the registered resource holder.
Any other change to an Internet resource that is not related to a holdership change (for example, a company name change or converting address space to another resource type) has no influence on the holding period.
Publishing Transfer Statistics
The proposal extends the publication of transfer-related information to include transfers completed as a result of mergers and acquisitions. This information would only be published for mergers and acquisitions completed after the implementation of the policy, not for those approved previously.
The consolidation of multiple LIR accounts belonging to the same legal entity or the move of resources from one LIR account to another LIR account belonging to the same legal entity will not be published, as there is no change of holdership involved.
The proposed policy change excludes the publication of aggregate statistics for non-approved holdership changes. Since the adoption of the policy proposal 2013-03, “Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text”, the RIPE NCC no longer performs needs-based evaluation of transfers; publication of statistics for non-approved IPv4 transfer requests is therefore no longer relevant.
There is an important distinction between “non-approved” requests and “invalid/incomplete” requests. If a request is received which cannot be completed due to a policy restriction (for example IPv6 allocations smaller than the minimum /32 or IPv4 allocations which have already changed holdership within the previous 24 months), it is considered to be invalid. If a request is received with inadequate supporting documentation (for example missing the signed transfer agreement), it is considered to be incomplete. In both of these scenarios, the RIPE NCC is unable to complete the evaluation of the request and therefore it cannot be considered to be either approved or non-approved.
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 that any significant impact will be caused if this proposal is implemented.
Fragmentation/Aggregation:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
C. Impact of Policy on RIPE NCC Operations/Services
Software Engineering:
Software development will be needed to:
- Update the transfer statistics to differentiate between policy transfers and mergers/acquisitions
- Prevent transfer of scarce resources for 24 months after any ownership change
- Exclude LIR Account consolidations from the 24-month restriction
Registration Services:
Some manual intervention will be required from Registration Services to support Software Engineering with identifying and excluding LIR account consolidations from the existing list of mergers/acquisitions.
External Relations:
This proposal continues a trend towards defining policies according to the action being performed (in this case the transfer of resources between holders), rather than according to the type of resource (such as a policy for allocation and assignment of IPv6 address space). The community has identified this approach as producing more straightforward policy, and the RIPE NCC agrees with this assessment. The trade-off, however, is that there co-exist certain policies based on specific operations and others based on specific types of resources. This has the potential to complicate future policy development activity, and it is expected that increased efforts will be needed to explain to the RIPE NCC membership and other stakeholders which policy document applies in which situations, especially during the implementation period. We recognise that the RIPE NCC has a primary role in making this information available, but hope the RIPE community can assist and support us in these efforts.
Billing/Finance Department:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
RIPE Database:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
D. RIPE NCC Executive Board
The Executive board has examined both the proposal and the RIPE NCC impact analysis for this proposal.
They make the following two comments:
1) The RIPE NCC impact analysis notes that acceptance of this proposal could significantly affect the stability of the RIR system as a whole by allowing transfer of any resource (including assigned PA space) to any entity including one that is not a member of the RIPE NCC (or any other RIR).
2) The Board also notes that the following wording
"Any legitimate resource holder is allowed to transfer complete or partial blocks of address space or number resources (IPv4, IPv6 and AS Numbers) that were previously allocated or assigned to them by the RIPE NCC or otherwise through the Regional Internet Registry (RIR) system. Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC."
reinforces this.
We would respectfully suggest that this policy proposal be returned to the community for further work.
E. Legal Impact of Policy
If this proposal becomes policy, the RIPE NCC may need to update the relevant procedural documents, including the RIPE NCC procedural document“Transfer of Internet Number Resources and Change of a Member’s Official Legal Name”.
F. 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 internal RIPE NCC systems. Internal and external processes and documentation would also need to be updated.