- lir-wg - mailman.ripe.net

list subscribe
by Serhat CAMLIDERE 28 Oct '96

28 Oct '96

list subscribe

1 0

list subscribe
by Marco Rinaudo 26 Oct '96

26 Oct '96

list subscribe

1 0

Minutes of LIR WG meeting at RIPE 25
by chachi＠arcc.or.ke 17 Oct '96

17 Oct '96

Below please find the minutes of the Local IR WG meeting last week; comments and corrections are welcome. I'm very grateful to Anne Lord for taking a full and accurate record of the proceedings, and to Janos Szako for presenting the WG report to the plenary in my absence. Mike Norris Local IR Working Group minutes RIPE 25: September 23rd, 1996 Nikhef, Amsterdam Chair: Mike Norris Scribe: Anne Lord 1. Preliminaries The chairman welcomed the audience to the working group session and Anne Lord (was) auto-volunteered as scribe. There were over 90 people present at the meeting of the working group. 2. RIPE 24 Minutes: The minutes from the previous working group meeting at RIPE 24 were approved without comment. Actions: All the actions below were completed and marked as DONE: Action 24.5 : complete ripe-104++ draft and circulate Action 24.6 : produce new IP address request form Action 24.7 : circulate paper on charging by local IR's Action 24.8 : raise question of removing European networks from InterNIC db. It was noted that in fact duplicate entries of European networks had now been removed from the InterNIC database. 3. Reports from Registries RIPE NCC It was noted that a full report from the RIPE NCC Registration Services Manager would be given at the plenary, so a report would be deferred until then. o Contributors committee The RIPE NCC Contributors committee met on 11th September 1996. At the meeting there was agreement on the proposed activity plan for the RIPE NCC for 1997. Of relevance for the local IR working group, the workplan included recommendations to hire additional hostmasters for the Registration Services activity of the RIPE NCC, operating under the new policy and procedures of ripe-104++ (now ripe-140). o Other registries There were no reports from other local IR's. o Other regionals There were no reports from any other Regional IR's. 4. IP address space assignment o Summary of position Several important documents were completed since the last meeting. These are: ftp://ftp.ripe.net/ripe/docs/ripe-140.{txt,ps} "European Internet Registry Policies & Procedures" ftp://ftp.ripe.net/ripe/docs/ripe-141.{txt,ps} "European IP Address Space Request Form" ftp://ftp.ripe.net/ripe/docs/ripe-142.{txt,ps} "Supporting Notes for the European IP Address Space Request Form" ripe-140 obsoletes a number of other documents: ripe-104, ripe-105 and ripe-136 and is the first document to describe in full the policies of the European Regional Internet Registry. Other Regional IR's follow the same principles of policy. o Some inconsistencies A number of inconsistencies between ripe-140 and ripe-141 have emerged. Notably : The admin-c, zone-c and tech-c attributes in the objects in ripe-140 requests a "nic-hdl" as mandatory but this is not endorsed by the DB software. The "status" attribute in the "inetnum" object in ripe-140 is mandatory but again this is not endorsed by the DB software. A short discussion followed whereby it was agreed to make both attributes mandatory. This was to be recommended to the DB working group for approval. 5. Charging by local IR's A draft paper by Mike Norris and Daniel Karrenberg on "Charging by local IR's" had now been circulated to the DNS working group mailing list and TLD's administrators. The paper was endorsed by the DNS working group and the group agreed that it should now be published as a RIPE document. The paper recommends that Local IR's should publish their policies with respect to the sale or not of both address and namespace. Action: RIPE NCC To publish paper on "charging by Local IR's" as a RIPE document. 6. Training o Training courses A report on the status of the training for local IR's will be reported in the Report from the RIPE NCC in the plenary session. Currently 2 courses per month are being run and there are no plans to reduce this frequency. It was noted that in the 1997 budget for the RIPE NCC, funds would continue to be available for the training of Internet registries. It was suggested by Antonio_Blasco Bonito that it would be useful to have the slides from the training courses converted into html format. This was agreed by the NCC providing they could find a convertor from framemaker to html. Action: RIPE NCC To convert slides from Local IR training courses to html format subject to finding a suitable mechanism for conversion from framemaker. o Local IR workshop There was no discussion under this point. 7. Input/output with other working groups o Database Recommendations will be made to the DB working group as reported under agenda point 4 "Some inconsistencies". o DNS The DNS wg endorses the charging document as reported under agenda point 5 "Charging by local IR's". There were no other comments as input our output from other working groups. 8. Global registry co-ordination Daniel Karrenberg reported that the RIPE NCC as a Regional IR has a good working relationship with the IANA and the other Regional IR's. ripe-140 has been published as a guideline to the policies in Europe, but there is implicit agreement on these policies by all other Regional RR's. He also reported that since the last meeting, all duplicate registration of networks in the InterNIC database for European networks have now been removed. Whilst the RIPE NCC and AP-NIC databases are synchronised as they use a common architecture, the InterNIC database does not and the work on the synchronisation between all RR's is held up by lack of resources at the InterNIC to devote to this. This is something that the RIPE NCC has no authority to do anything about. It was noted that the InterNIC database is now classless however. 9. Reverse domains o counts and errors The counts and errors of the hostcount are regularly published by the RIPE NCC. Reverse zone errors are monitored closely, with offenders receiving notification of their errors with a request to fix. Daniel Karrenberg commented that the 193.in-addr.apra and 194.in-addr.arpa zones are in fact quite well managed. Wilfried Woeber asked whether it was recommended that reverse domains objects were mandatory in the RIPE DB. Carol Orange noted that it was "recommended" for /24 reverse domain objects to be registered and "mandatory" for /16 reverse domain objects. 10. AOB Internet Registry Evolution (IRE) Daniel Karrenberg reported on a new IETF working group, IRE, which falls under the operations area of the IETF. In Montreal a BOF was held which was quite well attended. The chairman of the group is David Conrad from the AP-NIC and he has circulated a number of draft charters of the working group. Consensus is yet to be reached on the document. Broadly speaking the charter can be defined as: "discussing all aspects relating to the policies of Internet Registries and to channelise input from the IETF at large." The RIPE NCC will attend these working group meetings regularly and report at RIPE meetings. There is also a mailing list which you can subscribe to at <ire-request(a)apnic.net>. Everyone at the local IR working group was encouraged to join in the discussions. There was some discussion over the grey area between address space policies and namespace policies and how this fitted into the charter of the IRE working group. The RIPE NCC does not manage the allocation of namsespace as a RR but the InterNIC does. It was felt that the two should be kept as separate. Other o PIARA (Prices of Internet Addresses and Route Advertisements) Mike O'Dell introduced another new working group which is currently under discussion, PIARA. It is concerned with an initiative looking at ways of charging for address space. There has been a suggestion to make an experiment with charging and a draft paper has been circulated. AFRICAN REGIONAL CENTRE FOR COMPUTING NAIROBI KENYA

1 0

Minutes of LIR WG meeting at RIPE 25
by Mike Norris 03 Oct '96

03 Oct '96

Below please find the minutes of the Local IR WG meeting last week; comments and corrections are welcome. I'm very grateful to Anne Lord for taking a full and accurate record of the proceedings, and to Janos Szako for presenting the WG report to the plenary in my absence. Mike Norris Local IR Working Group minutes RIPE 25: September 23rd, 1996 Nikhef, Amsterdam Chair: Mike Norris Scribe: Anne Lord 1. Preliminaries The chairman welcomed the audience to the working group session and Anne Lord (was) auto-volunteered as scribe. There were over 90 people present at the meeting of the working group. 2. RIPE 24 Minutes: The minutes from the previous working group meeting at RIPE 24 were approved without comment. Actions: All the actions below were completed and marked as DONE: Action 24.5 : complete ripe-104++ draft and circulate Action 24.6 : produce new IP address request form Action 24.7 : circulate paper on charging by local IR's Action 24.8 : raise question of removing European networks from InterNIC db. It was noted that in fact duplicate entries of European networks had now been removed from the InterNIC database. 3. Reports from Registries RIPE NCC It was noted that a full report from the RIPE NCC Registration Services Manager would be given at the plenary, so a report would be deferred until then. o Contributors committee The RIPE NCC Contributors committee met on 11th September 1996. At the meeting there was agreement on the proposed activity plan for the RIPE NCC for 1997. Of relevance for the local IR working group, the workplan included recommendations to hire additional hostmasters for the Registration Services activity of the RIPE NCC, operating under the new policy and procedures of ripe-104++ (now ripe-140). o Other registries There were no reports from other local IR's. o Other regionals There were no reports from any other Regional IR's. 4. IP address space assignment o Summary of position Several important documents were completed since the last meeting. These are: ftp://ftp.ripe.net/ripe/docs/ripe-140.{txt,ps} "European Internet Registry Policies & Procedures" ftp://ftp.ripe.net/ripe/docs/ripe-141.{txt,ps} "European IP Address Space Request Form" ftp://ftp.ripe.net/ripe/docs/ripe-142.{txt,ps} "Supporting Notes for the European IP Address Space Request Form" ripe-140 obsoletes a number of other documents: ripe-104, ripe-105 and ripe-136 and is the first document to describe in full the policies of the European Regional Internet Registry. Other Regional IR's follow the same principles of policy. o Some inconsistencies A number of inconsistencies between ripe-140 and ripe-141 have emerged. Notably : The admin-c, zone-c and tech-c attributes in the objects in ripe-140 requests a "nic-hdl" as mandatory but this is not endorsed by the DB software. The "status" attribute in the "inetnum" object in ripe-140 is mandatory but again this is not endorsed by the DB software. A short discussion followed whereby it was agreed to make both attributes mandatory. This was to be recommended to the DB working group for approval. 5. Charging by local IR's A draft paper by Mike Norris and Daniel Karrenberg on "Charging by local IR's" had now been circulated to the DNS working group mailing list and TLD's administrators. The paper was endorsed by the DNS working group and the group agreed that it should now be published as a RIPE document. The paper recommends that Local IR's should publish their policies with respect to the sale or not of both address and namespace. Action: RIPE NCC To publish paper on "charging by Local IR's" as a RIPE document. 6. Training o Training courses A report on the status of the training for local IR's will be reported in the Report from the RIPE NCC in the plenary session. Currently 2 courses per month are being run and there are no plans to reduce this frequency. It was noted that in the 1997 budget for the RIPE NCC, funds would continue to be available for the training of Internet registries. It was suggested by Antonio_Blasco Bonito that it would be useful to have the slides from the training courses converted into html format. This was agreed by the NCC providing they could find a convertor from framemaker to html. Action: RIPE NCC To convert slides from Local IR training courses to html format subject to finding a suitable mechanism for conversion from framemaker. o Local IR workshop There was no discussion under this point. 7. Input/output with other working groups o Database Recommendations will be made to the DB working group as reported under agenda point 4 "Some inconsistencies". o DNS The DNS wg endorses the charging document as reported under agenda point 5 "Charging by local IR's". There were no other comments as input our output from other working groups. 8. Global registry co-ordination Daniel Karrenberg reported that the RIPE NCC as a Regional IR has a good working relationship with the IANA and the other Regional IR's. ripe-140 has been published as a guideline to the policies in Europe, but there is implicit agreement on these policies by all other Regional RR's. He also reported that since the last meeting, all duplicate registration of networks in the InterNIC database for European networks have now been removed. Whilst the RIPE NCC and AP-NIC databases are synchronised as they use a common architecture, the InterNIC database does not and the work on the synchronisation between all RR's is held up by lack of resources at the InterNIC to devote to this. This is something that the RIPE NCC has no authority to do anything about. It was noted that the InterNIC database is now classless however. 9. Reverse domains o counts and errors The counts and errors of the hostcount are regularly published by the RIPE NCC. Reverse zone errors are monitored closely, with offenders receiving notification of their errors with a request to fix. Daniel Karrenberg commented that the 193.in-addr.apra and 194.in-addr.arpa zones are in fact quite well managed. Wilfried Woeber asked whether it was recommended that reverse domains objects were mandatory in the RIPE DB. Carol Orange noted that it was "recommended" for /24 reverse domain objects to be registered and "mandatory" for /16 reverse domain objects. 10. AOB Internet Registry Evolution (IRE) Daniel Karrenberg reported on a new IETF working group, IRE, which falls under the operations area of the IETF. In Montreal a BOF was held which was quite well attended. The chairman of the group is David Conrad from the AP-NIC and he has circulated a number of draft charters of the working group. Consensus is yet to be reached on the document. Broadly speaking the charter can be defined as: "discussing all aspects relating to the policies of Internet Registries and to channelise input from the IETF at large." The RIPE NCC will attend these working group meetings regularly and report at RIPE meetings. There is also a mailing list which you can subscribe to at <ire-request(a)apnic.net>. Everyone at the local IR working group was encouraged to join in the discussions. There was some discussion over the grey area between address space policies and namespace policies and how this fitted into the charter of the IRE working group. The RIPE NCC does not manage the allocation of namsespace as a RR but the InterNIC does. It was felt that the two should be kept as separate. Other o PIARA (Prices of Internet Addresses and Route Advertisements) Mike O'Dell introduced another new working group which is currently under discussion, PIARA. It is concerned with an initiative looking at ways of charging for address space. There has been a suggestion to make an experiment with charging and a draft paper has been circulated.

1 0

RIPE Database Workshop
by Carol Orange 20 Aug '96

20 Aug '96

W O R K S H O P A N N O U N C E M E N T R I P E D A T A B A S E 2.0 ------------------------------ MONDAY, SEPTEMBER 23, 1996 9.00 - 12.00 In conjunction with the 25th RIPE Meeting to be held at the Nikhef Institute in Amsterdam, the RIPE NCC will hold a workshop in which the features of the new release of the RIPE Database package will be introduced. The workshop will be held at the RIPE meeting location. Topics to be covered in the workshop include: + Hierarchical authorization + Automatic NIC-handle mechanism + Role objects + Classless update and lookup mechanisms + Reverse lookup of objects + Near real time mirroring Where applicable, examples will be used to illustrate how the features above can best be employed. Common questions regarding the use of each feature will also be discussed. Time will be reserved to address the questions of workshop attendees. The test database will be set up during the meeting with the examples covered in the workshop. Attendees can try things out during the RIPE meeting, and address any questions that may arise to RIPE NCC database support staff. Note that the content of the workshop is distinct from that of the Database WG meeting. The workshop will be of a tutorial nature describing how to work with the new database features. Priorities for further developments will be addressed in the WG as always. REGISTRATION The workshop is open to all members of the RIPE community. Attendees from RIPE NCC contributors will however receive priority. If you plan to attend, please register, using the form at the end of this message, as soon as possible, but before September 16th. This will allow proper planning of workshop logistics. Those who do not register in advance may be turned away if space restrictions arise. Upon completion, send the form should to: <meeting(a)ripe.net> %START PART 1 - Registration %MTG [ dbws1 ] 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton %NAME [ ] 2) Your Organisation/Institution %ORG [ ] 3) Your e-mail address %EMAIL [ ] 4) Registtry ID The registry ID string of the local IR (if any) e.g. fr.lereseau de.dasnetz uk.thenet. Contributing local IRs will receive priority registration. %REGID [ ] %END

1 0

Newest patches: ripe-dbase.2.0.3 available
by David.Kessens＠ripe.net 19 Aug '96

19 Aug '96

Dear all, The latest release unexpectedly contained a serious flaw in the classless database opening code. The problem was not found before putting things in production due to a non-complete copy of one file into the test database directory (my fault). The new database staff did some emergency measures and consulted me on the phone (The moving company was just packing my computers & modems ;-(). An older version was put back in production which caused the reappearing of some (non fatal) bugs. I want to apologize for the inconvenience this has caused although I hope that you also have some understanding: We were the last three weeks in the inconvenient position that we had to put new code in production while not having the time for an appropriate test period. Postponing the release was not a viable option since I was leaving the RIPE NCC (In fact I already did two weeks ago...), the new people first need some time to get up to speed, and I saw clear signs (in the internals of the database) that we rather should handle fast then slow with introducing the new software. I have prepared a new bug fixed version that also fixes a few other problems (including some older bugs that were already present in the previous release). This version runs now since friday afternoon on our production machine (note the subtle change in the config file: the 'av' attribute added in the 'OBJ an ATSQ' line). The code is available from: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase.2.0.3.tar.gz Kind regards, David K. ---

2 1

FYI: new database code in production
by David.Kessens＠ripe.net 31 Jul '96

31 Jul '96

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

1 0

Re: Please help: ptp links addresses
by Paolo Bevilacqua 23 Jul '96

23 Jul '96

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

1 0

Re: Please help: ptp links addresses
by zsako＠banknet.net 15 Jul '96

15 Jul '96

> 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

3 2

Announcement: new whois server in production+new features
by David.Kessens＠ripe.net 11 Jul '96

11 Jul '96

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. -----

1 0