Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
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@cnnic.cn
Jane Zhang zhangjian@cnnic.cn
Wendy Zhao Wei zhaowei@cnnic.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.
Terence, Jane and Wendy,
I read the policy with substantial interest, I have some comments on the policy, and the wording of the policy.
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.
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.
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)
4) I like the concept in the RIPE proposal about actually demonstrating a v6 _service_ to be eligible. As distinct from need.
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)
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.
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.
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?
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.
10) What are your feelings on a member sub-allocating this range to their customers? allow? disallow? conditional?
Otherwise, in essence, generally I'm in support of the idea.
Cheers Terry
On 29/07/2009, at 5:12 PM, Randy Bush wrote:
Information about this and other policy proposals is available from:
http://www.apnic.net/policy/proposalsRandy, Jian and Ching-Heng
prop-078-v001: Reserving /10 IPv4 address space to facilitate IPv6 deployment ________________________________________________________________________
Authors: Terence Zhang Yinghao zhangyinghao@cnnic.cn
Jane Zhang <zhangjian@cnnic.cn> Wendy Zhao Wei <zhaowei@cnnic.cn>Version: 1
Date: 29 July 2009
- 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.
- 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.
- 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.htmlRIPE 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.htmlAfriNIC and LACNIC currently have no similar policies or proposals.
- 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 amember 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 theutilization rate is higher than 75%;
4. The utilization rate of previous allocations/assignments ofother 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 amember 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.
- 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, whichensures 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 immediateIPv6 deployment needs to qualify for IPv4 addresses from APNIC.
However, with 12,288 possible allocations from the currentminimum 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.
- Effect on APNIC members
This proposal allows APNIC LIRs (existing and new) to receive dedicated IPv4 address space from APNIC to facilitate IPv6 deployment.
- 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.
- 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
- 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 IPv6deployment 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" willprovide 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 fromthis /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 needonly 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 longerprefixes 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 weare 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-contiguoussmall blocks in multiple allocations.
sig-policy: APNIC SIG on resource managementpolicy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
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@cnnic.cn
Jane Zhang <zhangjian@cnnic.cn> Wendy Zhao Wei <zhaowei@cnnic.cn>Version: 1
Date: 29 July 2009
- 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.
- 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.
- 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.htmlRIPE 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.htmlAfriNIC and LACNIC currently have no similar policies or proposals.
- 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.
- 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.
- Effect on APNIC members
This proposal allows APNIC LIRs (existing and new) to receive dedicated IPv4 address space from APNIC to facilitate IPv6 deployment.
- 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.
- 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
- 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@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Although I agree with the principle suggested in this proposal of using IPv4 addresses from the final /8 to encourage and facilitate IPv6 deployment, I suspect that the restriction on allocations for this purpose to /24 may greatly limit the value of the proposal.
My concern is that 256 v4 addresses may not be of sufficient scale to enable any significant facilitation of the introduction of v6, and this may be purely due to my lack of knowledge of such techniques.
I would therefore appreciate it if an author of the proposal could suggest an example of the possible circumstances, technologies and per-v4-address ratios that might be used, to demonstrate a method by which a single /24 could provide facilitation in the introduction of IPv6 for up to 50,000 users (purely as an example of moderate number of users that might be handled in the first instance by a medium ISP).
With many thanks,
David Woodgate
At 05:12 PM 29/07/2009, Randy Bush wrote:
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/proposalsRandy, Jian and Ching-Heng
prop-078-v001: Reserving /10 IPv4 address space to facilitate IPv6 deployment ________________________________________________________________________
Authors: Terence Zhang Yinghao zhangyinghao@cnnic.cn
Jane Zhang <zhangjian@cnnic.cn> Wendy Zhao Wei <zhaowei@cnnic.cn>Version: 1
Date: 29 July 2009
- 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.
- 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.
- 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.htmlRIPE 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.htmlAfriNIC and LACNIC currently have no similar policies or proposals.
- 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.
- 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.
- Effect on APNIC members
This proposal allows APNIC LIRs (existing and new) to receive dedicated IPv4 address space from APNIC to facilitate IPv6 deployment.
- 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.
- 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
- 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 managementpolicy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Activity Summary
- 5152 days inactive
- 5152 days old
- sig-policy@lists.apnic.net
- 4 participants
- 3 comments