From Mirjam.Kuehne at ripe.net Tue Mar 4 15:26:26 1997 From: Mirjam.Kuehne at ripe.net (Mirjam Kuehne) Date: Tue, 04 Mar 1997 15:26:26 +0100 Subject: Proposal for Temporary Special Class A Space Guidelines Message-ID: <9703041426.AA18918@ncc.ripe.net> Dear chair people and local registries, dear IANA, During the Local IR working group at the 26th RIPE Meeting in January in Amsterdam we learned that many local registries would be interested and prepared to assign addresses from former class A space. Because most registries have no experience with class A adddress space yet the RIPE NCC proposes to introduce new guidelines for a certain period of time. The proposal is attached below. Please send all comments, questions and suggestions you might have until the 17th March 1997 to me personally. We are planning to publish the proposal as a RIPE document after this date. Kind Regards, Mirjam Kuehne Manager Registration Services RIPE NCC ------- 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 TCP/IP host implementations are being used the class 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 addresses out of the class C range for the last cou- 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 is of class A. Therefore regional Internet registries 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 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]. During this time every orgnisation established as a LIR in the service reigion of he RIPE NCC may request an additional allocation of class A address space. This means for a limited amount of time each LIR can 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. Once a LIR has obtained an allocation from class A space in addition to an already existing allocation ____________________________________________________ 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- tion is entireley assigned, another class A allocation can be requested. 2. If the address space from the class C alloca- 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 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. Special Assignment Guidelines In order to motivate not only LIRs to use class A 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 class C address space can be made without 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]. 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. 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. ____________________________________________________ Page 4 From woeber at cc.univie.ac.at Wed Mar 5 10:28:18 1997 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 05 Mar 1997 10:28:18 MET-DST Subject: Proposal for Temporary Special Class A Space Guidelines Message-ID: <009B0CD8.6802A09C.1@cc.univie.ac.at> 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. . 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. Apologies, if I'm doing nit-picking again :-) 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- ^^^ 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 ^^^ 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 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. ^^^^^^^ ____________________________________________________ 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 ^^^^ 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. ^^^^ 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 ^^^^^^^^^^^^^^^^^^^^^ 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. ^^^^^^^^^^ 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 -------------------------------------------------------------------------------- From Mirjam.Kuehne at ripe.net Wed Mar 5 11:54:22 1997 From: Mirjam.Kuehne at ripe.net (Mirjam Kuehne) Date: Wed, 05 Mar 1997 11:54:22 +0100 Subject: Proposal for Temporary Special Class A Space Guidelines In-Reply-To: Your message of Wed, 05 Mar 1997 10:28:18 +0700. <009B0CD8.6802A09C.1@cc.univie.ac.at> Message-ID: <9703051054.AA12715@ncc.ripe.net> Dear Wilfried, Thank you for your comments. "Wilfried Woeber, UniVie/ACOnet" 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- * ^^^ * * 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 * ^^^ * * 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 * * * 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. ^^^^^^^ * * ____________________________________________________ * 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 ^^^^ * * * 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. ^^^^ * * * 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 * ^^^^^^^^^^^^^^^^^^^^^ * * * 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. ^^^^^^^^^^ * * * 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 * --------------------------------------------------------------------------- * ----- From mnorris at hea.ie Wed Mar 5 14:27:16 1997 From: mnorris at hea.ie (Mike Norris) Date: Wed, 05 Mar 97 13:27:16 +0000 Subject: Proposal for Temporary Special Class A Space Guidelines Message-ID: <199703051327.NAA17923@dalkey.hea.ie> Hi Mirjam mind if I piggy-back on Wilfried's comments? I'll use !!! instead of *** if that's OK. > Good stuff! Yes indeed! > . 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. Not an easy one. Sure, you can put the offending terms in quotes, as Wilfried does, to indicate disdain for this old politically incorrect terminology. But there's no getting away from the fact that when you say Class A in the document, you really mean Class A and not /8 - you don't mean that 196.0.0.0/8, for example, comes under the heading of Class A for the purposes of special allocation. Instead of Class A, you could say "addresses in the range 1.0.0.0 - 126.255.255.255" or something, but this could be clumsy and why not use the term that means the same, anyway. > . 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. Cheers. Mike 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 ^^^ !!! maybe say "The Internet registries, regional and local, have been...." ***proposal addresses out of the class C range for the last cou- ^^^ ple of years because this was believed to cause the least problems with obsolete classful software on the perimeter of the Internet. !!!It's been more than a couple (which means 'two') of years, more like five years. 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 ^^^ 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 ^^^ !!! spell it out - 'with respect to' ____________________________________________________ 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 ^ !!! insert 'the' 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. !!! Hmm, I'm not too sure about this "temporary relaxed" bit. The document we adopted and use (rip1-140) is called "European Internet Registry **Policies and Procedures**" (my emphasis). Policies, I think, have a slightly higher status than guidelines. Anyway, here's what was reported the LIR WG mtg at RIPE 26: A question arose as to whether Local IRs would be able to ease the requirements associated with address space assignments in order to encourage their customers to take an assignment from Class A space. There was *no* consensus on this issue, and it was therefore decided that the normal policies apply at least until further discussion can take place. So the normal policies should continue. What you are proposing now is in addition to the normal policies. ripe-140 was written and adopted in the context of the current RIPE NCC allocation and that allocation (193.0.0.0/8, 194.0.0.0/8 and 195.0.0.0/8) is specified in the text. I think it would be helpful if the proposal were framed as an addition or adjunct to the current policies and not a relaxation of policies. You say this two paragraphs down, so maybe reword the above along the same lines. 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 !!! suggestion: "During this time, any organisation established as a LIR in the service region of the RIPE NCC..." 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. ^^^^^^^ ____________________________________________________ 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 ^^^^^^^^^^ !!!entirely 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 ^^^^ 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- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ !!! suggest "has the option of returning..." * tion. It can then request an additional class C * allocation once the previously allocated class C * addresses are assigned entirely. ^^^^^^^^^^^^^^^^^^^^^ !!! suggest "are entirely assigned." * ***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. ^^^^ 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 ^^^^^^^^^^^^^^^^^^^^^ 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- ^^^^^^^ !!! amount 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. ^^^^^^^^^^ 5. All assignments no matter from wich allocation ^^^^ !!! which 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? Another comment: given that the proposal is for a limited special allocation, but that the goals are more long-term, would it be useful to suggest a review at the end of the special period to measure progress towards the goals. M From volar at alpha.dcs.fmph.uniba.sk Thu Mar 6 02:10:02 1997 From: volar at alpha.dcs.fmph.uniba.sk (Daniel Volar) Date: Thu, 6 Mar 1997 02:10:02 +0100 (MET) Subject: Proposal for Temporary Special Class A Space Guidelines In-Reply-To: <199703051327.NAA17923@dalkey.hea.ie> from Mike Norris at "Mar 5, 97 01:27:16 pm" Message-ID: <199703060110.AA03580@alpha.dcs.fmph.uniba.sk> hello mike, > > Good stuff! > > Yes indeed! me too. > > . 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. > > Not an easy one. Sure, you can put the offending terms in > quotes, as Wilfried does, to indicate disdain for this old > politically incorrect terminology. But there's no getting > away from the fact that when you say Class A in the document, > you really mean Class A and not /8 - you don't mean that > 196.0.0.0/8, for example, comes under the heading of Class A > for the purposes of special allocation. > > Instead of Class A, you could say "addresses in the range > 1.0.0.0 - 126.255.255.255" or something, but this could be > clumsy and why not use the term that means the same, anyway. i agree it's helluva clumsy and i've got an idea to use the (i think) easily understood term "traditional class A address space" which is meant as `all addresses in the range 1.0.0.0-126.255.255.255.' what's your opinion? > Cheers. > Mike cheerio, dinyl. From mnorris at hea.ie Thu Mar 6 10:25:40 1997 From: mnorris at hea.ie (Mike Norris) Date: Thu, 06 Mar 97 09:25:40 +0000 Subject: Proposal for Temporary Special Class A Space Guidelines In-Reply-To: Your message of "Thu, 06 Mar 97 02:10:02 +0100." <199703060110.AA03580@alpha.dcs.fmph.uniba.sk> Message-ID: <199703060925.JAA19507@dalkey.hea.ie> >i agree it's helluva clumsy and i've got an idea to use the (i think) easily >understood term "traditional class A address space" which is meant as >`all addresses in the range 1.0.0.0-126.255.255.255.' what's your opinion? Dinyl yes, I think 'traditional' is a good choice of word. The use of terms like 'Class A' is traditional and the meaning is well known in terms of the range of addresses covered. At the same time, the adjective 'traditional' is fairly neutral. Mind you, I wonder whether the Internet is old enough yet to have traditions. Habits maybe, but traditions...? Cheers. Mike From mahmed at ns.on-net.co.uk Thu Mar 6 17:20:49 1997 From: mahmed at ns.on-net.co.uk (Mobasshar Ahmed) Date: Thu, 6 Mar 1997 16:20:49 +0000 (GMT) Subject: Proposal for Temporary Special Class A Space Guidelines In-Reply-To: <199703060925.JAA19507@dalkey.hea.ie> Message-ID: On Thu, 6 Mar 1997, Mike Norris wrote: > > >i agree it's helluva clumsy and i've got an idea to use the (i think) easily > >understood term "traditional class A address space" which is meant as > >`all addresses in the range 1.0.0.0-126.255.255.255.' what's your opinion? > > Dinyl > yes, I think 'traditional' is a good choice of word. > The use of terms like 'Class A' is traditional and the > meaning is well known in terms of the range of addresses > covered. At the same time, the adjective 'traditional' > is fairly neutral. > > Mind you, I wonder whether the Internet is old enough yet > to have traditions. Habits maybe, but traditions...? > > Cheers. > > Mike > Trasitions means its still carried out. How about 'Historic Class A' Hopefully meaning that its not practised any more! --- Mobasshar Ahmed http://www.on-net.co.uk Technical Manager mahmed at on-net.co.uk ON-NET Yes we sell to ISPs Tel: ++44-181-256-9990 FAX: ++44-181-288-0222 From mnorris at hea.ie Thu Mar 6 17:28:41 1997 From: mnorris at hea.ie (Mike Norris) Date: Thu, 06 Mar 97 16:28:41 +0000 Subject: Proposal for Temporary Special Class A Space Guidelines In-Reply-To: Your message of "Thu, 06 Mar 97 16:20:49 GMT." Message-ID: <199703061628.QAA20493@dalkey.hea.ie> >Trasitions means its still carried out. How about 'Historic Class A' >Hopefully meaning that its not practised any more! Better yet! Mike From John.Murray at planet.net.uk Thu Mar 6 18:46:52 1997 From: John.Murray at planet.net.uk (John Murray) Date: Thu, 06 Mar 1997 17:46:52 +0000 Subject: Proposal for Temporary Special Class A Space Guidelines Message-ID: <199703061746.RAA28808@halo.theplanet.net> Hi, > > . 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. > > Not an easy one. Sure, you can put the offending terms in > quotes, as Wilfried does, to indicate disdain for this old > politically incorrect terminology. But there's no getting > away from the fact that when you say Class A in the document, > you really mean Class A and not /8 - you don't mean that > 196.0.0.0/8, for example, comes under the heading of Class A > for the purposes of special allocation. > > Instead of Class A, you could say "addresses in the range > 1.0.0.0 - 126.255.255.255" or something, but this could be > clumsy and why not use the term that means the same, anyway. How about just: 0.0.0.0/2 (old 'A' space) 128.0.0.0/2 (old 'B' space) 192.0.0.0/2 (old 'C' space) Cheers john From clive at demon.net Thu Mar 6 22:30:17 1997 From: clive at demon.net (Clive D.W. Feather) Date: Thu, 6 Mar 1997 21:30:17 +0000 (GMT) Subject: Proposal for Temporary Special Class A Space Guidelines In-Reply-To: <199703061746.RAA28808@halo.theplanet.net> from "John Murray" at Mar 6, 97 05:46:52 pm Message-ID: <857683817.20314.0@office.demon.net> John Murray said: > How about just: > > 0.0.0.0/2 (old 'A' space) > 128.0.0.0/2 (old 'B' space) > 192.0.0.0/2 (old 'C' space) Except that the original allocations were: Class A: 0.0.0.0/1 (I am ignoring the issues of 0.0.0.0/8 and 127.0.0.0/8) Class B: 128.0.0.0/2 Class C: 192.0.0.0/3 Class D: 224.0.0.0/4 Class E: 240.0.0.0/4 (I think it was /4 and not /5) -- Clive D.W. Feather | Associate Director | Director Tel: +44 181 371 1138 | Demon Internet Ltd. | CityScape Internet Services Ltd. Fax: +44 181 371 1037 | | From jhma at EU.net Fri Mar 7 01:58:54 1997 From: jhma at EU.net (James Aldridge) Date: Fri, 07 Mar 1997 01:58:54 +0100 Subject: Proposal for Temporary Special Class A Space Guidelines In-Reply-To: Your message of "Thu, 06 Mar 1997 17:46:52 GMT." <199703061746.RAA28808@halo.theplanet.net> Message-ID: <199703070058.BAA15003@aegir.EU.net> In message <199703061746.RAA28808 at halo.theplanet.net> you write: > > Instead of Class A, you could say "addresses in the range > > 1.0.0.0 - 126.255.255.255" or something, but this could be > clumsy and why not use the term that means the same, anyway. > > How about just: > > 0.0.0.0/2 (old 'A' space) > 128.0.0.0/2 (old 'B' space) > 192.0.0.0/2 (old 'C' space) Surely 0.0.0.0/1, 128.0.0.0/2, & 192.0.0.0/3 or else you erroneously exclude half the address space formerly classed as `A' (64.0.0.0/2) and include the 224.0.0.0/4 (`Class D'/Multicast) and 240.0.0.0/4 (`Class E') address blocks. How about simply using the phrase `former Class {A,B,C} space' when talking about these ranges, maybe with a note relating these to the 0/1, 128/2 and 193/3 notation. James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 622 4657 - ----- 24hr emergency number: +31 20 421 0865 From Yves.Devillers at EUnet.fr Fri Mar 7 10:22:30 1997 From: Yves.Devillers at EUnet.fr (Yves Devillers) Date: Fri, 07 Mar 97 10:22:30 N Subject: Proposal for Temporary Special Class A Space Guidelines In-Reply-To: Your message of Thu, 06 Mar 97 17:46:52 GMT. <199703061746.RAA28808@halo.theplanet.net> Message-ID: <199703070922.AA12159@relay2.eunet.fr> In message <199703061746.RAA28808 at halo.theplanet.net> john.murray at planet.net.uk wrote: > Instead of Class A, you could say "addresses in the range > 1.0.0.0 - 126.255.255.255" or something, but this could be > clumsy and why not use the term that means the same, anyway. How about just: 0.0.0.0/2 (old 'A' space) 128.0.0.0/2 (old 'B' space) 192.0.0.0/2 (old 'C' space) ==> "Formerley known as" or "formerly named" is probably more precise (at least to non-english speakers) that "old" (how old is your A space ?) Yves Devillers --------------------------------------------------------------------------- ========= ____ ===== Yves Devillers ======== / / / ___ ___ /_ ====== Directeur technique ======= /---- / / / / /___/ / ======= EUnet-France ====== /____ /___/ / / /___ /_ ======== 52, av. de la Grande Armee ===== ========= 75017 Paris, France E-mail: Yves.Devillers at EUnet.fr http: //www.EUnet.fr Tel: +33 01 53 81 60 60 Fax: +33 01 45 74 52 79 From ronald at arcadis.be Fri Mar 7 11:54:02 1997 From: ronald at arcadis.be (Ronald Kraaijer) Date: Fri, 7 Mar 1997 11:54:02 +0100 Subject: Proposal for Temporary Special Class A Space Guidelines In-Reply-To: <199703070922.AA12159@relay2.eunet.fr> References: Your message of Thu, 06 Mar 97 17:46:52 GMT. <199703061746.RAA28808@halo.theplanet.net> Message-ID: Why not leave it as it used to be, but just add the "/" notation since most people still refer to the "Class" IP addresses. It would avoid confusion, and everybody knows what you mean when you refer to a network with the / notation. Ronald Kraaijer At 11:22 AM +0100 3/7/97, Yves Devillers wrote: >In message <199703061746.RAA28808 at halo.theplanet.net> >john.murray at planet.net.uk wrote: > > > > Instead of Class A, you could say "addresses in the range > > 1.0.0.0 - 126.255.255.255" or something, but this could be > > clumsy and why not use the term that means the same, anyway. > > How about just: > > 0.0.0.0/2 (old 'A' space) > 128.0.0.0/2 (old 'B' space) > 192.0.0.0/2 (old 'C' space) > >==> "Formerley known as" or "formerly named" is probably more precise (at >least >to non-english speakers) that "old" (how old is your A space ?) > > > Yves Devillers > > --------------------------------------------------------------------------- > > ========= ____ ===== Yves Devillers > ======== / / / ___ ___ /_ ====== Directeur technique > ======= /---- / / / / /___/ / ======= EUnet-France > ====== /____ /___/ / / /___ /_ ======== 52, av. de la Grande Armee > ===== ========= 75017 Paris, France > E-mail: Yves.Devillers at EUnet.fr http: //www.EUnet.fr > Tel: +33 01 53 81 60 60 Fax: +33 01 45 74 52 79 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ronald Kraaijer (rkraaijer at arcadis.be) Network Manager | Voice: 02/534-1100 Arcadis SA/NV~ Internet Access and Web Services | Fax: 02/534-1188 151 rue Jourdan, 1060 Brussels, Belgium | Info: 0800/97-030 info at arcadis.be, http://www.arcadis.be | BBS: 02/534-3311 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~