Dear all,
Hereby, I want to announce that we have put the new RIPE database release
2.00 in production. Since this version is a major upgrade, we certainly
expect a few problems (unfortunately we already found some and fixed
them already ;-)). Please take a close look at your updates and send me
(<ripe-dbm(a)ripe.net> only) your bug reports so that I can fix any
possible problems.
I am still finalizing the documentation (with more detailed information
on the new features) and the software distribution package. You can
expect a separate announcement from me on this later this week.
And finally:
I want to apologize for the late announcement of this upgrade and the
confusion that might have been caused by this.
If you have any further questions, please don't hesitate to contact me,
Kind regards,
David K.
-----
*****Preliminary release notes*****:
Dear all,
This message is to announce the new 2.00 release version of the RIPE
database. Many new features and bug fixes have been added since the the
previous beta release.
The following lists the most interesting new features since the previous
non-beta release:
- AUTO NIC handle assignment support
- hierarchical authorization for creation of 'inetnum' and 'domain'
objects.
- role object support
- prefix notation for 'inetnum:' updates is supported and IP range
notation for whois lookups
- extended 'country:' attribute syntax implemented, more then one coutry
on a line and more 'country:' attributes per object are allowed now.
- the special RIPE whois client is now fully supported and included in
the distribution.
- much stronger syntax checking (=as strong as specified by the original
database specification) for NIC handles, phone numbers, E-mail
addresses, domain names (Some people might not like this ;-)).
- network updates, a method for directly updating objects by use of the
program 'networkupdate'. The use of this method is restricted by
an accesslist and intended for the maintenance people of the database.
- BSD DB dbm package is fully supported. This dbm package is a fast,
platform independant and reliable dbm package.
- No limitations on the number of hits (no matter what indexing package
you use):
a query like 'David' will give you an answer and person names like
'John George' will be found
- new and more intelligent indexing program 'indexdb' that can do a raw
index or a clean index and automatically detects if it is dealing with
a classless index. netdbm & cleandb are now obsoleted.
- reverse lookup of objects (whois -i option), this enables you to find
for example the routes with a given origin as by doing:
whois -h whois.ripe.net -i origin AS3333
- Nearly real time mirroring of the RIPE database. This feature is fully
supported but has a few shortcomings that will involve a bit more
administration work until the 'stored/processed' attribute and better
crash recovery routines are implemented.
- experimental inet6num support for ipv6 network objects, including
support for -L, -m, -M queries.
and many more small changes and fixes. Please read the release notes at
the bottom of this message for more information and discussion about
these topics.
Please send bug reports/fixes directly to <ripe-dbm(a)ripe.net> and I will
fix the problem but be fast since I will move to another job at ISI in
August!
Thanks for all your help,
Kind regards,
David Kessens
RIPE NCC software maintainer
-------
RELEASE NOTES (RIPE database version 2.00):
- Nearly real time mirroring support:
What is it:
The database software now keeps serial numbers of all updates. If you
have been added to an accesslist, it it possible to retrieve all the
changes to the database. A program 'syncdb' has been added to the
distribution that can retrieve these changes and update your mirror
database automatically. This program is intended to be put in a
cronjob.
The whois erver has an access list so you first need to ask the site
to be mirrored to add your host to the access list.
Please let me now at <ripe-dbm(a)ripe.net> if you are interested in
trying out this feature, and I will add the IP number of your site to
the access list.
Short discussion:
Note that this is the first version, it currently uses seperate files
internally for every update. We plan to change this since this is not
really what we want with 2000 (atomic) updates on some days.
Furthermore, we use currently an ever increasing integer serial number.
A proposal (stored/processed attribute) on how to this right has
already been circulated to the RIPE database working group and discussed
on the RIPE meeting. Implementation of this attribute will also allow
for a better crash recovery behavior.
- No limitations on the number of hits (no matter what indexing package
you use): a query like 'David' will give you an answer and person
names like 'John George' will be found
- New and more intelligent indexing program 'indexdb' that can do a raw
index or a clean index and automatically detects if it is dealing with
a classless index (from the config file). netdbm & cleandb are now
obsoleted. The indexing speed has also been improved.
- BSD berkeley DB support:
The database software can now use the Berkeley DB dbm package.
According to many people this package is superior to most other dbm
packages that perl can use (unlimited size of keys/values, platform
independent db files). We have put the current sources for this
package at ftp://ftp.ripe.net/tools/db.1.85.tar.gz
It should be possible with the BSD DB package to increase the
OVERFLOWSIZE and as result get rid of (most) of the overflow files.
However, it is not clear if this is desirable since it doesn't seem to
make the software more memory/space/speed efficient.
- a new help and HOWTO use the RIPE database file is available
use 'whois -h whois.ripe.net HELP' to get the most recent version.
The document gives a short introduction on the database, tells you how
to create/update/delete objects, contains a section with tips and common
problems and gives pointers to other documentation about the database.
- BSDI/perl memory leak problems
Due to a memory leak with perl on BSDI machines we needed to make the
code more memory conscious. enread.pl has been rewritten completely and
uses now less memory and as an (intended) side effect became faster
when reading big objects. Also the special input routine for reading in
an object from an E-mail has undergone the same optimizations.
- Most patches (for greater speed and less memory consumption) that I
received from Curtis Villamizar <curtis(a)ans.net> have been included.
Thanks Curtis!
- The direct network updating method is now fully supported.
Currently this method is only intended for use by the registry itself,
however it is possible to add support in the maintainer objects if
desired by the RIPE community.
You can now do you updates very rapidly by giving the command
'networkupdate' and input your object via STDIN. Of course, this is
also protected with an access list.
- The special magic to overrule the maintainer protection needs a
password now. Syntax will be published after the main registries
support this...
- All support for the historical 'guarded' objects have been removed. The
guardian attribute can be obsoleted if the database working group
wishes to. Present guardian attributes will act as a 'notify:'
attribute.
- the special RIPE whois version is now fully supported and included in
the distribution.
- cryptpw
is a new (small) program that encrypts a password with a shoosen salt
for use in the maintainer objects.
- dbupdate -T
Makes it very easy to install your own test database. The only
difference with a normal update is that it doesn't need manual
authorization for creation of maintainer objects and that it will add a
warning to your acknowlegment message that this is not the normal
behavior...
- status: attribute as described in ripe-127 fully supported
- whoisd changes:
-D runs in daemon mode otherwise in 'inetd' mode ('inetd' mode is
untested)
The number of disk accesses have been further minimized and should
result in a better performance.
- line continuation by use of a "\" character at the end of an attribute
line in your update message. The database software will then
automatically concatenate the next line with the previous one.
- prefix notation for 'inetnum:' updates and IP range notation for whois
lookups is supported
- extended 'country:' attribute syntax implemented. You can now specify
multiple countries in a 'country:' attribute line.
- much stronger syntax checking for NIC handles, phone numbers, E-mail
addresses, domain names (Some people might not like this ;-)). The
syntax was too relaxed and follows our own specifications more closely.
- perl5 patches. perl5 is still not supported. However, the biggest
problems should be gone now (the software runs with perl5 at home with
Linux & perl5.001m). The Makefiles have been changed to support
perl5 and some of the database tools as 'whois' can be configured to
run with perl5 by default (and work with it!). See the Makefiles on how
to configure this. You are welcome to experiment with perl5 and we are
interested in your comments!
- Tony Bates <Tony.Bates(a)mci.net> recent patch for a problem with the
maintainer notifications. Thank you Tony.
- databases and serial number files that don't exist are now
autogenerated.
- Config file has been simplified by removing some options that can be
determined by the database software itself. Of course, also a few new
options appeared. Everything is documented in the config file itself.
- The Makefiles have been rewritten to allow for easier installation and
more logical behavior when doing make [[un]install].
- many small fixes and clean up of the code to make above changes
possible.
- bug that caused problems when deleting objects with(out) syntactic sugar
- bug that caused a crash when one tries to delete an object
that cannot be updated (object is mirrored from other database)
- List of OS's that we know the RIPE database works with:
- SUNOS
- BSDI
- Linux
(Please inform me with you own results so that I can update this list!)
Automatic on the fly patches implemented in the new Makefiles should
make it possible to run the database on Solaris. This is untested for
now and you will need a special perl4 that will be made available from
ftp://ftp.ripe.net/tools. Peter Haag has made the perl version and
patches available to me. Thanks!
- The auto nic handle generation support (Gabor Kiss helped me with some
patches)
- Role object
What didn't make it in this release:
- checking for relations between objects:
- disallow deletion of referenced object
- disallow creation of objects that reference non exiting objects
At 17:59 23/07/96 +0200, you wrote:
>
>>Date: Sat, 13 Jul 1996 21:39:23 +0300 (IDT)
>>From: Alain Golan <alain(a)NetVision.net.il>
>>To: Janos Zsako <zsako(a)banknet.net>
>>Cc: robert(a)dk.net, lir-wg(a)ripe.net
>>Subject: Re: Please help: ptp links addresses
>>X-Info: UniNet by Unidata
>>
>>I don't remember exactly, but I am under the impression, that
>> I'v read somewhere that you can do something like the following
>> on Cisco routers:
>> 1) Set an IP address (/32) to the loopback interface.
>> 2) Tell the router that all ICMP replies should be sent
>> with this interface address.
>>
>>( I have done it for TFTP & SNMP..)
>>
>>If it is the case, with one address per router, You'll get
>> a fine traceroute reply.
>>
>>Can someone confirm ?
>>
You get this behavoir with 'ip unnumbered Loopback0'.
/pab
>> Regards,
>>
>> ___ ___ __
>> /__/ / /__/ / /\ /
>>/ / /__ / / _/_ / \/ o
>> vox://+972-4-8560600
>> cel://+972-5-2593886
>> Alain(a)NetVision.net fax://+972-4-8550345
>> http://www.netvision.net.il/php/alain
>>
>>
--
Paolo Bevilacqua ¦ ¦ Via F.T. Marinetti 221
cisco Systems Engineer ¦¦¦ ¦¦¦ 00143 Rome - Italy
pab(a)cisco.com .¦¦¦. .¦¦¦. Tel: +39 (6) 58201230
"The net works, then ?" ..¦¦¦¦¦....¦¦¦¦¦.. Fax: +39 (6) 5020016
> From owner-lir-wg(a)ripe.net Thu Jul 11 23:01:33 1996
> From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net>
Daniel,
> Also note that even for private address space traceroute will return the
> address correctly, so the diagnostics are useful. There just are no
> names. If the border gateways with publicly adressed interfaces has a
> reasonable name such as 'bordergw-xxx.clever.net' 'clever-gw.customer.nl'
> it is quite clear "where you are" in between.
Although I agree in general with your statement above, I think the details are
not necessarily true. According to RFC 1918:
Because private addresses have no global meaning, routing information
about private networks shall not be propagated on inter-enterprise
links, and packets with private source or destination addresses
^^^^^^^^^^^^^^^^^^^^^^^^^^^
should not be forwarded across such links. Routers in networks not
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
using private address space, especially those of Internet service
providers, are expected to be configured to reject (filter out)
routing information about private networks. If such a router receives
such information the rejection shall not be treated as a routing
protocol error.
If an ISP is taking this recommendation by the letter, then they install
a filter on the border routers to filter out these packets (as we do ourselves).
In this case though, a traceroute from outside will not receive any packets
from the interfaces that have a IP address from the private addresse space.
I agree however that the answers from the other routers will give you in most
of the cases enough information to figure out what route the packets take.
Regards,
Janos
Dear all,
First of all, it is recommended for everybody to read the *whole*
announcement. I have just put the new RIPE database whois server in
production. The new server has a couple of new features (and bug fixes):
- twice the speed for any classless lookups
- the lookup algoritm is changed such that: Matyas Matyas can finally be
found and also Daniel David hasn't problems anymore with finding
himself in the database
- email addresses in the person objects are now also indexed and can thus
be used as a search key from now on.
- unlimited number of matches allowed. You can now find all Davids in the
RIPE database
And then the *BONUS* feature (made in France during my vacation!):
- Inverse lookup has been implemented, that is:
$ whois -h whois.ripe.net -T limerick -i author MN131
will give you all limericks written by Mike Norris (as long as his NIC
handle is used, else try the same search with 'Mike Norris' as the key)
$ whois -h whois.ripe.net -T route -i origin AS3333
will give you all routes with origin AS AS3333
(this makes the ftp://ftp.ripe.net/ripe/as/db directories obsolete,
and they will thus be removed)
Also a comma separated list can be used as in:
$ whois -h whois.ripe.net -i admin-c,tech-c,zone-c DK13-RIPE
which will give you all objects that reference myself as an admin-c,
tech-c or zone-c.
You can use the following attributes for inverse lookups:
admin-c
as-exclude
author
as-in
as-list
as-out
comm-list
default
interas-in
interas-out
localas
mnt-by
mnt-lower
mnt-nfy
nserver
notify
origin
peer
rev-srv
tech-c
zone-c
Furthermore, the RIPE whois client program has been updated to support
the new options (I finally got the chance to do some C coding ;-)). The
program is now packaged with some other small C programs for use in
conjunction with the RIPE database:
ftp://ftp.ripe.net/tools/ripe-whois-tools-2.0.tar.gz
(perl versions will be packaged together with the new release of the
database software, when the updating code is also ready)
You will also need to upgrade the prtraceroute in case you use this
program (ftp://ftp.ripe.net/pride/tools/prtraceroute-2.0beta6.tar.gz).
(see also separate announcement).
Finally an important note to software developers:
The whois server now returns objects always in the following sequence:
newline
object/message
newline
object/message
newline
newline
(The newline at the start is new)
This change allowed for more consistency and faster code. However, I am
willing to make an ugly fix in case too many tools cannot handle this
corectly and need updates. Please let me know if this is indeed needed.
As always: please send bug reports directly to me and I will fix the
problem.
Kind regards,
David Kessens
RIPE NCC
----
RIPE whois tools 2.0
This is a set of C programs (perl versions of the same programs are
available in the RIPE database distribution) to be used in conjunction
with the RIPE database. It contains the following programs:
- whois
The RIPE version of the whois client program.
This is intended for European users as it will query a RIPE whois
server with extended whois capabilities rather than a standard whois
protocol server. The whois program is fully compatible with the
standard whois protocol and can thus replace your default whois
program.
This program is aware of quite some extra flags that the standard whois
doesn't support. Just try 'whois' without arguments to see an
explanation of these. Please note that most of these flags are NOT
supported by non RIPE whois servers. In cases where you use this client
to query non RIPE whois servers, you should not use any of these
flags.
- networkupdate
A program that allows updating the RIPE database with the whois
protocol instead of the usual E-mail interface. This program can
usually only be used by the administrators of the whois server itself.
The updating mechanism is too powerfull (for now) to allow the general
public to use this mechanism. The server is protected by means of an
accesslist.
- cryptpw
Calculate a crypted password with given password and salt.
This password can then be used in the 'auth:' field of maintainer
objects.
-----
Dear Local Registries,
I need some advice on the following:
An italian ISP, which we run its delegated LIR, is planning its
backbone network where there are *A LOT* of point-to-point links (on
leased lines, on channelized lines, on Frame Relay PVCs, etc.).
I know about two ways of managing the links in terms of IP addresses:
1- using a /30 subnet for each link:
in this way both ends of the link have a unique address (binary
01 and 10), but two addresses (binary 00 and 11) cannot be used,
so 50% of the address space used is wasted. This should be
avoided if possible because the address space required is
really large.
2- using unnumbered interfaces for each link and, on cisco routers,
associating another interface IP address (the loopback interface
is quite useful for this purpose):
in this way addresses are not wasted but certain functionalities
are lost, i.e. SNMP monitoring of each physical interface, etc.
Are you aware of any other way to deal with this issue so that it
is possible to have IP addresses for each interface without wasting
address space?
Thank you very much in advance.
---------- ----------
Antonio-Blasco Bonito E-Mail: bonito(a)nis.garr.it
GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito
c/o CNUCE - Istituto del CNR Tel: +39 50 593246
Via S. Maria, 36 Fax: +39 50 904052
I-56126 PISA Telex: 500371 CNUCE I
Italy Url: http://www.nis.garr.it/nis/staff/bonito.html
---------- ----------
