Re: [sig-policy] prop-078: Reserving /10 IPv4 address space to facilitat
Thanks for your comments on this proposal, your advices are really helpful.
In general, the key point of this proposal is to reserve relatively adequate
space for IPv6 to IPv4 internetworking,
'whether this block come from the final /8 or not'
and 'whether the allocation size is /24 or /26';
Those are not that critical in this proposal, what we propose is what we
consider is better to represent the current situation and what we can foresee
from now.
Here are explanations to some of your comments, your further comments
are welcome:
> 1) While you elude to to the possibility of a longer prefix in both
> the appendix and disadvantages, I think it is highly likely that a
> change in routing practice will occur (unfortunately) and longer
> prefixes will find their way into the DFZ. I urge a consideration to
> limit the prefix length of that block to a /27 or /28.
As we mentioned in the appendix 'reason for /24', we can expect routing
practices will change when we are running out of IPv4, but we don't
know when and how this is going to happen, so we don't want
to create longer prefixes just because of this policy.
We believe /24 is the most generally accepted longest prefix currently,
that's why we choose /24, it's also consistent with the minimum size
of the transfer proposal.
As we mentioned in the 'reason for /24', 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.
>
> 2) Specifying that this block is taken from the final /8 is perhaps
> restrictive. I suggest leaving it to the secretariat to decide which
> block this /10 is taken from.
First of all, whether the reserved block come from the final /8 or not
doesn't impact the spirit of this proposal, I also believe it's more
flexible to leave it to the secretariat to decide which block this /10
is taken from.
Secondly, This is a balance between setting aside too much space and
not having enough for IPv6 deployment. Although it's not necessary,
we recommend to reserve this /10 from the final /8 because of
the following:
1. If we reserve the /10 from outside the final /8, then, together with
the final /8 policy, totally /8+/10 will be exluded from normal
IPv4 allocation, which means less addresses available for IPv4 services.
2. Current /8 policy 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.
So we believe setting aside a /10 from the final /8 will have little
impact to the final /8 allocations under current policy.
So, we believe reserving the /10 from the final /8 has less impact to the
current policy and allocation status.
>
> 3) If a transfers policy is adopted, I would suggest that if a member
> (or nir member) transfers v4 address space to another organisation and
> holds a 'ipv6 deployment' allocation from this policy, that the 'ipv6
> deployment' allocation is automatically recovered by APNIC.
> (eg the member has just proven their ability to renumber)
>
If I understand you correctly, your goal is to prevent people from
address trading, I appreciate that idea.
But the purpose of the IPv4 allocations under this policy and
other IPv4 allocations are different,
IPv4 allocations under this policy are
for 'IPv6 to IPv4 interconnect', while
other IPv4 allocations are for IPv4 services,
There for, I don't think we need to question the eligibility for
an organization to receive IPv4 for IPv6 deployment just because
they give up some IPv4 addresses for normal IPv4 services.
Although this allows the possibilities of trading, since the allocation
size under this policy is only /24, the incentives to make profit
from this block is not high.
Finally, even current proposed transfer policy will remove
justification and re-application limit when APNIC start using the
final /8 allocation, so I don't think we need restriction
for transfer in this proposal.
> 5) Should the automatic v6 allocation proposal be adopted, the second
> point in section 4 might become superfluous. (yes - adoption of that
> policy is not a given)
I agree with your assumption.
>
> 6) I question your assurance that no organisation will lack ipv4 for
> ipv6 deployment given an organisation may have several of these
> allocations. But that might just be a cynical view.
>
As we mentioned in the appendix, In most cases we can foresee, a /24,
can perfectly satisfy the deployment needs for one organization.
There for we don't expect an organization getting multiple /24s
under this policy, but we have to allow that possibility, since
there might be some special situation we cannot foresee from now.
So this proposal allow subsequent allocations, but restrict that
with 12 months interval and 75% utilization rate, and this 75%
utilization rate is restricted to facilitate IPv6, NOT IPv4 services.
Of course, theoretically, this proposal DOES NOT guarantee
'no organisation will lack ipv4 for hundred years', but practically
speaking, with 16384 allocations, together with 12 months
reapplication interval and 75% untilization rate, also
consider current APNIC members projection, we can
expect this pool can support the needs for IPv6 to IPv4
internetworking for at least 10-20 years.
I also want to point out that the demand for IPv6 to IPv4
internetworking will be stable at a certain point. Since V4's
growth will be limited by address resources, and as V6 grows
to a certain scale, the needs for communicate with V4
will be kept in a certain level .
> 7) I am hedging to say that an allocation of this sort should be time
> based. How much time? hard to say given that v6 deployment should have
> been done by now. But holding a 'transition' allocation indefinitely
> dilutes an incentive to actually transition.
>
I would say, even if the world move to IPv6 tomorrow, the demand for
IPv6 to IPv4 internetworking will be sustained for many years.
Investment protection is a very important rule in the IT industry,
I believe there are still legacy IBM server running SNA over
TCP/IP at present time.
> 8) why do you have the restriction on eligibility if the member has
> received an allocation in the last 12 months? wouldn't your following
> rule about 80% utilisation cover it?
>
As what I said in responding your comment 6), In most cases we can foresee,
a /24 can perfectly satisfy the V6/V4 interconnect needs for one
organization. There for we don't expect many subsequent allocations
going on, but we have to allow that possibility.
12 months interval and 75% untilization rate is to prevent one
organization consuming too many blocks from this /10.
> 9) I don't think I read anywhere in this proposal that sparse
> allocation methods must be used. Regardless of the prefix length I
> think we would want to give members every opportunity to aggregate if
> multiple allocations are issued to a member.
>
I agree with you sparse allocation is a good method to allow aggregation,
We didn't mention sparse allocation method because of the following:
1. We believe the secretariat will make allocation with best practise
2. we don't expect too many subsequent allocation
If most people believe we have to explicitly point out sparse allocation
in this proposal, we are happy to do that.
> 10) What are your feelings on a member sub-allocating this range to
> their customers? allow? disallow? conditional?
>
At this point, although we think sub-allocating a /24 is not practical,
I would consider sub-allocating is welcome as long as they follow
the rule of 'facilitate IPv6 deployment' and their route to the
global routing table is a single /24.
Thanks for your comments again, and further comments and discussions
are welcome.
Terence Zhang
CNNIC
>> ________________________________________________________________________
>>
>> 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