Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default

  • To: jrjahangir at gmail dot com
  • Subject: Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size
  • From: (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) <fujisaki at syce dot net>
  • Date: Tue, 28 Jan 2014 13:41:36 +0900 (JST)
  • Cc: sig-policy at apnic dot net
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:date:message-id:to:cc:subject:from:in-reply-to:references: x-mailer:mime-version:content-type:content-transfer-encoding:x-greylist; bh=8neXvOzOkNdIXNNC8qCC93F6nuLRWL2ObmdabxFTSPU=; b=iKLQDxoXuocNdNAXre9PXArQhlM7BBCgYXULer8CHKRICj7wpGoCwtbIcJHBUeszdcHzw2vvjWPOy 8z13bWX+aPj5KkYoPe9SsV0qX1xHDye/j06vXZ0kNc0dqp7GL7RrsJ5nTM+zUtSu3TABhECf/Di06s deIy70p616ToEtl8=
  • In-reply-to: <CAG5EbHLEBU3r=eioYhKb3WvbcLBfjrges00FEixkPjpTQF6_Rw at mail dot gmail dot com>
  • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy/>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/options/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • References: <CALS-_OpoaFyk-77ReARzYkyn_yVSe7Xc1Ktd6nML59+0AZE3wg@mail.gmail.com> <CAK5YLgdFm=6HkiASCgD0y60n50+OQNL=1CYW83MOuJ4+fDs=Mg@mail.gmail.com> <CAG5EbHLEBU3r=eioYhKb3WvbcLBfjrges00FEixkPjpTQF6_Rw@mail.gmail.com>
    • 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