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

 Title:     IPv6 address allocation and assignment policy

 Short title:                   ipv6-address-policy
 Document ref:                  APNIC-089 
 Version:                       009
 Date of original publication:  1 July 2002 
 Date of this version:          8 November 2010
 Review scheduled:              n/a 
 Obsoletes:                     Previous versions
 Status:                        Active 
 Comments:                      n/a
--------------------------------------------------------------------



    IPv6 Address Allocation and Assignment Policy



Status of this Memo

   This document was initially developed through joint discussions
   among the APNIC, ARIN and RIPE communities. The document also
   incorporates APNIC-specific policies developed since that time.


Abstract

   This document defines registry policies for the assignment and
   allocation of globally-unique IPv6 addresses to ISPs and other
   organizations. This document obsoletes the "Provisional IPv6
   assignment and allocation policy document".

   This document was developed jointly by the communities of APNIC,
   ARIN, and RIPE.


Contents

1. Introduction

   1.1  Overview 

2. Definitions

   2.1 Internet Registry (IR) 
   2.2 Regional Internet Registry (RIR) 
   2.3 National Internet Registry (NIR) 
   2.4 Local Internet Registry (LIR) 
   2.5 Allocate 
   2.6 Assign 
   2.7 Utilization 
   2.8 HD-Ratio 
   2.9 End site 
   2.10 Internet Exchange Point (IXP)

3. Goals of IPv6 address space management

   3.1 Goals 
   3.2 Uniqueness 
   3.3 Registration 
   3.4 Aggregation 
   3.5 Conservation 
   3.6 Fairness 
   3.7 Minimized Overhead 
   3.8 Conflict of goals 

4. IPv6 Policy Principles

   4.1 Address space not to be considered property 
   4.2 Routability not guaranteed 
   4.3 Minimum Allocation 
   4.4 Consideration of IPv4 infrastructure 

5. Policies for allocations and assignments 

   5.1 Initial IPv6 block for APNIC members with existing IPv4 space 
   
       5.1.1 Criteria 
       5.1.2 Minimum size of IPv6 block

   5.2 Initial allocation 

       5.2.1 Initial allocation criteria 
       5.2.2 Minimum initial allocation size 
       5.2.3 Larger initial allocations 

   5.3 Subsequent allocation 

       5.3.1 Subsequent allocation criteria 
       5.3.2 Applied HD-Ratio 
       5.3.3 Subsequent Allocation Size 

   5.4 LIR-to-ISP allocation 

   5.5 Assignment 

       5.5.1 Assignment address space size 
       5.5.2 Assignment of multiple /48s to a single end site 
       5.5.3 Assignment to operator's infrastructure 

   5.6 Registration 

   5.7 Reverse lookup 

   5.8 Existing IPv6 address space holders 

   5.9 Portable assignments 

       5.9.1 Small multihoming assignments 
       5.9.2 Internet Exchange Points 
       5.9.3 Critical infrastructure 

6. References 

7. Appendix A: HD-Ratio 

8. Appendix B: Background information 

   8.1 Background 
   8.2 Why a joint policy 
   8.3 The size of IPv6's address space 
   8.4 Acknowledgment 



1.    Introduction


1.1   Overview

      This document describes policies for the allocation and
      assignment of globally-unique Internet Protocol Version 6 (IPv6)
      address space. It updates and obsoletes the existing Provisional
      IPv6 Policies in effect since 1999 [RIRv6-Policies]. Policies
      described in this document are intended to be adopted by each
      registry. However, adoption of this document does not preclude
      local variations in each region or area.

      [RFC2373, RFC2373bis] designate 2000::/3 to be global unicast
      address space that IANA may allocate to the RIRs. In accordance
      with [RFC2928, RFC2373bis, IAB-Request], IANA has allocated
      initial ranges of global unicast IPv6 address space from the
      2001::/16 address block to the existing RIRs. This document
      concerns the initial and subsequent allocations of the 2000::/3
      unicast address space, for which RIRs formulate allocation and
      assignment policies.

      This policy is considered to be an interim policy. It will be
      reviewed in the future, subject to greater experience in the
      administration of IPv6.



2.    Definitions

      [Note: some of these definitions will be replaced by definitions
      from other RIR documents in order to be more consistent.] 

      The following terms and their definitions are of particular
      importance to the understanding of the goals, environment, and
      policies described in this document.

      Responsibility for management of IPv6 address spaces is
      distributed globally in accordance with the hierarchical
      structure shown below.

        Figure 1 Distribution Hierarchy


                +--------+
                |  IANA  |
                +--------+
                    |
              +-----------+
              |           |
          +--------+  +--------+
          |   RIR  |  |   RIR  |  Regional Internet
          +--------+  +--------+  Registries (APNIC, ARIN, RIPE NCC,
              |           |       plus possible future RIRs)
              |           |
              |        +-----+
              |        | NIR |     National Internet
              |        +-----+     Registries (AP region)
              |           |
         +--------+   +--------+
         |LIR/ISP |   |LIR/ISP |   Local Internet
         +--------+   +--------+   Registries (ISPs)
              |           |
        +--------+        |
        |        |        |
    +-------+  +----+   +----+
    |EU(ISP)|  | EU |   | EU |     End users
    +-------+  +----+   +----+


2.1   Internet Registry (IR)

      An Internet Registry (IR) is an organization that is responsible
      for distributing IP address space to its members or customers and
      for registering those distributions. IRs are classified according
      to their primary function and territorial scope within the
      hierarchical structure depicted in the figure above.


2.2   Regional Internet Registry (RIR)

      Regional Internet Registries (RIRs) are established and
      authorized by respective regional communities, and recognized by
      the IANA to serve and represent large geographical regions. The
      primary role of RIRs is to manage and distribute public Internet
      address space within their respective regions.


2.3   National Internet Registry (NIR)

      A National Internet Registry (NIR) primarily allocates address
      space to its members or constituents, which are generally LIRs
      organized at a national level. NIRs exist mostly in the Asia
      Pacific region.


2.4   Local Internet Registry (LIR)

      A Local Internet Registry (LIR) is an IR that primarily assigns
      address space to the users of the network services that it
      provides. LIRs are generally ISPs, whose customers are primarily
      end users and possibly other ISPs.


2.5   Allocate

      To allocate means to distribute address space to IRs for the
      purpose of subsequent distribution by them.


2.6   Assign

      To assign means to delegate address space to an ISP or end-user,
      for specific use within the Internet infrastructure they operate.
      Assignments must only be made for specific purposes documented by
      specific organizations and are not to be sub-assigned to other
      parties.


2.7   Utilization

      The actual usage of addresses within each assignment will be 
      quite low, when compared to IPv4 assignments. In IPv6, 
      "utilization" is only measured in terms of the bits to the left 
      of the /56 boundary. In other words, utilization refers to the 
      assignment of /56s to end sites, and not the number of addresses 
      assigned within individual /56s at those end sites.

      Throughout this document, the term utilization refers to the 
      allocation of /56s to end sites, and not the number of addresses 
      assigned within individual /56s within those end sites.


2.8   HD-Ratio

      The HD-Ratio is a way of measuring the efficiency of address 
      assignment [RFC 3194]. It is an adaptation of the H-Ratio 
      originally defined in [RFC1715] and is expressed as follows:

           Log (number of allocated objects) 
      HD = ------------------------------------------------ 
           Log (maximum number of allocatable objects)

      where (in the case of this document) the objects are IPv6 site 
      addresses (/56s) assigned from an IPv6 prefix of a given size.


2.9   End site

      An end site is defined as an end user (subscriber) who has a 
      business relationship with a service provider that involves:

      * that service provider assigning address space to the end user
      * that service provider providing transit  service for the end 
        user to other sites
      * that service provider carrying the end user's  traffic
      * that service provider advertising an aggregate prefix route 
        that contains the end user's assignment


2.10  Internet Exchange Point (IXP)

      An Internet Exchange Point (IX or IXP) is a layer 1 and layer 2 
      network structure that interconnects three or more Autonomous 
      Systems (AS) for the purpose of Internet traffic interchange.



3.    Goals of IPv6 address space management


3.1   Goals

      IPv6 address space is a public resource that must be managed in a
      prudent manner with regards to the long-term interests of the 
      internet. Responsible address space management involves balancing 
      a set of sometimes competing goals. The following are the goals 
      relevant to IPv6 address policy.


3.2   Uniqueness

      Every assignment and/or allocation of address space must 
      guarantee uniqueness worldwide. This is an absolute requirement 
      for ensuring that every public host on the Internet can be 
      uniquely identified.


3.3   Registration

      Internet address space must be registered in a registry database
      accessible to appropriate members of the Internet community. This 
      is necessary to ensure the uniqueness of each Internet address 
      and to provide reference information for Internet troubleshooting 
      at all levels, ranging from all RIRs and IRs to end users.

      The goal of registration should be applied within the context of
      reasonable privacy considerations and applicable laws.


3.4   Aggregation

      Wherever possible, address space should be distributed in a 
      hierarchical manner, according to the topology of network 
      infrastructure. This is necessary to permit the aggregation of 
      routing information by ISPs, and to limit the expansion of 
      Internet routing tables.

      This goal is particularly important in IPv6 addressing, where the 
      size of the total address pool creates significant implications 
      for both internal and external routing.

      IPv6 address policies should seek to avoid fragmentation of 
      address ranges.

      Further, RIRs should apply practices that maximize the potential 
      for subsequent allocations to be made contiguous with past 
      allocations currently held. However, there can be no guarantee of 
      contiguous allocation.
      
      In addition, wherever possible, network operators announcing 
      address space are strongly encouraged to avoid announcing 
      deaggregated routes when announcing address blocks from a single 
      Autonomous System unless this deaggregation is required for 
      traffic engineering purposes.

      When contiguous blocks are delegated to a network operator, the 
      operator is encouraged to announce the contiguous address blocks 
      as a single aggregated prefix, with minimal additional 
      announcements of deaggregated prefixes being made only for traffic 
      engineering requirements.


3.5   Conservation

      Although IPv6 provides an extremely large pool of address space, 
      address policies should avoid unnecessarily wasteful practices. 
      Requests for address space should be supported by appropriate 
      documentation and stockpiling of unused addresses should be 
      avoided.


3.6   Fairness
      
      All policies and practices relating to the use of public address 
      space should apply fairly and equitably to all existing and 
      potential members of the Internet community, regardless of their 
      location, nationality, size or any other factor.


3.7   Minimized Overhead

      It is desirable to minimize the overhead associated with 
      obtaining address space. Overhead includes the need to go back to 
      RIRs for additional space too frequently, the overhead associated 
      with managing address space that grows through a number of small 
      successive incremental expansions rather than through fewer, but 
      larger, expansions.


3.8   Conflict of goals

      The goals described above will often conflict with each other, or
      with the needs of individual IRs or end users. All IRs evaluating
      requests for allocations and assignments must make judgments,
      seeking to balance the needs of the applicant with the needs of
      the Internet community as a whole.

      In IPv6 address policy, the goal of aggregation is considered to
      be the most important.



4.    IPv6 Policy Principles

      To address the goals described in the previous section, the 
      policies in this document discuss and follow the basic principles 
      described below.


4.1   Address space not to be considered property

      It is contrary to the goals of this document and is not in the
      interests of the Internet community as a whole for address space
      to be considered freehold property.

      The policies in this document are based upon the understanding
      that globally-unique IPv6 unicast address space is licensed for
      use rather than owned. Specifically, IP addresses will be
      allocated and assigned on a license basis, with licenses subject
      to renewal on a periodic basis. The granting of a license is
      subject to specific conditions applied at the start or renewal of
      the license.

      RIRs will generally renew licenses automatically, provided
      requesting organizations are making a good-faith effort at
      meeting the criteria under which they qualified for or were
      granted an allocation or assignment. However, in those cases
      where a requesting organization is not using the address space as
      intended, or is showing bad faith in following through on the
      associated obligation, RIRs reserve the right to not renew the
      license.

      Note that when a license is renewed, the new license will be
      evaluated under and governed by the applicable IPv6 address
      policies in place at the time of renewal, which may differ from
      the policy in place at the time of the original allocation or
      assignment.


4.2   Routability not guaranteed

      There is no guarantee that any address allocation or assignment
      will be globally routable.

      However, RIRs must apply procedures that reduce the possibility
      of fragmented address space which may lead to a loss of 
      routability.


4.3   Minimum Allocation

      RIRs will apply a minimum size for IPv6 allocations, to
      facilitate prefix-based filtering.

      The minimum allocation size for IPv6 address space is /32.


4.4   Consideration of IPv4 infrastructure

      Subject to section 5.1.3, existing IPv4 networks may be 
      considered in determining the initial IPv6 allocation size.



5.    Policies for allocations and assignments


5.1   Initial IPv6 block for APNIC members with existing IPv4 space


5.1.1 Criteria

      APNIC members that have received an IPv4 address block from APNIC
      but have no IPv6 space can qualify for an appropriately sized
      IPv6 block under the matching IPv6 policy. For example, a member
      that has received an IPv4 IXP assignment will be eligible to
      receive an IPv6 IXP assignment.


5.1.2 Minimum size of IPv6 block

      The size of the IPv6 delegation for members that meet this
      criteria will be based on the following:

      * A member that has an IPv4 allocation is eligible for a /32 IPv6
        address block.
      * A member that has an IPv4 assignment is eligible for a /48 IPv6
        address block.

      If an APNIC member wishes to receive an initial allocation or
      assignment larger than the sizes described above, the member will
      need to apply under the alternative criteria described in
      sections 5.2 and 5.5 below.


5.2   Initial allocation


5.2.1 Initial allocation criteria

      To qualify for an initial allocation of IPv6 address space, an
      organization must:

      a. Be an LIR
      b. Not be an end site
      c. Plan to provide IPv6 connectivity to organizations to which it
         will make assignments
      d. Meet one of the two following criteria:
          * Have a plan for making at least 200 assignments to other
            organizations within two years OR
          * Be an existing LIR with IPv4 allocations from an APNIC or  
            an NIR, which will make IPv6 assignments or sub-allocations 
            to other organizations and announce the allocation in the
            inter-domain routing system within two years

      Private networks (those not connected to the public Internet) may 
      also be eligible for an IPv6 address space allocation provided 
      they meet equivalent criteria to those listed above.


5.2.2 Minimum initial allocation size

      Organizations that meet the initial allocation criteria are
      eligible to receive a minimum allocation of /32.


5.2.3 Larger initial allocations

      Initial allocations larger than /32 may be justified if:

      1. The organization provides comprehensive documentation of 
         planned IPv6 infrastructure which would require a larger 
         allocation; or
      2. The organization provides comprehensive documentation of all 
         of the following:
          * its existing IPv4 infrastructure and customer base,
          * its intention to provide its existing IPv4 services via
            IPv6, and
          * 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.


5.3   Subsequent allocation

      Organizations that hold an existing IPv6 allocation may receive a
      subsequent allocation in accordance with the following policies.


5.3.1 Subsequent allocation criteria

      Subsequent allocation will be provided when an organization
      (ISP/LIR) satisfies the evaluation threshold of past address
      utilization in terms of the number of sites in units of /56
      assignments. The HD-Ratio [RFC 3194] is used to determine the
      utilization thresholds that justify the allocation of additional
      address as described below.


5.3.2 Applied HD-Ratio

      The HD-Ratio value of 0.94 is adopted as indicating an acceptable
      address utilization for justifying the allocation of additional
      address space. Appendix A provides a table showing the number of
      assignments that are necessary to achieve an acceptable
      utilization value for a given address block size.


5.3.3 Subsequent allocation size

      When an organization has achieved an acceptable utilization for
      its allocated address space, it is immediately eligible to obtain
      an additional allocation that results in a doubling of the
      address space allocated to it. Where possible, the allocation
      will be made from an adjacent address block, meaning that its
      existing allocation is extended by one bit to the left.

      If an organization needs more address space, it must provide
      documentation justifying its requirements for a two-year period.
      The allocation made will be based on this requirement.


5.4   LIR-to-ISP allocation

      There is no specific policy for an organization (LIR) to allocate
      address space to subordinate ISPs. Each LIR organization may
      develop its own policy for subordinate ISPs to encourage optimum
      utilization of the total address block allocated to the LIR.
      However, all /48 assignments to end sites are required to be
      registered either by the LIR or its subordinate ISPs in such a
      way that the RIR/NIR can properly evaluate the HD-Ratio when a 
      subsequent allocation becomes necessary.


5.5   Assignment

      LIRs must make IPv6 assignments in accordance with the following 
      provisions.


5.5.1 Assignment address space size

      End-users are assigned an end site assignment from their LIR or
      ISP. The exact size of the assignment is a local decision for the
      LIR or ISP to make, using a minimum value of a /64 (when only one
      subnet is anticipated for the end site) up to the normal maximum
      of /48, except in cases of extra large end sites where a larger
      assignment can be justified.

      RIRs/NIRs are not concerned about which address size an LIR/ISP
      actually assigns. Accordingly, RIRs/NIRs will not request the
      detailed information on IPv6 user networks as they did in IPv4,
      except for the cases described in Section 4.4 and for the
      purposes of measuring utilization as defined in this document.


5.5.2 Assignment of multiple /48s to a single end site

      When a single end site requires an additional /48 address block,
      it must request the assignment with documentation or materials
      that justify the request. Requests for multiple or additional
      /48s will be processed and reviewed (i.e., evaluation of
      justification) at the RIR/NIR level.

      Note: There is no experience at the present time with the
      assignment of multiple /48s to the same end site. Having the RIR
      review all such assignments is intended to be a temporary measure
      until some experience has been gained and some common policies
      can be developed. In addition, additional work at defining
      policies in this space will likely be carried out in the near
      future.


5.5.3 Assignment to operator's infrastructure

      An organization (ISP/LIR) may assign a /48 per PoP as the service
      infrastructure of an IPv6 service operator. Each assignment to a
      PoP is regarded as one assignment regardless of the number of
      users using the PoP. A separate assignment can be obtained for
      the in-house operations of the operator.


5.6.  Registration

      When an organization holding an IPv6 address allocation makes
      IPv6 address assignments, it must register assignment information
      in a database, accessible by RIRs as appropriate (information
      registered by an RIR/NIR may be replaced by a distributed
      database for registering address management information in
      future). Information is registered in units of assigned /48
      networks. When more than a /48 is assigned to an organization,
      the assigning organization is responsible for ensuring that the
      address space is registered in an RIR/NIR database.

      RIR/NIRs will use registered data to calculate the HD-Ratio at
      the time of application for subsequent allocation and to check
      for changes in assignments over time.

      IRs shall maintain systems and practices that protect the
      security of personal and commercial information that is used in
      request evaluation, but which is not required for public
      registration.

      Organizations that receive an allocation from APNIC can choose
      whether or not their customer assignment registrations should be
      publicly available. If the organization does not indicate a
      choice, or it chooses to hide its customer assignment
      registrations, then those records will not be visible in the
      public whois database. Whois queries on these records will return
      details of the allocation.

      In addition, it is mandatory to register an Incident Report Team 
      (IRT) object for each allocation and assignment record in the APNIC 
      Whois Database.

5.7.  Reverse lookup

      When an RIR/NIR delegates IPv6 address space to an organization,
      it also delegates the responsibility to manage the reverse lookup
      zone that corresponds to the allocated IPv6 address space. Each
      organization should properly manage its reverse lookup zone. When
      making an address assignment, the organization must delegate to
      an assignee organization, upon request, the responsibility to
      manage the reverse lookup zone that corresponds to the assigned
      address.

 
5.8   Existing IPv6 address space holders

      Organizations that received /35 IPv6 allocations under the
      previous IPv6 address policy [RIRv6-Policies] are immediately
      entitled to have their allocation expanded to a /32 address
      block, without providing justification, so long as they satisfy
      the criteria in Section 5.1.1. The /32 address block will contain
      the already allocated smaller address block (one or multiple /35
      address blocks in many cases) that was already reserved by the
      RIR for a subsequent allocation to the organization. Requests for
      additional space beyond the minimum /32 size will be evaluated as
      discussed elsewhere in the document.


5.9   Portable assignments


5.9.1 Small multihoming assignments

      An organization is eligible to receive a portable assignment from
      APNIC if it is currently multihomed or plans to be multihomed
      within three months.

      An organization is considered to be multihomed if its network
      receives full-time connectivity from more than one ISP and has
      one or more routing prefixes announced by at least two of its
      ISPs.

      The minimum assignment made under these terms is /48.

      Address space assigned under these terms and not used for
      multihoming three months after assignment by APNIC will be
      reclaimed.


5.9.2 Internet Exchange Points

      Internet Exchange Points are eligible to receive a portable
      assignment from APNIC to be used exclusively to connect the IXP
      participant devices to the Exchange Point.

      The minimum assignment made under these terms is /48.

      Global routability of the portable assignment is left to the
      discretion of the IXP and its participants.


5.9.3 Critical infrastructure

      The following critical infrastructure networks, if operating in
      the Asia Pacific region, are eligible to receive a portable 
      assignment:

        * root domain name system (DNS) server;
        * global top level domain (gTLD) nameservers;
        * country code TLD (ccTLDs) nameservers;
        * IANA;
        * Regional Internet Registry (RIRs); and
        * National Internet Registry (NIRs).

      Assignments to critical infrastructure are available only to the
      actual operators of the network infrastructure performing such
      functions. Registrar organizations which do not actually host the
      network housing the registry infrastructure, will not be eligible
      for an assignment under this policy.

      The maximum assignment made under these terms is /32 per
      operator.

      Exchanges made under this policy remain subject to the address
      space license policy.



6.    References

      [RFC1715] "The H Ratio for Address Assignment Efficiency", C.
      Huitema. November 1994, RFC 1715.

      [IAB-Request] "Email from IAB to IANA",
      http://www.iab.org/iab/DOCUMENTS/IPv6addressspace.txt.

      [RFC2373] "IP Version 6 Addressing Architecture", R. Hinden, S.
      Deering. July 1998, RFC 2373.

      [RFC2373bis] draft-ietf-ipngwg-addr-arch-v3-07.txt.

      [RFC2928] "Initial IPv6 Sub-TLA ID Assignments", R. Hinden, S.
      Deering, R. Fink, T. Hain. September 2000, RFC 2928.

      [RFC3177] "IAB/IESG Recommendations on IPv6 Address". IAB, IESG.
      September 2001, RFC 3177.

      [RFC3194] "The H-Density Ratio for Address Assignment Efficiency
      An Update on the H ratio", A. Durand, C. Huitema. November 2001,
      RFC 3194.

      [RIRs-on-48]
      http://www.arin.net/library/guidelines/ipv6_initial.html,

      [RIRv6-Policies]
      http://www.arin.net/regserv/ipv6/ipv6guidelines.html,

      http://www.ripe.net/ripe/docs/ripe-196.html,

      http://archive.apnic.net/docs/drafts/ipv6/ipv6-policy-
      280599.html.



7.    Appendix A: HD-Ratio

      The utilization threshold T, expressed as a number of individual
      /56 prefixes to be allocated from IPv6 prefix P, can be
      calculated as:

      T=2((56-P)*HD)

      Thus, the utilization threshold for an organization requesting
      subsequent allocation of IPv6 address block is specified as a
      function of the prefix size and target HD ratio. This utilization
      refers to the allocation of /56s to end sites, and not the
      utilization of those /56s within those end sites. It is an
      address allocation utilization ratio and not an address
      assignment utilization ratio.

      This document adopts an HD-Ratio of 0.94 as the utilization
      threshold for IPv6 address space allocations.

      The following table provides equivalent absolute and percentage
      address utilization figures for IPv6 prefixes, corresponding to
      an HD-Ratio of 0.94
   

   P    56-P             Total /56s              Threshold    Util %
   
   56      0                      1                      1     100.0
   55      1                      2                      2      95.9
   54      2                      4                      4      92.0
   53      3                      8                      7      88.3
   52      4                     16                     14      84.7
   51      5                     32                     26      81.2
   50      6                     64                     50      77.9
   49      7                    128                     96      74.7
   48      8                    256                    184      71.7
   47      9                    512                    352      68.8
   46      10                 1,024                    676      66.0
   45      11                 2,048                  1,296      63.3
   44      12                 4,096                  2,487      60.7
   43      13                 8,192                  4,771      58.2
   42      14                16,384                  9,153      55.9
   41      15                32,768                 17,560      53.6
   40      16                65,536                 33,689      51.4
   39      17        	    131,072                 64,634      49.3
   38      18               262,144                124,002      47.3
   37      19        	    524,288                237,901      45.4
   36      20        	  1,048,576                456,419      43.5
   35      21             2,097,152                875,653      41.8
   34      22             4,194,304              1,679,965      40.1
   33      23             8,388,608              3,223,061      38.4
   32      24            16,777,216              6,183,533      36.9
   31      25            33,554,432             11,863,283      35.4
   30      26            67,108,864             22,760,044      33.9
   29      27           134,217,728             43,665,787      32.5
   28      28           268,435,456             83,774,045      31.2
   27      29           536,870,912            160,722,871      29.9
   26      30         1,073,741,824            308,351,367      28.7
   25      31         2,147,483,648            591,580,804      27.5
   24      32         4,294,967,296          1,134,964,479      26.4
   23      33         8,589,934,592          2,177,461,403      25.3
   22      34        17,179,869,184          4,177,521,189      24.3
   21      35        34,359,738,368          8,014,692,369      23.3
   20      36        68,719,476,736         15,376,413,635      22.4
   19      37       137,438,953,472         29,500,083,768      21.5
   18      38       274,877,906,944         56,596,743,751      20.6
   17      39       549,755,813,888        108,582,451,102      19.8
   16      40     1,099,511,627,776        208,318,498,661      18.9
   15      41     2,199,023,255,552        399,664,922,315      18.2
   14      42     4,398,046,511,104        766,768,439,460      17.4
   13      43     8,796,093,022,208      1,471,066,903,609      16.7
   12      44    17,592,186,044,416      2,822,283,395,519      16.0
   11      45    35,184,372,088,832      5,414,630,391,777      15.4
   10      46    70,368,744,177,664     10,388,121,308,479      14.8
    9      47   140,737,488,355,328     19,929,904,076,845      14.2
    8      48   281,474,976,710,656     38,236,083,765,023      13.6
    7      49   562,949,953,421,312     73,357,006,438,603      13.0
    6      50  1,125,899,906,842,620   140,737,488,355,328      12.5
    5      51  2,251,799,813,685,250   270,008,845,646,446      12.0
    4      52  4,503,599,627,370,500   518,019,595,058,136      11.5



8.    Appendix B: Background information


8.1   Background

      The impetus for revising the 1999 Provisional IPv6 policy started
      with the APNIC meeting held in Taiwan in August 2001. Follow-on
      discussions were held at the October, 2001 RIPE and ARIN
      meetings. During these meetings, the participants recognized an
      urgent need for more detailed, complete policies. One result of
      the meetings was the establishment of a single mailing list to
      discuss a revised policy together with a desire to develop a
      general policy that all RIRs could use. This document does not
      provide details of individual discussions that lead to policies
      described in this document; detailed information can be found in
      the individual meeting minutes at the www.apnic.net, 
      www.arin.net, and www.ripe.net web sites.
      
      

8.2   Why a joint policy

      IPv6 addresses are a public resource that must be managed with
      consideration to the long-term interests of the internet
      community. Although regional registries adopt allocation policies
      according to their own internal processes, address policies
      should largely be uniform across registries. Having significantly
      varying policies in different regions is undesirable because it
      can lead to situations where "registry shopping" can occur as
      requesting organizations request addresses from the registry that
      has the most favorable policy for their particular desires. This
      can lead to the policies in one region undermining the efforts of
      registries in other regions with regards to prudent stewardship
      of the address space. In cases where regional variations from the
      policy are deemed necessary, the preferred approach is to raise
      the issue in the other regional registries in order to develop a
      consensus approach that all registries can support.


8.3   The size of IPv6's address space

      It should be noted that the 128-bit address space is divided into
      three logical parts, with the usage of each component managed
      differently. The rightmost 64 bits, the Interface Identifier
      [RFC2373], will often be a globally-unique IEEE identifier (e.g.,
      mac address). Although an "inefficient" way to use the Interface
      Identifier field from the perspective of maximizing the number of
      addressable nodes, the numbering scheme was explicitly chosen to
      simplify Stateless Address Autoconfiguration [RFC2462]. The
      middle bits of an address indicate the subnet ID.


8.4   Acknowledgment

      The initial version of this document was produced by The JPNIC
      IPv6 policy drafting team consisting of Akihiro Inomata, Akinori
      Maemura, Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro
      Fujisaki, and Toshiyuki Yamasaki. Special thanks goes out to this
      team, who worked over a holiday in order to produce an initial
      document quickly.

      An editing team was then organized by representatives from each
      of the three RIRs (Takashi Arano, Chair of APNIC's Policy SIG,
      Thomas Narten, Chair of ARIN's IPv6 WG, and David Kessens, Chair
      of RIPE NCC's IPv6 WG).

      The editing team would like to acknowledge the contributions to
      this document of Takashi Arano, John Crain, Steve Deering, Gert
      Doering, Kosuke Ito, Richard Jimmerson, David Kessens, Mirjam
      Kuehne, Anne Lord, Jun Murai, Paul Mylotte, Thomas Narten, Ray
      Plzak, Dave Pratt, Stuart Prevost, Barbara Roseman, Gerard Ross,
      Paul Wilson, Cathy Wittbrodt and Wilfried Woeber.

      The final editing of the initial document was done by Thomas
      Narten.