Dear SIG members
The policy proposal 'Reapplication limits when transferring 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-072-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-072: Reapplication limits when transferring 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 not permitting organisations who have transferred IPv4
address from obtaining more address space from APNIC for a period of
24
months after the transfer.
2. Summary of current problem
------------------------------
Prop-050, "IPv4 address transfers", as it stands at time of writing,
places no restriction on the organisation transferring IPv4 address
space to return to APNIC for additional IPv4 address space.
This gives organisations the opportunity to transfer their IPv4
address
space to another organisation, and return to APNIC almost immediately
with a fully justified application for additional resources. This
means
that organisations could rapidly deplete the remaining IPv4 pool, 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 places no limits on any
organisation transferring address space to a third party from going
back to the RIPE NCC for further IPv4 address space. See:
http://www.ripe.net/ripe/policies/proposals/2007-08.html
ARIN
The transfer policy notes that transfers of address space between
organisations are only considered if the originating organisation
has
made a complete transfer of assets to the recipient (such as a
liquidation of the originating organisation). See:
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 organisations disposing of their space using the
transfer policy described in prop-050, "IPv4 address transfers", are
not
eligible for APNIC IPv4 assignments and/or allocations for two years.
5. Advantages and disadvantages of the proposal
------------------------------------------------
5.1 Advantages
- Organisations transferring address space to third parties can
not
go back to APNIC and request additional IPv4 address space for a
period of 24 months. This prevents organisations from making
frequent and repeated requests to APNIC, and then transferring
the address space elsewhere.
5.2 Disadvantages
- None.
6. Effect on APNIC Members
---------------------------
The proposal impacts all APNIC members in that they now cannot receive
more address space from the APNIC free pool for a full 24 months after
they have made a transfer to another organisation.
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.
* 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