A lot of this policy looks to compare the current APNIC situation with
that in other RIRs, I do not believe a difference in itself is a
reason to change policy. Just because it is done differently
elsewhere, while interesting, should not be a necessary and sufficient
condition for policy change within this region.
As with prop-99. I'd like to ask Sanjaya, is there a way to
accomodate this situation under the current policies.
For example, If a user were able to justify their needs for a two year
period, would the hostmasters support a transfer under the current
policies.
We can then see if there appears to be a problem.
- Summary of the current problem
The current APNIC transfer policy has a requirement for demonstrate a
need for transferred IPv4 addresses. The period of demonstrated needs
under the current operational practice is 12 months based on the
definition in Section 3.2, "Criteria for subsequent LIR delegations" in
the "Policies for IPv4 address space management in the Asia Pacific
region",
"Based on these factors, APNIC and NIRs will delegate address space to
meet the LIR's estimated needs for a period up to one year up to the
maximum allowed delegation under Section 3."
and this period was defined before the exhaustion.
On the other hand, ARIN allows transfers based on demonstrated needs up
to 24 months. This leads to difference in conditions of the transfer
between LIRs in the APNIC region and the ARIN region.
Furthermore, 12 months is also too short for transfers within the APNIC
region considering many xSPs plan their service and their addressing
requirements beyond one year.
- Situation in other RIRs
ARIN has a requirement for the period to be approved of IPv4 transfers
for recipients under demonstrated needs, up to 24 months. LACNIC has a
policy that defines to evaluate for 12 months needs. RIPE NCC has 3
months requirement at this time, and the policy proposal that extend to
24 months, is under discussion.
AfriNIC:
AfriNIC currently does not have an IPv4 address transfers policy.
ARIN:
ARIN policy has a clear period for justification for IPv4 address
transfers, and the period is 24 months.
"Such transferred number resources may only be received under RSA by
organizations that are within the ARIN region and can demonstrate the
need for such resources in the amount which they can justify under
current ARIN policies showing how the addresses will be utilized within
24 months."
See Section 8.3, "Transfers to Specified Recipients" in the "ARIN Number
Resource Policy Manual":
https://www.arin.net/policy/nrpm.html#eight3
This change was proposed by "DRAFT POLICY ARIN-2012-1: CLARIFYING
REQUIREMENTS FOR IPV4 TRANSFERS".
https://www.arin.net/policy/proposals/2012_1.html
LACNIC:
LACNIC policy defines to evaluate for 12 months needs for the recipient
of the IPv4 address transfer. However, the transfer will only be
activate once LACNIC's address pool runs out. (expect for the reserved
space)
See Section 2.3.2.13, "Submission of Assignment Information" and Section
2.3.2.18.2, "Transfer of IPv4 Blocks within the LACNIC Region" in the
LACNIC Policy Manual (v1.9):
http://lacnic.net/en/politicas/manual3.html
RIPE:
In the RIPE region, the period of needs approved for IPv4 address
transfers will be based on the definition of the current allocation
policy, which is 3 months.
Currently, there is no policy which defines the period of needs based
justification, specifically for IPv4 transfers, separate from allocation
criteria. See Section 5.0, "Policies and Guidelines for Allocations" in
the RIPE-553, "IPv4 Address Allocation and Assignment Policies for the
RIPE NCC Service Region:"
http://www.ripe.net/ripe/docs/ripe-553/
However, there is a policy proposal under discussions which proposes to
extend the period of the demonstrated needs in case of IPv4 transfers,
up to 24 months. See 2012-03, "Intra-RIR Transfer Policy Proposal".
http://www.ripe.net/ripe/policies/proposals/2012-03
- Details
This proposal clarifies the requirement on a period approved for the
transferred resource to recipients of IPv4 transfers based on the
demonstrated needs, and defines its period as "24 months".
In case of Inter-RIR transfer, when there is a RIR which defines a
period longer than 24 months in the future, the longer period adopted by
the other RIR will be adopted.
This proposal does not intend to change the requirement for an address
allocation or assignment.
- Pros/Cons
Advantages:
- Extended period will allow the larger block size to match a longer
term needs of the requester. It will help to reduce an IPv4
address block fragmentation caused by transfer.
- APNIC member can apply for IPv4 address transfer as a receiver on
the same condition of demonstrate a need in other RIR in case of
Inter-RIR transfer. At this time, ARIN is the only RIR that adopts
Inter-RIR policy in place other than APNIC. Thus, it places APNIC
policy in line with ARIN on the transfer conditions.
- It will allow the block size to more closely match the block size
available for transfer from source
- It will reduce the risk of underground IPv4 address transfers,
which do not get registered in APNIC database. There is a
possibility that the recipients could not obtain justification for
enough IPv4 address by the current period of demonstrated needs.
Disadvantages:
- None
There may be people who feel 24 months does not lead to efficient
utilization compared to 12 months.
However, the objective of needs based justification is not to "cut
the size of address space to be transfered"; it is to ensure that
the transfered space will be utilized in realities. 24 months is a
realistic period to estimate required address space for xSPs.
- Effect on APNIC Members
It will requires a recipients within the APNIC region must demonstrate
the need for up to a 24 months use of IPv4 address block.
If there is a RIR which defines a period longer than 24 months, the
recipients may use the longer period to demonstrate its demand for an
Inter-RIR transfer from that RIR.
- Effect on NIRs
It is the NIR's choice as to whether to adopt this policy.
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy