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.

Summary of Proposal

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.

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 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. The RIPE NCC will publish a list of all allocations transferred under this 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 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 under this policy, and the date each prefix was 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 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. No transfers have been recorded in the RIPE NCC service region 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: 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."

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

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. Future development of changes to such reporting will not be able to be performed without the implementation of a new Policy Proposal.

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

The proposal requests that the RIPE NCC publish a monthly list with the following information:

About 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

About rejected transfers:

• the name of the party that had the intention to transfer their resources,
• the block from which a prefix was requested to be transferred

The RIPE NCC currently does not publish information about rejected transfers because it considers this data to be confidential. This information reveals failed attempts of Members to transfer resources and consequently their business plans.

Before the request is submitted, the RIPE NCC should explicitly inform the party that intends to transfer resources that this information will be published and obtain their agreement to this.

There would be no such issue if this information were anonymised (i.e., not revealing the name of the transferring party and referring to the size of the block to be transferred instead of the block itself).