Re: [sig-policy] prop-077: Proposal to supplement transfer policy of his
After going through the revised version again, a new question came up to me.
It only seems defines transfer between APNIC account-holders and there
are no clear definitions of inter-registry transfers.
I recall there was substantial support for inter registry transfers in
Manila, especially allowing transfers betweeen LIRs under an NIR and
direct APNIC LIRs.
Could I confirm if inter NIR-APNIC transfers will be allowed with the
revised version if NIR adopts the transfer proposal and agrees with the
inter registry transfer?
izumi
Ren-Hung Hwang wrote:
>> Message: 2
>> Date: Wed, 29 Jul 2009 09:11:54 +0200
>> From: Randy Bush <randy at psg dot com>
>> Subject: [sig-policy] prop-077: Proposal to supplement transfer policy
>> of historical IPv4 addresses
>> To: Policy SIG <sig-policy at apnic dot net>
>> Message-ID: <m2fxcg0xqd.wl%randy at psg dot com <m2fxcg0xqd.wl%25randy at psg dot com>>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> 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 at cnnic dot cn>
>>
>> Jane Zhang
>> <zhangjian at cnnic dot cn>
>>
>>
>> Terence Zhang Yinghao
>> <zhangyinghao at cnnic dot 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.
>
>
> (1) Will the transferred address remains the status of "historical address"
> or not?
> (2) I second that the recipient of a transfer of historical IPv4 address
> must
> justify use of the transferred space, but I think it is better that APNIC
> reclaim (recover) historical address based on current policy.
> (prop-017 Recovery of unused address space)
> (3) Since they are historical resources, why should we consider the "final
> /8"
> policy?
> Ren-Hung
>
>
>>
>>
>> 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
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 29 Jul 2009 09:12:23 +0200
>> From: Randy Bush <randy at psg dot com>
>> Subject: [sig-policy] prop-078: Reserving /10 IPv4 address space to
>> facilitate IPv6 deployment
>> To: Policy SIG <sig-policy at apnic dot net>
>> Message-ID: <m2eis00xpk.wl%randy at psg dot com <m2eis00xpk.wl%25randy at psg dot com>>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> Dear SIG members,
>>
>> The proposal, 'Reserving /10 IPv4 address space to facilitate IPv6
>> deployment', 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-078-v001: Reserving /10 IPv4 address space to facilitate IPv6
>> deployment
>> ________________________________________________________________________
>>
>>
>> Authors: Terence Zhang Yinghao
>> <zhangyinghao at cnnic dot cn>
>>
>> Jane Zhang
>> <zhangjian at cnnic dot cn>
>>
>> Wendy Zhao Wei
>> <zhaowei at cnnic dot cn>
>>
>> Version: 1
>>
>> Date: 29 July 2009
>>
>>
>>
>> 1. Introduction
>> ----------------
>>
>> This proposal seeks to ensure some small blocks of IPv4 space will
>> remain available to LIRs for a long time to ease the co-existence of
>> IPv4 and IPv6 and to facilitate IPv6 deployment.
>>
>> It is proposed that when APNIC receives its last /8 IPv4 allocation from
>> IANA, a contiguous /10 IPv4 block will be set aside and dedicated to
>> facilitate IPv6 deployment.
>>
>>
>> 2. Summary of the current problem
>> ----------------------------------
>>
>> The IPv4 address pool is expected to be depleted in the near future, but
>> the Internet will still use IPv4 for many years during the adoption of
>> IPv6, during this period, LIRs will need to connect to the IPv4 Internet
>> while they deploy services using the IPv6 Internet.
>>
>> APNIC's current "final /8" policy [1] prevents any one organization
>> consuming too many IPv4 address from the final /8, which ensure new LIRs
>> can participate in the IPv4 Internet. However, the final /8 policy
>> does not require LIRs to deploy IPv6. Therefore, it is possible that
>> LIRs use those allocated address entirely for IPv4 services. Later, when
>> they intend to deploy IPv6, they will have no chance to get another IPv4
>> allocation from APNIC under the "final /8" policy, even if there are
>> a certain amount of unallocated IPv4 addresses remaining in APNIC's
>> pool. Instead, the LIR would have to re-organize their IPv4 network to
>> set aside some addresses. This would impact their progress in IPv6
>> deployment.
>>
>> To remedy this problem, this policy proposal seeks to encourage LIRs to
>> deploy IPv6 and ensure IPv4 space will remain available for LIRs' IPv6
>> deployment.
>>
>>
>> 3. Situation in other RIRs
>> ---------------------------
>>
>> ARIN has adopted a similar policy:
>>
>> 2008-5: Dedicated IPv4 block to facilitate IPv6 Deployment
>> https://www.arin.net/policy/proposals/2008_5.html
>>
>> RIPE has similar policy proposal under discussion:
>>
>> 2009-04: IPv4 Allocation and Assignments to Facilitate IPv6
>> Deployment
>> http://www.ripe.net/ripe/policies/proposals/2009-04.html
>>
>> AfriNIC and LACNIC currently have no similar policies or proposals.
>>
>>
>> 4. Details
>> -----------
>>
>> It is proposed that when APNIC receives its last /8 IPv4 allocation from
>> IANA, a contiguous /10 IPv4 block from the /8 will be set aside and
>> dedicated to facilitate IPv6 deployment.
>>
>> Allocations and assignments from this dedicated /10 block must be
>> justified by immediate IPv6 deployment needs; examples of such needs
>> include: IPv4 addresses for key dual stack devices, NAT-PT or NAT464
>> translators, etc.
>>
>> The size of each allocation from this /10 block is /24, or APNIC's
>> minimum allocation size in force at time of the allocation, which ever
>> is smaller.
>>
>> Each LIR may apply for and receive the specified allocation size
>> regardless of LIR size or intended membership tier.
>>
>> In order to receive a first allocation or assignment under this policy:
>>
>> 1. The applicant must demonstrate immediate IPv6 deployment needs,
>> especially for IPv6 to IPv4 internetworking.
>>
>> 2. The applicant must either have existing IPv6 addresses or valid
>> application for IPv6 addresses.
>>
>> 3. The applicant must be a current APNIC account holder or a member
>> of an NIR.
>>
>> In order to receive subsequent allocation or assignment under this
>> policy:
>>
>> 1. The applicant must demonstrate immediate IPv6 deployment needs,
>> especially for IPv6 to IPv4 internetworking.
>>
>> 2. The applicant may not have received resources under this policy
>> in the preceding 12 months.
>>
>> 3. Previous allocations/assignments under this policy must be
>> strictly used to facilitate IPv6 deployment, and the utilization
>> rate is higher than 75%;
>>
>> 4. The utilization rate of previous allocations/assignments of other
>> IPv4 addresses allocated from APNIC must reach 80%, or APNIC's
>> current IPv4 allocation policy required utilization rate at the
>> time of the allocation.
>>
>> 5. The applicant must be a current APNIC account holder or a member
>> of an NIR.
>>
>>
>> Allocations under this policy do not affect an LIR's eligibility to
>> apply for IPv4 addresses under the "final /8' policy", and vice versa.
>>
>>
>> 5. Pros/Cons
>> -------------
>>
>> 5.1 Advantages:
>>
>> - This proposal will encourage IPv6 deployment as it ensures LIRs
>> can receive dedicated IPv4 address space from the APNIC if they
>> have an immediate need to deploy IPv6.
>>
>> - The dedicated /10 block provides 16,384 allocations, which ensures
>> that no organization lacks IPv4 address space for IPv6 deployment
>> for many years.
>>
>>
>> 5.2 Disadvantages:
>>
>> - There is a remote possibility that, after setting aside one /10
>> under this proposal, the remainder of the last /8 may be used
>> up. If that were to happen, LIR would need to have immediate IPv6
>> deployment needs to qualify for IPv4 addresses from APNIC.
>>
>> However, with 12,288 possible allocations from the current minimum
>> allocation (at time of writing), and considering that the
>> projection of APNIC members in 2013 is 4000, it is not likely the
>> 12,288 allocations will be used up. In addition, if it does
>> happen, applying for IPv4 address without any intent to deploy
>> IPv6 is not practical.
>>
>> Also, the size of allocation under this policy (/24) can be
>> reduced to suit future needs, if necessary.
>>
>>
>> 6. Effect on APNIC members
>> ---------------------------
>>
>> This proposal allows APNIC LIRs (existing and new) to receive dedicated
>> IPv4 address space from APNIC to facilitate IPv6 deployment.
>>
>>
>> 7. Effect on NIRs
>> ------------------
>>
>> This proposal has no direct impact to NIRs. NIR members (existing and
>> new) can receive dedicated IPv4 address space from APNIC to facilitate
>> IPv6 deployment.
>>
>>
>> 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
>>
>>
>> 9. Appendix A
>> -------------
>>
>> Reason for reserving a contiguous /10
>>
>> The IPv6 Internet may take a long time to develop, and since IPv4
>> and IPv6 may co-exist for many years, the demand for IPv6 to IPv4
>> internetworking will be sustained for many years.
>>
>> The intention of the proposal is to stimulate native IPv6 deployment
>> as much as possible, while supporting the need for IPv6 networks to
>> communicate with the IPv4 world.
>>
>> The current policy for allocations from the "final /8" will provide
>> 16384 allocations. Setting aside a /10 from that /8 will reduce the
>> allocations to 12288. Since currently APNIC has about 2000 members
>> and is projected to have 4000 members in 2013, it is feasible to set
>> aside a /10 to encourage and ensure IPv6 deployment.
>>
>> The dedicated /10 block itself can provide 16384 allocations with
>> the /24 maximum allocation size. This, in addition to the
>> requirements of a 12-month interval between allocations from this
>> block and a 75% utilization rate for previous allocations from this
>> /10 before additional allocations from this block can be made, would
>> prevent hoarding and ensure this pool will last many years.
>>
>>
>> Reason for /24 allocation size
>>
>> Allocations under this policy are mainly for IPv6 to IPv4
>> internetworking purpose, such as IPv4 addresses for key dual stack
>> devices, NAT-PT or NAT464 translators, etc. Therefore, we need only
>> a few addresses to do the job. In most cases we can foresee, a /24,
>> or even a /27, can perfectly satisfy the deployment needs for one
>> organization.
>>
>> The reason we choose /24 is we do not want to create longer prefixes
>> in the Internet routing table just because of this policy. Based on
>> knowledge of current Internet's route filtering culture, we believe
>> /24 is the most generally accepted longest prefix currently.
>>
>> Of course, it is possible routing practices will change when we are
>> running out of IPv4. Therefore, in the future, if longer route
>> prefixes are more generally accepted, or a smaller minimum
>> allocation size takes effect, we can certainly reduce the size of
>> allocation under this policy to suit future needs, and ensure more
>> allocations from this block are possible.
>>
>> Finally, a relatively larger allocation size will minimize the
>> possibility of an organization getting multiple non-contiguous small
>> blocks in multiple allocations.
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> sig-policy mailing list
>> sig-policy at lists dot apnic dot net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>>
>> End of sig-policy Digest, Vol 62, Issue 20
>> ******************************************
>>
>
>
>
>
> ------------------------------------------------------------------------
>
> * 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