[sig-policy] Fwd: [Sig-policy-chair] DRAFT### Returned to SIG: prop-111:

  • To: SIG policy <sig-policy at apnic dot net>
  • Subject: [sig-policy] Fwd: [Sig-policy-chair] DRAFT### Returned to SIG: prop-111: Request-based expansion of IPv6 default allocation size
  • From: Andy Linton <asjl at lpnz dot org>
  • Date: Mon, 3 Mar 2014 17:22:56 +1300
  • 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:dkim-signature:x-google-dkim-signature:x-gm-message-state: x-received:mime-version:received:in-reply-to:references:from:date:message-id: subject:to:content-type; bh=6u6n1MH4rG6UCnIP6eus5SzXA2jKq/9RApJ8wGHbik4=; b=PIRS4NVJReYK3Y4aJ0Db85UwUkgSJ65EgSwfUmfRR8UTT5wWp+hAPpPsYfMWvD7S1Ti1WRZxbieVD ld6bo8OTrh5oxzMUmjVvDy1rfGBSOovyRfJextS2/UuPvpDxtKopflA8izw9TvycAxGajw/MyyO+65 xwD11j6cUZXJLkmg=
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lpnz.org; s=dkim; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=6u6n1MH4rG6UCnIP6eus5SzXA2jKq/9RApJ8wGHbik4=; b=jZ/L8taSOw6xiTeunbrQTlrnVOX4gFgZey1RsyVFw4HZmyihNrtD8cBHvm3N7GZc8S wa4s/k8Ge/gUIwvJU1hZvo72WliA0xWKGed8UOMmyY160PxC9jWjNTirdHWYy0UjBjUj KHq7LZEMCKP7zrD4JYrfaBLzSd75sgswDUEmw=
  • In-reply-to: <99F75E2B2B34CC43B21E446903FC0F7C88B5DE5A@NXMDA1.org.apnic.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: <99F75E2B2B34CC43B21E446903FC0F7C88B5DD7E@NXMDA1.org.apnic.net> <99F75E2B2B34CC43B21E446903FC0F7C88B5DE1F@NXMDA1.org.apnic.net> <99F75E2B2B34CC43B21E446903FC0F7C88B5DE5A@NXMDA1.org.apnic.net>
    • Dear colleagues

      Version 2 of prop-111: Request-based expansion of IPv6 default
      allocation size, did not reach consensus at the APNIC 37 Policy SIG.
      Therefore, this proposal is being returned to the author and the Policy
      SIG mailing list for further discussion.

      Proposal details

      This proposal modifies the eligibility for an organization to receive an
      initial IPv6 allocation up to a /29 by request basis.

      Proposal details including the full text of the proposal, history, and
      links to mailing list discussions are available at:

      ÂÂÂÂÂÂ http://www.apnic.net/policy/proposals/prop-111


      Andy and Masato

      prop-111-v002 Request-based expansion of IPv6 default allocation size

      Author:ÂÂÂÂÂÂ Tomohiro Fujisaki
      ÂÂÂÂÂÂÂÂÂÂÂÂÂ fujisaki at syce dot net

      1. Problem statement

      ÂÂ IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6
      ÂÂ address allocation and assignment policy"[1]. It's better to
      ÂÂ expand this minimum allocation size up to /29 (/32 - /29) since:

      ÂÂ - Before sparse allocation mechanism implemented in late 2006, /29
      ÂÂÂÂ was reserved for all /32 allocations by sequential allocation
      ÂÂÂÂ method made from those old /23 blocks. These reserved blocks
      ÂÂÂÂ might be kept unused in the future.

      ÂÂ - Sparse allocation mechanism was implemented in late 2006 with a
      ÂÂÂÂ /12 allocation from the IANA. Under the sparse allocation
      ÂÂÂÂ mechanism, there is no reservation size defined, and the space
      ÂÂÂÂ between allocations continues to change, depending on the
      ÂÂÂÂ remaining free pool available in APNIC.

      ÂÂÂÂ However, the "APNIC guidelines for IPv6 allocation and
      ÂÂÂÂ assignment requests"[2] stated:

      ÂÂÂÂ "In accordance with APNIC's "IPv6 address allocation and
      ÂÂÂÂ assignment policy", where possible, subsequent delegations to the
      ÂÂÂÂ same resource holder are made from an adjacent address block by
      ÂÂÂÂ growing the delegation into the free space remaining, unless
      ÂÂÂÂ disaggregated ranges are requested for multiple discrete
      ÂÂÂÂ networks."

      ÂÂÂÂ So, it is expected that allocation up to /29 is guaranteed for
      ÂÂÂÂ consistency with allocations above. Based on the current
      ÂÂÂÂ situation, contiguous allocation of /29 can still be accommodated
      ÂÂÂÂ even under the sparse allocation mechanism (Current /32
      ÂÂÂÂ allocations from the /12 block can grow up to /24 at this stage).

      ÂÂ - For traffic control purpose, some LIRs announce address blocks
      ÂÂÂÂ longer than /32 (e.g. /35). However, some ISPs may set filters to
      ÂÂÂÂ block address size longer than /32 since some filtering
      ÂÂÂÂ guidelines recommend to filter longer prefix than /32([3][4]). 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.

      Â2. Objective of policy change
      ÂÂ This proposal modifies the eligibility for an organization to
      ÂÂ receive an initial IPv6 allocation up to a /29 (/32 - /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 is possible to utilize address blocks which is potentially
      ÂÂÂÂ unused into the future.
      ÂÂ - It will be possible for LIRs to control traffic easier.
      ÂÂ - Organizations can design their IPv6 networks more flexibly.

      6. Explain the disadvantages of the proposal
      ÂÂ Some people may argue this will lead to inefficient utilization of
      ÂÂ IPv6 space since LIRs can obtain huge address size unnecessarily.
      ÂÂ However, this will not happen because larger address size needs
      ÂÂ higher cost to maintain that address block.

      7. Impact on resource holders
      ÂÂ NIRs must implement this policy if it is implemented by APNIC.

      8. References
      [1] IPv6 address allocation and assignment policy

      [2] APNIC guidelines for IPv6 allocation and assignment requests

      [3] Packet Filter and Route Filter Recommendation for IPv6 at xSP routers

      [4] IPv6 BGP filter recommendations