October 1992 - lir-wg - mailman.ripe.net

FYI: Guidelines for Management of IP Address Space
by Daniel Karrenberg 20 Oct '92

20 Oct '92

------- Forwarded Message Date: Mon, 19 Oct 1992 18:25:44 -0700 From: postel(a)ISI.EDU (Jon Postel) To: iesg(a)ISI.EDU, iab(a)ISI.EDU cc: ncc(a)ripe.net, wgc(a)fnc.gov, fepg(a)fnc.gov, usac(a)ISI.EDU, ScottW(a)nic.ddn .mil, Daniel.Karrenberg(a)ripe.net, BobM(a)nic.ddn.mil, rfc-editor(a)ISI.EDU, iana(a)ISI.EDU Subject: Guidelines for Management of IP Address Space Hi. As RFC Editor i am about to release to the world the following two RFCs (currently called AAAA and BBBB). The first is a paper written by Elise Gerich presenting some guidelines for managing the IP address space. The second is a note written by Claudio Topolcic suggesting a schedule for implementing the guidelines. I'd like to be sure that you are at least aware of these documents before they become widely available. Even as RFCs these are still, in a sense, trial balloons. If there is a great deal of discussion and suggestions for change, there will be new editions. If not, these may become (somehow) "official policy". - --jon. ========================================================================= Network Working Group E. Gerich Request for Comments: AAAA Merit October 1992 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 Task Force (FEPG) on behalf of the Federal Networking Council (FNC), the co- chairs of the International 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", 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 Gerich [Page 1] RFC AAAA Guidelines for Management of IP Address Space October 1992 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, 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 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) the commitment to allocate IP numbers according to the guidelines established by the IANA and the IR e) the commitment to coordinate with the IR to establish qualifications and strategies for sub-allocations of Gerich [Page 2] RFC AAAA Guidelines for Management of IP Address Space October 1992 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 numbers; 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) [1] Class A and B network numbers are a limited resource and therefore the entire number space will be retained by the IR. No allocations from the Class A and B network numbers will be made to distributed regional registries at this time. 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. A preliminary 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. Gerich [Page 3] RFC AAAA Guidelines for Management of IP Address Space October 1992 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: Gerich [Page 4] RFC AAAA Guidelines for Management of IP Address Space October 1992 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 network number space. The IANA 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 IANA 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 under utilization of the Class B number space by most organizations, the recommendation is now to use multiple Class Cs where practical. The IANA and the IR will maintain sole responsibility for the Class B number space. Where there are designated regional registries, those registries will act in an auxiliary capacity in evaluating requests for Class B numbers. Organizations applying for a Class B network number should fulfill the following criteria: 1) the organization presents a subnetting plan which documents more than 32 subnets within its organizational network AND 2) the organization has more than 4096 hosts. These criteria assume that an organization which meets this profile will continue to grow and that assigning a Class B network number to them will permit network growth and reasonable utilization of the Gerich [Page 5] RFC AAAA Guidelines for Management of IP Address Space October 1992 assigned number space. There may be circumstances where it will be impossible to utilize a block of Class C network numbers in place of a Class B. These situations will be considered on a case-by-case basis. 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 deals with how network numbers are assigned from within those blocks. 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 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 The number of addresses that a network subscriber indicates that it needs should be based on a 24 month projection. The maximal block of class C nets that should be assigned to a subscriber consists of sixteen contiguous class C networks which corresponds to a single IP prefix the length of which is twelve bits. If a subscriber has a requirement for more than 4096 unique IP addresses it should most likely receive a Class B net number. Gerich [Page 6] RFC AAAA Guidelines for Management of IP Address Space October 1992 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 International 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, 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 sighted for their comments. 7.0 References [1] Wang, Z., and J. Crowcroft, "A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion", University College London, May 1992. [2] "Internet Domain Survey", Network Information Systems Center, SRI International, July 1992. [3] Ford, P., "Working Draft - dated 6 May 1992", Work in Progress. [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. Varadha, "Supernetting: an Address Assignments and Aggregation Strategy", BARRNet, cisco, Merit, OARnet, June 1992. Gerich [Page 7] RFC AAAA Guidelines for Management of IP Address Space October 1992 [6] Rekhter, Y., and T. Li, "Guidelines for IP Address Allocation", Work in Progress, August 1992. [7] Cerf, V., "IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet 'Connected' Status", CNRI, August 1990. Security Considerations Security issues are not discussed in this memo. Author's Address Elise Gerich Merit Computer Network 1075 Beal Avenue Ann Arbor, MI 48109-2112 Phone: (313) 936-3000 EMail: epg(a)MERIT.EDU Gerich [Page 8] ========================================================================= Network Working Group C. Topolcic Request for Comments: BBBB CNRI October 1992 Schedule for IP Address Space Management Guidelines 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. Introduction This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC AAAA. This schedule is meant to support the implementation and deployment of an address aggregation mechanism for the Internet by proposing an achievable target for which we can all aim. The timely deployment of that aggregation mechanism and the IP addressing plan will help the the size of the Internet router forwarding tables and management of the IP address space. By doing so, it will help the current Internet addressing and routing technology operate during the interim period until the next generation technology is deployed. This interim solution in no way constrains the selection of the next generation addressing and routing technology. This draft schedule was put together by the FNC Engineering and Planning Group (FEPG) based on the IP addressing plan BOF of the July 1992 IETF meeting, as well as discussions with a number (though, of course, not all) of knowledgeable and interested parties, including the IANA and IR. This draft schedule assumes that the address aggregation mechanism will be available in the Internet by mid-1993. The activities described in this schedule are the precursors to that deployment, and will promote the efficient operation of that mechanism. We feel that our assumptions are realistic and that this schedule can be met. We encourage its open discussion as we move toward community consensus. Please send comments to topolcic(a)nri.reston.va.us, or to the mailing list ipalloc(a)nri.reston.va.us. To be added to this mailing list, send a request to ipalloc-request(a)nri.reston.va.us. Note that the references below to an addressing plan and to criteria for regional address registries refer to RFC AAAA. Topolcic [Page 1] RFC BBBB Schedule for IP Address Space Guidelines October 1992 Draft Implementation Schedule for IP Network Number Allocation Plan: 1) 31 October 92: The following address allocation procedures are continued: a) Initial set of criteria for selecting regional address registries will be put into place, and requests from prospective regional registries will be accepted by the IANA. b) Class A network numbers are practically impossible to obtain. c) Class B network numbers will continue to be issued only when reasonably justified. If possible, a block of C's will be issued rather than a B. The requirements for allocating a Class B will become progressively more constrained until the date in step (3). d) Class C network numbers will be allocated according to the addressing plan. Allocation will be performed by the Internet Registry (IR) if an appropriate regional registry has not yet been designated by the IANA. 2) 14 February 93: Re-evaluate and readjust the schedule if necessary. 3) 15 April 93: a) The IR begins to allocate all networks according to the addressing plan in appropriately sized blocks of Class C numbers. b) Class B network numbers will be difficult to obtain, following the recommendation of the addressing plan and only issued when justified. 4) 6 June 93: Expected date that an address aggregation mechanism is available in the Internet. References [1] Gerich, E., "Guidelines for Management of IP Address Space", RFC AAAA, Merit, October 1992. Topolcic [Page 2] RFC BBBB Schedule for IP Address Space Guidelines October 1992 Security Considerations Security issues are not discussed in this memo. Author's Address Claudio Topolcic Corporation for National Research Initiatives 895 Preston White Drive Suite 100 Reston, VA 22091 Phone: (703) 620-8990 EMail: topolcic(a)NRI.Reston.VA.US Topolcic [Page 3] ======================================================================== ------- End of Forwarded Message

1 0

IMPORTANT: Re-assignments now ONLY to <assign@ripe.net>
by Daniel Karrenberg 16 Oct '92

16 Oct '92

Dear Local Registrars, on request of the DDN NIC we have changed the re-assignment procedures slightly. Currently you are required to send RIPE database templates for re-assigned networks to both <ripe-dbm(a)ripe.net> and <hostmaster(a)nic.ddn.mil>. This is changed effective immediately. Please send these messages ONLY to <assign(a)ripe.net> The RIPE NCC will coordinate incorporation of this information in the DDN NIC database with the DDN NIC. We expect this "one stop shopping" :-) procedure will be more convenient to you. It will certainly help to reduce the clerical overhead at both the DDN NIC and the NCC. The change in procedure has been incorporated into the document describing the re-assignment procedures; the current version of this document is now designated ripe-72. Please note that since the database exchange between the DDN NIC and the NCC is just being started it can take a few weeks before all information about re-assigned networks has been incorporated in the DDN NIC database. We are working with the DDN NIC to place pointers to the RIPE database where apropriate for the time being. Regards Daniel Karrenebrg NCC Manager PS: I had planned to discuss this change in the local registries session at the Paris meeting but it fell off the agenda due to time constraints.

1 0

Common IP netnum application form?
by Havard.Eidnes＠runit.sintef.no 14 Oct '92

14 Oct '92

> There are a few actions that came out of the RIPE meeting in Paris: > > - start developing 1 European wide IP number template, including some > documentation. Bob Day of the JNT has volunteered to compose a first > draft, based on the JANET templates and with input from you all. He and > Daniel will work together on this issue. Hi, just to get this action going, I am going to present to you what I have been doing. Before the RIPE meeting in Paris, I had created my own application form to use for norwegian applicants for IP network numbers. At the meeting, the current JANET template was handed out, and I decided that on some points the new form was better than mine, so I modified mine accordingly. I also looked at the recommendation section of the internet draft discussing IP Allocation which was handed out at the RIPE meeting. The result I am currently using is appended below. I also append a copy of ripe-50 (the description of the RIPE "net" and "person" entries) whenever I send out an application form. I do not mean that this form is useable for all, as there is a fair bit of local/national dependent information in the form (eg. the section asking for "who do you plan to have a network connection through, if any?" and contact information for the delegated registry). These are issues that make a "common European form" difficult to create, however, IMHO it still makes sense to "harmonize" the different application forms. Other areas where this application form could use improvement: - a better references section (well, mine has none...) - something that acommodates the requiremens/recommendations of RFC 1355 (eg. warnings regarding privacy / accuracy of the information) - always ask for # of subnets (now, 1 year, 2 years) when more than 1 class C is requested? I append the english version of my form (yes, I maintain two -- one in norwegian and one in english). - Havard ------------------------------ IP address application form for norwegian applicants ---------------------------------------------------- The Internet authorities need to register and maintain information on the owner of each individual IP network number. In Europe, the assignment of IP network numbers is coordinated by RIPE (Reseaux IP Europeens). RIPE hand out blocks of network numbers to network operators, who again assign these numbers to their customers. In Norway, the currently sole IP network operator, Uninett, have taken it upon themselves to hand out IP network numbers to those norwegian organizations which want to have officially assigned IP network numbers. For a norwegian organization to be given a new IP network number, I need the following information. Note that I have omitted some of the fields in the entries for the RIPE database, I will fill the missing entries in based on the stated information. 1) A filled-out network template with at least this information: netname: descr: country: admin-c: tech-c: tech-c: If you apply for more than one network number, please specify the "netname" to be used for the other nets you want to assign -- there's no need to repeat the other information several times if it is the same for these nets. 2) A filled-out person entry for each person mentioned in "admin-c" and "tech-c" above. The minimum information is shown in these three entries: person: address: address: address: address: address: phone: fax-no: e-mail: nic-hdl: person: address: address: address: address: address: phone: fax-no: e-mail: nic-hdl: person: address: address: address: address: address: phone: fax-no: e-mail: nic-hdl: The nic-hdl is optional, as explained in the attached document. 3) Type of alocation request. Please indicate which one of the following is required: o 1 class C number (ie. up to 254 hosts) o 2 class C numbers (ie. up to 508 hosts) o 4 class C numbers (ie. up to 1016 hosts) o 8 class C numbers (ie. up to 2032 hosts) o 16 class C numbers (ie. up to 4064 hosts) o 32 class C numbers (ie. up to 8128 hosts) o a single class B number o other (please specify) If other than a single class C number is required, please provide a justification below of your request in terms of the number of end systems to be connected: Current number of hosts : Expected number of hosts in 1 year : Expected number of hosts in 2 years : If you require a class B network please provide some details of your planned physical network structure and a reason why a number of class C networks cannot fulfill your technical needs. Please remeber that a class C network number can be subnetted. 4) Will this (or these) network(s) be connected to Uninett sometime in the near future? Please return this information to Uninett Hostmaster, att. H}vard Eidnes SINTEF Runit 7034 Trondheim via postal mail, or via telefax at 07-940706 or via e-mail at hostmaster(a)nac.no (822 format) or S=hostmaster;O=nac;PRMD=uninett;ADMD=uninett;C=no; (x.400 O/R format) On behalf of Uninett Hostmaster, H}vard Eidnes, 921006 Attached: ripe-50 -- RIPE Database Template for Networks

1 0

Creation of local-ir@ripe.net
by RIPE Mailing List Department 08 Oct '92

08 Oct '92

Hi all, This is to notify you that a new mailing list is created: Local Internet Registries <local-ir(a)ripe.net> Administrativia for this list should go to <local-ir-request(a)ripe.net>. All message that are send to this list are archived, and will be put in the document store on a regular bases. Purpose of this list -------------------- The list created currently contains all people who have received blocks of class C addresses from the RIPE NCC, and people who are interested in issues related to IP number allocation and the involvement of local registries. There are a few actions that came out of the RIPE meeting in Paris: - start developing 1 European wide IP number template, including some documentation. Bob Day of the JNT has volunteered to compose a first draft, based on the JANET templates and with input from you all. He and Daniel will work together on this issue. - start thinking about a model for financing local registries. - this mailing list could be used to discuss difficult IP assignment cases, experience with address assignments in general, and any other issue that may arise with delegated registry. It should be noted that this list is not appropriate to discuss confidential issues, since the list is relatively open.

1 0