Proposal for Temporary Special Class A Space Guidelines
Mirjam Kuehne Mirjam.Kuehne at ripe.net
Wed Mar 5 11:54:22 CET 1997
Dear Wilfried, Thank you for your comments. "Wilfried Woeber, UniVie/ACOnet" <woeber at cc.univie.ac.at> writes: * Hi Mirjam! * * >Subj: Proposal for Temporary Special Class A Space Guidelines * * Good stuff! * * Just a couple of minor (general) comments, a few proposals for * clarification in the context of the proposed text, as well as a couple * of questions. * * General: * * . I'm slightly unhappy with the frequent use of the terms "class A" and * "class C". I think we are trying for a while now to sort of phase-out * the usage of these terms. So I'd prefer to * * - clearly qualify the usage of these terms as obsolete, or "old * classful terminology", * * - wherever possible, please replace "class x" with the appropriate * address range. I think this would make the paper more obvious * anyway. We tried to get the terminology right and realised that it is hard to use classless terminology for classful addresses ;-) You cannot always use just prefix notation when you really mean the address space formerly known as "class A" address sapce. But I will go through the text again and make the necessary changes where possible. * * . While in general there is a one-to-one correspondance of Local-IR and * ISP (routing-wise), I think we could be a bit more careful to refer * to a Local-IR when we talk about assignments, and to refer to the * routing or operations group of an ISP when talking about * routing/operations. Good point. I will change it where possible. * * Apologies, if I'm doing nit-picking again :-) * No, you're not. Very useful comments as always :-) Regards, Mirjam * Wilfried. * -------------------------------------------------------------------------- * Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at * Computer Center - ACOnet : * Vienna University : Tel: +43 1 4065822 355 * Universitaetsstrasse 7 : Fax: +43 1 4065822 170 * A-1010 Vienna, Austria, Europe : NIC: WW144 * -------------------------------------------------------------------------- * * Temporary Special Class A Space Guidelines * Kuehne, Karrenberg * D R A F T * ____________________________________________________ * * * * * Temporary Special Guidelines for * * Allocation and Assignment * * of address space out of class A ranges. * * Mirjam Kuehne * Daniel Karrenberg * * * Background * * Before the introduction of classless inter-domain * routing CIDR [RFC1519] the unicast IP address space * was divided into three ranges called A, B and C each * assotiated with a routing prefix length of 8, 16 and * 24 bits respectively. In this context IP addresses * are often called class A, B or C addresses depending * on the range. With CIDR the prefix length informa- * tion is carried in the routing protocols and it is * technically insignificant which particular range an * address belongs to. * * Whenever classful routing protocols or obsolete * *** proposal ^^^^^^^^ * As long as ... * * TCP/IP host implementations are being used the class * *** ^^^^^ * "class" (as implied by the particular range) * * of the address can become significant because either * it determines prefix length in routing or other * assumptions are being made from the class of the * address. Classful software can be configured to * work properly by using subnetting [RFC950] or basing * configurations on the prefix length implied by the * address class. * * The Internet registires have been assigning * ***typo ^^^ * ***proposal addresses out of the class C range for the last cou- * ^^^ * <insert values here, please> * ple of years because this was believed to cause the * least problems with obsolete classful software on * the perimeter of the Internet. * * However there is only a limited amount of unallo- * cated class C address space available. More than 50% * of the class C address space is allocated and some * parts of the remaining ranges are reserved by IANA. * Currently the largest amount of unallocated addresses * ***proposal is of class A. Therefore regional Internet registries * ^^^ * <insert values here, please> * will at some point have to use allocations from class A * space. * * In April 1995 an experiment started to find out * if classless use of the former class A addresses * (1.0.0.0 - 126.255.255.255) would create any signifi- * cant problems wrt routing. The aim of this experiment * * ____________________________________________________ * Page 1 * Temporary Special Class A Space Guidelines * Kuehne, Karrenberg * D R A F T * ____________________________________________________ * * is described in RFC1797. * * The experiment ran for 6 month and was considered * ***typo a success.The results of are described in RFC1879 * ^^^^^^ * including possible problems and solutions. * * * RIPE Community Initiative * * To promote the use of classless addressing the RIPE * NCC has taken initiative to give local IRs in its * service region a choice of allocations either from * class C or class A space. * * At the 26th RIPE meeting held in Amsterdam in Jan- * uary 1997 the RIPE community welcomed this initia- * tive and expressed their interest in assigning this * type of addresses to their customers. There was * consensus that in order to encourage usage of class * A address space, allocation and assignment guide- * lines for this space should be temporarily relaxed * if IANA and the other regional IRs agree to this. * The RIPE NCC was asked to make a proposal. * * The following sections will describe the special * allocation procedures the RIPE NCC proposes. * * * Special Allocation Rules * * From April 1997 until December 1997 special guide- * lines will apply to the allocation and assignment of * class A address space. These guidelines are addi- * tions to the normal procedures [ripe-140]. * ***sugg. ^^^^^^ * regular? basic? * During this time every orgnisation established as a * ***typo ^^^^ * ***proposal * <remove the phrase "organisation established as a", * unless it refers to something special which I don't * understand?> * * LIR in the service reigion of he RIPE NCC may * ***typo ^^^^ * request an additional allocation of class A address * space. * * This means for a limited amount of time each LIR can * ***sugg. ^^^^ * any ? * hold two allocations of the same size: one from * class C address space (currently 195.0.0.0/8) and * one from class A (to be allocated by IANA). * * * In order to limit the adverse effect of these spe- * * cial allocations on routing table growth, global * * routing annnouncements for this address space should * * be kept at an absolute minimum. Ideally each allo- * * cation will be announced via just one prefix. Addi- * * tional prefixes should only be announced globally if * * this is technically necessary. * * ***question what is the special case for assignments out of the * traditional class A space, as compared to any other * "regular" assignment by way of the regional and local * regsitries? * * Once a LIR has obtained an allocation from class A * space in addition to an already existing allocation * *** sugg. ^^^^^^^ * <remove> * ____________________________________________________ * Page 2 * Temporary Special Class A Space Guidelines * Kuehne, Karrenberg * D R A F T * ____________________________________________________ * * from class C space the following rules apply: * * * 1. If the address space from the class A alloca- * ***sugg. ^^^ * a * tion is entireley assigned, another class A * allocation can be requested. * * * 2. If the address space from the class C alloca- * ***sugg. ^^^ * a * tion is entirely assigned, another class A or * class C allocation can be requested. * * * This means that a LIR can have two class A alloca- * tions or one allocation of each class but never two * class C allocations. * * After the expiration of the special period the usual * allocation policies apply, i.e. every LIR can only * hold one free alocation of a maximum of a /16 at a * ***quest., typo ^^^^ * <what is a "free" allocation?> * * time. This means that first all allocations the LIR * has at this point in time must be finished before * additional address space can be allocated. * * * If the LIR has at this point decided that it will * * not continue assigning from class A address space it * * has the possibility to return the class A alloca- * * tion. It can then request an additional class C * * allocation once the previously allocated class C * * addresses are assigned entirely. * * * ***question wrt to routing table size, is the LIR expected to * return the whole block, including the assigned * componentes, or just the subset which has not yet been * assigned? * I'd propose to reclaim the whole block. * * Special Assignment Guidelines * * In order to motivate not only LIRs to use class A * ***sugg. ^^^^ * <I think this is targetting ISPs (routing-wise) and * end-users. Strictly speaking, for the LIR it's just * numbers and the LIR shouldn't care :-).> * * address space but also end-users to use class A * address space in their networks special assignment * policies apply until the end of the special period. * * * 1. A temporary assignment from class A space in * addition to an already existing assignment from * ***proposal ^^^^ * class C address space can be made without * ^^^^^^^^^^^^^^^^^^^^^ * <remove that phrase, *unless* you explicitely want to * restrict that simplified approach to applicants that * do not hold (A or) B space. I think it would be a * good idea *not* exclude that scenario!> * * detailed documentation so that the end-user can * experiment with these addresses. * * * 2. This additional assignment can have up to the * same size of the total previously assigned * address space but not more than a /19. * * * * ____________________________________________________ * Page 3 * Temporary Special Class A Space Guidelines * Kuehne, Karrenberg * D R A F T * ____________________________________________________ * * * 3. The class A address space must be returned by * * the end-user to the appropriate Internet reg- * * istry 6 months after the assignment or the * * usage of the addresses must be documented prop- * * erly according to normal assignment rules * * [ripe-141]. * * * ***proposal < * - duration of temporary assignement can be agreed * with the end-user and/or specified by the LIR * * - validity expires at the end of the special period * * - if the LIR decides to continue to assign addresses * from class A space allocation, then assignment has * to be converted to a regular assignment. * -----> for the else-clause, please see previous comment! * * - conversion to a regular assignment involves * submitting documentation according to * ripe-whatever, and adjusting the size of the * assignment if necessary. * > * * Note: As per these rules address space assign- * ments can be justified by returning an equiva- * lent ammount of addresses as well as by docu- * menting new use. * * * 4. The LIR is obliged to clearly inform the * address space user about the special rules that * apply to the additional assignment before it is * made. LIRs are encouraged to advise users to * plan ahead. * *** quest. ^^^^^^^^^^ * <what?> * * 5. All assignments no matter from wich allocation * must be registerd in the RIPE database. * * * Conclusion * * In order to promote classless addressing and to * address the shortage of class C address space, the * RIPE NCC proposes to give all LIRs in its service * region the chance to prepare for the final transi- * tion to classless addressing and the use of class A * address space. * * This document proposes to create special guidelines * for addresses from class A space until the end of * * 1997. After this period it is expected that most * * registries are prepared to assign class A address space * * to their customers as as well as to their own networks. * * * ***comment: This sort of vaguely contradicts the (implied) freedom, * as outlined by this paper, to decline future allocations * from former class A space and to stick with the class C * range? * * * * * * * * * * * * * * ____________________________________________________ * Page 4 * --------------------------------------------------------------------------- * -----
[ lir-wg Archives ]