Dear Local IR Working Group, The document included below is the first part of a document intended to replace ripe-104 and ripe-105. While we have made progress on the latter half, it is not ready for review. You can see what will be covered there if you read Section 1. This will be the background for the discussion mentioned by Mike Norris for the Local IR working group meeting next week. A number of people, most notably Mike Norris, Wilfried Woeber and Janos Zsako, have made useful comments and contributions to the draft below. Any remaining problems are, however, the responsibility of the authors. While our aim was to write down current practices, we understand that it may raise questions about policy. That's why we want to get it out to you before the RIPE meeting next week. Any errors you note can be sent directly to me (orange@ripe.net). I look forward to meeting you all next week. -- Carol PS: Postscript follows in a separate message. ------------------------------------------------------------------------ European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ European Internet Registry Policies and Procedures Version 0.1 C. Orange, M. Kuehne, D. Karrenberg Document ID: ripe-104++ Obsoletes: ripe-104, ripe-105, ripe-127, ripe-128 ABSTRACT The distribution of IP address space follows the hierarchical scheme described in RFC1466. For Europe and parts of the surrounding area address space is allo- cated by IANA to the RIPE NCC which acts as a regional Internet registry. Address space is allocated by the RIPE NCC to local Internet Registries (IR), who assign it to to end users. In this document, we describe the policies and procedures asso- ciated with address space management that must be followed by local IRs. Moreover, we present a number of services available to local IRs to simplify the tasks associ- ated with address space management. 1. Scope This document describes the European Internet reg- istry system for the distribution of globally unique Internet address space and its operation. Particu- larly it describes the rules and guidelines govern- ing the distribution of this address space. The rules set forth in this document are binding for all address space allocated and assigned via the RIPE NCC. This document does not describe private Internet address space and multicast address space. This document does not describe local additions to the European guidelines. While providing an overview about the global Internet registry system this ____________________________________________________ ripe-104++.txt Page 1 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ document does not describe allocation and assignment rules used by other regional registries. 1.1. Overview The main body of this document comprises eight sec- tions, with content as follows. Section 2 (Internet Address Space and the Internet Registry System) defines different types of IP address space and their purposes. It explains the goals used in assigning such addresses and outlines the hierarchical nature of the Internet Registry system used to achieve these goals. The important distinction between Provider Aggregatable and Provider Independent address space is also covered. In Section 3 (Address Space Assignment Procedures), the procedures to be followed by European IP reg- istries when assigning IP addresses to users. The importance of documentation is stressed, while the various elements of information required are explained in detail. Next, the criteria and stan- dards of evaluation are dealt with. Finally, the actual assignment of address space, of various kinds, is described, as are the accompanying steps which a registry must take. Section 4 (Rules and Guidelines for Allocations) explains how the RIPE NCC allocates IP address space to registries in an efficient and equitable manner and how the status and nature of such allocations are made publicly available in the RIPE database. Section 5 (DNS and Reverse Address Mapping) docu- ments the role of the RIPE NCC in providing reverse delegation, and explains how registries can manage subsidiary reverse delegation of assigned address space. Section 6 (Internet Registry Operations) documents operational procedures of IR. This includes informa- tion on starting and closing an IR, communications, record keeping, confidentiality, and policies on IR operations. Moreover various resources and tools for registry operation are described in that sec- tion. Section 7 (AS Number Assignment Procedures and Poli- cies) describes how to manage a group of IP networks as an autonomous system. Both the procedural and technical issues involved in AS number management ____________________________________________________ ripe-104++.txt Page 2 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ are described. Section 8 (Interdomain Routing Considerations) describes the policies and procedures necessary to originate routes for assigned address space. We conclude with a glossary in which the key terms used in this document are defined. ____________________________________________________ ripe-104++.txt Page 3 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 2. Internet Address Space and the Internet Registry System 2.1. Types of IP Addresses IP addresses for the purposes of this document are 32-bit binary numbers used as addresses in the IPv4 protocols. There are three main types of IP addresses Public Addresses The public IP addresses make up the Internet address space. They are assigned to be glob- ally unique according to the goals described below. The main purpose of this address space is to allow communication using IPv4 over the Internet. A secondary purpose is to allow com- munication using IPv4 over interconnected pri- vate internets. One can currently distinguish two kinds of public addresses: provider inde- pendent (PI) and provider aggregatable (PA) addresses; see below for more details. Private Addresses Some address ranges have been set aside for the operation of private networks using IP. Anyone can use these addresses in their private net- works without any registration or coordination. Hosts using these addresses can not be reached from the Internet. For a thorough description of private address space, please refer to RFC1597. Special and Reserved Addresses There are a number of address ranges reserved for applications like multicasting. These are described elsewhere [ref] and are beyond the scope of this document. ____________________________________________________ ripe-104++.txt Page 4 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 2.2. Goals of Public Address Space Distribution In the remainder of this document, we are primarily concerned with the management of public Internet address space, as defined in the previous section. Every assignment of Internet addresses must guaran- tee that the following restriction is met. Uniqueness Each public Internet address worldwide must be unique. This is an absolute requirement which guarantees that every host on the Internet can be uniquely identified. In addition to the uniqueness requirement, public Internet address space assignments should be made with the following three goals in mind. Aggregation The distribution of public Internet addresses in a hierarchical manner, permitting the aggre- gation of routing information. This is neces- sary to ensure proper operation of Internet routing. This goal could also be called "Routability". Conservation The fair distribution of public Internet address space according to the operational needs of the end users operating networks using this address space. In order to maximize the lifetime of the public Internet address space resource, addresses must be distributed accord- ing to need, and stockpiling must be prevented. Registration The provision of a public registry documenting address space allocation and assignment. This is necessary to ensure uniqueness and to pro- vide information for Internet trouble shooting at all levels. It is in the interest of the Internet community as a whole that the above goals are pursued. It is worth noting that "Conservation" and "Aggregation" are ____________________________________________________ ripe-104++.txt Page 5 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ often conflicting goals, and therefore that each assignment must be evaluated carefully. Moreover, the above goals may occasionally be in conflict with the interests of individual end users or Internet service providers. Careful analysis and judgement are necessary in each individual case to find an appropriate compromise. The rules and guidelines in this document are intended to help Internet reg- istries and end users in their search for good com- promises. ____________________________________________________ ripe-104++.txt Page 6 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 2.3. The Internet Registry System The Internet Registry system has been established to achieve the above stated goals. It consists of hierarchically organized Internet Registries (IRs). Address space is typically assigned to end users by local IRs. The address space assigned is taken from that allocated to the local IR by the regional IR. End users are those organizations operating networks in which the address space is used. The address space may, however, be requested by a consultant (requester) acting on behalf of the end user. Local IRs are typically operated by Internet Service Providers (ISPs). Local IRs hold allocations of address space for assignment to end users. Assigned address space is actually used to operate networks, whereas allocated address space is held by local IRs for future assignments to end users. To achieve both the conservation and aggregation goals, only IRs can hold allocations of address space. IANA The Internet Assigned Numbers Authority has author- ity over all number spaces used in the Internet. This includes IP address space. IANA allocates pub- lic Internet address space to regional IRs according to their established needs. Regional IRs Regional IRs operate in large geopolitical regions such as continents. To date, three Regional IRs have been established, namely the InterNIC serving North America, the AP-NIC serving the Asian Pacific region, and the RIPE NCC serving Europe and sur- rounding areas. Since these do not cover all geo- graphical areas, regional IRs also serve areas around their core service areas. The number of regional IRs is expected to remain small. Regional IRs are established under the Authority of IANA. This requires consensus within the Internet community of the region. In particular, the ISPs in the region under consideration should be involved in the process. The duties of a regional IR include the coordination and representation of the local IRs in its region. ____________________________________________________ ripe-104++.txt Page 7 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ Local IRs Local IRs are established under the authority of a regional IR. Local IRs are typically operated by ISPs and serve the customers of those ISPs as well as the customers of smaller ISPs who are connected to the rest of the Internet through the larger ISP. Other organizations such as large international Enterprises can also operate local IRs. Much of this document is concerned with the respon- sibility of the local IR in the assignment process. In some cases, the local IR assigning the address space is not run by the ISP that will provide con- nectivity. It is important to note that maintenance of the administrative information regarding the assigned address space is the responsibility of the IR that makes the assignment, and not of the ISP providing the connectivity. Furthermore, only IRs can hold address allocations. End-Users Strictly speaking end users are not part of the IR system. They do, however, play an important role with respect to the goals defined above. In order to achieve the conservation goal, for example, end users should plan their networks to use a minimum amount of address space. They must document their addressing and deployment plans to the IR and fur- nish any additional information required by the IR for making assignment decisions. To achieve the aggregation goal, an end user should choose an appropriate local IR. End users should be aware that changing ISPs may require replacing addresses in their networks. Finally end users must provide and update registration data for the address space assigned to them. Requesters In addition to these key players in the Internet Registry System, there are often consultants who setup and manage networks for end users. The consul- tants may be the people actually submitting a request for address space to an IR on behalf of an end user. We refer to the person making the request for an end user as a requester, whether that person is employed by the organization, or is simply acting on behalf of the organization with respect to the address space request. ____________________________________________________ ripe-104++.txt Page 8 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ For Europe, the Internet Registry System hierarchy consists of the following entities (from the top down): IANA, the RIPE NCC, Local IRs. See Appendix A the area covered by the RIPE NCC. 2.4. Provider Independent vs Provider Aggregatable Addresses Provider Aggregatable Address Space Local IRs operated by Internet service providers are allocated Provider Aggregatable (PA) address space which they assign to their end users. This is done in such a way that routing information for many end users of an ISP can be aggregated on the borders of the provider's routing domain. This keeps the num- ber of routes and state changes in the interdomain routing system (between providers) at an acceptable level. The cost of propagating a relatively small number of aggregated routes is much lower than that of propagating each end user's individual routes throughout the entire interdomain routing system. If an end user changes service providers, their PA address space will have to be replaced. As a conse- quence, all hosts and routers at the end user's organization will have to be reconfigured. The end user will need to obtain an assignment from the local IR run by the new service provider, and return the previously assigned address space to the local IR run by the old service provider. To ensure the address space is properly returned, a clear, prefer- ably contractual, understanding is needed between the service provider and the end user. The agreement should state that the assignment of the address space becomes invalid when the provider no longer provides Internet connectivity to the end user or shortly thereafter. The goal of this arrangement is to minimize the load on the interdomain routing system. If the end user continued to use PA address space obtained from their previous service provider when connecting to another service provider, their routing information could not be aggregated and would have to be propa- gated separately throughout the whole interdomain routing system. ____________________________________________________ ripe-104++.txt Page 9 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ Provider Independent Address Space In contrast to PA address space, PI address space can remain assigned to its user as long as the cri- teria for the original assignment are met. The dura- tion of the assignment is independent of the use of a particular provider's services. The apparent advantage of PI address space is that a user's hosts and routers need not be reconfigured if the user decides to change service providers. However, PI addresses are expensive to route because no use can be made of aggregation. All early Internet address space assignments were provider independent. Many assignments made by local IRs are also formally provider independent due to a lack of prior agree- ments between ISP and the end user that the assign- ment will be terminated when the service is. Validity of assignment Assignments of any kind of address space are valid as long as the original criteria on which the assignment was based are still valid. If an assign- mnet is made for a specific purpose and the purpose does no longer exist, also the assignment is no longer valid. If an assignment is based on informa- tion that turns out to be invalid so is the assign- ment. ____________________________________________________ ripe-104++.txt Page 10 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 3. Address Space Assignment Procedures 3.1. Introduction In this section, we describe the procedures to be followed by local IRs when assigning address space to their users. We start with a description of the information to be gathered from the user. The pur- pose of the information gathering is twofold. First, the information is required to make address assign- ment decisions, with respect to the aggregation and conservation goals. Second, the information is required for registration purposes. We go on to describe how this information should be evaluated to make appropriate assignments, and introduce additional considerations that may be essential in the assignment decision. Finally we specify the procedures to be followed in the assign- ment process. Before going into the factors in the assignment pro- cess, we start with some general background informa- tion and policies that determine the information to be gathered, and the procedures to be followed. Address space is assigned by IRs to end users who use it to operate the specific networks described in an address space request. IRs guarantee that no other end user will be assigned the same address space during the validity of the assignment. An assignment is valid as long as the criteria on which it is based remain valid. In accordance with the conservation goal, end users are not permitted to reserve address space. Evalua- tion of IP address space requests must be based on the documentation provided for the following 24 months, as specified in the addressing plan and the current address space usage described in the next section. The amount of address space assigned must be justified by this documentation. This means that address space assigned in the past should be used to meet the current request if possible. Once an orga- nization has used its assigned address space, it can request additional address space based on an updated estimate of growth in its network. ____________________________________________________ ripe-104++.txt Page 11 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 3.2. Documentation To make appropriate assignment decisions, informa- tion must be gathered about the organization, addressing requirements, network infrastructure, current address space usage, and future plans of the end user requesting address space. Some information is essential to the assignment process, and is for- mally required by the IR's. Other information is very helpful in making assignment decisions, but is not strictly required. The Local IR must assure that the required information is complete before proceeding with the request. For gathering the required information, the RIPE NCC provides a set of forms and a set of instructions to fill them in. Although use of the forms provided (or a local-language equivalent) is strongly encour- aged, each local IR can obtain and manage this information as it considers appropriate. Requests requiring evaluation by the NCC must, however, be submitted on a current version of the "IP Address Space Request Form". The information gathered in the assignment process must be maintained permanently by the IR making the assignment. It must be made available to the parent registry immediately upon request. The IR is respon- sible for protecting the end user's privacy. Aside from the data specified in Section (database infor- mation) below, which is published in the registry database, the data gathered must be kept in strict confidence. The IR is not authorized to provide the information to anyone not representing the parent registry. In the subsections that follow, we outline the spe- cific data to be gathered and the reasons for doing so. 3.2.1. Required Information The following set of information must be provided with every request for an address assignment. The data is essential both to properly assigning addresses and to maintaining a global overview of assignments. With the exception of the information specified in Section (current address space usage), all information refers to the currently requested address space. ____________________________________________________ ripe-104++.txt Page 12 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 3.2.1.1. Overview of Organization To properly assess the user's address space require- ments, it is essential to understand the structure of the organization to which the addresses are being assigned, and which part of the organization will make use of the addresses. Consider the following situation. A bicycle manufac- turer based in Belgium has a variety of departments. Some, such as the Front Fork and Derailer depart- ments, specialize in specific bike parts. Others, such as the Sales and Development departments are more general by nature. In such a company, the departments Sales, Development, and Manufacturing may fall directly under the top management, whereas the subdepartments Derailer, Chain, Pedal, and Front Fork fall under the Manufacturing department. If someone submits a request for address space, we must know which part of the organization will make use of the assigned addresses. Suppose, for example, the Manufacturing department is assigned address space for use by all bike parts sub-departments. If shortly thereafter, the Chain department requests address space it is important that we know an assignment has already been made to the organization to meet the Chain department's needs. A similar situation may occur if the Sales department has groups of representatives in several countries. It is essential to know if addresses being requested by the central office will be used in Antwerp or in Madrid. We want to prevent assignments being made for the same subnet by two different parts of the organization. In the case of a distributed sales department, this must also be known to assure a proper assignment with respect to aggregation. The person responsible for making the assignment can only be aware of this situation if an overview of the organization, and the requester's role therein is known. It is therefore important that a brief overview of the organizational structure be pro- vided. This should include details of the parent company, subsidiaries and contact persons. In the case of our bicycle manufacturer, one would expect someone representing the Chain department to produce general information about the structure of the organization in Belgium, and contact persons for the Manufacturing, Sales, and Development depart- ments. We would not expect the same person to pre- sent information on the structure within the Sales ____________________________________________________ ripe-104++.txt Page 13 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ department, such as who manages the office in Rome. Clearly, the assignment process is greatly simpli- fied if an organization coordinates its address space management, and if all requests are made by a single body representing the entire organization. Contact Persons To facilitate handling the request, contact informa- tion is required for the person making the request and for someone at the organization to which the address space will be assigned. The information should be entered on the Requester and User contact templates, respectively. These templates contain name, organization, country, phone, fax-no, and e- mail fields. In each template, the appropriate per- son's name should be specified in full. The organi- zation refers to that in which this person works, and the country refers to that in which the person's office is located. The telephone and fax numbers should include the country prefixes in the form +code, and if the person can be reached by e-mail from the Internet, the address should be specified. The contact person information is only collected to facilitate the address space request. It may or may not include data for persons that will later be entered in the RIPE database. 3.2.1.2. Current Assignment Space Usage To meet the conservation goal in address space assignments, one must have information regarding address space assignments made to the user in the past before new address space can be assigned. A detailed description of how the address space is currently being used is required. Using this infor- mation, we can prevent assigning new address space, where already assigned addresses can be employed to meet the user's needs. Each set of addresses already assigned to the orga- nization must therefore be reported. The current use of these addresses must be documented in a table similar to that below. An entry must be included for each physically separate subnet in the user's network. Subnets are considered to be physically separate if there is an IP router between them. ____________________________________________________ ripe-104++.txt Page 14 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ Each row in the table below contains an entry for a subnet in the end user's organization. Addresses Used Prefix Subnet Mask Size Current 1yr 2yr Description 193.1.193.0 255.255.255.192 64 28 34 50 Derailer 193.1.193.64 255.255.255.224 32 10 12 15 Chain 193.1.193.96 255.255.255.224 32 8 13 17 Front Fork 193.1.193.128 128 Unused 193.1.194.0 255.255.255.0 256 132 170 210 Frame 193.1.195.0 255.255.254.0 512 317 350 380 Assembly 1024 495 579 672 Totals Each entry in the table above is made up of the fol- lowing fields which specify the current and pro- jected use of the address space in the subnet. The Description field is used to specify a short but semantically meaningful description of the role of the subnet in the user's organization. In our exam- ple, we have descriptions corresponding to various bike parts. Together with the size information, this provides significant insight as to the network structure in the organization. The number of network interfaces currently used in the subnet, along with the number expected to be needed in the coming one and two years must also be specified. These numbers are to be entered in the Current, 1yr, and 2yr fields of the subnet entry, and include the number of network interfaces to be used, such as those for hosts, routers, gateways, terminal concentrators, printers, and any other machines requiring one or more network interfaces. The Size field is used to specify the size of the subnet, which determines the maximum number of net- work interfaces that can be incorporated in the sub- net. It must be a power of two, and of course should be greater than or equal to the number specified in the 2yr field. If it is smaller, this may be the motivation for the address request, or it may be a mistake in the requester's planning. The Subnet Mask field is used to specify just that, and finally, in the Prefix field, the position in the assigned address space at which the addresses for this subnet start is specified. As in the example, entries should be made in the ____________________________________________________ ripe-104++.txt Page 15 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ table for assigned address space which is currently not used. 3.2.1.3. Request Overview The network overview is used to obtain a quick idea about the scale of the request. This information allows the IR processing the request to gain immedi- ate insight as to the nature of the assignment request. The exact information to be gathered is: Size of Request To give the IR an immediate indica- tion of the scale of the request, the total number of Internet addresses being requested must be speci- fied under request-size on the network overview form. If the request-size is 512, the user speci- fies a need for that number of Internet addresses. Prior to the use of CIDR, the user would have asked for two Class C networks. Because classless address- ing is now used, the size of the request may be less than 256 or fall between the class borders (e.g. 32, 288, 384). Addresses to be Used To obtain an overview of the structure of the requester's network, one must know how many Internet addresses will actually be used at different points in time. This corresponds to the number of interfaces to the network, which often will be slightly higher than the number of hosts. In the network overview form, the fields addresses- immediate, addresses-year-1, and addresses-year-2 are used to specify how many of the requested net- work addresses will be used immediately following the assignment, within 12 months, and within 24 months, respectively. Number of Subnets In practice, the end user will want to employ the requested addresses in one or more subnets in an organization. The number of physically separate subnets in which the requested addresses will be used is an important factor in making correct assignments. Together with the num- ber of addresses to be used, this provides a global picture of the requester's envisioned network infrastructure. In the network overview form, the fields subnets-immediate, subnets-year-1, and sub- nets-year-2 are used to specify the number of sub- nets in the requester's network plan to be ____________________________________________________ ripe-104++.txt Page 16 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ implemented immediately, within 12 months and within 24 months, respectively. Internet Connection Prior to assigning address space, it is essential to know if the end user requesting IP addresses is already connected to the Internet. If so, then the selection of appropriate address space for this user may depend on which provider(s) currently supplies connectivity. If the user is not connected, but is planning to be, this should also be taken into account. This information is essential if the conservation and aggregation goals of the public address space distribution are to be met. The current and planned connectivity of the user is specified in the inet-connect field of the network overview form. Country Finally, the country or countries in which the addresses will be used must be specified using the ISO 3166 two letter code. The country-net field of the network overview form is reserved for this purpose. If the ISO 3166 code is not known, the full name of the country should be specified. Private Address Space Using private addresses helps to meet the conservation goal. For this reason, users should always be informed that private addresses might be a viable option. In particular, private address space can be employed if not all hosts require network layer access to the Internet. Although users are not required to use private address space even if it would satisfy their needs, it is important that they have considered the possi- bility. The private-considered field in the network overview form should be checked after the requester has indicated whether it is applicable for the user's network. Request Refused If a user's organization has had an assignment request refused in the past, then it is useful to know when and by which IR. Whatever the case, it is useful to know if a request has been refused, and why. This information should be speci- fied in the request-refused field in the network overview form. PI Requested If provider independent address space is requested by the user, special steps will have to ____________________________________________________ ripe-104++.txt Page 17 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ be taken by the local IR processing the request. The PI-requested field in the network overview form should be checked if this is a request for PI address space. 3.2.1.4. Addressing Plan To assess the suitability of assigning the requested address space, an addressing plan is required. This provides detailed information on the projected use of the requested address space. Like the current address space usage, the addressing plan is a table in which every subnet is specified. With few exceptions, the entries in the following table are the same as those in the table of current address space usage. Relative Addresses Used Prefix# Subnet Mask Size Immediate 1yr 2yr Description 0.0.0.0 255.255.255.192 64 8 16 30 Systems Group 0.0.0.64 255.255.255.224 32 17 22 26 Engineering 0.0.0.96 255.255.255.224 32 12 17 20 Manufacturing 0.0.0.128 255.255.255.224 32 10 15 20 Sales 0.0.0.160 255.255.255.240 16 5 9 12 Management 0.0.0.176 255.255.255.240 16 7 8 9 Finance 192 59 87 117 Totals The number of network interfaces immediately required in the subnet, along with the projected need for the coming 12 and 24 months must be speci- fied. These numbers are to be entered in the Immedi- ate, 1yr, and 2yr fields of the subnet entry. In the Relative Prefix field, we specify the rela- tive position in the assigned address space at which the addresses for this subnet will start. The rela- tive position of the first subnet is always 0.0.0.0. For each subsequent subnet, the start position is selected to allow for the total number of hosts in the Size fields of the subnets which precede it. To conserve address space, the start positions of the subnets should be selected to minimize padding in the address space. In the example above, we ____________________________________________________ ripe-104++.txt Page 18 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ arrange the rows in decreasing order of the Size field. This scheme can be applied in general to pre- vent wasting address space between subnets. The size of every valid request for address space will be the sum of sizes of the subnets specified in the addressing plan. Current evaluation criteria assume that addressing is classless. This means that all possible prefixes of any length can be used. If there are technical restrictions preventing the use of certain address ranges or the choice of optimal subnet sizes, these restrictions need to be explicitly documented. Doc- umentation needs to include the precise nature of the restriction, the make, model and version of the hardware or software causing the restriction, and its precise location in the network. 3.2.1.5. Database Information For registration purposes, information is required about the organization needing address space. Infor- mation is also required about the persons involved in the request and administration of the addresses. request. Some of the information may be redundant because the same person can play multiple roles. However, every role can be filled by someone differ- ent, so all information must be supplied in full. The data specified below is to be gathered by the local IR handling the assignment, and will be stored in the registry database, at which point it becomes publicly accessible. Organization Some information about the organization that will be using the addresses must be supplied for maintenance of the RIPE database. The Network Template is supplied for this purpose. To help identify this assignment in the RIPE database, a short, but semantically meaningful name must be entered in the netname field. A short description of the organization that will use the assigned addresses is needed. The information is specified using one or more descr fields in the Net- work Template. If, for example, the assigned addresses will be used by the Department of Neural Surgery at Catatonic State University, then the department and university names may be specified in two descr fields. The ISO 3166 country code should be specified in the country field. The full country ____________________________________________________ ripe-104++.txt Page 19 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ name can be used if the code is not known. The admin-c and tech-c fields are used to specify the IR handle (NIC handle) for the administrative and technical contact persons, respectively. The administrative person specified in the admin-c field must be physically located at the site of the net- work. The technical person specified in the tech-c field may be a network support person located on site, but could also be a consultant that maintains the network for the organization. In both cases, more than one person can be specified. The use of NIC handles to specify each contact person is required, as it assures each person has a unique entry in the database. If the person doesn't have an entry in the database, a unique NIC handle can be acquired upon request. Personal Data For every person involved in an assignment request, we need a full set of personal data. This data can only be omitted if up to date information for the given person is already stored in the RIPE database. If new data is provided for a person with an entry in the database, it will be viewed as an update upon submission, and overwrite the current person data. Otherwise, the following set of data must be specified in the Person Tem- plate. The person's name should be specified in full in the person field. The full postal address is specified using multiple address fields. The international telephone number which can be used to reach the person at work must be entered in the phone field, and the fax number should be entered in the fax-no field. Of course, the NIC handle for this person must be entered in the nic-hdl field to uniquely identify this person in the database. Submission Information In both the Network Template and Person Template, space is reserved to identify the person submitting these entries to the registry database. The submit- ter's e-mail address must be specified in the changed field together with the date the template is submitted. Similarly, the source field is used to specify the registry database where the requester information can be found after an assignment is made. In this ____________________________________________________ ripe-104++.txt Page 20 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ case it will be RIPE, as the requester information for this assignment will be stored in the RIPE database. 3.2.2. Additional Information In the assessment of an assignment request, the additional information described below is always useful. In some cases, IR's may require this data be provided as part of the evaluation process. Deployment Plan Suppose we are dealing with a new corporation that wants to have access to the Inter- net, and estimates an immediate need for 10,000 addresses. In such cases, a deployment plan may be requested from the user. The plan should include a list of events which will lead to the use of the requested addresses, along with the dates that the events will occur. This can be used to determine how realistic the user is being, and if suitable to phase the assignment process in according to the user's plans. Topological Map The old saying "a picture is worth a thousand words" certainly holds in the case of net- works. If a topological map of the current and planned network infrastructure in the requesting organization can be acquired, it can provide insight on the network structure. Such maps are often avail- able, and are quite useful when combined with the addressing plan and current address space usage. Special Circumstances Sometimes, due to the use of old systems or special purpose hardware, the user is unable to make use of assignments based on classless addressing. If this is the case, information should be gathered from the user as to the specific hard- ware or software which presents a problem. Moreover, it is useful to know how long the user will be using the hardware or software which presents a problem. Verification Information In working with a user who hasn't had substantial network experience, it is sometimes hard to determine whether the user's request is based on a realistic plan. It can there- fore be useful to request information which might indicate the degree to which the user understands network planning and management. First, one may ask how accurate the user thinks the estimations in the addressing plan are, and how they have been derived. The corresponding name space plans provide another ____________________________________________________ ripe-104++.txt Page 21 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ indication of how well considered the user's plans are. 3.3. Evaluation Having collected the above information, we must now determine a proper assignment with respect to the conservation and aggregation goals stated in Section 1. Every request requires an individual evaluation process that takes current assignment guidelines into account. Given the above documentation, one must determine if IP addresses should be assigned, and if so, how many and of what type. In the process, it is essential that IR's work to prevent the stockpiling of address space. The use of classless addressing will con- tribute to the conservation of address space. Mean- while, to enable proper routing, one must make strategic decisions with regard to aggregation. These concerns motivate the evaluation process out- lined in this section. Evaluation Steps 1. Current address space usage One should start by comparing the current address space usage provided by the requester with other information available to the IR. After verifying the current address space usage, one should check to see if the requested IP addresses can be taken from those already assigned to the user. 2. Network Overview Next, the size of the request, specified in the Network Overview should be compared with the number of addresses to be used immediately, and within two years of the time the request is made. Here we evaluate the utilization rates, that is address space requested in relation to that to be used. Unless there are special circumstances, imme- diate utilization should be at least 25% of the assigned address space, and the utilization rate one year later should be at least 50%. 3. Private Address Space If private address space might be suitable for this network, it must be assured that the user is aware of this option and has decided against it. Moreover users should be aware that they will have more address space at their disposal if they use private address space. ____________________________________________________ ripe-104++.txt Page 22 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 4. Very Small Enterprises (VSE's) An address space user with a small number of hosts (currently <=32) is referred to as a very small enterprise (VSE) regardless of the size of the organization. Address space for VSEs should be assigned in a classless way. As with all address space requests, care should be taken to avoid assigning more address space than is required. See (Eidnes/deGroot) for appropriate reverse delegation methods. VSEs that do not intend to connect to the Internet should nor- mally not be assigned PI space but referred to pri- vate address space because the effort to renumber into PA space at that point is normally minimal. 5. Addressing Plan In evaluating the addressing plan, one should first check that the totals for the number of addresses to be used immediately, in one year, and in two years, correspond to those speci- fied in the request overview. The validity of the network masks should then be checked to see if they are consistent with the size of the subnet. Some- times address space can be saved by using different subnet masks than specified by the user. If so, the user should be requested to resubmit an addressing plan with a more appropriate use of network masks. In general, there should not be a large gap between the number of addresses requested for a subnet (size) and the number which will be used. This holds even if the requester argues that network adminis- tration will be greatly simplified by an addressing scheme with lots of padding. 6. Additional Information If a deployment plan has been provided, the addressing plan should be reviewed to see if the two correspond. Likewise, one should inspect the topology map if it is available to see if it agrees with the addressing plan. Any information gathered which can be used to check the validity of the current address space usage and addressing plans should be employed to do so. 7. Address Reservations Assignments must be based solely on realistic expectations as specified in the addressing plan and the current address space usage. End users are not permitted to reserve addresses based on long term plans, because it fragments the address space. Such reservations are generally fruitless because they turn out to be unnecessary or insufficient for the user's needs. 8. Static Dialup Due to constraints on the available free pool of IPv4 address space, the use of static ____________________________________________________ ripe-104++.txt Page 23 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ IP address assignments (e.g., one address per cus- tomer) for dial-up users is strongly discouraged. While it is understood that the use of static addressing may ease some aspects of administration, the current rate of consumption of the remaining unassigned IPv4 address space does not permit the assignment of addresses for administrative ease. Organizations considering the use of static IP address assignment are expected to investigate and implement dynamic assignment technologies whenever possible. If allocations for this purpose are indeed made, special allocation and verificatin pro- cedures apply. Please contact the RIPE NCC for details. 9. Virtual Hosts Sometimes a single host is assigned more than one IP address on the same interface and physical network. Often this is used to circumvent shortcomings in higher level protocols such as HTTP. Large scale assignments for this purpose are dis- couraged for the reasons mentioned in the paragraph above. If allocations or assignments for this pur- pose are indeed made, special allocation and verifi- catin procedures apply. Please contact the RIPE NCC for details. 3.4. Assignment Procedures We now describe the specific procedures to be fol- lowed in assigning address space. In the following, we assume that the required information has been gathered, and evaluated as outlined in the previous subsections. The procedures described in this sub- section lead to the assignment of specific address space for the request under consideration. 3.4.1. Assignments within Allocations Once an IR has assured that the address space request merits the assignment of k addresses, the actual set of addresses to be assigned must be selected. If the addresses are to be assigned from a range of address space allocated to the local IR making the assignment, then care must be taken to prevent fragmentation of the allocated space. Specifically, each set of address space assigned should start on a CIDR (bit) boundaries. This means the start address for each set of assigned range must be divisible by the size of the block to be assigned. This helps to achieve the aggregation ____________________________________________________ ripe-104++.txt Page 24 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ goal in address space assignments. Suppose a request can be satisfied with a number small chunks of address space rather than one large one. For example, if 384 addresses are sufficient to satisfy a request, but no more than 256 will be used in a single physical subnet, then the user can be assigned a /24 and a /25 rather than a /23, which results in saving a /25 for another user. Local IRs are encouraged to assign multiple range of address space, rather than a single range in accordance with the conservation goal. Of course the effort to do so should increase as the amount of address space that can be saved in doing so increases. Local IRs are always welcome to request advice from the RIPE NCC in making assignment decisions. In some cases, however, an assignment must be approved by the RIPE NCC even if it is made from a block of address space allocated to the local IR making the assignment. In particular, if the size of the assignment is larger than the local IR is permitted to make, it must be approved by the RIPE NCC in advance. The size of assignments a local IR is per- mitted to make without prior approval is determined by the local IR's assignment window, discussed in Section (Assignment Window). If the addresses are to be assigned from a block not allocated to the local IR, the selection will be made by the IR to which the the address space is allocated. In general, this will be the regional IR. 3.4.2. PA vs PI Space The criteria used to determine the amount of address space and the registration requirements are identi- cal for PA and PI address space. For example, regardless of whether the assignment is for PA or PI address space, an assignment with a prefix longer than /24 can be made if the request can be satisfied with less than 256 addresses. Local IRs must make it clear to the user which type of address space is assigned. Clear contractual arrangements which specify the duration of the address space assignment are mandatory for every assignment of PA address space. Although not strictly required, it is strongly recommended that contractual arrangements are made when assigning PI space as well. ____________________________________________________ ripe-104++.txt Page 25 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ With respect to aggregation, the clear advantages of assigning PA space mandate that IRs recommend its use whenever possible. End users should therefore be advised to use PA space if it appears to be suf- ficient for their situation. The consequences of using PA or PI space must always be made clear to the end user. In particular, to be certain end users understand the consequences of using PA space, the assigning IR must give each user requesting PA space a warning similar to the follow- ing: Assignment of this address space is valid as long as the criteria for the original assignment are still met and only for the duration of the service agreement between yourself and ISP XXXX. ISP XXXX has the right to re-assign the address space to another user upon termination of the agreement or following an agreed period thereafter. If the address space assign- ment becomes invalid, you may have to re- configure the addresses of all equipment using this address space. The reconfigura- tion is only necessary if you continue to require global uniqueness of the addresses for that equipment. It is important to realize that some Internet services do not require globally unique addresses. For example, services that can be accessed through a NAT (network address translator) or through an application layer gate- way/firewall don't require the machines which access them to have globally unique addresses. Of course, the consequences of using PI space must also be made clear to the end user. This is accom- plished by giving each user requesting PI space a warning similar to the following: Assignment of this address space is valid as long as the criteria for the original assignment are met. Note that the assign- ment of PI address space does not imply that it will be routable on any part of the Internet. Users may have to pay a pre- mium for routing of PI addresses (as opposed to PA addresses). Eventually, it ____________________________________________________ ripe-104++.txt Page 26 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ may become impossible to get relatively small amounts of PI space routed on most of the Internet. We strongly suggest you contact any prospective service providers for information regarding the possibility and pricing of service when using PI addresses. The type of assigned address space must be regis- tered in the status attribute of the inetnum object in the RIPE database by the assigning IR. The pos- sible values of this attribute are ASSIGNED PA This is used for PA address space that has been assigned to an end user. ASSIGNED PI This is used for PI address space that has been assigned to an end user. Every new address space assignment must be marked as PA or PI in the RIPE database. Moreover, to improve registration of old assignments, IRs are encouraged to mark past assignments in the registry database with PA or PI as appropriate. Any assigned address space without an explicit type in the status attribute is assumed to be PI space. Priority should therefore be given to marking PA space as such. In general, local IRs are provided with ranges of PA space from which they can make assignments. If an end user requests address space of a type which an IR does not assign (typically PI), the IR must refer the end user to a registry which can fulfill the request. IRs that do not assign PI space must sup- port an IR that does provide this service. This includes aiding the end user in the preparation of a properly documented request and furnishing back- ground information to the assigning IR. Local IRs which do not normally assign large amounts of a particular type of address space do not need to hold an allocation of that type of address space. It can be acquired from the RIPE NCC as needed. In general, such assignments will not be aggregatable with other address space assigned by the local IR. ____________________________________________________ ripe-104++.txt Page 27 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ IRs have assigned address space in the past which is aggregated in practice but is not formally of type PA. Formally, address space is not of type PA unless there are contractual agreements regarding the assignment's termination. It is therefore recom- mended that IRs ask end users to release non-PA address space upon termination of service. Simi- larly, if an end user moves to a new IR to obtain Internet services, the new IR should encourage the user to release any non-PA address space they hold, and to request a new assignment (a process which the new IR should be more than happy to support). To minimize the use of non-PA space in the future, IRs should work to make contractual arrangements to con- vert aggregated address space to formal PA address space. 3.4.3. Multihomed Users An end user may have reason to obtain connectivity through more than one service provider. If so, it may be necessary to obtain address space assignments from more than one IR to support different parts of the user's network. In general, there is no problem with users acquiring address space and service from more than one IR. Such users are referred to as mul- tihomed. Because users can be multihomed, IRs must be espe- cially careful in reviewing address space requests, and the corresponding current address space usage described in Section (Current Assignment Space Usage). One must be sure that users are not acquir- ing multiple assignments for the same purpose from different IRs. Moreover, one must check that a sim- ilar address space request has not been refused by another IR for some valid reason. 3.4.4. Update the RIPE Database Registration of objects pertaining to an assignment in the RIPE database makes it possible to track the use of address space, facilitate operational con- tacts, and facilitate studies of address allocation. These activities are essential to effective mainte- nance of the Internet. Submission of objects to the database is the final step in making an assignment. This step makes the assignment definite, and makes public information regarding the assignment available to anyone seeking ____________________________________________________ ripe-104++.txt Page 28 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ it. Care should therefore be taken to assure the correctness of the assignment and of all relevant data prior to completing this step. The information collected about the user's organiza- tion in the Network Template (see Section (Database Information)), should be entered in an inetnum database object. The range of addresses assigned to the user is also entered in the inetnum object, and is specified in dotted quad notation. For example, if an organization is assigned a /22 address set for 1024 network addresses, the range will be something like: 193.1.192.0 - 193.1.195.255. And, as stated above, the status field of the inetnum object is used to specify whether the assigned addresses are PI or PA. In addition to the inetnum object, a person object must be submitted for each of the people specified in the tech-c and admin-c fields of the inetnum object. Assuming the assigning IR has properly stored infor- mation gathered in the assignment process for future reference, submission of the objects described above completes the assignment process. The IR can now provide the end user with the assigned address range and any other data relevant to its use. 3.5. Assignment Window It is essential that local IR staff follow the pro- cedures for address space assignments and apply the evaluation criteria used to determine assignment sizes as discussed above. The procedures are straightforward. The evaluation criteria however, can be difficult to apply to new situations. To assure the conservation, aggregation, and regis- tration goals are met, we must be sure the assign- ment criteria and procedures are properly applied. In general, this means that local IRs with little or no experience should receive maximal support in the assignment process, whereas local IRs with more experience should be allowed to make most assign- ments without consulting the RIPE NCC. Large assign- ments always require prior approval because of their impact on the available address space. To achieve this variation in support level, each local IR is given an assignment window by the RIPE NCC. The assignment window is the maximum number of ____________________________________________________ ripe-104++.txt Page 29 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ addresses that can be assigned by the local IR to an end user without prior approval by the RIPE NCC. The number of addresses is always expressed in /xx nota- tion, so a local IR with an assignment window of /23 is allowed to assign up to 512 addresses to an end user without prior approval of the RIPE NCC. As the local IR staff gain experience, the window size is increased. Every assignment of address space which is larger than the local IR's assignment window is invalid prior to explicit approval by the RIPE NCC. Without such approval, the address space should not be used to address hosts with Internet connectivity. Use of invalid address can result in a failure to meet the uniqueness requirement for Internet addresses. The assignment window is not only applied to indi- vidual assignments, but to multiple assignments to the same end user in a single year. If an local IR makes combined assignments to an organization in the course of a year, the total amount of address space assigned may not exceed the local IR's assignment window. Additional address space can only be assigned to that organization after approval by the RIPE NCC. In general the assignment window for new registries is 0. This means that every assignment requires prior approval by the RIPE NCC before becoming effective. This ensures that the local IR staff become familiar with the evaluation criteria and assignment procedures described in this document. As the local IR staff become familiar with assign- ment procedures, the assignment window can be raised. In general, it will be raised to /24 the first time, which means the local IR staff can make assignments for up to 256 addresses. If the RIPE NCC receives a request to raise the assignment win- dow for a local IR, it will be evaluated based on the proficiency of the local IR staff. This is determined based on whether assignment documentation presented to the RIPE NCC is correctly completed, whether good judgement is shown in the evaluation of address space requests, whether past assignments have been properly registered, and on the experience of the local IR with handling larger assignments. Currently, the maximum size of the assignment window for any local IR is 4096 addresses (/20). This means that every assignment for more than this requires approval of the RIPE NCC. ____________________________________________________ ripe-104++.txt Page 30 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ Sometimes new registration staff at a well estab- lished local IR make errors both in judgement and procedure before they are properly trained to make assignments. If such errors are noticed by the RIPE NCC, the assignment window for the local IR may be decreased to prevent the staff from making erroneous assignments involving a substantial amount of address space. As the new staff members receive training, and the proficiency level is again up to par, the assignment window can be increased just as it would be for a new local IR. ____________________________________________________ ripe-104++.txt Page 31 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 4. Rules and Guidelines for Allocations In the previous section, we described the procedures for handling requests for address space, including the selection of a set of addresses for an end user. In completing the assignment, address space is selected from a range that has been allocated to the local IR for this purpose. Of course, before a local IR can select addresses to fulfill a request, it must have a range of address space to choose from. (If the local IR does not have sufficient address space of the type to be assigned, then a request can be submitted to the RIPE NCC.) To meet this need, a range of addresses is made available to a local IR by the RIPE NCC. Such an address range is referred to as an allocation. In Europe, the RIPE NCC is the only IR permitted to allocate address space. A local IR is not allowed to re-allocate part of its allocation to any other organization. Moreover, without prior approval by the NCC, local IRs are not permitted to exchange allocated address space among themselves. In some cases, a local IR acts as a transit provider for an IP service provider which itself is not a local IR. If a local IR allows another IP service provider to make an assignment from its allocated address space, the local IR is still responsible to guarantee the assignment is made according to the guidelines specified in this document. If at some point, an IP service provider decides to become a local IR rather than using an existing local IR to obtain address space, then all subse- quent assignments it makes should be from address space allocated directly to it from the RIPE NCC. Furthermore, address space already assigned by the IP provider from transit providers' allocations should be returned to the transit provider, and new assignments should be made to the end users from the new allocation. In this section, we describe how a local IR can obtain an allocation and how allocated address space should be managed. 4.1. Slow Start of Allocations To prevent allocating large blocks of address space that won't be assigned, the RIPE NCC has introduced the concept of a slow start for allocations. The ____________________________________________________ ripe-104++.txt Page 32 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ idea is to allocate address space to local IRs at the rate it will be assigned. The minimum allocation is /19 (8192 addresses). The maximum size of an individual allocation is /16 (65536 addresses). The size of allocations is based solely on the rate that previously allocated address space has been assigned to end users. It will be increased or decreased depending on the rate at which a local IR assigns its space. The slow start mechanism implements a consistent and fair policy for every local IR with respect to allo- cations. Although the mechanism is similar to the assignment window mechanism described in the previ- ous section, the policy it implements is different. The size of further allocations depends exclusively on the assignment rate of the local IR concerned while the assignment window depends on the demon- strated proficiency of the registry staff in evalu- ating requests and processing assignments. 4.2. First Allocation When a new local IR starts up, it has no address space allocated to it. The first allocation will be made automatically by the RIPE NCC, generally upon receipt of the first assignment request from the local IR. Because there is no information about the rate at which a new IR will make address assign- ments, the size of the first allocation is always set at the minimum. Remember that the amount of space allocated does not determine the size of assignments a local IR can make. As discussed at the end of the previous sec- tion, a new local IR must have every assignment approved by the RIPE NCC until its assignment window is increased. 4.3. Further Allocations A local IR can obtain additional allocations as required. A request should be submitted to the RIPE NCC when the currently allocated address space is nearly used up, or if a single request requires a larger block of addresses than can be satisfied with the currently allocated address space. To obtain a new allocation, a local IR should submit a request to the RIPE NCC which includes a complete list of the assignments made from all of their allocations. The RIPE NCC will check this information, compare it ____________________________________________________ ripe-104++.txt Page 33 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ with assignments registered in the database and may request further information to determine the need for a new allocation. Additional address space will be allocated after the information delivered with the request has been verified, and a new allocation has been deemed necessary. Unfortunately, there is a tradeoff between the aggregation and conservation goals in making alloca- tions. To further aggregation, the RIPE NCC aims to allocate contiguous address ranges to a local IR. However, because conservation of address space must also be taken into account, this is not always pos- sible. A new allocation to a registry can therefore not be expected to be contiguous with past alloca- tions. While the RIPE NCC always aims to further the aggregation goal, and therefore to allocate contigu- ous space, the RIPE policy is that under no circum- stances are multiple allocations made to the same local IR guaranteed to be contiguous. 4.4. Allocation Registration Allocations are registered in the RIPE Database by the NCC using inetnum objects. Information about the local IR, which is similar to that for an end user receiving an assignment is stored together with the range of allocated address space and its type. The range of addresses is stored in the inetnum field in dotted quad notation, and the type is stored in the status field and can have one of the following values: ALLOCATED PA This address space has been allocated to an IR, and all assignments made from it are provider aggregatable. This is the most common alloca- tion type for local IRs. ALLOCATED PI This address space has been allocated to an IR, and all assignments made from it are provider independent. ALLOCATED UNSPECIFIED This address space has been allocated to an IR, and assignments made from it may be either provider aggregatable or provider independent. ____________________________________________________ ripe-104++.txt Page 34 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ This type of allocation is obsolete, and will not be applied to future allocations. Some older allocations have been used for both PA and PI assignments, and as such receive this allocation type. These objects are maintained by the RIPE NCC. When hierarchical authorization is implemented, autho- rization can be implemented for creation of inetnum objects "under" the allocation objects. ____________________________________________________ ripe-104++.txt Page 35