IPv6 Address Allocation and Assignment Policy

   APNIC
   ARIN
   RIPE NCC

   Document ID: ripe-267
   Date: 22 January 2003
   Obsoletes: ripe-196, ripe-246
     _____________________________________________________________________

Abstract

   This document defines registry policies for the assignment and
   allocation of globally unique IPv6 addresses to Internet Service
   Providers (ISPs) and other organisations. This document obsoletes
   the "Provisional IPv6 assignment and allocation policy
   document". It was developed through joint discussions among the
   APNIC, ARIN and RIPE communities.
   _____________________________________________________________________

Table of 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. Utilisation
     2.8. HD-Ratio
     2.9. End Site

   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. Minimised 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 allocation
     5.1.1. Initial allocation criteria
     5.1.2. Initial allocation size
     5.2. Subsequent allocation
     5.2.1. Subsequent allocation criteria
     5.2.2. Applied HD-Ratio
     5.2.3. Subsequent Allocation Size
     5.3. LIR-to-ISP allocation
     5.4. Assignment
     5.4.1. Assignment address space size
     5.4.2. Assignment of multiple /48s to a single end site
     5.4.3. Assignment to operator's infrastructure
     5.5. Registration
     5.6. Reverse lookup
     5.7. Existing IPv6 address space holders

   6. Assignments for Internet Experiments

     6.1 Defining the experiment
     6.2 Publication
     6.3 Non-commercial basis
     6.4 Period of the temporary resource registration
     6.5 Registration
     6.6 Making the request
     6.7 Nota bene
     
   7. References
     
   8. Appendix A: HD-Ratio

   9. Appendix B: Background information

     9.1. Background
     9.2. Why a joint policy
     9.3. The size of IPv6's address space  
     9.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.

   [RFC 2373, RFC 2373bis] designate 2000::/3 to be global unicast
   address space that the Internet Assigned Numbers Authority (IANA)
   may allocate to the RIRs. In accordance with [RFC 2928, RFC
   2373bis, 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. 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)
               |            |
          +--------+        |

          |        |        |
      +-------+  +----+   +----+
      |EU(ISP)|  | EU |   | EU |     End users
      +-------+  +----+   +----+

     
   
2.1. Internet Registry (IR)
   
   An Internet Registry is an organisation 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 are established and authorised by
   respective regional communities and recognised 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 primarily allocates address space to
   its members or constituents, which are generally LIRs organised at
   a national level. NIRs exist mostly in the Asia Pacific region.
   
2.4. Local Internet Registry (LIR)
   
   A Local Internet Registry 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 organisations and are not to be sub-assigned
   to other parties.
     
2.7. Utilisation
     
   Unlike IPv4, IPv6 is generally assigned to End Sites in fixed
   amounts (e.g. /48). The actual usage of addresses within each
   assignment will be low when compared to IPv4 assignments. In IPv6,
   "utilisation" is only measured in terms of the bits to the left of
   the /48 boundary. In other words, "utilisation" 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 "utilisation" 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
   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.
   
   Further, RIRs should apply practices that maximise 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. Minimised overhead
   
   It is desirable to minimise 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 organisations 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 organisation 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
   
   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
   organisation must:
   
     a) be an LIR;
   
     b) not be an End Site;
   
     c) plan to provide IPv6 connectivity to organisations 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
     organisations within two years.
   
5.1.2. Initial allocation size
   
   Organisations that meet the initial allocation criteria are
   eligible to receive a minimum allocation of /32.
   
   Organisations 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 organisation's infrastructure.
 
5.2. Subsequent allocation
   
   Organisations that hold an existing IPv6 allocation may receive a
   subsequent allocation in accordance with the following policies.
   
5.2.1. Subsequent allocation criteria

   Subsequent allocation will be provided when an organisation
   (i.e. ISP/LIR) satisfies the evaluation threshold of past address
   utilisation in terms of the number of sites in units of /48
   assignments. The HD-Ratio [RFC 3194] is used to determine the
   utilisation 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 utilisation 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 utilisation
   value for a given address block size.
   
5.2.3. Subsequent allocation size
   
   When an organisation has achieved an acceptable utilisation 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 organisation 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 organisation (LIR) to allocate
   address space to subordinate ISPs. Each LIR organisation may
   develop its own policy for subordinate ISPs to encourage optimum
   utilisation 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.
   
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 utilisation 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 organisation (i.e. 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 organisation 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 organisation, the
   assigning organisation 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 organisation, it
   also delegates the responsibility to manage the reverse lookup zone
   that corresponds to the allocated IPv6 address space. Each
   organisation should properly manage its reverse lookup zone. When
   making an address assignment, the organisation must delegate to an
   assignee organisation, upon request, the responsibility to manage
   the reverse lookup zone that corresponds to the assigned address.
   
5.7. Existing IPv6 address space holders
   
   Organisations 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 organisation. Requests for additional
   space beyond the minimum /32 size will be evaluated as discussed
   elsewhere in the document.
   
6.0 Assignments for Internet Experiments
   
   Organisations often require deployment tests for new Internet
   services and technologies. These require numbering resources for
   the duration of the test.

   The policy goal of resource conservation is of reduced importance
   when resources are issued on a temporary basis.
   
6.1 Defining the experiment
   
   An organisation receiving numbering resources must document the
   experiment. This may be in the form of a current IETF Experimental
   RFC (http://www.ietf.org/rfc/rfc2026.txt see Sec. 4.2.1) or an
   "experiment proposal" detailing the resources required and the
   activities to be carried out.
   
   The assignment size will be equal to the existing minimum
   allocation size on the date the request is received. Where the
   experiment requires a variation to this rule it should be noted in
   the resource request.
   
6.2 Publication
   
   The experiment proposal must be made public (e.g. published on web
   site), upon registration of the resources by the RIPE
   NCC. Following the conclusion of the experiment the results must be
   published free of charge and free from disclosure constraints.
   
6.3 Non-commercial basis
   
   Resources issued for an experiment must not be used for commercial
   purposes.

6.4 Period of the Temporary Resource Registration

   The resources will be issued on a temporary basis for a period of
   one year. Renewal of the resource's registration is possible on
   receipt of a new request that details any continuation of the
   experiment during the extended period.
   
   The resources issued cannot be used for a commercial service
   following the conclusion of the experiment.

6.5 Registration
   
   The RIPE NCC will register the resources issued in the RIPE Whois
   Database.
   
6.6 Making the request
   
   The request must be made by a Local Internet Registry (LIR) using
   the appropriate request form for the resource found at:
   
   http://www.ripe.net/ripe/docs/internet-registries.html#request

7. References
   
   [RFC1715] "The H Ratio for Address Assignment Efficiency", C. Huitema. 
   November 1994, ftp://ftp.ripe.net/rfc/rfc1715.txt.

   [IAB-Request] "Email from IAB to IANA",
   http://www.iab.org/iab/DOCUMENTS/IPv6addressspace.txt.
   
   [RFC2026] "The Internet Standards Process -- Revision 3 IETF Experimental
   RFC ftp://ftp.ripe.net/rfc/rfc2026.txt see Sec. 4.2.1
   
   [RFC2373] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering.
   July 1998,
   ftp://ftp.ripe.net/rfc/rfc2373.txt.
   
   [RFC2373bis]
   http://www.ietf.org/internet-drafts/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
   ftp://ftp.ripe.net/rfc/rfc2928.txt.
   
   [RFC3177] "IAB/IESG Recommendations on IPv6 Address". IAB, IESG. September
   2001, ftp://ftp.ripe.net/rfc/rfc3177.txt.
   
   [RFC3194] "The H-Density Ratio for Address Assignment Efficiency An Update
   on the H ratio", A. Durand, C. Huitema. November 2001,
   ftp://ftp.ripe.net/rfc/rfc3194.txt.
   
   [RIRs-on-48]
   http://www.arin.net/library/guidelines/ipv6_initial.html.

   [RIRv6-Policies]
   http://www.arin.net/registration/ipv6/,
   http://www.ripe.net/ripe/docs/ipv6-policy.html,
   http://www.apnic.net/docs/drafts/ipv6/ipv6-policy-280599.html.
   
8. Appendix A: HD-Ratio
   
   The HD-Ratio is not intended to replace the traditional utilisation
   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 utilisation 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
   utilisation and the assignment of additional address space becomes
   justified.

   The utilisation 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 utilisation threshold for an organisation requesting subsequent
   allocation of IPv6 address block is specified as a function of the prefix
   size and target HD ratio. This utilisation refers to the allocation of 
   /48s to End Sites, and not the utilisation of those /48s within those End
   Sites. It is an address allocation utilisation ratio and not an address
   assignment utilisation ratio.
   
   In accordance with the recommendations of [RFC 3194], this document
   adopts an HD-Ratio of 0.8 as the utilisation threshold for IPv6
   address space allocations.
   
   The following table provides equivalent absolute and percentage
   address utilisation 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%
        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%
   
   
9. Appendix B: Background information
   
9.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 recognised 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.
   
   In September 2002 at the RIPE 43 Meeting in Rhodes, Greece, the
   RIPE community approved the policy allowing Internet experiments to
   receive temporary experiments. As a result, Section 6 was added to
   this document in January 2003.
        
9.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 organisations
   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.
        
9.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].
   
9.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 organised 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 the
   RIPE IPv6 Working Group).

   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 version of this document was done
   by Thomas Narten.
