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

  • To: "(Tomohiro -INSTALLER- Fujisaki/èå æå)" <fujisaki at syce dot net>
  • Subject: Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size
  • From: Owen DeLong <owen at delong dot com>
  • Date: Tue, 28 Jan 2014 22:39:49 -0800
  • Cc: "sig-policy at apnic dot net SIG List" <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:x-dkim:dkim-signature:content-type:mime-version:subject: from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to: x-mailer:x-greylist; bh=P0swbA71Mqg7MmkQNP8hyNPQMxu4cSUEv++GjbG14Kw=; b=Cy26YIgp11CnYS+uzPjhwtPHrn/JHDVRO4oIBvU49c/u2HTV4IzZzDsdF9nlOd6tipLD1MBeT1bA6 n67dT4C6TUEGdurpt0a5VGBHxXifFtffpZg7QgBUM+QHCu6TXfGXd1myxEK8CXjZH85O/q1jKLUdJR ZohS/l4XG2Z2K2ao=
  • Dkim-signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1390977632; bh=FOgmhVfesjp2fTMT7nGVDe7/GMQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=5qwWwadUoPfl8oILnY53LiVCIWjYaWzoxw4nlyHvgJnpmPSu2x5sn6aBWDNSP+uFm LHJv2u5zsPBGha8Iba+gEHO2Fnj3mdshNHSVCOBGw1PjTMvQlqsXiZsfxNlYXa5qlr b/yhKatuCAuDRjL5ivzGRD4p8sWCk+hC6r5mj7wM=
  • In-reply-to: <20140129.114827.1805623808110966081.fujisaki at syce dot net>
  • 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> <20140129.114827.1805623808110966081.fujisaki@syce.net>
    • 
      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
      > |