Please see the below re the above, as discussed at at the LIR WG mtg on Monday. Mike --------------------------------------8<---------------------------- Message-Id: <199701020201.LAA08209@moonsky.jp.apnic.net> To: pagan@apnic.net Subject: IRE->PAGAN Minutes Date: Thu, 02 Jan 1997 11:01:19 +0900 From: "David R. Conrad" <davidc@apnic.net> Sender: owner-pagan@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@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@eni.net, modified by davidc@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@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@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@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