Allow IPv4 PI transfer
Summary of Proposal
According to “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”, it is not possible to transfer Provider Independent (PI) IP space.
There is, however, a lot of IPv4 PI space that was assigned over the past years and there is currently a market for this space as well. Although it isn’t possible to actually hand-over the IP space in the RIPE Registry, some people are actually “selling ownership via side-letters” or other means. This poses a risk for the buyer (new users) and as the registry isn’t correctly maintained, the world is looking at incorrect/stale/false data in the registry.
The goal of this policy proposal is to get PI space on-par with PA space in terms of the ability to be able to transfer it.
[The following text will update sections 6.3 and 7.0 and will create a new section 6.4 in the RIPE Policy Document “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”, if the proposal reaches consensus.]
a. Current policy text
6.3 Validity of an Assignment
All assignments are valid as long as the original criteria on which the assignment was based are still valid and the assignment is properly registered in the RIPE Database. If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. If an assignment is based on information that turns out to be invalid, the assignment is no longer valid.
7.0 Types of Address Space
- ASSIGNED PI: This address space has been assigned to an End User and can be kept as long as the criteria for the original assignment are met. It cannot be re-assigned or further assigned to other parties.
b. New policy text
6.3 Validity of an Assignment
An assignment is valid as long as the original criteria on which it was based remain valid and it is properly registered in the RIPE Database. Changes to the original criteria must be documented in the RIPE Registry, or the assignment will no longer be considered valid. An assignment that was based on information that turns out to be incorrect is no longer valid.
6.4 Transfers of PI space
Any holder of Provider Independent (PI) address space is allowed to re-assign complete or partial blocks of IPv4 address space that were previously assigned to them by the RIPE NCC.
Address space may only be re-assigned in accordance with the RIPE Policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”.
Re-assignments must be reflected in the RIPE Database. This re-assignment can either be on a permanent or non-permanent basis.
Parties that receive a re-assignment from another party cannot re-assign complete or partial blocks of the same address space to another party within 24 months of receiving the re-assignment.
The RIPE NCC will record the change of PI assignment after the transfer.
The RIPE NCC will publish a separate list of all PI assignments transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses.
The list will contain information about approved and non-approved transfers.
The following information will be published for approved transfers:
- The name of the transferring party
- The block originally held by the transferring party
- The name(s) of the receiving party or parties
- Each subdivided prefix (each partial block derived from that original block) transferred
- The date each prefix was transferred
Non-approved transfers will be published in aggregate statistics. In the statistics the following information will be published:
- The number of requested transfers not approved after the RIPE NCC’s evaluation
- The sum of the number of addresses included in the requested transfers
Neither the blocks nor the organizations involved will be identified in these statistics.
Please note that the transferring party always remains responsible for the entire assignment it receives from the RIPE NCC until the transfer of address space to another party is completed or if the address space is returned.
Re-assigned blocks are no different from PI assignments made directly by the RIPE NCC and so must be used by the receiving party according to the policies described in this document.
7.0 Types of Address Space
- ASSIGNED PI: This address space has been assigned to an End User for a specific purpose . It cannot be used to make further assignments to other parties.
a. Arguments supporting the proposal
- Currently the policy for PA and PI space isn’t the same and people don’t understand the difference between the various types of IP Space.
- There is already some trade in PI space, however it is not documented or registered, which doesn’t help to keep the registry updated.
- A lot of current PI space holders are more than happy to have their assignments re-assigned to other parties, but due to the current policy it is not possible. The same goes for the documentation provided to the RIPE NCC during mergers or acquisitions of infrastructure with PI space. Due to the current policy, some changes in company names are marked as mergers or acquisitions when they are actually a transfer of IP space with added documentation to make it look like an merger or acquisition of infrastructure.
- We want to have an open and honest communication to the RIPE NCC from the community and we need to make sure that the registry is up to date, without having to fluff up the procedures, bend the rules and truth in communication to the RIPE NCC to be able to transfer the IP space.
- The goal of this policy change is to get PI space on-par with PA space in respect to the ability to transfer it.
b. Arguments opposing the proposal
- The original text in the policy stated that if an assignment isn’t valid anymore, it should be returned. However, this is not happening. IP space isn’t returned to the RIPE NCC and people still trade their assignments. This policy changes the original implicit return if the holder doesn’t meet the original requirements anymore under which they received the PI space.
Note: In order to provide additional information related to the RIPE Policy Proposal 2014-02, “Allow IPv4 PI transfer”, 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 NCCs understanding that this proposal would allow the transfer of Provider Independent (PI) assignments (or parts of them) from the rightfully registered resource holder to a new resource holder. Both parties would need to fulfill the contractual requirements for independent resources before the transfer could take place. The RIPE NCC would publish a list of all PI assignments transferred under the policy. Non-approved transfers would be published only in aggregate statistics. Transferred PI assignments would not be able to be transferred again for 24 months.
Assignments provided to Internet Exchange Points (IXPs) for peering LANs would not be eligible for transfer under this new policy due to the special requirements for assignments for IXPs (section 6.1).
It is the RIPE NCC’s understanding that changes to the assignment criteria are only valid if they are documented in the RIPE Registry. The RIPE Registry is the comprehensive record of all Internet number resources registered within the RIPE NCC service region. The RIPE Database provides access to the public component of this registry data. For all Provider Aggregatable (PA) allocation criteria and many PI assignment criteria, an update in the RIPE database is sufficient and no RIPE NCC involvement is needed. The RIPE NCC needs to be involved when the changes affect the holdership of PI assignments or changes to the sponsoring LIR, as these resources were distributed directly by the RIPE NCC.
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.
If it is accepted, the proposal would likely result in increased deaggregation, as existing PI assignments could be split and transferred in parts. The RIPE NCC has no historical data to estimate the likely amount of deaggregation.
C. Impact of Policy on RIPE NCC Operations/Services
RIPE NCC Registration Services expects that this proposal will have a very positive effect on the accuracy and consistency of the RIPE Registry as the resource holders will have more incentive to properly request and document transfers of PI assignments.
There are more than 22,000 IPv4 PI assignments. Since this service will be open for anyone wanting IPv4 space, rather than being limited to LIRs (as allocation transfers are), it is expected that the number of IPv4 PI assignment transfers will become much higher than the number of IPv4 PA allocation transfers. In 2014, the RIPE NCC expects to process at least 800 allocation transfers based on the continuous increase in growth rates since 2012. If this proposal reaches consensus, it is therefore expected that this will result in a considerable increase in administrative work for the RIPE NCC.
In this context, it is important to highlight that the work involved with a PI assignment transfer will be higher than the work needed with an IPv4 allocation transfer. With PI assignment transfers, Registration Services not only needs to check the status of the LIR requesting the transfer but also needs to verify the accuracy of the information (and agreement) of the transferring PI resource holder. IPv4 PI assignments are not subjected to the Assisted Registry Check (ARC) and Registration Services depends on the LIRs to keep the registration data up-to-date over time.This data needs to be verified before transferring address space from one party to another. In addition, RIPE NCC IP Resource Analysts need to assist the LIR, as well as the recipient of the PI assignment, in creating the necessary RIPE Database objects and in collecting the required documentation. It is expected that the PI End Users will often be new to these processes and therefore will require more assistance. There would be additional time and effort needed from Registration Services to support the transfer process for PI assignments.
Business Applications Department:
Software development will be needed to facilitate the process of the PI transfer. Given the information that is currently available, a medium impact is expected in order to develop necessary software tools.
After analysing the data that is currently available, the RIPE NCC does not anticipate any significant impact if this proposal is implemented.
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact if this proposal is implemented.
D. Legal Impact of Policy
A number of legal documents will need to be updated, including:
- The procedural document “Transfer of Internet Number Resources and Name Changes”
- The transfer agreement template
- The procedural document “Contractual Relationship Changes Between End Users and Sponsoring LIRs”, where we will explain any possible implications
- Template agreement for assignments between End Users and LIRs
Existing contracts between End Users and sponsoring LIRs state that End Users may not transfer their assignments. However, the contracts also state the use of resources is subject to RIPE policies and which may be amended from time to time. Therefore, if the RIPE Policy Proposal is accepted, it will be possible to transfer PI assignments under existing contracts without any changes being required.
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 PI transfers in internal RIPE NCC systems. New processes and documentation will also need to be created. Experience gained from the existing transfer process for IPv4 PA allocations will be used to optimize the implementation process.