Frankly, I believe it is better to issue additional /28s or /24s or whatever is needed and leave those blocks unallocated. Organizations which have not started deploying their /32 could return the unused /32 and deploy initially using the larger block from the sparse allocation pool.
The small number of /29s that are reserved in this way (even smaller if people not using their /32s return them and most returned /32s enable a /28 to be issued) really isn’t a problem in the grand scheme of IPv6. Owen On Jan 28, 2014, at 6:48 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) <[email protected]> wrote: > > 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
