- lir-wg - mailman.ripe.net

IPv6 Assignment and Allocation Policy Document
by Paula Caslav 16 Apr '99

16 Apr '99

Dear colleagues, The RIPE NCC is pleased to make available the latest draft "IPv6 Assignment and Allocation Policy Document" for your information. This document http://www.ripe.net/lir/registries/ipv6.html is the result of a collaborative effort of all the Regional Internet Registries (APNIC, ARIN, and RIPE NCC) and aims to provide a responsible, globally consistent framework for the management of IPv6 address space. This new version takes into consideration suggestions and comments made by the RIPE community on the ipv6-wg mailing list and at the last RIPE meeting, as well as comments made by other communities (such as the ARIN and APNIC members, the IETF and the IAB). IPv6 address space is a public resource and, therefore, its management involves developing policies which achieve the best possible balance of the needs of all members of the Internet community. The RIPE NCC encourages you, as a member of the Internet community, to read this document and consider its implications. We invite you to make any comments you feel would be constructive to the development of a further draft. In order to ensure global consensus, the discussion of this draft will take place on the 6bone mailing list. This way the comments are all collected in one place, and interested parties from all regions/communities can participate. To join this list, please refer to http://www.6bone.net/6bone_email.html. If you would prefer to make private comments about this document, please contact Paula Caslav <paula(a)ripe.net>. Kind regards, Paula Caslav RIPE NCC IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (5th draft 16 April 1999) [* Important note: Throughout this draft, several sections require numerical values to be specified, pending further discussion and comment from the Internet community. In such cases the variable "X*" has been used in place of the numerical value. Where relevant the variable is accompanied by a suggested value range, such as "range=3-6".] 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 internal and 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 site 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. A /64 is the minimum network prefix that can be assigned within a site. Additional subnets would require assignment of additional prefixes of the same size or shorter. 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, 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 sub-TLA registry. 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 BGP 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 [X*: range=30-50] 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 [X*: range=6-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 BGP 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 BGP 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 [X*: range=6-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 [X*: range=30-50] 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 use of a pseudo-TLA (pTLA) registered to it for at least six months prior to requesting a sub-TLA. 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 address space. 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, the address space is considered to be "used" if the TLA Registry has made all of its allocations and assignments of that address space in accordance with the policies and guidelines specified in this document. The size of the subsequent allocation depends on the demonstrated usage rate of the previous allocation. 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[X*: 12-24] 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-0 8.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. Therefore, if the NLA Registry does not use it fully within a certain period of time, [X* time to be specified here?] the TLA Registry may require it to be returned. 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 criteria for allocations continue to be met. 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 [X*: range=4,000-8,000] 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 current routing technology then is not able to support additional routing entries, all allocations made up to that point will be reviewed. TLA Registries with a very low usage rate [X*: to be defined] or that do not meet the new criteria may have their sub-TLA space revoked. These Registries will be required to renumber their networks and return their previous allocation within a maximum of [X*: range=6-12] 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 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. 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 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

1 0

Adding nic handles to contact objects without one (72 chars/line)
by Joao Luis Silva Damas 16 Apr '99

16 Apr '99

Thou shall not send vi docs directly on a mail! At people's request here goes the mail again with sorter lines. Regards, Joao ------- Include message ------ Dear all, During the month of February the RIPE NCC, at the RIPE Database working group's request after the RIPE 32 meeting in Amsterdam, put out a proposal to add automatically generated nic handles to existing person objects that do not currently have one. Some other unrelated issues have caused me to not follow this up appropriately. I am sorry for that. In order to resume (and hopefully swiftly conclude) this issue, I will use the rest of this message to summarize the state of discussions. I would like to ask for a 10 day discussion period after which I will summarize the conclusion to the list and have the Database group take whatever action is agreed to. Summary: The initial proposal called just for the addition of an automatically generated nic handle to person and role objects which currently do not have one. This would be done using the same automatic procedure used by the Database software when a user request an AUTO nic handle. That is, the database takes up to 4 initials from the name, looks for the highest exisiting number of a nic handle in the sequence of nic handles with the same initials, generates a new number and adds the suffix "-RIPE". Input received discussed if we should use the opportunity and try to modify some database objects that reference person and role objects by name instead of nic handle as is required now in the RIPE Database. These are two separate issues. The first one could be approved without the second one. The first one alone brings old objects up to date to current specifications, simplifies the prorammers life and enables further steps to increase the DB's consistency. In my personal opinion it is a Good Thing. The main advantage of the second part is that: - References by nic handle are less ambiguous than references by name since the DB ensures that there are no duplicate nic handles whereas there is no reason why two persons can't have the same name. (Note: currently there are around 30 duplicate nic handles in the RIPE DB due to legacy objects from the past and bugs in past releases of the software. This problem is being addressed in the context of the RIPE DB consistency project. There will be an extensive report on the progress of this project in the coming RIPE meeting in Vienna). Doing this doesn't solve all the problems, naturally, and may have some problems as itemized below: - If the reference by name is to a name for which more than one object exists then there is an ambiguity that can't be handled automatically. The solution to this requires intervention by the referencing object's owner. This will be handled by the DB consistency project. - If there is no object with the referenced name then the referencing object is at least partially orphaned. This issue will also be addressed by the DB consistency project and may eventually need further policy decisions in the future, to be discussed by the community. - There is a chance that a person/role object with a refenced name exists and is unique but is not the one that created the referencing object. Eg. if I created an inetnum object in 1991 but then deleted my person object and then my twin ghost registered in the DB and created some new objects: should the original inetnum object (still in the database) be linked to my twin ghost (who probably doesn't know anything about it)? If this issue is seen as a heavy one then no name references can be modified to references by NIC handle automatically, unless an exhaustive search of the DB update logs is performed (and even then, there is no guaranteed result). I think this summarizes the state of affairs. Please give your input as soon as possible so that a conclusion can be reached. If possible, address the original and the extension proposal separately. Thanks, Joao Damas RIPE DB Group Manager RIPE NCC

1 0

2 digit years in the RIPE DB (Y2K)
by Joao Luis Silva Damas 16 Apr '99

16 Apr '99

Dear all, at the last RIPE meeting the Database Working group asked the RIPE NCC to propose to the community a rewrite of all dates currently stored in the RIPE Database that are using two figures for the year as dates with four figures for the year. The RIPE DB software has already been modified to avoid problems with Y2K. Changing the date format would make things cleaner and not dependant on conventions for interpretation of dates. This simplifies software development both at the RIPE NCC and by users writing their own programs. This is a rather small change although it involves modification of user data and therefore we would like to open a comment period of 10 days to see if there any user concerns about the proposed change. Best regards, Joao Damas RIPE DB Group Manager RIPE NCC

1 0

Adding nic handles to contact objects without one
by Joao Luis Silva Damas 16 Apr '99

16 Apr '99

Dear all, During the month of February the RIPE NCC, at the RIPE Database working group's request after the RIPE 32 meeting in Amsterdam, put out a proposal to add automatically generated nic handles to existing person objects that do not currently have one. Some other unrelated issues have caused me to not follow this up appropriately. I am sorry for that. In order to resume (and hopefully swiftly conclude) this issue, I will use the rest of this message to summarize the state of discussions. I would like to ask for a 10 day discussion period after which I will summarize the conclusion to the list and have the Database group take whatever action is agreed to. Summary: The initial proposal called just for the addition of an automatically generated nic handle to person and role objects which currently do not have one. This would be done using the same automatic procedure used by the Database software when a user request an AUTO nic handle. That is, the database takes up to 4 initials from the name, looks for the highest exisiting number of a nic handle in the sequence of nic handles with the same initials, generates a new number and adds the suffix "-RIPE". Input received discussed if we should use the opportunity and try to modify some database objects that reference person and role objects by name instead of nic handle as is required now in the RIPE Database. These are two separate issues. The first one could be approved without the second one. The first one alone brings old objects up to date to current specifications, simplifies the prorammers life and enables further steps to increase the DB's consistency. In my personal opinion it is a Good Thing. The main advantage of the second part is that: - References by nic handle are less ambiguous than references by name since the DB ensures that there are no duplicate nic handles whereas there is no reason why two persons can't have the same name. (Note: currently there are around 30 duplicate nic handles in the RIPE DB due to legacy objects from the past and bugs in past releases of the software. This problem is being addressed in the context of the RIPE DB consistency project. There will be an extensive report on the progress of this project in the coming RIPE meeting in Vienna). Doing this doesn't solve all the problems, naturally, and may have some problems as itemized below: - If the reference by name is to a name for which more than one object exists then there is an ambiguity that can't be handled automatically. The solution to this requires intervention by the referencing object's owner. This will be handled by the DB consistency project. - If there is no object with the referenced name then the referencing object is at least partially orphaned. This issue will also be addressed by the DB consistency project and may eventually need further policy decisions in the future, to be discussed by the community. - There is a chance that a person/role object with a refenced name exists and is unique but is not the one that created the referencing object. Eg. if I created an inetnum object in 1991 but then deleted my person object and then my twin ghost registered in the DB and created some new objects: should the original inetnum object (still in the database) be linked to my twin ghost (who probably doesn't know anything about it)? If this issue is seen as a heavy one then no name references can be modified to references by NIC handle automatically, unless an exhaustive search of the DB update logs is performed (and even then, there is no guaranteed result). I think summarizes the state of affairs. Please give your input as soon as possible so that a conclusion can be reached. If possible, address the original and the extension proposal separately. Thanks, Joao Damas RIPE DB Group Manager RIPE NCC

1 0

Re: Modifications to the inet6num in the RIPE Database
by Wilfried Woeber, UniVie/ACOnet 17 Mar '99

17 Mar '99

Guy, Engin, thanks a lot for the explanation! Guy said: >Finally, you can only have one of these constructs per address. This is >common sense really since, if you have 3ffe::aaaa::bbbb, you cannot tell >how many zeroes are replaced with the first pair of colons and how many >by the second. There is no convention (AFAIK) for which block would be >written out in full. Personally, since I am lazy, I choose to write out >the fewer number of zeroes (remembering that I only need one zero per >block of 4 hex digits). > >So, some examples of IPv6 addresses are... > >3ffe:1100:0:c00::/52 >= Note the :0: because there is a :: later in the address Engin added: >The algorithm we use translates "5:0:0:78:0:0:0:0" >into "5:0:0:78::" but not "5::78:0:0:0:0". Of course, >both are legal, but we choose to double-colonize the >last group of zeros, and all prefixes are normalized >according to this and then put into the registry. which already gives us two compatible but different ways to deal with that, and >But I don't know what 6bone registry does. interesting, indeed. Taking this one step further, and looking back at what we did with IPv4, where it would be feasible to say 131.130/16, implying 131.130.0.0/16, I wonder if it wouldn't again be worthwhile to restrict the use of these shorthand notations in the Address Registry? Is there a danger for braking something by _not_ allowing the "::" construct in the registry at all, or - in particular - not _in the middle_ of a prefix? Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

5 5

Report on NCC progress toward ICANN Address Supporting Organisation (IMPORTANT)
by Keith Mitchell 17 Mar '99

17 Mar '99

This is a summary of activities undertaken by RIPE NCC on the formation of an Address Supporting Organisation to affiliate to ICANN since the 32nd RIPE meeting in Amsterdam. At that meeting, we heard from Esther Dyson, interim chairman of ICANN, on the need for an ASO to develop policy in the area of Internet addresses. She, in turn, got to meet us and to see the open forum that is RIPE in action, discussing and forming Internet policy in Europe. She expressed the view that RIPE made sense and the hope that RIPE would become involved in ICANN and in the formation of the ASO. In plenary, RIPE 32 clearly said that it wanted to maintain a bottom-up structure in Internet governance, with working and representative regional structures forming the basis of bodies such as the ASO. Least of all did they want a situation whereby ISPs would be obliged to argue their views on address policy in both European and global forums. Mandated by these clear expressions of policy, RIPE NCC undertook to engage in fresh discussions with the other RIRs, APNIC and ARIN. The NCC arranged a teleconference involving exec and board members of all three RIRs. This established a good deal of common round, including the importance of transparent and open process, and of representative structures. The RIRs and their communities were the most directly concerned with address policy and as such should have a key role in the ASO. The views of other groups were also important, and three possible sectors were identified here: government (representing the general public interest), engineering (with an overview of what was technically feasible), and industry (in the widest sense of the Internet). It was agreed to continue this discussion at the APNIC meeting in Singapore at the end of February, again with exec and board members of the three RIRs. There, the process was further opened, with EuroISPA and CIX being invited to attend. These two bodies had made a joint ASO proposal to ICANN, although they had neither advised nor consulted any of the RIRs about this. While anyone is of course at liberty to make a proposal to ICANN, RIPE NCC believes that this should be done in conformance with the open and transparent ethos of ICANN. Indeed, we believe that the RIPE NCC association can speak for you in matters of address policy; we have an obligation to do so on your behalf in external forums, provided we continue to listen to your views and to give effect to them in a clear and impartial manner. At the same time, we recognise that RIPE NCC does not represent ISPs in all aspects of their business, and that there are areas of concern which might best be addressed by trade associations such as EuroISPA. However, when it comes to address policy, you, through RIPE, are the people who have formed the working policies in Europe in the past decade, and RIPE NCC is your association which has helped to implement those policies, openly and impartially, on our behalf, and to represent those policies to other RIRs and to IANA. At the meeting in Singapore, the consensus was that time should be taken to produce a set of solid ASO principles and a charter, rather then being driven by looming deadlines. We are determined to pursue a course of action which will do justice to the collective opinion of members of the RIPE NCC association, and to the work which you have done in shaping and self-regulating the Internet in Europe. We welcome your views on these matters and look forward to representing them in the formation of the ASO. We encourage RIPE participants and RIPE NCC members to follow and participate in the formation process of the ICANN ASO - more information can be found at: http://www.ripe.net/info/ncc/regional.html and http://www.icann.org Keith Mitchell Chairman, on behalf of the RIPE NCC Executive Board

1 0

Re: Modifications to the inet6num in the RIPE Database
by Wilfried Woeber, UniVie/ACOnet 16 Mar '99

16 Mar '99

Hi David, Joao, et.al. <disclaimer> My question is going to prove complete ignorance when it comes to IPv6 address formats. So please bear with me :-) </disclaimer> => The two suggested changes are: => => - - addition of a "status" attribute with the following possible values: => TLA, NLA and SLA. => Syntax checks will be done so that: => TLA is only allowed if the prefix length is 3<x<=16 => NLA is only allowed if the prefix length is 16<x<=48 => SLA is only allowed if the prefix length is 48<x<=64 = =This is fine although, I am not entirely convinced that we really need =it. It's a bit redundant information. By definition something is a =TLA/NLA/SLA so you can just look at the 'inet6num:' field and you =already know what it is. Can't you just generate this field =automatically ?!? For the IPv4 case we do have a well-established format for external representation of addresses and prefixes, i.e. full dotted quad with /prefix-length. In the 6bone registry there's IPv6 prefixes with a "structured" external representation, like "3FFE::/16" or "5FBC:1000::/32". So my questioon is: is there an agreed algorithm to insert punctuation at the "appropriate" positions, and does the proposal/criticism for the semantic checks do have an influence on this formatting? Thanks, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

4 3

IETF Attendees: Open Meeting on the Formation of the ICANN ASO
by Daniel Karrenberg 16 Mar '99

16 Mar '99

For those attending the IETF and interested in the future of Internet Address Space administration, here is notice of a pertinent meeting. This is one of a series of open meetings to solicit broad input on the formation of the "Address Upoorting Organisation" of ICANN. This meeting will not decide anything. It is just a vehicle to keep interested parties informed of what is happening and solicit discussion on the topic. The pertinent mailing list is <aso-discuss(a)ripe.net>. For more info, see: http://www.ripe.net/info/ncc/regional.html "Open Meeting on the Formation of the ICANN ASO" tomorrow Wednesdae 17 March, 1800-1900 (6pm-7pm) Minneapolis Hilton & Towers, Rochester Room (3rd floor) Agenda 1) Presentation of Current State of Process (NN) 2) Discussion Daniel

1 0

Modifications to the inet6num in the RIPE Database
by Joao Luis Silva Damas 15 Mar '99

15 Mar '99

Dear all, A week has passed and no comments against the proposed modifications to the IPv6 object have been put forward. Therefore we take it that everyone is happy with it and will procede with the implementation. We expect this to be available in about two weeks. The original message is repeated below for your reference. Regards, Joao Damas DB Group RIPE NCC ------- Begin Original Message From: Joao Luis Silva Damas <joao(a)ripe.net> Date: Thu, 04 Mar 1999 10:20:17 +0100 To: lir-wg(a)ripe.net, db-wg(a)ripe.net Subject: Modifications to the inet6num in the RIPE Database Dear all, below are the proposed modifications to the inet6num object in the RIPE Database as discussed during the past RIPE Meeting. These are mainly to bring the IPv6 object up to the IPv4 object's functionality. The two suggested changes are: - - addition of a "status" attribute with the following possible values: TLA, NLA and SLA. Syntax checks will be done so that: TLA is only allowed if the prefix length is 3<x<=16 NLA is only allowed if the prefix length is 16<x<=48 SLA is only allowed if the prefix length is 48<x<=64 - - addition of "mnt-lower" capabilities, as in the IPv4 object. We would like to open a comment period of 1 week from today to gather input and proceed with implementation if there is consensus. Regards, Joao Damas DB Group RIPE NCC ------- End Original Message

2 1

ANN: Autohm source release
by Maldwyn Morris 15 Mar '99

15 Mar '99

Hi, I am pleased to announce the public release of the source code of autohm, the syntax-checking part of Web141, which is the RIPE NCC's European IP Address Space Request web form. Autohm is a fairly complex perl program designed to be run by web141.pl.cgi or standalone. Some customisation is required by the user, but nothing too complicated. This installation process is documented in docs/readme.pub. You mainly need to ensure that the directory and executable paths are correct and that the permissions are set correctly. You can get the ( gzip-ed and tar-ed ) file at: ftp://ftp.ripe.net/tools/autohm.1.24.tar.gz You can see our local copy running at: http://www.ripe.net/cgi-bin/web141/web141.pl.cgi We have had some helpful suggestions regarding web141, which we hope to implement during the next few days. Please let us know your comments and suggestions - we have already had some helpful suggestions regarding web141, which we hope to implement during the next few days. Cheers, Maldwyn Morris Software Manager RIPE NCC

1 0