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

    • To: <sig-policy at apnic dot net>
    • Subject: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size
    • From: Masato Yamanishi <myamanis at japan-telecom dot com>
    • Date: Thu, 31 Jul 2014 11:42:21 -0700
    • 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-google-dkim-signature:x-gm-message-state:x-received: return-path:received:user-agent:date:subject:from:to:cc:message-id: thread-topic:mime-version:content-type; bh=EOBLOj2ZoZsWfKEAsOsaZnYbUE3g31njAZzAAILi4lA=; b=tcWw/o8iYPOXW7rqlOnyInsKIimJ90IlKNZrUTsEBhR5fw1be21acPoVC+G15pmJDOPg7hIAqLoOM +ZrDt6uZau9Aa6LA3ENP0yhBv4uNYHkSQ8bW6p+9fodxrwPhbg7QYnby5oJo29FoCU/JVhmjTHwL2A oTqfLoyxRHTRKLJ8=
    • 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>
    • Thread-topic: New version of prop-111: Request-based expansion of IPv6 default allocation size
      • 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 the proposal?
         - Is there anything in the proposal that is not clear?
         - What changes could be made to this proposal to make it more effective?

        Please find the text of the proposal below.

        Kind Regards,

        Andy and Masato

        prop-111-v003 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
        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).
        - After amended HD Ratio (0.94) and base calculation size (/56) was
        introduced (prop-031 and prop-033), to obtain address blocks larger
        than /32 and to request additional address blocks became harder
        especially for small and middle size ISPs.
        - 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 or extend an IPv6 address space up to a /29 (/32 -/29) by
        explaining how the extended space up to /29 will be used.
        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. The organizations
        can receive up to /29 by providing utilization information of the whole
        address space.
        - 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 by explaining
        how the whole address space will be used.
        5. Explain the advantages of the proposal
        - It is possible to utilize address blocks which is potentially
          unused into the future.
        - Organizations can design their IPv6 networks more flexibly.
        - It will be possible for LIRs to control traffic easier.
        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 (if required)
        [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