[GLOBAL-V6] Final version of IPv6 policy document (document itself)

  • To: global-v6 at lists dot apnic dot net
  • Subject: [GLOBAL-V6] Final version of IPv6 policy document (document itself)
  • From: Thomas Narten <narten at us dot ibm dot com>
  • Date: Wed, 26 Jun 2002 15:38:49 -0400
  • Sender: owner-global-v6@lists.apnic.net
    •          IPv6 Address Allocation and Assignment Assignment Policy
                                     June, 26 2002
      
      
      Status of this Memo
      
         This document was developed through joint discussions among the
         APNIC, ARIN and RIPE communities.
      
      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
      
         Status of this Memo..........................................    1
      
         1.  Introduction.............................................    1
            1.1.  Overview............................................    1
      
         2.  Definitions..............................................    1
            2.1.  Internet Registry (IR)..............................    1
            2.2.  Regional Internet Registry (RIR)....................    1
            2.3.  National Internet Registry (NIR)....................    1
            2.4.  Local Internet Registry (LIR).......................    1
            2.5.  Allocate............................................    1
            2.6.  Assign..............................................    1
            2.7.  Utilization.........................................    1
            2.8.  HD-Ratio............................................    1
            2.9.  End site............................................    1
      
         3.  Goals of IPv6 address space management...................    1
            3.1.  Goals...............................................    1
            3.2.  Uniqueness..........................................    1
            3.3.  Registration........................................    1
            3.4.  Aggregation.........................................    1
            3.5.  Conservation........................................    1
            3.6.  Fairness............................................    1
            3.7.  Minimized Overhead..................................    1
            3.8.  Conflict of goals...................................    1
      
         4.  IPv6 Policy Principles...................................    1
      
      
      
                                                                      [Page 1]
      
      
      
      
      
                                         -2-
      
      
            4.1.  Address space not to be considered property.........    1
            4.2.  Routability not guaranteed..........................    1
            4.3.  Minimum Allocation..................................    1
            4.4.  Consideration of IPv4 Infrastructure................    1
      
         5.  Policies for allocations and assignments.................    1
            5.1.  Initial allocation..................................    1
               5.1.1.  Initial allocation criteria....................    1
               5.1.2.  Initial allocation size........................    1
            5.2.  Subsequent allocation...............................    1
               5.2.1.  Subsequent allocation criteria.................    1
               5.2.2.  Applied HD-Ratio...............................    1
               5.2.3.  Subsequent Allocation Size.....................    1
            5.3.  LIR-to-ISP allocation...............................    1
            5.4.  Assignment..........................................    1
               5.4.1.  Assignment address space size..................    1
               5.4.2.  Assignment of multiple /48s to a single end site    1
               5.4.3.  Assignment to operator's infrastructure........    1
            5.5.  Registration........................................    1
            5.6.  Reverse lookup......................................    1
            5.7.  Existing IPv6 address space holders.................    1
      
         6.  References...............................................    1
      
         7.  Appendix A: HD-Ratio.....................................    1
      
         8.  Appendix B: Background information.......................    1
            8.1.  Background..........................................    1
            8.2.  Why a joint policy..................................    1
            8.3.  The size of IPv6's address space....................    1
            8.4.  Acknowledgment......................................    1
      
      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 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
      
      
      
                                                                      [Page 2]
      
      
      
      
      
                                         -3-
      
      
         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.  Because end
         sites will generally be given /48 assignments [RFC 3177, RIRs-
         on-48s], the particular emphasis of this document is on policies
         relating the bits within 2000::/3 to the left of the /48 boundary.
         However, since some end sites will receive /64 and /128 assignments,
         all bits to the left of /64 are in scope.
      
         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.
      
      
                      +--------+
                      |  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)
                    |           |
              +--------+        |
      
      
      
                                                                      [Page 3]
      
      
      
      
      
                                         -4-
      
      
              |        |        |
          +-------+  +----+   +----+
          |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.
      
      
      
      
      
      
      
      
                                                                      [Page 4]
      
      
      
      
      
                                         -5-
      
      
      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
      
         Unlike IPv4, IPv6 is generally assigned to end sites in fixed amounts
         (/48).  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 /48
         boundary.  In other words, utilization refers to the assignment of
         /48s to end sites, and not the number of addresses assigned within
         individual /48s at those end sites.
      
         Throughout this document, the term utilization refers to the
         allocation of /48s to end sites, and not the number of addresses
         assigned within individual /48s 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 (/48s) 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
      
      
      
                                                                      [Page 5]
      
      
      
      
      
                                         -6-
      
      
            contains the end user's assignment
      
      
      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.
      
      
      
                                                                      [Page 6]
      
      
      
      
      
                                         -7-
      
      
         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.
      
      
      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
      
      
      
                                                                      [Page 7]
      
      
      
      
      
                                         -8-
      
      
         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.
      
      
      
      
      
      
                                                                      [Page 8]
      
      
      
      
      
                                         -9-
      
      
      4.4.  Consideration of IPv4 Infrastructure
      
         Where an existing IPv4 service provider requests IPv6 space for
         eventual transition of existing services to IPv6, the number of
         present IPv4 customers may be used to justify a larger request than
         would be justified if based solely on the IPv6 infrastructure.
      
      
      5.  Policies for allocations and assignments
      
      
      5.1.  Initial allocation
      
      
      5.1.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 assign /48s, by advertising that connectivity through its
            single aggregated address allocation; and
         d) have a plan for making at least 200 /48 assignments to other
            organizations within two years.
      
      
      5.1.2.  Initial allocation size
      
         Organizations that meet the initial allocation criteria are eligible
         to receive a minimum allocation of /32.
      
         Organizations may qualify for an initial allocation greater than /32
         by submitting documentation that reasonably justifies the request.
         If so, the allocation size will be based on the number of existing
         users and the extent of the organization's infrastructure.
      
      
      5.2.  Subsequent allocation
      
         Organizations that hold an existing IPv6 allocation may receive a
         subsequent allocation in accordance with the following policies.
      
      
      
      
      
      
      
      
                                                                      [Page 9]
      
      
      
      
      
                                        -10-
      
      
      5.2.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 /48 assignments.  The HD-
         Ratio [RFC 3194] is used to determine the utilization thresholds that
         justify the allocation of additional address as described below.
      
      
      5.2.2.  Applied HD-Ratio
      
         The HD-Ratio value of 0.8 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.2.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.3.  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.4.  Assignment
      
         LIRs must make IPv6 assignments in accordance with the following
         provisions.
      
      
      
                                                                     [Page 10]
      
      
      
      
      
                                        -11-
      
      
      5.4.1.  Assignment address space size
      
         Assignments are to be made in accordance with the existing guidelines
         [RFC3177,RIRs-on-48], which are summarized here as:
      
          - /48 in the general case, except for very large subscribers
          - /64 when it is known that one and only one subnet is needed by
            design
          - /128 when it is absolutely known that one and only one device is
            connecting.
      
         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.4.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.4.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.5.  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
      
      
      
                                                                     [Page 11]
      
      
      
      
      
                                        -12-
      
      
         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.
      
      
      5.6.  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.7.  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.
      
      
      
      6.  References
      
         [RFC1715] "The H Ratio for Address Assignment Efficiency", C.
                 Huitema.
                      November 1994, RFC 1715.
      
         [IAB-Request] "Email from IAB to IANA",
      
      
      
                                                                     [Page 12]
      
      
      
      
      
                                        -13-
      
      
                 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://www.apnic.net/docs/drafts/ipv6/ipv6-policy-280599.html.
      
      
      7.  Appendix A: HD-Ratio
      
         The HD-Ratio is not intended to replace the traditional utilization
         measurement that ISPs perform with IPv4 today.  Indeed, the HD-Ratio
         still requires counting the number of assigned objects.  The primary
         value of the HD-Ratio is its usefulness at determining reasonable
         target utilization threshold values for an address space of a given
         size.  This document uses the HD-Ratio to determine the thresholds at
         which a given allocation has achieved an acceptable level of
         utilization and the assignment of additional address space becomes
         justified.
      
         The utilization threshold T, expressed as a number of individual /48
         prefixes to be allocated from IPv6 prefix P, can be calculated as:
      
                           ((48-P)*HD)
                     T =  2
         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 /48s to end sites, and not the
      
      
      
                                                                     [Page 13]
      
      
      
      
      
                                        -14-
      
      
         utilization of those /48s within those end sites.  It is an address
         allocation utilization ratio and not an address assignment
         utilization ratio.
      
         In accordance with the recommendations of [RFC 3194], this document
         adopts an HD-Ratio of 0.8 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.8
      
              P    48-P          Total /48s        Threshold      Util%
      
             48       0                   1                1     100.0%
             47       1                   2                2      87.1%
             46       2                   4                3      75.8%
             45       3                   8                5      66.0%
             44       4                  16                9      57.4%
             43       5                  32               16      50.0%
             42       6                  64               28      43.5%
             41       7                 128               49      37.9%
             40       8                 256               84      33.0%
             39       9                 512              147      28.7%
             38      10                1024              256      25.0%
             37      11                2048              446      21.8%
             36      12                4096              776      18.9%
             35      13                8192             1351      16.5%
             34      14               16384             2353      14.4%
             33      15               32768             4096      12.5%
             32      16               65536             7132      10.9%
             31      17              131072            12417       9.5%
             30      18              262144            21619       8.2%
             29      19              524288            37641       7.2%
             28      20             1048576            65536       6.3%
             27      21             2097152           114105       5.4%
             26      22             4194304           198668       4.7%
             25      23             8388608           345901       4.1%
             24      24            16777216           602249       3.6%
             23      25            33554432          1048576       3.1%
             22      26            67108864          1825677       2.7%
             21      27           134217728          3178688       2.4%
             20      28           268435456          5534417       2.1%
             19      29           536870912          9635980       1.8%
             18      30          1073741824         16777216       1.6%
             17      31          2147483648         29210830       1.4%
             16      32          4294967296         50859008       1.2%
             15      33          8589934592         88550677       1.0%
      
      
      
                                                                     [Page 14]
      
      
      
      
      
                                        -15-
      
      
             14      34         17179869184        154175683       0.9%
             13      35         34359738368        268435456       0.8%
             12      36         68719476736        467373275       0.7%
             11      37        137438953472        813744135       0.6%
             10      38        274877906944       1416810831       0.5%
             9       39        549755813888       2466810934       0.4%
             8       40       1099511627776       4294967296       0.4%
             7       41       2199023255552       7477972398       0.3%
             6       42       4398046511104      13019906166       0.3%
             5       43       8796093022208      22668973294       0.3%
             4       44      17592186044416      39468974941       0.2%
      
      
      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.
      
      
      
                                                                     [Page 15]
      
      
      
      
      
                                        -16-
      
      
      8.3.  The size of IPv6's address space
      
         Compared to IPv4, IPv6 has a seemingly endless amount of address
         space.  While superficially true, short-sighted and wasteful
         allocation policies could also result in the adoption of practices
         that lead to premature exhaustion of the 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 16 bits of an address indicate the subnet ID.  Per [RFC
         3177, RIRs-on-48s], this field will often be inefficiently utilized,
         but the operational benefits of a consistent width subnet field were
         deemed to be outweigh the drawbacks.
      
         The decisions to inefficiently utilize the bits to the right of /48
         were made under the knowledge and assumption that the bits to the
         left of /48 would be managed prudently and that if done so, will be
         adequate for the expected lifetime of IPv6 [RFC3177].
      
      
      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 this document was done by Thomas Narten.
      
      
      
                                                                     [Page 16]
      
      -
      - This list (global-v6) is handled by majordomo at lists dot apnic dot net