RIPE NCC Quarterly Report Issue 2 October 1992 Document-ID: ripe-73 1. Introduction RIPE (Reseaux IP Europeens) is a collaborative organisation open to all European Internet service providers. The objec- tive of RIPE is to ensure the necessary administrative and technical coordination to allow the operation of a pan- European IP network. RIPE does not operate a network of its own. RIPE has been functioning since 1989. Currently more than 60 organisations participate in the work. The result of the RIPE coordination effort is that the individual end-user is presented on their desktop with a uniform IP service irrespective of the particular network his or her worksta- tion is attached to. In September 1992 more than 230,000 hosts throughout Europe are reachable via networks coordi- nated by RIPE. The total number of systems reachable world- wide is estimated at more than one million. The RIPE Network Coordination Centre (RIPE NCC) is a Euro- pean organisation chartered to support all those RIPE activities which cannot be effectively performed by volunteers from the participating organisations. As such, it provides a wide range of technical and administrative sup- port to network operators in the Internet community across Europe. The charter of the NCC is formally described in the NCC Activity Plan (document ripe-35 in the RIPE document store). The RIPE NCC currently has 3 permanent staff members. The RARE association provides the formal framework for the NCC. Funding for the first year of operation of the NCC is provided by EARN, the national members of RARE, Israel and EUnet. This is the second quarterly report produced by the RIPE NCC. As before, comments and suggestions are very welcome. - 2 - Important Note on Statistics This report has been finalised one week before the end of the reporting period so it can be presented at the 13th RIPE meeting on September 30th. Please note that the statistics in this report are exclusive of the final week of the reporting period. The arrangement of categories including country codes in some statistical tables and figures have been standardised to make the data more easily comparable between different tables and editions of these reports. As a consequence some categories appear with no data and/or seemingly nonsensical combinations. In the PostScript version of this document much information is presented both in graphical and in table form. This apparent duplication is necessary because the graphics cannot be represented in the ASCII version of the document which has to contain the same information as the PostScript version. - 3 - 2. Management Summary Delegated Internet Registry By far the most important development during the reporting period has been the full scale introduction of the delegated internet registry function of the NCC. From scratch 36 local registries were identified throughout Europe and suc- cessfully started operations in the midst of the holiday season. Because of the quick start-up needed not all pro- cedures have been fully optimised yet but nonetheless almost 1000 class C and 50 class B network numbers have been assigned using quickly developed procedures. The typical response times achieved so far are quite encouraging. The procedures will be refined further in cooperation with the local registries during the next quarter. The start-up of this whole activity has taken slightly more NCC resources than anticipated, thus delaying other activities tem- porarily. In conjunction with this, the latest Internet draft concern- ing IP address space management and address assignment pro- cedures should be carefully evaluated by RIPE; and RIPE should provide input to the appropriate Internet bodies on these issues. RIPE Database Major revision work on the database software has been car- ried out, all of which is being used in production as of this writing. Usage of the database has increased consider- ably. The envisaged thorough consistency checking and meas- ures to increase database coverage in some low coverage regions have not been started yet because of time con- straints. This is expected to start during next quarter. Priorities Besides the Internet Registry start-up the NCC has concen- trated on continuity of the core services during the report- ing period. There have not been sufficient resources to start any activities which had not been tackled previously. As this will hopefully change in the next quarter, RIPE should provide the NCC with explicit guidance as to the relative priority of hitherto untackled activities in the activity plan. - 4 - 3. Activities The NCC aims to provide a service which is both responsive and efficient, whilst providing a known, accessible focus for the gathering and dissemination of information across the European Internet community. To this end, the NCC has in its second quarter of operation, the following activities to report. 3.1. DNS Coordination As reported in the first quarterly report, the NCC is now responsible for the RIPE DNS hostcount. All hosts listed in the RIPE part of the DNS (the Internet Directory) are counted. The hostcount is currently gathered once per month and distributed via the RIPE mailing list.In addition the DNS output which is used to produce the hostcount, is archived in the RIPE document store. Also archived in the document store is the graph below showing the growth of the IP network in Europe, in terms of DNS registered hosts. The following table gives a historical view of the number of hosts counted: 1990 Oct 26141 Nov 33665 Dec 29226 1991 Jan 43799 Feb 44000 Mar 44506 Apr 46948 May 52000 Jun 63267 Jul 67000 Aug 73069 Sep 92834 Oct 104828 Nov 129652 Dec 133000 1992 Jan 141308 Feb 161431 Mar 167931 Apr 170000 May 182528 Jun 196758 Jul 213017 Aug 221951 Sep 232522 - 5 - 3.2. Internet Registry Delegated Registry The administrative arrangements for the allocation of Inter- net (IP) numbers has been revised further. At the end of July the Internet Registry (IR, a.k.a hostmaster@nic.ddn.mil) requested that the RIPE NCC handle all IP network number applications from European organisa- tions. We complied with the request even though there had been no time to get all the necessary procedures fully esta- blished. The main rationale for this step was to off-load the IR and improve response times for European organisations as early as possible. From August 1st 1992, all requests received by the Internet Registry from European organisa- tions were forwarded to the RIPE NCC. This included both e-mail and letter applications. Initial Procedure Initially, in response to each query, the NCC sent a letter to applicants which advised them of all recent changes with regard to Internet number assignments (see "Appendix E" on page 28 for a copy of the letter) Specifically, the letter advised organisations that it is beneficial to them if they obtain their IP numbers from their current or prospective IP service provider. The letter also contains a template to fill in and send back to the NCC in case a service provider has not yet been identified. In order to make this work the NCC made an effort to locate as many service providers as possible and to delegate blocks of class C network numbers to them for reassignment. At the same time, country NICs were asked to identify themselves as organisations to whom the NCC could further delegate the allocation of class C IP numbers to organisations without an IP service provider. Considering that this happened in the middle of the European holiday season the response was very good both from the providers and from organisations willing to act as country NICs. To date 30 different service pro- vider registries and 6 country NICs for organisations without service provider have been identified and allocated class C network numbers to redistribute. The allocation of class B networks is done from the NCC. No new class B blocks will be allocated to local registries. Some local registries still have (sometimes quite large) blocks of class B numbers. The total extent of this is presently unknown as we do not know which European organisa- tions hold such blocks. - 6 - Current Procedure Once the country NICs were identified, we changed the pro- cedure slightly by forwarding all requests from that country which did not identify a service provider to the country NIC. While this takes some load off the NCC and provides local language service it turns out not to be without draw- backs: particularly the applicant will be in contact with up to 4 registries in sequence if he first applies to the IR which still happens very frequently and finally gets his number allocated from a service provider: IR -> NCC -> coun- try NIC -> provider. In order to eliminate the first step of this chain the IR has made the NCC template available in their information server and included a pointer to it in the standard Internet number registration template. This measure will need some time to take effect, because many copies of the original template are still in circulation. Future Procedure To further simplify this procedure we propose to use a com- mon registration template in Europe. The applicants will then be able to fill in one form accepted by all European registries independently of which registry will ultimately assign network numbers to them. This maximises the chance that the applicants will fill out the right form to start with and simplifies forwarding of requests between regis- tries. We urge RIPE to establish consensus about this as quickly as possible. NCC Workload and Performance In order to quantify the workload generated at the NCC and to monitor the service quality, the NCC has kept a log of actions related to the delegated registry function. Since log-keeping did not start right away at the beginning of August, the numbers below are a lower bound for the report- ing period. A total of 172 requests were logged; 100 were received from the IR, 59 directly and 13 via local NICs. Generally more than 50% of the requests are received via paper mail and more than 50% of the information sent out by the NCC is via FAX because the applicants are not reachable by e-mail. E-mail accounts for only 25% of incoming and out- going registry transactions. This generates a lot of cleri- cal overhead as paper has to be filed, generated and posted or faxed. In order to reduce this overhead we are currently evaluating FAX software which enables NCC staff to send and file outgoing FAX messages from within their e- mail environment. 63.4% of all requests were answered (not only acknowledged) on the day they were received, 14% on the next. 89% of all - 7 - requests were completed within 5 days. It took an average 1.96 days to allocate (a block of) class C networks from the NCC and on average 24 days to allocate a class B network. The latter average is so high because there were a few cases where it took the applicants several weeks to provide the necessary information to evaluate the request. The typical allocation time for a class B network, once the necessary information is complete, is around 2 working days. These allocation response times apply only to allocations made directly by the NCC and not those by local registries. Address space usage During the reporting period the NCC assigned 50 class B net- work numbers, delegated 55 blocks of class C network numbers and reserved 97 blocks of class C network numbers. The assignment and reservation of class C blocks was done in accordance with the CIDR scheme to allow route aggregation in the future. It should be noted that blocks are reserved based on usage estimates given by the local registries for a period of about 24 months. Should the assignment rate differ from the estimated one, reserved blocks can and will be used for other purposes if necessary. During the reporting period the European registries have assigned a total of 940 class C networks to bring the total of networks assigned from blocks delegated by the NCC to 1098. About two thirds of the allocations has been made from blocks allocated to registries of service providers. The detailed status of the address space delegated to the RIPE NCC can be found in "Appendix B" on page 22 and "Appen- dix C" on page 23 for class B and class C network numbers respectively. 3.3. RIPE Network Management Database Revision of the Database Support Software A major revision of the database indexing and whois server software has been completed. The software now fully supports the new database objects routing privilege and boundary gateway.The whois server was extended with additional heuristics to speed up searches and extensive logging features. Also blocks of networks are now fully supported. The indexing software was extended to enhance generality with respect to the NIC and NSFnet databases. We have recently received contributions from the DE-NIC in this area which will be incorporated during the next reporting period. There is also now a very general distribution feature which makes it possible to send out database files to multiple subscribers automatically when they have changed. This - 8 - enables local registries and future database secondary server sites to have the files sent to them rather than hav- ing to poll the NCC server for possible changes. A total revision of the software to support database updates has been completed. This new software is much more easily configurable than the previous ad-hoc version. The extensive configuration file allows for easy addition of new database objects and their attributes. This enables local registries to quickly adapt the software to local database extensions. All error messages and mail messages generated by the con- sistency checking scripts are now configurable without changing the software itself. This allows for easy modifica- tions to make messages more clear or even to create local language versions if desired. The update function now sends individual acknowledgements messages to each person who sent in an update rather than just one message to everyone. These messages contain all objects which caused error or warning messages.We plan to adapt all parts of the database support software package to use the configuration file at the time they undergo extensive revision. The update software package is currently under beta test at four sites. It is expected to be released in October. New WHOIS Client Software A RIPE version of the Unix whois client has been completed and is available from the NCC now (ftp.ripe.net:tools/ripe- whois.tar.Z). This client will query the RIPE database by default rather than the US NIC database. Of course the US database can still be selected using the -h flag All options provided by the RIPE WHOIS server can be accessed from this client without unnecessary quoting of arguments. The client is also prepared to find a local WHOIS server once secondary servers for the RIPE database have been established. Database Statistics The development of the number of database objects since November 1990 is shown in the graph and table below: This shows that the increase in the number of domain objects is relatively low. The main reason for this is that there is no direct incentive to register in the RIPE database in addition to the DNS. The rationale for the domain object in the RIPE database was that certain information like an organisation's full name and contact person's phone number could not be included in the DNS. Since RFC1183 specifies how to code contact information for domains in the DNS, the RIPE DNS working group should review the usefulness of this object. - 9 - Month Nets Persons Domains _________________________________ Nov 90 643 670 0 Jun 91 1270 1053 845 Jan 92 2728 1792 1254 Apr 92 3365 2242 1360 Jun 92 3797 2736 1422 Sep 92 4172 4594 1549 We are not able to fully explain the relatively steep increase in the number of persons. Due to improved con- sistency checking some missing person entries have been added but it is not clear whether this is sufficient expla- nation. The increase in the number of networks continues to slow down. This is partly due to the fact that measures to increase coverage of the database have not produced results everywhere yet as can be seen from the comparison with the number of networks seen by the hostcount: Country Nets in DNS Nets in DB Ratio Ratio Q3 Q2 __________________________________________________ BE 8 8 100.0 100.0 CS 11 11 100.0 100.0 HU 4 4 100.0 100.0 TN 1 1 100.0 100.0 YU 3 3 100.0 100.0 FR 337 317 94.1 95.5 ES 24 22 91.7 88.9 CH 97 85 87.6 93.1 IE 16 14 87.5 90.9 PL 15 13 86.7 90.0 PT 40 34 85.0 80.0 IT 84 71 84.5 82.4 NL 105 87 82.9 80.9 DE 342 282 82.5 80.5 GR 14 11 78.6 66.7 IS 4 3 75.0 50.0 IL 23 17 73.9 71.4 UK 208 140 67.3 67.8 AT 58 39 67.2 63.8 SE 166 96 57.8 49.3 NO 51 29 56.9 58.5 DK 20 9 45.0 40.0 LU 3 1 33.3 50.0 FI 457 40 8.8 6.9 - 10 - A grahical representation of this table can be found "Appen- dix H". Database Updates The frequency of update runs remains at once per working day with an occasional run skipped and some days with multiple runs as demanded by the volume of updates received. This ensures that users perceive the database update process as predictable. During the reporting period the NCC has pro- cessed 17455 object updates, an average of 290 per working day. The number of updates received per month varies widely with peaks usually occurring just before RIPE meetings. The updates consist of additions and changes as well as so called "NOOPs". NOOPs are updates received which do not differ from the information already recorded in the data- base. The NCC accepts such requests because it makes bulk updates from secondary NICs easier: secondary NICs can just send in their whole database without having to select just the records which changed since the last bulk update was sent to the NCC. Action June 1992 Q3 1992 __________________________________ Updated 286 16% 1372 8% Added 483 27% 2505 14% NOOP 1005 57% 13578 78% Worldwide Database Coordination THe Internet Registry (at GSI), the NSFnet NIC (at MERIT) and the RIPE NCC have worked on a database exchange format during the reporting period. Mark Kosters of GSI has developed a formal syntax which is now almost agreed apart from a few cases where not all database schemas can easily support the exchange format. In this context the NCC has proposed some small schema changes to the RIPE database working group. The NCC has also developed alpha level software to convert the RIPE database to the exchange format in order to test the practical feasibility of the format and to spot gaps and problems. 3.4. Document Store The document store is maintained as a reference point for information that will be useful to network service provid- ers, NICs, NOCs alike. The documents stored relate to a wide - 11 - variety of networking topics. For example, information can be obtained about the activities EBONE, the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG), RARE, and not least, documents relat- ing to RIPE itself. In addition the document store contains information relating to Internet drafts and RFC's.In total the document store contains approximately 2300 documents. By volume, it accounts for over 130 Mbytes. A breakdown of the composition of the document store is shown below Area Files KBytes _________________________________ rfc 556 39255 tools 129 31110 internet-drafts 377 21973 nsfnet 109 13683 ripe 210 10118 rare 223 8274 ietf 657 6774 iesg 33 360 ebone 19 278 internet-society 13 86 Revision of the RIPE archives The RIPE archives in the document store have been substan- tially revised in both structure and format. In revising the document store, the following benefits are perceived: o easy to follow structure o unique document identification o availability of early RIPE documents All RIPE documents are now located in a ripe/docs/ direc- tory, which is further divided into the following subdirec- tories: - 12 - ripe-agenda/ ripe-current/ ripe-docs/ ripe-drafts/ ripe-minutes/ Throughout there is a new numbering scheme. In each sub- directory the numbering schemas are as follows: In the ripe-agenda/ subdirectory documents are numbered according to the format ripe-a-n where a indicates the agenda of the nth RIPE meeting. This subdirectory contains the agendas of all the RIPE meetings to date, in both Postscript (.ps) and ASCII (.txt) formats. The ripe-docs/ subdirectory contains RIPE approved docu- ments. The README file gives an indication of the nature of the documents but there is also a complete index in the file ripe-index.txt in the same directory. The document numbering scheme format is ripe-n where n indicates the document number. The README file from this directory containing the list of all RIPE documents to date can be found in "Appendix G" on page 34. The ripe-drafts/ subdirectory contains documents under dis- cussion and not yet formally approved by RIPE. In the numbering scheme the version number is indicated. The fol- lowing draft documents are labelled thus ripe- draft- folder1.v2.ps and ripe-draft-position-v2.txt. In the ripe-minutes/ subdirectory the minutes from all the RIPE meetings can be found in both Postscript and ASCII for- mats. The numbering scheme is in the format ripe-m-n where m indicates minutes of the nth RIPE meeting. A README file gives a listing of all the documents with the date of the RIPE meeting and the location. The ripe-current/ subdirectory contains the most recent ver- sions of frequently used documents. Documents in this subdirectory can also be found in other areas of the RIPE document store. So this subdirectory is maintained for the users convenience. For example, you can find templates for registering objects in the RIPE database in this subdirec- tory. You can also find the details of the next RIPE meeting and the latest hostcount statistics. - 13 - Accessing the Document Store The NCC document store can be accessed through a variety of methods. It can be accessed via anonymous ftp to ftp.ripe.net and by using GOPHER and WAIS clients to gopher.ripe.net or wais.ripe.net respectively. Additionally the NCC document store can be accessed through the NCC Interactive Information Server. FTP Usage Statistics The most popular archive sections of the RIPE document store are tabulated below. This displays the top 15 most popular sections which were accessed using ftp.The most popular sec- tion is the ripe database, with approximately 440 Mbytes transferred: Archive Section Files Sent Bytes Sent % of % of files sent bytes sent ___________________________________________________________________ ripe/dbase 716 442483156 12.90 57.72 rfc 551 60191792 9.93 7.85 ripe/hostcount 677 55739857 12.20 7.27 ripe/docs 1447 54068799 26.08 7.05 tools/conf 111 32760502 2.00 4.27 nsf 232 28134842 4.18 3.67 tools/www 97 19017057 1.75 2.48 nsf/recompete 67 11203652 1.21 1.46 ripe/maps 180 8378535 3.24 1.09 tools/wais 66 8275052 1.19 1.08 tools/gopher 73 7476512 1.32 0.98 internet-drafts 123 7122860 2.22 0.93 rare/monograph 14 3430267 0.25 0.45 rare/RTR 16 3197348 0.29 0.42 rare/archive 148 3011151 2.67 0.39 The number of Mbytes transferred using ftp per top level domain is shown below: Domain Name Number of Number of % of % of files sent bytes sent files sent bytes sent _______________________________________________________________ IIS 0 0 0 0 IXI 0 0 0 0 LOCAL 0 0 0 0 NCC-X25 0 0 0 0 UNKNOWN 481 31137253 8.67 4.06 - 14 - at 102 11305114 1.84 1.47 au 1 18672 0.02 0.00 be 76 8576826 1.37 1.12 ca 15 3172096 0.27 0.41 ch 377 95012970 6.79 12.39 cl 0 0 0 0 com 104 8783639 1.87 1.15 cs 123 5623920 2.22 0.73 de 279 24371114 5.03 3.18 dk 7 1304257 0.13 0.17 edu 182 30193420 3.28 3.94 es 201 7352212 3.62 0.96 fi 923 177825504 16.63 23.20 fr 149 27713042 2.69 3.62 gov 13 1172986 0.23 0.15 gr 16 3009143 0.29 0.39 hk 1 59437 0.02 0.01 hu 15 3745953 0.27 0.49 ie 69 6143620 1.24 0.80 il 8 461240 0.14 0.06 is 0 0 0 0 it 97 7080885 1.75 0.92 jp 12 896779 0.22 0.12 kr 33 961636 0.59 0.13 lu 0 0 0 0 mil 1 7909 0.02 0.00 mx 2 819399 0.04 0.11 net 1379 219298206 24.85 28.61 nl 560 72367290 10.09 9.44 no 87 3941346 1.57 0.51 org 7 521496 0.13 0.07 pl 37 2380214 0.67 0.31 pt 38 1696189 0.68 0.22 se 35 3940305 0.63 0.51 sg 0 0 0 0 tn 0 0 0 0 tw 0 0 0 0 uk 83 3023006 1.50 0.39 us 0 0 0 0 yu 33 2639771 0.59 0.34 za 3 30670 0.05 0.00 The unresolved category refers to where there is no match found between the IP address and the Domain Name. A grahical representation of this table can be found "Appendix H". Interactive Information Server Once again the NCC would like to stress the idea behind the Interactive Information Server (IIS) and to encourage its usage. Therefore we make no apologies for repeating the - 15 - information (although abbreviated) in this paragraph. The goal of the IIS is to enable users with minimal hardware and/or software support to access information stored by the NCC. The IIS is also the most convenient method to access the RIPE document store from networks which are not IP based. At the same time it caters for those occasional users who do not choose to run or learn the local WAIS, GOPHER etc. clients. It is possible to access the information in the document store using both telnet and pad connections. In addition the server provides an interface to a number of clients enabling a wide range of information to be accessed in a number of different ways. Currently these comprise WAIS, Gopher and WHOIS. For details on how to use the IIS, please refer to our information leaflet "Interactive Infor- mation Server" or see the first edition of the NCC Quarterly Reports. General Service Usage Statistics. Statistics for the use of the various NCC information ser- vices were collected for the third quarter of 1992 The table below shows the total number of connections made for each service (Whois, IIS, Wais, Ftp and Gopher) contacted either directly from a user client or from the NCC Interactive Information Service. The breakdown is given as total number of connections per month: Service Apr May Jun Jul Aug Sep _________________________________________________ Whois 3014 5093 4520 7909 7845 8044 IIS 230 530 602 669 591 628 Wais 14 159 1005 1040 682 816 FTP 201 436 770 849 645 625 Gopher 0 89 577 371 337 340 Due to technical problems GOPHER logging has commenced in mid May.The number of connections to the various servers at the NCC broken down by the source of the request is shown in the table below. Source Whois IIS Wais Ftp Total ____________________________________________ IIS 2606 0 1149 0 3755 IXI 16 217 0 0 233 LOCAL 779 101 74 7 961 NCC-X25 0 23 0 0 23 - 16 - PSPDN 0 1 0 0 1 UNKNOWN 275 315 49 206 845 at 113 53 9 55 230 au 8 34 27 2 71 be 47 8 3 32 90 ca 6 6 0 14 26 ch 184 81 103 233 601 cl 0 8 0 1 9 com 86 31 751 81 949 cs 118 2 17 34 171 de 4828 76 18 165 5087 dk 100 17 10 17 144 edu 7599 196 293 161 8249 es 109 17 0 28 154 fi 48 10 14 117 189 fr 487 53 21 109 670 gov 19 3 7 9 38 gr 44 11 0 7 62 hk 0 0 0 3 3 hu 153 48 10 19 230 ie 230 23 0 55 308 il 52 5 0 12 69 is 29 0 0 5 34 it 208 15 1 46 270 jp 0 6 0 5 11 kr 2 4 1 3 10 lu 0 5 0 0 5 mil 1 34 20 6 61 mx 0 0 0 2 2 net 1890 36 8 187 2121 nl 2105 264 42 365 2776 no 128 16 0 42 186 org 2776 20 4 8 2808 pl 9 22 0 17 48 pt 218 12 0 23 253 se 588 65 6 27 686 sg 0 3 0 0 3 tn 0 3 0 2 5 tw 0 0 0 1 1 uk 259 112 21 54 446 us 0 5 0 0 5 yu 0 2 0 11 13 za 0 3 0 6 9 Total 26120 1966 2658 2177 32921 In total there were 1966 connections to the Interactive Information Server, which is queried, on average, 32 times per working day. A grahical representation of this table can be found "Appendix H". The provisional access from the IXI network has been used 233 times during the reporting period, slightly less than 4 - 17 - times per working day on average. This service will have to be discontinued once the IXI connection at NIKHEF which it uses is disconnected unless alternative access can be found. 3.5. Information Leaflets Revised versions of the RIPE NCC promotional leaflets `Net- work Management Database' and `Interactive Information Ser- vice' respectively, have been drafted. The revised leaflets comprise new information as well as bringing the existing information up to date. Prior to printing the leaflets will be raised for approval at the 13th RIPE meeting. Copies of the draft leaflets (ASCII) were circulated to the RIPE mail- ing list with an invitation for comments. Postscript versions of the leaflets (complete with graphics) were also posted in the RIPE document store in the subdirec- tory: ripe/docs/ripe-drafts/ ripe-draft-folder2.v2.ps (database leaflet) ripe-draft-folder1.v2.ps (interactive information services leaflet). In addition, a new leaflet "Delegated Internet Registry" has been drafted and the content will be discussed at the forth- coming 13th RIPE meeting in Paris. A further 2,000 of each leaflet will be printed. The Joint Network Team (GB) have ordered 1,000 copies of each of the leaflets. The NCC is happy to supply hard copies of the leaflets to any organisation requesting them. 3.6. Presentations Once again the NCC wishes to stress that it is considered a priority to inform as many users as possible, as clearly as possible, what the role of the NCC is in relation to the multitude of networking organisations. Clearly the larger the audience, the easier this task is. To this end the NCC will give presentations about its activities wherever appropriate and possible. It is stressed that all those organisations wishing to convey the work of the RIPE NCC to others are invited to contact the NCC with a request for a presentation. SURFnet is the only organisation that has contacted the NCC over the last quarter with a request for a presentation, which is scheduled for 6th October to be given by Daniel Karrenberg. - 18 - 3.7. RIPE Support Activities RIPE meetings Currently RIPE meetings take place three times a year. From its initiation on April 1st 1992, the RIPE NCC was chartered to provide support to all RIPE meetings. The meetings are open to all Internet service providers, and enable both formal and informal information gathering, the exchange of ideas and debate. In addition it is at RIPE meetings where the members of the 8 RIPE working groups can meet face to face to discuss and progress their work. The NCC welcomes suggestions for support from participants for future RIPE meetings. WG Liaison Once again it is necessary to highlight the importance to RIPE of the work carried out by the working groups. To this end, continuity of dialogue between the RIPE meetings is vital. In the June Quarterly it was reported that to encourage and promote this, the RIPE NCC staff members had been appointed "liaison officers" to assist the chairpersons of the working groups (see "Appendix F" on page 32 for details). The working group chairpersons are encouraged to utilise the services offered by the RIPE NCC. Specifi- cally the NCC can offer assistance with editing and format- ting documents, directing enquiries to the relevant working groups and assistance with keeping track of the minuted actions. The initiative needs more impetus. The RIPE NCC welcomes suggestions on giving support to the working groups. New Mailing List for IP Providers From time to time the RIPE NCC receives queries from organi- sations wishing to obtain information about service provid- ers in a particular area. To retain an impartial role, the NCC has established a new mailing list: ip-provs@ripe.net All such queries are posted to this list. IP service pro- viders who subscribe to the list will then receive at the same time, requests from potential customers. It is then the responsibility of the individual service providers to contact the potential customers. The list is not intended - 19 - to be a discussion list in any sense, but a referral list to which the details of queries from potential customers will be posted to those who subscribe to the list, at the same time and without bias from the NCC. If you do not already subscribe to the list, you can do so by sending an email message to: ip-provs-request@ripe.net 3.8. Audiocast The NCC has experimented with the audio transmission tools used to broadcast plenary sessions at IETF meetings. This tool looks promising for operational coordination as well as support of RIPE activities such as working groups. As a large scale trial it is planned to audiocast the plenary sessions of the 13th RIPE meeting. Since these tools are based on IP multicasting, a European Multicast Backbone is needed as part of the worldwide MBONE to replace the current ad hoc structures. To this end a BOF session at the 13th RIPE meeting has been proposed. 3.9. Referrals and End-User Enquiries The number of referral requests and end-user enquiries has not been significant during the reporting period. Most queries have been related to either requests for IP numbers or dealt with by establishing the mailing list for IP Pro- viders. See "New Mailing List for IP Providers" on page 18. 3.10. General Set Up The acquisition of a new fax machine located in the NCC office, has enabled the NCC to improve its response times. Please note our new fax number: +31 20 592 5090 The fax has been of benefit to organisations who do not have email connectivity (most frequently this has been in connec- tion with requests for IP network numbers), thus enabling the NCC to respond swiftly to requests. In addition, software that allows sending fax messages directly from the workstation is undergoing testing. - 20 - 4. Acknowledgements The RIPE NCC wishes to thank the RARE Secretariat for their excellent support throughout this quarter. We wish also to thank the local registries for their excel- lent work, especially with regard to the allocation of IP numbers Thanks are due to the RIPE chairman for his considerable effort in revising and making complete, the document store. - 21 - Appendix A - Meetings Attended The following meetings were attended by staff during the second quarter of the RIPE NCC operations. Date Name & Location Attendee ________________________________________________________ July 13-17 IETF, Boston, USA Marten Terpstra August 3-4 EBONE Action Team EBONE Operations Team Stockholm, Sweden Marten Terpstra Sept. 30 - October 2 13th RIPE meeting Paris, France Daniel Karrenberg Marten Terpstra Anne Lord - 22 - Appendix B - Class B Network Number Allocations to Date The table below summarises all assignments of class B net- work numbers made through the RIPE NCC to date. The "Via" column indicates through which registry received the request and solicited the necessary justification. Network Number Via ___________________________ 160.44-160.52 DE-NIC 160.53 SWITCH 160.54-160.58 DE-NIC 160.59 SWITCH 160.60 DE-NIC 160.61-160.62 CH NIC 160.63 SWITCH 163.156-163.157 RIPE NCC 163.158 CH NIC 163.159-163.160 RIPE NCC 163.161 SWITCH 163.162 GARR 163.163-163.165 RIPE NCC 163.166 ICNET 163.167 JANET 163.168-163.175 RIPE NCC 164.1 RIPE NCC 164.2 RIPE NCC 164.3 EUnet/AT 164.4 SE NIC 164.5 RIPE NCC 164.6 PIPEX 164.7-164.15 free 164.16-164.34 DE-NIC 164.35-164.40 free - 23 - Appendix C - Class C Block Allocations to Date The table below summarises the delegation status of the class C network number blocks allocated through the NCC and the number of networks allocated from these blocks. The "p/n" column indicates whether the block in question is delegated to the local registry of a service provider or is used to allocate numbers to organisations without a service provider. The fact that there are multiple non-provider blocks for Belgium and Norway is due to an unfortunate clerical error at the NCC. This situation will be corrected if possible. It should be noted that blocks are reserved based on usage estimates given by the local registries for a period of about 24 months. Should the assignment rate differ from the estimated one, reserved blocks can and will be used for other purposes if necessary. Block p/n assigned Country Registry __________________________________________________________________________ 192.162 6 NCC Miscellaneous TN,RO,PT 192.164 p 142 AT EUnet/AT 192.165 155 SE NORDUnet 192.166 174 DE DE-NIC 192.167 2 IT GARR 192.168 p 0 EU EUnet/NOC 193.0 free NCC 193.1 p 6 IE HEANET 193.2 p 2 YU ARNES 193.3 free NCC (was EUnet/DK temporary) 193.4 11 IS Iceland everything 193.5 p 24 CH SWITCH 193.6 p 22 HU Sztaki 193.7 p 0 DE chambers of commerce DE-NIC 193.8 n 2 CH non-provider CH-NIC 193.9 n 16 EU non-provider European (managed by NCC) 193.10 p 3 SE SUNET 193.11 p resvd SE SUNET 193.12 p 12 SE SWIPNET 193.13-15 p resvd SE SWIPNET 193.16 n 127 DE non-provider DE-NIC 193.17 n 41 DE non-provider DE-NIC 193.18-31 n resvd DE non-provider DE-NIC 193.32 p 45 UK non-provider UK-NIC 193.33-34 n resvd UK Sainsbury's (multiple B request) 193.35-39 n 0 UK non-provider UK NIC 193.40 n 1 NO non-provider NCC - 24 - (to be reclaimed) 193.41-43 free NCC 193.44 p 4 SE TIPNET 193.45-47 p resvd SE TIPNET 193.48 p 97 FR RENATER 193.49-51 p resvd FR RENATER 193.52 free NCC 193.53 n 5 BE non-provider (managed by NCC) block allocated by clerical error 193.54-55 free NCC 193.56 n 0 FR non-provider FR NIC 193.57 n resvd FR non-provider FR NIC 193.58 n 5 BE non-provider (managed by NCC) 193.59 p 5 PL academic 193.60 p 36 UK JANET 193.61 p 10 UK JANET 193.61 p 0 UK JANET 193.63 p 1 UK JANET 193.64 p 13 FI EUnet/FI 193.65-67 p resvd FI EUnet/FI 193.68 p 0 BG EUnet/BG 193.69 p resvd IS EUnet/IS 193.70 p resvd IT EUnet/IT 193.70 p resvd NO EUnet/NO 193.72 p 8 CH EUnet/CH 193.73 p resvd CH EUnet/CH 193.74 p 1 BE EUnet/BE 193.75 p resvd BE EUnet/BE 193.76-77 p resvd HR EUnet/HR 193.78 p 9 NL EUnet/NL 193.79 p resvd NL EUnet/NL 193.80-83 p resvd AT EUnet/AT 193.84 p 0 CS EUnet/CS 193.85-87 p resvd CS EUnet/CS 193.88 p 17 DK EUnet/DK 193.89-91 p resvd DK EUnet/DK 193.92 p 0 GR EUnet/GR 193.93 p resvd GR EUnet/GR 193.94 p 5 TN EUnet/TN (managed by NCC) 193.95 p resvd TN EUnet/TN 193.96 p 43 DE EUnet/DE 193.97 p 0 DE EUnet/DE 193.98-103 p resvd DE EUnet/DE 193.104 p 0 FR EUnet/FR 193.105-111 p resvd FR EUnet/FR 193.112 p 0 UK EUnet/UK 193.113 p 0 UK EUnet/UK (special) 193.114-119 p resvd UK EUnet/UK 193.120 p 0 IE EUnet/IE 193.121-123 p resvd IE EUnet/IE 193.124 p 11 RU EUnet/RU + xSU 193.125 p resvd RU EUnet/RU + xSU 193.126-127 p resvd PT EUnet/PT - 25 - 193.128 p 16 UK PIPEX 193.129-135 p resvd UK PIPEX 193.136 p 0 PT RCCN 193.137 p resvd PT RCCN 193.138 3 SI general (managed by NCC) 193.139 free NCC 193.140 6 TR general (managed by NCC) 193.141 free NCC 193.142 n 1 FI non-provider (managed by NCC) 193.143 n resvd FI non-provider (managed by NCC) 193.144 p 0 ES RedIRIS 193.145-147 p resvd ES RedIRIS 193.148 n 9 ES non-provider ES NIC 193.149-155 n resvd ES non-provider ES NIC 193.156 p 0 NO UNINETT 193.157-159 p 0 NO UNINETT 193.160 n 0 NO non-provider NO NIC 193.161 n resvd NO non-provider NO NIC 193.162 n 1 DK non-provider (managed by NCC) 193.163 n resvd DK non-provider (managed by NCC) 193.164 n 1 PL non-provider (managed by NCC) 193.165 n resvd PL non-provider (managed by NCC) 193.166-255 free NCC - 26 - Appendix D - Domain Table This appendix gives an overview of all top level domains, and other categories mentioned in the tables and graphs. Domain Specifying ______________________________________________________________________ IXI IXI IIS the Interactive Information Server LOCAL the NCC itself using IP NCC-X25 the NCC itself using X.25 PSPDN the Public Data Network UNKNOWN no mapping between IP address and domain name could be found com commercial organisations (mainly in the US) edu educational organisations (mainly in the US) gov US government organisations mil US military organisations net network providers and related organisations org organisations (mainly in the US) al Albania at Austria au Australia be Belgium bg Bulgaria by Byelorus ca Canada ch Switzerland cl Chile cs Czechoslovakia de Germany dk Denmark dz Algeria ee Estonia es Spain fi Finland fr France gb Great-Britain gr Greece hk Hong Kong hr Croatia hu Hungary ie Ireland is Iceland it Italy il Israel jp Japan kr Korea lt Lithuania lu Luxembourg lv Latvia - 27 - nl The Netherlands mx Mexico no Norway nz New Zealand pl Poland pt Portugal ro Romania se Sweden sg Singapore si Slovenia su USSR tn Tunesia tw Taiwan ua Ukraine uk United Kingdom us United States va Vatican City State yu Yugoslavia za South Africa - 28 - Appendix E - Standard Information Package for Registry Requests To whom it may concern, The RIPE Network Coordination Centre now handles all requests for IP network numbers from European organisations. Our aim is to provide a rapid and efficient service to all European organisations. As this is a recent initiative, pro- cedures for handling network number requests are in the pro- cess of being established. Therefore we apologise in advance for any duplication of effort that may be required by you due to new forms and templates. As the European NIC, we require different information to that required by the US and for it to be presented in a format which is both easy for you to complete and for us to process. Before your applica- tion can be processed any further, you will need to complete the enclosed templates and return them to the appropriate organisation responsible for issuing IP network numbers. In most cases this will be your IP service provider or the RIPE NCC. Before completion of the template, please be sure to read the following text and examples carefully which will guide you. A new classless IP addressing scheme called CIDR has recently been adopted to cope with routing table growth and address space exhaustion problems in the Internet. Under this scheme it is beneficial for everyone to get their net- work numbers allocated via their respective IP service pro- viders. Your IP service provider is the organisation provid- ing external connectivity to your network. If you are plan- ning to connect your network to other networks outside your organisation in the foreseeable future we strongly urge you to get numbers allocated from your current or prospective IP service provider. Alternatively, if this is not likely, then you will be allocated a number from a different part of the address space by the RIPE NCC. Please pay careful attention to this matter. Class A and B network numbers are a scarce resource and some justification in terms of expected network size and struc- ture will be needed before such a number can be allocated. Class A numbers will only be assigned to networks which technically need more than 65000 hosts to be on one network number. A detailed technical justification is needed, review takes place on a global scale and the allocation process can take several months. Similarly due to class B scarcity, a reasonable number of class C numbers will be assigned over class B. If you can engineer your network to use multiple class C numbers, it is strongly advised. Please note that this is contrary to earlier recommendations where it was recommended to use Bs over multiple Cs due to routing table size constraints. A one page document detailing the - 29 - information needed by the NCC to evaluate requests for class B numbers is available from the NCC if it is not enclosed with this letter; this document also includes a list of recommended reading about CIDR and address allocation in general. Appended to this letter is a blank template for IP number registration, which we would be extremely grateful if you complete and return to the appropriate organisation respon- sible for issuing IP network numbers. In most cases this will be your IP service provider. It may of course also be the RIPE NCC. If you have any further queries please do not hesitate to contact the NCC. Please note that all queries should, if possible, be made through e-mail and sent to . If you do not have access to elec- tronic mail, then we prefer to communicate by fax rather than by ordinary mail. You can reach us at: Kruislaan 409 Phone: +31 20 592 5065 NL-1098 SJ Amsterdam Telefax: +31 20 592 5090 The Netherlands If we do not hear from you in the near future we will assume that you have contacted your IP service provider. Yours sincerely, The RIPE NCC staff Recommended Reading List for Address Allocation and CIDR 1. rfc 1338.txt - CIDR Addressing Scheme 2. draft-rekhter-ipaddress-guide-02.txt - Global Address Requirement 3. rfc1347.ps (postscript format) - Further Reading 4. rfc1347.txt (ascii format) - 30 - The documents you require are all contained within the RIPE document store. Reference 1, 3 and 4 can be found in the rfc/ directory. Reference 2 can be found in the internet- drafts/ directory. The RIPE document store can be accessed in a number of ways: 1. on the Internet type: telnet info.ripe.net 2. using the IXI network type: pad 020430459300031 3. via the Public Data Network type: pad 0204129004331 4. on the Internet via anonymous FTP from host ftp.ripe.net Additional Hints for Organisations Requesting Class B Net- work Numbers Please understand that the criteria for allocating Class B network addresses are extremely strict. This is due to the global scarcity of these network numbers. Out of necessity then, the NCC has to closely examine each and every request we receive for a class B network address. As a result the allocation process will take longer. Organisations can how- ever speed up the process by providing the NCC with as much information as possible on their initial request to enable us to make a decision without having to request more infor- mation. Specifically, we require information about the number of hosts in your network at the following points in time: - now - one year from now - two years from now - any other significant milestone The number of hosts estimates should be substantiated with other data about the network and/or organisation like number of employees, geographical distribution, type of hosts. The clearer you can document that your estimates are carefully derived, the easier it is for us to justify allocation of a class B address. Besides a sufficient number of hosts we must determine that - 31 - your network cannot be engineered using a number of contigu- ous class C networks. If your network consists of a large number of physical networks with relatively small numbers of hosts on each, you will have to consider subnetting class C networks. A large number of subnetworks alone is not suffi- cient justification for allocation of a class B network number. We realise that a number of engineering decisions can be based on administrative convenience. Unfortunately the remaining class B address space is too small to take these considerations into account. The clearer your explana- tion is, as to why your network *cannot* be engineered using a block of class C network numbers, the easier it is for us to justify allocation of a class B network address. All the above mentioned points apply even more strongly to cases where multiple class B network numbers are requested. Assignments of multiple class B network numbers will only occur when the RIPE NCC is satisfied with a detailed justif- ication in terms of the criteria mentioned. Finally, please understand that we are not working against you, but with the whole Internet community to achieve a fair distribution of the remaining address space. If you have any questions about the procedure or the information needed, please do not hesitate to contact the RIPE NCC for further guidance. - 32 - Appendix F - Working Group Mailing Lists Coordinating and support for the activities of the Working Groups is a key focus for the RIPE NCC. During the first quarter, the NCC has created mailing lists for those working groups that have requested this facility. Relationship between Academic & Research Networks & Commer- cial Networks. Chair: Glenn Kowack. E-mail: glenn@eu.net. Working Group E-mail: raec-wg@ripe.net. Network Information Discovery and User Support. Chair: Nandor Horvath. E-mail: horvath@sztaki.hu Working Group E-mail: nidus-wg@ripe.net DNS Issues Chair: Francis Dupont. E-mail: francis.dupont@inria.fr Working Group E-mail: dns-wg@ripe.net Routing Issues Chair: Jean-Michel Jouanigot. E-mail: jimi@dxcoms.cern.ch Working Group E-mail: routing-wg@ripe.net Network Monitoring and Statistics Gathering Chair: Bernhard Stockman. E-mail: boss@sunet.se Network Maps Chair: N.N. (Hank Nussbacher resigned) European Connectivity - 33 - Chair: Milan Sterba. E-mail: milan.sterba@inria.fr RIPE Database Chair: Wilfried Woeber. E-mail: woeber@access.can.ac.at To subscribe to any working group send a message to: [listname]-request@ripe.net where [listname] is replaced by the name of one of the work- ing groups specified above. - 34 - Appendix G - README file from RIPE Document Store Contents: RIPE documents. The agenda's and minutes of RIPE meetings are kept separately: agenda's: ripe/ripe-agenda minutes: ripe/ripe-minutes How to access: The documents can be retrieved by anonymous ftp from ftp.ripe.net in the directory ripe/ripe-docs Numbering scheme: A document may be stored in two ways: as plain ASCII text and as PostScript. The two can be distinguished by the file extension: .txt and .ps respectively. For completeness sake, a reference to the "old" RIPE document classification scheme is given, when available. Also: A fully indexed description of all RIPE documents can be found in the file ripe- index.txt in this directory. - 35 - Index: ripe-1 RIPE Terms of Reference ripe-2 Statement of Cooperation ripe-3 Letter of Introduction ripe-4 Task Force Description ripe-5 European IP connectivity map - by IP number ripe-6 European IP connectivity map - by domain name ripe-7 Some practical DNS advice ripe-8 European IP connectivity map - by IP number ripe-9 European IP connectivity map - by domain name ripe-10 Legend to European IP maps ripe-11 European IP connectivity map - by IP number ripe-12 European IP connectivity map - by domain name ripe-13 RIPE Databases ripe-14 Legend to European IP maps ripe-15 European IP connectivity map - by IP number, 1 page version ripe-16 European IP connectivity map - by IP number, 2 page version ripe-17 European IP connectivity map - by domain name, 1 page version ripe-18 European IP connectivity map - by domain name, 2 page version ripe-19 RIPE Network Coordination Centre (RIPE NCC) ripe-20 RIPE DNS hostcount ripe-21 RIPE requirements ripe-22 RIPE DNS hostcount ripe-23 Legend to European IP maps ripe-24 European IP connectivity map - by IP number, 1 page version ripe-25 European IP connectivity map - by IP number, 2 page version ripe-26 European IP connectivity map - by domain name, 1 page version ripe-27 European IP connectivity map - by domain name, 2 page version ripe-28 RIPE DNS hostcount ripe-29 RIPE DNS hostcount ripe-30 Legend to European IP maps ripe-31 European IP connectivity map - by IP number ripe-32 European IP connectivity map - by domain name ripe-33 RIPE DNS hostcount ripe-34 RIPE DNS hostcount ripe-35 RIPE NCC Activity Plan ripe-36 RIPE recommendation: IP networking on IXI ripe-37 RIPE recommendation on IP router management ripe-38 RIPE DNS hostcount ripe-39 Procedures to set up the RIPE NCC ripe-40 RIPE Database status report ripe-41 RIPE DNS hostcount ripe-42 RIPE DNS hostcount ripe-43 RIPE DNS hostcount ripe-44 RIPE DNS hostcount ripe-45 Relationship between A & R networks and Commercial networks ripe-46 RIPE DNS hostcount ripe-47 RIPE DNS hostcount ripe-48 RIPE request template for IP numbers ripe-49 RIPE database template for domains ripe-50 RIPE Database Template for Networks ripe-51 RIPE Database Template for Persons - 36 - ripe-52 RIPE Database status report ripe-53 RIPE DNS hostcount ripe-54 An overview of East and Central European Networking activities ripe-55 RIPE NCC - Hardware Configuration (slides) ripe-56 RIPE NCC - Report (slides) ripe-57 General information about RIPE and the RIPE NCC ripe-58 RIPE NCC Database leaflet ripe-59 RIPE NCC Information leaflet ripe-60 Policy based routing within RIPE ripe-61 RIPE DNS hostcount ripe-62 RIPE NCC Quarterly report Issue 1 ripe-63 RIPE recommendation on Operational Contacts ripe-64 RIPE DNS hostcount ripe-65 RIPE NCC Internet Numbers registration Procedures ripe-66 RIPE Task Forces ripe-67 RIPE DNS hostcount ripe-68 Central European connectivity map ripe-69 RIPE DNS hostcount history (slide) ripe-70 RIPE DNS hostcount ripe-71 RIPE DNS hostcount