Given the pre-allocation practice already in place, I support this proposal.
...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd [email protected] ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; <http://twitter.com/networkceoau> linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering On Sun, Jan 26, 2014 at 12:22 PM, 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
