Dear SIG members
The policy proposal 'Justifying receiving IPv4 address space' has been
sent to the Policy SIG for review. It will be presented at the Policy
SIG at APNIC 28 in Beijing, China, 24-28 August 2009. The proposal's
history can be found at:
http://www.apnic.net/policy/proposals/prop-071-v001.html
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?
Randy, Jian, and Ching-Heng
________________________________________________________________________
prop-071: Justifying receiving IPv4 address space
________________________________________________________________________
Author: Philip Smith
pfs at cisco dot com
Version: 1
Date: 10 March 2009
1. Introduction
----------------
This policy proposal seeks to supplement prop-050, "IPv4 address
transfers", by requiring recipients of transferred IPv4 address space to
justify its use.
2. Summary of current problem
------------------------------
Prop-050, "IPv4 address transfers", as it stands at time of writing,
places no requirement on the recipient of transferred IPv4 address space
to justify their need for the additional address space before APNIC
registers the transfer.
This can allow any organisation the opportunity to stockpile IPv4
address space, to the detriment of the entire industry during the IPv4
runout period.
3. Situation in other RIRs
---------------------------
RIPE NCC
The transfer policy adopted by RIPE only permits transfers to take
place if the recipient can justify the need for address space to the
RIPE NCC. Recipients of transfers cannot transfer any portion of that
address space to another organisation within 24 months. See:
http://www.ripe.net/ripe/policies/proposals/2007-08.html
ARIN
The transfer policy specifically states the justification conditions
under which transfers are permitted in the ARIN region - see section
8.2 at:
http://www.arin.net/policy/proposals/2007_8.html
LACNIC
LACNIC is currently discussing a transfer proposal:
LAC-2009-04 Transfer of IPv4 Blocks within the LACNIC Region
http://www.lacnic.net/documentos/politicas/LAC-2009-04-propuesta-en.pdf
AfriNIC has no transfer policy.
4. Details of the proposal
---------------------------
It is proposed that:
4.1 Until such a time when the prevailing APNIC IPv4 allocation
practice uses the "final /8" policy [1], the recipient of a
transfer is to justify use of transferred space using the
allocation and assignment policies in force at the time of the
transfer.
4.2 After that time, no justification is needed.
4.3 Recipients of transferred address space are not permitted to
transfer any portion of this address space to another
organisation for at least 24 months.
5. Advantages and disadvantages of the proposal
------------------------------------------------
5.1 Advantages
- Recipients of IPv4 address transfers will have to fully justify
receiving the address space, just as they do for any current
direct allocations or assignments from the APNIC pool.
5.2 Disadvantages
- None.
6. Effect on APNIC members
---------------------------
The proposal impacts all APNIC members in that they now will have to
fully justify transfers they receive under proposal-050.
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 at lists dot apnic dot net
http://mailman.apnic.net/mailman/listinfo/sig-policy