Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default
Hi Jahangir,
Thank you for your comments.
From: Jahangir Hossain <jrjahangir at gmail dot com>
Subject: Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size
Date: Mon, 27 Jan 2014 01:23:23 +0600
| 5. Explain the advantages of the proposal
| -----------------------------------------
|
| - It will be possible for LIRs to control traffic easier.
|
| I think most of LIRs control traffic for present initial allocation .
In the global routing table, we find some /35, and some of them may be
used for traffic control purpose. Prefixes longer than /32 are
possibly filtered, since IPv6 minimum allocation size is /32.
Yours Sincerely,
--
Tomohiro Fujisaki
From: Jahangir Hossain <jrjahangir at gmail dot com>
Subject: Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size
Date: Mon, 27 Jan 2014 01:23:23 +0600
| 5. Explain the advantages of the proposal
| -----------------------------------------
|
| - It will be possible for LIRs to control traffic easier.
|
| I think most of LIRs control traffic for present initial allocation .
|
| - It is possible to use current reserved blocks efficiently.
|
| True .
|
| 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.
|
| True, specially for development phases . By considering justification might
| be encourage the efficient utilization but organization miss the
| opportunity of initial IPv6 allocation up to a /29 by request basis.
|
|
|
|
| On Sun, Jan 26, 2014 at 1:38 PM, Aftab Siddiqui <aftab.siddiqui at gmail dot com>wrote:
|
| >
| >
| > 5. Explain the advantages of the proposal
| > -----------------------------------------
| >
| > - It will be possible for LIRs to control traffic easier.
| > And I guess traffic is under control with existing minimum initial
| > allocation.
| >
| > - It is possible to use current reserved blocks efficiently.
| > The idea is to use the allocated block (no matter how big or small it is)
| > 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.
| >
| > No, the argument is nothing is broken here to be fixed. Option is already
| > there to request for larger then minimum initial allocation with proper
| > justification. If the need is there to have larger address block then
| > justification won't be an issue. The only purpose this policy serve is
| > remove the "Justification" portion.
| >
| > Regards,
| >
| > Aftab A. Siddiqui
| >
| >
| > On Sun, Jan 26, 2014 at 6:22 AM, 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
| >>
| >>
| >
| > * 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
| >
| >
|
|
| --
| Regards // Jahangir