- lir-wg - mailman.ripe.net

RE: Proposal for Temporary Special Class A Space Guidelines
by Wilfried Woeber, UniVie/ACOnet 05 Mar '97

05 Mar '97

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(a)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 --------------------------------------------------------------------------------

2 1

Proposal for Temporary Special Class A Space Guidelines
by Mirjam Kuehne 04 Mar '97

04 Mar '97

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

1 0

Local Whois Server
by Yucel Guven 18 Feb '97

18 Feb '97

Hi, Here, in Middle East Tech. University (METU), we setup a whois server. Together with updating RIPE sources, we also want RIPE NCC directly to communicate with our whois-server and got the all neccessary info's (such as inetnum:'s domain:'s person:'s etc..) Is this possible? If possible, could you inform me about the steps we must follow? TIA. Yucel Guven METU Computer Center, Network Group e-mail: yucel(a)metu.edu.tr tel : +90 (312) 2102091 fax : +90 (312) 2101120 metu-nic: YG1-METU ripe-nic: YG251-RIPE

1 0

Minutes of LIR WG meeting at RIPE 26
by Mike Norris 04 Feb '97

04 Feb '97

Below are the minutes of the LIR WG meeting on 20th Jan, kindly prepared by our scribe, Carol Orange. Any inaccuracies or omissions are my fault, and open to correction by list members. Regards. Mike Norris Local IR Working Group meeting Chair: Mike Norris RIPE-26 Mon Jan 20 1997 1. Preliminaries Scribe: Carol Orange Agenda: agreed, without adjustment Participants: At RIPE-26 Local IR WG, /26 = 2^6 = 64 attended. 2. RIPE-25 Minutes: no comments Actions: 1. Charging paper published as: ripe-152. 2. The LIR Training slides are currently being converted to HTML. 3. Reports from registries + Mirjam Kuehne gave the RIPE NCC Registration Services report. Her slides can be obtained in: ftp: //ftp.ripe.net/ripe/presentations/ripe-m26-mir-RS-Report.ps.gz http://www.ripe.net/meetings/ripe/ripe-26/pres/ncc-reg/ + Other registry stuff: Mike Norris reports that there are interesting statistics on ISPs in the US in: http://www.boardwatch.com/isp/intro2.htm + Other Regional Registries: Daniel reported that cooperation among the three regionals remains good, and that there is substantial contact. He also reported on the development of ARIN, the American Registry for Internet Numbers (http://rs.internic.net/arin) ARIN closely resembles the RIPE NCC and APNIC regional registry model both in terms of operations and charging. This development strengthens the position of the RIPE NCC and other Regional registries. Together, the three registries are an excellent example of industry self regulation. The question arises as to whether the IANA should eventually be run by the regionals since together they represent the user community. ARIN is planned to be independent of NSI in 2nd Quarter of 97. Daniel says they will be watching the breakoff from NSI closely, as it resembles the RIPE NCC breakoff from TERENA to take place before January 1, 1998. 4. IP Address Space Assignment + RIPE policy, ripe-140 Mike Norris pointed out that both the policy document (ripe-140) and the associated procedures document (ripe-142) have been in place for a time, and are working well. + IETF WG: IRE --> PAGAN A new IETF working group in the operations area called PAGAN (Policies and Guidelines for Allocations of Network numbers) was kicked off in San Jose to discuss registry policy issues. You can subscribe to the mailing list by sending "subscribe" in the body of a message to "pagan-request(a)apnic.net". + Use of A's Mike Norris informed the group that ther is a new RFC (rfc2036) entitled: "Observations on the use of Components of the Class A Address Space within the Internet" The document examines the implications for service providers and end clients who get an allocation or assignment of the unallocated Class A address space. DFK: For next allocation, we can ask IANA for 1. A /8 in Class C space. 2. A /8 in Class A space. 3. Both. It was pointed out that while option 1 is safe in the short run, that when the Class C space runs out, we will have no experience with the Class A space which at that point will be the only IPv4 address space at our disposal. It was therefore considered optimal to obtain a /8 from Class A space immediately, and allow those interested in working with it to have an allocation next to their Class C allocation to assign from as they see fit. There were about 15 people present who said they understood the nature of the issues associated with making Class A assignments and would be interested in such an allocation. Daniel said he would request a /8 in Class A space from IANA immediately. 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. 5. IP Address Space Usage and Reclamation + use of Class B's It was agreed that this is not a significant issue at the moment. + reclamation of 192.0.0.0/8 It was noted that Bill Manning's effort to get back the address space in 192 seems to have died out. This raised a question about the followup to the "dollar BOF" at the 36th IETF in Montreal. The proposal to set up an IETF working group (PIARA) in which the possibility of experimenting with marketing IPv4 address space (starting with 192.0.0.0/8) has been formally dropped by the IESG who says it falls outside the charter of the IETF. 6. Training + RIPE training courses Aside from the report that the RIPE NCC regularly holds Local IR training courses around Europe and will continue to do so (also in a broader region), Mirjam Kuehne brought up the problem that there are an increasing number of people who sign up, but don't show up. Lars Liman suggested that the RIPE NCC charge a fee to sign up which is returned to those who show up at the course, but not to others. There was consensus that the RIPE NCC should introduce some form of financial back-pressure to prevent this problem, which the NCC happily agreed to do. + Local IR Workshop Rather than having a local IR workshop in conjunction with RIPE 27 in Dublin, it was suggested by Wilfried Woeber that we hold a Database workshop with an emphasis on its use by local Internet registries and their requirements of the RIPE database. It was agreed that such a workshop will be held at RIPE 27. + Other training e.g. APRICOT Mike Norris noted that there is a broad range of in depth tutorials taking place at the APRICOT (Asian Pacific Operators) meeting at the end of January. He asked those attending to give input to the RIPE community on the usefulness of these trainings, that we might hold similar courses in conjunction with future RIPE meetings. Daniel and Mirjam, who are attending APRICOT agreed to give input for the next meeting. 7. Input / Output with other working groups None. 8. Tools + registry administration + stats Bernard Stockman asked if anyone had had experience with "netramet" for gathering network statistics. Wilfried said he'd worked with it quite some time ago, but found it unwieldly (hard to configure to collect the right stuff). It was noted that work on this tool continues and that people may want to check it out. 9. Reverse Domains + counts, errors Daniel noted that the behavior for 193-195 is good, but did not have exact statistics. + administration It was noted that increasingly servers are refusing to allow the NCC to do zone transfers, and claim doing so would cause security risks. This was considered generally unacceptable, as the NCC is chartered to safeguard the quality of the 193-195.inaddr.arpa name space data. 10. AOB Yves Devillers mentioned that it was hard to convince customers wanting connectivity for PI/UNSPECIFIED space already assigned to them to renumber into one of the local IR's PA blocks. He asked what the NCC response is when approached. John Crain answered that we try to convince people to renumber. A question was also raised as to what happens to a local IR's allocation if the local IR closes. Daniel stated that it depends on the circumstances. If it is a takeover by another local IR, then the space will just be allocated by the local IR taking over. There are a lot of complicated scenarios possible, but luckily they've not come up yet in practice. He stated that each closing local IR will have to be dealt with carefully on an individual basis to make sure the customers suffer as little as possible.

1 0

Reclamation of 192.0.0.0/8 space
by Mike Norris 24 Jan '97

24 Jan '97

Please see the below re the above, as discussed at at the LIR WG mtg on Monday. Mike --------------------------------------8<---------------------------- Message-Id: <199701020201.LAA08209(a)moonsky.jp.apnic.net> To: pagan(a)apnic.net Subject: IRE->PAGAN Minutes Date: Thu, 02 Jan 1997 11:01:19 +0900 From: "David R. Conrad" <davidc(a)apnic.net> Sender: owner-pagan(a)apnic.net Hi, Sorry for the long silence. Holidays get in the way... I have changed the name of the working group mailing list to pagan(a)apnic.net (pagan-request for administrivia -- it is a majordomo list). The IRE addresses (ire, ire-request) will continue to work. I've left the archive names as ftp://ftp.apnic.net/mailing-lists/ire/ire.* (it's actually a symbolic link to ftp://ftp.apnic.net/mailing-lists/pagan/ire.*) but new archives will be pagan.archive.*. I've included the rough draft of the IRE minutes. Please send comments/changes/additions/deletions to me. With respect to the goals document, the original plan was to have a rough draft available by Dec 31. This was a bit optimistic. Hope to have something by Jan 15. Regards, - - -drc - - -------- IRE minutes, Monday, Dec 10, 1996 Minutes taken by sheer(a)eni.net, modified by davidc(a)apnic.net New working group name - - ---------------------- A rough consensus was formed on Policies And Guidelines for Allocation of Network numbers (PAGAN). The minutes will reflect that the name has been changed to PAGAN. Charter Review - - -------------- The query was placed as to weather this is a replacement for 1466, and/or 2050. The rough consensus was that this BOF was organized to revise 2050 to apply better to the future. The comment was made, repeatedly, that "If you are interested in DNS, go away. We have nothing to do with DNS" The correction was made to the Dec 31, 1997 date to change from ' draft' to 'final version'. The suggestion was made that goals shopuld be done sooner. The change was made to finalize the goals by Apr 1, 1997. The April date will be after the IETF, by suggestion. Registry Status Reports - - ----------------------- RIPE-NCC reported that nothing much has changed, although they had 8 people assigning addresses to customers, and the Europian address allocation guidelines document was finished (RIPE 140). APNIC reported that they had 3 full time and one part time staff, and had about 125 members. Current distribution of (self-determined) member "size" is running around 20% large, 30% medium, and 50% small, with yearly membership fees of $10k, $5k, and $2.5k, respectively. Currently APNIC is allocating out of the 210 block and have alocated most of the AS number they had, have about 7 left. Due to tax considerations, APNIC will likely be forced to relocate from Tokyo, Japan to elsewhere in the Asia Pacific Rim region. A question was asked weather AP-NIC was still losing money. The answer was no, APNIC has $275k in the bank. InterNIC reports that around 95% of IP allocations are for ISPs. InterNIC is faced with a lot of multi-homed ISPs, ISPs who need routable blocks because they are connected directly to a NAP, and direct assignments to end users. The future of the interNIC IP registry is to become a non profit org, similar to APNIC and RIPE, with membership and fees, a NSI as the funding backstop until it is self sustaining. A discussion will be held on the mailing list (listserv(a)internic.net, send a message body of "subscribe NAIPR"). A question was asked what the fee structure was going to be like. The answer was that it would resemble APNIC's. Once the membership is built up, it will be up to the members what the fees are. A question was asked what happens to end user IP allocations. The answer was that right now, there is nothing to discourage end users from hitting the NIC up for addresses, in fact, under RFC1814, the registries must provide address space. There will be a discussion over whether RFC 1814 will be moved to historic. nA question was raised whether membership to the new IP registry will be open or not. The answer was yes. A question was raised whether large end users can become members of the registry. The answer was yes. Time frame is for establishment is around April, 1997. Rough consensus was formed for the InterNIC's new registry plan. 192 recovery - - ------------ "Long ago and far away before much of this had happened, there was a tremendous amount of dead space in the IPv4 allocation pool". All of the contacts listed in the /8 space were asked if they were done with it, and if so, if they would bring it back. So far, 13% of the total IPv4 space has been recovered. There are now more addresses in the free pool than there were 18 months ago. The 192 space is considered to be one of the largest problems with routing tables (the C class dumping ground). So attempts were made to recover the 192 space. Most of the attempts resulted in email bounces. About 3000 responded, of which, 10% turned over their space. Most 192 space turned out to be allocated, but not connected and seeable from the public internet. One problem with recovering the space is finding out what registry is authoritative. The US DOD NIC was keeping information in the 192 space, as well as RIPE-NCC. The information about this project was posted in NANOG. About 1/3 of the 300 IP addresses recovered were in the global routing table. The point was made that the most important thing learned by the 192 reclimation project is that we don't know that much about that space. A question was raised as to whether the effort should be formalized. A rough consensas was yes. The question was raised how NICs were keeping their databases up. The answer from APNIC was that they were polling the database to find out when the information was bad, although there had been no resolution yet as to what to do when they found out it was. JPNIC Class B Utilization Survey - - -------------------------------- JPNIC IP Working group email address is ip-wg(a)nic.ad.jp Purpose: - To study address utilization - Not to force to return addresses Survey Form: - Emailed to 770 Technical and adminstrative contacts of 404 class-B's in Japan in late August - 246 replies received by October 22 Some statistics were presenented - Average number of hosts is ~2k, std dev is 3180 - Average number of connected hosts is 843, std dev is 3480 - Average number of hosts per subnet is 15.23, std dev is 150 The rough consensus was that the standard deviations of these statistics imply the statistics are not particularly useful. Also organizations should probably consider renumbering (among much laughter) The question was raised when the survey was sent out, how many emails to the contacts bounced? The answer was somewhere on the order of 10% "Goals" derived from Jim Browning's mail on the IRE mailing list - - ---------------------------------------------------------------- * IPv4 Internet address space is a limited resource which requires conservation and management Discussion: Suggestion that this was not a goal and that IPv6 space is also limited. Is our goal to further limit it? Suggested that the issue was not to limit, or to conserve, but rather to manage the address space. There has not been a lot of management of the IPv4 address space. The reason management is neccesary is that the resource is limited. Rewritten: - - - Because IPv4 Internet address space is a limited resource, the goal is to manage it. Suggested that we are trying to maximize utility and longevity of ipv4 space and that this group should produce guidelines and protocals by which the space can be managed. * The current address allocation policy requires subjective evaluations on the part of registry personnel. A question was asked must allocations of address space have a human-resource element? Rough consensus was yes. * There are aspects of the current address allocation that make things difficult, particularly with ISPs that are just starting out or which are growing quickly. General agreement. * Conservation of address space and slowing the growth in the size of the rout table can be conflicting goals, and priority is given to slowing the growth in the routing table General agreement. * Registries should assign routable address blocks to qualified requesters. The maximum routable prefix should be dtermined by collecting filtering policy information (as it relates to prefix size) from all requesters: Observation: The registries can not determine what is routable. It has been proposed that when orginizations submit request forms, they list the prefixes that they route from. This would allow probibility of routability to be calculated. It was noted that this will, at best, simply provide a snapshot of routability at one particular instant in time. * Mechanisms are needed to evaluate wheather allocated space is being utilized effeciantly, and reclaim unused space. Observation was made that it "would be nice" if allocations were useful, however how can registries determine if allocation is routable? Routability information is short lived and only reflects policy at time checked. While it would undoubtedly be good to collect information about routability, perhaps the allocation registries are not the best organizations to collect it. It was noted that address prefixes are not in absolute terms routable or non-routable, end result -- registries cannot determine that address space is useable. After much discussion, the rough consensus was that registries will assign address blocks to requestors. Question: Who is going to try and reclaim address space? Submitted that there is a need to provide tools to people to determine wheather they are doing efficiant utilization. Query as to whether the creation of such tools should be a goal of the working group. Comment that reclamation of address space might present a conflict of interest if non-profit orgs are being created that are leasing/selling/providing address space to downstream providers without any type of higher control or feedback mechanism to guage utilization. * Mechanisms are needed to evaluate wheather allocated space is being utilized effiecently (an acceptable percentage of allocated addresses are actually assigned to hosts) General agreement. * Mechanisms are needed to reclaim unused address space. General agreement. * Recipients of provider independent space must maintain an acceptable ratio of their number of announced prefixes to their number of registry assigned prefixes in order to obtain additional address space. Observation that such a statement need more words, particularly regarding multihoming. The ratio discussed on the IRE list was 1:1. Suggestion was made that registries should not make unenforceable limitations. Question is does the registry have to look after aggregation or not? Goal of the statement on the list was to limit the number of routable entries in the tables, not to limit address hoarding. Goals suggested as: Conservation - Have address space available Aggregation - cleaan routing table Registration - able to maintain contact all within the context of fairness (since registries should be fair accross all 3 goals). Question raised as to what the cost of each of these items is? Answer proposed as sometimes they must be traded off against each other. Fairness is suggested to be a seperate issue because it is subjective, and unable to be reduced to objective form. Question: do the registries have to be subserviant to the providers. Comments from the registry personnel is that the organizations which the registries allocate to are their customers. Suggested that part of the goal of this working group is to provide a document with goals for the registries. Address Transferability - - ----------------------- Presented by Yakov Rehkter. It was proposed that orginizations perhaps should be allowed to transfer addresses to other orginization and that this will provide further aggrigation oppertunities in the address space. To keep the discussion distinct from PIARA discussion, the approach suggested for the discussion was swaps should be allowed if registries permit it. Problem pointed out that the buyers of address space are often not ISPs, but large corporations. Comment made that if we begin selling and buying address space, the IRS will then start taxing ownership of an Internet address. Suggested that what market equilibrium will do in this case is that every group will get broken into the smallest address space that is routable. This will result in the world's ugliest router table. Filtering Information in Registration Database - - ---------------------------------------------- Proposed that it would be usefull if someone could predict the routability of an adress. General consensus, but unclear whether allocation registries should perform this function. Clearly this is a routing registry function. Address and Routing Registry Integration - - ---------------------------------------- Pointed out that the two databases have very different needs, and very different results, because one is required and the other is strictly voluntary. Suggestion on the mailing list was that the allocation registry take into account routing registry database information before making a decision. Comment that perhaps the informational service of having routing database registry integrated with address registry might be worth having. Comment that we would more likely get results if a registration for address space also included a routing registration. Comment that it would be usefull, but it is not possibile to force people to provide routing data. "We have not had good experience with voluntary registration in any database to date" Allocation Policy Modifications to Allow New Isps to Obtain More Space - - ----------------------------------------------------------------------- Suggested that a maintainence fee be charged for updating contigious space, email attempts to contact owners of address space, and if it isn't possible to contact owners of address space, records be deleted from database. Suggested that people be charged for incorrect or missing data, wheather than correct data. Pointed out that it would not be possible to charge for people that have no proper contact data. Response was to delete the record. Question as to what happens when the registries delete the entry from the database. Pointed out that if address is in route space, it will not stop being used, and will continue to function correctly. Response that the registry will contact the ISP, which will then contact the customer. Pointed out that this is a chance to encourage people to form logical aggregated CIDR blocks. Question from an ISP: "If you take away their whois record, but can't stop people from routing to them, why'd they pay up? -- If our customer doesn't pay you, we should cut them off even if they pay us?" Response: the question is is the registration database usable. If so, the ISPs must pay a role in maintaining that database. Point that the benificiaries of the cleanup are the ISPs, which gives them more access to the addresses in the pool, and also cleans up the routing table. Question as to what happens when someone tries to steal an address block. Response is that the ISPs should, and usually do check, and other ISPs "tell on them" Comment from ISP that has gotten customers that accidentally gave the wrong class C. RIDE - - ---- Proposed working group: Registry Information Database Exchange formats (see slides , David Kessens) Mailing list is ride(a)isi.edu (Majordomo) Join if wish to join the fray for a commen registry database format and exchange format Closing - - ------- IRE/PAGAN is hoped to soon be a working group, provided that there is a working group chair. The working group chair will be David Conrad, with a co-chair of Kim Hubbard Question as to what to do first, proposed answer is goals document

1 0

LIR mtg at RIPE 26 - draft agenda
by Mike Norris 08 Jan '97

08 Jan '97

Please see the following draft agenda for the meeting of the Local IR WG meeting at RIPE 26. The meeting is scheduled for some time or times on 20th and 21st Jan 1997; more specifics anon. Comments and ideas are very welcome. Cheers. Mike RIPE 26 - 20-22 January 1997 Local IR Working Group D R A F T A G E N D A 1. Preliminaries - select a minute-taker - agree agenda, times 2. RIPE 25 - minutes - actions - To publish paper on "charging by Local IR's" as a RIPE document. (RIPE NCC) - To convert slides from Local IR training courses to html format subject to finding a suitable mechanism for conversion from framemaker. (RIPE NCC) 3. Reports from registries - European regional (RIPE NCC) - NCC contributors' committee - scale of charges - effect of "resizing" - other registries, significant events, war stories - other regionals, coordination - Internic -> ARIN 4. IP Address Space Assignment - RIPE policy, ripe-140 - IEPG WG: IRE -> PAGAN - use of available Class As 5. IP Address Space Usage and Reclamation - use of Class Bs - reclamation of 192.0.0.0/8 6. Training - RIPE training courses - Local IR workshop - other training e.g. APRICOT 7. Input/Output with other Working Groups - Database - Routing - DNS - NetNews - other 8. Tools - registry administration - stats 9. Reverse domains - counts, errors - administration 10. AOB

1 0

wishes
by sam 23 Dec '96

23 Dec '96

dear collegues, To the RIPE-NCC team, the staff of Internext wishes you a mery christmas and a happy new year. We thank you for all your patience and we hope that 1997 will be a prosperous year for the Internet business. Our wishes for all the local registries . With my best regards sam

1 0

(Fwd) ISPACs
by Mike Norris 28 Nov '96

28 Nov '96

Apologies for multiple postings. Mike ------- Forwarded Message Return-Path: owner-nanog(a)merit.edu Date: Tue, 26 Nov 1996 12:49:12 -0800 (PST) Message-Id: <199611262049.MAA05750(a)chimp.jnx.com> From: Tony Li <tli(a)jnx.com> To: nanog(a)merit.edu, cidrd(a)iepg.org, metro(a)nlanr.net Subject: ISPACs Sender: owner-nanog(a)merit.edu Status: RO Folks, I'd like to point your attention to the following ID. I would appreciate any comments. For the lack of a better place, I'd ask that discussion be on the cidrd mailing list. Thanks, Tony A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Service Provider Address Coalitions (ISPACs) Author(s) : T. Li Filename : draft-li-ispac-00.txt Pages : 5 Date : 11/25/1996 ------- End of Forwarded Message

3 2

proposal for RIPE's IPv6-address space structure
by JOIN Project Team 26 Nov '96

26 Nov '96

Hello, we want to present a proposal concerning the allocation of IPv6-address space within the RIPE-region on the basis of the Internet Draft "An IPv6 Provider-Based Unicast Address Format" [1], which itself is consistent with RFC 1884 [2] and RFC 1887 [3]. The proposal is based on the following assumptions. A1. There will likely be a mixture of providers of different sizes. A2. Small providers will grow to become large providers. A3. Large providers will lose customers and become small providers. A4. Organizations which need to be multi-homed to more than one provider will request a Provider ID assignment. These four assumptions are essentially taken from [1] (see section 3.3). We add one further assumption: A5. Internet Service Providers will mainly offer their service within one country. Our proposal tries to achieve the following goals: D1. The hierarchical address structure is to simplify routing or rather to offset the growth of routing tables. (Aggregation) D2. Address space should be sufficient for a long time - in principle for ever. This leads to a conservative approach. (Conservation) D3. It should accommodate ISPs and their customers (avoid reassignments, if possible; long-term address space planning for providers). D2 and D3 are contrary in a way. We propose the following address allocation scheme: |FP+RegID| Provider ID | Subscriber ID | Intra-Sub | | | PRID | RPID | | | +--------+-------+------+---------------+-----------+ | 8 bit | 7 bit | n bit| (49 - n) | 64 bit | +--------+-------+------+---------------+-----------+ with n = 17 ! PRID (Provider Region ID) 7 bit corresponds to 128 IDs. These are mainly reserved for the countries of the 'natural', ie. European, RIPE-Region (A5). Non-European domains supported by RIPE get their own prefix (FP+RegID) in order to support a dedicated authority for these regions in the future. We should mention that we have discussed the possibility to subdivide the RIPE address space in such a way that the length of the Country-ID depends on the size (population) of that country. In such a scheme big countries could get a 5 or 6 bit long Country-ID (instead of 7 bit), resulting in a larger address space for those countries. RPID (Rest of Provider ID): In principle 56 bit are available to address providers and their customers. With n=17 there is room for 2^17 (= 131072) providers per provider region (=country). The remaining 32 bits are available to identify a customer. Hence, each provider has as many customer networks available as there are host addresses available with IPv4. If this turns out not to be enough to satisfy the needs of a very LARGE provider then, there should be the option to double the assigned address space by adjoining the neighboring address block. In order to do so RPIDs should be assigned in multiples of 16 initially, leaving the option to half the 'reserved' address space but still keeping the option to double. Given a reasonable size for an ISP within an open market this compromise should address D2 as well as D3 still leaving the option for some degenerated cases with just a single prefix. Different assumptions about the future growth and dynamics of national Internet markets might result in a different choice for n. We hope that this proposal will serve at least as input for discussion. References: [1] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., Postel, J., "An IPv6 Provider-Based Unicast Address Format", Internet Draft, March 1996. [2] Hinden, R., "IP Version6 Addressing Architecture", RFC 1884, December 1995. [3] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast Address Allocation", RFC 1887, December 1995. Best regards Frank Hoffmeister Guido Loeffler Juergen Rauschenbach Author's Addresses: Frank Hoffmeister EUnet Deutschland GmbH Phone: +49 231 972 00 Emil-Figge-Str. 80 Fax: +49 231 972 1188 D-44227 Dortmund E-Mail: Frank.Hoffmeister(a)Germany.EU.net Guido Loeffler JOIN project University of Muenster Phone: +49 251 83 8458 Einsteinstr. 60 Fax: +49 251 83 2678 D-48149 Muenster E-Mail: join(a)uni-muenster.de Juergen Rauschenbach DFN-Verein Phone: +49 30 884299 46 Pariser Str.44 Fax: +49 30 884299 70 D-10707 Berlin E-Mail: jrau(a)dfn.de

7 17

Re: proposal for RIPE's IPv6-address space structure
by Neil Harris 23 Nov '96

23 Nov '96

>Daniel Karrenberg writes: > > > > How about just using the 56 bits for local-IR+subscriber? > > The boundary does not need to be fixed at all. > > Then use a similar scheme than the present IPv4 one to determine the > > size of allocations to local IRs (provider): > > Fixed size for new local IRs and further allocations based on > > established usage rate. > > >Using only 56 bits for the IR would effectively defeat the possiblity >of using MAC / ESI addresses as the low 48 bits of an IP address. > >Pete Not to mention ESI and 1-byte selector, as is usual for ATM NSAP addressing, if we want to mix-and-match NSAP and IPv6 addresses. At Sohonet we are currently working out our NSAP addressing scheme. We have 4.5 bytes of prefix under the UK DCC scheme, and we add another nibble to define an 'escape hatch' version number for our numbering scheme, and bring it to byte alignment. We also have 6 bytes of ESI, and 1 byte of SEL, from common ATM practice. So, we now have only 20 - (4.5 + 0.5 + 6 + 1) = 8 bytes of NSAP address space left for our own internal purposes. We would very much like to have an addressing scheme where IPv6 and NSAP addresses can, at the very least, be derived algorithmically from one another. Our design criteria for our NSAP addressing scheme: > >The proposed addressing proposal should allow: > > Easy interpretation by human beings (eg byte aligned or nibble-aligned >fields) > A version field, to allow changing the numbering scheme later. > Compatibility with IPv6, if possible. > Easy NSAP filtering by _organisation_ and class of service, bearing in > mind that some filtering may only be possible by strict prefix. > Efficient routing > Support of multiple providers, multi-homing and diverse routing. > Some customer-specified numbering for internal use (???) -- Neil Harris Sohonet Limited http://www.sohonet.co.uk/

1 0