Transparency in Address Block Transfers

This proposal intends to increase the transparency of the transfer market for IPv4 addresses. It modifies the current intra-RIR IPv4 allocation transfer policy in order to require the RIPE NCC to publish a record of all transfers conducted under the policy.

Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA. Such address space must not contain any block that is assigned to an End User.

Address space may only be re-allocated to another LIR that is also a member of the RIPE NCC. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. An LIR may only receive a transferred allocation after their need is evaluated and approved by the RIPE NCC, following the policies set for receiving further allocations within RIPE region (see the Section 5.3 Additional Allocations of this document).

Re-allocation must be reflected in the RIPE Database. This re-allocation may be on either a permanent or non-permanent basis.

LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation.

The RIPE NCC will record the change of allocation after the transfer. Please note that the LIR always remains responsible for the entire allocation it receives from the RIPE NCC until the transfer of address space to another LIR is completed or the address space is returned. The LIR must ensure that all policies are applied.

Re-allocated blocks will be signed to establish the current allocation owner.

Re-allocated blocks are no different from the allocations made directly by the RIPE NCC and so they must be used by the receiving LIR according to the policies described in this document.

Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA. Such address space must not contain any block that is assigned to an End User.

Address space may only be re-allocated to another LIR that is also a member of the RIPE NCC. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. An LIR may only receive a transferred allocation after their need is evaluated and approved by the RIPE NCC, following the policies set for receiving further allocations within RIPE region (see the Section 5.3 Additional Allocations of this document).

Re-allocation must be reflected in the RIPE Database. This re-allocation may be on either a permanent or non-permanent basis.

LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation.

The RIPE NCC will record the change of allocation after the transfer.

The RIPE NCC will publish a list of all allocations 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 an 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 LIR always remains responsible for the entire allocation it receives from the RIPE NCC until the transfer of address space to another LIR is completed or the address space is returned. The LIR must ensure that all policies are applied.

Re-allocated blocks will be signed to establish the current allocation owner.

Re-allocated blocks are no different from the allocations made directly by the RIPE NCC and so they must be used by the receiving LIR according to the policies described in this document.

Rationale

Arguments for the proposal

IPv4 address transfer policies were put into place to encourage the movement of unused or underutilized address blocks to networks that need them and value them more highly than the current holder. The functioning of these exchanges is very important to the future of the Internet. The transfer process will work more fairly and efficiently if there is greater transparency regarding who is releasing and who is acquiring IPv4 address blocks, and more public information about each transaction. This will allow policy analysts and members of the community to better analyze and understand the effects of transfer markets. It will provide information about the extent of de-aggregation fostered by the market, the number of transactions, the parties involved, and trends toward prospective concentration of resources. Recording when address transfers were denied on the basis of needs evaluation (without identifying the block or the proposed recipient) is also important, because it facilitates greater awareness of the impact of RIPE NCC’s application of needs assessment policies on the transfer market.

Currently, ARIN and APNIC both publish lists of their transfers similar to the one proposed here. RIPE NCC is the only RIR with a transfer policy that does not make the transactions transparent.

Arguments opposing the proposal

We should make it as difficult as possible for people to know what is happening to the address space.

Those involved in the selling of addresses would like to keep everyone in the dark so that the price will be higher.

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

The RIPE NCC understands that the goal of the Policy Proposal is to increase transparency in address block transfers. The proposal would require a change to RIPE NCC procedures but no change to the management of Internet number resources.

It is worth mentioning that the RIPE NCC is willing to publish details on resource transfers and a report has not been requested so far. Only one transfer has been recorded in the RIPE NCC service region recently, and this is why no details on resource transfers have been published so far.

It is also worth mentioning the practices of the RIRs referred to in the Rationale:

- ARIN: publishes a list of transfers without any policy regulation

- APNIC: maintains a log of transfers as per generic requirement

"APNIC will maintain a public log of all transfers made under this policy."

This policy very clearly describes what the RIPE NCC should report: completed and rejected transfers. It is expected that transfer requests will be flat-out rejected only very rarely. Much more common would be cases where the amount actually transferred is less than was originally requested and transfer requests that are never completed but simply abandoned by one of the participants when it becomes clear that it cannot be immediately approved. Reduced transfers will be reported as their reduced size only and abandoned requests will not be reported at all.

It should also be noted that names of organisations can change and that it is not feasible to update the published record of transfers as and when this happens.

For legal and financial purposes, the RIPE NCC defines the date of transfer as the date that the resources are added to the receiving LIR's registration.

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

Registration Services:

The Registration Services Department will have to report transfers with the detailed information requested in this Policy Proposal. Should any changes to the reporting process be required in future, a new Policy Proposal will need to be implemented first.

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.Legal Impact of Policy

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 RIPE NCC uses cookies. Some of these cookies may have been set already. More information about our cookies can be found in our privacypolicy. You can accept our cookies either by clicking here or by continuing to use the site.