[sig-policy] prop-099 Returned to mailing list

  • To: <sig-policy at apnic dot net>
  • Subject: [sig-policy] prop-099 Returned to mailing list
  • From: "Masato Yamanishi" <myamanis at japan-telecom dot com>
  • Date: Tue, 6 Mar 2012 17:15:27 -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>
  • Thread-index: Acz7/8f8cyAcTuE2SKq7Gf4b1wu+sg==
    • 
      # I'm sending this notification on behalf of Andy Linton, Policy SIG chair
      
      Version 2 of prop-099: IPv6 Reservation for Large Networks, did not reach
      consensus at the APNIC 33 Policy SIG. Therefore, this proposal is being
      returned to the author and the Policy SIG mailing list for further 
      discussion.
      
      
      Proposal details
      ---------------------
      
      This proposal extends the IPv6 request process to allow large ISPs to
      request multiple prefixes within a single, contiguous, reserved space.
      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-099
      
      Regards
      
      Andy, Skeeve, and Masato
      
      
      ------------------------------------------------------------------------
      
      prop-099-v002: IPv6 Reservation for Large Networks
      ------------------------------------------------------------------------
      
      
      Authors:   Xing Li
                  <xing at cernet dot edu dot cn>
      
                  Song Jiang,
                  Xiaomin Zhou,
                  Haijin Li
      
      
      1. Introduction
      ---------------
      
      This proposal extends the IPv6 request process to allow large ISPs to
      request multiple prefixes within a single, contiguous, reserved space.
      
      Such a request must justify each prefix allocation in terms of specific
      demonstrated needs (in the same manner as a normal IPv6 allocation
      request); and must justify the total requested reservation in terms of
      documented architectural plans and projected space requirements for a
      period of up to 5 years.
      
      
      2. Summary of the current problem
      ---------------------------------
      
      The current IPv6 address allocation and assignment policy
      (apnic-089-v010) states that
      
         5.2.3 Larger initial allocations
         Initial allocations larger than /32 may be justified if:
         a. The organization provides comprehensive documentation
            of planned IPv6 infrastructure which would require a
            larger allocation; or
         b. The organization provides comprehensive documentation
            of all of the following:
            o its existing IPv4 infrastructure and customer base,
            o its intention to provide its existing IPv4 services
              via IPv6, and
            o its intention to move some of its existing IPv4
              customers to IPv6 within two years.
         In either case, an allocation will be made which fulfills
         the calculated address requirement, in accordance with
         the HD-Ratio based utilization policy.
      
      Large networks are facing challenges deploying IPv6 networks. The
      current slow start policy is to allocate a /32 and then reduce the bit
      mask one bit at a time on subsequent allocations (i.e. /31, /30, /29
      etc.).
      
      This approach is designed to maximise global routing aggregation,
      however, it causes fragmentation and complexity in the internal routing
      configuration of very large networks. This is particularly a problem in
      large networks with many POPs growing at different rates.
      
      Also, the IPv6 Address Allocation and Assignment Policy (Section 5.2.3
      Larger initial allocations) does not take into account long-term future
      growth.
      
      A partial solution is available after prop-083 (Alternative criteria
      for subsequent IPv6 allocations) [1] where additional prefixes can be
      delegated to an organization??s disparate networks. However, this does
      not address the specific needs of organizations with very large
      non-disparate networks. These require a large address space over which
      they can design their network on a longer planning window (up to 5
      years).
      
      
      3. Situation in other RIRs
      --------------------------
      
      No similar policy or policy proposal is available in the other RIRs.
      
      
      4.  Details of the proposal
      ---------------------------
      
      4.1 Multiple prefix request
      
           Each IPv6 request will be able to specify any number of prefixes,
           although each must be separately justified according to specific
           demonstrated needs.
      
           Conventional allocation policies will be applied in assessment of
           each prefix requested. In particular, existing IPv4 infrastructure
           can be considered, and the current minimum allocation size will
           apply to each prefix.
      
           Each request may specify a proposed map of requested prefixes
           within the reserved space, based on expected growth forecasts for
           each prefix.
      
           As the allocated prefixes grow and become aggregatable, external
           routing should be aggregated whenever possible.
      
      4.2 Subsequent allocations
      
           Subsequent allocations within the reserved space can be requested
           and made according to Section 5.3 of the IPv6 address allocation
           and assignment policy.
      
           Subsequent allocation requests can include extensions to previously
           allocated prefixes and/or new prefixes as needed.
      
      4.3 Reservation request
      
           Each IPv6 request will be able to specify a proposed reservation
           for the entire network, to contain all allocated prefixes, and room
           for their future growth.
      
           The requested reservation may accommodate projected network growth
           for up to 5 years, based on supporting information, which may
           include long-term network plans such as:
      
           - Network architecture
      
             o Number of POPs and the growth rate of each based on past
               records and future projection
      
             o IPv6 address assignment plan that covers the initial and the
               end deployment within the planning window
      
             o List of equipment and devices to be deployed in the network
               and,
      
           - Environmental factors such as:
      
             o Market size and market share
      
             o Population and economic growth of service region
      
      4.4 Reservation term
      
           Each reservation will be subject to expiry after 2 years, unless
           renewed by a request, which provides an update of network
           deployment and projections. No reservation will be expired or
           cancelled by APNIC without prior contact with the holder.
      
      4.5 Registration
      
           In case of a multiple-prefix allocation, only the individual
           allocated prefixes will be registered in whois, or included in
           resource certificates; the reservation itself will not be
           registered, however it may be separately documented.
      
      4.6 Suggested modifications of the current policy
      
      Suggest to add bullet 'c' in the current policy
      
         5.2.3 Larger initial allocations
         Initial allocations larger than /32 may be justified if:
      
         a. The organization provides comprehensive documentation
            of planned IPv6 infrastructure which would require a
            larger allocation; or
      
         b. The organization provides comprehensive documentation
            of all of the following:
            o its existing IPv4 infrastructure and customer base,
            o its intention to provide its existing IPv4 services
              via IPv6, and
            o its intention to move some of its existing IPv4
              customers to IPv6 within two years; or
      
         c. The organization provides comprehensive documentation
            of long term (up to 5 years) IPv6 infrastructure which
            would require a larger allocation:
      
            o Larger initial allocation will be via a multiple-prefix
              request, conventional allocation policies will be
              applied in assessment of each prefix requested,
              subsequent allocation requests can include extensions
              to previously allocated prefixes and/or new prefixes
              as needed;
      
            o Each IPv6 request will be able to specify a proposed
              reservation for the entire network, to contain all
              allocated prefixes, and room for their future growth;
      
            o In case of a multiple-prefix allocation, only the
              individual allocated prefixes will be registered in
              whois, or included in resource certificates; the
              reservation itself will not be registered, however
              it may be separately documented.
      
         In either case, an allocation will be made which fulfills
         the calculated address requirement, in accordance with
         the HD-Ratio based utilization policy.
      
      5.  Advantages and disadvantages of the proposal
      ------------------------------------------------
      
      Advantages:
      
           - This proposal enables large networks to make long-term network
             plans and reduce internal routing complexities.
      
           - The reserved space is aggregated, and can be globally routed as a
             single prefix once the space is fully allocated.
      
           - The proposal allows long-term growth forecasts to be taken into
             account in the allocation process, without making allocation
             commitments based on those forecasts
      
      Disadvantages:
      
           - Initial allocation from the reserved space could be made in
             multiple disaggregated prefixes that have to be announced
             separately on the global routing table. However, as more
             allocations are made, the announcement could eventually converge
             to a smaller number of prefixes, or even to a single prefix.
      
           - Additional work for APNIC Secretariat to manage the request
             process, and regular renewals of reservations. The APNIC EC may
             want to look at the cost implication, which is out of scope of
             this policy proposal.
      
      
      6.  Effect on APNIC Members
      ---------------------------
      
      APNIC account holders with large networks will be able to submit their
      long-term network plan and receive IPv6 allocations in stages
      according to that plan.
      
      
      7. Effect on NIRs
      -----------------
      
      The proposal allows NIRs to choose when to adopt this policy for their
      Members.
      
      
      
      
      
      -- 
      Adam Gosling
      Senior Policy Specialist       email:          adam at apnic dot net
      APNIC                                    sip:          adam at voip dot apnic dot net
      http://www.apnic.net        phone:          +61 7 3858 3100
      ________________________________________________________________________
        * Sent by email to save paper. Print only if necessary.
      _______________________________________________
      Sig-policy-chair mailing list
      Sig-policy-chair at apnic dot net
      http://mailman.apnic.net/mailman/listinfo/sig-policy-chair