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

  • To: APNIC Policy SIG List <sig-policy at apnic dot net>
  • Subject: [sig-policy] prop-083-v003: Alternative criteria for subsequent IPv6 allocations
  • From: Gaurab Raj Upadhaya <gaurab at lahai dot com>
  • Date: Tue, 01 Mar 2011 04:08:09 +0000
  • 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>
  • User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
    • Hash: SHA1
      
      Dear SIG members
      
      Below is an updated version of the proposal that includes elements
      changed during the APNIC 31 Policy SIG meeting.
      
      The following changes were made:
      
             - The specific examples in section 4.2 were removed from the text.
      
      The proposal's history can be found at:
      
            http://www.apnic.net/policy/proposals/prop-083
      
      This proposal reached consensus at the Policy SIG meeting during the
      Policy SIG at APNIC 31 in Hong Kong SAR, China, 21-25 February 2011.
      
      It will be presented to the Policy SIG mailing list soon for a formal
      eight-week final call for comments.
      
      Gaurab, Terence, and Andy
      
      ___________________________________________________________________
      
      prop-083-v003: Alternative criteria for subsequent IPv6 allocations
      ___________________________________________________________________
      
      
      Author:    Skeeve Stevens
                  <skeeve at eintellego dot net>
      
      Version:   3
      
      Date:      24 February 2011
      
      
      1.  Introduction
      - ----------------
      
      This is a proposal to enable current APNIC account holders with existing
      IPv6 allocations to receive subsequent IPv6 allocations from APNIC to
      facilitate network deployments.
      
      Examples:
            - For use in networks that are not connected to the initial IPv6
              allocation
      
            - Transitional technologies such as 6RD
      
            - Other reasons accepted by APNIC as valid circumstance, or as
              decided by the community in policy amendments.
      
      
      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].
      
      As an example, a 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 Australia.Ê The ISP wants to build a new network in Cambodia.
            The ISP's new network in Cambodia is not connected to the existing
            Australian 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.
      
      Other valid examples of subsequent allocation may be to facilitate
      transitional technologies such as 6RD.
      
      
      3.  Situation in other RIRs
      - ---------------------------
      
      AfriNIC and LACNIC currently have no similar policies or proposals.
      
      ARIN:  A similar policy, 2009-5 has been adopted [3] and integrated
      into the ARIN Number Resource Policy Manual
      
      RIPE: 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 LIRÕs can announce smaller (i.e. if they have a /32,
      they can announce a /35) prefixes.  APNIC Policy 082 at this meeting
      (APNIC 29) is basically the same, but does not address this issue
      covered by this policy proposal.
      
      
      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 to
      obtain additional IPv6 resources.
      
      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
              allocation
      
            - Be announcing its existing IPv6 allocation
      
            - Have a compelling reason for requiring the subsequent allocation
      
      4.3 As part of this process, if the LIR should indicate whether it
      will be using an existing ASN for the additional announcement 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
              deaggregation.
      
            - Current APNIC account holders will be able to acquire resources
              and announce them separately to transit providers in disparate
              locations.
      
      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 issue.
      
      
      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"
           http://www.space.net/~gert/RIPE/ipv6-filters.html
      
      [2] See section 5.2, "Subsequent Allocation Section" in "IPv6 Address
           Allocation and Assignment Policy"
           http://www.apnic.net/policy/ipv6-address-policy#5.2
      
      [3] https://www.arin.net/policy/proposals/2009_5.html
      
      [4] http://www.ripe.net/ripe/policies/proposals/2009-05.html
      
      [5] http://www.ripe.net/ripe/policies/proposals/2009-06.html
      
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
      Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
      
      iEYEARECAAYFAk1scSkACgkQSo7fU26F3X00kgCg9ONbsCtvi+I6nKrAF/l/hFC5
      OjEAoPJYqDgnfWkSY9CuPvZP+s0wU/R+
      =ZhcR
      -----END PGP SIGNATURE-----