Transparency in Address Block Transfers

Legend
Added
Deleted

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.

Summary of Proposal

Policy Text

Current

[Following text is to be modified in the RIPE Policy Document “IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region” , if the proposal reaches consensus. This would result in a new policy section.]

5.5 Transfers of Allocations

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.

New

[Following text will replace section 5.5 in the RIPE Policy Document “IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region”, if the proposal reaches consensus. This would result in a new policy section. NOTE: edits to the 5^th paragraph of section 5.5] ~~5.5]~~

5.5 Transfers of Allocations

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,

~~section and a list of all requested transfers that were not approved after their need was evaluated. The list will be updated monthly and will contain the transferring organization’s name,~~

the block originally held by the transferring party,
the name(s) of the receiving party or parties,

~~transferor, and, if the transfer was approved, the organization name(s) to which the block(s) were transferred,~~

each subdivided prefix (each partial block derived from that original block) transferred,

~~transferred under this policy, and~~

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.

~~transferred.~~

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 ~~naming~~ 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.

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 ~~No transfers have~~ been recorded in the RIPE NCC service region recently, ~~at the time of writing,~~ 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: ~~-ARIN:~~ publishes a list of transfers without any policy regulation

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

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

More info is available at:
http://www.apnic.net/policy/transfer-policy#recipient-conditions Link: http://www.apnic.net/policy/transfer-policy#recipient-conditions

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.

~~(http://www.apnic.net/policy/transfer-policy#recipient-conditions Link: http://www.apnic.net/policy/transfer-policy#recipient-conditions )~~

B. Impact of Policy on Registry and Addressing System

Address/Internet Number Resource Consumption: