From Marten.Terpstra at ripe.net Tue Feb 2 16:11:23 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 02 Feb 93 16:11:23 +0100 Subject: Looking for info Message-ID: <9302021511.AA20600@ncc.ripe.net> 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: changed: marten at ripe.net 930202 source: RIPE -Marten From Daniel.Karrenberg at ripe.net Thu Feb 4 17:17:06 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 04 Feb 93 17:17:06 +0100 Subject: Request for Unused Class B Internet Numbers Message-ID: <9302041617.AA26223@ncc.ripe.net> 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 From Daniel.Karrenberg at ripe.net Tue Feb 16 16:46:46 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 16 Feb 93 16:46:46 +0100 Subject: RFC1366 Revision Message-ID: <9302161546.AA22631@ncc.ripe.net> 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 at MERIT.EDU ------- End of Forwarded Message From Havard.Eidnes at runit.sintef.no Tue Feb 16 17:52:45 1993 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Tue, 16 Feb 93 17:52:45 MET Subject: RFC1366 Revision In-Reply-To: Your message of Tue, 16 Feb 93 16:46:46 +0100 Message-ID: > 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 From Daniel.Karrenberg at ripe.net Tue Feb 16 18:14:05 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 16 Feb 93 18:14:05 +0100 Subject: RFC1366 Revision In-Reply-To: Your message of Tue, 16 Feb 93 17:52:45 +0700. Message-ID: <9302161714.AA22969@ncc.ripe.net> > Havard.Eidnes at runit.sintef.no writes: > > 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.) I can't that was one of the questions I had as well. I have had legitimate cases with 2-4 hosts / subnet and allocating 1C for each is wasteful. We should go CIDR right away. Daniel From Marten.Terpstra at ripe.net Fri Feb 19 15:07:21 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Fri, 19 Feb 93 15:07:21 +0100 Subject: problems with data base updates In-Reply-To: Your message of Thu, 18 Feb 93 22:36:10 +0100. <9302182136.AA10224@meins.informatik.uni-dortmund.de> Message-ID: <9302191407.AA00249@ncc.ripe.net> rv at deins.informatik.uni-dortmund.de writes: * Hello, * * recently I mentioned to Daniel on the phone, that it looks like some * "connect:" fields are filtered (without warning) in the RIPE data base. * I just came across an example (I will keep looking), the record for * network 139.1: I'm very sorry to say that this is all my fault, and it was even worse than some "connect:" fields dissapearing ... In fact what happened is that all LOCAL connect fields dissapeared from the database because of an(other) error in the procedure that adds the routing tags to the database. I have done the following to correct this: - modified the script that adds the routing tags to leave the connect fields in, - rebuild the database, and added a "connect: LOCAL" field to any network that had no connect tag in the current database. I have checked this extensively and are sure that ONLY "connect: LOCAL" fields dissapeared. All other connect fields were not removed, and still have their old value. My apologies for this error. If you do find any inconsistencies, please inform us, and we will process with the highest priority. -Marten From Daniel.Karrenberg at ripe.net Wed Feb 24 17:58:01 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 24 Feb 93 17:58:01 +0100 Subject: Database Update Acknowledgement Messages Message-ID: <9302241658.AA10789@ncc.ripe.net> Effective immediately the acknowledgements we send out for database updates will mention the "Subject" of the update mail message being acknowledged in addition to the "Message-ID". This should allow easier matching of acknowledgements to update requests. Please let us know if you see any wrong behaviour of this new feature. We also have had requests to mention the names of all objects updated e.g. person, network, domain etc.. We have refrained from doing this as it would produce *very* long acknowledgements in some cases. We were thinking of providing it for updates containing less objects than a threshold of -say- 20. Anyone who wants this in addition to the Subject please speak up with an explanation why to the list. Then we can make a decision whether it is worthwhile. Daniel From Piet.Beertema at mcsun.EU.net Wed Feb 24 18:04:35 1993 From: Piet.Beertema at mcsun.EU.net (Piet.Beertema at mcsun.EU.net) Date: Wed, 24 Feb 1993 18:04:35 +0100 Subject: Database Update Acknowledgement Messages In-Reply-To: Your message of Wed, 24 Feb 93 17:58:01 +0100 . <9302241658.AA10789@ncc.ripe.net> Message-ID: <9302241704.AA19180@mcsun.EU.net> We also have had requests to mention the names of all objects updated e.g. person, network, domain etc.. We have refrained from doing this as it would produce *very* long acknowledgements in some cases. We were thinking of providing it for updates containing less objects than a threshold of -say- 20. Anyone who wants this in addition to the Subject please speak up with an explanation why to the list. Then we can make a decision whether it is worthwhile. I don't like the idea of *by default* getting all or even upto 20 (or some other limit) changed objects reported. However, in some cases I would like to have this feature. How about making it depend on the presence of the "ACK" keyword in the Subject: line? Piet From Daniel.Karrenberg at ripe.net Wed Feb 24 22:31:18 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 24 Feb 93 22:31:18 +0100 Subject: Database Update Acknowledgement Messages In-Reply-To: Your message of Wed, 24 Feb 93 18:04:35 +0100. <9302241704.AA19180@mcsun.EU.net> Message-ID: <9302242131.AA11329@ncc.ripe.net> > Piet.Beertema at mcsun.EU.net writes: > > I don't like the idea of *by default* getting all or even > upto 20 (or some other limit) changed objects reported. > However, in some cases I would like to have this feature. > How about making it depend on the presence of the "ACK" > keyword in the Subject: line? OK, this sounds reasonable. I have implemented this using the string LONGACK rather than ACK which might legitimately be in the subject line. If you send us an update with the string LONGACK (in capitals) somewhere in the Subject:-line, the acknowledgements will contain a line saying Update OK: for each update which generated no messages. The updates generating messages will return the full object and messages as before. Please let us know your experiences and suggestions. Daniel From afs at Germany.EU.net Thu Feb 25 14:48:19 1993 From: afs at Germany.EU.net (Andreas Schachtner) Date: Thu, 25 Feb 93 13:48:19 GMT Subject: Database Update Acknowledgement Messages In-Reply-To: Your message of Wed, 24 Feb 93 17:58:01 N. <9302241658.AA10789@ncc.ripe.net> Message-ID: <9302251448.AA08075@walhalla.Germany.EU.net> > >Effective immediately the acknowledgements we send out for database >updates will mention the "Subject" of the update mail message being >acknowledged in addition to the "Message-ID". This should allow easier >matching of acknowledgements to update requests. Please let us know if >you see any wrong behaviour of this new feature. Good move. NMow I have to change my scripts, to generate the subject lines automatically :-) Andreas Schachtner