- lir-wg - mailman.ripe.net

Re: RFC1366 Revision
by Havard.Eidnes＠runit.sintef.no 16 Feb '93

16 Feb '93

> These criteria are not intended to cause a subscriber to subnet Class > C networks. If the subscriber's network is divided into logically > distinct LANs across which it would be difficult to use the given > number of Class C network numbers, the above criteria may apply on a > per-LAN basis. For example, if a subscriber has 600 hosts equally > divided across ten Ethernets, the allocation to that subscriber would > be ten Class C network numbers; one for each Ethernet. Exceptions from > the stated criteria would be determined on a case-by-case basis. Oh, well... If some of you remember the form I sent to you as input to the common form, I specifically stated that even a class C network can be subnetted, and that such a strategy could be useful to conserve some address space. From the above, I read that this is not the intention anymore. Can someone explain why? (This is a section where the new version differs a bit from RFC 1366.) - Havard

2 1

RFC1366 Revision
by Daniel Karrenberg 16 Feb '93

16 Feb '93

Dear clolleagues, please find a proposed revision of RFC1366 below. We at the NCC would be interested in yur comments which we will take to both the author and the IEPG. Let's have some internal discussion and I'll collate all comments into a general European statement. After a first reading I think this version is an improvement over the previous one. Especially the clarification on block 193.x.y.z and the improves section 4.2 should be noted. Daniel Network Working Group E. Gerich Request for Comments: 1366 Merit January 1993 Guidelines for Management of IP Address Space Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Abstract This document has been reviewed by the Federal Engineering Planning Group (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the Intercontinental Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. 1.0 Introduction With the growth of the Internet and its increasing globalization, much thought has been given to the evolution of the network number allocation and assignment process. RFC 1174, "Identifier Assignment and Connected Status", [1] dated August 1990 recommends that the Internet Registry (IR) continue as the principal registry for network numbers; however, the IR may allocate blocks of network numbers and the assignment of those numbers to qualified organizations. The IR will serve as the default registry in cases where no delegated registration authority has been identified. The distribution of the registration function is desirable, and in keeping with that goal, it is necessary to develop a plan which manages the distribution of the network number space. The demand for network numbers has grown significantly within the last two years and as a result the allocation of network numbers must be approached in a more systematic fashion. This document proposes a plan which will forward the implementation of RFC 1174 and which defines the allocation and assignment of the network number space. There are three major topics to be addressed: 1) Qualifications for Distributed Regional Registries 2) Allocation of the Network Number Space by the Internet Registry 3) Assignment of the Network Numbers 2.0 Qualifications for Distributed Regional Registries The major reason to distribute the registration function is that the Internet serves a more diverse global population than it did at its inception. This means that registries which are located in distinct geographic areas may be better able to serve the local community in terms of language and local customs. While there appears to be wide support for the concept of distribution of the registration function, it is important to define how the candidate delegated registries will be chosen and from which geographic areas. Based on the growth and the maturity of the Internet in Europe, North America, Central/South America and the Pacific Rim areas, it is desirable to consider delegating the registration function to an organization in each of those geographic areas. Until an organization is identified in those regions, the IR will continue to serve as the default registry. The IR remains the root registry and continues to provide the registration function to all those regions not covered by distributed regional registries. And as other regions of the world become more and more active in the Internet, the Internet Assigned Numbers Authority (IANA) and the IR may choose to look for candidate registries to serve the populations in those geographic regions. It is important that the regional registry is unbiased and and widely recognized by network providers and subscribers within the geographic region. It is also important that there is just a single regional registry per geographical region at this level to provide for efficient and fair sub-allocation of the address space. To be selected as a distributed regional registry an organization should meet the following criteria: a) networking authorities within the geographic area legitimize the organization, b) the organization is well-established and has legitimacy outside of the registry function, c) the organization will commit appropriate resources to provide stable, timely, and reliable service to the geographic region, d) is committed to allocate IP numbers according to the guidelines established by the IANA and the IR, and e) is committed to coordinate with the IR to establish qualifications and strategies for sub-allocations of the regional allocation. The distributed regional registry is empowered by the IANA and the IR to provide the network number registration function to a geographic area. It is possible for network subscribers to contact the IR directly. Depending on the circumstances the network subscriber may be referred to the regional registry, but the IR will be prepared to service any network subscriber if necessary. 3.0 Allocation of the Network Number Space by the Internet Registry The Class A portion of the number space represents 50% of the total IP host addresses; Class B is 25% of the total; Class C is approximately 12% of the total. Table 1 shows the current allocation of the IP network numbers. Total Allocated Allocated (%) Class A 126 49 38% Class B 16383 7354 45% Class C 2097151 44014 2% Table 1: Network Number Statistics (June 1992) [2] Class A and B network numbers are a limited resource and therefore allocations from this space will be restricted. The entire Class A number space will be retained by the IANA and the IR. No allocations from the Class A network numbers will be made to distributed regional registries at this time. (See section 4.1.) Allocations from the Class B network number space will be restricted also. Small blocks of numbers may be allocated to regional registries, which will be required to ensure that the allocation guidelines are met. The IR will monitor those allocations. (See section 4.2.) It is proposed that the IR, and any designated regional registries, allocate addresses in conformance with this overall scheme. Where there are qualifying regional registries established, primary responsibility for allocation within that block will be delegated to that registry. It should be noted that the Reseaux IP Europeens Network Coordination Center (RIPE NCC) had been allocated a block of Class C addresses (193.0.0 - 193.255.255) prior to the adoption of this proposal. The RIPE NCC has agreed to allocate the addresses within that block according to the guidelines stated in this RFC. The Class C network number space will be divided into allocatable blocks which will be reserved by the IANA and IR for allocation to distributed regional registries. In the absence of designated regional registries in geographic areas, the IR will assign addresses to networks within those geographic areas according to the Class C allocation divisions. Inspection of the Class C IP network numbers shows that the number space with prefixes 192 and 193 are assigned. The remaining space from prefix 194 through 223 is mostly unassigned. The IANA and the IR will reserve the upper half of this space which corresponds to the IP address range of 208.0.0.0 through 223.255.255.255. Network numbers from this portion of the Class C space will remain unallocated and unassigned until further notice. The remaining Class C network number space will be allocated in a fashion which is compatible with potential address aggregation techniques. It is intended to divide this address range into eight equally sized address blocks. 192.0.0.0 - 193.255.255.255 194.0.0.0 - 195.255.255.255 196.0.0.0 - 197.255.255.255 198.0.0.0 - 199.255.255.255 200.0.0.0 - 201.255.255.255 202.0.0.0 - 203.255.255.255 204.0.0.0 - 205.255.255.255 206.0.0.0 - 207.255.255.255 Each block represents 131,072 addresses or approximately 6% of the total Class C address space. It is proposed that a broad geographic allocation be used for these blocks. At present there are four major areas of address allocation: Europe, North America, Pacific Rim, and South & Central America. In particular, the top level block allocation be designated as follows: Multi-regional 192.0.0.0 - 193.255.255.255 Europe 194.0.0.0 - 195.255.255.255 Others 196.0.0.0 - 197.255.255.255 North America 198.0.0.0 - 199.255.255.255 Central/South America 200.0.0.0 - 201.255.255.255 Pacific Rim 202.0.0.0 - 203.255.255.255 Others 204.0.0.0 - 205.255.255.255 Others 206.0.0.0 - 207.255.255.255 It is proposed that the IR, and any designated regional registries, allocate addresses in conformance with this overall scheme. Where there are qualifying regional registries established, primary responsibility for allocation from within that block will be delegated to that registry. The ranges designated as "Others" permit flexibility in network number assignments which are outside of the geographical regions already allocated. The range listed as multi-regional represents network numbers which have been assigned prior to the implementation of this plan. It is proposed that the IANA and the IR will adopt these divisions of the Class C network number space and will begin assigning network numbers accordingly. 4.0 Assignment of the Network Number Space The exhaustion of the IP address space is a topic of concern for the entire Internet community. This plan for the assignment of Class A, B, or C IP numbers to network subscribers has two major goals: 1) to reserve a portion of the IP number space so that it may be available to transition to a new numbering plan 2) to assign the Class C network number space in a fashion which is compatible with proposed address aggregation techniques 4.1 Class A The Class A number space can support the largest number of unique host identifier addresses and is also the class of network numbers most sparsely populated. There are only approximately 77 Class A network numbers which are unassigned, and these 77 network numbers represent about 30% of the total address space. The IANA and the IR will retain sole responsibility for the assignment of Class A network numbers. The upper half of the Class A number space will be reserved indefinitely (IP network addresses 64.0.0.0 through 127.0.0.0). While it is expected that no new assignments of Class A numbers will take place in the near future, any organization petitioning the IR for a Class A network number will be expected to provide a detailed technical justification documenting network size and structure. Class A assignments are at the IANA's discretion. 4.2 Class B Previously, organizations were recommended to use a subnetted Class B network number rather than multiple Class C network numbers. Due to the scarcity of Class B network numbers and the underutilization of the Class B number space by most organizations, the recommendation is now to use multiple Class Cs where practical. The restrictions in allocation of Class B network numbers may cause some organizations to expend additional resources to utilize multiple Class C numbers. This is unfortunate, but inevitable if we implement strategies to control the assignment of Class B addresses. The intent of these guidelines is to balance these costs for the greater good of the Internet. 4.2.1 An organization applying for a Class B network number must submit an engineering plan that documents its need for a Class B network number. This document must demonstrate that it is unreasonable to engineer its network with a block of class C network numbers. The engineering plan must include how many hosts the network will have within the next 24 months and how many hosts per subnet within the next 24 months. If it is deemed that the applicant's engineering plan, including the number of hosts and subnets, does not warrant a Class B assignment, the applicant will be allocated a block of Class C addresses. 4.2.2 The IR may allocate small blocks of Class B network numbers to regional registries if so doing will improve the service that is being provided to the community. The IR may issue more specific guidelines for the further assignment of the numbers which will be consistent with the stated guidelines. The IR may require accounting of the block assignment including receipt of the applicants' engineering plans. The IR may audit these engineering plans to confirm that the assignments are consistent with the guidelines. 4.3 Class C Section 3 of this document recommends a division of the Class C number space. That division is primarily an administrative division which lays the groundwork for distributed network number registries. This section addresses assignment of network numbers from within regional block assignments. Sub-allocations of the block to sub-registries is beyond the scope of this paper. By default, if an organization requires more than a single Class C, it will be assigned a bit-wise contiguous block from the Class C space allocated for its geographic region. For instance, an European organization which requires fewer than 2048 unique IP addresses and more than 1024 would be assigned 8 contiguous class C network numbers from the number space reserved for European networks, 194.0.0.0 - 195.255.255.255. If an organization from Central America required fewer than 512 unique IP addresses and more than 256, it would receive 2 contiguous class C network numbers from the number space reserved for Central/South American networks, 200.0.0.0 - 201.255.255.255. The IR or the registry to whom the IR has delegated the registration function will determine the number of Class C network numbers to assign to a network subscriber based on the subscriber's 24 month projection of required end system addresses according to the following criteria: Organization Assignment 1) requires fewer than 256 addresses 1 class C network 2) requires fewer than 512 addresses 2 contiguous class C networks 3) requires fewer than 1024 addresses 4 contiguous class C networks 4) requires fewer than 2048 addresses 8 contiguous class C networks 5) requires fewer than 4096 addresses 16 contiguous class C networks 6) requires fewer than 8192 addresses 32 contiguous class C networks 7) requires fewer than 16384 addresses 64 contiguous class C networks These criteria are not intended to cause a subscriber to subnet Class C networks. If the subscriber's network is divided into logically distinct LANs across which it would be difficult to use the given number of Class C network numbers, the above criteria may apply on a per-LAN basis. For example, if a subscriber has 600 hosts equally divided across ten Ethernets, the allocation to that subscriber would be ten Class C network numbers; one for each Ethernet. Exceptions from the stated criteria would be determined on a case-by-case basis. If a subscriber has a requirement for more than 4096 unique IP addresses it could conceivably receive a Class B network number. However, there are cases where a subscriber may request a larger block of Class C network numbers. For instance, if an organization requires fewer than 8192 addresses and requests 32 Class C network addresses, the regional registry may honor this request. The maximal block of Class C network numbers that should be assigned to a subscriber consists of 64 contiguous Class C networks. This would correspond to a single IP prefix of 18 bits. 5.0 Conclusion This proliferation of class C network numbers may aid in preserving the scarcity of class A and B numbers, but it is sure to accelerate the explosion of routing information carried by Internet routers. Inherent in these recommendations is the assumption that there will be modifications in the technology to support the larger number of network address assignments due to the decrease in assignments of Class A and B numbers and the proliferation of Class C assignments. Many proposals have been made to address the rapid growth of network assignments and a discussion of those proposals is beyond the scope and intent of this paper. These recommendations for management of the current IP network number space only profess to delay depletion of the IP address space, not to postpone it indefinitely. 6.0 Acknowledgements The author would like to acknowledge the substantial contributions made by the members of the following two groups, the Federal Engineering Planning Group (FEPG) and the Intercontinental Engineering Planning Group (IEPG). This document also reflects many concepts expressed at the IETF Addressing BOF which took place in Cambridge, MA in July 1992. In addition, Dan Long (BBN), Jon Postel (ISI), and Yakov Rekhter (T.J. Watson Research Center, IBM Corp.) reviewed this document and contributed to its content. The author thanks those groups and individuals who have been cited for their comments. 7.0 References [1] Cerf, V., "IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet 'Connected' Status", RFC 1174, CNRI, August 1990. [2] Wang, Z., and J. Crowcroft, "A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion", RFC 1335, University College London, May 1992. Other related relevant work: [3] "Internet Domain Survey", Network Information Systems Center, SRI International, July 1992. [4] Solensky, F., and F. Kastenholz, "A Revision to IP Address Classifications", Work in Progress, March 1992. [5] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignments and Aggregation Strategy", RFC 1338, BARRNet, cisco, Merit, OARnet, June 1992. [6] Rekhter, Y., and T. Li, "Guidelines for IP Address Allocation", Work in Progress, August 1992. 8.0 Security Considerations Security issues are not discussed in this memo. 9.0 Author's Address Elise Gerich Merit Network, Inc. 1071 Beal Avenue Ann Arbor, MI 48109-2112 Phone: (313) 936-3335 EMail: epg(a)MERIT.EDU ------- End of Forwarded Message

1 0

Request for Unused Class B Internet Numbers
by Daniel Karrenberg 04 Feb '93

04 Feb '93

Dear colleagues, as you certainly know the amount of class B Internet numbers available for allocation has run quite low. Before this had become a concern European organisations have been allocated substantial blocks of class B network numbers by "the" NIC either for their own use or for reassignment to other organisations. In the meantime the RIPE NCC has taken up the role of European regional Internet registry. In the first half year of operation we have allocated 61 class B networks to European organisations that meet the criteria established by the Internet Assigned Numbers Authority (IANA). In order to ensure fair distribution of the unused class B address space to the Internet community we ask any organisation in Europe holding unused class B numbers to return them to us. We have consulted IANA on this and it has been agreed that all numbers returned in this manner will be retained by the RIPE NCC for re-assignemt to European organisations. Thus Europe as a whole will not "loose" any address space. The NCC will publish a list of all organisations returning numbers each quarter. Also we encourage all organisations currently using class B network numbers for networks with a few 10s of hosts to consider exchanging their class B number for a class C number as a service to the community. Even before this announcement we have already received 7 class B addresses from Deutsches Forschungsnetz (DFN) and one from an individual organisation. We thank them and hope that many of you will follow their example. Daniel Karrenberg RIPE NCC Manager

1 0

Looking for info
by Marten Terpstra 02 Feb '93

02 Feb '93

All, I just had a request from Mr Ghijs from LMS International in Belgium, with offices in Beglium, France, Germany, Italy, the UK and the US, who wants some information on Internet connectivity. He is not quite sure yet when or how he wants to connect, but he would like some information so he can make some decisions. Please contact him at: person: Carol Ghijs address: LMS International address: Interleuvenstraat 68 address: 3001 Leuven address: Belgium phone: +32 16 402854 fax-no: +32 16 400308 e-mail: <none> changed: marten(a)ripe.net 930202 source: RIPE -Marten

1 0

Re: NCC Funding (fwd)
by bonito＠nis.garr.it 28 Jan '93

28 Jan '93

Folks, after the discussion at in Prague I recirculate on the list a message I sent to Daniel and Rob with y ideas on the funding issue. Greetings to everybody from a much warmer climate than in Prague ;-) Blasco Forwarded message: > From bonito Thu Jan 21 12:23:53 1993 > Subject: Re: NCC Funding > To: Daniel.Karrenberg(a)RIPE.NET, k13(a)nikhef.nl (Rob Blokzijl) > Date: Thu, 21 Jan 93 12:23:53 MET > Reply-To: > In-Reply-To: <9301201639.AA00678(a)jolly.nis.garr.it>; from "Daniel Karrenberg" at Jan 20, 93 5:18 pm > Organization: GARR Network Information Service > X-Mailer: ELM [version 2.3 PL11] > > Daniel, Rob, > > > Rob and I have been asked by many people (among them the current funders > > of the NCC) to come up with ideas for funding the NCC in 1994 and maybe to > > provide addtitional funding in 1993. > > > > This is related to the strategic decisions which must be made about > > charging for the registry functions. Below is a *very* rough first draft > > representing out thinking in this. I circulate it for discussion > > during the agenda point registry funding at Praha local-ir meeting. > > Please do not take this as prejudicating anything. It is just some very > > basic thoughts. > > > > Comments welocme. > > I was already stimulated to think about this issue by the NSF announcement. > Your (well done) paper has unblocked my natural attitutive against writing. > I feel myself involved in the problem as "representing" a service provider > as well as RIPE deputy chairman. > > I generally agree with what is said in your document about feasible > and unfeasible ways of funding the NCC. > I think you should spend some effort trying to "model" funding criterias > in the overall european networking scene, but only SOME EFFORT. > Our major concern should be to exactly define rules to fund NCC, leaving > to service providers the task of defining their own rules to charge > customer organizations or even final users. It is evident that there > are very different requirements and constraints put on a national > research network than on a commercial network: the first is supported > by the government and is able to give services for free. > > I think that: > > RIPE Network Management Database > has not yet reached the status of a strongly needed service, so it could > be a risk to charge service providers on this base. I think we should > continue the effort in order to have major backbones (EBONE, EMPB, GIX, ...) > making use of the database: it is then a unavoidable tool! > > A small uncorrectness: > > The community represented in the database is limited to Eu- > > ropean organisations with Internet connectivity. *stats* > -------------------------- > not true, it contains also networks with connect: LOCAL > > I think that the > > European Regional Internet Registry > despite it is a young service, it is already a strongly needed service: > without unique IP numbers no one can be connected to Internet either now > or in the future. By the way the NCC should start some activity as soon > as possible about the registration of the successors of 4-byte IP addresses > whatever they will be. > > I think it is feasible to define ways of finance the NCC which are based > on the IP registry > > > RIPE Support > > General Coordination > should be financed through basic funding mechanisms (i.e. RARE, the > CEC trough RARE, the CEC directly): the importance of RIPE has > reached a sufficient general consensus, I think. > > A note: > > The NCC also partecipates in global activities representing RIPE > ------------ > I think this is a task of the RIPE chairman and deputy chairmans, not > of the NCC. > > Now about charging mechanisms: > > > > European Internet Service Providers > > ... > > Charging the service providers could be achieved in the same > > way as above through a database registration charge and with > > the same drawbacks Also the use of the registry service > > could be billed, with similar difficulties. > > > > The big benefit of funding via the service providers is that > > the number of entities to bill is relatively small and -even > > more importantly- there is a chance to come to a consensus > > about the charging model. On the other hand the wider Euro- > > pean user community will be funding the NCC services from > > which they benefit via the providers. So the users having a > > direct benefit pay, albeit indirectly. > > I think that a reasonable and acceptable way to charge should be > based on services actually given, so > - a service provider can charge a customer organization on the base > of the address space, because a larger address space can connect > more hosts and can generate more traffic > - a registry service can charge a service provider on the base > of the effort needed to make and maintain a registration > > The funding model I have in mind is the following: > 1- any service provider is registered by RIPE-NCC and pays an annual fee > (subscription + some advance payment for a foreseen number of > actual network registration) > 2- any "RIPE registered" service provider can submit registration > requests during the year, as well as updates of the database concerning > routing privileges. This registration are tipically about > connected networks/block of networks. They have a steady benefit > from the RIPE registration. > 3- any national "non-provider registry" is also registered by RIPE-NCC > and pays a much smaller annual fee > 4- non-provider registries can tipically submit a number of new > "unconnected" network registration. They have a "once-only" > benefit from the RIPE registration. > > The RIPE-NCC issues an yearly bill > a) to service providers computed as follows: > inetnum entries with connect: <service providers name> are counted > (note this is NOT the number of networks) and then multiplied by a > database-management tariff and then discounted by the advance payment > already done. > b) to non-provider regitries as follows: > inetnum entries with country: <non-provider country>, connect: LOCAL > and changed: <current year> are counted and multiplied by a > registration tariff. > > Service providers can then bill, if they need so, their customers on > the base of the address space used or any other rule. > Non-provider registeries can bill requestors per single request/assignment > made or as they like, but I think that it is time to state that an > official address cannot be given for free. > > All my best, see you in Praha. > ---------- ---------- > Antonio_Blasco Bonito E-Mail: bonito(a)nis.garr.it > GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito > c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 > Via S. Maria, 36 Telex: 500371 CNUCE I > 56126 PISA Italy Fax: +39 (50) 904052 > ---------- ---------- > -- ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito(a)nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------

1 0

Database updates
by Marten Terpstra 26 Jan '93

26 Jan '93

Dear folks, The network connection to Prague is of such qualt\ity that we cannot do an update of the database from here right now. We cannot risk the update to break somewhere halfway because of network connectivuty. We will of course try to do an update whenever possible. Apologies for this, the NCC staff.

1 0

Database updates during upcoming RIPE meeting
by Marten Terpstra 22 Jan '93

22 Jan '93

Dear folks, Since all of the RIPE NCC staff will be in Prague next week for the RIPE meeting, there may be a chance that we miss an update. Because of time or connectivity constraints it can happen that we cannot keep our daily update service. Our apologies for this, but we will try to do the best we can. -Marten

1 0

NCC Funding
by Daniel Karrenberg 20 Jan '93

20 Jan '93

Folks, Rob and I have been asked by many people (among them the current funders of the NCC) to come up with ideas for funding the NCC in 1994 and maybe to provide addtitional funding in 1993. This is related to the strategic decisions which must be made about charging for the registry functions. Below is a *very* rough first draft representing out thinking in this. I circulate it for discussion during the agenda point registry funding at Praha local-ir meeting. Please do not take this as prejudicating anything. It is just some very basic thoughts. Comments welocme. Daniel RIPE NCC Funding Some General Observations DRAFT Vertsion 0.1 Rob Blokzijl Daniel Karrenberg Introduction When examining the problem of how the RIPE NCC should be funded, the question of "Who uses the NCC?" immediately comes to mind. And indeed the RARE CoA has asked for an answer to just this question. However, it is difficult to answer such a general question. A little easier might be "Who benefits from NCC services?". In this paper, an attempt has been made to analyse the prob- lem by categorising the services and user communities of the NCC. A single model for NCC funding has not yet been con- sidered, as this requires discussion and consensus from all the parties involved. Instead, this paper aims to examine the problem, discuss some of the possible options and to ar- rive at a framework which will promote further discussion. Categories of NCC Services When approaching the problem from the NCC user angle one can identify several classes of users according to the different services the NCC offers. Therefore we present the main ser- vices presently provided by the NCC first. For details about these services, please see the RIPE NCC Quarterly reports. Information Service - RIPE Document Store The biggest and most diverse group of NCC users are those makeing use of the NCC information services. The informa- tion services consist of various ways to retrieve informa- tion from what is called the "RIPE Document Store". Despite the name this carries not only documents but also software tools related to network management. The scope is wider than just RIPE but restricted to information relevant to Internet and RIPE activities. For instance the document store con- tains mirror images of the RARE, EBONE and IETF document stores including all RFC and all Internet draft documents. In the Internet tradition the document store is available to all sites on the Internet and additionally accessible from the public X.25 networks as well as EMPB(IXI). Users do not January 20, 1993 - 2 - need to register before using this information service. Logs are kept about usage though and summaries are published in the RIPE NCC Quarterly Reports * insert some usage stats* The user community of this service is the whole worldwide Internet. No registration is necessary. RIPE Network Management Database The RIPE network management database holds information about European IP networks (network in the sense of IP network numbers), DNS Domains and contact persons for these. Furth- er it contains routing policy information. Users do not need to register before querying the RIPE database. Logs are kept about usage though and summaries are published in the RIPE NCC Quarterly Reports. * insert some usage stats* The database is available to the whole worldwide Internet community. The community represented in the database is limited to Eu- ropean organisations with Internet connectivity. *stats* European Regional Internet Registry The RIPE NCC functions as the European regional registry for Internet numbers. The most important such numbers are the IP network numbers, which constitute the IP address space. The NCC provides a meachanism which enables European organisa- tion to obtain the address space they need in an efficient manner without the need to refer to the global registry in the US. At the same time the NCC ensures that usage of the address space fair and economical. In principle the NCC achieves the above by working through so called local registries. These are IP service providers assigning address space to their customers or "non-provider" registries assigning address space for local use. Wherever a local registry has not been established the NCC assigns ad- dress space directly. The NCC also handles all requests for larger amounts of address space directly, especially those for class B IP numbers. *insert numbers of registries* The user community for the regional registry functions is all European organisations using TCP/IP protocols and desir- ing unique addresses. Note that this is larger than the com- munity connected to what we call the European part of the Internet. Looking at it in a hierarchical fashion the direct user com- munity are the European IP service providers and the "non- provider" registries. This the direct assignments by the January 20, 1993 - 3 - NCC in cases where there is no appropriate local registry. RIPE Support The RIPE NCC supports RIPE activities in general. This in- cludes providing mailing list service as well as some secre- tarial service to RIPE and the RIPE working groups, prepara- tion and logistics for three RIPE meetings a year in varying locations for an increasing amount of attendees. The last meeting was attended by approximately 75 people. The NCC also participates in global activities representing RIPE. The direct user community of these services are the organi- sations participating in RIPE. The indirect user commmunity are all organisations connected to the European part of the Internet because RIPE is the organisation coordinating the European Internet. General Coordination The NCC also performs a host of small and/or incidental coordination functions related to the European part of the Internet which are not easy to categorise. This is normal for a focal point of distributed activities like the RIPE NCC. Categories of RIPE NCC Users Based on the different services offered one can disitinguish different categories of NCC users. We will do this in a hierarchical fashion by defining a number of user categories which are progressively smaller subsets of each other. The Internet at Large The most general category is users of Internet protocols and the Internet worldwide. The information and database query- ing services of the NCC are open to the whole global Inter- net community. Charging for these services is nesxt to im- possible in the current Internet framework because users do not need to register before using these services. The sheer number of users makes traditional billing methods unworkable as well. If it was practicable to bill for these services it would probably be counterproductive because their usage helps keeping the Internet coordinated and keeps quite a bit of load off the NCC itself as well as the help desks of the service providers. January 20, 1993 - 4 - European TCP/IP Users The next category is all organisations using TCP/IP in Eu- rope. This category is a subset of the previous one. In ad- dition to the global Internet community this community uses the regional Internet registry and database registration services. These organisations are known with contact infor- mation, so billing is at least theoretically possible. The only basis for billing which is obvious at this level is the adress space. Once could charge either per assignment or one could "rent" address space. The limits of practicability here are the number of orgaisations, the legal implications, especially with holders of already assigned address space. Another prerequisite is global agreement on the charges to prevent "black imports". Our conclusion is that this is impractical for the time being but could be valuable in the future, especially as a tool to rationalise address space usage. It remains doubtful however whether it will ever become practi- cable and economical to do. European Internet Users The next category is all organisation connected to the Euro- pean Internet. In addition to the services used by the pre- vious categories organisations in this category can depend more sophisticated use of the RIPE database registration service because of the role the database plays in distribut- ing routing policy information. Because these organisations are connected they are alos more likely to benefit from the general coordination activities of the RIPE NCC. Charging these users could be done in form of a poeriodical database registration charge. However this could work out counterproductive to the goal of manageability of the Euro- pean Internet if organisations or service providers find ways of achieving the desired connectivity without register- ing. Also the measurement of use and the charging model will be hard to agree. The number of entities to bill is still large. European Internet Service Providers Each organisation in the previous category either is con- nected through a service provider or is itself such a ser- vice provider. The service providers make use of all NCC services the previous category uses. However they do so much more directly than their customers, the users of the Europe- an Intnernet. The service providers interact directly with the NCC for the registry function, as members of RIPE and when using the RIPE database for trouble shooting and rout- January 20, 1993 - 5 - ing. Most of the time the service providers act on behalf of their customers. Charging the service providers could be achieved in the same way as above through a database registration charge and with the same drawbacks Also the use of the registry service could be billed, with similar difficulties. The big benefit of funding via the service providers is that the number of entities to bill is relatively small and -even more importantly- there is a chance to come to a consensus about the charging model. On the other hand the wider Euro- pean user community will be funding the NCC services from which they benefit via the providers. So the users having a direct benefit pay, albeit indirectly. *list service providers from local registty list* Making suggestions for that charging model needs consider- ably more time than we have had so far to write this paper. Any simplistic model suggested and simulated so far was un- fair and/or might cause providers economise in undesirable ways. So we will just present an incomplete list of the problems: What service measures to charge on? registry service ehat measures? do not penalise well organised local registries! do not reward service providers putting load on the NCC by not running a local registry! do not stimulate bad adress space usage pat- terns! do not break route aggregation! database service what measures? do not discourage registration! reward organised local maintenance of database! Legal Framework? how to organise? what to do with providers who "do not p(l)ay"? January 20, 1993 - 6 - How to build consensus? RIPE is the obvious place! How to proceed? Conclusion Looking at the services and the user communities the most practical general model is funding via the service provid- ers. If this much can be agreed then an activity can be started to further work things out within this group. Because this needs more work we suggest that in order to seek additional funding for (part of) 1993 all identifiable service providers not contributing yet are approached for a voluntary contribution and all commitments including the al- ready established ones are publisised publicised within RIPE. January 20, 1993

1 0

Revised European IP template
by Anne Lord 20 Jan '93

20 Jan '93

Dear All, Below is the revised draft European IP template which will be discussed at the local-ir working group in Prague. The aim is to discuss and agree on a format of the template, so that it can be used after Prague. As before, comments welcome. ------------------------------------------------------------------------ DRAFT January 1993 RIPE NCC EUROPEAN IP-NETWORK NUMBER INFORMATION PACKAGE GUIDELINES DOCUMENT and APPLICATION FORM ---------------------------------------- Introduction ------------ In the past, if you needed an IP network number you would need to obtain and complete a form issued by the Global Internet Registry in the United States (aka hostmaster(a)nic.ddn.mil). Since August 1st 1992, there has been a change in procedure, whereby all network number requests from European organisations are handled by the European Regional Internet Registry. This refers to the RIPE Network Coordination Centre located in Amsterdam, The Netherlands (RIPE NCC or hostmaster(a)ripe.net). The RIPE NCC receives blocks of network numbers from the Global Registry. Class C numbers it reallocates to local registries across Europe, who in turn, according to strictly defined RIPE procedures make the actual network number assignments. Slightly different procedures exist for Class B network numbers which are only assigned by the RIPE NCC. Therefore when you are making an application for a class B you should complete this form and send it direct to the RIPE NCC. However, if it is felt that a class B is not justified, then your application will be forwarded to your local registry who will consult you over an appropriate allocation of class C network numbers. There are two types of local registries: those who are IP service providers who run local registries for their customers. The majority of IP service providers run local registries. There are also "non-service provider" local registries which provide an IP registry service to organisations who do not have an IP service provider. Only one "non-service provider" registry exists per European country, but they are as yet not established for every country in Europe. In cases where a local non-service provider registry does not exist for a country, the RIPE NCC manages the allocations. If you are in doubt contact the RIPE NCC for more information. An "IP service provider" can be defined as an organisation that provides Internet services to other organisations. Examples of IP service providers are (national) research network organisations or commercial network service providers. In making your application for a network number you should be guided by the following preliminary question: Q. Are you a customer (existing or prospective) of an IP Service Provider? A. If the answer is YES - then you should complete this form and then return it to your IP Service Provider. or A. If the answer is NO - then you should complete the European IP request form and return it to your local non-provider registry. If you do not know whether a local registry exists for your country, please contact the RIPE NCC who will be able to advise you. If you have any queries or problems please do not hesitate to contact the RIPE NCC or <your local registry address>. Before making your request for an IP number, you should you have read all the documentation carefully. There are 3 documents which you should receive and read: a) the European IP number request form - the actual application form b) the `Guidelines Document' - this document c) the `Helpful Hints' document - which contains information you need to know before applying for IP network numbers (Bob Day) This document will guide you in how to complete the European IP number request form correctly. The request form is used by all the Internet registries across Europe. The format of the form is designed so that it enables us to process your application quickly. That is why we ask you to carefully read and follow this 'Guidelines Document' which describes in detail how to complete the form. In addition, please ensure that you read the 'Helpful Hints' document which contains information that you should know before applying for a network number. Local language versions of the 'Guidelines' document and the `Helpful Hints' may document exist. Please contact your local registry for a copy (or the RIPE NCC?). ------------------------------------------------------------------- new page Part A - Administrative Details - Guidelines -------------------------------------------- The information supplied for this section together with the assigned network numbers will be entered into a database of European network numbers and their contact information which is accessible by the whole Internet community. netname: Please complete with an appropriate network name for the network to be numbered which is short and meaningful. The `netname' is used mainly for administrative purposes like consistency checking of the Internet Registry. You will most likely not see this name appear anywhere, but on forms like this. eg. netname: TBIT descr: Please complete with a short description of the organisation, including the location. The full postal address is not needed as this is required in the person template. eg. descr: Terabit Labs Inc. descr: Network Bugs Feeding Facility descr: Northtown country: Please give the ISO 3166 two letter country code which is appropriate for the organisation. We know this gives problems for networks crossing national boundaries, so choose the most appropriate country, based on the location of the admin contact. If you do not know the ISO 3166 code for your country, please complete with the full name of the country. eg. country: IE admin-c: Please complete with the name or NIC handle of the person who is the administrative contact for the network. The NIC handle (if known) is preferred. Please do not use formal titles like `Dr' or `Prof' or `Sir'. Please specify as in the example below (or with the NIC handle if known). Do not add full stops between the names or initials. eg. admin-c: John E Doe tech-c: Please give the name of technical contact person. There can be more than one technical contacts name. NOTE: please give names for both the administrative AND the technical contact. If two different names are not appropriate, then the same name for both contacts is fine. changed: Email address of the person who is completing the template, followed by the current date. If you do not have email connectivity please leave blank and we will complete it. Please add the date as it is shown below. eg. changed: johndoe(a)terabit.nn 921215 source: Source of the information. This will always be RIPE, which we have added. PERSON TEMPLATE NOTES For each different person specified in the network template, please complete a separate person template, unless the data about those persons is already in the RIPE database. person: Please give the full name of the admin-c contact and the tech-c contact. There must be a person template completed for each different name specified. The names must be written identically to those given above in the "admin-c:" and "tech-c:" attributes above (but must not be the NIC handle). eg. person: John E Doe address: Please complete with the full postal address, and write as you would for ordinary postal mail using one line for each part of the address as shown below. eg. address: Terabit Labs Inc. address: Industrial Estate North address: North Perpendicular Road 12 address: NN-1234 Northtown address: Repubic of Northern Nowhere phone: Please give the work telephone number of the person specified above. Please specify the telephone number with + <country code> <area code> <telephone number> Most countries should drop the leading zero when specifying their area code. More than one telephone number is fine. Each telephone number should be put on a separate line and written in order of the most appropriate number for the contact person. eg. phone: +31 20 12334676 phone: +44 71 9876542 ext. 4711 fax-no: Please complete with the telefax number of the person specified above. eg. fax-no: +31 20 12334677 e-mail: Please supply the appropriate electronic mail address for the contact. If you DO NOT have e-mail connectivity, please insert <none>. Please ensure that this is a valid domain address please. eg. e-mail: johndoe(a)terabit.nn or e-mail: <none> nic-hdl: This refers to a NIC handle which is a unique identifier assigned and used by the US NIC to unambiguously refer to Internet people. If you do not have a NIC handle, then please leave blank. eg. nic-hdl: JD0401 changed: Who and when changed this last. Please complete with your e-mail address followed by the current date in the format which is shown below. If you do not have e-mail connectivity, please leave blank and we will complete this on your behalf. Example - changed: johndoe(a)terabit.nn 921215 source: Source of the information. This should always be RIPE. ------------------------------------------------------------------- new page Part B - Technical Details -------------------------- Information supplied below helps us to evaluate and process your request. It will be kept in strict CONFIDENCE and NOT entered into the RIPE Network Management Database. request-typ: Please specify the quantity and class of your request for network numbers. eg. request-type: 1 class C In making the application, please be guided by the following EXAMPLES of number of hosts which relate to the quantity of network numbers requested: eg. 1 class C number (up to 254 hosts) 2 class C numbers (up to 508 hosts) 4 class C numbers (up to 1016 hosts) 8 class C numbers (up to 2032 hosts) 16 class C numbers (up to 4064 hosts) 32 class C numbers (up to 8128 hosts) a single class B number other (please specify) machine-0: Please state the number of machines in your organisation that currently require a unique IP address. Do not forget to include terminal servers and transit networks when calculating this figure. eg. machine-0: 100 machine-1: Estimate the number of machines requiring a unique IP address in one years time. eg. machine-1: 134 machine-2: Estimate the number of machines requiring a unique IP address in two years time. eg. machine-2: 250 subnet-0: Please state the number of subnets required for the current network. A subnet refers to the physical parts of the network which need a unique (sub)net number. eg: subnet-0: 10 subnet-1: Estimate the number of subnets in one years time. subnet-2: Estimate the number of subnets in two years time. inet-connect: Please state whether you plan to connect to the Internet. Please answer with whichever of the following options most closely describes the position of your organisation. eg. - will never connect - already connected <through whom> - plan to connect <date> If you are "already connected" to the Internet, please state which service provider you are connected to. If you answer with "plan to connect" then please make an estimation on the date that you hope to connect, specifying the month and the year (if possible). eg. inet-connect: already connected JANET in the UK or eg. inet-connect: plan to connect December 1993 use-net: Has your organisation already obtained an IP network number or numbers? If so, please give the network number(s) and the network name if known. If not, then please complete with <no>. Format: complete with the network number only - four numbers separated by dots, as shown below. If known, please also add the network name entry as shown below. This must be specified in exactly the same way as it appears Example - use-net: 193.87.45.0 TBIT or Example - use-net: <no> iso-net: Please give the ISO 3166 country code which describes where the network will be located. If more than one country applies, then give the name of the country "responsible" for the network, using the country of the admin-c: contact given in Part A. Format: complete with country name using ISO 3166 country code. Example - iso-net: NL Part C - Technical Details --------------------------- Please complete this section on a separate page if you are applying for more than 2 Class C network numbers. The more numbers you are requesting, the more detailed your technical description will need to be. Furthermore, the more detail you provide, the quicker we will be able to process your application. Please include an overview of the size of your subnets, ensuring that you do not forget transit networks, terminal servers etc. when calculating your needs. Before you complete this section you should read the `Helpful Hints' document (currently under preparation) which will guide you. It is particularly important to read this document if you are applying for a class B network number, as it provides additional hints. It is available from: <supportingip-docs(a)wherever.net>. Local language versions also exist. Please contact your local registry for copies or the RIPE NCC. If you are applying for a Class B network number please send your completed application to the RIPE NCC who will review your case. If it is felt that a Class B network number is not justified, your application will be forwarded to your local registry who will consult with you over an alternative allocation. Please be reminded that Class B network numbers are extremely scarce and are rarely allocated. Part D - Contact Details ------------------------ This section should be completed *ONLY IF* you are making an application on behalf of another organisation. Please indicate who the application is being made by and behalf of whom, giving all the contact details requested. ====================== 8< please cut here ================================== DRAFT January 1993 RIPE NCC EUROPEAN IP NUMBER REQUEST FORM ------------------------------- Part A - Administrative Details ------------------------------- The information supplied for this section together with the assigned network numbers will be entered into a database of European network numbers and their contact information which is accessible by the whole Internet community. netname: descr: descr: country: admin-c: tech-c: changed: source: RIPE person: address: address: address: address: phone: fax-no: e-mail: changed: source: RIPE person: address: address: address: address: phone: fax-no: e-mail: changed: source: RIPE ----------------------------------------------------------------------- new page Part B - Technical Details -------------------------- Information supplied below helps us to evaluate and process your request. It will be kept in strict CONFIDENCE and NOT entered into the RIPE Network Management Database. request-typ: machine-0: machine-1: machine-2: subnet-0: subnet-1: subnet-2: inet-connect: use-net: iso-net: Part C - Technical Details -------------------------- If you are applying for more than 2 Class C network numbers then on a separate page, please submit a description of your network plans. Current network layout: Future network plans: In both please include an overview of the size of your subnets. Please do not forget transit networks, terminal servers etc. when calculating your needs. ------------------------------------------------------------------------ new page Part D - Contact Details ------------------------ Complete the section below *ONLY IF* you are making an application on behalf of another organisation. This application is made by:- Name: Organisation: Country: Tel: Fax: E-mail: On behalf of the following organisation: Name: Organisation: Country: Tel: Fax: E-mail: ----------------------------------------------------------------- Please return this document to: local ir-registry name <email of local ir-registry> <phone of local ir-registry> <fax no of local ir-registry> <address of local ir-registry> or to the RIPE NCC if you are applying for a class B network number.

1 0

Local IR WG meeting in Praha
by Daniel Karrenberg 15 Jan '93

15 Jan '93

The local Internet Registries Group will meet during the Praha RIPE meeting. Draft Agenda ============ 1. Approval of the European Internet Number Registration Template Goal is to have an approved template which will replace all local templates thus standardising information and facilitating referral of requests. 2. General discussion about registration procedures Could they be improved and how? Could NCC support be improved and how? 3. 193.in-addr.arpa delegation Report by NCC. 4. Brainstorming about charging models for registration services Deferred from the Paris meeting. Needs progress because of NSF's intention to develop a scheme within 15 months.

1 0