Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default
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/èå æå) <fujisaki at syce dot net> 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 <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
> |