Status of this Memo

   This document specifies "Internet best current practices" for the
   Internet community, and requests discussion and suggestions for
   improvements.  Distribution of this document is unlimited as long as
   its contents remain unchanged.

   Comments on this document should be sent to the global-v6 mailing
   list:

      To post: <global-v6@lists.apnic.net>.
      To subscribe:  <http://www.apnic.net/net_comm/lists/>
      Archives: <http://www.apnic.net/mailing-lists/global-v6>

   Contents

   Status of this Memo..........................................    1

   1.  Introduction.............................................    2
      1.1.  Overview............................................    2
      1.2.  Current Status......................................    3

   2.  Definitions..............................................    4
      2.1.  Autonomous System (AS)..............................    5
      2.2.  Internet Registry (IR)..............................    5
      2.3.  Internet Assigned Numbers Authority (IANA)..........    5
      2.4.  Regional Internet Registry (RIR)....................    6
      2.5.  National Internet Registry (NIR)....................    6
      2.6.  Local Internet Registry (LIR).......................    6
      2.7.  Allocate............................................    6
      2.8.  Assign..............................................    6
      2.9.  Utilization.........................................    7
      2.10.  Site...............................................    7

   3.  Goals of IPv6 address space management...................    7
      3.1.  Goals...............................................    7
      3.2.  Uniqueness..........................................    8
      3.3.  Registration........................................    8
      3.4.  Aggregation.........................................    8
      3.5.  Conservation (Stewardship)..........................    9
      3.6.  Fairness............................................    9
      3.7.  Minimize Overhead...................................    9
      3.8.  Conflict of goals...................................    9

   4.  IPv6 Policy Principles...................................   10
      4.1.  Address space not to be considered property.........   10
      4.2.  Routability not guaranteed..........................   11
      4.3.  Minimum Allocation..................................   11
      4.4.  Consideration of IPv4 Infrastructure................   12

   5.  Policies for allocations and assignments.................   12
      5.1.  Consistency of IR address space management policies.   12
      5.2.  Initial allocation..................................   12
         5.2.1.  Initial allocation criteria....................   12
         5.2.2.  Initial allocation size........................   13
      5.3.  Subsequent allocation...............................   13
         5.3.1.  Subsequent allocation criteria.................   13
         5.3.2.  Utilization Metric.............................   13
         5.3.3.  Applied HD-Ratio...............................   14
         5.3.4.  Subsequent Allocation Size.....................   14
      5.4.  LIR-to-ISP allocation...............................   14
      5.5.  Assignment..........................................   15
         5.5.1.  Assignment address space size..................   15
         5.5.2.  Assignment to a site...........................   15
         5.5.3.  Assignment of multiple /48s to a single site...   15
         5.5.4.  Assignment to operator's infrastructure........   15
      5.6.  DB registration.....................................   16
      5.7.  Reverse lookup......................................   16
      5.8.  Validity of allocations and assignments.............   16
      5.9.  Existing IPv6 address space holders.................   17

   6.  Special case.............................................   17
      6.1.  IX (Internet Exchange)..............................   17

   7.  Acknowledgment...........................................   17

   8.  References...............................................   18

   9.  Appendix A:..............................................   19

1.  Introduction

1.1.  Overview

   This document describes policies for the allocation and assignment of
   globally unique Internet Protocol Version 6 (IPv6) address space. In
   particular, [RFC2373, RFC2373bis] designates 2000::/3 to be global
   unicast address space that IANA may allocate.  In accordance with
   [RFC2928, RFC2373bis, IAB-Request], IANA has assigned 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 policies.  Because end sites will
   generally be given /48 allocations [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 allocations, all bits to the left
   of /64 are in scope.

   This document updates and replaces all the guidelines and procedures
   of the existing Provisional IPv6 Policies [RIRv6-Policies] based on
   over two years of experience with the 1999 policy.  The Provisional
   IPv6 Policy document will be obsoleted with the adoption of this
   document.

   Address policies should be globally uniform and formulated in a
   bottom-up manner through consensus processes at regional and global
   levels. Address policies must be determined with well-balanced
   consideration given to not only technical constraints and the
   expectations of the Internet community, but also to the operational
   needs of ISPs and end users.  Furthermore, the policies should be
   reviewed whenever necessary in accordance with changes in the
   external environment or operational experience of the relevant
   communities.

   Policies described in this document are global in nature and are
   intended to be followed in each registry.  However, adoption of this
   document does not preclude local variations in each region or area.

   This policy is also considered an interim policy in the sense that
   there is still little experience with allocating IPv6 addresses.  As
   experience from implementing the policy is gained, some aspects of
   the policy will likely need review and updating.

1.2.  Current Status

   The APNIC meeting held in Taiwan in August 2001 discussed policies
   relating to IPv6 address allocation and assignment and reached a
   certain consensus.  Afterward, similar suggestions were made at a
   RIPE meeting held in October 2001 and an ARIN meeting held in the
   same month.  Various discussions were held at these meetings, with
   consensus identified on a number of points.  This document makes a
   proposal based upon the results of discussions at these meetings.

   In all of these meetings, the participants recognized an urgent need
   for more detailed, complete policies in the Asia Pacific Region
   governing global IPv6 address space management. It was generally
   recognized that discussion about policies for IPv6 allocation and
   assignment will not easily come to an end, but there is a consensus
   that such discussion should be summed up quickly to establish interim
   policies.  Accordingly, this document should be considered as a time-
   limited public document that describes the most reasonable solution
   available at present that has been obtained through these
   discussions.  This document will therefore be duly updated as the
   Internet environment of IPv6 progresses, and it is expected that
   updates will occur relatively frequently in the coming years.

   This document does not provide details of discussions concerning
   individual policy issues, however the following sources provide
   background information which may be of interest:

   Meeting results: <http://www.apnic.net/meetings/12/results/>
   <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes.html>
   <http://www.arin.net/minutes/ARIN_VIII/PPM.html>

   Presentation Materials:
   <http://www.apnic.net/meetings/12/docs/prop_new_ipv6_policy.ppt>
   <http://www.apnic.net/meetings/12/docs/ipv6principles-dist.ppt>
   <http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/>
   <http://www.arin.net/minutes/ARIN_VIII/PPM.html>

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  |  |   RIR  | Regional Internet
                    +--------+  +--------+  +--------+ Registries
                                     |
                      +-----------+--+--------+
                      |           |           |
                      |        +-----+     +-----+
                      |        | NIR |     | NIR |     National Internet
                      |        +-----+     +-----+     Registries
                      |           |           |
                +--------+   +--------+   +--------+
                |LIR/ISP |   |LIR/ISP |   |LIR/ISP |   Local Internet
                +--------+   +--------+   +--------+   Registries
                   |              |           |
               +---------+        |           |
               |         |        |           |
           +-------+   +----+    +----+     +----+
           |EU(ISP)|   | EU |    | EU |     | EU |     End users
           +-------+   +----+    +----+     +----+

2.1.  Autonomous System (AS)

   Autonomous Systems are the unit of routing policy in the world of
   exterior routing, and are specifically applicable to protocols like
   BGP [RFC1771].

2.2.  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.3.  Internet Assigned Numbers Authority (IANA)

   The Internet Assigned Numbers Authority (IANA) has responsibility for
   management of the entire IP address space used on the Internet.
   Actual assignment operations are performed by organizations under
   IANA.  Rather than allocating or assigning address space to
   operational networks, the IANA delegates responsibility for large
   blocks of address space to Regional Internet Registries, for
   management at the regional level.

2.4.  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.  Currently, there are three RIRs: APNIC,
   RIPE NCC, and ARIN.  Preparations are being made to establish LACNIC
   and AfriNIC.

2.5.  National Internet Registry (NIR)

   A National Internet Registry (NIR) is an IR that primarily allocates
   address space to its members, which are Local Internet Registries
   (LIRs).  NIR members are generally Internet Service Providers (ISPs)
   organized at a national level.  A NIR is constituted from ISPs, but
   the NIR itself does not function as an ISP.  NIRs are expected to
   remain neutral to the interests of ISPs of their constituency.  NIRs
   exist mostly in the Asia Pacific Region.

2.6.  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.7.  Allocate

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

2.8.  Assign

   To assign means to designate address space that an IR distributes
   part or all of to an end user for the purpose of actual deployment in
   that end user's or ISP's own network.  Address space is also
   designated as assigned if the IR uses it for the purpose of
   addressing their own network.  Assignments are made only for specific
   purposes demonstrated by specific organizations and are not be sub-
   allocated or sub-assigned to other parties.

   In this hierarchical structure, IANA allocates address space to RIRs
   for the purpose of redistribution.  RIRs then allocate address space
   to NIRs or LIRs in their respective regions (or in some cases to NIRs
   which further allocate the space to LIRs within their own countries).
   Each NIR allocates address space to LIRs in its own country.  When an
   RIR or NIR allocates address space to an LIR, it also delegates to
   the LIR the authority to assign addresses to end users.

2.9.  Utilization

   Unlike IPv4, IPv6 generally assigns a /48 to each end site. The
   actual utilization of any particular /48, when compared to IPv4 ,
   will be extremely low. In IPv6, the "utlization" that is of interest
   refers to the bits to the left of the /48.

   Throughout this document, the term utilization refers to the
   allocation of /48s to end sites, and not the utilization of those
   /48s within those end sites.

2.10.  Site

   A site is defined as an end user (subscriber) who has a business
   relationship with a provider that involves that provider carrying its
   traffic.  Every end user (subscriber) individually on a contract with
   an ISP is considered an entity and is eligible to receive a /48 IPv6
   assignment, regardless of organization or geographical location.

3.  Goals of IPv6 address space management

3.1.  Goals

   The goals of address space management described here reflect the
   mutual interest of all members of the Internet community and ensure
   that the Internet is able to function and grow to the maximum extent
   possible.

   Address policies must be determined with well-balanced consideration
   given to not only technical constraints and the expectations of the
   Internet community but also to the operational needs of ISPs and end
   users.

   These goals are essentially the same as the goals in IPv4 policies
   that have been formulated by the Internet community.  However,
   attention must be paid to the fact that differences between IPv6 and
   IPv4 change the relative priority of elements that must be considered
   to attain these goals.

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

   Every assignment and allocation of Internet address space must be
   registered in a public registry database accessible to all members of
   the Internet community.

Which database is this referring to ?  Each RIR database?

   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.

Are we talking /48s /64s and /128s?

   It also reflects the expectation of the Internet community that all
   users of public resources, such as address space, should be able to
   check the conditions of the resources.

What does "conditions of the resource" mean?

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
   and limit the expansion of Internet routing tables.  With its vast
   address space, IPv6 makes hierarchical distribution for aggregation
   much easier than IPv4.

   The IPv6 specification creates a huge address space, and the number
   of hosts under internal routing control of an individual autonomous
   system is expected to increase dramatically compared with IPv4. For
   example, cellular phones, various electric appliances, and telemeter
   sensors, are likely to become connected to the Internet in addition
   to the conventional types of IPv4 hosts. Thus, hierarchical
   distributions must be considered to limit the expansion of routing
   tables regarding not only external routing information advertised in
   the Internet default-free zone but also internal routing information
   within an autonomous system.  Because internal aggregation is
   important, policies should be sensitive to supporting better internal
   aggregation (e.g, through assignment of bigger blocks).

3.5.  Conservation (Stewardship)

   Maintaining unnecessary allocations and assignments or stockpiling
   address space with no aggregation merit should be avoided as a matter
   of course.  Also, efforts must be made for the efficiency of address
   use as much as possible within the bounds of other constraints.

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.  Minimize Overhead

   It is desirable to minimize the overhead associated with obtaining
   additional address space as a site grows. 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, etc.

3.8.  Conflict of goals

   The goals of conservation, aggregation and minimization of
   administrative overhead often conflict with each other.  In IPv6
   address management, the six goals described above are given different
   priorities from the implicit priorities of IPv4 address management.

   IPv6 address management should give higher priority to aggregation
   and lower priority to address conservation, when compared with
   current IPv4 management practices.  This does not mean that wasteful
   address usage should be tolerated because vast address space is
   available.  Instead, emphasis is placed on the need for policies that
   place aggregation in higher priority so that the number of external
   and internal routes will be practically limited in the large address
   space to ensure stable Internet operations for a long time to come.
   Emphasis on aggregation sometimes leads to somewhat lower priority on
   address conservation because these two goals tend to conflict with
   each other.

   It should be noted that an exclusive choice between aggregation and
   conservation will not be made on the basis of the policies or
   judgment of any registry practices in accordance with these policies.

   Both aggregation and conservation should be taken into consideration
   in the right balance. In IPv6, the right balance is generally "more
   aggregation, less conservation".

   The balance between aggregation and conservation will be reviewed
   over time according to various factors, such as operational
   experience and address consumption.

   Some or all of the goals described here may occasionally be in
   conflict with the interests of individual IRs or end users.
   Therefore, all IRs evaluating requests for allocations and
   assignments must make judgment, seeking to balance the needs of the
   applicant with the needs of the Internet community as a whole.

   The policies described in this document are intended to help IRs
   balance these needs in consistent and equitable ways.  Full
   documentation of and transparency within the decision making process
   must also be maintained in order to achieve this result.

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 global IPv6 policies in this document are based upon the
   understanding that address space is lease-licensed for use rather
   than owned. All Internet Registries are expected to manage address
   space operations correctly in accordance with this principle.

   According to this policy, IP addresses will be allocated on a lease-
   license basis, with such lease-licenses to be of specific limited
   duration of normally one year.  Conditions of a lease-license have
   specific conditions applied at the start or renewal of the lease.

   Lease-licenses will typically be renewed automatically at the end of
   their duration when the following two conditions are met:
    a) The original basis of the allocation remains valid.
    b) Registration requirements relating to that allocation have been
      fulfilled at the time of renewal

   However, when a lease-license is renewed, the new lease-license will
   be evaluated under and governed by the applicable resource allocation
   and renewal policies in place at the time of renewal.

   Changes to the conditions of current lease-licences shall be subject
   to a definite period of notice, except in exceptional circumstances
   recognized by a consensus of the Internet community.

   As address space is not owned, and consistent with the desire to
   avoid excessive fragmentation of address space, it may become
   necessary in extreme circumstances to renumber assignments. Such
   renumbering will only be undertaken after extensive consultation with
   the Internet community.

4.2.  Routability not guaranteed

   Because IPv6 is fundamentally based upon aggregatable addresses, its
   circumstance differs from IPv4, which contains a number of non-
   provider-based assignments for historical reasons.  Nonetheless,
   registries are not responsible for routability, which is affected by
   the technical implementation by LIRs/ISPs. RIRs must take steps,
   however, to ensure that allocations they make will not result in
   excessively fragmented address space, as that may lead to loss of
   routability.

4.3.  Minimum Allocation

   As under current IPv4 management policies, it is proposed that IPv6
   policies establish a "minimum allocation" of address space, which
   serves to limit the distribution by Internet Registries of portable
   address prefixes.

   Generally speaking, making minimum allocation size too small leads to
   address fragmentation, and making the size too large lowers the
   efficiency of address use.  Discussion about the appropriate size of
   allocation needs to be continued in the future.  The interim policies
   adopt the following concept:

   First, a minimum address space (/32) will be provided by default by
   RIR/NIR to LIRs.  However, many large providers will quickly deplete
   a /32 space and need to use more address space within a short time.
   For this reason, providers requiring space larger than a /32 may
   request more address space, but must provide justification for such a
   request.

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 as a reason for requesting more
   space in justifying IPv6 address space requests.  This is based upon
   the implicit assumption that service providers having a large number
   of IPv4 customers are likely to have many customers in IPv6 as well.

   This assumption should be evaluated and reviewed on the next occasion
   of revising the policies.

5.  Policies for allocations and assignments

5.1.  Consistency of IR address space management policies

   All Internet Registries shall adopt policies that are consistent with
   the policies formulated by the Internet community and described in
   this document.

5.2.  Initial allocation

5.2.1.  Initial allocation criteria

   A requesting organization can receive an initial allocation by
   demonstrating that it has an immediate (i.e., within next three
   months) requirement for at least a /36 prefix.  That is, immediately
   after the allocation, the organization will have 776 or more sites in
   need of address assignments.  776 is the number of /48 address blocks
   that can be assigned out of a /36 address block to achieve an HD-
   Ratio of 0.8.  The HD-Ratio is an address allocation utilization
   metric proposed in RFC 3194 as an adaptation of the H-Ratio
   originally defined in [RFC1715].  (See also Section 5.3.3.)

This para now mention 3 months, but this is too short a time to connect 776 customer sites. It is not obvious what the new time frame should be, but it should be longer than 3 months.

   [Note: discussion is needed as to whether justification for need of a
   /36 is reasonable initial starting point, or whether the criteria of
   an immediate need to address 776 sites is too high. Note also, that
   once a request for an initial allocation has been granted, the
   minimum allocation (i.e., /32) is provided, even though the requestor
   has not justified a need for such a large amount of space.]

5.2.2.  Initial allocation size

   A requesting organization satisfying the initial allocation criteria
   can receive an initial allocation of the minimum /32 address block.
   Any organization requesting a larger address block may receive the
   necessary size of allocation by submitting documentation that
   reasonably justifies the necessity.  For instance, a provider or an
   enterprise currently providing IPv4 address services may apply for
   and receive an initial allocation of the size reasonably judged
   necessary to provide all the existing users with IPv6 services. In
   this case, the necessary size will be judged on the basis of the
   number of existing users and infrastructure.

Shouldn't this be that the IPv4 provider should be allocated an initial allocation for its IPv4 customers PLUS the next 2 years growth, as in 5.3.4. Otherwise we will have the scenario where an IP v4 provider switches to IPv6, and changes its customers over to IPv6 and then has to go back to the RIR to request an additional block for its new IPv6 customers.  Suggest that the "2 year rule" should be applied here also.

   This can be represented by the following expression:

       S(0) = shorter(/32, eval(required prefix size))

   where (required prefix size) is the prefix size of applicant
   requesting allocation

5.3.  Subsequent allocation

   An organization (ISP/LIR) that has already received an address block
   from an RIR/NIR 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 /48 assignments.  The HD-
   Ratio is used to assess the utilization of the existing address block
   as described below.

5.3.2.  Utilization Metric

   In general, HD-Ratio [RFC3194] is expressed as follows:
                     Log (number of allocated objects)
                HD = ------------------------------------------------
                     Log (maximum number of allocatable objects)
   where the objects are IPv6 site addresses (/48s) assigned from an
   IPv6 prefix of length P.

   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
   utilization of those /48s within those end sites. It is an address
   allocation utilization ratio and not an address assignment
   utilization ratio.

5.3.3.  Applied HD-Ratio

   A desirable HD-Ratio for evaluation is thought to lie between 0.80
   and 0.85, with the actual value needing to be determined as
   experience is gathered from implementation of this policy.  An HD-
   ratio of 0.8 is adopted for this interim policy. The value may change
   in response to implementation experience.

5.3.4.  Subsequent Allocation Size

   The size of an "n"-th time subsequent allocation S(n) is found as:

           S(n) = shorter(S(n-1)-1, eval(two_years_req))
   where S(n-1)-1 represents one bit shorter prefix address block size
   of the previous allocated address block size, and eval(two_years_req)
   represents the evaluation of two-year demands of the requesting
   organization.

   In other words, an organization (ISP/LIR) satisfying the criteria can
   receive at least one bit shorter prefix automatically.

   If an organization needs more address space, it needs to demonstrate
   its two-year demand to an RIR/NIR. Then, the RIR/NIR evaluates it and
   allocates the address prefix enough to satisfy its two-year
   requirements.

5.4.  LIR-to-ISP allocation

   There is no specific policy for an organization (ISP/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, the LIR is
   required to keep track of all /48s assignments, including assignments
   made by its subordinate ISPs to end users, and report the assignment
   status to RIR/NIR so that the HD-Ratio can be evaluated when a
   subsequent allocation becomes necessary.

Here the text implies that the LIR should keep track of all subordinate allocations, which means that if an LIR allocates a block to a subordinate ISP then the LIR needs to keep track of all the /48s that the subordinate ISP allocates to its own customers.  Then, when the LIR requests a larger allocation, that same LIR needs to report these allocations to RIR/NIR so that the RIR/NIR can then calculate the subsequent allocation.  However, earlier in "3.3.  Registration" it says that "Every assignment and allocation of Internet address space must be registered in a public registry database accessible to all members of the Internet community"

It also talks about registration in 5.6 see below.
This registration question needs clarifying - the document contradicts itself.

Currently in IPv4, addresses are registered in either a public database or in the LIR's own database, thus allowing a mixture. Thus, if we need to keep our customer information private, we can keep it "off" a public database, but if the customer does want to be seen in the public database then we can enter it.  Suggest the same principle needs to be applied to IPv6.

5.5.  Assignment

   This section describes the assignment policy.

5.5.1.  Assignment address space size

   Address space following the 64th bit is the IETF boundary [RFC2460].
   Address space following the 48th bit is a policy boundary, with IETF
   recommendations [RFC3177] and RIR agreement [RIRs-on-48] recommending
   the assignment of:

    - /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 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 to a site

5.5.3.  Assignment of multiple /48s to a single site

   When a single site requires an additional /48 address block, it can
   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.

5.5.4.  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.  On the other hand, a separate assignment can be obtained
   for the in-house operations of the operator.

5.6.  DB registration

   When an organization in reciept of an IPv6 address allocation makes
   IPv6 address assignments, it must register assignment information in
   a public database (initially a database maintained by an RIR/NIR,
   which may be replaced by a distributed database for registering
   address management information in future).  Information is registered
   in units of assigned /48 networks.  When an organization assigns an
   address space larger than a /48 to another organization, it must
   monitor if this organization has registered address utilization
   information in a public database.

This para talks about an organization (LIR) assigning an address space larger than a /48 to another organization.  In this case it implies that the other organization (NOT THE LIR) must register its /48's in a public database and that the LIR must ensure that the other organization has done this.  But section 3.3 implies that every allocation be an a public database, and section 5.4 implies that it is not.

   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.

   Each registry shall handle personal information with ultimate care.
   Concrete methods of protecting personal data shall be in accordance
   with privacy policies of each RIR/NIR (e.g., assign providers as
   tech-c or admin-c, divide an address in the middle, etc.).

5.7.  Reverse lookup

   When an RIR/NIR delegates IPv6 address space to an organization, it
   also delegates the right 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 assigned
   organization, upon request, the right to manage the reverse lookup
   zone that corresponds to the assigned address.

5.8.  Validity of allocations and assignments

   An allocation or assignment of address space is valid only so long as
   the original criteria on which the allocation or assignment was based
   continues to be valid.

   If an allocation or assignment is made for a specific purpose, but
   the original purpose or original justification no longer applies, the
   allocation or assignment shall become invalid.

   If an allocation or assignment is based on information that is found
   to be false or incomplete, the allocation or assignment shall become
   invalid.

   Invalid allocations shall be returned to the appropriate IR.

5.9.  Existing IPv6 address space holders

   Once the policies described in this document have been adopted, an
   organization already receiving an allocation according to the
   "PROVISIONAL IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT"
   [RIRv6-Polices] is immediately eligible to having its allocation
   expanded to a /32 address block. 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.  Special case

   Special considerations will be given to the cases described below,
   with no regard to the provision of this document. Individual RIRs are
   currently discussing policies for these cases independent of this
   document.

6.1.  IX (Internet Exchange)

   An IX is a point at which ISPs connect with one another.  It requires
   ISP-independent addresses.

7.  Acknowledgment

   The initial version of this document was produced by The JPNIC IPv6
   global 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, Kosuke Ito,
   Richard Jimmerson, David Kessens, Mirjam Kuehne, Anne Lord, Jun
   Murai, Paul Mylotte, Thomas Narten, Ray Plzak, Paul Wilson and
   Wilfried Woeber.

8.  References

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

   [RFC1771] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li.
           March
                1995, RFC 1771.

   [IAB-Request] "Email from IAB to IANA", [XXX need better reference].
           See IAB Minutes, Dec. 12, 1998, <ftp://ftp.iab.org/in>-
           notes/IAB/IABmins/IABmins.981208, <ftp://ftp.iab.org/in>-
           notes/IAB/IABmins/IABmins.990112.

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

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

   [RFC2460] "Internet Protocol, Version 6 (IPv6) Specification", S.
           Deering, R.  Hinden. December 1998, RFC 2460.

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

   [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/minutes/bot/bot08152001.html>, XXX
           fill in.

   [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>.

9.  Appendix A:

   In accordance with the recommendations of "The Host-Density Ratio for
   Address Assignment Efficiency: An update on the H ratio" [RFC 3194],
   it is proposed in this draft to adopt 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%
       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%

DRAFT                                                          [Page 20]