Minutes 23rd RIPE meeting _____________________________________________________________ 23rd RIPE meeting Minutes NCC staff Working Group Chairs/Scribes Amsterdam, The Netherlands January 29-31, 1996 _____________________________________________________________ ripe-m-23.txt Page 1 Minutes 23rd RIPE meeting _____________________________________________________________ AGENDA 1. Opening and Welcome 2. Adoption of the Agenda 3. Minutes 22nd RIPE meeting 4. Actions 22nd RIPE meeting 5. RIPE NCC Report 6. RIPE NCC Activity Plan - evaluation / update 7. European Netnews coordination 8. NSF: RA report 9. Address Space and Routing: Conservation vs. Aggregation 10. Working Groups Reports 11. Next RIPE meetings 12. AOB 13. Closing APPENDICES Appendix 1: List of Participants Appendix 2: Open Action Items _____________________________________________________________ ripe-m-23.txt Page 2 Minutes 23rd RIPE meeting _____________________________________________________________ 1. Opening 1.1. Welcome Rob Blokzijl welcomed the participants to the 23rd RIPE meet- ing hosted by NIKHEF in Amsterdam, The Netherlands. 1.2. Papers tabled: - Agenda for the 23rd RIPE meeting - Working Group Agendas - List of Participants of the 23rd RIPE meeting 2. Agenda The agenda was approved. Note: some of the agenda items were rescheduled during the meeting but they are minuted as origi- nally scheduled. 3. Minutes of the last meeting. The minutes of the 22nd RIPE meeting were approved with no changes. 4. Review of the action list of the last meeting The action items from the 22nd RIPE meeting minutes were reviewed. The following list comprises the ongoing action items only. All other action items were closed. Action 21.3 on Daniel Karrenberg, Mike Norris To draft a recommendation on charging by local IRs until September Action 21.9 on Erik-Jan Bos (Wilfried Woeber) To update the proposal "A Multicast Router in the Rout- ing Registry" delegation process. Action 22.12 on David Kessens To work with A. Blasco Bonito to improve the WAIS func- tionality for access to the database information on info.ripe.net. auto-assign). Action 22.16 on RIPE NCC To follow up on and implement the NOC-Object. 5. NCC REPORT Daniel Karrenberg started the NCC report, after which Mirjam Kuehne, as the new manager Registration Services, took over most of the presentation. The slides of this presentation _____________________________________________________________ ripe-m-23.txt Page 3 Minutes 23rd RIPE meeting _____________________________________________________________ provide a concise but complete overview of the report. They can be found at: ftp://ftp.ripe.net/ripe/presenatations/ ripe-m23-dfk-NCC-REPORT.ps.gz ftp://ftp.ripe.net/ripe/presenatations/ ripe-m23-mir-RS-REPORT.ps.gz Questions and remarks made following the presentation: Mike Norris expressed concern about the growing number of small registries while the number of medium and large reg- istries stayed fairly stable. He proposed that the NCC would make a suggestion to registries that they upgrade to a higher category, if this seems appropriate. The answer from Daniel was that this is indeed being done at certain points in time. Regarding the fact that the RIPE NCC will restart some tech- nical activities, Wilfried Woeber asked if and how the RIPE community should be involved in steering the direction of these activities. Daniel noted that the RIPE NCC is well in touch with the various RIPE working groups on this, and that the emphasis is currently on issues that the routing working group is dealing with. 6. RIPE NCC Activity Plan - evaluation / update Rob Blokzijl announced that it would soon be time to re- evaluate the RIPE NCC action plan, as is done every two years. He announced that an electronic mailinglist would be set up to discuss these matters. Rob urged everyone inter- ested to participate in the revision of the action plan. The creation of this new mailinglist 'ncc-review@ripe.net' would soon be announced at the 'ripe-list' mailinglist. 7. NSF: RA report Elise Gerich gave a presentation covering the activities that MERIT is currently involved with. The presentation emphasised mainly on the tools, having to do with Internet Routing, that are being developed. An overview of these can be found in the slides of the presentation, which will be available at: ftp://ftp.ripe.net/ripe/presentations/ as soon as they are received by the RIPE NCC. Elise stressed that these tools are developed for the Inter- net community as a whole and that MERIT is keen on any input that helps or steers them in the process of development. _____________________________________________________________ ripe-m-23.txt Page 4 Minutes 23rd RIPE meeting _____________________________________________________________ 8. European NetNews Coordination Willi Huber reported on the NetNews BOF that was held earlier during the meeting. The minutes of this BOF can be found after the minutes of the Working Groups. 9. Address Space: Aggregation versus Conservation Daniel Karrenberg introduced this point that was put on the agenda to create some discussion among the RIPE members, and eventually reach consensus on the way to approach the issue. The presented issue has two problems whose solutions work against each other. The first is the future runout of IPv4 address space, which causes Internet Registries to be conser- vative in handing out address space. The second is the runout of routing table space, which makes it necessary that address space is assigned in an aggregatable way. Aggregation could be improved by handing out larger blocks to Local Registries, but this goes against the goal of conservation of address space. A current issue is that at least one large Internet Service Provider threatens only to route prefixes of size /18 or shorter across its networks, in the 195.0.0.0/8 block. (This is the block that will soon be used by the RIPE NCC for allo- cating address space to its Local Registries.) This is in conflict with the RIPE NCC's allocation policy to hand out /19 prefixes to new registries. In addition, the IANA has recently stated that allocation policies from regional reg- istries should not be influenced by the policies from indi- vidual ISPs. Daniel first made clear that this /18 restriction only goes for the 195/8 block and not for the 193/8 and 194/8 blocks. After that he asked for input from the audience (the RIPE community) concerning the way the NCC should go with regard to this issue. He hinted at two possible ways to go: - ask US Sprint not to filter prefixes in the 195/8 block, based on the good track record that the European ISP commu- nity has regarding aggregation; - ask the IANA to change its policy statement regarding allo- cations from Regional Registries. The discussion that followed is partially represented below. (Havard Eidnes) We should try to reduce the number of routes in 193/8 and 194/8. Then we will have more justification to go to Sprint and ask them to change the policy for 195/8. (DK) Agreed - the question is how we achieve this. (Geert Jan de Groot) There is not much more that can be won in 193/8 and 194/8 by eliminating unnecessary route entries. If they want to reduce or even stabilise the number of routes, the ISPs should agree not to take customers that _____________________________________________________________ ripe-m-23.txt Page 5 Minutes 23rd RIPE meeting _____________________________________________________________ have their own IP numbers out of another ISP's block. The customer should be told to renumber. All ISPs should agree to do this in order for this to work. (Lars-Johan Liman) Can we set a goal (in terms of number of routes)? (Wilfried Woeber) The goal should not only include the number of routes but also where these routes are measured, since the number varies per location. (DK) The number of routes measured in Amsterdam does not vary dramatically with the rest of the world. (Peter Galbavy) We should make people see regularly who cre- ates the biggest number of routes. 'Embarrass them'. (DK) This was also done in the past. 10. Working Groups Reports The chairs from the various working groups gave reports on the working group meetings that were held earlier. The min- utes made by each working group chair/scribe follow below. At the end of each minutes, questions may be found that were asked by the RIPE23 audience following the reports. _____________________________________________________________ ripe-m-23.txt Page 6 Minutes 23rd RIPE meeting _____________________________________________________________ 10.1. European Operators Forum Chair: Peter Lothberg Scribe: Havard Eidnes 10.1.1. Welcome Peter Lothberg (PL) welcomed everyone to the meeting. 10.1.2. Agenda bashing No additions to the agenda were proposed. 10.1.3. Minute taker HE volunteered. 10.1.4. Apologies None received. 10.1.5. Previous minutes No comments were presented. The previous minutes were approved. 10.1.6. Status updates of interconnect points PL invited updates on o Status o WWW info availability Stockholm D-GIX Changes since last time: about to expand geographical coverage of the D-GIX via fiber cables provided by Stokab, providing D-GIX functionality at carrier colocate facilities. Locating equipment at KTH remains possible. Web pointer: http://www.sunet.se/dgix/ French GIX The main model is still that France Telecom owns and man- ages customer routers connected to the interconnect point. The interconnect is a shared ethernet, and FT charges 50K FFR a year for this service. A new offer is currently being provided where each ISP can rent rack space and house and manage their own router connected to the IX. Prices for this service are not yet available. The shared ethernet will be replaced by switched ether- net, possibly interconnected switches with fast ethernet (100baseT). All customer connections are for the _____________________________________________________________ ripe-m-23.txt Page 7 Minutes 23rd RIPE meeting _____________________________________________________________ immediate future foreseen to remain at 10 Mbit/s ethernet speed. Web information available from: http://www.urec.fr/Renater/gix/gix1000.html(french) and http://www.urec.fr/Renater/gix/gixangl.html(english) LINX There are now 17 connected providers. Recent activities include formalizing the organizational matters of the LINX. For 1995-1996 the fees are 5000 GBP/year plus 5000 GBP in startup fee. The LINX is currently housed in three racks housing respectively telco equipment, routers and switches. The LINX is located at Telehouse in Lon- don. Technically the LINX is implemented with two Cisco Cata- lyst switches interconnected with FDDI. Currently there is no switching of >10Mbit/s medium, they are currently looking at alternatives (FDDI or 100Mbit/s switched eth- ernet), and are wondering whether 100Mbit/s ether is a good idea. Peter Lothberg commented that "In theory, it's not a good idea", and said that the Digital GigaSwitch can throttle a sender under congestion by tem- porarily "stealing" the token, thus pushing the require- ment for buffering back at the connected router. The LINX is not to be used for providing transit service, however private "backdoor" connections can be established in the same physical facility should that be required. Web pages are available from: http://www.linx.net/ Moscow Implemented with an ethernet switch. The fee for con- necting is approx. 200 USD/month, the policy is "bring (and manage) your own box". Oslo The Norwegian Internet eXchange (NIX) in Oslo has been in operation since April 1993. It currently connects 7 dif- ferent service providers, most of them providers with Norwegian coverage of their services. The current imple- mentation is an ethernet switch. No web information is currently available. Exchange points in Munich, Portugal, Ljubljana and Prague were also briefly mentioned. Either there was no new information (the three first (?)) or the exchange point was yet to be fully established (Prague). _____________________________________________________________ ripe-m-23.txt Page 8 Minutes 23rd RIPE meeting _____________________________________________________________ Updated web pointers were solicited for those currently lacking these. 10.1.7. European issues for NANOG PL would attend NANOG in San Diego 15-16 February, and solicited input. No input appeared. 10.1.8. Filtering of prefixes (routes) As most know by now, US Sprint has imposed prefix length fil- tering in certain network blocks. Specifically, US Sprint will not admit prefixes longer than 18 bits in the address space 207.0.0.0/8 and 208.0.0.0/8. The same kind of filter- ing is set up for 195.0.0.0/8. This will soon start to impact the european service providers who are allocated address space out of this block. In particular, this con- flicts with the RIPE policy of only allocating a /19 prefix to new registries until a usage rate has been established. While routing is a slightly separate issue from allocation of address space, the obvious for a newly established service provider would be to announce his /19 block with routing, and if he has addresses in the 195.0.0.0/8 block he will not be able to communicate with customers of US Sprint. Sean Doran explained that the same limit has been set for 195 as for 207 and 208 on the grounds of consistency, and that if that should change a solid explanation has to be presented. Daniel Karrenberg suggested that as long as the number of routes in 195.0.0.0/18 remains below 1024, US Sprint should allow /19 prefixes in this block. This has the obvious prob- lem that if this target is not met, people who were earlier able to communicate with US Sprint using a /19 prefix would be blocked when the limit had to be raised to only accepting /18 and shorter prefixes. Also, the RIPE NCC cannot give any guarantees that the number of routes in this block will remain fewer than 1024, as it has no way to apply force towards the service providers. [I must admit I didn't catch any conclusion here, if there was any] 10.1.9. Renumbering Peter Lothberg did a presentation written by Yakov Rekhter on renumbering. The essence was that *some* need to renumber, and some current and near-future techniques for assisting in renumbering were mentioned: DHCP, Dynamic DNS update, Grace- ful host renumbering (interface aliases) and use of NATs (Network Address Translators), ALGs (Application-Layer Gate- ways), SOCKS (essentially IP tunnelling (?)) etc. It was also mentioned that IPv6 with the current routing _____________________________________________________________ ripe-m-23.txt Page 9 Minutes 23rd RIPE meeting _____________________________________________________________ schemes proposed has essentially the same problems as IPv4 in this area: renumbering will in some cases have to be per- formed to permit sufficient scaling of the Internet routing architecture. [Ed.: some claim that the auto-renumber hooks in IPv6 solve this problem, while other think it merely is a modest assistance in the matter.] 10.1.10. Aggregation of CIDR blocks cross-Atlantic This was merely briefly mentioned as a possibility, and that it "may be possible". [This remains to be seen, though.] 10.1.11. Internet World Fair / Internet Railroad The "Internet World Fair" is basically "like a world fair, but on the net". Anyone may put up their own "pavilion" on this exposition. To support this initiative an "Internet Railroad" network is being built. It's topology will be approximately as sketched here (sorry 'bout the ASCII graph- ics, it's all I can do with this medium, though...): Seoul------Tokyo-------Washington DC-----New York ! ! ! ! ! ! Taiwan ! ! Stockholm------Helsinki /!\ \ ! / \ \ ! / ! \ \ ! / \ \ ! / ! \ \ St.Petersburg / \ \ ! London ! \ \ Paris \ ! Amsterdam Munich ! ! Moscow The "sparsely dotted" lines are a little uncertain. All the lines will be either T3 or E3. There will be an AUP for this network, and that is that usage of the network should be "good for the Internet". There will be a number of servers scattered about on this network. Quite substantial amounts of sponsorship has been gathered for the project, among others for bandwidth and for disk space -- Quantum has donated 1TB of disk drives to the pro- ject. _____________________________________________________________ ripe-m-23.txt Page 10 Minutes 23rd RIPE meeting _____________________________________________________________ More information is available from: http://park.org/ 10.1.12. Any other business None. 10.1.13. Next meeting In conjunction with the next RIPE meeting, i.e. 22 April in Berlin. Meeting adjourned. _____________________________________________________________ ripe-m-23.txt Page 11 Minutes 23rd RIPE meeting _____________________________________________________________ 10.2. DNS Working Group Chair: Antonio-Blasco Bonito Scribe: Carol Orange 10.2.1. Scribe Carol Orange took notes. 10.2.2. Agenda The agenda was agreed to without changes. 10.2.3. DNS Working Group Chair Rob Blokzijl: o announced that the former DNS-WG chair (Leonid A. Yegoshin) had to resign due to a change in both job and residence. o invited people to suggest candidates for the DNS working group chair. Hopefully a new chair will be appointed during the next RIPE meeting. 10.2.4. Status of 'in-addr.arpa' automatic checking David Kessens gave an update on the tool he created for 'in- addr.arpa' automatic checking and delegation. His report included the following information: To use the tool, one must: o submit the appropriate RIPE database template (inetnum or domain). o send the template to . The tool will: o check the setup of the primary and secondary name servers. o if no errors are detected, forward request to human opera- tor for final approval. o report back to user. The tool will *not*: o check the relative location of servers. o check whether the corresponding address space is allocated or assigned. o check whether /24's which fall under a /16 to be delegated, have been delegated. The latest version has several software improvements includ- ing: o a standardised output transaction format. o tools for RIPE support staff to check what the tool does not check (see above). o a number of bug fixes. _____________________________________________________________ ripe-m-23.txt Page 12 Minutes 23rd RIPE meeting _____________________________________________________________ Currently under development: o a tool to automatically update RIPE NCC zone files after human approval. Plans to integrate the tool in RIPE database will mean: o requests should be submitted to database with keyword. o the RIPE database authentication mechanism will be used to validate requests. The tool is available in: ftp://ftp.ripe.net/tools/inaddrcheck-960110.tar.gz Following David's report, the following discussion ensued. Documentation about reverse delegation procedures was requested. David replied that the necessary information will be provided in ripe-104++. Whether the automated mechanisms for inverse delegations will work with IPv6 came up. There was some discussion as to whether this is important given the slow progress of IPv6. However it was also mentioned that as test beds are becoming operational, these and other tools will be needed to support them. It is expected that at most minor modifications to these mechanisms will be required for use with IPv6. Randy Bush raised the issue of data integrity of DNS, and asked whether steps are being taken to prevent corruption of the inaddr.arpa name space delegated in Europe. After some discussion on this topic, Randy said he has some tools avail- able for inspecting the integrity of DNS name space. Those interested are welcome to contact him. This was followed by a discussion of how lame delegations come into being and why they need to be cleaned up. It was pointed out that the number of bad entries in the inaddr.arpa name space will increase as renumbering goes in to effect. It was also mentioned that currently the integrity of the Euro- pean inaddr.arpa name space data is quite good. 10.2.5. Status of the BIND software Blasco Bonito announced that a the final version of Bind 4.9.3 has been released. Geert Jan de Groot recommended that nameserver functionality should be split up between recursive (non-authoritive) and authoritive nameservers. For authoritive nameservers, he rec- ommend to use the 'no recursion' option to prevent data pol- lution, and to control data sizes. Action 23.1 on Geert Jan de Groot To write up recommendations for managing nameserver con- figurations. _____________________________________________________________ ripe-m-23.txt Page 13 Minutes 23rd RIPE meeting _____________________________________________________________ Finally, Randy Bush reported that a new version of TGV is available for VMS users. Their new release contains, among much other stuff, a modern version of BIND with all the recent improvements (performance, security, etc). Folks should be strongly encouraged to upgrade. By the way, TGV was recently bought by cisco. 10.2.6. Report of problems experienced There have been some problems with the delegation of TLD names under non TLD domains. For example, someone recently delegated the name sgi.net.co.uk. The result is that sgi.com couldn't be resolved anymore when using some old resolvers. As a large number of similar names were generated, the DNS name space became severely polluted, and it took two days to clear it up. According to Geert Jan, the problem is caused in part by old bind software, which in accordance with RFC1535 should no longer be used, but in practice is. Guy Davis says that in the UK, delegation of top level domain names under TLDs (e.g. net.uk) will no longer be permitted. It was reported that this is already the case in other coun- tries (i.e. Germany, Italy, ...) and that DNS second level administrators are also discouraged from allowing top level domain names to be used. There was some discussion as to whether the problem should be solved by getting administrators to replace old resolver software or by getting them to abstain from delegating TLD names. In the end, there was consensus that the problem should be tackled as a combined effort. It was mentioned again that the security issues are discussed in RFC-1535 and that DNS administrators should be reminded to review that document carefully. 10.2.7. Report on European TLD administrator's questionnaire Guy Davis reported on a questionnaire he sent out to European TLD administrators. The questionnaire was designed to deter- mine the policies used in DNS delegations by the TLD adminis- trators. A summary of the report he presented follows. Anyone interested in the full set of information gathered can send a request to . DNS TLD - Questionnaire - 22 response for 24 top level domains - Full set of answers available on request _____________________________________________________________ ripe-m-23.txt Page 14 Minutes 23rd RIPE meeting _____________________________________________________________ email: guyd@pipex.net EDITED HIGHLIGHTS 1. Who defines your policies? Org Running TLD - 15 1/2 The Government - 1 1/2 ISPs by consensus - 4 2. How do you establish your policies? By Working Group - 2 Told by Govt. - 1 1/2 Decided by Org Running TLD - 7 1/2 ISPs by Concensus - 10 3. What Legal Status do your decisions/policies have? None - 19 1/2 As defined by Govt. - 1 1/2 4a Public Subdomains? Yes - 7 No - 15 b Geographic Subdomains? Yes - 6 No - 16 c 2nd level categories (private & public) in parallel? Yes - 6 No - 16 d If you have public subdomains must everybody's request be accepted? Yes - 7 N/A - 15 e How would you split your TLD See full listing - 6 N/A - 16 5a Sub. TLD? Yes - 20 No -2 b Sub. public TLD? Yes - 7 No - 15 6a Who can obtain domains? Anyone - 11 Just Orgs - 11 8 Must the requester be local? Yes - 16 _____________________________________________________________ ripe-m-23.txt Page 15 Minutes 23rd RIPE meeting _____________________________________________________________ No - 6 9a More than one domain per Org. ? Yes - 12 No - 10 17a Do you charge ? Yes - 5 No - 16 19 Are you likely to change the system within 12 months? Yes - 14 No - 5 Don't know - 3 22 Do you use automation? Yes - 11 No - 11 After Guy's presentation of the above data, a discussion started regarding the charging fees and schedules. Most TLD administrators presently don't charge, but are thinking about doing so to cover their costs. Among those who do charge, some have only a one time fee, and some have a yearly admin- istration fee. There does not appear to be competition among the national TLD administrators. Moreover, running a TLD is primarily per- formed as a non-profit service to the Internet community. Blasco suggested a need for better coordination among TLD administrators, so they can consult one another on technical and policy matters. It was pointed out that this does not mean they will all follow the same policy. The question was raised as to whether some private forum for communication among TLD administrators should be created, so they can exchange information easily. Whether or not 2nd level domain administrators might be included in the "private" communication was considered. Action 23.2 on RIPE NCC To set up a mailing list for TLD administrators. A need was also expressed that the policies of TLD adminis- trators be made public. Action 23.3 on RIPE NCC To incorporate a page where TLD policies can be pub- lished at its WWW site. It was suggested the questionnaire be repeated in 6 months so that changes in policy can be monitored. _____________________________________________________________ ripe-m-23.txt Page 16 Minutes 23rd RIPE meeting _____________________________________________________________ 10.2.8. Delegation of International TLDs (Randy Bush) Randy Bush explained that there is a lot of talk in the US at the moment about whether and why new TLDs should be created. International TLDs are com, org & net. The main reason for expanding these is to create healthy competition in the mar- ket. Also, the US government (NSF here) wants to be out of the IP and DNS delegation business. Randy also presented a set of guidelines that should be used in determining whether a new TLD can be created. There was some discussion as to whether or not names should be used for profit. Also, whether a white pages service (which is what DNS provides) is sufficient, or whether we should start looking into yellow page models for directory services. Back to the name space: it is perceived that the US wants to control the name space. Who gave them the right to edu, mil, and gov? Basically, it was stated that the US came up with those names, so they have a right to them. Still the process remains unclear. Piet Beertema said the US should use the extension "us" just as other countries use country extensions. Randy then summarised the proposal they are submitting to slowly expand the number of TLDs. The number of TLDs would be increased at a rate of about 3-5 per year. Basically, anyone suggesting a new domain should argue that it will serve some purpose that none of the currently existing TLDs do, and agree that it will be managed responsibly following the guidelines agreed to in RFC1591 (as well as some new ones: non-discrimination policies, appeals procedures, etc.). Piet B. pointed out that those changes only generate a false sense of order in the chaos. The new policies only apply to new TLDs, not to the old ones. No similar restrictions are applied to second level domain administrators. Mike Norris pointed out that DNS administration is experi- enced as a public service in Europe. Randy said that "com" on the other hand is turning into a high profit monopoly, and the new suggestions are intended to curb its power. A discussion surrounding the trademark wars surrounding domain names started up. Should the names be delegated on a "first come, first served" or should DNS administrators be required to control trademarks. Back to the issue as to whether new TLDs should be created: _____________________________________________________________ ripe-m-23.txt Page 17 Minutes 23rd RIPE meeting _____________________________________________________________ It was suggested that whereas the US TLDs fall under ".", they should be placed under "us" (e.g. com.us, mil.us, edu.us, etc). In other words, the problems surrounding "name for profit" monopolies are US based, and should be solved there. To clarify this, Randy asked the audience whether they should be removed from the root. There was general consensus about that. That was about it for the DNS working group. _____________________________________________________________ ripe-m-23.txt Page 18 Minutes 23rd RIPE meeting _____________________________________________________________ 10.3. MBONE Working group Chair: Magnus Danielson (KTH/IT) Scribe: Kurt Kayser (ECRC) 10.3.1. Opening 10.3.1.1. Welcome Magnus Danielson, Chair of the MBone WG welcomed everybody. 10.3.1.2. Apologies No apologies were received 10.3.1.3. Minute taker Kurt Kayser volunteered for the scribe of the meeting minutes 10.3.1.4. Outstanding action items 21.9 no progress yet, will be done (did nowhere find a list of current action items... maybe we should publish them on the web, or on the ftp-server?) 10.3.2. The Mbone topology in Europe (and the US) 10.3.2.1. Strategy for intradomain topology management Magnus recommended that all mrouter administrators should enable the unicast reachability due to problem isolation and troubleshooting issues. It helps a lot to create statistics and provide answers to connections that are currently down or unreachable hosts. Existing M-tools (like mstat, mrinfo, mtrace and others) pro- vide an easy mechanism to show the current status of tunnels, utilization and errors. There are 2 relatively new tools which are called mconfig and mview which provide a GUI interface for the mrouted's config- uration file (/etc/mrouted.conf) and shows also an overview of the configured VIFs and their addresses plus actual sta- tus. Magnus promised to publish the sources and pointers to the FTP-Servers on the mailing-list. Action 23.4 on Magnus Danielson To publish the sources of mconfig and mview and send pointers to the sources to the mailinglist. _____________________________________________________________ ripe-m-23.txt Page 19 Minutes 23rd RIPE meeting _____________________________________________________________ 10.3.2.2. Software versions and global optimation The 'cleanup raid' DVMRP contains some RIP code which causes some scalability problems with the current expansion of the Internet/Mbone. The algorithms used in DVMRP are hard to debug and on heavily loaded lines sometimes instable. Magnus asked if someone had heard of the "cleanup-raid" before. Nobody had. He explained that it is an effort to 'cleanup' the different versions of mrouted and already deployed Cisco PIM code that is currently not supported any- more or even outdated and harms the functionality of the international Mbone. These versions are mrouteds before 3.5 and Cisco IOS Versions 10.2 and 10.3 because of pruning prob- lems and incorrect routing-table behaviour. Magnus showed a comparison of European countries and their percentages of different versions currently in use. Version hosts percent -------- ----- ------- 3.8PGM 160 38.5% 11.0PM 38 9.1% 3.8PGMS 14 3.4% 11.0PMS 11 2.6% 11.1PMS 4 1.0% -------- ----- ------- 54.6% so far 3.6PGM 42 10.1% 11.0Mpim 13 3.1% 10.3pim 12 2.9% 10.2pim 6 1.4% -------- ----- ------- 72.1% so far 3.3 27 6.5% 3.4 21 5.0% 2.2 20 4.8% 3.2 15 3.6% 10.3 8 1.9% 10.2 8 1.9% 3.1 7 1.7% 3.5PGM 6 1.4% 3.7PGM 2 0.5% 2.0 2 0.5% -------- ----- ------- Total 416 League Table for Europe Domain Hosts Score New OK Old ru 3 100.0 100.0% 0.0% 0.0% pl 5 80.0 60.0% 40.0% 0.0% no 28 76.8 67.9% 17.9% 14.3% _____________________________________________________________ ripe-m-23.txt Page 20 Minutes 23rd RIPE meeting _____________________________________________________________ de 104 73.6 64.4% 18.3% 17.3% fi 45 72.2 64.4% 15.6% 20.0% se 46 69.6 56.5% 26.1% 17.4% uk 85 63.5 58.8% 9.4% 31.8% EU 416 63.3 54.6% 17.5% 27.9% be 4 62.5 50.0% 25.0% 25.0% it 18 58.3 50.0% 16.7% 33.3% si 2 50.0 0.0% 100.0% 0.0% pt 2 50.0 50.0% 0.0% 50.0% cz 10 45.0 10.0% 70.0% 20.0% es 6 41.7 16.7% 50.0% 33.3% nl 14 35.7 35.7% 0.0% 64.3% fr 35 34.3 28.6% 11.4% 60.0% at 5 20.0 20.0% 0.0% 80.0% su 3 0.0 0.0% 0.0% 100.0% A comparison with the US shows clearly that the version num- bers in Europe are quite higher than in the US. World Table of Mrouted/IOS versions Version hosts percent -------- ----- ------- 3.8PGM 479 28.3% 11.0PM 120 7.1% 11.0PMS 31 1.8% 3.8PGMS 25 1.5% 11.1PMS 16 0.9% 11.1PM 9 0.5% -------- ----- ------- 40.2% so far 10.3pim 171 10.1% 3.6PGM 161 9.5% 10.2pim 46 2.7% 11.0Mpim 45 2.7% -------- ----- ------- 65.2% so far 2.2 148 8.7% 3.3 83 4.9% 3.4 83 4.9% 10.3 78 4.6% 2.0 54 3.2% 10.2 49 2.9% 3.5PGM 21 1.2% 1.0 20 1.2% 3.2 18 1.1% 3.7PGM 18 1.1% 3.1 9 0.5% OLD 5 0.3% 11.0M 4 0.2% -------- ----- ------- Total 1693 League Table for Europe _____________________________________________________________ ripe-m-23.txt Page 21 Minutes 23rd RIPE meeting _____________________________________________________________ Domain Hosts Score New OK Old EU 416 63.3 54.6% 17.5% 27.9% World 1693 52.7 40.2% 25.0% 34.8% World-EU 1277 49.2 35.5% 27.4% 37.1% 10.3.2.3. Maps - A constant concern. Why are they needed? Still under development by Magnus and Kurt Kayser. Magnus explained his way of notation of a tunnel description: met- ric/threshold/bandwidth It is a convention that should be kept by other European metric or topology changes as well. It is suggested that all changes are forwarded to WG so that we can keep track of the current topology. Maps are currently collected and evaluated. Magnus is also working on integrating online information elements into a postscript map that printout could reflect the current status of the European Mbone connectivity. 10.3.2.4. Link description list/map A question was how other countries or institutions (US or NASA i.e.) keep track of their connectivity and topology integrity. Action item could be to contact other Mbone admin- istrators to get this info?! Maps should also show a link description with speed and met- ric values for both ends. 10.3.3. Various Issues 10.3.3.1. Presentation of the TF-ATM/MICE test network results Victor Reijs gave a presentation of the experiences that were gathered during usage of the Pan-European ATM test network in conjunction with MBone applications. (include some slides or excerpts?) URL to the Terena Server where the project was homed is: http://www.terena.com/ 10.3.3.2. MBone EU FAQ and web pages - call for more info The EU-Mbone-FAQ was moved to: http://www.it.kth.se/~e93_mda/mbone/ripewg/eufaq.html Action 23.5 on RIPE NCC To include a pointer to the EU-Mbone-FAQ in the RIPE WWW-server. 10.3.4. Free forum _____________________________________________________________ ripe-m-23.txt Page 22 Minutes 23rd RIPE meeting _____________________________________________________________ 10.3.5. Closing 10.3.5.1. Summary of new actions 10.3.5.2. Thanks Thanks to Victor Reijs for his presentation and Kurt Kayser for scribe. _____________________________________________________________ ripe-m-23.txt Page 23 Minutes 23rd RIPE meeting _____________________________________________________________ 10.4. Local IR working group Chair: Mike Norris Scribe: Anne Lord At the working group meeting there were 111 attenders. 10.4.1. Preliminaries A scribe was volunteered :) and the agenda which was previ- ously circulated to the Local IR mailing list was agreed with some modifications to the order of the discussion. The min- utes will reflect the order in which items appeared on the agenda. 10.4.2. RIPE 22 10.4.2.1. Minutes The minutes of the 22nd RIPE meeting had been circulated shortly after that meeting to the Local IR mailing list for comment and minor corrections were made to the text. The minutes were then accepted. 10.4.2.2. Review of actions Action 21.3 on Daniel Karrenberg, Mike Norris To draft a recommendation on charging by local IRs until September. Action is still open. A first outline had been written but needed further study and elaboration before a draft would be sent to the list. Action 22.1 on Mike Norris and RIPE NCC To find volunteers from the Local IR working group to continue working on the revision of ripe-104++ without waiting for the publication of rfc1466++. This action was closed. In addition to the RIPE NCC, the mem- bers of the editorial committee were: Mike Norris Wilfried Woeber Sabine Dolderer Hans Petter Holen Holger Weinhardt Janos Zsako 10.4.3. Reports from registries 10.4.3.1. European Regional Registry (RIPE NCC) As the formal report from the European IR was presented in the RIPE meeting plenary, the report to the working group was _____________________________________________________________ ripe-m-23.txt Page 24 Minutes 23rd RIPE meeting _____________________________________________________________ brief. The shortened report was as follows: o there are now 308 local IR`s. o the predictions for the workload for 1995 were accurate. o new staff are now fully trained. o the "wait" queue is now empty ("wait" queue is non-assigned requests). o approximately one new registry per working day is now being signed up. 10.4.3.2. Other Registries There were no comments from other local registries. It was suggested that this might be a good opportunity to organise a local IR workshop in conjunction with the next meeting. There was consensus within the group that this should not be organised in parallel with the EOF meeting. An action item was taken on by the RIPE NCC. Action 23.6 on RIPE NCC To organise a Local IR workshop in conjunction with RIPE24. 10.4.4. Registry Procedures 10.4.4.1. European registries - ripe-104++ The draft document "European Internet Registry, Policies and Procedures" (ftp://ftp.ripe.net/ripe/drafts/ripe-104++.{txt,ps}) was pre- viously circulated to the Local IR mailing list for comment. There has been and still was considerable discussion on the mailing list. Within the working group the aim was to isolate the salient points and to resolve any differences of opinion so that consensus could be agreed and the document pro- gressed. The following points were discussed: Assignment procedures VSEs - It was commented that the assignment procedures are too complicated for VSEs. The common situation being one or two externally facing hosts and the rest behind a fire- wall. It was suggested that the end customer does not necessarily have to complete a network number applica- tion form in such cases, but the information might be collected by the Local IR. The important point is how- ever, that the information is archived. PI/PA address space issues _____________________________________________________________ ripe-m-23.txt Page 25 Minutes 23rd RIPE meeting _____________________________________________________________ - There was a discussion about PA (Provider Aggregatable) and PI (Provider Independent) address space. If your customer insists, PI address space can be allocated. Local IRs can apply on a per case basis for PI address space from the EU IR or they can apply for a PI block. As specified in ripe-127, there will be no guarantees over the routability of such blocks assigned and using such address space is *strongly* discouraged. - It was also suggested that ripe-104++ could include a sentence to strongly recommend that ISPs/Local IRs should *not* accept PA address space from new customers which is outside their own CIDR address space. This was agreed. - There was a question about the existing allocation reg- istration information in the RIPE database. It was agreed that unless a contractual arrangement existed with the customer, assignments in the RIPE database without the "status" attribute marked as PA are consid- ered PI (Provider Independent). If local IRs can make such contractual arrangements retrospectively, then such allocations can be considered PA and marked as such. Agreed. - Assignments of address space are only valid as long as the assignment criteria under which the original addresses were allocated are still true. Agreed. - It was suggested that the assignment messages from the RIPE NCC could be made clearer to reflect the signifi- cance of the PA assigned address space. Renumbering - There was some discussion around the procedures for renumbering. It was agreed, that this would be encour- aged by making the procedures as easy as possible for those who had agreed to renumber and words to the effect that the size of the previous assignment would not be questioned unless the efficiency was extremely low. Reservations Policy - It was agreed to base assignments on a 2 year plan from the requester. No reservations policy was endorsed. Static assignments for dial up - The document strongly discourages the use of static IP assignments for dial up service. Strongly discourages means that if a strong technical reason is given and accepted, then assignments will be made for a vastly shortened time scale - 3 months was mentioned. _____________________________________________________________ ripe-m-23.txt Page 26 Minutes 23rd RIPE meeting _____________________________________________________________ Assignment window anomaly - The largest current assignment window for any local IR is /19 -1. This refers to the amount of address space that they can assign without referring first to the RIPE NCC. The proposal in ripe-104++ was to reduce this to /20. After some discussion and by way of compromise, it was agreed to make the new maximum /19 rather than /20. However, for every local IR with a /19 -1 assignment window, the current value of it's assignment window will be set to /20, with the understanding that it can be increased to a /19 based on the usual criteria (as spec- ified in ripe-104++). It was agreed that this would come into effect immediately after the meeting. Work remaining on ripe-104++ Sections 5,6,7 and 8 remain to be drafted. Section 5 will be drafted shortly after the RIPE meeting when the editorial committee meet and the draft will be circulated to the list shortly after the meeting. 10.4.5. Registry services and charges 10.4.5.1. RIPE NCC charging model The contributors committee had agreed on a charging model for 1996. All documents relating to the Contributors Committee meetings and revenue and expenditure documents can be found in: ftp://ftp.ripe.net/ripe/new-registry/ncc-co/ 10.4.5.2. Charging by local IRs As reported under item 2.2 a draft outline had been prepared. The reviewed document will be circulated to the mailing list after the RIPE meeting, once it has been reviewed and edited. The main emphasis of the document is that it is acceptable practice for Local IRs to charge for their services. There will probably also be some wording included to the effect that any remaining Last Resort Registries should not charge for profit. 10.4.6. Tools All Local IRs were encouraged to make any tools developed for local use available to the wider community if they thought that they could be useful to others. The RIPE NCC offered to "house" these tools and make their location visible. 10.4.7. Input from other Working Groups _____________________________________________________________ ripe-m-23.txt Page 27 Minutes 23rd RIPE meeting _____________________________________________________________ 10.4.7.1. DNS Ripe-105 will be incorporated into ripe-104++. 10.4.7.2. Database A proposal was made to the Database WG mailing list to incor- porate the functionality of into the general database update procedure. In future, it was pro- posed that in-addr updates could be sent to with a special tag which could be something like "INADDRREQUEST". 10.4.8. AOB 10.4.8.1. Reverse delegation for partially assigned class B networks There was a question about in-addr.arpa delegations for assigned portions of class B address space. It was suggested that either you could ask the Internic to delegate 128 zones to the Local IR or to channel this request through the RIPE NCC. It was suggested that it might be useful to include a reference to this in ripe-104++. Action 23.7 on RIPE NCC To include a paragraph in rpe-104++ on procedures for the reverse delegation of partially assigned class B networks. 10.4.8.2. Handing back of networks from block 192.0.0.0/8 In a mail of the PIER working group it was proposed that by 1997 users of non-aggregatable 192 address space should con- sider renumbering. There was a question concerning where 192 address space should be returned to. It was suggested to return it to the RIPE NCC in all cases, and the RIPE NCC will handle it as appropriate. Any queries can be sent to the RIPE NCC . _____________________________________________________________ ripe-m-23.txt Page 28 Minutes 23rd RIPE meeting _____________________________________________________________ 10.5. Database Working Group Chair: Wilfried Woeber Scribe: Kurt Kayser 10.5.1. Administrative stuff Kurt Kayser, ECRC, volunteered to take notes. The WG meeting was split into two sessions - part 1 to deal with current topic, problems and ideas - part 2 the more traditional stuff The proposed WG-agenda was accepted. 10.5.2. Databases and registries B. Manning's review of the 192.0.0.0/8 address range prompted a brief discussion of where the authoritative information should be maintained. The general feeling was that networks used in Europe should be documented in the RIPE-DB. [ A comment was received after the WG-meeting to ask the Internic (and other registries?) to expand the standard referral text ("The InterNIC Registration Services Host contains...") to include pointers to the RIPE-DB and maybe other registry sources. ] From the user's point of view it would be very convenient to send updates to a "local" database and have the software for- ward the message(s) to the appropriate database(s) according to the source: attribute. Currently the RIPE-NCC holds copies of the following databases: RA, MCI, APNIC, CA*Net - but NOT the InterNIC. While things are to improve with the introduction of the shadow-dbs, mirror copies are always sort of out-dated by definition. RIPE intends to have a 10min delay. Other problems identified: - uniqueness of names / keys across different databases - lookup and processing of entries from more than one DB (e.g. evaluate AS-Macros from different DB...) -> minority problem for the time being. - quality control on information, o like duplicate entries alert, o automatic handle assignment, _____________________________________________________________ ripe-m-23.txt Page 29 Minutes 23rd RIPE meeting _____________________________________________________________ o semantics for more than one person object for a given individual o Registry ID information is maintained manually, this might change by building links to objects in the pub- lic database. 10.5.3. User interface(s) - access to the data in a more clever (selective) way by WAIS and/or WWW. A. Blasco Bonito and Paolo Bevilacqua have a test-version available for a WWW interface that supports logical AND and OR of keys. - whois "help" gives on-line documentation hypertext ver- sion being considered - An on-line survey form is available via the RIPE-NCC web pages, you are invited to use it to describe your wishes for access to data kept at the RIPE-NCC. - RADB/Merit has a web interface for queries and updates, although this obviously works for auth: NONE or MAIL- FROM only - proposal: put a pointer to whois "help" into ripe-104++ 10.5.4. Authorization and Security DFK reports that development work is on the action list (PGP facilities to be integrated) but there is still a severe lack of resources. Additional help is needed to make real progress, because design work is necessary first. The Key management would most probably be done according to the Merit approach. We might benefit from (Euro-)CERT activities? In more general terms, if we want to see development progress faster than in the past, then we have to come up with clearly defined needs and a proposal for a development project with additional resources. 10.5.5. DB-SW report David Kessens offered the traditional database software report. The slides can be obtained from: ftp://ftp.ripe.net/ripe/presentations/ ripe-m23-david-DB-REPORT.ps.gz Another set of slides for the In-Addr-Check handling is available from ftp://ftp.ripe.net/ripe/presentations/ ripe-m23-david-DNS-INADDRCHECK.ps.gz _____________________________________________________________ ripe-m-23.txt Page 30 Minutes 23rd RIPE meeting _____________________________________________________________ - beta version V1.1 that allows (close to) real-time mir- roring is available. At the time of writing these min- utes (4-MAR-1996) the distribution is at: ftp://ftp.ripe.net/ripe/dbase/software/ ripe-dbase-1.1beta2.tar.gz - requests to run a mirror copy are to be sent to ripe- dbm@ripe.net - other changes include o support for the BSD DB package o a password controlled mechanism to overrule normal security mechanisms (e.g. for adding maintainers and the like) o "network updates" are now fully supported by the RIPE- DB SW. Fully supported means: "If your address is in the RIPE-DB access list" However, this is a very pow- erful method and currently does not provide enough data for the logs to track down problems. For further study, before being made available to the community at large. o less memory consumption In conjunction with the mirror capability, the software has to keep track of individual object creations and updates. The mechanism that is currently used is not suitable for long- term consistency (because the sequentially increasing values are expected to suffer from wrap-around, eventually). Thus a stored: attribute was proposed and accepted. stored: