[sig-policy] prop-083-v002: Alternative criteria for subsequent IPv6 all

  • To: Policy SIG <sig-policy at apnic dot net>
  • Subject: [sig-policy] prop-083-v002: Alternative criteria for subsequent IPv6 allocations
  • From: Randy Bush <randy at psg dot com>
  • Date: Tue, 02 Mar 2010 11:58:34 +0800
  • Delivered-to: sig-policy at mailman dot apnic 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/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • References: <4B8C8C7E.4070704@apnic.net>
  • User-agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
      Version 2 of the proposal 'Alternative criteria for subsequent IPv6
      allocations' has been sent to the Policy SIG for review. It will be
      presented at the Policy SIG at APNIC 29 in Kuala Lumpur, on Thursday 4
      March 2010.
      Information about this and other policy proposals is available from:
      This new version of the proposal reflects feedback from the community
      received on the Policy SIG mailing list:
            - Section 3 has been updated to show the most recent status
              of similar discussions in other RIRs.
            - Section 4.2 has been updated to incorporate community
            - There are additional references in section 8.
      We encourage you 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
      Randy, Ching-Heng, and Terence
      prop-083-v002: Alternative criteria for subsequent IPv6 allocations
      Author:    Skeeve Stevens <skeeve at eintellego dot net>
      Version:   2
      Date:      2 March 2010
      1.  Introduction
      This is a proposal to enable current APNIC account holders with existing
      IPv6 allocations to receive subsequent IPv6 allocations from APNIC for
      use in networks that are not connected to the initial IPv6 allocation.
      2.  Summary of current problem
      An APNIC account holder with an existing /32 IPv6 allocation (or larger)
      is unable to deaggregate that allocation into routes smaller than a /32
      due to the community practice of 'filter blocking' or 'bogon lists'
      associated with RIR blocks which are known to have a minimum allocation
      size of /32 [1].
      An LIR may want to build a network in a separate location and provide
      IPv6 connectivity; however, because the LIR risks routability problems
      if they deaggregate, they cannot use a subset of their initial
      allocation in the new location.
      For example:
           An ISP has a /32 allocation which they announce via an upstream
           in New Zealand.  The ISP wants to build a new network in Singapore.
           The ISP's new network in Singapore is not connected to the existing
           New Zealand network and the ISP is using a local transit provider
           to obtain dual stacked connectivity.
           If the network was using IPv4 addresses, the ISP would usually
           be able to deaggregate their allocation and announce one part of
           the deaggregated range to the local transit provider.
           In IPv6, however, this is not possible due to 'community filtering'
           on ranges smaller than a /32.
           Such a filter may look like the following:
               ipv6 prefix-list ipv6-ebgp-strict permit 2400::/12 ge 19 le 32
           This above statement in the IPv6 BGP filter recommendations would
           cause any announcements by an ISP which had an allocation,
           such as 2400:0000::/32, to announce smaller routes from that block,
           such as multiple /35s for example, to be filtered.  In a default
           free situation, connectivity to the ISP would be problematic.
           Instead, the ISP needs to obtain a new /32 allocation to be able to
           have IPv6 connectivity in the new location with an independent
           (from their primary network) transit provider.
      3.  Situation in other RIRs
      AfriNIC and LACNIC currently have no similar policies or
           A similar policy, 2009-5 has been adopted [3] and integrated into
           the ARIN Number Resource Policy Manual.
           A similar policy, 2009-5 [4] was rejected in favor of 2009-6 [5].
           RIPE's 2009-6 recommended that routing announcements requirements be
           relaxed so that LIRs can announce smaller (i.e. if they have a /32,
           they can announce a /35) prefixes.  APNIC prop-082 is basically the
           same, but does not address this issue covered by this policy
           proposal (prop-083).
      4.  Details of the proposal
      4.1 It is proposed that alternative criteria be added to the subsequent
           IPv6 allocation policy [2] to allow current APNIC account holders
           with networks in multiple locations but without a connecting
           infrastructure to obtain IPv6 resources for each location.
      4.2 To qualify for subsequent IPv6 allocations under the proposed
           alternative criteria, account holders must:
             - Be a current APNIC account holder with an existing IPv6
             - Be announcing its existing IPv6 allocation
             - Have a compelling reason for establishing a separate network
               which is not connected to the network of the initial allocation.
               Examples of acceptable reasons for requesting resources for a
               Separate network installations are:
                - Geographic distance and diversity between networks
                - Autonomous multi-homed separate networks
                - Regulatory restrictions requiring separate networks
             - Each additional allocation must be announced from a separate ASN
      4.3 As part of this process, if the LIR should indicate whether it will
           be using an existing ASN for the additional announcement =96 which
           cannot be the same as the ASN of the initial assignment.
      5.  Advantages and disadvantages of the proposal
      5.1 Advantages
             - This proposal enables current APNIC account holders to avoid
               problematic network design issues and policy issues related to
             - Current APNIC account holders will be able to acquire resources
               and announce them separately to transit providers in disparate
      5.2 Disadvantages
             - This proposal could cause faster consumption of IPv6 address
               space. However, given the size of the total IPv6 pool, the
               author of this proposal does not see this as a significant
      6.  Effect on APNIC members
      APNIC members would be able to build networks in separate locations and
      obtain local IPv6 connectivity and announce their own resources.
      7.  Effect on NIRs
      The proposal allows for NIRs to have the choice as to when to adopt this
      policy for their members.
      8.   References
      [1] For example, see "IPv6 BGP filter recommendations"
      [2] See section 5.2, "Subsequent Allocation Section" in "IPv6 Address
           Allocation and Assignment Policy"
      [3] 2009-5 IPv6 Multiple Discrete Networks
      [4] Multiple IPv6 /32 Allocations for LIRs
      [5] Removing Routing Requirements from the IPv6 Address Allocation