What is the rationale for tying this to 'final /8'?

yi

----- Original Message ---- From: Randy Bush randy@psg.com To: Policy SIG sig-policy@apnic.net Sent: Wednesday, July 29, 2009 3:11:54 AM Subject: [sig-policy] prop-077: Proposal to supplement transfer policy of historical IPv4 addresses

Dear SIG members,

The proposal, 'Proposal to supplement transfer policy of historical IPv4 addresses', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 28 in Beijing, China, 25-28 August 2009.

We invite you to review and comment on the proposal on the mailing list before the meeting.

The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to express your views on the proposal:

- Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective?

Information about this and other policy proposals is available from:

http://www.apnic.net/policy/proposals

Randy, Jian and Ching-Heng

________________________________________________________________________

prop-077-v001: Proposal to supplement transfer policy of historical IPv4 addresses ________________________________________________________________________

Authors: Wendy Zhao Wei zhaowei@cnnic.cn

Jane Zhang zhangjian@cnnic.cn

Terence Zhang Yinghao zhangyinghao@cnnic.cn

Version: 1

Date: 29 July 2009

1. Introduction ----------------

This policy proposal seeks to supplement current policy for the transfer of historical Internet resources, by requiring recipients of transferred historical IPv4 address space to justify its use or subjected to the justification criteria of transfer policy of current IPv4 resources.

2. Summary -----------

Under current policy, transfers of historical resources to current APNIC members are recognized and registered by APNIC; APNIC does not require any technical review or approval of the resource's current use to approve the transfer.

This may allow the opportunity for an organization to stockpile IPv4 address space without any actual demand, which is contrary to the current goal of address space management.

3. Situation in other RIRs ---------------------------

AfriNIC:

If an LIR plans to exchange or transfer address space, it needs to contact AfriNIC so that the changes are properly registered. The LIR remains responsible for all the allocations registered in the AfriNIC database until they have been transferred to another LIR or returned to AfriNIC. There is no requirement to justify the transfer.

ARIN:

ARIN has two different transfer policies:

1. Mergers and acquisitions

Under this policy, organizations must show documentation that justifies use of the resources. However, organizations do not need to meet the current criteria for receiving IPv4 addresses to justify the transfer of historical space as part of a merger or acquisition. The recipient has the option of signing either the Legacy Resource Services Agreement or the standard Resource Services Agreement.

2. Transfers to specified recipients

Under this policy, historical resources, like current resources, must first be returned to ARIN. The space can be transferred only if the recipient can demonstrate the need for the resources under current ARIN policies. The recipient must sign the standard Resource Services Agreement.

LACNIC:

LACNIC permits transfers of historical IPv4 resources in cases of mergers and acquisitions only. Organizations must show documentation that they are not only transferring IP addresses but also equipment and end users of the IP addresses. In these cases, organizations do not need to meet the current criteria for receiving IPv4 addresses to justify the transfer of historical space as part of a merger or acquisition. Once historical resources have been transfered this way, they are considered to be "current".

RIPE:

Member LIRs can transfer complete or partial blocks of historical or current IPv4 addresses. Such address space must not contain any block that is assigned to an end user. An LIR may only receive a transferred allocation after their need is evaluated and approved by the RIPE NCC according to the existing allocation policies. LIRs that receive a transfer 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.

4. Details -----------

It is proposed to modify the current policy for the transfer of historical Internet resources, it is proposed that:

4.1 Until the allocation principles of the "final /8" policy [1] take effect, transfers of historical IPv4 address must meet the justification criteria of applied to transfers of current IPv4 address space, if such a policy exists;

4.2 If a transfer policy for current IPv4 transfers does not exist, then the recipient of a transfer of historical IPv4 address must justify use of the transferred space using the allocation and assignment policies in force at the time of the transfer.

4.3 After the allocation principles of the "final /8" policy [1] take effect, no justification is needed to transfer historical resources.

5. Pros/Cons -------------

5.1 Advantages

The utilization of historical IPv4 addresses will comply with address management policy for current resources.

5.2 Disadvantages

None.

6. Effect on APNIC members ---------------------------

All APNIC members will have to justify transfers of historical IPv4 addresses they receive, or subjected to justification criteria of transfer policy of current IPv4 resources.

7. Effect on NIRs ------------------

The proposal has no direct impact on NIRs, but impacts members of NIRs in the same way it impacts APNIC members.

8. References --------------

[1] See section 9.10, "Policies for IPv4 address space management in the Asia Pacific region" http://www.apnic.net/policy/add-manage-policy.html#9.10 * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy