--------------------------------------------------------------------
APNIC Document identity

 Title: APNIC guidelines for IPv6 allocation and assignment
        requests

 Short title:                     ipv6-guidelines
 Document ref:                    APNIC-114
 Version:                         008
 Date of original publication:    2 July 2004
 Date of this version:            20 September 2012
 Review scheduled:                n/a
 Obsoletes:                       apnic-114-007
 Status:                          Active
 Comments:                        Include definition of Multiple
                                  Discrete Networks
---------------------------------------------------------------------



APNIC guidelines for IPv6 allocation and assignment requests

About this document
-------------------
These guidelines are intended to complement the document IPv6 address 
allocation and assignment policy.

    http://www.apnic.net/policy/ipv6-address-policy

These guidelines will be updated from time to time, in consultation with 
the Asia Pacific and global Internet communities, to ensure they remain 
appropriate to the current addressing environment.



Table of contents
-----------------

Section 1: Background

1. Introduction

2. Scope

3. Additional guidance

4. Goals of address space management

5. Application of guidelines


Section 2: General guidelines

6. Definitions
   6.1.  End Site
   6.2.  Multiple Discrete Networks
   
7. IPv6 allocations
   7.1.  Initial allocation criteria

         7.1.1.  A plan for 200 assignments
         7.1.2.  Existing LIRs with IPv4 allocations from APNIC or 
                 an NIR
         7.1.3.  Justifying an initial allocations larger than /32
                 7.1.3.1.  Expanding initial allocations received 
                           before August 2004
         7.1.4.  Supporting documentation
   7.2. Sparse Allocation Framework


8.  Assignments to end sites
    8.1.  Assignment size
    8.2.  Second opinion request

          8.2.1.  Sub-allocations and second opinion request
          8.2.2.  Supporting documentation

9.  Subsequent allocations
    9.1.  Prior allocations to be used first
    9.2.  Special circumstances

10.  Requesting a reverse DNS delegation
     10.1.  Reverse DNS delegations in ip6.int and ip6.arpa

11.  Registration requirements
     11.1.  Updating registration details
     11.2.  Registering contact persons



Section 1: Background
------------------------------------------------------------------------


1. Introduction
---------------

These guidelines are developed within the APNIC community and are 
consistent with the goals and policies applicable to IPv6 address space 
management. They are intended to assist organizations requesting IPv6 
address space only.

Nothing in these guidelines should be considered to replace or modify 
any of the specific policies defined in other APNIC documents.


2. Scope
--------

This document applies to the management of global unicast IPv6 public 
address space in the Asia Pacific region.

This document does not apply to IPv4, multicast, or unique local IPv6 
unicast addresses, or Autonomous System Numbers. It should be read in 
conjunction with other APNIC documents, particularly APNIC-089: IPv6 
address allocation and assignment policy.

    http://www.apnic.net/policy/ipv6-address-policy


3. Additional guidance
----------------------

These guidelines are not intended to be exhaustive. Additional guidance 
and examples are available from the help information available for each 
APNIC request form and in FAQs and other information on the APNIC web 
site:

    - Resource guides
      http://www.apnic.net/publications/media-library/documents
      
    - APNIC FAQs
      http://www.apnic.net/info/faq
 
    - RFC 3596 DNS Extensions to Support IP Version 6
      http://www.apnic.net/external-pages/rfcs/ietf-rfc-3596
      
    - RFC 6177 IPv6 Address Assignment to End Sites
      http://www.apnic.net/external-pages/rfcs/ietf-rfc-6177


4. Goals of address space management
------------------------------------

In this document, all reference to the goals of address space management
refer to the goals described in the IPv6 address allocation and 
assignment policy, namely:

    - uniqueness;
    - registration;
    - aggregation;
    - conservation;
    - fairness; and
    - minimised overhead.


5. Application of guidelines
----------------------------

This document is primarily intended to guide ISPs when making 
assignments to their customers or requesting address space from APNIC. 
The issues discussed in this document reflect many of the considerations 
used by APNIC in evaluating requests for initial allocations and 
subsequent allocations.

It is intended that NIRs will either adopt these, or similar, guidelines 
for their own members.


Section 2: General guidelines
------------------------------------------------------------------------


6. Definitions
--------------

6.1 End Site

    Section 2.9 of "IPv6 address allocation and assignment policy" 
    defines an end site as "an end user (subscriber) who has a business 
    relationship with a service provider". That section also lists some 
    possible business relationships (which would normally be found in 
    the contract between the LIR and their customer) that typically 
    indicate end sites. End sites do not re-assign any of their IP 
    addresses to other organizations.

    Examples:

    Single end site

    - A home or corporate user who has a single contract with a service 
      provider for their own device or network.

    - A home or corporate user who has multiple devices to connect the 
      Internet, but has only one contract with a service provider.


    Multiple sites

    - A home or corporate user who has multiple contracts with one or 
      more service providers.

    - A home or corporate user who has multiple separate networks that 
      are not connected each other because each network has a different 
      management policy, even if they are in the same place (for 
      example, a merged company with independent networks).
      

6.2 Multiple Discrete Networks

    Where an organization demonstrates a compelling need, or 
    requirement, to build discrete networks due to regulatory, 
    geographic, or operational reasons and these multihomed networks are 
    advertised either internally, or externally, the network may be 
    defined by APNIC as being composed of discrete networks.


7. IPv6 allocations
-------------------

APNIC will allocate IPv6 address space to a network with global or local 
connectivity, provided the network meets the criteria stated in "IPv6 
address allocation and assignment policy".

The following networks are examples of the types of organizations that 
most commonly apply for an IPv6 allocation from APNIC
This list is not intended to be exhaustive:

    - An ISP providing IPv6 connectivity to the global Internet.

    - An ISP providing IPv6 services to end sites and restricting 
      connectivity to its own closed network.

    - An ISP providing IPv6 services to end sites and restricting 
      connectivity to peering partners.

    - A large organization providing IPv6 connectivity to its group 
      companies or subsidiaries and restricting connectivity to its own 
      network.


7.1. Initial allocation criteria

     To qualify for an initial allocation of IPv6 address space, an 
     organization must meet the criteria stated in section 5.1.1 of 
     "IPv6 address allocation and assignment policy". Under d) in 
     section 5.1.1, an organization can choose from one of the two 
     alternative criteria:

     1. Have a plan for making at least 200 assignments to other 
        organizations within two years, OR

     2. Be an existing LIR with IPv4 allocations from APNIC, or from an 
        NIR, which will make IPv6 assignments or sub-allocations to 
        other organizations and announce the allocations in the 
        inter-domain routing system within two years

     These two alternative criteria are explained in sections 7.1.1. and 
     7.1.2. below.


7.1.1. A plan for 200 assignments

       An organization must provide a plan to make at least 200 
       assignments within two years. However, APNIC regards the 
       existence of the plan as a demonstration of the LIR's readiness 
       to commence IPv6 services and does not assess the feasibility of 
       the plan.

       For example

       An LIR with at least 200 customers currently using IPv4 address 
       space can meet the initial allocation criteria of 200 assignments 
       if it plans to provide them with IPv6 connectivity service within 
       two years.

       IPv4 sub-allocations made by an LIR to downstream ISPs can be 
       used to justify the corresponding amount of /56 assignments.

       For example
 
       If a CATV provider has 4,000 IP static connection customers in 
       IPv4 and 5% of the customers (200 customers) are expected to 
       subscribe to IPv6 services, then this provider will meet the 
       initial allocation criteria of 200 assignments. (A /56 can be 
       assigned to end sites using either static or dynamic addressing).

       If an LIR assigns a single static IP address in IPv4, the ISP can 
       assign up to a /48 in IPv6. The LIR may also assign a smaller 
       prefix in accordance with recommendations in RFC 6177.


7.1.2. Existing LIRs with IPv4 allocations from APNIC or an NIR

       To qualify under this criterion, an organization must:

       - Document an existing IPv4 allocation made to it by APNIC, or an 
         NIR
       - Commit to making IPv6 assignments and/or sub-allocations 
       - Agree to announce the IPv6 allocation in the routing table 
         within two years

       Please note that historical IP ranges do not meet the criteria of 
       being "an existing IPv4 allocation from APNIC, or an NIR". 
       Historical IP ranges are defined in Section 2.2 of: Policies for 
       historical Internet resources in the APNIC Whois Database.
       
           http://www.apnic.net/policy/historical-resource-policies


7.1.3. Justifying an initial allocation larger than /32

       LIRs can use existing IPv4 customers and IPv4 network 
       infrastructure to justify an initial allocation larger than a /32 
       by providing documentation on the number of their existing IPv4 
       users as well as the extent of their IPv4 network infrastructure.

       The HD ratio is used to determine the appropriate size of the 
       IPv6 allocation based on IPv4 customer and infrastructure 
       assignments. For more information, refer to section 5.2.3 of the 
       "IPv6 address allocation and assignment policy".
       
           http://www.apnic.net/policy/ipv6-address-policy

       LIRs are likely to be eligible for an initial allocation if they 
       meet both of the following conditions:

       - They have received an IPv4 allocation as an LIR, or meet the 
         criteria to receive an IPv4 allocation; and
       - They plan to transfer the existing IPv4 infrastructure or 
         customers partly, or wholly, to IPv6 in two years.

       LIRs are still requested to provide information on how many /56s 
       they expect to assign within the first two years.


7.1.3.1 Expanding initial allocations received before August 2004

        Organizations that received an initial allocation of IPv6 can 
        take advantage of the August 2004 policy permitting initial 
        allocations larger than /32.

        To expand the initial allocation size without needing to meet 
        subsequent allocation criteria, the LIR must have received its 
        initial allocation before 16 August 2004 and must meet the 
        initial allocation criteria described in Section 5. of the "IPv6 
        address allocation and assignment policy".
        
            http://www.apnic.net/policy/ipv6-address-policy

        For more information, see: prop-021: Expansion of the initial 
        allocation space for existing IPv6 address space holders.

            http://www.apnic.net/policy/proposals/prop-021


7.1.4. Supporting documentation

       The APNIC IPv6 Allocation Request Form gives LIRs the opportunity 
       to include additional documentation to support the request for an 
       initial IPv6 allocation.

       Examples of the types of information an LIR can include in the 
       "Additional information" section of the form to support the 
       request are:

       - network diagrams
       - approximate deployment dates
       - a brief description of IPv6 deployment method (use of IPv6 
         tunneling, dual stack, etc.)
       - service plans (web hosting, access service, etc.)
       - network equipment information to demonstrate that the LIR has a 
         plan to implement IPv6-ready infrastructure; and
       - IPv4 infrastructure and/or customer information if the LIR 
         chooses the option of using existing IPv4 infrastructure to 
         justify the request (see Section 7.1.2.).

       When requesting an initial allocation from APNIC, network 
       equipment information such as the vendor and model name of an 
       LIR's equipment, is not mandatory; however, if an LIR requests a 
       large pool of address space for CATV or ADSL operations, APNIC 
       may ask for information on the network's equipment.


7.2. Sparse Allocation Framework

     APNIC delegates blocks of IPv6 address space to resource holders 
     according to a "sparse allocation" algorithm. This allocation 
     process is designed to maximize the growth potential for each 
     allocation by maximizing the distance between allocations.

     The following illustration shows the order in which a sequence of 
     16 delegations would be made in an available free pool using 
     APNIC’s sparse allocation algorithm.

     |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
     1   |   |   |   |   |   |   |   2   |   |   |   |   |   |   |    
         |   |   |   3   |   |   |       |   |   |   4   |   |   |    
         |   5   |       |   6   |       |   7   |       |   8   |    
         9       10      11      12      13      14      15      16

 
     The sparse allocation algorithm used, selects the starting address 
     for each new delegation by calculating the mid-point between the 
     next two start addresses that are furthest apart in the free pool. 
     The algorithm works from the beginning address of the free pool to 
     the end address before returning to the first available slot at the 
     beginning of the pool.

     The effect is to successively sub-divide each remaining free block 
     in two, the addresses after that point being used for the new 
     allocation and the preceding addresses being left available for 
     subsequent delegation.

     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 
     allocation into the free space remaining, unless disaggregated 
     ranges are requested for multiple discrete networks.


7.2.1. Avoiding Fragmentation

       While the free space between sparse delegations is initially very 
       large, the size of available blocks reduces as more sub-divisions 
       occur. To minimize this effect, APNIC manages its central pool by 
       making similar sized allocations from a number of sub-pools, with 
       large delegations made from one pool, small delegations made from 
       another, and so on.

       In this way, the high frequency of smaller allocations will not 
       cause sub-divisions of free space available to large address 
       block holders, as they are taken from different sub-pools.

       For more information about the resource ranges managed by APNIC 
       see:

           http://www.apnic.net/resources


8. Assignments to end sites
---------------------------

8.1. Assignment size

     An LIR can assign a /64 to /48 to an end site customer network 
     based on their requirements.

     The following guidelines may be useful:

     - /64 where it is known that only one subnet is required.

     - /56 for small sites where it is expected only a few subnets will 
       be required within the next two years. Subscribers can receive a 
       /56 when connecting through on-demand or always-on connections 
       such as small office and home office enterprises.

     - /48 for larger sites, or if an end site is expected to grow into 
       a large network.

     An LIR must submit a second opinion request to APNIC if it plans to 
     assign more than a /48 to a single end site (see Section 8.2 
     below).
     
         http://www.apnic.net/services/manage-resources/second-opinion


8.2. Second opinion request

     Currently, the global Internet community considers a /48 assignment 
     to be sufficient address space for an end site.

     Therefore, when an end site requires an assignment larger than /48, 
     or it requires additional /48 assignments after the initial 
     assignment, the LIR must first submit a second opinion request.
     
         http://www.apnic.net/services/manage-resources/second-opinion


8.2.1. Sub-allocations and second opinion request

       LIRs do not need to submit a second opinion request before making 
       sub-allocations to downstream ISPs (please see Section 9 below). 
       However, APNIC encourages LIRs to contact APNIC hostmasters for 
       advice if LIRs are unsure how much address space to sub-allocate.


8.2.2. Supporting documentation

       The APNIC Second Opinion Request Form gives LIRs the opportunity 
       to include additional documentation to support the request for an 
       assignment to an end site that is larger than a /48.

       Examples of the types of information an LIR can include in the 
       Additional information section of the form to support the request 
       are:
 
       - Network diagram of an end site
       - Network equipment information
       - Full details to justify multiple /48 assignments to an end site 
         (for example, the number of clients (PCs or other network 
         equipment), or other information which justify multiple /48 
         assignments)


9. Subsequent allocations
-------------------------

9.1. Prior allocations to be used first

     An LIR is not eligible to receive subsequent allocations until its 
     current assignments reach a HD ratio of 0.94 based on /56 
     assignments.


9.2. Special circumstances

     An LIR may request an exception to the HD 0.94 rule when:

     - It has a demonstrated need for an assignment that is larger than 
       the amount of remaining space,

     - It is announcing its existing IPv6 allocation and can demonstrate 
       a need or requirement to build discrete networks,
 
     - It requires the additional allocation for technical reasons such 
       as for IPv4 to IPv6 transitional technologies, or
       
     - It can demonstrate other reasons accepted by APNIC as valid 
       circumstance, or in accord with applicable policies.


10. Requesting a reverse DNS delegation
---------------------------------------

LIRs should maintain reverse DNS delegations for their customers' 
networks. If a network is not specifically associated with an LIR then 
the reverse DNS delegation should be maintained by APNIC. In both IPv4 
and IPv6 networks, it is the LIR's responsibility to delegate or to 
maintain PTR records for its customers' networks.

The size of a reverse DNS delegation by an LIR to an end site will 
usually be a /48, which is the recommended minimum assignment to an end 
site specified in RFC 6177. However, it is possible to delegate a prefix 
longer than /48. Some organizations may delegate such a prefix in their 
internal network.


10.1. Reverse DNS delegations in ip6.int and ip6.arpa

      As specified in RFC 3596, reverse DNS delegations in the ip6.int 
      tree have been deprecated, and APNIC has now removed all ip6.int 
      reverse delegations from the APNIC Whois Database.

      For more information, see: Reverse DNS delegations resource guide
      
          http://www.apnic.net/dns


11. Registration requirements
-----------------------------

LIRs are responsible for promptly and accurately registering their 
allocations, sub-allocations, and assignments in the APNIC Whois 
Database, as follows:

    - All allocations and sub-allocations must be registered.
    - Assignments for networks equal to or greater than /48 must be 
      registered.
    - Assignments for networks of /48 or less may be registered, at the 
      discretion of the LIR and the network administrator.

When an LIR makes a sub-allocation to a downstream ISP, the LIR is 
responsible for ensuring that assignments from the sub-allocated range 
are registered in the database; however, the LIR may delegate the 
responsibility to the downstream ISP.

If an LIR registers a /64 assignment, it will be counted as a utilized 
/48 when assessing existing address utilization for future IPv6 
allocation requests.

Note: Privacy of customer assignments (prop-007-v001) was implemented in 
2004. APNIC policy no longer requires the registration of assignments 
and sub-allocations to be publicly available. The registration of 
customer assignments is still required, but will be 'hidden' by default.


11.1. Updating registration details

      LIRs must update the APNIC Whois Database when any of the 
      registration information changes. This is the responsibility of 
      the LIR concerned, but may be formally delegated to the end user 
      as a condition of the original assignment.


11.2. Registering contact persons

      Administrative and technical contact persons must be registered.

      The registered administrative contact (admin-c) must be someone 
      who is physically located at the site of the network, subject to 
      the following exceptions:

      - For residential networks or users, the network's technical 
        contact may be registered as admin-c.
    
      - For networks in exceptional circumstances that make it 
        impractical to maintain an on-site administrative contact, an 
        off-site person may be registered as the admin-c.

      The technical contact (tech-c) need not be physically located at 
      the site of the network, but must be a person who is responsible 
      for the day-to-day operation of the network.