[sig-policy] New version of prop-111 Request-based expansion of IPv6 def

  • To: SIG policy <sig-policy at apnic dot net>
  • Subject: [sig-policy] New version of prop-111 Request-based expansion of IPv6 default allocation size
  • From: Andy Linton <asjl at lpnz dot org>
  • Date: Fri, 14 Feb 2014 12:29:20 +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:from:date:message-id:subject:to:content-type; bh=d3F09fp8x+XGwRTPnbvqa9gjGLnXE7rRiJ66lnFYpak=; b=WvTvENy3M/1ukRakT9GFbAl3hKxMUztIOIoZQ1rx/M30uC7qMMM9a5CSjAgSTKXiQ7C/vYlldIVxZ 9Fgpaj1pbS5P6xQSY1FFKUDPZsNuSectZgz3I6KCgL2e0PmYGPCShXOV3FTLYBPqZRyItdhLmUuX6K OfLSmZu/+biVE/aQ=
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lpnz.org; s=dkim; h=mime-version:from:date:message-id:subject:to:content-type; bh=d3F09fp8x+XGwRTPnbvqa9gjGLnXE7rRiJ66lnFYpak=; b=P50QWWSD/zaFFCYlb5+GHQTQUeaAj1PWLmIsD5YU6peXOQUXs+RB0odzKDenCRwTdl dv/gBghgzwh9+CPIoVvTsAVFbIACE0n3AxVmCTqd3Enin9PQgzVkhCc51LWKZodNw/vJ tVDtNWSdqtkYBtkLJL6JeFnj1PL+iBY6ExfY0=
  • 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>

    • Dear SIG members

      A new version of the proposal "prop-111 Request-based expansion of IPv6
      default allocation size" has been sent to the Policy SIG for review.

      Information about earlier versions is available from:

      You are encouraged to express your views on the proposal:

      - Do you support or oppose 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?


      Andy and Masato

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

      Author: Tomohiro Fujisaki

      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

      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

      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