- lir-wg - mailman.ripe.net

web interface for ripe-141 form
by Naeem malik 26 Oct '98

26 Oct '98

Dear Local IRs, During the LIR WG meeting at RIPE 31 in Edinburgh we discussed various possibilities to implement a web interface for the IP request form. We would like to further discuss this on the mailing list. Note that we distinguish here between 'syntax checks' which merely make sure the submitted form is sensible, and 'full checks' which check the data it contains. As a first step we propose to implement a public web page based at the RIPE NCC that LIRs can use to check the syntax of their IP request forms. The output will be a detailed error report or a request form suitable for pasting into an email. This would enable LIRs to check the syntax of a request before sending it to RIPE NCC, or a LIR customer to check the syntax of a form before sending it to the LIR. <copied from original text> I for one think it is a good idea. If anybody is interested, take a look at APNIC's equivalent web form at http://www.apnic.net/reg.html which would serve as a useful start and could be improved on. This could also be extended to submitting the network object, as it is a bit laborious at the moment. Another example if you'd like a look is available from the Cable & Wireless (used to be MCI) web pages (SWIP updates) http://infopage.cw.net/Address/swip.html I think this would be a useful development and would suggest that you endeavour to proceed with it. For those who LIR's who have not got a web form for their customers, I suggest taking a look at http://services.concert.net/address-space/request.html. Note this page has been designed for all the registries, RIPE/APNIC/ARIN and is used by our customers many times during the day. Com on guys, lets move into the 20th century. Regards, Naeem Malik

1 0

RE: web interface for ripe-141 form
by De Groote, Patrick 23 Oct '98

23 Oct '98

A syntax-checking web page would be valuable indeed. The registration of networks is not my primary job-description, but comes with the job. I therefore spend a lot of time getting the syntax right, due to the fact that it does not happen every day (or every week) that I need to fill out a ripe-141. Having the customer check out the syntax before he submits would be of equal, if not larger value. rgds Patrick Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer >-----Original Message----- >From: Paula Caslav [SMTP:Paula.Caslav@ripe.net] >Sent: Thursday, October 22, 1998 5:50 PM >To: local-ir(a)ripe.net >Cc: lir-wg(a)ripe.net >Subject: web interface for ripe-141 form > > >Dear Local IRs, > >During the LIR WG meeting at RIPE 31 in Edinburgh we discussed various >possibilities to implement a web interface for the IP request form. >We would like to further discuss this on the mailing list. > >Note that we distinguish here between 'syntax checks' which merely >make sure the submitted form is sensible, and 'full checks' which >check the data it contains. > >As a first step we propose to implement a public web page based at the >RIPE NCC that LIRs can use to check the syntax of their IP request >forms. The output will be a detailed error report or a request form >suitable for pasting into an email. > >This would enable LIRs to check the syntax of a request before sending >it to RIPE NCC, or a LIR customer to check the syntax of a form before >sending it to the LIR. > >A next step would a web page based at the LIR's server that LIRs can >use to check the syntax of their IP request forms. The output will be >a detailed error report or an IP request form suitable for pasting >into an email. The source code will be available to allow the LIR to >make this available to their customers, with hooks so additional >comments and local-language labels can be easily added or so the >result can be automatically sent by the program in an email. At this >phase, support would be limited initially. > >The last step would be a web page based at the RIPE NCC that will >allow LIRs *only* ( controlled by password) to submit an IP request >form. > >This would mean: > >- Requests within the LIR's assignment window will be fully checked but > will *not* create a ticket and will *not* be forwarded to a RIPE NCC > hostmaster for further processing. > >- Requests outside the LIR's assignment window will be fully checked. > A new ticket will be created and all submissions of the form will be > added to the ticket. This ticket will be forwarded to a RIPE NCC > hostmaster on passing all the checks, or exceeding the number of > checks limit. > > >If you have any suggestions or comments, please let us know. > > >Kind Regards, > >Maldwyn Morris > >P.S. I am sending this mail to both the local-ir list and the lir-wg >list, to make sure that everybody is aware of this discussion. However >the discussion itself should take place on the lir-wg mailing list. If >you are not subscribed to that list but wish to follow this discussion, >please send a mail to majordomo(a)ripe.net with HELP in the body. You can >also follow the discussion in the archives on our web site.- Paula >Caslav >

2 1

RE: web interface for ripe-141 form
by Laurent BERNARD 23 Oct '98

23 Oct '98

'couldn't say it more accurately. Thanks. Best regards. ---------------------------------------------------- A syntax-checking web page would be valuable indeed. The registration of networks is not my primary job-description, but comes with the job. I therefore spend a lot of time getting the syntax right, due to the fact that it does not happen every day (or every week) that I need to fill out a ripe-141. Having the customer check out the syntax before he submits would be of equal, if not larger value. rgds Patrick Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer >-----Original Message----- >From: Paula Caslav [SMTP:Paula.Caslav@ripe.net] >Sent: Thursday, October 22, 1998 5:50 PM >To: local-ir(a)ripe.net >Cc: lir-wg(a)ripe.net >Subject: web interface for ripe-141 form > > >Dear Local IRs, > >During the LIR WG meeting at RIPE 31 in Edinburgh we discussed various >possibilities to implement a web interface for the IP request form. >We would like to further discuss this on the mailing list. > >Note that we distinguish here between 'syntax checks' which merely >make sure the submitted form is sensible, and 'full checks' which >check the data it contains. > >As a first step we propose to implement a public web page based at the >RIPE NCC that LIRs can use to check the syntax of their IP request >forms. The output will be a detailed error report or a request form >suitable for pasting into an email. > >This would enable LIRs to check the syntax of a request before sending >it to RIPE NCC, or a LIR customer to check the syntax of a form before >sending it to the LIR. > >A next step would a web page based at the LIR's server that LIRs can >use to check the syntax of their IP request forms. The output will be >a detailed error report or an IP request form suitable for pasting >into an email. The source code will be available to allow the LIR to >make this available to their customers, with hooks so additional >comments and local-language labels can be easily added or so the >result can be automatically sent by the program in an email. At this >phase, support would be limited initially. > >The last step would be a web page based at the RIPE NCC that will >allow LIRs *only* ( controlled by password) to submit an IP request >form. > >This would mean: > >- Requests within the LIR's assignment window will be fully checked but > will *not* create a ticket and will *not* be forwarded to a RIPE NCC > hostmaster for further processing. > >- Requests outside the LIR's assignment window will be fully checked. > A new ticket will be created and all submissions of the form will be > added to the ticket. This ticket will be forwarded to a RIPE NCC > hostmaster on passing all the checks, or exceeding the number of > checks limit. > > >If you have any suggestions or comments, please let us know. > > >Kind Regards, > >Maldwyn Morris > >P.S. I am sending this mail to both the local-ir list and the lir-wg >list, to make sure that everybody is aware of this discussion. However >the discussion itself should take place on the lir-wg mailing list. If >you are not subscribed to that list but wish to follow this discussion, >please send a mail to majordomo(a)ripe.net with HELP in the body. You can >also follow the discussion in the archives on our web site.- Paula >Caslav > Laurent BERNARD "Not knowing it couldn't be done, he went ahead and did it"

1 0

web interface for ripe-141 form
by Paula Caslav 23 Oct '98

23 Oct '98

Dear Local IRs, During the LIR WG meeting at RIPE 31 in Edinburgh we discussed various possibilities to implement a web interface for the IP request form. We would like to further discuss this on the mailing list. Note that we distinguish here between 'syntax checks' which merely make sure the submitted form is sensible, and 'full checks' which check the data it contains. As a first step we propose to implement a public web page based at the RIPE NCC that LIRs can use to check the syntax of their IP request forms. The output will be a detailed error report or a request form suitable for pasting into an email. This would enable LIRs to check the syntax of a request before sending it to RIPE NCC, or a LIR customer to check the syntax of a form before sending it to the LIR. A next step would a web page based at the LIR's server that LIRs can use to check the syntax of their IP request forms. The output will be a detailed error report or an IP request form suitable for pasting into an email. The source code will be available to allow the LIR to make this available to their customers, with hooks so additional comments and local-language labels can be easily added or so the result can be automatically sent by the program in an email. At this phase, support would be limited initially. The last step would be a web page based at the RIPE NCC that will allow LIRs *only* ( controlled by password) to submit an IP request form. This would mean: - Requests within the LIR's assignment window will be fully checked but will *not* create a ticket and will *not* be forwarded to a RIPE NCC hostmaster for further processing. - Requests outside the LIR's assignment window will be fully checked. A new ticket will be created and all submissions of the form will be added to the ticket. This ticket will be forwarded to a RIPE NCC hostmaster on passing all the checks, or exceeding the number of checks limit. If you have any suggestions or comments, please let us know. Kind Regards, Maldwyn Morris P.S. I am sending this mail to both the local-ir list and the lir-wg list, to make sure that everybody is aware of this discussion. However the discussion itself should take place on the lir-wg mailing list. If you are not subscribed to that list but wish to follow this discussion, please send a mail to majordomo(a)ripe.net with HELP in the body. You can also follow the discussion in the archives on our web site.- Paula Caslav

4 3

Initial Allocation Policy
by Daniel Karrenberg 14 Oct '98

14 Oct '98

Background ---------- The advisory council of ARIN asked ARIN to consider changing the current allcation policy. The initial allocation to a new LIR/ISP should be reduced from a /19 to a /20. The reason being that this would make it easier for new ARIN customers to receive an allocation directly from ARIN rather than from their up-stream provider. According to ARIN's local allocation policy they would then need to justify the utilisation of only a /21 instead of a /20 previously allocated to them by their upstream provider. Another motivation is to improve conservation of address space by reducing the amount of unused addresses in initial allocations. The new policy would not increase the load on the global routing, because the same amount of allocations would still be given out, just one longer prefix. Before deciding on this proposal ARIN has asked the other regional registries (APNIC and RIPE NCC) to also consider this change. Considerations -------------- Based on the RIPE NCC allocation data starting in 1992 we investigated how much impact the proposed change would have on the conservation of address space. We determined how many LIRs in our service region had not used more than a /20 from their initial /19 allocation within one year. The results are as follows: Of 1410 LIRs checked 304 (22%) had assigned not more than a /20 during the first 12 months of operations. This means that 78% of the LIRs had used more than a /20 within one year. The total amount of allocated but, after one year, not yet assigned address space was equivalent to 19 /16s. Some of the LIRs which did not have assigned more than a /20 after one year have since become inactive and the address space concerned will not be assigned in the foreseeable future. However 272 of the 304 are still operational and it is likely that most of them will assign more address space in the future. Further investigations showed that about 50% of those LIRs who haven't used more than a /20 appear to be multihomed. Conclusions ----------- These results have been presented to the LIR WG at the 31. RIPE Meeting in Edinburgh. The LIR WG is the body defining local address space policy for the RIPE NCC. The LIR WG didn't feel that this is a reason to change the current allocation policy. The benefits for conservation are not significant. However, the consequences for aggregation are likely to be noticeable if 80% of LIRs require a second allocation within a year. Furthermore the LIR WG expressed concerns about the routability of longer pefixes in the light of current prefix-length dependent filtering and flap dampening policies. Under the current circumstances the LIR WG did not see a valid reason to change the current allocation policy. We ask the ARIN membership to take this into consideration and consider other ways of achieving the aims of the proposed change.

1 0

/20 Initial Allocations
by Daniel Karrenberg 14 Oct '98

14 Oct '98

1 0

ripe-159 changes
by Paula Caslav 22 Sep '98

22 Sep '98

Hello all, At the last RIPE Meeting we were asked to make a change in the policy on allocations (that an allocation only needs to be 80% used up instead of 90% before receiving a new one). After discussing it with the other Regional Registries, we have decided to go ahead with this change. This means that the Policies and Procedures document (currently ripe-159) needs to be updated. At the same time I've taken the opportunity to also include a few new sections in the document on practices that are already in place and should be mentioned. Below I've included all the new/changed sections. (Though there's also a few minor changes, mainly in documents/rfcs that have changed) Please send us any comments you may have, before we publish the final document. By the way, there was a discussion on this list and the database working group mailing list a few weeks about version numbers of RIPE documents. As a result of that we've decided to start referencing RIPE documents by their titles and not their numbers on the web site and in other documents. The documents will still have a ripe-xxx number, so that you can see what the latest version is, but all references will be to the title instead of the number. Therefore, ripe-159 will changed to ripe-185, but the web site link will be to the document title once it's officially published. Kind regards, Paula Caslav Registration Services Manager RIPE NCC Here is the list of major changes: Changed section 4.3 Further Allocations as decided at RIPE meeting: > 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 their last alloca- > tion, (however the RIPE NCC will check all the pre- > vious allocations for 80% usage as well). Changed section 6.2 Establishing a New Registry (shortened it and mainly pointed to ripe-160 so that the procedure is only documented in one place and changes can be made more easily). > 6.2. Establishing a New Registry > > A local IR is established after submitting a request > to the RIPE NCC which includes assurances that the > relevant rules and guidelines defined in this and > related documents are known and a commitment that > they will be followed. The process of setting up a > new registry is explained in detail in "Guidelines > for Setting up a Local Internet Registry" (currently > ripe-160 [Caslav98a]). Added under section 6.4 Registry Operations: > External Quality Assurance > > In order to promote consistent and fair application > of assignment criteria with regard to conservation > and registration of address space and aggregation of > routing information, the RIPE NCC has started an > activity of consistency checking of registry data > and auditing of registries. To ensure that reg- > istries are following the assignment criteria, and > entering assignments into the database correctly, > the RIPE NCC may contact a registry to ask for docu- > mentation or more information about certain requests > or database entries. If the NCC finds problems, it > will work with the registry to correct these, and > may take disciplinary action, such as lowering the > registry's Assignment Window. This activity is > described in-depth in "RIPE NCC Consistency & Audit- > ing Activity" (currently ripe-170 [Caslav97a]). Added under same section: > Distribution Robot > > The RIPE NCC uses an automatic robot to distribute > all messages sent to <hostmaster(a)ripe.net> and to do > syntax checking on IP address space requests. For > help on interacting with the robot, please see the > RIPE NCC web site at: > > http://www.ripe.net/lir/services/status.html Added new section 6.5 (that allocations can't be transfered without RIPE NCC permission is already mentioned elsewhere, but I wanted a separate section to specifically point this out- we've had a few cases lately of registries changing owners without telling us): > 6.5. When a Registry Changes Ownership > > If a Local Internet Registry changes ownership > (because it is sold, or merges with another com- > pany), the RIPE NCC should be contacted about the > change in ownership. Depending on the case, the RIPE > NCC may need to request a new service agreement from > the new owners. Also, if all of the contact persons > who will be sending requests have changed, the NCC > may lower the assignment window of the registry > until the new contacts are up-to-date on the RIPE > NCC procedures and policies. > > Sometimes a registry is taken over or merged with > another, already existing registry. The RIPE NCC > needs to be notified in this case as well. The reg- > istries in question will need to discuss with the > NCC what will be done with the allocations in case > one of the registries is closing. An allocation can- > not be transfered from one registry to another (or > to a non-registry) without contacting the RIPE NCC > first. A registry cannot have more than one "open" > (less than 80% used up) allocation, so sometimes > transfering all allocations is not possible. Please > discuss these issues with <hostmaster(a)ripe.net>. And here is the entire document itself. European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group Document ID: ripe-185 Date Published: July 23, 1998 Obsoletes: ripe-104, ripe-105, ripe-136, ripe-140, ripe-159 ABSTRACT The distribution of IP address space follows the hierarchical scheme described in (RFC 1466 [Gerich93a]). For Europe and parts of the surrounding area address space is allocated by IANA to the RIPE NCC which acts as a regional Internet reg- istry. Address space is allocated by the RIPE NCC to Local Internet Registries (IRs), who assign it to to end users. In this document, we describe the policies and procedures associated with address space management that must be followed by local IRs. Moreover, we present a number of services available to local IRs to sim- plify the tasks associated 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 ____________________________________________________ ripe-185.txt Page 1 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ European guidelines. While providing an overview about the global Internet registry system this docu- ment does not describe allocation and assignment rules used by other regional registries. This document has been produced by the RIPE Local Internet Registry (LIR) Working Group with the help of an editing committee consisting of: P. Caslav RIPE NCC S. Dolderer DE NIC D. Karrenberg RIPE NCC M. Kuehne RIPE NCC M. Norris HEANET C. Orange RIPE NCC W. Woeber ACONET J. Zsako Banknet H.P. Holen Schibsted Nett 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. Section 3 (Address Space Assignment Procedures) describes the procedures to be followed by European IP registries 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 ____________________________________________________ ripe-185.txt Page 2 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ delegation, and explains how registries can manage subsidiary reverse delegation of assigned address space. Section 6 (Operating a Local Internet Registry) describes a number of services offered by the RIPE NCC to facilitate the uniform implementation of the policies outlined in this document, and outlines procedures associated with IP registration services which Local IRs are expected to follow. Section 7 (AS Number Assignment Policies and Proce- dures) explains the procedures to be followed by European IP registries when requesting an autonomous system number. Section 8 (Interdomain (Exterior) Routing Considera- tions) discusses interdomain routing issues (such as originating routing information; propagating routing announcements; aggregation and registering routes in the database) and their role in defining the poli- cies regarding address space distribution described in this document. We conclude with a glossary in which the key terms used in this document are defined. ____________________________________________________ ripe-185.txt Page 3 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 in Section 2.2. The main purpose of this address space is to allow communication using IPv4 over the Internet. A secondary purpose is to allow communication using IPv4 over interconnected private internets. One can currently distin- guish two kinds of public addresses: provider independent (PI) and provider aggregatable (PA) addresses; see Section 2.4 for more details. More information about PI and PA address space can also be found in (ripe-127 [ Karren- berg95a]). 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 (RFC 1918 [Rekhter96b]. Special and Reserved Addresses There are a number of address ranges reserved for applications like multicasting. These are described elsewhere (cf RFC 1112 [Deering89a]) and are beyond the scope of this document. ____________________________________________________ ripe-185.txt Page 4 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 guaran- tees that every host on the Internet can be uniquely identified. In addition to the uniqueness requirement, pub- lic 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 these goals are pursued. It is worth noting that "Conservation" and "Aggregation" are often conflicting goals, and therefore that each ____________________________________________________ ripe-185.txt Page 5 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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-185.txt Page 6 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 2.3. The Internet Registry System The Internet Registry system has been established to achieve the goals stated in Section 2.2. It con- sists of hierarchically organized Internet Reg- istries (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 organi- zations 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 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 ARIN serving North America, the APNIC serving the Asian Pacific region, and the RIPE NCC serving Europe and surrounding areas. Since these do not cover all geographical 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-185.txt Page 7 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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-185.txt Page 8 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ The European IR System For Europe, the Internet Registry System hierarchy consists of the following entities (from the top down): IANA, the RIPE NCC, and Local IRs. 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 a new address space assign- ment, and return the previously assigned address space. To ensure the address space is properly returned, a clear, preferably contractual, under- standing is needed between the Local IR 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. Provider Independent Address Space In contrast to PA address space, PI address space can remain assigned to its user as long as the ____________________________________________________ ripe-185.txt Page 9 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ criteria for the original assignment are met. The duration 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- ment is made for a specific purpose and the purpose no longer exists, then the assignment is no longer valid. If an assignment is based on information that turns out to be invalid so is the assignment. ____________________________________________________ ripe-185.txt Page 10 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 current address space usage template and in the addressing plan as described in the next section. The amount of address space assigned must be justified by this documenta- tion. This means that address space assigned in the past should be used to meet the current request if possible. Once an organisation has used its assigned address space, it can request additional address space based on an updated estimate of growth in its network. ____________________________________________________ ripe-185.txt Page 11 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 3.2. Documentation To make appropriate assignment decisions, informa- tion must be gathered about the organisation, addressing requirements, network infrastructure, current address space usage, and future plans of the end user requesting address space. This information is essential to the assignment process, and is for- mally required by the IR's. In some cases additional information might be needed to make the assignment decision. 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 "European IP Address Space Request Form" (currently ripe-141: [Caslav96a]) in english. A separate request form must be submitted for each customer. It must be clear to which end-user the address space will be assigned. General requests for customers A, B, C (for example) are not accepted. The information gathered in the assignment process must be maintained permanently by the Local IR mak- ing the assignment, and must be made available to the regional registry immediately upon request. The Local IR is responsible for protecting the end user's privacy. Aside from the data specified in Section 3.2.1.5, which is published in the registry database, the information gathered must be kept in strict confidence. The Local IR is not authorised to provide the information to anyone not represent- ing IANA or a regional registry, unless explicitly requested to do so by the end-user. 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 ____________________________________________________ ripe-185.txt Page 12 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 3.2.1.2, all information refers to the currently requested address space. 3.2.1.1. Overview of Organisation To properly assess the user's address space require- ments, it is essential to understand the structure of the organisation to which the addresses are being assigned, and which part of the organisation 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, specialise 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 sub-departments 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 organisation 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 organisation 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 organisation. 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 organisation, and the requester's role therein is known. It is therefore important that a brief overview of the organisational structure be pro- vided. This should include details of the parent company, subsidiaries and contact persons. ____________________________________________________ ripe-185.txt Page 13 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ In the case of our bicycle manufacturer, one would expect someone representing the Chain department to produce general information about the structure of the organisation 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 department, such as who manages the office in Rome. Clearly, the assignment process is greatly simpli- fied if an organisation coordinates its address space management, and if all requests are made by a single body representing the entire organisation. Contact Persons To facilitate handling the request, contact informa- tion is required for the person making the request and for someone at the organisation 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, organisation, country, phone, fax-no, and e- mail fields. In each template, the appropriate per- son's name should be specified in full. The organi- sation 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. ____________________________________________________ ripe-185.txt Page 14 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ Each set of addresses already assigned to the organ- isation 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. Each row in the table below contains an entry for a subnet in the end user's organisation. Addresses Used Prefix Subnet Mask Size Current 1yr 2yr Description 193.1.193.0 255.255.255.192 64 28 34 50 Derailer LAN 193.1.193.64 255.255.255.224 32 10 12 25 Chain (dynamic dial-up) 193.1.193.96 255.255.255.224 32 8 13 27 Front Fork LAN 193.1.193.128 255.255.255.128 128 57 100 114 Main Office (routers, servers, & office LAN) 193.1.194.0 255.255.255.0 256 132 170 210 Frame LAN 193.1.195.0 255.255.254.0 512 317 350 380 Assembly LAN & dynamic dial-up) 1024 549 679 806 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 organisation. Please avoid vague descriptons such as "Location 1", "Location 2") In our example, we have descriptions correspond- ing to various bike parts. Together with the size information, this provides significant insight as to the network structure in the organisation. 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 numbers in these fields should be cumulative amounts showing the total number of addresses used. (ie if the front fork subnet is using 8 addresses immediately and plan to add an additional 5 in year 1, then addresses-year-1 field should show the total ____________________________________________________ ripe-185.txt Page 15 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ of 13 addresses.) 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 table for assigned address space which is currently not used. 3.2.1.3. Request Overview The request 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 Classless Inter-Domain Routing, the user would have asked for two Class C networks. Because classless addressing is now used, the size of the request may be less than 256 or fall between the class borders (e.g. 32, 288, 384). More informa- tion on CIDR can be obtained in (RFC 1519 [Fuller93a]) and (RFC 1518 [Rekhter93a]). 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. 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 ____________________________________________________ ripe-185.txt Page 16 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ network addresses will be used immediately following the assignment, within 12 months, and within 24 months, respectively. As with the current usage tem- plate, the numbers in these fields should show the total number of addresses requested in each time period, and not only the newly added addresses. They also should show the actual amount of addresses needed based on concrete technnical plans. Number of Subnets: In practice, the end user will want to employ the requested addresses in one or more subnets in an organisation. 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 imple- mented 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, ____________________________________________________ ripe-185.txt Page 17 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 organisation 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 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. PI address space usually does not come out of an LIR's allocation, but will be assigned by the RIPE NCC from a separate range. Address Space Returned: If the user is returning address space in exchange for a new assignment, the RIPE NCC needs to be notified. The information should be specified in the address-space-returned field in the network overview form. The range to be returned, the date of return and the registry or ISP to whom the addresses will be returned should be specified. 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. ____________________________________________________ ripe-185.txt Page 18 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ Relative Addresses Used Prefix# Subnet Mask Size Immediate 1yr 2yr Description 0.0.0.0 255.255.255.192 64 8 16 60 Systems Group (back-bone, dynamic dial-up) 0.0.0.64 255.255.255.224 32 17 22 26 Engineering LAN 0.0.0.96 255.255.255.224 32 12 17 20 Manufacturing LAN 0.0.0.128 255.255.255.224 32 10 15 27 Sales LAN 0.0.0.160 255.255.255.240 16 5 9 12 Management LAN 0.0.0.176 255.255.255.240 16 7 8 13 Finance LAN 192 59 87 158 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. The numbers in these fields should be cumulative amounts showing the total number of addresses used in each period. 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 minimise padding in the address space. In the example above, we 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. Docu- mentation 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. Usually in cases where large amounts of address space are ____________________________________________________ ripe-185.txt Page 19 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ wasted due to classfull addressing, the request will not be granted. 3.2.1.5. Database Information For registration purposes, information is required about the organisation needing address space. Infor- mation is also required about the persons involved in the request and administration of the addresses. Some of the information may be redundant because the same person can play multiple roles. However, every role can be filled by someone different, 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 pub- licly accessible. Every assignment and every indi- vidual customer needs to be registered in the database separately. More information on the RIPE NCC database can be obtained at (ripe-157 [Magee97a]). Organisation: Some information about the organisa- tion that will be using the addresses must be sup- plied for maintenance of the RIPE database. The Net- work Template is supplied for this purpose. There is an inetnum field which can be left blank in the request and will be used for entering the IP address numbers into the database. 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 organisa- tion that will use the assigned addresses is needed. The information is specified using one or more descr fields in the Network Template. If, for example, the assigned addresses will be used by the Depart- ment of Neural Surgery at Catatonic State Univer- sity, 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 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 person does not have to have technical knowledge of the network. The technical person ____________________________________________________ ripe-185.txt Page 20 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ specified in the tech-c field may be a network sup- port person located on site, but could also be a consultant that maintains the network for the organ- isation. In both cases, more than one person can be specified. The tech-c field can reference a role object instead of a person object. 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. See ripe-157 [Magee97a] for more information on how to obtain a NIC handle. If the person already has a NIC handle and person object in the ARIN database, they can use that same NIC handle in the RIPE database. The type of assigned address space must be regis- tered in the status attribute of the inetnum object as either "ASSIGNED PA" or "ASSIGNED PI". For security purposes, a notify field can be filled out with an e-mail address to be notified when changes are made to the database object and a mnt-by field can reference a maintainer object which desig- nates who can make changes to the object. 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. As with the network template, a notify field can be filled out with an e-mail address to be notified when changes are made to the database object and a mnt-by field can reference a maintainer object which designates who can make changes to the object. ____________________________________________________ ripe-185.txt Page 21 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 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 4,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 according to the user's plans. Topological Map: The old saying "a picture is worth a thousand words" certainly holds in the case of networks. If a topological map of the current and planned network infrastructure in the requesting organisation 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. The map can be sent as a postscript document or it can be faxed. Please include the ticket number (see sec- tion 6.3) of the request on the fax. 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 ____________________________________________________ ripe-185.txt Page 22 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 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. A registry should always evaluate a request filled out by an end-user before making an assignment or sending it to the RIPE NCC for approval. Given the above documentation, one must determine whether 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 contribute to the conservation of address space. Meanwhile, 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. ____________________________________________________ ripe-185.txt Page 23 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 utilisation rates, that is address space requested in relation to that to be used. Unless there are special circumstances, imme- diate utilisation should be at least 25% of the assigned address space, and the utilisation 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 established 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. 4. Very Small Enterprises (VSE's): An end user with a small number of hosts (currently <24) is referred to as a very small enterprise (VSE) regardless of the size of the organisation. 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. All assignments made to VSE's need to be registered in the database individually. VSEs that do not intend to connect to the Internet should not be assigned public address space but rather should be advised to use private address space. This is espe- cially the case for VSEs that request PI space so they can easily arrange connectivity at a later date. These enterprises should be advised that for VSEs in general, the effort required to renumber at a later date is 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 ____________________________________________________ ripe-185.txt Page 24 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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. 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 avail- able free pool of IPv4 address space, the use of static IP address assignments (e.g., one address per customer) 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. Organisations 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 verification procedures 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 inter- face and physical network. Often this is used to circumvent shortcomings in higher level protocols such as HTTP. Large scale assignments for this pur- pose are discouraged for the reasons mentioned in the paragraph above. The RIPE NCC currently assigns address space for virtual WWW servers on the condi- tion that it be returned or used for another purpose when a version of HTTP which transmits the host part of a URL is widely deployed. If allocations or assignments for this purpose are indeed made, spe- cial allocation and verification procedures apply. Please contact the RIPE NCC for details. ____________________________________________________ ripe-185.txt Page 25 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 some amount of address space, 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 allo- cated space. Specifically, each set of address space assigned should start on a CIDR (bit) bound- ary. This means the start address for each range of addresses to be assigned must be divisible by the size of the range. This helps to achieve the aggre- gation goal in address space assignments. Suppose a request can be satisfied with either a number of small chunks of address space or with a single 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. In accordance with the conservation goal, Local IRs are encouraged to assign multiple ranges of addresses in such cases, rather than a single large range. 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 ____________________________________________________ ripe-185.txt Page 26 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ Section 3.6. If the addresses are to be assigned from a range which has not allocated to the Local IR, the selec- tion will be made by the IR to which the address space has been allocated. In general, this will be the regional registry. 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. 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 sure that 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 ____________________________________________________ ripe-185.txt Page 27 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 realise 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 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 ____________________________________________________ ripe-185.txt Page 28 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 (usually the RIPE NCC Regional Registry). If a Local IR wants to assist one of its customers in obtaining an assignment of address space for which it does not hold an allocation, it should sup- port an IR that does provide this service. This includes aiding the end user in the preparation of a properly documented request and in furnishing back- ground information to the assigning IR as required. The Local IR can of course refer the user to a Local IR which is able to make the assignment. Local IRs which do not normally assign large amounts of a given type of address space (again typically PI) need not hold an allocation to handle address space requests. The address space can be acquired from the RIPE NCC as needed. In general, such assignments are not aggregatable. 3.5. Replacing IP Addresses Much of the address space assigned in the past is aggregated in practice but formally is not of type PA. Formally, address space is not of type PA unless there are contractual agreements regarding the assignment's purpose and term of validity. It is therefore recommended that Local IRs ask end users to release non-PA address space upon termination of service. Similarly, if an end user moves to a new Local IR to obtain Internet services, the new Local IR should encourage the user to release any non-PA address space they hold, and to request a new assignment (a process with which the new Local IR should be more than happy to help). To minimise the use of non-PA space in the future, IRs should work to make contractual arrangements to formally convert non-aggregated address space to PA address space. While the procedures for numbering and renumbering hosts in an IP network are becoming less trouble- some, asking or forcing end users to renumber is sometimes problematic. The renumbering process ____________________________________________________ ripe-185.txt Page 29 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ usually requires a considerable amount of time and effort both on the part of the end users and on the part of the ISPs and Local IRs involved. In some cases, there is a clear obligation to replace address space assignments, and Local IRs should be prepared to support their customers in the process. A more general and very important case is the (vol- untary) replacement of PI address space which for historical reasons has been randomly assigned and cannot be aggregated with other PA assignments. Such replacements can play a key role in containing the growth of routing tables, and thus for the main- tainability of the Internet as a whole. Because the renumbering process is nontrivial, the Internet Reg- istry System as a whole must support the process as far as possible. During the period in which end users migrate indi- vidual services or parts of their networks to the new address space, complications may arise. In many cases, they may need to be connected to more than one ISP for the duration of the transition period, and sometimes addresses from both the old range(s) and the new might have to be managed and used in parallel. With the goals of aggregation and conser- vation in mind, as well as to minimise duplicate logistics, this period should be kept as short as possible. IP Address Space Replacement Procedures: In general, address space should be replaced on a one-to-one basis. An assignment of PA space to replace previously assigned PI space can be made if the original assignment criteria are still met and if the address space to be replaced is currently used for the end user's network. Only if a large percentage of the original assign- ment is not in use (50% or more than 4096 addresses) will an end user be required to submit the usual documentation to the new registry. This part of the request is then treated like any other request for assignment of additional addresses. The address space to be replaced (the individual address ranges and the total size) must be properly documented with the standard IP address space assignment request forms. For address space that was allocated by Local IRs established within the framework of the RIPE NCC, a copy of the documenta- tion is forwarded to the registry or registries that ____________________________________________________ ripe-185.txt Page 30 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ assigned the address space being replaced. Before assigning the new address space, an agreement (preferably contractual) should be reached regarding the maximum period within which the previously assigned addresses will be returned to the original registry or to the regional registry for eventual reassignment. After the renumbering is complete, the database must be updated to reflect the changes. Whenever a large amount of addresses are to be replaced (the equivalent of a /20 or more) the Regional IR must be informed about the intended replacement and the agreements on the maximum period of parallel assignments. In complex cases, the Regional IR may decide to provide guidance in the process of managing the address space replacement. In general a period of 3 months should be allowed for the end user to complete the transition to the new addresses. RFC 2008 "Implications of Various Address Allocation Policies for Internet Routing" [Rekhter96a] recommends a grace period of at least 30 days, and no longer than six months. For excep- tional cases, where the end user requests to keep both assignments for more than 6 months, approval should be obtained for the proposed time frame from the RIPE NCC. For those addresses that have not been assigned by a Local IR, or which were assigned by an IR that has since closed, the Regional IR will act in lieu of the original registry. 3.5.1. 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. Their networks are then referred to as multihomed. 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 3.2.1.2. One must be sure that users are not acquiring multiple assignments for the same purpose from different IRs. Moreover, one must ____________________________________________________ ripe-185.txt Page 31 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ check that a similar address space request has not been refused by another IR for some valid reason. 3.6. 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 and required step in making an assignment. This step makes the assignment definite, and makes public information regarding the assignment available to anyone seeking it. Care should therefore be taken to assure the correctness of the assignment and of all relevant data prior to completing this step. If the assignment is above the registry's assignment window (see next section), the LIR should first get approval from the RIPE NCC before entering the assignment into the database. The information collected about the user's organisa- tion in the Network Template (see Section 3.2.1.5) is used to construct 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 organisa- tion 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. Unless up-to-date objects are already available in the RIPE database, in addition to the inetnum object, a person object must be submitted for each person specified in the tech-c and admin-c fields of the inetnum object. The person object needs to ref- erence a nic-handle. The information should remain in the database for as long as the original assignment is valid. If the address space is returned, the registry that made the assignment must remove the old entry from the database. Assuming the assigning IR has properly stored infor- mation gathered in the assignment process for future reference, submission of the objects described above ____________________________________________________ ripe-185.txt Page 32 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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.7. 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 addresses that can be assigned by the local IR to an end user without prior approval by the RIPE NCC. This is expressed in /nn notation. Therefore, a local IR with an assignment window of /23 is allowed to assign up to and including 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 formally invalid until explicit approval is acquired from the RIPE NCC. Without this approval, the address space can not be used as it may result in a failure to meet the uniqueness requirement for Internet addresses at a later date. The assignment window is not only applied to indi- vidual assignments, but to multiple assignments to the same end user in a 12 month period If a Local IR makes more than one assignment to an organisation in any 12 month period, the total amount of address space assigned may not exceed the Local IR's assign- ment window. This also applies to address space used by the Registry for their internal network. ____________________________________________________ ripe-185.txt Page 33 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ Additional address space can only be assigned to that organisation 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. As the Local IR staff become familiar with assign- ment procedures, the assignment window can be raised. In general, it will be raised to match the size of the requests sent in by the registry. For example, if the registry has sent in several requests that were /25 or smaller, and there were no major problems with the requests, the RIPE NCC would raise the assignment window to a /25. At this point, the Local IR staff can make assignments for up to and including 128 addresses without prior approval from the RIPE NCC. If the RIPE NCC receives a request to raise the assignment window 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 judge- ment is shown in the evaluation of address space requests, whether past assignments have been prop- erly 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 a /19. Therefore, every assignment involving more than 8192 addresses requires the approval of the RIPE NCC. An established Local IR is responsible to train new staff to handle address space assignments according to the policies and procedures described in this document. Sometimes, due to time constraints on experienced registry staff the training is not per- formed sufficiently, and new staff members of a well established local IR may make errors both in judge- ment and procedure before they are properly trained to make assignments. If such errors are noticed by the RIPE NCC, the local IR will be notified, and if it happens repeatedly, the assignment window for the local IR may be decreased to prevent the new staff members from making erroneous assignments involving large amounts of address space. The assignment win- dow can again be increased based on the criteria stated above. ____________________________________________________ ripe-185.txt Page 34 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 4. Rules and Guidelines for Allocations In Section 3, we described the procedures for han- dling requests for address space, including the pro- cess used to determine which addresses should be assigned to an end user. In most cases, the address space will be 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 for an (additional) allocation 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. A registry cannot have more than one "open" (less than 80% assigned) /16 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 organisation. More- over, without prior approval by the NCC, Local IRs are not permitted to exchange allocated address space among themselves. In some cases, a Local IR makes address space assignments for the customers of another IP service provider which itself does not operate a Local IR. The Local IR is of course responsible for all assignments from its allocation, even if there is an agreed involvement of staff from the other IP ser- vice provider. Whereas staff of the other IP ser- vice provider can and should be involved in process- ing the end user's request, local agreements about shared responsibility in the registration process are not recognised by the regional registry and are strongly discouraged. If at some point, an IP service provider decides to establish 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 to it from the RIPE NCC. Further- more, any address space used by the ISP's customers which was acquired from a transit provider's alloca- tions should be returned to the transit provider as soon as possible, and new assignments should be made to the end users from the ISP's allocated address space. ____________________________________________________ ripe-185.txt Page 35 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ In the following subsections, we describe how a Local IR can obtain an allocation and how allocated address space should be managed. 4.1. The Slow Start Mechanism 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 idea is to allocate address space to Local IRs at the rate it will be assigned. The minimum size of an individual address space allocation is /19 (8192 addresses), and the maximum size is /16 (65536 addresses). The size of an allocation to a particu- lar Local IR is based solely on the rate that the IR has assigned previously allocated address space to end users. 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 Section 3.6, 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 proficiency of the registry staff in evaluating requests and pro- cessing assignments. Please note that only the RIPE NCC can make allocations. A registry can never make allocations or sub-allocations to any other ISPs or customers. A registry can only make 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 a /19 (8092 addresses). 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 Section 3, a new Local IR must have every assignment approved by the RIPE NCC until its assignment window is increased. ____________________________________________________ ripe-185.txt Page 36 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 (about 80 percent), or if a single assignment will require a larger set of addresses than can be satisfied with the allocated address space. By "used up" we mean that the allocation is filled with actual assignments, reservations do not count. A Registry can set aside (or "reserve") address space in their allocation for customers, if they think the customers will grow beyond their assignment, however once the Registry's allocation starts getting used up and they start running out of address space, they should reuse these "reserved" blocks by giving them to other customers. The RIPE NCC will consider "reservations" as free address space when evaluating an allocation request. 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 their last alloca- tion, (however the RIPE NCC will check all the pre- vious allocations for 80% usage as well). The RIPE NCC will check this information, compare it with assignments registered in the database and may request further information (such as documentation of some of the assignments) to determine the need for a new allocation. Additional address space will be allocated after the information supplied 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 and aggregat- able with previous allocations. ____________________________________________________ ripe-185.txt Page 37 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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. 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 authorisation is implemented, authori- sation can be used for the creation of inetnum objects "under" the allocation objects. ____________________________________________________ ripe-185.txt Page 38 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 5. DNS and Reverse Address Mapping Applications such as ftp, e-mail, and telnet allow users to specify an Internet host as a domain name, such as "ns.ripe.net". With this notation, the full name of a host is determined in a hierarchical fash- ion. In this example, net is one of the top level domains in the system, ripe is the name of a subdo- main defined in the net domain, and ns is the name of a host in the "ripe.net" domain. This hierarchy is similar to the UNIX file system, and it enables unique naming of hosts on the Internet. Before an application can send IP packets to a given destination, however, its IP address must be deter- mined. The Domain Name System (DNS) is a dis- tributed hierarchical directory service which makes it possible to obtain the IP address for a host given its symbolic name specified in the domain name notation described above. The inverse procedure which produces the domain name from the IP address is called reverse address mapping, and is the focus of this section. We begin with a brief introduction to the DNS because reverse address mapping is simply a specific application thereof. Detailed information on the DNS can be found in [Albitz94a]. In this section, we aim to provide a sufficient basis to understand the procedures involved in making reverse address map- ping possible for address space allocated by the RIPE NCC. 5.1. Forward Name Mapping The DNS is a client/server system. If data is prop- erly administered on the domain name servers, then every public IP address in use has exactly one domain name associated with it. The IP address which corresponds to a given domain name can be extracted with a resolver, which works as follows. If a machine needs the IP address for a host identified by its symbolic name, and it cannot be obtained locally, the resolver is used, first to inspect the domain name, and then to determine what name server should be able to provide the IP address that corre- sponds to it. The resolver then sends a request to the appropriate name server which either returns the required IP address, or the address of a server that should be able to provide more details. If the lat- ter, the resolver repeats its request to the new server. This continues until the IP address is found ____________________________________________________ ripe-185.txt Page 39 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ (or the host is reported to be unknown). This pro- cedure is called forward mapping or resolution. Of course, before a host can be identified with the DNS, it must be registered with a server. The responsibility for name registration is hierarchi- cal. The administration of a subset of the DNS name space is delegated to a representative of an organi- sation by the party which holds responsibility for the name space it falls under. In the example above, the administration of the top level domain net is performed by the InterNIC. The InterNIC delegated the subdomain ripe to a representative of the RIPE NCC, who chose to use the name ns to refer to one of the hosts in its network. After the name ns has been properly specified in the name server for ripe.net, the domain name ns.ripe.net can be used to find the Internet host with IP number 193.0.0.193. The suffix of each domain name corresponds to a top level domain (TLD) in DNS, and authority to adminis- ter it is delegated by IANA. Generally, this will be an ISO 3166 two letter country code such as "nl" for The Netherlands, "fr" for France, or "us" for the United States. These codes have been delegated by IANA as country specific TLDs. (The only excep- tion is the domain ".uk" which has been delegated to Great Britain; "gb" is in fact the ISO code.) The administration of each country specific TLD is dele- gated to a representative residing in the country. If responsibility for a country specific TLD has yet to be delegated, then a resident can request permis- sion from IANA to manage it. Responsibility for the TLD will be delegated to that person if the guide- lines specified in (RFC 1591 [Postel94a]) are agreed to and if no objections are made within some short period after the possible delegation is announced. When the DNS was first implemented, a small number of "generic" three letter codes were defined as TLDs. These domains are administered by the InterNIC and are still in wide spread use within the US. His- torically, organisations have selected TLDs based on their primary business. For example academic insti- tutions usually have names that end in "edu", mili- tary organisations in "mil", and companies in "com". Delegation policies are up to the party responsible for the administration of the domain from which del- egations are made. For example, policies regarding delegation of second level domain names ending in "edu" are determined by the InterNIC. Delegation policies for third level domain names, however, are ____________________________________________________ ripe-185.txt Page 40 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ determined by the body to which the corresponding second level domain name has been delegated. For example, a representative of Catatonic State Univer- sity may be responsible for the delegation of subdo- mains which fall under "cat.edu". In general, the delegation policies applied by DNS domain adminis- trators are expected to remain within the guidelines outlined in (RFC 1591 [Postel94a]). In mapping a domain name to an IP address, the name servers administered by those responsible for the associated domains must provide the information suf- ficient to resolve it. Suppose a request is received for the IP address of a host named "bite.dog.cat.edu". Because the InterNIC is respon- sible for all delegations in the TLD "edu", the request can first be passed to InterNIC's name server. If the domain "cat.edu" has been delegated to the Catatonic State University name server, the InterNIC's name server will probably pass the request to the university's name server, which in turn might pass it on to the appropriate depart- ment's name server. If all name server files are in order, the department's name server should provide the IP address for the domain name in question. This is a simplified model of how name resolution occurs. It ignores caching and other alternatives that are used to optimise the DNS. It does, how- ever, give a realistic view of which parties are responsible to provide which information in the res- olution process. 5.2. Reverse Address Delegation and Mapping Just as it is necessary to obtain the IP number for a host with a given domain name, it is often neces- sary to do the reverse, that is to obtain the domain name associated with a specific IP address. Simple authorisation checks used by some Internet applica- tions and some diagnostic services need the fully qualified domain name associated with an address, for example. Given an IP address, the procedure used to obtain the domain name associated with it is called reverse mapping. In the DNS, a pseudo domain called "in-addr.arpa" (a historical abbreviation for "inverse addresses in the Arpanet") has been defined, to make this possi- ble. Delegations in this domain are made by IRs, because they allocate and assign address space. For example, the RIPE NCC has been delegated the domain ____________________________________________________ ripe-185.txt Page 41 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ "193.in-addr.arpa", because it is responsible for allocations and assignments in 193/8 (among others). The RIPE NCC delegates authority for names within the domain "193.in-addr.arpa", after the correspond- ing address space has been allocated and assigned. Given the IP address 193.3.20.100 in dotted quad notation, suppose its domain name is required. First, a pseudo domain name "100.20.3.193.in- addr.arpa" is generated by reversing the order of the address components and adding the suffix ".in- addr.arpa". This name is then used to find the domain name corresponding to the IP address with reverse mapping. Once the name as been generated in the pseudo domain, the reverse mapping mechanism is technically equivalent to the forward mapping mecha- nism. Although the mechanisms used for forward and reverse mapping are equivalent, authority of the domain hierarchies is different. In particular, while dele- gation in the generic and country specific TLDs fol- lows the organisational structure described in the previous section, delegation in the pseudo domain "in-addr.arpa" involves those responsible for the allocation and assignment of the corresponding address space. The term reverse delegation refers to the delegation of IP address names in the pseudo domain "in- addr.arpa". For example, the inverse domain name "193.in- addr.arpa" has been reverse delegated to the RIPE NCC, which is therefore responsible to supply infor- mation which can lead to domain names corresponding with assigned IP addresses in the 193/8 range. It is important to note that reverse delegation of address names in the pseudo domain does not occur automatically either upon allocation or upon assign- ment of address space. Rather, for all allocations and assignments from the address space managed by the RIPE NCC, reverse delegation only occurs in response to an explicit request submitted to the RIPE NCC. This is of course a prerequisite if reverse mapping is to be used for IP address to domain name translations. As described above, pseudo domain names are gener- ated in terms of dotted quad notation for IP addresses. This requires that reverse delegation take place on octet boundaries. Suppose the RIPE NCC allocates a /17 to a Local IR named Eye-Pea, for ____________________________________________________ ripe-185.txt Page 42 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ example, 193.1.0/17. Then no reverse delegation of the name "1.193.in-addr.arpa" will be made to Eye- Pea, because it is only responsible for a subset of the address space corresponding to the inverse domain "1.193.in-addr.arpa". The RIPE NCC therefore remains responsible for the inverse domain name "1.193.in-addr.arpa" and all reverse delegations that fall under it. On the other hand, suppose a /16 allocation is made to a Local IR called Aye-Queue, for example 193.2/16. Then, the zone "2.193.in-addr.arpa" can be reverse delegated to Aye-Queue upon request because that IR is responsible for all assignments in the address range 193.2.0.0 - 193.2.255.255. Subse- quently, Aye-Queue will be expected to provide pointers to reverse domain name information for addresses in the range 193.2.0.0 - 193.2.255.255. Note that if the request is granted, Aye-Queue is said to have authority over the "2.193.in-addr.arpa" zone. Following the procedures specified in Section 3 of this document, Aye-Queue may then assign a /24, for example 193.2.40.0 - 193.2.40.255 to some organisa- tion called Organiser. Subsequently Aye-Queue can make a reverse delegation for "40.2.193.in- addr.arpa" so that requests for domain names associ- ated with addresses in the range 193.2.40.0 - 193.2.40.255 will be forwarded to Organiser. Note that with the classless scheme, both address space allocations and assignments may take place on non-octet boundaries, whereas reverse delegations must occur on octet boundaries because the the reverse domain name is specified in terms of dotted quad notation for the IP address. This means that allocations and assignments made on non octet CIDR boundaries, a slightly different delegation strategy is required, that will be explained in this section. The basic system, however, remains unchanged. The RIPE NCC together with the Local IRs act together to assure that reverse delegation is cor- rectly performed. This allows reverse mapping to be used to find the domain names corresponding to IP addresses from the range managed by the RIPE NCC. The role of both parties is covered in the following subsections. ____________________________________________________ ripe-185.txt Page 43 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 5.3. Local IRs and Reverse Delegations If a Local IR obtains reverse delegations for the address space it assigns, it is able to efficiently provide expected services, namely IP number to domain name mapping, for the end users it services. In this section, we describe how reverse delegations can be obtained. We start with a description of the responsibilities which accompany authority over inverse address domain name zones. We then discuss the proper dis- tribution and maintenance of the reverse address database when CIDR address space allocations and assignments are made. The specific procedures used to obtain reverse delegations are described. Finally we consider issues relevant to Local IRs regarding PA versus PI address space assignments. 5.3.1. Responsibilities Prior to the delegation of domain name zones (e.g. "cat.edu"), the person or organisation to whom authority over the zone is delegated agrees to pro- vide some key services necessary to support domain names extending from the zone. Similar agreements are of course necessary for reverse delegations if DNS is to provide accurate mappings from IP addresses to domain names. When a reverse domain zone is delegated to a Local IR, care should of course be taken in the proper construction of the DNS configuration files for the zone. Known pitfalls and some useful tips for avoiding them can be found in (RFC 1537 [Beertema93a]). For each zone, a secondary server must be set up to improve the reliability of the database under adverse conditions. To increase the probability that the secondary server can be reached if the pri- mary server becomes unavailable, the secondary server is required to be on a subnet physically sep- arated from the primary server. For reverse delega- tions corresponding to /16 allocations to Local IRs, an additional secondary server is provided by the RIPE NCC. This does not replace the required sec- ondary, but rather provides extra reliability for these substantial delegations. It is customary for Local IRs and other organisations managing reverse domain names to provide secondary services for one another. ____________________________________________________ ripe-185.txt Page 44 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ As is required for top level domain name servers, both the primary and secondary reverse domain name servers must be directly reachable from the Inter- net. If a Local IR is given authority over a reverse domain name zone, it is responsible for subsequent reverse delegations in that zone. This means the Local IR must assure that an organisation to which authority is delegated satisfies the requirements described in this section for its zone. In Section 5.4, we describe the services provided by the RIPE NCC to assure proper working of the reverse domain name system. Local IRs should use this as a refer- ence for the services they provide to end users to whom they make reverse delegations. 5.3.2. CIDR and Reverse Delegations As mentioned above, making allocations and assign- ments on CIDR boundaries, rather than on traditional class (octet) boundaries, requires a slight varia- tion on the reverse delegation scheme. Basically, if an allocation or an assignment is made on a nonoctet boundary, authority over the corresponding reverse domain zone must not be delegated, but must be main- tained by the IR that makes the address space allo- cation or assignment. 5.3.2.1. Allocations and Reverse Delegations If an allocation smaller than a /16 is made to a Local IR, such as the 193.1.0/17 allocation to Eye- Pea in our example, then authority for an immediate subdomain of 193.in-addr.arpa cannot be granted, because a subset of the corresponding address space may be allocated to another Local IR. For any single allocation smaller than /16 in the 193/8 address range, the RIPE NCC will maintain authority for the immediate subdomain of 193.in- addr.arpa, and reverse delegations will be made upon request if preceded by corresponding address space assignments. This of course holds for reverse dele- gations corresponding to any /8 address space allo- cations managed by the RIPE NCC. If at some point, the remainder of the block (in this example 193.1.128/17) happens to be allocated to Eye-Pea, a request (accompanied by a domain database object) can be submitted for a reverse ____________________________________________________ ripe-185.txt Page 45 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ delegation of 1.193.in-addr.arpa. When a reverse delegation is made to a Local IR, the RIPE NCC will forward all the relevant data and the responsibility for any reverse delegated zones to the Local IR. In this example, if 1.193.in-addr.arpa is delegated to Eye-Pea, all past and future delegations made from that domain fall under the authority of Eye-Pea. Suppose, on the other hand that a /16 has been allo- cated to the Local IR in the first place, such as the 193.2/16 allocated to Aye-Queue in the example above. Then Aye-Queue (e.g. the Local IR receiving the allocation) may immediately request authority for a subdomain of 193.in-addr.arpa, in this case 2.193.in-addr.arpa. Because Aye-Queue is responsi- ble for all address space corresponding to the reverse domain name 2.193.in-addr.arpa, the reverse delegation can be granted. 5.3.2.2. Assignments and Reverse Delegations With respect to reverse delegations, we can distin- guish two address space assignment categories, namely those assignments that involve an integral number of /24's, and those that do not. We begin with the latter. We first consider an assignment made by a registry holding a full /16 allocation. Continuing with our example, suppose that Aye-Queue has been allocated 193.2/16 and has a reverse delegation for 2.193.in- addr.arpa. Aye-Queue might assign the 64 addresses in 193.2.0/26 to an end user, say Use-IQ. Following the reasoning applied for the /17 allocation to Eye- Pea above, Use-IQ cannot obtain a reverse delegation for 0.2.193.in-addr.arpa, because some of the corre- sponding address space may be assigned to other end users. To address this problem, Aye-Queue can essentially delegate 0.2.193.in-addr.arpa to itself, and main- tain the IP address to domain name information for Use-IQ and any other end users to whom the corre- sponding address space is assigned. Such a delega- tion to the same organisation is of course not nec- essary, but it can help in the administration of multiple domains. When a Local IR makes a reverse delegation to itself for address space it assigns, it is recommended, but not strictly required that a domain object be submitted to the RIPE database to register the reverse delegation. ____________________________________________________ ripe-185.txt Page 46 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ Suppose a similar assignment is made by Eye-Pea from the 193.1.0/17 address space allocated to it. If Eye-Pea assigns 193.1.0.0/26 to an end user, say Use-IP, the problem arises again. Moreover, because Eye-Pea does not have authority for 1.193.in- addr.arpa, it cannot delegate 0.1.193.in-addr.arpa to itself. Rather Eye-Pea can receive a reverse del- egation for 0.1.193.in-addr.arpa upon request, after at least one assignment has been made from the cor- responding /24 address space. The procedures to obtain a reverse delegation are outlined in Sections 5.3.3 and 5.5 below. Of course, Use-IQ could have been assigned an inte- gral number of /24's. For example, suppose it was assigned 768 addresses in the range 193.2.0.0-193.2.2.255. Then Aye-Queue can make reverse delegations of {0,1,2}.2.193.in-addr.arpa to Use-IQ. The procedures Aye-Queue should follow in making reverse delegations and the services it should provide to its end users are described in Sections 5.4 and 5.5. Suppose now that Eye-Pea assigns the 256 addresses in the range 193.1.0.0 - 193.1.0.255 to Use-IP. Then Eye-Pea need not manage the reverse domain 0.1.193.in-addr.arpa, because Use-IP is the only end-user with addresses assigned from the corre- sponding address space. In this case, Eye-Pea should support the end user in requesting a reverse delega- tion (using the inetnum object) from the RIPE NCC, and provide secondary database and other services as necessary. See the next section for more informa- tion. In summary, after an assignment which is smaller than /24 has been made, a Local IR should obtain a reverse delegation for the reverse domain corre- sponding to the entire /24 of which the assigned address space is a subset. It should maintain the reverse mapping entries to reflect IP address to domain name information provided by the end user. More information on management of inverse mappings when allocations and assignments are made on non- octet CIDR boundaries is available in [Eidnes98a]. For quick reference, two tables are included below to give an overview of reverse delegation procedures for the end user and the Local IR. ____________________________________________________ ripe-185.txt Page 47 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ Instructions for the User: +-------------------------------------+ | Allocation Size | +-------------------------------------+ | /16 </16 | |Assignment >=/24 LIR NCC | |Size </24 LIR LIR | +-------------------------------------+ LIR= User requests delegation from the Local IR NCC= User asks LIR to request delegation from the RIPE NCC Instructions for the Local IR: +-------------------------------------+ | Allocation Size | +-------------------------------------+ | /16 </16 | |Assignment >=/24 DF FR | |Size </24 ML RR | +-------------------------------------+ DF= Delegate further FR= Forward request to the RIPE NCC ML= Maintain locally RR= Request delegation from the RIPE NCC and main- tain locally 5.3.3. Obtaining a Reverse Delegation We now describe the procedures to be followed by a Local IR, requesting a reverse delegation from the RIPE NCC. As can be concluded from the previous sec- tion, a Local IR can obtain authority for a /16 fol- lowing its allocation, or for a /24 after one or more assignments have been made from it. The two procedures are very similar. However, in this sec- tion we describe only the steps to be taken for a /16 reverse delegation, while the procedures for a /24 are described in Section 5.5. To acquire authority over the reverse domain name zones corre- sponding with the address space involved, the fol- lowing steps should be taken. 1. Configure the DNS configuration files for the zone for which the delegation is requested. Following the findings in (RFC 1537 ____________________________________________________ ripe-185.txt Page 48 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ [Beertema93a]), for a direct subdomain of the domains under RIPE NCC authority (193.in- addr.arpa, etc.), the following settings are strongly recommended: Refresh = 8 hours (28800 seconds) Retry = 2 hours (7200 seconds) Expire = 7 days (604800 seconds) Time To Live = 1 day (86400 seconds) We recommend a lower retry level if connectiv- ity is unstable. 2. Install the configuration files on the pri- mary and secondary servers. Make sure the name servers allow zone transfers from 193.0.0/23 (the RIPE NCC address range). 3. Gather information required for a RIPE database domain object. The name of the domain requested, for example "0.194.in-addr.arpa" must be entered in the domain field. A description of the organisation to maintain the zone under consideration should be included in one or more descr fields. The admin-c, tech-c, and zone-c fields should specify the persons who are responsible for administration at the site of the primary server, technical support for the site, and authority over the zone, respectively. The nserver fields, of which there must be at least three, specify the domain names of the primary, secondary, and RIPE NCC reverse name servers. Finally, as for all RIPE database objects, there is a changed and source field used to specify the e-mail address of the person making the request and the database source "RIPE", respectively. For example, if a Local IR has been allocated 194.0.0.0 - 194.0.255.255 for assignments to customers, they would send in a domain object such as the one below. domain: 0.194.in-addr.arpa descr: Our organisation allocation admin-c: JLC2-RIPE tech-c: PC111-RIPE zone-c: JLC2-RIPE nserver: ns.someserver.net nserver: ns.otherserver.net nserver: ns.ripe.net changed: email(a)address.net 960731 source: RIPE ____________________________________________________ ripe-185.txt Page 49 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ Please note that one of the name servers has to be ns.ripe.net. The domain object needs to be entered in the RIPE database before requesting reverse delega- tion. 4. Submit a request for a reverse delegation to <auto-inaddr(a)ripe.net>. This step implies the requirements described in Section 5.3.1 have been satisfied. The domain object described above should be included in the request, as well as zone file entries for the zone above the one requested. For example if a reverse delegation is requested for 1.193.in-addr.arpa, the relevant zone file entries should be included for 193.in-addr.arpa, whereas if a reverse delegation is requested for 2.2.193.in- addr.arpa, the zone file entries should be included for 2.193.in-addr.arpa. (This is one request to <auto-inaddr(a)ripe.net> for which the X-NCC-RegID field may be omitted, but the omis- sion will result in the a low priority for the request.) As described below, the RIPE NCC will test the proper working of the primary and secondary servers. If the Local IR making the request has been allo- cated the address space corresponding to the reverse domain name zone for which the request has been sub- mitted, and the servers are running properly, the request for delegation will be granted. In the next section, the services provided by the RIPE NCC are described. 5.3.4. Side Effects for PA/PI Assignments End users have a right to reverse mapping services. An end user holding non-PA address space from a zone that has been reverse delegated to one service provider is permitted to keep the address space, and obtain connectivity services from another provider. Because the address space falls in the reverse dele- gation zone of the initial Local IR, that IR is required to continue to provide reverse mapping ser- vices for the address space assigned to the end user. Moreover, the Local IR has to provide this service under the same conditions it applies to its other end users (e.g. extremely high fees for this service are unacceptable - unless they are applied to all end users.) ____________________________________________________ ripe-185.txt Page 50 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ For PA addresses, contractual agreements confine the provision of reverse mapping services directly to the time period for which the assignment is valid. Clearly this is one reason why converting non-PA address space to PA address space is in the best interests of the assigning Local IRs and their cus- tomers. 5.4. The RIPE NCC Services for Reverse Delegation Because the RIPE NCC allocates address space to Local IRs from 193/8 and other /8's allocated to it by IANA, it is responsible for reverse delegations that correspond to the address space. Requests to resolve reverse mappings for address space assigned from that allocated by the RIPE NCC should therefore be sent to the RIPE NCC. If a reverse mapping is required for an address, and one is not sure which regional IR the address originated from, a request can be sent to the RIPE NCC; if the address space originated from one of the other regional reg- istries, its contact details will be returned. Of course, one cannot perform reverse mappings for IP addresses that have not either been allocated (/16) or assigned and registered (/24). Upon receiving a request for a reverse delegation of an immediate subdomain of 193.in-addr.arpa, 194.in- addr.arpa, 195.in-addr.arpa, or 62.in-addr.arpa the RIPE NCC will first check if all of the correspond- ing address space has been allocated to the request- ing IR. If the request is for a /24, then a check will be made as to whether some or all of the address space has been assigned. If the required allocation (assignment) has been made, the following services will be performed: 1. Access to the primary and secondary servers specified in the domain object will be tested. 2. Data for any already registered reverse zones in the corresponding address space will be forwarded to the requesting organisation, for inclusion in the newly defined reverse zone files. (If the reverse delegation is made, fur- ther responsibility for past delegations is transferred to the requesting organisation.) 3. The reverse domain name server will be tested using the information provided in the request. ____________________________________________________ ripe-185.txt Page 51 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ For a /16 reverse delegation, the next two tasks are also performed: 4. If the reverse delegation request is to be granted, the RIPE NCC will set up secondary server for the reverse domain on ns.ripe.net, and notify the Local IR. 5. Once the reverse delegation has been made, requests made to the RIPE NCC for reverse dele- gations for address space corresponding to the delegated zone will be forwarded to the mailbox specified in the SOA RR field of the reverse zone configuration file, and to the person specified in the zone-c field of the domain object. All requests for reverse delegations at the RIPE NCC are now being handled by an automatic procedure. Zone information for the request described above will be checked automatically upon receipt in the <auto-inaddr(a)ripe.net> mailbox. The automatic robot does a zone transfer as one of the checks, so please make sure to allow zone transfers from 193.0.0/23 (the RIPE NCC address range). If the zone is set up properly and everything is in order, the request request will be granted (sometimes after additional manual evaluation by a RIPE NCC staff member). Please note that in order to insure the consistency of the zone the NCC reverse delegates, the automatic procedure includes a zone transfer Reverse delegations allow a Local IR to administer reverse mapping services for IP addresses assigned to its end users. The end users can then be sure they can be identified quickly and easily from hosts on the network having only access to the IP address. Because of the distributed nature of the database, its proper working depends on the correct adminis- tration of all zones. On some rare occasions, an organisation managing a delegated zone proves unable to correctly perform the required services. If repeated complaints are made regarding the adminis- tration of a zone delegated by the RIPE NCC, the RIPE NCC may revoke the delegation, as a final ser- vice to support efficient and correct reverse map- ping. 5.5. Making Reverse Delegations to End Users Up to this point, we have been concerned with the procedures surrounding the reverse delegation of a ____________________________________________________ ripe-185.txt Page 52 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ zone to a Local IR. Because the reliability of the data distributed with the DNS increases as the dis- tance to the data source decreases, reverse delega- tions of a zone can also be made to end users for each /24 that is assigned. In this context a /22 assignment is simply a multiple /24 assignment, for which multiple reverse delegations should be requested. A Local IR should always support end users request- ing reverse delegations corresponding to address space (one or more /24's) which has been assigned to them from address space allocated to the Local IR. The end user must be made aware of the means to acquire a reverse delegation and the responsibili- ties that go with it. Basically, the same criteria hold in the case of reverse delegations to end users as hold for Local IRs. The end user requesting authority for a partic- ular zone must agree to fulfill the responsibilities described in Section 5.3.1. There is a slight varia- tion of the procedures described in Section 5.3.3. While the end user is responsible for the reverse delegation and therefore for the procedures sur- rounding it, Local IRs traditionally support end users in obtaining and in maintaining reverse dele- gations for their address space. For example, it is common for the assigning Local IR to provide a sec- ondary server for the reverse delegation. If a Local IR such as Eye-Pea has an allocation for a /19, /18, or a /17 address range, then the reverse delegation must be made by the RIPE NCC rather than the Local IR. In this case, an inetnum database object for the entire assignment (or a domain object for each /24 in the assignment) should be submitted to the RIPE database and with the request sent to <auto-inaddr(a)ripe.net>. The inetnum object for a /24 or larger assignment to one customer should follow the example below: inetnum: 194.0.0.0 - 194.0.3.255 netname: NETA descr: NET A Incorporated admin-c: JLC2-RIPE tech-c: PC111-RIPE country: NL rev-srv: ns.someserver.net rev-srv: ns.otherserver.net status: ASSIGNED PA changed: email(a)address.net 960731 ____________________________________________________ ripe-185.txt Page 53 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ source: RIPE Please note ns.ripe.net should not be one of the name servers in this case. The inetnum object should be updated in the database before requesting reverse delegation, and needs to have a status field indicating whether the assign- ment is PI (provider independant) or PA (provider aggregatable). If a /24 is divided among several small customers, a domain object should be send to the database and to <auto-inaddr(a)ripe.net> for the entire /24. For example, if a Local IR has assigned 194.0.0.0 - 194.0.0.127 to customer A and 194.0.0.128 - 194.0.0.255 to customer B, they should submit one domain object to <auto-inaddr(a)ripe.net>, such as the example below (Please refer to [Eidnes98a] for more information.) The Local IR does not need to wait until the entire /24 is filled with assignments before requesting reverse delegation. domain: 0.0.194.in-addr.arpa descr: Splitblock descr: our company admin-c: JLC2-RIPE tech-c: PC111-RIPE zone-c: JLC2-RIPE nserver: ns.someserver.net nserver: ns.otherserver.net changed: email(a)address.net 990731 source: RIPE Please note that ns.ripe.net should not be one of the name servers listed here. Note that the RIPE NCC will only reverse delegate address space after it has been assigned to end- users (with the exception of /16 allocations). The NCC will not reverse delegate address space that is allocated to the registry but not assigned to an end-user yet. The NCC will also not reverse delegate assignments that are made above the registry's assignment window without RIPE NCC approval. It is necessary that the Local IR update the RIPE database at <auto-dbm(a)ripe.net> with the inetnum and domain objects first since the RIPE NCC will not reverse delegate address space that cannot be found in the RIPE database. ____________________________________________________ ripe-185.txt Page 54 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ When sending a reverse delegation request to <auto- inaddr(a)ripe.net> keywords can be used in the Subject line of the E-mail to control the checking process. The use of the LONGACK keyword is highly recom- mended. It will send back the most verbose output possible. Other keywords are HELP which will send this chapter of the document, CHANGE which is needed when changing an existing reverse delegation, and TEST which will only test an (existing) delegation without actually doing the request. For special requests, deletion of reverse delegated address space in RIPE NCC zone files, bug reports, commments or human intervention the Local IR can contact <inaddr(a)ripe.net>. If a local IR such as Aye-Queue has a /16 alloca- tion, it may make the reverse delegation itself, but is encouraged to submit an inetnum object with "rev- srv" fields or a domain object to the RIPE database to register the reverse delegation. In both cases the Local IR is expected to perform services similar to those performed by the RIPE NCC to assure the requested delegation is appropriate and properly administered. For example, the assigned address space must correspond to the zone requested, and the primary and secondary servers must be tested to assure that they are reachable and properly configured. ____________________________________________________ ripe-185.txt Page 55 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 6. Operating a Local Internet Registry Local Internet Registries (Local IR's) process the vast majority of address space assignments to end users. Most Local IRs are operated by Internet ser- vice providers (ISPs) and offer IP registration ser- vices to the customers of the ISP. In this section, we describe a number of services offered by the RIPE NCC to facilitate the uniform implementation of the policies outlined in this doc- ument. We also outline procedures associated with IP registration services which Local IRs are expected to follow in order to ensure that the policies are applied in a fair and impartial manner throughout the RIPE NCC service area. 6.1. RIPE NCC Registration Services The RIPE NCC offers the contributing Local IR's a range of registration services, most of which are described in other chapters of this document. Requests and queries related to these services are handled almost exclusively by electronic mail. A set of role mailboxes is available for handling various requests and queries. They are regularly serviced by RIPE NCC personnel or by automatic procedures. Per- sonal mailboxes of NCC staff are not used for request handling. Paper mail is to be avoided wher- ever possible. Telephone communications should be confirmed by e-mail for documentation purposes and to avoid misunderstandings. While <ncc(a)ripe.net> serves as a catch-all for general queries and requests, there are a number of other mailboxes for submitting specific requests. All of the "auto" mailboxes are processed automatically and in general are not read by a person. These mailboxes perform specific tasks and any extra messages or information will not be read by NCC staff. The RIPE NCC mail- boxes are: <hostmaster(a)ripe.net> This is the mailbox associated with registration services and our primary interface with Local IRs. Requests for allocation and/or assignment of IP address space and autonomous system (AS) numbers should be submitted here. All corre- spondence about IP address related requests and AS number requests sent to the RIPE NCC should be transmitted by e-mail to this address. However, information related to IP address requests, such as network topology and other documents only accessible in hardcopy can be sent by fax. Any faxed documents ____________________________________________________ ripe-185.txt Page 56 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ should include the ticket number of the request in the subject line or somewhere in the message. If such documents are available in PostScript they can be sent by e-mail rather than by fax. <auto-dbm(a)ripe.net> This is an automatic mailbox which handles requests for updates to the RIPE net- work management database. This mailbox is a robot which analyses the requests, performs authorisation checks and then does the actual updates requested. <ripe-dbm(a)ripe.net> Questions and requests regarding the RIPE network management database which require human intervention can be sent to this mailbox. <auto-inaddr(a)ripe.net> This mailbox is a robot which handles requests for DNS delegations in the in- addr.arpa domain (used to reverse map from IP addresses to host names). Each request is analyzed and technical checks are performed to see whether the DNS servers to which delegation is requested are set up properly. If a request passes the checks it is forwarded to <inaddr(a)ripe.net>. <inaddr(a)ripe.net> Performs additional manual checks on each delegation request that has passed the auto- mated tool. The NCC DNS configuration is updated according to the request. Unusual requests and gen- eral questions about reverse delegations can also be submitted to this mailbox. <training(a)ripe.net> Questions about upcoming Local IR Training Courses should be send to this account. Likewise, those wishing to attend a course register by sending e-mail to this address. <billing(a)ripe.net> This is the role account which deals with invoicing of bills and answering ques- tions about invoices. <ncc(a)ripe.net> General queries can be sent to this role account. Whenever one is unsure to which role account a specific question or request should be submitted, this mailbox can be used. The query will be answered or be redirected to other role mailboxes or specific staff members as appropriate. This mail- box also deals with setting up new registries and updating registry information. ____________________________________________________ ripe-185.txt Page 57 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ List of Local IRs The RIPE NCC maintains a list of all Local IRs within its service region. It contains a set of information for every registry. Part of this infor- mation is published for reference by other reg- istries and address space users. The public data for each Local IR can be found under: http://www.ripe.net/lir/reg- istries/indices/index.html 6.2. Establishing a New Registry A local IR is established after submitting a request to the RIPE NCC which includes assurances that the relevant rules and guidelines defined in this and related documents are known and a commitment that they will be followed. The process of setting up a new registry is explained in detail in "Guidelines for Setting up a Local Internet Registry" (currently ripe-160 [Caslav98a]). 6.3. Mailing Lists The RIPE NCC maintains a series of mailing lists of interest to Local Registries. Some are mandatory for LIRs to follow, meaning that each registry has to have at least one e-mail address subscribed and an e-mail address cannot be removed unless the registry gives an alternative address instead. <local-ir(a)ripe.net> All registry related operational issues are discussed here. Announcements of upcoming Local IR Training courses and other matters which are of interest to all Local IRs are posted to this list. This list is moderated and is a closed list, only open to contributing local registries. This mailing list is mandatory, every registry has to have at least one e-mail address subscribed to this mailing list. To change the e-mail address sub- scribed for another one, please contact <hostmas- ter(a)ripe.net>. <lir-wg(a)ripe.net> This is a local IR working group mailing list which anybody can join. This list is unmoderated and can include general discussion of Local IR policies and registration services. This mailing list is optional, however the RIPE NCC strongly encourages registries to follow the discus- sions here. To join this list, a registry should ____________________________________________________ ripe-185.txt Page 58 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ send a request to <majordomo(a)ripe.net>. <ncc-co(a)terena.nl> This is the RIPE NCC Contributors Committee mailing list. All formal issues related with the operation of the NCC are discussed here. For example, the RIPE NCC activity plan and budget are always posted and discussed here. This mailing list is also mandatory, every registry has to have at least one e-mail address subscribed to this mail- ing list. To change the e-mail address subscribed for another one, please contact <hostmas- ter(a)ripe.net>. <lst-provs(a)ripe.net> This is a mailing list used to distribute requests for Internet services received at the RIPE NCC. This mailing list is optional, how- ever it is only open to Local IRs. To subscribe or unsubscribe please contact <hostmaster(a)ripe.net>. The lists are used for important announcements and operational information. It is assumed that at least one representative of each registry follows these lists and that information sent to these lists will be read. It is strongly recommended that at least one staff member of a new registry attends a Local IR training course. This is a one day introduction to Internet address space assignments and registration proce- dures in Europe. It also describes how one can query and use the information registered in the RIPE database. The NCC announces upcoming courses to the local-ir mailing list. 6.4. Registry Operations In this section, we outline a number of practices that should be followed when running a Local IR. Most have been established historically by consensus among the Local IRs in the RIPE community. Local IRs should adhere to the established practices, or move to have them modified by starting discussions on the <local-ir(a)ripe.net> mailing list, and active partic- ipation in the local IR working group. Record Keeping Local IRs must maintain proper records about all registry activities. Every Local IR should keep all information collected from its customers in the pro- cess of making a request for an IP address space assignment. This data is needed for the evaluation ____________________________________________________ ripe-185.txt Page 59 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ of subsequent requests for the same customers, for audits by the regional registry, and for the resolu- tion of any questions that may arise regarding assignments. The records must include: o The original request o All supporting documentation o All related correspondance between the reg- istry and the customer o The assignment decision, including: o Reasons behind any unusual decision o The person responsible for making the decision The chronology of events and the persons responsible should be clear in the records. In order to facili- tate the exchange of information, it is highly rec- ommended that documents are kept electronically and that they are readily accessible. External Quality Assurance In order to promote consistent and fair application of assignment criteria with regard to conservation and registration of address space and aggregation of routing information, the RIPE NCC has started an activity of consistency checking of registry data and auditing of registries. To ensure that reg- istries are following the assignment criteria, and entering assignments into the database correctly, the RIPE NCC may contact a registry to ask for docu- mentation or more information about certain requests or database entries. If the NCC finds problems, it will work with the registry to correct these, and may take disciplinary action, such as lowering the registry's Assignment Window. This activity is described in-depth in "RIPE NCC Consistency & Audit- ing Activity" (currently ripe-170 [Caslav97a]). Registry Identifier The Registry Identifier must be included in every message sent to <hostmaster(a)ripe.net>. It is used to identify the registry. Each request containing a valid identifier will receive an acknowledgement indicating whether they receive service or not and a ticket number (see below). In accordance with the ____________________________________________________ ripe-185.txt Page 60 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ policies established by the contributors' committee (see ripe-132 Kuehne95a] for details), the RIPE NCC provides service only to its contributors. Requests received from contributing Local IRs will be handled in the order in which they are received. Requests from Local IRs that are behind on their payments will not be serviced until the financial situation has been rectified. Requests not accompanied by a valid registry identifier will not be processed. Where possible we suggest the inclusion of the iden- tifier in an RFC822 header line of the messages con- cerned. The suggested format is: X-NCC-RegID: nn.example Where it is impossible to modify the RFC822 header, this line can also be included in the body of the message. Please note that the registry identifier needs to be lower case (it is case sensitive). For more information, see (ripe-183 [ Karrenberg94a]). Ticketing System The RIPE NCC uses a ticketing system to track the history of every request sent to <hostmas- ter(a)ripe.net>. Requests submitted to this role account will be notified of the ticket number that has been assigned to the request. The number must be referenced in all subsequent messages related to this request. The ticket number remains valid until the request has been handled. Every new request gets a new ticket number. This means that a local IR should never send two requests in the same mes- sage. Moreover, because a ticket number is associ- ated with a specific request, it should never be reused. For more information, see (ripe-183 [ Kar- renberg94a]). A registry can check the status of their ticket on the RIPE NCC web site: http://www.ripe.net/cgi-bin/rttquery Distribution Robot The RIPE NCC uses an automatic robot to distribute all messages sent to <hostmaster(a)ripe.net> and to do syntax checking on IP address space requests. For help on interacting with the robot, please see the RIPE NCC web site at: http://www.ripe.net/lir/services/status.html ____________________________________________________ ripe-185.txt Page 61 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ Contact Persons Every Local IR must provide the RIPE NCC with a list of contact persons. The contact persons should be those who submit address space and AS number requests for the Local IR. The contact information should be kept up to date. In general, address space and AS number requests will only be accepted from registry staff members that are registered as con- tact persons for a Local IR. Confidentiality Information collected by a registry in the registra- tion process must be kept in strict confidence. It is to be used for registration purposes only. It must be transmitted only to higher level registries and/or IANA upon request, but will not be transmit- ted to any other party unless explicitly requested in writing by the end user. Publishing Local IR Policy The core business of a Local IR is to assign IP addresses. These have no intrinsic value, although they are essential for Internet connectivity. They must be assigned judiciously with regard to volume, strategically with regard to aggregation, and equi- tably as between different ISPs. The best assurance of these objectives is "perfect knowledge" by the market of the policies of Local IRs. For this rea- son, every Local IR must publish its policies regarding registry operations. Local IRs must regis- ter their policies with the RIPE NCC, which will publish them. The information to be published should include at least the following: 1) The Community Served A Local IR should provide a concise description of the community it serves. The following description is sufficient: "We serve customers of <foo> company, an ISP with mostly <bar> type customers based in countries NN AA BB and CC." The registry should also indicate whether it will provide IP address space registration ser- vices to those not buying other services from them. 2) Charging Policies A Local IR must publish its charging policy. The policy is defined in ripe-152 [Norris96a]: "Address space is a finite resource with no intrinsic value and direct costs cannot be ____________________________________________________ ripe-185.txt Page 62 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ ascribed to it. While they may not charge for address space as such, registries may charge for their administrative and technical ser- vices. Registries must publish their operating procedures and details of the services they offer and the conditions and terms that apply, including scales of tariffs if applicable." 3) Terms of Assignment The registry must publish its policy about assigning provider aggregatable and provider independent address space, and the terms and conditions that apply. 6.5. When a Registry Changes Ownership If a Local Internet Registry changes ownership (because it is sold, or merges with another com- pany), the RIPE NCC should be contacted about the change in ownership. Depending on the case, the RIPE NCC may need to request a new service agreement from the new owners. Also, if all of the contact persons who will be sending requests have changed, the NCC may lower the assignment window of the registry until the new contacts are up-to-date on the RIPE NCC procedures and policies. Sometimes a registry is taken over or merged with another, already existing registry. The RIPE NCC needs to be notified in this case as well. The reg- istries in question will need to discuss with the NCC what will be done with the allocations in case one of the registries is closing. An allocation can- not be transfered from one registry to another (or to a non-registry) without contacting the RIPE NCC first. A registry cannot have more than one "open" (less than 80% used up) allocation, so sometimes transfering all allocations is not possible. Please discuss these issues with <hostmaster(a)ripe.net>. 6.6. Closing a Registry A Local Internet Registry may decide to stop operat- ing as such. Should a registry decide to close and re-open at a later date, it must repeat all formal steps required to establish a new registry. As soon as the registry decides to close, it should halt any open requests for IP address space and refer the customers to the list of Local IRs. This will prevent the customer from having to renumber at ____________________________________________________ ripe-185.txt Page 63 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ a later date. This list is available in: http://www.ripe.net/lir/reg- istries/indices/index.html A closing registry is not allowed to make any fur- ther assignments from its address space allocation. To stop operating as a Local IR, a registry must follow three steps: 1) Send the RIPE NCC a written request to offi- cially close the registry and state the inten- tion to return the unassigned address space. The request and all subsequent communication is sent to <hostmaster(a)ripe.net>. A registry will continue to be billed for services until it formally asks to be closed. 2) Provide the NCC with all documentation regarding IP address space that has been assigned while operating as a Local IR. The registry only needs to provide documentation about address space that was allocated to it by the RIPE NCC. Sometimes a registry may want to transfer its allocation to another existing registry, in that case, it will provide the documentation about all assignments to the other registry. Such a transfer can, however, has to be agreed upon by the RIPE NCC. 3) The closing registry has to provide the NCC with a final summary of all address space assigned from all of its allocations. It must also verify that the contents of the RIPE database are up to date with respect to the address space that has been allocated to them by the RIPE NCC. The registry must provide the NCC with a list of all address space that was allocated to the registry by the RIPE NCC but is not currently assigned. Unassigned addresses will be returned to the NCC and will revert back to the public pool of IP space. It can be assigned by the RIPE NCC as necessary. If the registry is closing as a Local IR, but will continue to provide Internet connectivity to its customers as an ISP, the customers can continue to use the address space already assigned to them. Assignments made by a registry that is closed remain valid for as long as the original criteria under which they were assigned remains valid. ____________________________________________________ ripe-185.txt Page 64 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ If the registry will no longer provide Internet con- nectivity to customers with assigned address space, the assigned address space should be retrieved from the users as they renumber. It is the Local IR's responsibility to help its customers with renumber- ing. 6.6.1. When a Registry is Closed by the RIPE NCC The RIPE NCC may decide to close a registry that stops paying its bills to the RIPE NCC and/or cannot be contacted by the NCC for a significant period of time. Moreover, if a Local IR consistently violates the policies established by IANA or within the RIPE NCC community, in spite of multiple warnings, then it may be closed. The RIPE NCC will send the local IR a message to notify it of its closure. The registry must then provide documentation to the RIPE NCC regarding its allocated address space, and follow the other proce- dures for closing a registry outlined above. If the registry does not provide the RIPE NCC with the proper documentation, the RIPE NCC will deter- mine which address space should be returned to the public pool of IP address space. ____________________________________________________ ripe-185.txt Page 65 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 7. AS Number Assignment Policies and Procedures An Autonomous System (AS) is a group of IP networks run by one or more network operators which has a single and clearly defined routing policy. Every AS has a unique number associated with it which is used as an identifier for the AS in the exchange of exterior routing information (i.e. net- work reachability information between ASes). Exte- rior routing protocols such as BGP (RFC 1771 [Rekhter95a]) are used to exchange routing informa- tion between ASes. An AS will normally use some interior gateway proto- col to exchange routing information on its internal networks. The term AS is often misunderstood to be a conve- nient way of grouping a set of networks which fall under the same administrative umbrella. If, how- ever, within the group of networks there is more than one routing policy, then more than one AS is involved. On the other hand, if the set of networks has the same routing policy as another set, they fall under the same AS, regardless of the adminis- trative structure. Thus by definition, all networks in an autonomous system share a single routing pol- icy. In order to help decrease global routing complexity, a new AS number should be created only if a new routing policy is required. Sharing an AS number among a set of networks that do not fall under the same organisational umbrella will sometimes require extra coordination among the various network admin- istrators. In some cases, some level of network reengineering may be needed. However, this is proba- bly the only way to implement the desired routing policy anyway. Please see (RFC 1930 [Hawkinson96a]) for more information. 7.1. Obtaining an AS Number The RIPE NCC assigns AS numbers for Autonomous Sys- tems that are located in the area that is served by the RIPE NCC. As for IP address requests the RIPE NCC only accepts requests for AS numbers from Local IRs that contribute to the RIPE NCC. The forms should be submitted to <hostmaster(a)ripe.net>. ____________________________________________________ ripe-185.txt Page 66 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ To obtain an AS number the RIPE NCC provides a form similar to the one that is used to submit IP address requests. The form contains four parts, an aut-num (autonomous system number) object template, a tech- nical template, a mntner (maintainer) template, and one or more person templates. All of the information on the form is required. The NCC may sometimes also ask for additional information in order understand the planned routing policy and to decide if an AS number is really needed. The information provided in the templates will be entered into the database and is publicly accessible. The templates are described in more detail below. Aut-num Object The aut-num object template specifies a description of the organisation applying for the AS number and the contact persons. The aut-num object has among others the mandatory fields aut-num, descr, admin-c, tech-c, and mnt-by. The aut-num field specifies the number to be assigned. The admin-c and tech-c are to be specified as nic-handles. The mnt-by (maintain by) attribute is a reference to a mntner (maintainer) object in the database which describes those authorised to make changes to the object. Mntner Object A mntner (maintainer) object is mandatory for each aut-num object in the database. It designates where updates to the aut-num information should be send. In case a maintainer object is not registered yet in the database please send it together with the request for an AS number. The maintainer object templates contains, among oth- ers, the mandatory fields mntner, descr, admin-c, tech-c, auth, upd-to, mnt-by, notify, changed, and source fields. For more information about maintainer objects, see (ripe-120 [Karrenberg94b]). ____________________________________________________ ripe-185.txt Page 67 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ Person Objects In order to facilitate handling the AS number request and debugging of routing problems that may arise once the AS is operational, it is necessary to have contact persons (admin-c and tech-c) registered with each aut-num object. A person template is needed for the administrative contact and the tech- nical contact, unless they are already entered in the database. The administrative contact should be physically located at the enterprise requesting the AS number. These templates contain among others, the fields person, address, phone, fax-no, nic-hdl, and e-mail fields. In each template, the appropriate person's name should be specified in full. 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 full e-mail address should be specified. Technical Details Current assignment guidelines require a network to be multihomed for an AS number to be assigned. When a registry applies for an ASN, it needs to submit the routing policy of the Autonomous System that requires an AS number. The policy is defined in the following attributes as part of the aut-num object: multiple fields of as-in (description of accepted routing information from neighbouring ASes.), multi- ple fields of as-out (description of generated rout- ing information sent to other AS peers.), one or more fields of default (indication of how default routing is done). Evaluation and Assignment A completed form should be send to the RIPE NCC hostmaster mailbox. It will then be evaluated to determine whether an AS number is really needed. If an AS number is assigned, the NCC will enter all relevant information in the database and will notify the Local IR of the assignment. ____________________________________________________ ripe-185.txt Page 68 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 7.2. Returning an AS Number If an oranisation has an AS number that is no longer in use, it can be returned to the public pool of AS numbers by sending a message to <hostmas- ter(a)ripe.net>, it can then be re-assigned to another autonomous system by the RIPE NCC. ____________________________________________________ ripe-185.txt Page 69 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 8. Interdomain (Exterior) Routing Considerations Address space allocation and assignment policies are closely related to exterior routing considerations. In fact, routing issues have played a key role in defining the policies regarding address space dis- tribution described in this document. Specifically, decisions regarding address space allocations and assignments must be made to facilitate the routabil- ity of the assigned IP numbers, and to minimise the complexity of routing on the Internet as a whole. This is the key reason that aggregation plays a cen- tral role in address space allocation and assignment policies. Each and every host on the Internet has a routing table, ever so small, which tells it where to send packets intended for a certain destination address. In this section, we will discuss how route announce- ments are used to build these tables, and the role of aggregation in keeping them small. We will also describe use of the routing registry for management of global routing policies, and some tools available for examining the consistency of routing policy among ISPs. ISPs are encouraged to follow discussions in the relevant groups such as <routing-wg(a)ripe.net>, <eof(a)ripe.net>, and <cidrd(a)iepg.org>. Information about the first two can be obtained by sending e- mail to <majordomo(a)ripe.net> with "list" in the body of the message. For the last, the e-mail should be addressed to <cidrd-request(a)iepg.org>. 8.1. Originating Routing Information Having assigned address space to an end user for use in a network, one must provide some means for the machines on that network to communicate with others on the Internet. That is, one must somehow announce to the rest of the Internet where packets destined for those hosts can be sent. This process is referred to as originating route information whereby the rest of the Internet can reach the hosts using the corresponding address space. In practice, these announcements are made via rout- ing protocols. An AS interconnects with one or more neighbouring ASes by announcing the set of addresses which should be routed to it. The most common ____________________________________________________ ripe-185.txt Page 70 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ routing protocol in use by ASes for exchanging this information is BGP as defined in (RFC 1771 [Rekhter95a]). Information on how to configure par- ticular routing hardware can be found in [Nuss- bacher96a]. Of course, an ISP should only originate routes for public address space that has been allocated to it, or that has been assigned to the customer for whom the ISP will provide connectivity. A route should never be announced for private address space. Before announcing a route, one should always consult the RIPE database to confirm the associated address space allocation or assignment. If possible, ISPs should originate CIDR routes cov- ering their entire allocations. Unless absolutely necessary, ISPs should not originate more specific routes. Unless a network is multi-homed, more than one announcement leading to the associated address space is likely to be due to a configuration error. 8.2. Propagating Routing Announcements In addition to originating routes, ASes propagate routes from other ASes to their neighbours, which if all goes well, allows communication between any two hosts with addresses announced on the Internet. In order to keep the Internet as a whole running smoothly, ISPs that propagate routes should operate according to a number of established principles: 1) Routes should only be propagated if the associated address space has been properly reg- istered in the database of one of the regional registries. 2) When propagating routes, one should take care to ensure overall connectivity. Routing policies which limit the connectivity of other ISPs should be avoided. 3) If ISPs implement routing policies that limit the length of prefixes propagated or accepted, they should always allow routes with prefixes in line with the minimum size of an allocation in the associated address space. For the address space distributed by the RIPE NCC (193/8, 194/8 and 195/8), the minimum alloca- tion is a /19. Thus any routing policy that accepts this prefix length for addresses in this range, will enable connectivity for the associated hosts in the RIPE NCC service area. ____________________________________________________ ripe-185.txt Page 71 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ Any routing policy which does not propagate at least /19 prefixes is likely to cause connec- tivity problems for these and numerous other hosts on the Internet. ISPs can use the RIPE database when defining their routing policies. It provides information about valid allocations and assignments as well as the type (PI/PA) of address space. 8.3. Aggregation It is important that ISPs engineer their network with a clear distinction between their internal routing and external routing. In central routers on the Internet the load on the routers caused by (unnecessary) routing information and routing updates is considerable, and is known to lead to network failures. One means to achieve a stable connection with the global Internet is to aggregate routes as much as possible. In most cases there is no need for more specific routes to customer networks. However, if the customers for whom you are providing connectivity are using address space that was not assigned from your allocation, it is strongly recom- mended that they renumber their networks to use PA address space. Only then can their networks be reached without specific announcements. This is true both for customers using PI address space, and for those with PA address space that was assigned by another ISP. In the first case, it is seldom that PI addresses are really needed. In the latter case, the fact that the address space is PA means that the customer has agreed to renumber upon changing ISPs. 8.4. Registering Routes in the RIPE Database. When originating a route, it should be properly doc- umented in the routing registry. This is done by submitting a route object as described in (ripe-181 [Bates94a]) to the RIPE Database. Each route is originated by an Autonomous System (AS), and the origin attribute of the route object links to the aut-num object describing the routing policy of the AS. ____________________________________________________ ripe-185.txt Page 72 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ There are a number of useful tools available which employ the information in the routing registry in the process of deciding on routing policy and for trouble shooting. Here is a short summary: prtraceroute Trace the route that packets take to a given host, showing for each router on the way the number of the AS it belongs to, and how the route taken relates to routing policy stored in the routing registry. prpath Print all the possible paths between any two given destinations according to the routing registry. prcheck Check the syntax semantics and validity of an aut-num object. An extensive tutorial on the Routing Registry is available in [Bates94b]. ____________________________________________________ ripe-185.txt Page 73 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 9. Glossary This section provides a very bried description of important terms used in this document. Allocation In general higher level IRs allocate address space to lower level IRs who hold this address space for further allocation or assignment to end-users. Assignment IRs assign address space to the end-user who then use it in operational networks. Classless Addressing Historically IP addresses have been assigned in the form of network numbers of class A, B or C. With the advent of classless inter-domain routing (CIDR) this classful restrictions are no longer valid. ____________________________________________________ ripe-185.txt Page 74 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ Address space is now allocated and assigned on bit boundaries. The following table illustrates this: +----------------------------------------------+ |addrs bits pref class mask | +----------------------------------------------+ | 1 0 /32 255.255.255.255 | | 2 1 /31 255.255.255.254 | | 4 2 /30 255.255.255.252 | | 8 3 /29 255.255.255.248 | | 16 4 /28 255.255.255.240 | | 32 5 /27 255.255.255.224 | | 64 6 /26 255.255.255.192 | | 128 7 /25 255.255.255.128 | | 256 8 /24 1C 255.255.255 | | 512 9 /23 2C 255.255.254 | | 1K 10 /22 4C 255.255.252 | | 2K 11 /21 8C 255.255.248 | | 4K 12 /20 16C 255.255.240 | | 8K 13 /19 32C 255.255.224 | | 16K 14 /18 64C 255.255.192 | | 32K 15 /17 128C 255.255.128 | | 64K 16 /16 1B 255.255 | | 128K 17 /15 2B 255.254 | | 256K 18 /14 4B 255.252 | | 512K 19 /13 8B 255.248 | | 1M 20 /12 16B 255.240 | | 2M 21 /11 32B 255.224 | | 4M 22 /10 64B 255.192 | | 8M 23 /9 128B 255.128 | | 16M 24 /8 1A 255 | | 32M 25 /7 2A 254 | | 64M 26 /6 4A 252 | | 128M 27 /5 8A 248 | | 256M 28 /4 16A 240 | | 512M 29 /3 32A 224 | |1024M 30 /2 64A 192 | +----------------------------------------------+ 'bits' size of the allocation/assignment in bits of address space. 'addrs' number of addresses available; note that the number of addressable hosts normally is 2 less than this number because the host parts with all equal bits (all 0s, all 1s) are reserved. ____________________________________________________ ripe-185.txt Page 75 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 'pref' length of the route prefix covering this address space. This is sometimes used to indi- cate the size of an allocation/assignment. 'class' size of the address space in terms of classful network numbers. 'mask' The network mask defining the routing prefix in dotted quad notation. Throughout this document we refer to the size of allocation and assignments in terms of 'bits of address space' and add the length of the route pre- fix in parentheses wherever appropriate. ____________________________________________________ ripe-185.txt Page 76 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ References Albitz94a. Paul Albitz and Cricket Liu, DNS and BIND, O'Reilly & Associates, Inc., Sebastopol, CA (1994). Bates94a. T. Bates, E. Gerich, L. Joncheray, JM. Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu, Representation of IP Routing Policies in a Routing Registry, ripe-181 (10/1994). Bates94b. T. Bates, D. Karrenberg, and M. Terpstra, The PRIDE Guide (10/1994). Beertema93a. P. Beertema, Common DNS Data File Configuration Errors, RFC 1537 (10/1993). Caslav97a. P. Caslav and J. Crain, RIPE NCC Consistency & Auditing Activity, ripe-170 (12/1997). Caslav96a. P. Caslav, M. Kuehne, and C. Orange, European IP Address Space Request Form, ripe-141 (09/1996). Caslav98a. P. Caslav and M. Muit, Guidelines for Setting up a Local Internet Registry, ripe-160 (04/1998). Deering89a. S. Deering, Host Extensions for IP Multicast- ing, RFC 1112 (08/1989). Eidnes98a. H. Eidnes, G. de Groot, and P. Vixie, Classless in-addr.arpa delegation, RFC 2317 (03/1998). Fuller93a. V. Fuller, T. Li, J. Yu, and K. Varadham, Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy, RFC 1519 (09/1993). Gerich93a. E. Gerich, Guidelines for Management of IP Address Space, RFC 1466 (05/1993). ____________________________________________________ ripe-185.txt Page 77 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ Hawkinson96a. J. Hawkinson and T. Bates, Guidelines for cre- ation, selection, and registration of an Autonomous System, RFC 1930 (03/1996). Karrenberg94a. D. Karrenberg, RIPE NCC Request Tracking and Ticketing, ripe-183 (03/1994). Karrenberg95a. D. Karrenberg, Provider Independent vs Provider Aggregatable Address Space, ripe-127 (06/1995). Karrenberg94b. D. Karrenberg and M. Terpstra, Authorisation and Notification of Changes in the RIPE Database, ripe-120 (10/1994). Kuehne95a. M. Kuehne and D. Karrenberg, 2nd Meeting of the RIPE NCC Contributors Committee Minutes, ripe-132 (10/1995). Magee97a. A. M. R. Magee, RIPE NCC Database Documenta- tion, ripe-157 (05/1997). Norris96a. M. Norris, Charging by Local Internet Reg- istries, ripe-152 (04/1996). Nussbacher96a. H. Nussbacher, The CIDR FAQ, http://www.ibm.net.il/~hank/cidr.html (05/1996). Postel94a. J. Postel, Domain Name System Structure and Delegation, RFC 1591 (03/1994). Rekhter93a. Y. Rekhter and T. Li, An Architecture for IP Address Allocation with CIDR, RFC 1518 (09/1993). Rekhter95a. Y. Rekhter and T. Li, A Border Gateway Protocol 4 (BGP-4), RFC 1771 (03/1995). Rekhter96a. Y. Rekhter and T. Li, Implications of Various Address Allocation Policies for Internet Rout- ing, RFC 2008 (08/1996). ____________________________________________________ ripe-185.txt Page 78 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ Rekhter96b. Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, and E. Lear, Address Allocation for Pri- vate Internets, RFC 1918 (02/1996). ____________________________________________________ ripe-185.txt Page 79

2 1

RIPE NCC comments on new IANA drafts published on September 17th
by Daniel Karrenberg 20 Sep '98

20 Sep '98

RIPE NCC Statement on the Draft Articles and Bylaws for the new IANA as published on September 17th 1998 Amsterdam, September 18th 1998 The RIPE NCC executive board,representing the RIPE NCC membership, has considered the draft articles and bylaws for the new IANA published jointly by NSI and the IANA on September 17th. We note that there are a considerable number of substantive changes from those previous draft documents published by the IANA which we publicly supported as the basis for further development. Given the number and the substance of the changes there has been insufficient time for due consideration and consultation. Yet the authors of the latest drafts indicate that they wish to proceed 'within a day or two'. With this in mind we have to state now that at this time the RIPE NCC cannot support the current drafts or commit to participate in a new IANA constituted by them. We need sufficient time to consider all the changes and in particular: - Codifying in the bylaws that the new IANA will a-priori respect arrangements between third parties without any knowledge of them. This requires careful consideration because of the far reaching implications such arrangements may have on the new IANA. (IV/1d) - We need to understand and consider the material consequences of art IV/1e in order to determine whether it is acceptable. - We are still concerned about the room for interpretation in art V/6 and would like to see a stronger requirement of diversity than allowing 50% of the board to be from one region. - We need to understand and consider the far-reaching repercussions of codifying, at this stage, aspects of a possible membership structure that previously were left for the Initial Board to define and implement. In this context we also need to re-evaluate the fact that the board members nominated by the supporting organisations have no say at all in how it is implemented (V/4b/iv V/9c). - We need to understand the reasons and the material consequences of the weakening of the language in VI/c which now speaks of recommendations by the supporting organisations to the board. - We need to get clarification that the change in wording of art III/2 does not now imply that minutes of supporting organisation bodies have to be approved by the Board of the new IANA. - We need to fully understand and consider the consequences of the changes made to the requirements for supporting organisations, especially VI/2 and VI/3b. In the area of the address supporting organisation the participation of individuals and individual organisations currently happens at the local and regional levels. We need to understand whether the bylaws allow for this practice to continue or if they constrain the supporting organisations sufficiently to require changes in these structures. We stress that we have no issue with the added openness requirements. We will work to resolve the remaining issues with all parties concerned as soon as possible. The upcoming series of RIPE and related meetings in Edinburgh between September 21st and 25th will provide a good opportunity to make progress in our geographical area. We urge all concerned not to proceed with the current proposal before these concerns are addressed and we have had the opportunity to ensure that the RIPE NCC can participate fully in the new IANA. In the meantime the current IANA should continue to function and provide its services to us. We are willing to immediately and unilaterally contribute US$ 50k towards the operational costs of the current IANA after September 30th.

1 0

LIR WG meeting, revised draft agenda
by Mike Norris 18 Sep '98

18 Sep '98

Here is a revised agenda for the LIR WG meeting, which takes place at 11:00 on Wednesday 23rd Sep. Many thanks for the comments and additions. Mike Norris RIPE 31 - 23rdth to 25th September 1998 Local IR Working Group D R A F T A G E N D A 1. Selection of chair 2. Admin - scribe - agenda - meet the RIPE NCC hostmasters 3. RIPE 30 - minutes - actions 4. Reports from registries - IANA and structures (see also TLD WG) - European regional (RIPE NCC) - other regionals - APNIC, ARIN, AfriNIC 5. IP Address Space Assignment - distribution robot, document (NCC) - review of allocation rules, ripe-159 (NCC) - web interface to ripe-141 forms - IPv6 address allocation (IETF draft) - IPv8 ? 6. I/O with other WGs 7. Statistics - reverse DNS counts, quality 8. AOB

1 0

Re:ripe-159 changes
by UUNET Support 12 Sep '98

12 Sep '98

Hello all, At the last RIPE Meeting we were asked to make a change in the policy on allocations that an allocation only needs to be 80% used up instead of 90% before receiving a new one. After discussing it with the other Regional Registries, we have decided to go ahead with this change. This means that the Policies and Procedures document currently ripe-159 needs to be updated. At the same time Ive taken the opportunity to also include a few new sections in the document on practices that are already in place and should be mentioned. Below Ive included all the new/changed sections. Though theres also a few minor changes, mainly in documents/rfcs that have changed Please send us any comments you may have, before we publish the final document. By the way, there was a discussion on this list and the database working group mailing list a few weeks about version numbers of RIPE documents. As a result of that weve decided to start referencing RIPE documents by their titles and not their numbers on the web site and in other documents. The documents will still have a ripe-xxx number, so that you can see what the latest version is, but all references will be to the title instead of the number. Therefore, ripe-159 will changed to ripe-185, but the web site link will be to the document title once its officially published. Kind regards, Paula Caslav Registration Services Manager RIPE NCC Here is the list of major changes: Changed section 4.3 Further Allocations as decided at RIPE meeting: > 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 their last alloca- > tion, however the RIPE NCC will check all the pre- > vious allocations for 80% usage as well. Changed section 6.2 Establishing a New Registry shortened it and mainly pointed to ripe-160 so that the procedure is only documented in one place and changes can be made more easily. > 6.2. Establishing a New Registry > > A local IR is established after submitting a request > to the RIPE NCC which includes assurances that the > relevant rules and guidelines defined in this and > related documents are known and a commitment that > they will be followed. The process of setting up a > new registry is explained in detail in Guidelines > for Setting up a Local Internet Registry currently > ripe-160 [Caslav98a]. Added under section 6.4 Registry Operations: > External Quality Assurance > > In order to promote consistent and fair application > of assignment criteria with regard to conservation > and registration of address space and aggregation of > routing information, the RIPE NCC has started an > activity of consistency checking of registry data > and auditing of registries. To ensure that reg- > istries are following the assignment criteria, and > entering assignments into the database correctly, > the RIPE NCC may contact a registry to ask for docu- > mentation or more information about certain requests > or database entries. If the NCC finds problems, it > will work with the registry to correct these, and > may take disciplinary action, such as lowering the > registrys Assignment Window. This activity is > described in-depth in RIPE NCC Consistency & Audit- > ing Activity currently ripe-170 [Caslav97a]. Added under same section: > Distribution Robot > > The RIPE NCC uses an automatic robot to distribute > all messages sent to <hostmaster(a)ripe.net> and to do > syntax checking on IP address space requests. For > help on interacting with the robot, please see the > RIPE NCC web site at: > > http://www.ripe.net/lir/services/status.html Added new section 6.5 that allocations cant be transfered without RIPE NCC permission is already mentioned elsewhere, but I wanted a separate section to specifically point this out- weve had a few cases lately of registries changing owners without telling us: > 6.5. When a Registry Changes Ownership > > If a Local Internet Registry changes ownership > because it is sold, or merges with another com- > pany, the RIPE NCC should be contacted about the > change in ownership. Depending on the case, the RIPE > NCC may need to request a new service agreement from > the new owners. Also, if all of the contact persons > who will be sending requests have changed, the NCC > may lower the assignment window of the registry > until the new contacts are up-to-date on the RIPE > NCC procedures and policies. > > Sometimes a registry is taken over or merged with > another, already existing registry. The RIPE NCC > needs to be notified in this case as well. The reg- > istries in question will need to discuss with the > NCC what will be done with the allocations in case > one of the registries is closing. An allocation can- > not be transfered from one registry to another or > to a non-registry without contacting the RIPE NCC > first. A registry cannot have more than one open > less than 80% used up allocation, so sometimes > transfering all allocations is not possible. Please > discuss these issues with <hostmaster(a)ripe.net>. And here is the entire document itself. European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group Document ID: ripe-185 Date Published: July 23, 1998 Obsoletes: ripe-104, ripe-105, ripe-136, ripe-140, ripe-159 ABSTRACT The distribution of IP address space follows the hierarchical scheme described in RFC 1466 [Gerich93a]. For Europe and parts of the surrounding area address space is allocated by IANA to the RIPE NCC which acts as a regional Internet reg- istry. Address space is allocated by the RIPE NCC to Local Internet Registries IRs, who assign it to to end users. In this document, we describe the policies and procedures associated with address space management that must be followed by local IRs. Moreover, we present a number of services available to local IRs to sim- plify the tasks associated 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 ____________________________________________________ ripe-185.txt Page 1 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ European guidelines. While providing an overview about the global Internet registry system this docu- ment does not describe allocation and assignment rules used by other regional registries. This document has been produced by the RIPE Local Internet Registry LIR Working Group with the help of an editing committee consisting of: P. Caslav RIPE NCC S. Dolderer DE NIC D. Karrenberg RIPE NCC M. Kuehne RIPE NCC M. Norris HEANET C. Orange RIPE NCC W. Woeber ACONET J. Zsako Banknet H.P. Holen Schibsted Nett 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. Section 3 Address Space Assignment Procedures describes the procedures to be followed by European IP registries 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 ____________________________________________________ ripe-185.txt Page 2 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ delegation, and explains how registries can manage subsidiary reverse delegation of assigned address space. Section 6 Operating a Local Internet Registry describes a number of services offered by the RIPE NCC to facilitate the uniform implementation of the policies outlined in this document, and outlines procedures associated with IP registration services which Local IRs are expected to follow. Section 7 AS Number Assignment Policies and Proce- dures explains the procedures to be followed by European IP registries when requesting an autonomous system number. Section 8 Interdomain Exterior Routing Considera- tions discusses interdomain routing issues such as originating routing information; propagating routing announcements; aggregation and registering routes in the database and their role in defining the poli- cies regarding address space distribution described in this document. We conclude with a glossary in which the key terms used in this document are defined. ____________________________________________________ ripe-185.txt Page 3 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 in Section 2.2. The main purpose of this address space is to allow communication using IPv4 over the Internet. A secondary purpose is to allow communication using IPv4 over interconnected private internets. One can currently distin- guish two kinds of public addresses: provider independent PI and provider aggregatable PA addresses; see Section 2.4 for more details. More information about PI and PA address space can also be found in ripe-127 [ Karren- berg95a]. 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 RFC 1918 [Rekhter96b]. Special and Reserved Addresses There are a number of address ranges reserved for applications like multicasting. These are described elsewhere cf RFC 1112 [Deering89a] and are beyond the scope of this document. ____________________________________________________ ripe-185.txt Page 4 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 guaran- tees that every host on the Internet can be uniquely identified. In addition to the uniqueness requirement, pub- lic 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 these goals are pursued. It is worth noting that Conservation and Aggregation are often conflicting goals, and therefore that each ____________________________________________________ ripe-185.txt Page 5 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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-185.txt Page 6 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 2.3. The Internet Registry System The Internet Registry system has been established to achieve the goals stated in Section 2.2. It con- sists of hierarchically organized Internet Reg- istries 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 organi- zations 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 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 ARIN serving North America, the APNIC serving the Asian Pacific region, and the RIPE NCC serving Europe and surrounding areas. Since these do not cover all geographical 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-185.txt Page 7 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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-185.txt Page 8 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ The European IR System For Europe, the Internet Registry System hierarchy consists of the following entities from the top down: IANA, the RIPE NCC, and Local IRs. 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 providers 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 users 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 users organization will have to be reconfigured. The end user will need to obtain a new address space assign- ment, and return the previously assigned address space. To ensure the address space is properly returned, a clear, preferably contractual, under- standing is needed between the Local IR 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. Provider Independent Address Space In contrast to PA address space, PI address space can remain assigned to its user as long as the ____________________________________________________ ripe-185.txt Page 9 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ criteria for the original assignment are met. The duration of the assignment is independent of the use of a particular providers services. The apparent advantage of PI address space is that a users 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- ment is made for a specific purpose and the purpose no longer exists, then the assignment is no longer valid. If an assignment is based on information that turns out to be invalid so is the assignment. ____________________________________________________ ripe-185.txt Page 10 European Internet Registry Policies and Procedures RIPE Local Internet Registry Working Group ____________________________________________________ 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 current address space usage template and in the addressing plan as described in the next section. The amount of address space assigned must be justified by this documenta- tion. This means that address space assigned in the past should be used to meet the current request if possible. Once an organisation has used its assigned address space, it can request

1 0