____________________________________________________ IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC Document ID: ripe-196 Date Published: July 20, 1999 Scheduled revision: Formal revision of this document is scheduled to be commenced by 1 October 1999. 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 IPv6 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 responsibili- ties, 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 ____________________________________________________ ripe-196.txt Page 1 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ document should be considered binding on all organi- zations 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. 1.1. The structure of this document is as follows: Section 2, "IPv6 Address Space and the Internet Reg- istry System", describes the hierarchical structure of responsible organizations within the Internet Registry system and the explicit goals that deter- mine 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 dis- cusses 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 organiza- tions operating in more than one IR region request- ing 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 allo- cated/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. ____________________________________________________ ripe-196.txt Page 2 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ 2. IPv6 Address Space and the Internet Registry System IPv6 unicast addresses are aggregatable with con- tiguous bit-wise masks used to define routable pre- fixes, 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 Reg- istries, 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 allo- cates 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 ser- vice 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. ____________________________________________________ ripe-196.txt Page 3 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ Regional IRs are established under the authority of the IANA. This requires consensus within the Inter- net 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 "custodian- ship" of a TLA or sub-TLA block of IPv6 addresses. TLA Registries perform roles and bear responsibili- ties which are analogous and consistent with those of the Regional IR within their designated network services and infrastructures. 2.2. Goals of the Internet Registry System The goals described in this section have been formu- lated by the Internet community with specific refer- ence to IPv6 address space. They reflect the mutual interest of all members of that community in ensur- ing that the Internet is able to function and grow to the maximum extent possible. It is the responsi- bility 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. ____________________________________________________ ripe-196.txt Page 4 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ 2.2.2. Aggregation IPv6 addresses must be distributed in a hierarchical manner, permitting the aggregation of routing infor- mation 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 pri- mary 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 rout- ing table. Furthermore, increased complexity of net- work 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. Further- more, 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 "conserva- tion" of IPv6 addresses is not a significant con- cern, registries must implement policies and guide- lines that prevent organizations from stockpiling addresses. IPv6 addressing architecture allows con- siderable flexibility for end-users; however, all registries must avoid wasteful use of TLA and NLA address space by ensuring that allocations and ____________________________________________________ ripe-196.txt Page 5 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ assignments are made efficiently and based on demon- strated 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 cus- todians of public resources, such as public address space, should be identifiable. As is the case with IPv4 addresses, each of the Regional IRs will main- tain 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 por- tions is "hard" and ID address space cannot be fur- ther sub-divided. ____________________________________________________ ripe-196.txt Page 6 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ Also, in order to facilitate multihoming and renum- bering, 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 ini- tial 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-|Res|-NLA-|--SLA-|---Interface ID---| |--|-ID--|-TLA-|---|--ID-|--ID--|------------------| +--+-----+-----+---+-----+------+------------------+ Prefix boundaries (starting at bit 0) number of number of the left- the right- longest length ID most bit most bit prefix (in bits) ******* *********** ********** ******* ******** TLA 3 15 /16 13 sub-TLA 16 28 /29 13 Reserved 29 34 NLA 35 47 /48 13 SLA 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 ____________________________________________________ ripe-196.txt Page 7 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ 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 alloca- tions to requesting organizations that qualify for a sub-TLA (TLA Registries). TLA Registries then allo- cate 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 aggrega- tion 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 commu- nity 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 consis- tent with the policies and guidelines described in this document. ____________________________________________________ ripe-196.txt Page 8 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ 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 crite- ria specified in one or more of the following sec- tions: 4.2.1 "General Criteria for Initial Sub-TLA Allocation" and 4.2.2 "Criteria for sub-TLA Alloca- tions in Transitional 'Bootstrap' Phase". The criteria for an initial allocation to an organi- zation 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 2450), namely that addressing policies must pro- mote 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 fol- lows: a. The requesting organization's IPv6 network must have exterior routing protocol peering relationships with the IPv6 networks of at least three other orga- nizations that have a sub-TLA allocated to them. AND either b(i). The requesting organization must have reas- signed IPv6 addresses received from its upstream provider or providers to 40 SLA customer sites with routed networks connected by permanent or semi-per- manent links. OR ____________________________________________________ ripe-196.txt Page 9 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ 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 engi- neering plan or deployment plan. 4.2.2. Criteria for sub-TLA Allocations in Transitional "Boot- strap" Phase By requiring exterior routing protocol peering rela- tionships 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 gen- eral 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 engi- neering plan or a deployment plan. AND either c. The requesting organization must be an IPv4 tran- sit 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 ____________________________________________________ ripe-196.txt Page 10 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ 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 par- ticipation 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 rout- ing policies and practice from the requesting orga- nization. 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, pro- vided 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 gen- eral criteria in section 4.2.1. If 60 organizations have been allocated sub-TLAs within one region (but less than 100 have been allo- cated worldwide) then the bootstrap phase within that region will be considered to be over. Addi- tional applications from that region must satisfy the general criteria in section 4.2.1, while appli- cations 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 boot- strap phase can end. The regional limitation on bootstrapping is intended to prevent one region con- suming 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 ____________________________________________________ ripe-196.txt Page 11 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ 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 At the moment the issue of multihomed sites is still not resolved in the relevant working groups at the IETF and the Regional Registries will wait until this has been discussed further. 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 ini- tial 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 organi- zation 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 assign- ments.) 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 con- tact with TLA Registries as they develop, thereby providing a level of support and training that will ____________________________________________________ ripe-196.txt Page 12 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ help ensure that policies and practices are imple- mented 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 cor- rectly applying the policies for NLA and SLA assign- ments 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 assign- ments of that address space to its own infrastruc- ture or customer needs in accordance with the poli- cies 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 aggrega- tion 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 Reg- istry 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 situa- tion 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 reg- ister all end-site assignments and ISP allocations in the database of the Regional IR in its region. ____________________________________________________ ripe-196.txt Page 13 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ 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 peri- odic reports specifying how the addresses are being used. Registered end-sites must be connected and reach- able. 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 any- cast 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 describes the issues involved in and methods used for renumbering IPv6 ____________________________________________________ ripe-196.txt Page 14 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ 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 Reg- istries) 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. Defini- tions of 'sufficient use' and 'reasonable time' will be provided in a future version of this policy docu- ment. 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 per- cent 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 man- agement of all address space it allocates and should, therefore, appropriately monitor all assign- ments made by the NLA Registries to which it allo- cates. The Regional IR can at any time ask for addi- tional information about the allocations and assign- ments being made. ____________________________________________________ ripe-196.txt Page 15 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ 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 organiza- tions 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. Consis- tent with the goal of aggregation described in sec- tion 2.2.2, the criteria for allocations may be reviewed with regard to current routing technology. The current threshold point for reviewing the allo- cation 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 tech- nology at that time is not able to support addi- tional 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 ____________________________________________________ ripe-196.txt Page 16 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ 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 pre- vious allocation within a reasonable time. During the period that routing technology is being investigated, the Regional IRs will continue allo- cating address space even if the number of "possi- ble" routes are reached. 5. Organisations 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 6.1 Allocation and Reverse Address Mapping IANA will delegate to the Regional IRs responsibil- ity for the management of the reverse address map- ping of each of the address ranges allocated to them. For each IPv6 address block allocated by a Regional IR to a member or customer, the Regional IR must set up NS records in the appropriate sub-domain within the "ip6.int" domain. For example, where a /35 address block is allocated: An allocation of "3FFE:2100:2000::0/35" would require the following two zones to be delegated in the "0.0.1.2.e.f.f.3.ip6.int" zone file: $ORIGIN 0.0.1.2.e.f.f.3.ip6.int. 2 NS ns1.ispA.net. NS ns2.ispA.net. 3 NS ns1.ispA.net. NS ns2.ispA.net. ____________________________________________________ ripe-196.txt Page 17 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ Prior to allocating address space, the Regional IRs will notify the recipient of the address range they will receive. The recipient should configure reverse DNS servers for that address range and then inform the RIR of that configuration in order to complete the allocation process. Please see http://www.ripe.net/inaddr/ipv6.html for more information. 6.1. Assignments and Reverse Address Mapping All holders of a /35 allocation who make assignments from that allocation are required to set up reverse DNS for their customers. 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, there- fore, 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 ____________________________________________________ ripe-196.txt Page 18 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ service. Regional Internet Registries - Organizations operat- ing in large geographical regions such as continents which are responsible for fair distribution of glob- ally unique Internet address space and for docume- nting 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 phys- ical size or scope of a site. Site Topology - A local, specific site or organi- zation 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 bl- ocks until the provider can show an immediate requi- rement 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 interf- aces, and therefore many IPv6 identifiers. ____________________________________________________ ripe-196.txt Page 19 Provisional IPv6 Assignment and Allocation Policy Document APNIC, ARIN, RIPE NCC ____________________________________________________ 8. 8. LIST OF REFERENCES ____________________________________________________ ripe-196.txt Page 19