Re: [sig-policy] prop-078: Reserving /10 IPv4 address space to facilitat
Philips,
Thanks for your comments on this Proposal.
I joined CNNIC after Oct.2008, so I miss the opportunity
to witness the wondulful discussion of the final /8 policy proposal;
Otherwise I may have learned something from it or gave some inputs.
Anyway, I believe the final /8 policy is fine, so when we design
this policy proposal, we try the best to avoid impact to
the adopted final /8 policy as much as possible.
We believe a /10 is relatively adequate reserve for IPv6 to IPv4
internetworking purpose (there are 16,384 allocations with /24
allocations size, and possibly more allocations with smaller allocation
size.)
And we also believe borrow a /10 from the final /8 will have little
impact to the allocations of the /8 under current policy. (there are still
12,032 possible allocations left). And this /10 is not excluded
from allocation, just add more restrictions in the purpose of using it.
So, I believe the final /8 policy, toghether with more restrictions
on the final /10, will constitute a perfect rule on how the
end game of IPv4 is going to be played.
Thanks for your comments again, and further comments and discussions
are welcome.
Terence Zhang
CNNIC
----- Original Message -----
From: "Philip Smith" <pfs at cisco dot com>
To: "Policy SIG" <sig-policy at apnic dot net>
Sent: Thursday, August 06, 2009 1:38 PM
Subject: Re: [sig-policy] prop-078: Reserving /10 IPv4 address space to facilitate IPv6 deployment
> Hi Terence, Jane, Wendy,
>
> Just thinking about this, would it perhaps be an idea instead to propose
> a policy that assignments or allocations should only be made from the
> final /8 if the organisation has a plan to use it to assist with IPv6
> deployment?
>
> The final /8 proposal that was adopted was intended to help with IPv6
> deployment without explicitly saying as much. I felt at the time that
> noting it in the policy was interfering too much with organisation's
> business practices. But given the discussions I've heard in other RIR
> regions, folks there seem to be taking a harder line than we did.
>
> FWIW, I've no problem with the /10 coming out of the final /8 worth of
> address space (but it won't worry me if it doesn't). The final /8 has
> 16128 /22s in it (excluding the future use /16) - and removing a /10 for
> IPv6 deployment would reduce this to 12032 /22s. Which I think is still
> significantly higher than the number of organisations who are APNIC or
> NIR account holders today...
>
> philip
> --
>
> Randy Bush said the following on 29/7/09 17:12 :
>>
>> ________________________________________________________________________
>>
>> 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: 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
>>
>
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net