v6 message to IANA (fwd)

[bmanning@ISI.EDU]

This was sent to the ARIN members list. I've sent some comments
back to Kim which I'll forward to the list in a moment.

> 
> The following message was sent to the IANA on behalf of the Regional 
> Internet Registries.  Once we receive approval from IANA on the v6
> policy guidelines, below, we'll be ready to begin making allocations.
> 
> Kim
> 
> 
> 
> Joint Regional Internet Registry email to IANA
> 
> To: the Internet Assigned Numbers Authority
> 
> Subject: Initial IPv6 allocations
> 
> As you will be aware, APNIC, ARIN, and the RIPE NCC have for many months
> been working closely with their respective memberships and the IPv6
> community to produce a document setting out the policies and guidelines
> required for supporting responsible management of IPv6 address space. We
> now believe that the attached "Provisional IPv6 Assignment and Allocation
> Policy Document" is sufficiently advanced to allow the initial "bootstrap"
> phase of allocations to begin.
> 
> There is growing anticipation within the IPv6 community and the Internet
> community in general that IPv6 operations be established as soon as
> possible.  We therefore propose to commence allocating sub-TLAs following
> the general scheme described in the Internet Draft "Initial IPv6 Sub-TLA
> Assignments" <draft-ietf-ipngwg-iana-tla-o1.txt> and the more specific
> policies and guidelines set out in the attached policy document.  Although
> the document will be further developed and refined in the coming months -
> according to the input and experience gained during the initial period -
> the general community support for this document is strong enough to
> justify its implementation in its current form.
> 
> Accordingly, the Regional Internet Registries seek IANA's formal
> delegation of the address ranges specified in the Internet Draft and the
> approval to commence IPv6 allocations on the basis set out in this email.
> 
> On behalf and with the authority of:
> 
> Paul Wilson, Director-General             APNIC
> Kim Hubbard, President                     ARIN
> Daniel Karrenberg, General Manager     RIPE NCC
>  
> 
> 
> PROVISIONAL IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT
> 
> (28 May 1999)
> 
> Scheduled revision: Formal revision of this document is scheduled to be
> commenced by 1 October 1999.
> 
> TABLE OF CONTENTS
> 
> Abstract
> 
> 1. Scope
> 
> 2. IPv6 Address Space and the Internet Registry System
> 
> 2.1 The Internet Registry System Hierarchy
> 
> 2.2 Goals of the Internet Registry System
> 
> 3. IPv6 Technical Framework
> 
> 3.1 IPv6 Addressing Hierarchy
> 
> 3.2 Initial IPv6 Addressing Hierarchy
> 
> 4. Addressing Policies
> 
> 4.1 IPv6 Addresses Not to be Considered Property
> 
> 4.2 Allocations
> 
> 4.3 Assignments
> 
> 4.4 Reclamation Methods/Conditions
> 
> 5. Organizations Operating in More than One Region
> 
> 6. DNS and Reverse Address Mapping
> 
> 7. Glossary
> 
> 8. List of References
> 
> ABSTRACT
> 
> This document describes the registry system for distributing globally
> unique unicast IPv6 address space. IPv6 address space is distributed in a
> hierarchical manner (as is IPv4 address space), managed by the IANA and
> further delegated by the Regional Internet Registries (Regional IRs) as
> described in RFC 1881. In the case of IPv6, the Regional IRs allocate
> Top-Level Aggregation Identifiers (TLAs) to organizations, which, as TLA
> Registries, in turn allocate or assign address space to other Internet
> Service Providers (ISPs) and end users. ISPs then serve as Next Level
> Aggregation (NLA) Registries for their customers.
> 
> This document describes the responsibilities, policies, and procedures
> associated with IPv6 address space management, to be followed by all
> organizations within the allocation hierarchy. The intention of this
> document is to provide a framework for clear understanding and consistent
> application of those responsibilities, policies, and procedures throughout
> all layers of the hierarchy.
> 
> 1. SCOPE
> 
> This document first describes the global Internet Registry system for the
> distribution of IPv6 address space (as defined in RFC 2374) and the
> management of that address space. It then describes the policies and
> guidelines governing the distribution of IPv6 address space. The policies
> set forth in this document should be considered binding on all
> organizations that receive allocations or assignments of IPv6 address space
> either directly or indirectly from a Regional IR.
> 
> This document describes the primary operational policies and guidelines in
> use by all Regional IRs. Regional IRs may implement supplementary policies
> and guidelines to meet the specific needs of the Internet communities
> within their regions.
> 
> These policies and guidelines are subject to change based upon the
> development of operational experience and technological innovations, which
> together emerge as Internet best practice.
> 
> The structure of this document is as follows:
> 
> Section 2, "IPv6 Address Space and the Internet Registry System", describes
> the hierarchical structure of responsible organizations within the Internet
> Registry system and the explicit goals that determine the framework of
> policies for allocation and assignment of IPv6 address space.
> 
> Section 3, "IPv6 Technical Framework", explains the IPv6 addressing format
> and describes the differences between TLA, NLA, and SLA blocks.
> 
> Section 4, "Addressing Policies", describes the requirements for applying
> for a TLA allocation and the policies that apply to such allocations. It
> discusses how TLA registries can allocate space to other ISPs (NLA blocks)
> and assign address space to end-users (SLAs).
> 
> Section 5, "Organizations Operating in More than One Region", describes the
> requirements for organizations operating in more than one IR region
> requesting address space.
> 
> Section 6, "DNS and Reverse Address Mapping", describes the role of the
> Regional IRs in providing reverse delegation and explains how the Regional
> IRs can manage subsidiary reverse delegation of allocated/assigned address
> space.
> 
> Section 7, "Glossary", provides a listing of terms used in this document
> along with their definitions.
> 
> Section 8, "List of References", provides a list of documents referenced in
> this document.
> 
> 2 IPv6 ADDRESS SPACE AND THE INTERNET REGISTRY SYSTEM
> 
> IPv6 unicast addresses are aggregatable with contiguous bit-wise masks used
> to define routable prefixes, using a method similar to that used for IPv4
> addresses under CIDR. With IPv6, scarcity of address space is assumed to no
> longer exist for the end-user. However, inefficient assignments of address
> space and rapid expansion of routing tables remain as serious potential
> impediments to the scalability of the Internet. The Internet Registry
> system exists to ensure that IPv6 address space is managed in a globally
> consistent, fair, and responsible manner that minimizes wastage, and
> maximizes aggregation within the routing structure.
> 
> 2.1 The Internet Registry System Hierarchy
> 
> The hierarchical Internet Registry system exists to enable the goals
> described in this document to be met. In the case of IPv6, this hierarchy
> consists of the following levels, as seen from the top down: IANA, Regional
> Internet Registries, TLA, NLA Registries, and end-sites.
> 
> 2.1.1 IANA
> 
> The Internet Assigned Numbers Authority (IANA) has authority over all IP
> number spaces used in the Internet, including IPv6 address space. IANA
> allocates parts of the IPv6 address space to Regional Internet Registries
> (Regional IRs) according to their established needs.
> 
> 2.1.2 Regional Internet Registries
> 
> Regional IRs operate in large geographical regions such as continents.
> Currently, three Regional IRs exist: ARIN serving North and South America,
> the Caribbean, and sub-Saharan Africa; RIPE NCC serving Europe, the Middle
> East, and parts of Africa; and APNIC serving the Asia Pacific region. These
> Regional IRs also serve areas beyond their core service areas to ensure
> that all parts of the globe are covered. Additional Regional IRs may be
> established in the future, although their number will remain relatively
> low. Service areas will be of continental dimensions.
> 
> Regional IRs are established under the authority of the IANA. This requires
> consensus within the Internet community and among the ISPs of the
> respective region.
> 
> 2.1.3 TLA Registries
> 
> TLA Registries are established under the authority of the appropriate
> Regional IR to enable "custodianship" of a TLA or sub-TLA block of IPv6
> addresses. TLA Registries perform roles and bear responsibilities which are
> analogous and consistent with those of the Regional IR within their
> designated network services and infrastructures.
> 
> 2.1.4 NLA Registries
> 
> [to be written]
> 
> 2.1.5 End-sites [to be written]
> 
> 2.2 Goals of the Internet Registry System
> 
> The goals described in this section have been formulated by the Internet
> community with specific reference to IPv6 address space. They reflect the
> mutual interest of all members of that community in ensuring that the
> Internet is able to function and grow to the maximum extent possible. It is
> the responsibility of every IR to ensure that all assignments and
> allocations of IPv6 address space are consistent with these goals.
> 
> These goals will occasionally be in conflict with the interests of
> individual ISPs or end-users. Therefore, IRs evaluating requests for
> allocations and assignments must carefully analyze all relevant
> considerations and must seek to balance the needs of individual applicants
> with the needs of the Internet community as a whole. The policies and
> guidelines 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.
> 
> 2.2.1 Uniqueness
> 
> Each IPv6 unicast address must be globally unique. This is an absolute
> requirement for guaranteeing that every host on the Internet can be
> uniquely identified.
> 
> 2.2.2 Aggregation
> 
> IPv6 addresses must be distributed in a hierarchical manner, permitting the
> aggregation of routing information and limiting the number of routing
> entries advertised into the Internet. This is necessary to ensure proper
> operation of Internet routing and to maximize the routing system's ability
> to meet the demands of both likely and unforeseeable future increases in
> both size and topological complexity. In IPv6, aggregation of external
> routes is the primary goal.
> 
> This goal is motivated by the problems which arose in IPv4 network
> addressing. IPv4 address allocations have not been sufficiently
> hierarchical to ensure efficient routing across the Internet. Inefficient
> use of classful allocations led to an excess of routing entries appearing
> in the default-free routing table. Furthermore, increased complexity of
> network topologies led to IPv4 prefixes being announced many times via
> different routes.
> 
> Responsible policies and guidelines must limit the number of top level
> prefixes that are announced on the Internet so as to ensure that the
> problems of IPv4 are not repeated in IPv6. Such policies and guidelines
> will always reflect the constraints of current router technology and will
> be subject to reevaluation as that technology advances. Furthermore, such
> policies and guidelines will be reviewed according to a model consistent
> with that provided in RFC 2374 and RFC 2450. Under this model, a threshold
> is set significantly below the number of default-free routing table entries
> considered to be currently supportable. If the number of entries reaches
> that threshold, then allocation criteria are to be reviewed (see section
> 4.4).
> 
> 2.2.3 Efficient Address Usage
> 
> Although IPv6 address resources are abundant, the global Internet community
> must be careful to avoid repeating the problems that arose in relation to
> IPv4 addresses. Specifically, even though "conservation" of IPv6 addresses
> is not a significant concern, registries must implement policies and
> guidelines that prevent organizations from stockpiling addresses. IPv6
> addressing architecture allows considerable flexibility for end-users;
> however, all registries must avoid wasteful use of TLA and NLA address
> space by ensuring that allocations and assignments are made efficiently and
> based on demonstrated need.
> 
> 2.2.4 Registration
> 
> Every assignment and allocation of IPv6 Internet address space must be
> registered in a publicly accessible database. This is necessary to ensure
> uniqueness and to provide information for Internet trouble shooting at all
> levels. It also reflects the expectation of the Internet community that all
> custodians of public resources, such as public address space, should be
> identifiable. As is the case with IPv4 addresses, each of the Regional IRs
> will maintain a public database where all IPv6 allocations and assignments
> are entered.
> 
> 3. IPv6 TECHNICAL FRAMEWORK
> 
> 3.1 IPv6 Addressing Hierarchy
> 
> RFC 2374 specifies that aggregatable addresses are organized into a
> topological hierarchy, consisting of a public topology, a site topology,
> and interface identifiers. These in turn map to the following:
> 
> | 3|  13 | 8 |   24   |   16   |    64 bits                 |
> +--+-----+---+--------+--------+----------------------------+
> |FP| TLA |RES|   NLA  |  SLA   |   Interface ID             |
> |  | ID  |   |   ID   |  ID    |                            |
> +--+-----+---+--------+--------+----------------------------+
> |-- public topology---|  site  |     Interface              |
> |                     |topology|                            |
> +---------------------+--------+----------------------------+
> |                              |                            |
> |-------- network portion----->+<-----host portion----------|
> |                             /64                           |
> |-----------------------------------------------------------|
> 
> The public routing topology is represented by a /48, giving each site 16
> bits to create their local topology. The host portion is represented by the
> last 64 bits of the address.
> 
> Because all interface IDs are required to be in the EUI-64 format (as
> specified in RFC 2373 and RFC 2374) the boundary between the network and
> host portions is "hard" and ID address space cannot be further sub-divided.
> 
> Also, in order to facilitate multihoming and renumbering, the boundary
> between the public topology and the site topology division at the /48 is
> also hard. (RFC 2374 explains this more completely.)
> 
> 3.2 Initial IPv6 Addressing Hierarchy
> 
> A modified version of the addressing hierarchy described in section 3.1
> will be used for the initial IPv6 allocations. The first TLA prefix (TLA
> 0x0001) has been divided into further blocks, called "sub-TLAs", with a
> 13-bit sub-TLA identifier. Part of the reserved space and the NLA space
> have been used for this purpose.
> 
> This modified addressing hierarchy has the following format and prefix
> boundaries:
> 
> Format boundaries
> 
> | 3|    13    |    13   | 6 |   13   |   16   |     64 bits        |
> +--+----------+---------+---+--------+--------+--------------------+
> |FP|   TLA    | sub-TLA |Res|   NLA  |  SLA   |    Interface ID    |
> |  |    ID    |         |   |    ID  |   ID   |                    |
> +--+----------+---------+---+--------+--------+--------------------+
> 
> Prefix boundaries (starting at bit 0)
> 
>             number of the   number of the           ID
>             left-most       right-most       longest   length
>             bit             bit              prefix    (in bits)
>             ************    ************     *******   ********
> TLA ID       3                  15             /16        13
> sub-TLA ID   16                 28             /29        13
> Reserved     29                 34
> NLA ID       35                 47             /48        13
> SLA ID       48                 63             /64        16
> 
> For purposes of a "slow start" of a sub-TLA, the first allocation to a TLA
> Registry will be a /35 block (representing 13 bits of NLA space). The
> Regional IR making the allocation will reserve an additional six bits for
> the allocated sub-TLA. When the TLA Registry has fully used the first /35
> block, the Regional IR will use the reserved space to make subsequent
> allocations (see section 4.2.5).
> 
> All router interfaces are required to have at least one link-local unicast
> address or site-local address. It is recommended that site-local addresses
> be used for all point-to-point links, loopback addresses, and so forth. As
> these are not required to be visible outside the site's network, they do
> not require public address space. Any global unicast address space assigned
> must not be used for link-local or site-local purposes as there is address
> space reserved for these purposes. (Note that "all 1s" and "all 0s" are
> valid unless specifically excluded through reservation. See list of
> reserved addresses in RFC 2373.)
> 
> 4. ADDRESSING POLICIES
> 
> As described above, Regional IRs make IPv6 allocations to requesting
> organizations that qualify for a sub-TLA (TLA Registries). TLA Registries
> then allocate NLA space to ISPs that are their customers (NLA Registries).
> NLA Registries in turn assign SLA space to end-users. TLA Registries may
> also assign SLA space directly to end-users. TLA Registries and NLA
> Registries also use SLA space to address their own networks. This
> hierarchical structure of allocations and assignments is designed to
> maximize the aggregation of routing information.
> 
> 4.1 IPv6 Addresses not to be considered property
> 
> All allocations and assignments of IPv6 address space are made on the basis
> that the holder of the address space is not to be considered the "owner" of
> the address space, and that all such allocations and assignments always
> remain subject to the current policies and guidelines described in this
> document. Holders of address space may potentially be required, at some
> time in the future, to return their address space and renumber their
> networks in accordance with the consensus of the Internet community in
> ensuring that the goals of aggregation and efficiency continue to be met.
> 
> 4.1.1 Terms of allocations and assignments to be specified
> 
> At the time of making any allocation or assignment of IPv6 address space,
> Registries should specify the terms upon which the address space is to be
> held and the procedures for reviewing those terms in the future. Such terms
> and procedures should be consistent with the policies and guidelines
> described in this document.
> 
> 4.2 Allocations
> 
> In order to meet the goal of aggregation (section 2.2.2) Regional IRs will
> only allocate sub-TLA address space to organizations that meet the criteria
> specified in one or more of the following sections: 4.2.1 "General Criteria
> for Initial Sub-TLA Allocation" and 4.2.2 "Criteria for sub-TLA Allocations
> in Transitional 'Bootstrap' Phase".
> 
> The criteria for an initial allocation to an organization are different
> from the criteria that apply for subsequent allocations. Whereas the
> requirements for an initial allocation are based on technical
> considerations, requests for additional address space are evaluated solely
> on the basis of the usage rate of the initial allocation.
> 
> The following criteria for sub-TLA allocations reflect the intentions of
> the authors of the IPv6 addressing architecture (see RFC 2374, RFC 2373,
> and RFC 2950), namely that addressing policies must promote the goal of
> aggregation. The basis of these criteria is that it is primarily the
> organizations acting as transit providers or exchange points that will be
> involved in the top-level routing hierarchy and that other Service
> Providers should receive NLA address space from these organizations.
> 
> 4.2.1 General Criteria for Initial Sub-TLA Allocation
> 
> Subject to sections 4.2.2, and 4.2.3, Regional IRs will only make an
> initial allocation of sub-TLA address space to organizations that meet
> criterion (a) AND at least one part of criterion (b), as follows:
> 
> a. The requesting organization's IPv6 network must have exterior routing
> protocol peering relationships with the IPv6 networks of at least three
> other organizations that have a sub-TLA allocated to them.
> 
> AND either
> 
> b(i). The requesting organization must have reassigned IPv6 addresses
> received from its upstream provider or providers to 40 SLA customer sites
> with routed networks connected by permanent or semi-permanent links.
> 
> OR
> 
> b(ii). The requesting organization must demonstrate a clear intent to
> provide IPv6 service within 12 months after receiving allocated address
> space. This must be substantiated by such documents as an engineering plan
> or deployment plan.
> 
> 4.2.2 Criteria for sub-TLA Allocations in Transitional "Bootstrap" Phase
> 
> By requiring exterior routing protocol peering relationships with at least
> three other IPv6 networks, section 4.2.1 creates a problem during the
> initial period of transition to IPv6 network addressing, namely that too
> few organizations will meet the general criteria during this phase
> (referred to as the "bootstrap phase"). The criteria in this section
> provide an interim mechanism for eligibility that will only apply during
> the bootstrap phase, that is until the number of organizations operating
> IPv6 networks is considered sufficient for the general criteria to operate.
> (See section 4.2.2.1 "Duration of Bootstrap Phase".)
> 
> Notwithstanding section 4.2.1, during the bootstrap phase, Regional IRs
> will make an initial allocation of sub-TLA address space to organizations
> that meet criterion (a) AND criterion (b) AND either criterion (c) OR
> criterion (d).
> 
> a. The requesting organization's network must have exterior routing
> protocol peering relationships with at least three other public Autonomous
> Systems in the default-free zone.
> 
> AND
> 
> b. The requesting organization must show that it plans to provide
> production IPv6 service within 12 months after receiving allocated address
> space. This must be substantiated by such documents as an engineering plan
> or a deployment plan.
> 
> AND either
> 
> c. The requesting organization must be an IPv4 transit provider and must
> show that it already has issued IPv4 address space to 40 customer sites
> that can meet the criteria for a /48 IPv6 assignment. In this case, the
> organization must have an up-to-date routing policy registered in one of
> the databases of the Internet Routing Registry, which the Regional IR may
> verify by checking the routing table information on one of the public
> looking glass sites).
> 
> OR d. The requesting organization must demonstrate that it has experience
> with IPv6 through active participation in the 6bone project for at least
> six months, during which time it operated a pseudo-TLA (pTLA) for at least
> three months. The Regional IRs may require documentation of acceptable
> 6Bone routing policies and practice from the requesting organization.
> 
> 4.2.2.1 Duration of Bootstrap Phase
> 
> The eligibility criteria in this section will only apply until 100
> requesting organizations have received allocations of sub-TLA address
> space, provided that no more than 60 of these organizations are located in
> one Regional IR's region. After this threshold has been reached, the
> bootstrap phase will be considered to be over and Regional IRs will only
> make allocations to organizations that meet the general criteria in section
> 4.2.1.
> 
> If 60 organizations have been allocated sub-TLAs within one region (but
> less than 100 have been allocated worldwide) then the bootstrap phase
> within that region will be considered to be over. Additional applications
> from that region must satisfy the general criteria in section 4.2.1, while
> applications from other regions need only satisfy the bootstrap criteria.
> 
> When 100 sub-TLA registries are formed worldwide, there will be enough
> choices for new prospective sub-TLAs to find others to connect to and the
> bootstrap phase can end. The regional limitation on bootstrapping is
> intended to prevent one region consuming all available bootstrap
> opportunities before IPv6 deployment has started in other regions.
> 
> 4.2.3 Special considerations
> 
> 4.2.3.1 Exchange Points
> 
> It is expected that some exchange points will play a new role in IPv6, by
> acting as a sub-TLA registry for ISPs that connect to the exchange point.
> Because there is little information available about such exchange points
> and how they will operate, they have not been considered during development
> of sub-TLA eligibility criteria. As these exchange points are established,
> the Regional IRs will evaluate whether special criteria are required. It is
> expected that the Regional IRs will request from the exchange point
> information about the nature of the contracts they enter with the ISPs
> seeking IPv6 service.
> 
> 4.2.3.2 Multihomed Sites
> 
> [to be written]
> 
> 4.2.4 Size for Initial Allocation: "Slow-Start" Mechanism
> 
> Regional IRs will adopt a "slow start" mechanism when making initial
> allocations of sub-TLA space to eligible organizations. By this mechanism,
> the initial allocation will allow 13 bits worth of NLA IDs to be used by
> the organization unless the requesting organization submits documentation
> to the Regional IR to justify an exception based on topological grounds.
> This initial allocation allows the organization to create a hierarchy
> within the allocation depending on their customer type (ISP or end-site)
> and the topology of their own network. For example, an organization may
> receive 8,192 SLAs (a /48 each). (See section 4.3 for policies relating to
> assignments.)
> 
> The slow-start mechanism for sub-TLA allocations is important to the
> development of IPv6 addressing hierarchies for several reasons. One
> significant reason is that it allows the Regional IRs to set relatively low
> entrance criteria for organizations seeking a sub-TLA allocation. This
> makes the process fair to all organizations requesting sub-TLA space by
> giving everybody the same (relatively small) amount and basing future
> allocations on track record. Furthermore, the effect of this process will
> be to create a range of different prefix lengths which, in the event that
> routing table growth requires it, will allow the ISP industry to make
> rational decisions about which routes to filter.
> 
> Another important reason for adopting the slow-start mechanism is to allow
> Regional IRs to maintain contact with TLA Registries as they develop,
> thereby providing a level of support and training that will help ensure
> that policies and practices are implemented consistently. Without a slow
> start mechanism, TLA Registries receiving large initial allocations may not
> have formal contact with the Regional IR for several years. The slow-start
> mechanism helps Regional IRs to meet the goals of registration and
> efficiency, by providing a process that enables them to monitor whether the
> TLA Registries are properly registering assignments in the database and
> correctly applying the policies for NLA and SLA assignments contained in
> this document.
> 
> 4.2.5 Criteria for Subsequent Sub-TLA Allocations
> 
> Regional IRs will not make subsequent allocations of sub-TLA address space
> to a TLA Registry unless the TLA Registry has used at least 80 percent of
> its previously allocated address space. In this context, address space is
> considered to be "used" if the TLA Registry has made all of its allocations
> and assignments of that address space to its own infrastructure or customer
> needs in accordance with the policies and guidelines specified in this
> document.
> 
> The size of subsequent allocations depend on the demonstrated usage rate of
> the previous allocations.
> 
> 4.2.5.1 Contiguous allocations
> 
> The subsequent allocation will be contiguous with the previously allocated
> range to allow for aggregation of routing information. When a Regional IR
> makes an initial allocation to TLA Registry, it will reserve the full
> sub-TLA from which this allocation was made. Subsequent allocations to that
> TLA Registry will be made from the reserved sub-TLA. If no further growth
> is possible within that sub-TLA range, the Regional IR may allocate a full
> TLA. (Note, this practice may eventually lead to a situation in which no
> empty sub-TLAs are available, but the existing sub-TLAs are not fully
> utilised. If this occurs, then the provisions of section 4.4 will apply.)
> 
> 4.2.6 Registering and Verifying Usage
> 
> Each TLA Registry is responsible for the usage of the sub-TLA address space
> it receives and must register all end-site assignments and ISP allocations
> in the database of the Regional IR in its region. The Regional IR may
> verify whether all assignments are registered in the database. In addition
> to the database entries, the Regional IR may ask for periodic reports
> specifying how the addresses are being used.
> 
> Registered end-sites must be connected and reachable. To verify this, the
> relevant Regional IR is entitled to ping /48s within end-sites. Filtering
> holes should be negotiated by the Regional IR and the organization holding
> the addresses in question. Therefore, it is suggested that end-sites use
> anycast cluster addresses on their border routers to enable this. It is
> expected that one /48 SLA block is enough address space per end-site. If an
> end-site requests an additional SLA, the TLA Registry must send the request
> to the Regional IR for a second opinion.
> 
> 4.2.7 Renumbering
> 
> It is possible that circumstances could arise whereby sub-TLA address space
> becomes scarce. This could occur, for example, due to inefficient use of
> assigned address space, or to an increase in the number of organizations
> holding both TLA and sub-TLA space.
> 
> If such circumstances arise, it may be necessary for Regional IRs to
> require that previously allocated address space be renumbered into
> different ranges.
> 
> If a Regional IR requires a TLA Registry to renumber its own network, this
> will also have an impact on all of its customers' networks. Therefore, it
> is recommended that TLA Registries and NLA Registries enter contractual
> arrangements with their customers at the time of the first allocation or
> assignment. Such arrangements should clarify that the address space might
> have to be returned, requiring all end-sites to be renumbered. If
> renumbering is required, then TLA Registries should inform their customers
> as soon as possible.
> 
> Regional IRs requiring a TLA Registry to renumber will allow that Registry
> at least 12 months to return the sub-TLA space. [Note that the granted
> renumbering time may depend on the prefix length returned. The draft
> document
> <http://search.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-08.txt>
> describes the issues involved in and methods used for renumbering IPv6
> networks.]
> 
> [Note that site-local addresses are not affected by renumbering the global
> unicast IPv6 addresses.]
> 
> 4.2.8 Allocations to NLA Registries
> 
> TLA Registries with ISP customers may use their 13 bits of NLA address
> space to create an addressing hierarchy for those ISPs. Each of the TLA
> Registry's own end-user organizations would receive a /48 (see section
> 4.3); however, the ISP customers (NLA Registries) could be "allocated"
> additional bits in order to aggregate the ISP's customers internally. A
> slow-start mechanism will be used for these NLA allocations.
> 
> The NLA block is an allocation to the NLA Registry and not an assignment.
> If the NLA Registry does not sufficiently use it within a reasonable time,
> the TLA Registry may require it to be returned. Definitions of 'sufficient
> use' and 'reasonable time' will be provided in a future version of this
> policy document. These definitions will be influenced by IPv6 operational
> experience and determined by the Regional IR's with the consensus of the
> Internet registry and engineering communities.
> 
> Once an NLA Registry has assigned at least 80 percent of its allocation, it
> may request an additional block from the TLA Registry. This block can be
> any size, depending on the NLA Registry's usage rate for its first block. A
> TLA Registry receiving a request for subsequent NLA allocations must submit
> the request to the relevant Regional IR for a second opinion.
> 
> Each NLA allocation must be registered in the Regional IR's database. All
> end-user assignments must also be registered in the Regional IR's database.
> The same procedures for these end-user assignments apply for the end-user
> assignments made by the TLA Registry to their customers directly.
> Ultimately, the TLA Registry is responsible for management of all address
> space it allocates and should, therefore, appropriately monitor all
> assignments made by the NLA Registries to which it allocates. The Regional
> IR can at any time ask for additional information about the allocations and
> assignments being made.
> 
> 4.3 Assignments
> 
> 4.3.1 Assignments to End-users
> 
> The minimum assignment to end-user organizations that have a need to create
> subnets in their network is a /48 (80 bits of address space). Within this
> /48, 16 bits are an SLA block used for subnetting and further 64 bits are
> used per interface.
> 
> TLA Registries must submit all requests they receive for additional
> assignments to the relevant Regional IR for evaluation (a "second
> opinion"). All such requests must document the full use of the initial SLA
> and must be accompanied by an engineering plan justifying the need for
> additional address space.
> 
> Dial-up lines are considered part of an ISP's infrastructure and,
> therefore, addresses for such purposes should be assigned from the SLA
> block of that ISP. It is expected that longer prefixes be used for
> non-permanent, single-user connections.
> 
> 4.4 Reclamation Methods/Conditions
> 
> Allocations are valid only as long as the organizations holding the address
> space continue to meet the criteria for allocations set out in sections
> 4.2.1, 4.2.2, and other criteria which may be specified subject to the
> provisions of this section. Consistent with the goal of aggregation
> described in section 2.2.2, the criteria for allocations may be reviewed
> with regard to current routing technology. The current threshold point for
> reviewing the allocation criteria is 4096 default-free entries in the
> global routing table.
> 
> If this threshold is reached and current routing technology then allows
> additional route entries, the number of possible TLAs and sub-TLAs may be
> increased accordingly.
> 
> However, if the limit is reached and routing technology at that time is not
> able to support additional routing entries, Regional IRs will review all
> allocations made up to that point. In the course of this review, the
> Regional IRs may seek consensus of the Internet registry and engineering
> communities to set minimum acceptable usage rates or new criteria
> determining eligibility to hold sub-TLA space. Dependent upon such a
> consensus, the Regional IRs may revoke the sub-TLA allocations of any
> Registry not complying with those rates or criteria. Such Registries will
> be required by the relevant Regional IR to renumber their networks and
> return their previous allocation within a reasonable time.
> 
> During the period that routing technology is being investigated, the
> Regional IRs will continue allocating address space even if the number of
> "possible" routes are reached.
> 
> 5. ORGANIZATIONS OPERATING IN MORE THAN ONE REGION
> 
> Organizations requesting sub-TLA space that operate in more than one
> region, and that need separate sub-TLA blocks for routing purposes, may
> request the address space from more than one of the Regional IRs, provided
> that the organization's networks meet the criteria for allocation of
> sub-TLA address space in each of the relevant regions.
> 
> 6. DNS AND REVERSE ADDRESS MAPPING
> 
> [To be written..]
> 
> 7. GLOSSARY
> 
> Allocation - The provision of IP address space to ISPs that reassign their
> address space to customers.
> 
> Assignment - The provision of IP address space to end-user organizations.
> 
> Default-free zone - The default-free zone is made up of Internet routers
> which have explicit routing information about the rest of the Internet and,
> therefore, do not need to use a default route.
> 
> End-user - An organization receiving reassignments of IPv6 addresses
> exclusively for use in operational networks.
> 
> Exterior routing protocol peering relationships - Routing relationships in
> which the organisations receive the full Internet routing table separately
> from neighbouring Autonomous Systems and are, therefore, able to use that
> routing table to make informed decisions about where to send IP packets.
> 
> Interface Identifiers - A 64-bit IPv6 unicast address identifier that
> identifies an interface on a link.
> 
> NLA ID - Next-Level Aggregation Identifier.
> 
> NLA Registry - Internet Service Providers receiving IPv6 address
> allocations from a TLA Registry.
> 
> Public Topology - The collection of providers and exchanges who provide
> public Internet transit service.
> 
> Regional Internet Registries - Organizations operating in large
> geographical regions such as continents which are responsible for fair
> distribution of globally unique Internet address space and for documenting
> address space allocation and assignment.
> 
> Site - A location, physical or virtual, with a network backbone connecting
> various network equipment and systems together. There is no limit to the
> physical size or scope of a site.
> 
> Site Topology - A local, specific site or organization which does not
> provide public transit service to nodes outside the site.
> 
> SLA ID - Site-Level Aggregation Identifier.
> 
> Slow Start - The efficient means by which addresses are allocated to TLA
> Registries and to NLA ISPs. This method involves issuing small address
> blocks until the provider can show an immediate requirement for larger
> blocks.
> 
> TLA ID - Top-Level Aggregation Identifier.
> 
> TLA Registry - Organizations receiving TLA/sub-TLA ID from Regional IRs to
> reassign to customers.
> 
> Unicast - An identifier for a single interface. A packet sent to a unicast
> address is delivered to the interface identified by that address. Note that
> the definition of an IPv4 host is different from an IPv6 identifier. One
> physical host may have many interfaces, and therefore many IPv6
> identifiers.
> 
> 8. LIST OF REFERENCES
> 
> ------ =_NextPart_000_01BEA929.E5CD8FC0--
> 
> 
> 
> 


-- 
"When in doubt, Twirl..."  -anon