Hi Owen, I'm sorry but I misread your commmet.
| If you're going to do this, I would rather see providers given the option of choosing a size | ranging from /28 to /32 with encouragement towards either end (/28 or /32). As Guangliang wrote in his mail, only /29 is reserved for organizations in earlyer allcation address block. Main purpose of this policy intend to utilize those address, which will be kept unused. Yorus Sincerely, -- Tomohiro Fujisaki From: Owen DeLong <[email protected]> Subject: Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size Date: Sat, 25 Jan 2014 20:39:08 -0800 | If you're going to do this, I would rather see providers given the option of choosing a size | ranging from /28 to /32 with encouragement towards either end (/28 or /32). | | This has several advantages: | | 1. It reduces bitmath requirements. | 2. It simplifies DNS delegation for ip6.arpa zones | 3. It allows providers that simply don't need a larger allocation to choose the | size that best meets their needs. | 4. It simplifies APNIC's resource management process. | 5. It simplifies the request process and qualification requirements. | | Owen | | On Jan 25, 2014, at 17:22 , Andy Linton <[email protected]> wrote: | | > Dear SIG members | > | > The proposal "prop-111-v001: Request-based expansion of IPv6 default | > allocation size" has been sent to the Policy SIG for review. It will be | > presented at the Policy SIG at APNIC 37 in Petaling Jaya, Malaysia, on | > Thursday, 27 February 2014. | > | > 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 policy proposals is available from: | > | > http://www.apnic.net/policy/proposals/111 | > | > Andy, Masato | > | > ---------------------------------------------------------------------- | > prop-111-v001: Request-based expansion of IPv6 default allocation size | > ---------------------------------------------------------------------- | > | > Author: Tomohiro Fujisaki | > [email protected] | > | > | > 1. Problem statement | > -------------------- | > | > Currently, IPv6 minimum allocation size to LIRs is defined as /32 in | > the "IPv6 address allocation and assignment policy", while APNIC | > currently reserves up to /29 for each /32 allocation. It's better to | > expand this minimum allocation size up to /29 since: | > | > - For traffic control purpose, some LIRs announce address blocks | > longer than /32 (e.g. /35). However, some ISPs set filters to block | > address size longer than /32. If LIRs have multiple /32, they can | > announce these blocks and its reachability will be better than | > longer prefix. | > | > - If an LIR needs address blocks larger than /32, LIRs may tend to | > announce as a single prefix if a /29 is allocated initially at | > once. i.e., total number of announced prefixes in case 1 may be | > smaller 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 subsequent | > allocation mechanism. | > | > - Before sparse allocation mechanism implemented in late 2008, /29 | > was reserved for all /32 holders by sequence allocation mechanism | > in the early years. It is possible to use these reserved | > blocks efficiently with this modification. | > | > | > 2. Objective of policy change | > ----------------------------- | > | > This proposal modifies the eligibility for an organization to receive | > an 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 vs | > per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get | > up to /29 by default. | > | > | > 4. Proposed policy solution | > ---------------------------- | > | > - Change the text to "5.2.2 Minimum initial allocation size" of | > current policy document as below: | > | > Organizations that meet the initial allocation criteria are | > eligible to receive an initial allocation of /32. For allocations | > up 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 request | > extension of each of these allocations up to a /29 without meeting | > the utilization rate for subsequent allocation and providing | > further 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 of | > IPv6 space. However, the space up to /29 is reserved by APNIC | > secretariat 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 | > [email protected] | > http://mailman.apnic.net/mailman/listinfo/sig-policy | * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
