Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default
Hi Owen,
Thank you for your useful suggestions.
| 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
I'll mention these advantages in my presentation slides (and in the proposal
text if I need to revise the proposal text).
Yours Sincerely,
--
Tomohiro Fujisaki
From: Owen DeLong <owen at delong dot com>
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 <asjl at lpnz dot org> 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
| > fujisaki at syce dot net
| >
| >
| > 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
| > sig-policy at lists dot apnic dot net
| > http://mailman.apnic.net/mailman/listinfo/sig-policy
|