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 <ripe@ripe.net> 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
<hostmaster@ripe.net>. 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