This policy proposal has been accepted
The new RIPE Document is: ripe-682
You're looking at an older version: 3
The current (published) version is 4The 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:
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 extends the 24-month transfer restriction to resources that have changed holdership due to changes in an organisation’s business (such as a merger or acquisition). It is important to note that this restriction only prevents transfers – resources subject to this restriction may continue to change holdership due to further merger or acquisition within the 24-month period.
The proposal also requires that the RIPE NCC publish information about change in holdership due to changes in an organisation’s business (such as a merger or acquisition) in the same way that it already does with general transfers.
[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.]
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
This policy outlines:
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.
Allocated resources may only be transferred to another RIPE NCC member. Provider independent resources may be transferred to:
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.
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. This restriction also applies if the resource was received due to a change in the organisation’s business (such as a merger or acquisition).
This restriction does not prevent the resources from changing holdership due to further merger or acquisition within the 24-month period.
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.
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.
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.
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:
This document is developed by the RIPE community.
The following people actively contributed by making proposals through the RIPE Policy Development Process:
Erik Bais
a. Arguments supporting the proposal
b. Arguments opposing the proposal
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.
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.
The proposed policy says:
“Allocated resources may only be transferred to another RIPE NCC member. Provider Independent resources may be transferred to:
It is the RIPE NCC’s understanding that allocations of IPv4 and IPv6 can only be transferred to organisations that are members of the RIPE NCC (i.e. have a Local Internet Registry (LIR) account). Independent resources (such as IPv4 PI, IPv6 PI and AS Numbers) can be transferred to organisations that are members of the RIPE NCC or have contractual relations with a sponsoring LIR as per RIPE Policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”.
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:
N.B. IPv6 IXP assignments are not excluded from transfer because the associated policy does not specify a return requirement. The receiving party would, however, need to meet the policy requirements defined in the "IPv6 Address Space Policy For Internet Exchange Points" before the transfer could be completed. If this is not the intention of the community it may be necessary to make some policy development to ripe-451.
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.
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.
Holdership changes during a temporary resource transfer will not re-start the 24-month holding period for the original resource holder. While in a strict sense the return of the resource to the original holder could be seen as “receiving back”, the Address Policy Working Group decided during RIPE 69 that the 24-month holding period should not apply to such temporary holdership changes.
The temporary resource holder will not be able to transfer the resource further during the period in which the resource is registered to them.
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.
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.
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.
Software Engineering:
Software development will be needed to:
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.
The Board sees no major problems with the proposal as it stands but notes that the extra work required to implement software and procedural changes may have some adverse effects on budgets in the departments concerned.
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”.
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.