Hello all,

This is a draft version of the IPv6 assignment guidelines that we have been working on with the other Regional Registries. We would like your feedback on this at the RIPE meeting, and on this mailing list.

Please find my comments below, comments are marked with "Simon: <comment> :nomis"

The other Registries are now also discussing this with their communities.

Please note that when refering to the global adressing authority, we use the name IANA in this draft for now, but we will update this as soon as the ICANN developments progress.

Kind regards,

Paula Caslav RIPE NCC

Regards, Simon - --------------------begin included draft---------------------------- IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) 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 Allocations 4.2 Assignments 4.3 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 the distribution of globally unique IPv6 address space, which follows a hierarchical distribution as it does with IPv4. The distribution of IPv6 address space is managed by the IANA (formerly IANA) and further delegated by the Regional Internet Registries (IRs) as described in RFC 1881. The Regional IRs assign Top-Level Aggregation Identifiers (TLAs) to organizations, which in turn assign address space to other Internet Service Providers (ISPs) and end users. This document describes the policies and procedures associated with IPv6 address space management that must be followed by the organizations that hold Top-Level Aggregate IDs. Since ISPs essentially will be serving as NLA Registries for their customers, creating additional "layers" to the Registry system, it is crucial that responsibilities, procedures, and policies are well understood and consistently applied. 1. SCOPE This document first describes the global Internet Registry system for the distribution of globally unique unicast IPv6 address space, as defined in RFC 2374, and its operation, then describes the rules and guidelines governing the distribution of this address space. The rules set forth in this document are binding for all organizations that have IPv6 address space allocated and assigned via a Regional IR. This document does not describe private IPv6 address space, or anycast and multicast address space distribution. Simon: Why not write what this document does describe instead of writing wehat it does not do? This document describe aggregatable Global Unicast Address distribution. I really don't like the use of the term "private IPv6 address space", you do not find the term private address space used in any of the IPng working group documents. RFC2373 uses the term "local use addresses" to destingrise between aggregatable Global Unicast Addresses and {link/site}-local addresses. :nomis It also does not describe regional and local refinements of the global rules and guidelines. This document serves as the base set of operational guidelines in use by all Regional IRs. Additional guidelines may be imposed by a particular Regional IR as appropriate. As experience is gained in allocating IPv6 addresses, these rules and guidelines may change. The remaining sections of this document are presented as follows: Section 2, IPv6 Address Space and the Internet Registry System, explains the goals used in assigning IPv6 addresses and outlines the hierarchical structure of the responsible Internet Registry system organizations used to achieve those goals. Section 3, IPv6 Technical Framework, explains the IPv6 addressing format and outlines the difference between a TLA, NLA, and SLA block. 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 end-users (SLAs). Section 5, Organizations Operating in More than One Region, describes the process for requesting address space for organizations operating in more than one IR region. 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 similar to IPv4 addresses under CIDR. With IPv6, scarcity of address space is assumed to no longer exist for the end-user. However, routing table explosion and the efficient assignment of address space are still of great concern. Thus, aggregation and efficiency (conservation) of prefix allocations are explicit goals of the Internet registry system. 2.1 The Internet Registry System Hierarchy In order to achieve the goals of the Internet Registry system, a hierarchy was established which consists of the following levels as seen from the top down: IANA, Regional Internet Registries, and TLA Registries. 2.1.1 IANA The Internet Corporation for Assigned Names and Numbers (IANA) has authority over all number spaces used in the Internet, including IPv6 address space. IANA allocates parts of the IPv6 address space to Regional Internet Registries (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 are established: ARIN serving North and South America, the Caribbean, and sub-Saharan Africa; RIPE NCC serving Europe, the Middle East, and parts of Asia and Africa; and APNIC serving Asia and Pacific regions. These regional IRs also serve areas beyond their core service areas to ensure that all regions around the globe are covered. Additional Regional IRs may be established in the future, but it is expected that the number of Regional IRs will remain relatively small. Service areas will be of continental dimensions. Regional IRs are established under the authority of the IANA. This requires consensus within the Internet community of the region and may require consensus of ISPs in that region. 2.1.3 TLA Registries TLA Registries are established under the authority of the Regional IR. These Registries have the same roles and responsibilities as a Regional IR within their designated service areas. 2.2 Goals of the Internet Registry System The remainder of this document is primarily concerned with the management of public IPv6 address space. Every assignment of IPv6 addresses should be made with the following goals in mind for it is in the interest of the Internet community as a whole that these goals be pursued. It is worth noting that "conservation" and "aggregation" are often conflicting goals, and therefore each assignment must be evaluated carefully. Moreover, these goals may occasionally be in conflict with the interests of individual end users or ISPs. In such cases, careful analysis and judgement are necessary to find an appropriate compromise. The rules and guidelines in this document are intended to help Regional IRs, ISPs, and end-users in their search for effective solutions. 2.2.1 Uniqueness Each public IPv6 address worldwide must be unique. This is an absolute requirement which guarantees that every host on the Internet can be uniquely identified. 2.2.2 Aggregation Public IPv6 addresses are distributed in a hierarchical manner, permitting the aggregation of routing information. This is necessary to ensure proper operation of Internet routing. IPv4 addresses were not as hierarchical as needed for efficient routing across the Internet. Problems arose in IPv4 network addresses with classful allocations and inefficient use of them. This led to too many routing entries appearing in the default-free core of the Internet. To overcome this problem, the number of global routes must be limited according to technical restrictions. These technical constraints will have to be reevaluated as router technology changes. Until new paramaters are defined, however, the policies described in this document will remain valid. 2.2.3 Conservation Although IPv6 network address resources appear to be endless, care must be taken to avoid repetition of the IPv4 problems and instead focus on demonstrated need. These precautions will help manage and conserve IPv6 network addresses for future use. In order to mitigate this problem in use of IPv6, conservation is one of the main goals. It should be noted however, that the IPv6 addressing architecture allows end-sites a great amount of flexibility. Eighty bits out of a total of 128 bits available in an IPv6 address are used for addressing an end-site. Address space can be conserved only by carefully evaluating the requirements from TLAs and NLAs and allocating address space on the basis of demonstrated need. Experience has shown that the growth and the consequences of growth were never anticipated with IPv4. The Regional IRs will apply the lessons from the IPv4 experience to ensure that conservative policies are implemented from the beginning. 2.2.4 Registration In response to the rapid growth of Internet activity, a public registry system was established to document address space allocation and assignment. This was necessary to ensure uniqueness of Internet addresses and to provide information for Internet trouble-shooting at all levels. As with IPv4 addresses, each of the Regional IRs maintains a public database where all IPv6 assignments and reassignments are entered so that network operators can identify other network organizations. 3. IPv6 TECHNICAL FRAMEWORK 3.1 IPv6 Addressing Hierarchy RFC 2373 specifies that aggregatable addresses are organized into a topological hierarchy which consists of a public topology, a site topology, and interface identifiers. These in turn map into the following: Simon: No, this is in RFC2374. | 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 site topology is represented by a /48. Each site has a potential for 65,535 subnets as specified in RFC 2374. The network portion is represented by the first 64 bits. The host portion is represented by the last 64 bits of the address. A /64 is the minimum network prefix that can be assigned within a site. Additional subnets would require additional prefixes of the same size or shorter to be assigned. Note that the boundaries are "hard" between the network and host portions and that the ID address space cannot be further sub-divided as all interface ID's are required to be in the EUI-64 format as per RFC 2373/4. The boundaries are also hard between the public topology and the site topology division at the /48. The technical motivation for this is given in RFC 2374 in order to facilitate multi-homing. In IPv6, the following prefix boundaries are suggested: number of the number of the ID left-most right-most longest length bit boundary bit boundary prefix (in bits) ************ ************ ******* ******** TLA ID 4 16 /16 13 Reserved 17 24 N/A 8 NLA ID 25 48 /48 24 SLA ID 49 64 /64 16 3.2 Initial IPv6 Addressing Hierarchy A slightly modified version of the above (a special case of TLA 0x0001) derives a sub-TLA portion from principally the reserved address space. This has been described in RFC 2450. This has the following format and prefix boundaries: | 3| 13 | 13 | 19 | 16 | 64 bits | +--+----------+---------+---------+--------+--------------------+ |FP| TLA | sub-TLA | NLA | SLA | Interface ID | | | ID | | ID | ID | | +--+----------+---------+---------+--------+--------------------+ For this TLA, this means that there are the following prefix boundaries: number of the number of the ID left-most right-most longest length bit boundary bit boundary prefix (in bits) ************ ************ ******* ******** TLA ID 4 16 /16 13 sub-TLA ID 17 29 /29 13 NLA ID 30 48 /48 19 SLA ID 49 64 /64 16 For purposes of a slow start of a sub-TLA, however, a first sub-TLA allocation would actually always be a /35 block (13 bits instead of 19). All router interfaces are required to have at least one link-local unicast address or site-local address. Simon: It is not obvious how a router with only a site-local address could do anything useful, how do on-link routers/hosts communicate with the router? Routers are required to have a link-local address. :nomis Site-local will be used for all point-to-point links, loopback addresses, and so forth. Simon: Why should point-to-point links and loopback interfaces use site-local? Interfaces with only Site-local addresses assigned are useless. For point-to-point RFC 2461 (Neighbor Discovery) says: point-to-point - a link that connects exactly two interfaces. a point-to-point link is assumed to have multicast capability and have a link-local address. point-to-point - Neighbor Discovery handles such links just like multicast links. (Multicast can be trivially provided on point to point links, and interfaces can be assigned link-local addresses.) Neighbor Discovery should be implemented as described in this document. Loopback interfaces should use 0:0:0:0:0:0:0:1 (RFC2373), this address does not have a binary prefix of 1111 1110 11 and are not a site-local address. :nomis 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 the link-local or site-local purpose as there is reserved address space for these addresses. (Note that all 1's and all 0's are valid unless specifically excluded through reservation. See list of reserved addresses in RFC 2373.) 4. ADDRESSING POLICIES 4.1 Allocations Regional IRs make allocations to requesting organizations that qualify for a sub-TLA. Those organizations further allocate NLA space to ISP customers who in turn assign SLA space to end-sites. Sub-TLA holders can also assign SLA space directly to end-users, and sub-TLA and NLA holders will use SLA space to address their own networks. This hierarchical allocation structure allows aggregation of routing information. 4.1.1 Requirements for Allocating a Sub-TLA In order to meet the conservation and aggregation goals discussed above, only requesting organizations that meet certain requirements will be allocated sub-TLA space. The requirements for an initial allocation to an organization are different from the requirements that have to be met once the initial allocation has been used and additional address space is requested. Whereas the requirements for an initial allocation are based on technical considerations, all additional address space is purely based on the utilization of the initial allocation. In order to meet the aggregation goal, requests for an initial allocation of a sub-TLA have to be carefully evaluated. It is not necessary for every requesting organization to obtain sub-TLA space. The following requirements must be met in order to obtain an initial allocation of sub-TLA address space: The requesting organization's IPv6 network must be interconnected with the IPv6 networks of at least three other organizations that have a sub-TLA allocated to them, and either: -- The requesting organization must have reassigned IPv6 addresses received from its upstream provider or providers to 100 SLA customer sites with routed networks. Dial-in customers do not count toward the 100 IPv6 customer sites. Customers currently using IPv4 host addresses for dial-up should not be assigned an NLA or an SLA, or -- The requesting organization must demonstrate a clear intent to provide IPv6 service within 3 months after receiving allocated address space. This must be substantiated by such documents as an engineering plan or deployment plan. The above criterion that requires interconnection with at least three other sub-TLAs creates a bootstrapping problem which can be resolved by the following requirements that have been defined for a bootstrapping period: The requesting organization's network must have BGP peering relationships with at least three other public Autonomous Systems in default-free zones, The requesting organization must show that it already has issued IPv4 address space to 100 customer sites that can meet the criteria for a /48 IPv6 reassignment, and The requesting organization must demonstrate a clear intent to provide IPv6 service within 3 months after receiving allocated address space. This must be substantiated by such documents as an engineering plan or deployment plan. The first 50 requesting organizations who obtain a sub-TLA must fulfill either the criteria for the bootstrapping or the general criteria. Only 30 out of these 50 networks/organizations can be located in one region. After 50 sub-TLAs have been allocated, the bootstrap criteria will no longer apply. Once 30 organizations have been allocated sub-TLAs within one region, additional applications from that region must satisfy the general criteria, while applications from other regions may only have to satisfy the bootstrap criteria. This is because the first group of registries would not be able to fulfill the first criteria of being connected to three other sub-TLA networks, since there would be few sub-TLA networks at the start. After 50 sub-TLA registries are formed, there will be enough choices for new prospective sub-TLAs to find others to connect to and the bootstrapping phase can end. It has been decided to further limit the amount per region (an area covered by one Regional IR), so that one region will not have an unfair advantage over another. NOTE - Those who qualify for TLA or sub-TLA (whether during bootstrap or later) and who then fail to demonstrate ongoing utilization, will have their allocation revoked (defined further in section 4.3). 4.1.2 Size for Initial Allocation/Slow-Start Mechanism The initial allocation of sub-TLA space will allow 13 bits worth of NLA IDs to be utilized by the organization receiving the /35 reserved from the sub-TLA unless the requesting organization submits documentation to the Regional IR to justify an exception. 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: this allows the organization to receive 8,192 NLAs (a /48 each). The making of assignments (to ISPs or end-sites) is covered in section 4.2 in more detail. The size of the initial allocation has been set to 13 bits because this allows the TLA Registry some freedom in creating an addressing hierarchy. If it has other Service Providers as customers (who in turn have their own end-user customers), this allows the TLA Registry to sub-allocate smaller blocks to each of them. 4.1.3 Requirements for Next Allocation Once an organization has used 80% of the sub-TLA address space, the organization may contact the Regional IR in its region to request that another range of addresses be allocated. The size of the next range depends on the utilization rate of the previous allocation. It must be stressed that it is not enough to have allocated 80% of the sub-TLA address space. The addresses must also be assigned and in use by end-sites. This means that sub-TLA holders must be careful and conservative in their allocations to their ISP customers. Address space must be allocated and assigned based on actual need. Administrative convenience or internal routing table size can not be a reason to allocate or assign additional address space. It is expected that sub-TLA holders also apply a slow-start mechanism as described in section 4.2.2 to their ISP customers. The next allocation may be another range of sub-TLA space with a shorter prefix than the previous one. If growth is no longer possible in the sub-TLA space, it is expected that a full TLA will be allocated. In order to justify a new range of sub-TLA or TLA space, the utilization of the previous allocation must be demonstrated. This is described below. 4.1.3.1 Verification of Utilization All assignments to end-sites must be registered in the database of the Regional IR in the region the sub-TLA holder operates. The TLA Registry is responsible for the utilization of the sub-TLA and the registration of the end-site assignments and ISP allocations in the database. The Regional IR will verify whether all assignments are registered in the database. In addition to the database entries, the Regional IR may ask for periodic reports describing the utilization of the addresses to be sent. It is required that the end-sites be connected and reachable. The Regional IR has the right to ping end-sites' /48s. Filtering holes should be negotiated by the Regional IR and the organization with the addresses. 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 sub-TLA holder must send the request to the Regional IR for a second opinion. The information provided below shows address boundaries and their corresponding amount of address space. a TLA = /16 of address space an NLA = /48 of address space an SLA = /64 of address space TLA block = 13 bits of address space NLA block = 19 bits of address space SLA block = 16 bits of address space 4.1.3.2 Renumbering Once it has been decided to allocate additional TLA space to a sub-TLA holder, the previously allocated sub-TLA must be returned to the Regional IR. The sub-TLA holder must then renumber its own network. This of course has an impact on all of its customers and customers' networks. Therefore, it is recommended that the sub-TLA holder and its ISP customers make contractual arrangements with their customers at the time of the first assignment. These arrangements should clarify that the address space will have to be returned in the event the sub-TLA holder requests a full TLA, in which case, all end-sites must be renumbered. The sub-TLA holder should inform its customers early on regarding the upcoming need to renumber. The sub-TLA will have 3 months to return the sub-TLA space after the next TLA has been allocated. Renumbering in IPv6 is considerably easier than in IPv4. Once the provider has informed its customer about the address range to be used in the future, the customer's network (end-site) will have two sets of addresses for a certain period of time. Hosts learn prefixes from router advertisements. With each prefix, there is a "valid lifetime" and a "preferred lifetime" designation. New sessions should be initiated with the preferred address, but existing ones can continue with the old (valid but not preferred) address. A mechanism called Router Renumbering (RR) allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used and advertised by IPv6 routers throughout a site. (M. Crawford, work in progress) Note that site-local addresses are not affected by renumbering the global unicast IPv6 addresses. 4.2 Assignments 4.2.1 Assignments to End-users Every end-user organization receives a /48 worth of address space (80 bits). Out of this, 16 bits are an SLA block used for subnetting and another 64 bits are used per interface. All requests for additional address space from the same TLA Registry must be submitted to the Regional IR for evaluation (a second opinion). In this case the full utilization of the initial SLA must be documented. The need for additional address space must be presented in the form of an engineering plan. Since the SLA part of the end-user's assignment allows for creating 65,536 subnets, the organization must show in what way this was not sufficient for their network, and must present a plan showing where each of the 65,536 subnets is used and why new subnets are necessary. Only end-user organizations with a need to create subnets in their network should be assigned a full /48. Dial-up lines are considered part of the ISP's infrastructure and should be assigned from the SLA of that ISP. 4.2.2 Assignments and Allocations to Other ISPs If the TLA Registry has ISP customers (who in turn have end-users), the TLA Registry could use the 13 bits of NLA address space to create an addressing hierarchy for them. Each of the TLA Registry's own end-users would receive a /48 as specified above, however, the ISP customers (NLAs) 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 would be an allocation to the ISP and not an assignment. Therefore, if the ISP does not fully utilize it in a certain period of time, the range will have to be returned. Also, the sub-TLA organization should be careful about making these sub-allocations because they will get a new sub-TLA only when 80% of their entire sub-TLA block is assigned, not just allocated. Therefore, if they have many sub-allocations that are not fully used, they might ask the ISPs to give back some of the address space to use for other customers. Once an NLA ISP has used up its allocation, it may request an additional block from the TLA Registry. This block can be any size, depending on how quickly it took the ISP to use up its first block. Any additional requests for NLA allocations should be submitted to the Regional IR for a second opinion. Each NLA allocation must be registered in the Regional IR database. All end-user assignments must also be registered in the Regional IR database. The same procedures for these end-user assignments apply for the end-user assignments made by the TLA Registry to their customers directly. In the end, the TLA Registry is responsible for how the address space is handled and should have an overview of all the assignments being made by the NLA Service Providers. TLA Registries will not be permitted to assign static IPv6 addresses to dial-up customers. The Regional IR can at any time ask for additional information about the allocations and assignments being made (see /draft-ietf-dhc-dhcpv6-13.txt). 4.3 Reclamation Methods/Conditions Allocations are valid only as long as the original criteria are still met. The criteria for allocating TLA address space may change over time depending on routing technology. The current target is to limit the global routing space to roughly 8,000 entries. If 50% of this limit is reached, routing technology and allocation criteria will be reviewed. If routing technology allows additional route entries, the number of possible TLAs and sub-TLAs may be increased. If it turns out that routing technology at that time does not allow additional routing entries, the allocations made up to that point will be reviewed. Sub-TLA holders with a very low usage rate (to be defined before publication) or sub-TLA holders that do not meet the new criteria may have their sub-TLA space revoked. These organizations will have to renumber and return the sub-TLA within a maximum of 3 months. 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 If an organization requesting sub-TLA space operates in more than one region, and needs separate sub-TLA blocks for routing purposes, it should request the address space for its entire network from only one of the Regional IRs. It can apply for an initial allocation that is larger than 13 bits if it can show that its network is divided into several components with each needing its own sub-TLA route (each component individually needs to fulfill the criteria for being a TLA Registry). The size of the allocation would depend on how many top-level routes are needed. For example, if a multinational transit provider can show that it needs three top-level routes, it would initially receive 15 bits of NLA space (a /33). It could then allocate a /35 to each of the top-level parts of the network and route each one separately. Each of these sub-allocations would need to be entered in the database of the Regional IR individually. 6. DNS AND REVERSE ADDRESS MAPPING TBD 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. End-user - An organization receiving reassignments of IPv6 addresses exclusively for use in operational networks. Interface Identifiers - A 64-bit IPv6 unicast address identifier that identifies an interface on a link. NLA ID - Next-Level Aggregation Identifier. NLA ISP - 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 - --------------------end included draft---------------------------- ------- End of Forwarded Message -- Simon Nybroe System Developer, M. Sc. Telebit Communications A/S tel: +45 86 28 81 77 - 58 Fabrikvej 11 fax: +45 86 28 81 86 DK-8260 Viby J e-mail: sin@tbit.dk