Dear SIG members
The proposal "prop-111-v001: Request-based expansion of IPv6 defaultallocation size" has been sent to the Policy SIG for review. It will bepresented at the Policy SIG at APNIC 37 in Petaling Jaya, Malaysia, onThursday, 27 February 2014.
We invite you to review and comment on the proposal on the mailing listbefore the meeting.
The comment period on the mailing list before an APNIC meeting is animportant part of the policy development process. We encourage you toexpress 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 moreeffective?
Information about this policy proposals is available from:
Andy, Masato
----------------------------------------------------------------------prop-111-v001: Request-based expansion of IPv6 default allocation size----------------------------------------------------------------------
Author: Tomohiro Fujisaki
1. Problem statement--------------------
Currently, IPv6 minimum allocation size to LIRs is defined as /32 inthe "IPv6 address allocation and assignment policy", while APNICcurrently reserves up to /29 for each /32 allocation. It's better toexpand this minimum allocation size up to /29 since:
- For traffic control purpose, some LIRs announce address blockslonger than /32 (e.g. /35). However, some ISPs set filters to blockaddress size longer than /32. If LIRs have multiple /32, they canannounce these blocks and its reachability will be better thanlonger prefix.
- If an LIR needs address blocks larger than /32, LIRs may tend toannounce as a single prefix if a /29 is allocated initially atonce. i.e., total number of announced prefixes in case 1 may besmaller than in case 2.
case 1:The LIR obtains /29 at the beginning of IPv6 network construction.
case 2:The LIR obtains /32, and /31, /30 additionally with the subsequentallocation mechanism.
- Before sparse allocation mechanism implemented in late 2008, /29was reserved for all /32 holders by sequence allocation mechanismin the early years. It is possible to use these reservedblocks efficiently with this modification.
2. Objective of policy change-----------------------------
This proposal modifies the eligibility for an organization to receivean initial IPv6 allocation up to a /29 by request basis.
3. Situation in other regions-----------------------------
RIPE-NCC:The policy "Extension of IPv6 /32 to /29 on a per-allocation vsper-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can getup to /29 by default.
4. Proposed policy solution----------------------------
- Change the text to "5.2.2 Minimum initial allocation size" ofcurrent policy document as below:
Organizations that meet the initial allocation criteria areeligible to receive an initial allocation of /32. For allocationsup to /29 no additional documentation is necessary.
- Add following text in the policy document:
for Existing IPv6 address space holders
LIRs that hold one or more IPv6 allocations are able to requestextension of each of these allocations up to a /29 without meetingthe utilization rate for subsequent allocation and providingfurther documentation.
5. Explain the advantages of the proposal-----------------------------------------
- It will be possible for LIRs to control traffic easier.- It is possible to use current reserved blocks efficiently.
6. Explain the disadvantages of the proposal--------------------------------------------
Some people may argue this will lead to inefficient utilization ofIPv6 space. However, the space up to /29 is reserved by APNICsecretariat for each /32 allocation.
7. Impact on resource holders-----------------------------NIRs must implement this policy if it is implemented by APNIC.
* 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