From robert at DK.net Mon Jul 8 20:36:12 1996 From: robert at DK.net (Robert Martin-Legene) Date: Mon, 8 Jul 1996 20:36:12 +0200 (MET DST) Subject: Please help: ptp links addresses In-Reply-To: <199606251115.NAA27501@cuori.nis.garr.it> Message-ID: On Tue, 25 Jun 1996, Antonio_Blasco Bonito wrote: > 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: [...] > 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? Hmm... I tried to do the following... it makes a bit sense to me, but my Cisco didn't like it (makes more sense if it rfc1918 address space). I took a quick glance at RFC1812 as well, but it didn't give a solution. interface s0 ip unnumbered e0 ip addr 193.88.45.1 255.255.255.252 secondary What happened though, was that the traffic looped between the two interfaces. What would be the good about this solution was that on a traceroute it would still map back to a host in your domain, but you can still ping/SNMP to the interface. So if someone has a good contact at Cisco, please ask them if they'd consider adding this to the code in the future. :-) -- Robert Martin-Leg?ne (RM59), Network Manager (AS2109) DKnet, Fruebjergvej 3, DK-2100 K?benhavn ?, Denmark, +45 39 17 99 00 From nic at rediris.es Mon Jul 8 22:08:52 1996 From: nic at rediris.es (Network Information Centre. RedIRIS CSIC) Date: Mon, 8 Jul 1996 22:08:52 +0200 (MET DST) Subject: Please help: ptp links addresses In-Reply-To: References: Message-ID: <199607082008.WAA16226@chico.rediris.es> Estimado/a Sr/a, Su mensaje de fecha: Mon, 8 Jul 1996 20:36:12 +0200 (MET DST) acerca de: Re: Please help: ptp links addresses ha sido recibido satisfactoriamente en el help-desk del ES-NIC (nic at rediris.es). El numero de mensajes pendientes de procesar en estos momentos es de 312. El suyo sera procesado cuando le llegue su turno, que estimamos sera en 20 dias habiles. Por favor, le rogamos encarecidamente que no vuelva a enviar su mensaje (en ese caso el recibido en primer lugar sera ignorado). Si lo que desea es informacion acerca del procedimiento y formulario para registrar un dominio de DNS de segundo nivel bajo ".es", puede obtener la documentacion necesaria en: ftp://ftp.rediris.es/es-nic/es-nic-dom.txt o bien enviando un mensaje a nic at rediris.es cuyo "subject" sea: get es-nic-dom.txt Si lo que desea son direcciones IP Internet, pongase en contacto con su proveedor de acceso Internet, que es quien se las tiene que suministrar (con fecha 31/1/96 el ES-NIC ha dejado de ejercer las funciones de registro de ultimo recurso para la asignacion de direcciones IP en Espana). Los proveedores, a su vez, han de obtener las direcciones IP necesariamente bien de su proveedor de transito, bien del registro delegado de Internet en Europa (RIPE NCC). Si es para cualquier otro asunto, recibira contestacion cuando su mensaje sea procesado. En caso de tratarse de una solicitud de registro de nombre de dominio bajo "es" le recordamos algunas de las normas basicas: - Solo se puede registrar un dominio de segundo nivel por organizacion, entendiendo como tal una persona juridica (no fisica), es decir, una entidad legalmente establecida en Espana y, por tanto, registrada en algun registro oficial (mercantil, fundaciones, asociaciones, entidades publicas, partidos politicos, etc.) - El dominio propuesto habra necesariamente de corresponderse o ser directa y facilmente asociable al nombre con el que la organizacion aparece registrada en el mencionado registro oficial (preferentemente el nombre completo o un acronimo registrado y habitualmente usado por la organizacion). - En el caso de que la organizacion prefiera utilizar el nombre de una de sus marcas registradas con la que habitualmente se la identifique, en lugar del de la propia organizacion, podra solicitar el registro de un nombre de dominio que se corresponda con dicha marca, siempre que lo acredite mediante el envio a este NIC del certificado correspondiente de la Oficina Espanola de Pantentes y Marcas. - Los unicos caracteres validos para un nombre de dominio son las letras del alfabeto ingles, los numeros y el guion ("-"). - En nigun caso se admitiran solicitudes de registro de nombres de dominio que: a) tengan menos de tres caracteres b) coincidan con algun dominio de DNS de primer nivel (Top Level Domain) c) se compongan exclusivamente de un toponimico d) se compongan exclusivamente de un generico e) coincidan con nombres de protocolos, aplicaciones y terminologia de Internet f) sean contrarios a la Ley o el orden publico, ofensivos o malsonantes g) se compongan exclusivamente de una combinacion de c), d), e) o f) h) se asocien de forma notoria a otra organizacion distinta de la solicitante i) se compongan exclusivamente de nombres o apellidos - Las solicitudes se procesaran por estricto orden de llegada. - Toda solicitud incorrecta, incompleta o que no cumpla las normas sera rechazada. - Cualquier falsedad en los datos consignados en la solicitud podra ser causa de rechazo de la misma o de baja del dominio si el registro ya se hubiera producido. Atentamente, ES-NIC +---------------------------------------------------------------+ | ES-NIC (Delegated Internet Registry for Spain) | | Centro de Comunicaciones CSIC RedIRIS | | Serrano 142 Tel: + 34 1 5855150 | | 28006 Madrid Fax: + 34 1 5855146 | | SPAIN Email: nic at rediris.es | +---------------------------------------------------------------+ From hmaster at forthnet.gr Mon Jul 8 22:17:29 1996 From: hmaster at forthnet.gr (GR HostMaster) Date: Mon, 8 Jul 1996 20:17:29 GMT Subject: Please help: ptp links addresses In-Reply-To: References: Message-ID: <199607082017.UAA03717@info.forthnet.gr> This is an automatic reply to acknowledge that your message has been received by the Greek Hostmaster (hostmaster at forthnet.gr) This acknowledgement is NOT a confirmation that your request has been processed. Your mail was forwarded to the appropriate people and you will have a response to your request as soon as possible. Kind regards, GR-HOSTMASTER hostmaster at forthnet.gr From alain at NetVision.net.il Tue Jul 9 13:25:01 1996 From: alain at NetVision.net.il (Alain Golan) Date: Tue, 9 Jul 1996 14:25:01 +0300 (IDT) Subject: Please help: ptp links addresses In-Reply-To: Message-ID: Why not use "private" address space, like network 10.0.0.0 You'll have plenty of subnets for internal links ! Regards, ___ ___ __ /__/ / /__/ / /\ / / / /__ / / _/_ / \/ o vox://+972-4-8560600 cel://+972-5-2593886 Alain at NetVision.net fax://+972-4-8550345 http://www.netvision.net.il/php/alain From robert at DK.net Tue Jul 9 16:07:44 1996 From: robert at DK.net (Robert Martin-Legene) Date: Tue, 9 Jul 1996 16:07:44 +0200 (MET DST) Subject: Please help: ptp links addresses In-Reply-To: Message-ID: On Tue, 9 Jul 1996, Alain Golan wrote: > Why not use "private" address space, like network 10.0.0.0 > You'll have plenty of subnets for internal links ! Because the address of the router in a traceroute then might be private address space one. I sort of like the idea that you know where in the world you are when you do a traceroute. If the interface has a hidden IP# that you can send packets to, but it still will present itself as (for instance) the ethernet interface, you just give the ethernet interface a "normal" IP# and all looks normal and the router only takes up one IP# (not counting RFC1918 address space). This way you can still ping the interface on 10.0.0.1 . -- Robert Martin-Leg?ne (RM59), Network Manager (AS2109) DKnet, Fruebjergvej 3, DK-2100 K?benhavn ?, Denmark, +45 39 17 99 00 From Daniel.Karrenberg at ripe.net Thu Jul 11 14:58:04 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 11 Jul 1996 14:58:04 +0200 Subject: Please help: ptp links addresses In-Reply-To: Your message of Tue, 09 Jul 1996 16:07:44 +0200. References: Message-ID: <199607111258.MAA28111@kantoor.ripe.net> > Robert Martin-Legene writes: > > Because the address of the router in a traceroute then might be private > address space one. I sort of like the idea that you know where in the > world you are when you do a traceroute. While this is nice but there may be a tradeoff here. If the address space for links and router interfaces is used efficiently, this is very nice to have. However some people for convenience or other reasons want to burn a lot of address space inefficiently -/24 subnets for 2 interfaces come to mind. In this case they are welcome to use private address space. One of the prices they pay is the tradcerooute problem; another is that they are not able to address spaceific interfaces directly from the Internet. Some tell us that this is a feature and not a bug ;-). As always there is no answer/soloution that fits everyone. 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. > If the interface has a hidden IP# that you can send packets to, but it > still will present itself as (for instance) the ethernet interface, you > just give the ethernet interface a "normal" IP# and all looks normal and > the router only takes up one IP# (not counting RFC1918 address space) > This way you can still ping the interface on 10.0.0.1 . I am not sure I grok that. Daniel From David.Kessens at ripe.net Thu Jul 11 15:47:35 1996 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Thu, 11 Jul 1996 15:47:35 +0200 (MET DST) Subject: Announcement: new whois server in production+new features Message-ID: <9607111347.AA04807@voldragen.ripe.net> 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. ----- From zsako at banknet.net Fri Jul 12 12:13:10 1996 From: zsako at banknet.net (Janos Zsako) Date: Fri, 12 Jul 96 12:13:10 +0200 Subject: Please help: ptp links addresses Message-ID: <9607121013.AA18642@banknet.banknet.net> > From owner-lir-wg at ripe.net Thu Jul 11 23:01:33 1996 > From: Daniel Karrenberg 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 From alain at NetVision.net.il Sat Jul 13 20:39:23 1996 From: alain at NetVision.net.il (Alain Golan) Date: Sat, 13 Jul 1996 21:39:23 +0300 (IDT) Subject: Please help: ptp links addresses In-Reply-To: <9607121013.AA18642@banknet.banknet.net> Message-ID: 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 ? Regards, ___ ___ __ /__/ / /__/ / /\ / / / /__ / / _/_ / \/ o vox://+972-4-8560600 cel://+972-5-2593886 Alain at NetVision.net fax://+972-4-8550345 http://www.netvision.net.il/php/alain From Daniel.Karrenberg at ripe.net Mon Jul 15 13:53:33 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 15 Jul 1996 13:53:33 +0200 Subject: Please help: ptp links addresses In-Reply-To: Your message of Fri, 12 Jul 1996 12:13:10 +0200. <9607121013.AA18642@banknet.banknet.net> References: <9607121013.AA18642@banknet.banknet.net> Message-ID: <199607151153.LAA07825@kantoor.ripe.net> > zsako at banknet.net (Janos Zsako) writes: > ... 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. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I stand corrected. I was very much arguing the status quo and not the status expected by the RFC (and by myself when I wrote the passage you quote ;-). > I agree however that the answers from the other routers will give you in mo > st > of the cases enough information to figure out what route the packets take. Yep. From pab at cisco.com Tue Jul 23 18:47:31 1996 From: pab at cisco.com (Paolo Bevilacqua) Date: Tue, 23 Jul 1996 18:47:31 +0200 Subject: Please help: ptp links addresses Message-ID: <2.2.32.19960723164731.00692088@malcolm.rmnet.it> At 17:59 23/07/96 +0200, you wrote: > >>Date: Sat, 13 Jul 1996 21:39:23 +0300 (IDT) >>From: Alain Golan >>To: Janos Zsako >>Cc: robert at dk.net, lir-wg at 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 at 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 at cisco.com .???. .???. Tel: +39 (6) 58201230 "The net works, then ?" ..?????....?????.. Fax: +39 (6) 5020016 From David.Kessens at ripe.net Wed Jul 31 19:41:24 1996 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Wed, 31 Jul 1996 19:41:24 +0200 (MET DST) Subject: FYI: new database code in production Message-ID: <9607311741.AA26097@belegen.ripe.net> 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 ( 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 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 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 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 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