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

  • To: owen at delong 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: Wed, 29 Jan 2014 11:48:27 +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=3Hpq6XP9JQnnJkKCpiFJvSIZG6oN8DzmIgs/vQYFHAY=; b=cP6PAqGiD9DvjzbR+Uust/mepQWysPtpERuN+/aclkpDs1Gu3I03GtT8pUctEFNoCVRscrgMUMxkK X1PJ1wPShZgrzTlocRPOdQWoINHSNAxtPAXFE2PCVZlMXtX4dmgGnKtmy32rLQgk7TRpkntvJbNHjs SN/rGguQyJMNx9eM=
  • In-reply-to: <68EF2921-4F7D-42E3-9A7D-8A88E8BB76C0 at delong 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> <68EF2921-4F7D-42E3-9A7D-8A88E8BB76C0@delong.com>
    • 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
       |