- db-wg - mailman.ripe.net

Deprecating auth=NONE
by Hank Nussbacher 15 Apr '03

15 Apr '03

Back in March 2002 we started to deprecate auth=MAIL-FROM. In August we finished it: http://www.ripe.net/ripencc/pub-services/db/mailfrom.html We did not do the same for auth=NONE and the RIPE announcement stated: "Though NONE "auth" scheme is even weaker it is not supposed to be consciously used for object protection, but rather as notification facility. Therefore NONE "auth" scheme is outside the scope of this proposal." It has come lately to the attention in the Internet security realm that spammers as well as crackers are hijacking IP address space. One easy way to "steal" IP address space is via those that have auth=NONE on their objects. Go to: http://www.ripe.net/db/whois-free.html select ALL and type in the search bar "auth: none". The results of those that can have their IPs easily hijacked is, how shall I say this, enormous. Luckily the RIPE search form is limited to 100 hits. Just as an example and not to pick on C&W but: aut-num: AS13186 as-name: UNSPECIFIED descr: C&W SA Autonomous System descr: Alcalde Barnils 64-68 descr: Parque Empresarial Sant Joan descr: 08190 Sant Cugat del Valles descr: BARCELONA import: from AS3352 action pref=100; accept ANY import: from AS12541 action pref=100; accept ANY import: from AS3561 action pref=100; accept ANY import: from AS16091 action pref=100; accept AS16091 export: to AS3352 announce AS13186 AS16091 export: to AS12541 announce AS13186 AS16091 export: to AS3561 announce AS13186 AS16091 export: to AS16091 announce ANY default: to AS12541 action pref=100; networks ANY admin-c: RV4415-RIPE tech-c: XL5-RIPE remarks: AS3352 -> anvazque@obscured-domain remarks: AS12541 ->graham.cole@obscured-domain mnt-by: AS13186-MNT mntner: AS13186-MNT descr: Cable and Wireless SA admin-c: RV4415-RIPE tech-c: XL5-RIPE upd-to: d12@obscured-domain auth: NONE mnt-by: AS13186-MNT referral-by: RIPE-DBM-MNT route: 212.66.160.0/19 descr: Intercom Servicios Telematicos Avanzados, S.A. origin: AS13186 notify: xlario@obscured-domain mnt-by: AS13186-MNT I could right now remove the route entry for 212.66.160.0/19 or change it to some other origin and thereby hijack the entry. All those that use auto-build tools based on the info in RIPE would allow me to announce the /19 and not C&W in Spain. Just an example. There are thousands. RIPE NCC won't deprecate auth=NONE without us telling them to do it. Why would we not want this? -Hank

1 0

Problems with RipeWhois.pm
by Arnd Vehling 28 Mar '03

28 Mar '03

Hi All, i am experiencing the following problem with the RipeWhois perl modul supplied with asused-3.65 / $Id: RipeWhois.pm,v 1.4 2001/04/18 17:01:20 timur Exp $ The "RipeWhois" function only works as long as i have the environment variables WHOIS_HOST set. If i unset the var the function stops working. I verified that with the supplied test client "cwhois". All command-line parameters and in-script defaults are ignored. OS is Solaris, perl version is: v5.6.1 Any Ideas? best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av(a)nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Köln Fax : +49 221 8809212

1 1

Ref: Abuse contact
by Wilfried Woeber, UniVie/ACOnet 27 Mar '03

27 Mar '03

>To: s.willing(a)mops.net >CC: anti-spam-wg(a)ripe.net >From: RIPE Database Manager <ripe-dbm(a)ripe.net> >Date: Tue, 25 Mar 2003 10:07:29 +0100 >Subject: [anti-spam-wg(a)ripe.net] Re: NCC#2003034446 Abuse contact > >Dear Sebastian, > >Any changes to database schemas are decided upon in >RIPE Database Working Group, Yes, in principle, but as a matter of fact we prefer requests for object creations or modifications to come in from the "user base" (including a rough blueprint :-), i.e. the appropriate RIPE WG(s). >which is an open working >group. It has a mailing list. You can subscribe to it >and present your proposal there, for the review of other >members of the WG. Its web page is: > >http://www.ripe.net/ripe/wg/db/index.html In this particular case I'd expect (at least) Anti-SPAM to discuss any deployment scenarios, before we go ahead and modifify objects. As a personal note - I tend to think the IRT object might be a better place to put such stuff. Because the IP-address management role(s), being more administartive, often do not have close links to abuse or incident roles within an ISP. >If you have any more questions, please don't hesitate >to contact <ripe-dbm(a)ripe.net>. > >Regards, > >Engin Gunduz >____________________________ >RIPE Database Administration. Cheers, Wilfried (RIPE DB-WG Chair) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Tue, 25 Mar 2003 09:53:28 +0100 (CET), S Willing wrote: * Hello! * * Some RIPE entries already include abuse information, but not in a uniform type. * * Arin has some extra abuse contact attributes: * OrgAbuseHandle: ABUSE23-ARIN * OrgAbuseName: Abuse * OrgAbusePhone: +1-800-436-8489 * OrgAbuseEmail: abuse(a)genuity.com * * I'ld like to suggest a new RIPE-DB attribute: "abuse-mail". * * It should be required for every new allocation and optional for assignments. * Somewhere in the future, the whois server should automatically return the * most-specific "abuse-mail"-entry which exists. * For example: 10.1.0.0/16 allocation has an "abuse-mail"-entry, but * 10.1.2.0/25 has none. In this case, the entry from the allocation * is returned. * 10.1.3.128/26 has an own "abuse-mail"-entry which is returned if * someone queries this object. * * MfG / Regards, * S.Willing * * ************************************************************************ * M / W / S Sebastian Willing * http://www.mops.net Technical director * Telefon: 01803/684310578 e-Mail: s.willing(a)mops.net * Telefax: 01805/445169111 SW88-RIPE * ************************************************************************ * --------------------------------------------------------------------------------

1 0

Mirroring of LEVEL3 database
by Koepp, Karsten 12 Mar '03

12 Mar '03

Hello around, does anyone besides me consider the Level (3) IRR database useful to be mirrored? I can find the Level(3) data on whois.ra.net but I would like to continue using whois.ripe.net. I understand the db admins position but I consider this source valuable. I have no statistics on the number of objects - I just happen to meet source LEVEL3 now and then. Karsten > Dear Karsten.Koepp, > > Regarding you question about the RIPE NCC mirroring the LEVEL > 3 database, > we currently have no plans on doing that as we were not requested by > LEVEL 3 to carry a mirror of their data. > > Our requirements for mirroring are: > 1. The source is a public IRR > 2. It should have considerable size > 3. It should be useful for the users in the RIPE region > > We don't seek out databases to mirror, although if a number > of our users > think that it can be useful we can ask permission for that. > > Best Regards, > Tiago Antao > ---------------------------- > RIPE Database Administration >

2 1

Proposed change 2003.1: notification for more-specific
by Shane Kerr 10 Mar '03

10 Mar '03

Colleagues, This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users. Please have a look, and discuss it here. [2003.1] Notification on more-specific object creation authorisation -------------------------------------------------------------------- Change: When the creation of an object requires authorisation by a less-specific object, normal mntner notification will apply; "upd-to:" is notified of failure, and "mnt-nfy:" is notified of success. Where there are multiple maintainers, only one is needed to successfully authorise the creation, but all the maintainers in the list will be notified. For example: inetnum: 192.168.101.0 - 192.168.101.255 . . . mnt-by: EXAMPLE-MNT mnt-lower: ANOTHER-MNT mnt-lower: YET-ANOTHER-MNT If the successful creation of the more specific inetnum: inetnum: 192.168.201.0 - 192.168.201.255 . . . mnt-by: SOME-MNT Is authorised by YET-ANOTHER-MNT in the less specific inetnum, notifications will be sent to the "mnt-nfy:" listed in both ANOTHER-MNT and YET-ANOTHER-MNT. Motivation: This is useful for two cases. The first is so that the maintainer of an object will be notified when unauthorised attempts to create objects occur and will receive confirmation when objects are successfully created. The second is for cases where there are multiple maintainers in a position to authorise a creation (as in the example above). The maintainers that did not specificially authorise the creation are still notified (this is how notification for updates works today). -- Shane Kerr RIPE NCC

4 5

Proposed change 2003.3: "reclaim:"-like functionality
by Shane Kerr 10 Mar '03

10 Mar '03

Colleagues, This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users. Please have a look, and discuss it here. [2003.3] Implementation of "reclaim:"-like functionality -------------------------------------------------------- Proposal: Any maintainer that would have been able to authorise the creation of an object can authorise the deletion of the same object. If creation of an object requires authorisation from multiple maintainers (e.g. route objects that require authorisation from an aut-num and an inetnum), then any of those maintainers may authorise the deletion. Motivation: The maintainer of an object is responsible for insuring that the data in the object is accurate. For hierarchical objects the maintainer can delegate responsibility for a subset. However, under the current implementation, there is no way for the maintainer to delete objects created and delegated to maintainers who should not or will not have access to the resources represented by these objects any more. For example, if the holder of portable address space changes ISP, then the address space will be advertised from a different AS. This means that the old route object is invalid and should be deleted. However, if the old ISP maintains the object, then the holder of the space has no way to delete the old object. This old route object will prevent the creation of a new route object that represents the new arrangement. The "reclaim:" attribute defined in RPSS allows for very similar functionality, but it may not be added to space that already has objects. This means that any existing more-specific objects cannot be deleted by the maintainers of the less-specific objects. For the case of old objects - the ones most likely to need such deletion - this means that the "reclaim:" attribute does not help. The "reclaim:" attribute also has a different syntax, depending on the specific object type that it is present in. This complicates parsing of objects. -- Shane Kerr RIPE NCC

3 3

Another Proposal: Sort of generated Authorized-by Attribute + some PGP stuff
by Ulrich Kiermayr 04 Mar '03

04 Mar '03

Hi List, Since Shane has posted some proposals for the RIPE-DB, I have another one: For Updates which have been authorized by someone using strong encryption it would be nice to reflect the key that has been used in the object. this is similar to the changed: attribute but should be generated by the robot and not filled in by the user. Why? At the moment there is no way to tell that data within the Database is authentic in a way that it was really put in by the person who is in the object (pls. correct me if I am wrong), and the mnt-* just prevents you from stealing an object and not from giving it away to pretend something. Usually this is not bad, but related to some irt-stuff it can give the people the opportunity to pretend to be someone else. If the authorizing key was reflected in the object, one can check if who sent the update.... Something else related to PGP (and discussed with wilfried a while ago): it would be really nice to be able to link key-certs and persons/roles together other than by using remarks.... (as we do it now). lG uk -- ------------------------------------------------------------------------ Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network Security Universitaetsstrasse 7, 1010 Wien, Austria ------------------------------------------------------------------------ eMail: ulrich.kiermayr(a)univie.ac.at Tel: (+43 1) 4277 / 14104 Hotline: security.zid(a)univie.ac.at Fax: (+43 1) 4277 / 9140 ------------------------------------------------------------------------ GPG Key fingerprint = BF0D 5749 4DC1 ED74 AB67 7180 105F 491D A8D7 64D8

1 0

Proposed change 2003.4: "mnt-lower:" on set objects
by Shane Kerr 04 Mar '03

04 Mar '03

Colleagues, This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users. Please have a look, and discuss it here. [2003.4] Addition of "mnt-lower:" to set objects ------------------------------------------------ Change: The "mnt-lower:" attribute will be optional for all set object types, which are as-set, filter-set, peering-set, route-set, and rtr-set. The "mnt-lower:" must authorise creation when hierarchical names are used. If it is not present, "mnt-by:" must authorise the creation. Motivation: The set objects in RPSL allow hierarchical names. The rules for authorising creation of such an object is documented in RPSS, and specifies that when an AS is used in the name, "mnt-lower:" on the aut-num object may authorise the creation, otherwise "mnt-by:" of the aut-num is used. In this case: as-set: AS1:AS-foo If AS1 had a "mnt-lower:" attribute, the maintainer listed there would have to authenticate the creation, otherwise the "mnt-by:" of AS1 would be used. This allows the administrator of an aut-num to delegate authority to create sets to maintainers without having to allow them to modify the aut-num itself. This functionality is not present within the set classes themselves. For example: as-set: AS1:AS-Foo:AS-Bar If AS1:AS-Foo object is allowed to have the "mnt-lower:" attribute, a maintainer that can create AS1:AS-Foo:AS-Bar but not modify AS1:AS-Foo can be used. -- Shane Kerr RIPE NCC

1 0

Proposed change 2003.2: removal of cross notifications
by Shane Kerr 04 Mar '03

04 Mar '03

Colleagues, This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users. Please have a look, and discuss it here. [2003.2] Removal of cross notifications in the routing registry --------------------------------------------------------------- Proposal: Deprecate cross notifications. This means removing "cross-mnt:" and "cross-nfy:" attributes from aut-num or route objects with them (150 and 555 of each, respectively). Motivation: Currently cross notifications provide a redundant facility now fully implemented by RPSL authorisation. Also, current implementation sends notifications to every possible overlapping route (-L + -M), which is not very consistent with RPSL hierarchical authorisation scheme. -- Shane Kerr RIPE NCC

1 0

Proposed change 2003.0: default to protected inetnum/inet6num/domain
by Shane Kerr 04 Mar '03

04 Mar '03

Colleagues, This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users. Please have a look, and discuss it here. [2003.0] Default to protected for inetnum, inet6num, and domain objects ----------------------------------------------------------------------- Change: All hierarchical object types will now default to requiring authorisation for more-specific object creation. Motivation: In RPSS, objects use "mnt-lower:" to specify a maintainer which has the ability to authorise the creation more-specific objects. If a "mnt-lower:" attribute is not present, then the "mnt-by:" of the less-specific object is used. For example: route: 192.168.100.0/24 origin: AS1 mnt-by: EXAMPLE-MNT mnt-lower: ANOTHER-MNT . . . Authorisation for creation of a more-specific route must be given by ANOTHER-MNT. inetnum: 192.168.200.0/24 origin: AS1 mnt-by: EXAMPLE-MNT . . . Authorisation for creation of a more-specific route must be given by EXAMPLE-MNT (in the absence of an exact match or less specific route object). For object types not defined in RPSS, the current behaviour is as defined in RIPE-181. This includes inetnum, inet6num, and domain objects. In RIPE-181 if no "mnt-lower:" attribute is present, then requests to create more-specific objects require no authorisation from the less-specific inetnum. The proposal is to bring this into line with the new default. For example: inetnum: 192.168.101.0 - 192.168.101.255 mnt-by: EXAMPLE-MNT mnt-lower: ANOTHER-MNT . . . Authorisation for creation of a more-specific inetnum must be given by ANOTHER-MNT. inetnum: 192.168.201.0 - 192.168.201.255 mnt-by: EXAMPLE-MNT . . . Authorisation for creation of a more-specific inetnum does NOT currently require authorisation by EXAMPLE-MNT. The proposed change would require authorisation by EXAMPLE-MNT. -- Shane Kerr RIPE NCC

1 0

RIPE NCC network affected by the DDoS attack
by Andrei Robachevsky 27 Feb '03

27 Feb '03

Dear Colleagues, Starting from 14:00 UTC today, 27 February, RIPE NCC network suffered a large DDoS attack. It was a distributed ICMP echo attack. The attack caused various congestion related problems for the RIPE NCC's network, to the extent that our BGP peering sessions were affected, and non-ICMP traffic was being randomly dropped. The attack was successfully mitigated with cooperation of our peer networks at AMS-IX. Network condition returned back to normal at 16:30 UTC. As a result some of our services, including www.ripe.net (web), whois.ripe.net (RIPE Database), ns.ripe.net (DNS) and ftp.ripe.net (FTP) were not accessible during this timeframe. Now all services are back to normal. Regards, Andrei Robachevsky CTO, RIPE NCC

1 0

route aggregation and RFC2725
by Frank Bohnsack 18 Feb '03

18 Feb '03

Dear colleagues, we have three side by side "assigned PI" inetnum blocks 193.17.60.0/24, 193.17.61.0/24 and 193.17.62.0/23. To reduce routing table space we want to create only one aggegated route for these blocks instead of three seperated. But the authentication process of RFC2725 does checks exact or less specific routes or inetnums only and will go wrong in this case. My question: Is this a known/proposed "feature" or should we think about a modification of the authentication process of RFC2725 to support this case? Thanks Frank fb@OC3 20> whoisRIP -r -M 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.17.62.0 - 193.17.63.255 netname: HOFMANN-LAN descr: Enno Hofmann descr: D-58089 Hagen country: DE admin-c: EHO-RIPE tech-c: EHO-RIPE tech-c: EHO-RIPE rev-srv: auth04.ns.de.uu.net rev-srv: auth54.ns.de.uu.net status: ASSIGNED PI notify: eho(a)de.uu.net mnt-by: UUNETDE-I mnt-by: HOFMANN-MNT mnt-lower: HOFMANN-MNT changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921216 changed: eho(a)de.uu.net 19991008 changed: eho(a)de.uu.net 20020621 source: RIPE inetnum: 193.17.61.0 - 193.17.61.255 netname: GSD-HH descr: GSD Berlin descr: - Geschaeftsstelle Hamburg - descr: D-W-2000 Hamburg 53 country: DE admin-c: JA1966-RIPE tech-c: RG2666-RIPE tech-c: MF3386-RIPE mnt-by: UUNETDE-I status: ASSIGNED PI changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921015 changed: hostmaster(a)de.uu.net 20020205 changed: eho(a)de.uu.net 20020807 source: RIPE inetnum: 193.17.60.0 - 193.17.60.255 netname: GSD-BLN descr: GSD descr: D-10785 Berlin country: DE admin-c: JL15-RIPE tech-c: TM2554-RIPE status: ASSIGNED PI mnt-by: UUNETDE-I changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921015 changed: eho(a)de.uu.net 20020807 source: RIPE route: 193.17.62.0/23 descr: HOFMANN-LAN origin: AS702 member-of: RS-UUNETEUDE mnt-by: UUNET-MNT changed: eho(a)de.uu.net 20020611 source: RIPE fb@OC3 21> whoisRIP -r -l 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.16.0.0 - 193.31.255.255 netname: EU-ZZ-930921 descr: block for PI assignments maintained by RIPE NCC former address space of de.zz country: EU admin-c: CREW-RIPE tech-c: CREW-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: marten(a)ripe.net 19930921 changed: hostmaster(a)ripe.net 20020621 source: RIPE

2 1

route aggregation and RFC2725
by Frank Bohnsack 18 Feb '03

18 Feb '03

Dear colleagues, we have three side by side "assigned PI" inetnum blocks 193.17.60.0/24, 193.17.61.0/24 and 193.17.62.0/23. To reduce routing table space we want to create only one aggegated route for these blocks instead of three seperated. But the authentication process of RFC2725 does checks exact or less specific routes or inetnums only and will go wrong in this case. My question: Is this a known/proposed "feature" or should we think about a modification of the authentication process of RFC2725 to support this case? Thanks Frank fb@OC3 20> whoisRIP -r -M 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.17.62.0 - 193.17.63.255 netname: HOFMANN-LAN descr: Enno Hofmann descr: D-58089 Hagen country: DE admin-c: EHO-RIPE tech-c: EHO-RIPE tech-c: EHO-RIPE rev-srv: auth04.ns.de.uu.net rev-srv: auth54.ns.de.uu.net status: ASSIGNED PI notify: eho(a)de.uu.net mnt-by: UUNETDE-I mnt-by: HOFMANN-MNT mnt-lower: HOFMANN-MNT changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921216 changed: eho(a)de.uu.net 19991008 changed: eho(a)de.uu.net 20020621 source: RIPE inetnum: 193.17.61.0 - 193.17.61.255 netname: GSD-HH descr: GSD Berlin descr: - Geschaeftsstelle Hamburg - descr: D-W-2000 Hamburg 53 country: DE admin-c: JA1966-RIPE tech-c: RG2666-RIPE tech-c: MF3386-RIPE mnt-by: UUNETDE-I status: ASSIGNED PI changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921015 changed: hostmaster(a)de.uu.net 20020205 changed: eho(a)de.uu.net 20020807 source: RIPE inetnum: 193.17.60.0 - 193.17.60.255 netname: GSD-BLN descr: GSD descr: D-10785 Berlin country: DE admin-c: JL15-RIPE tech-c: TM2554-RIPE status: ASSIGNED PI mnt-by: UUNETDE-I changed: cp(a)deins.Informatik.Uni-Dortmund.DE 19921015 changed: eho(a)de.uu.net 20020807 source: RIPE route: 193.17.62.0/23 descr: HOFMANN-LAN origin: AS702 member-of: RS-UUNETEUDE mnt-by: UUNET-MNT changed: eho(a)de.uu.net 20020611 source: RIPE fb@OC3 21> whoisRIP -r -l 193.17.60.0/22 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 193.16.0.0 - 193.31.255.255 netname: EU-ZZ-930921 descr: block for PI assignments maintained by RIPE NCC former address space of de.zz country: EU admin-c: CREW-RIPE tech-c: CREW-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: marten(a)ripe.net 19930921 changed: hostmaster(a)ripe.net 20020621 source: RIPE

1 0

Announcement RIPE NCC RRC Training Course
by RIPE NCC Training 17 Feb '03

17 Feb '03

Dear Colleagues, [apologies for duplicate postings] As a new service to its members the RIPE NCC offers the "Routing Registry Training Course". The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT describe how to receive Internet resources from the RIPE NCC not describe to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The Routing Registry Training Course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the Routing Registry Training Course can be found at: http://www.ripe.net/training/rr/ REGISTRATION: You can register for a Routing Registry Training Course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> . In order to register for a Routing Registry Training Course you must be an employee of an LIR and either: - be an LIR contact - be confirmed by an LIR contact LIR contacts are those employees of an LIR who are registered with RIPE NCC as authoritative contact persons. It is expected that most of those interested in the Routing Registry Training Course will not be an authoritative contact person for their LIR, and therefore will be, refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, The RIPE NCC Training Team ----------------------------------------------------------------------- COURSE DATES AND VENUES ======================== Date: Monday 14 April 2003 Time: 0900 - 1700 Location: Amsterdam, The Netherlands AND: Date: Friday 20 June 2003 Time: 0900 - 1700 Location: Kiev, Ukraine ------------------------------------------------------------------------ REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

syncupdates source code release
by RIPE Database Administration 11 Feb '03

11 Feb '03

[apologies for duplicate messages] Dear Colleagues, We are happy to announce the syncupdates source code release. The release contains: - syncupdates, infrastructure facility to update the Whois server online and synchronously. - webupdates, web based graphical interface for updating objects. The software is available at ftp://ftp.ripe.net/ripe/dbase/software/syncupdates-1.0.1.tar.gz Please contact dbtools(a)ripe.net for any comments. Best regards, -- Can Bican DB Group RIPE NCC

1 0

hint: IPv6 whois presentation in IPv6 WG (only)
by Wilfried Woeber, UniVie/ACOnet 28 Jan '03

28 Jan '03

Dear DB-WG, to avoid duplicating effort in various WGs, there is a presentation about the IPv6 capabilities of the NCC's whois service scheduled in the IPv6 WG _only_. We do _not_ plan to repeat that in DB-WG - although I'd like to add a minor item to the DB agenda to _start_ a "review" activity on IPv6 facilities for the whole machinery. Bottom line: if you are interested in v6 whois - pls. go to IPv6; if you are interested in v6 DB stuff in general - stop by at DB :-) Wilfried. ______________________________________________________________________ Date: Tue, 28 Jan 2003 12:58:33 +0100 From: Andrei Robachevsky <andrei(a)ripe.net> [ ... ] Dear Wilfried, My own opinion: [ ... ] - ipv6 in the DB. Shane is making a presentation on ipv6 whois server (the proxy we put online) This can be replicated at the DB meeting. [ ... ] Thanks, Andrei -- Andrei Robachevsky CTO, RIPE NCC --------------------------------------------------------------------------------

1 0

IPV6 Whois
by DB-News 27 Jan '03

27 Jan '03

[apologies for duplicate messages] Dear Colleagues, We are happy to announce the availability of RIPE Whois servers on IPv6 network. It is now possible to query whois.ripe.net and test-whois.ripe.net from an IPv6 host, using an IPv6 enabled whois client. If your system doesn't already have one, you can find the latest RIPE Whois client at: ftp://ftp.ripe.net/ripe/tools/ripe-whois-latest.tar.gz You can read the full anouncement at: http://www.ripe.net/ripencc/pub-services/db/whois-ipv6.html Best regards, -- Can Bican Database Group RIPE NCC

3 3

Organisation object proposal
by Shane Kerr 26 Jan '03

26 Jan '03

Colleagues, Attached please find a proposal for adding the organisation object type to the RIPE Database. As always, discussion about the document can be done on this mailing list. There will be a brief presentation at the RIPE meeting next week about organisation objects. -- Shane Kerr RIPE NCC

5 4

IPv6 Whois update
by Shane Kerr 23 Jan '03

23 Jan '03

Colleagues, As you may have seen on the list, there were a few reachability problems with the new IPv6 Whois service. We believe these are configuration related, and have a workaround allowing queries to WHOIS.RIPE.NET to work while we research it further. If you have network issues with this service please e-mail <ripe-dbm(a)ripe.net>. We also have heard some problems people are having with their Whois clients giving them errors querying the RIPE Whois server. These can occur in the case that: - The Whois client has IPv6 support. - The host computer does not have working IPv6 support. The client will: 1. Get the AAAA record for WHOIS.RIPE.NET. 2. Try to connect to the IPv6 address. 3. Fail because there is no IPv6 stack/address/router/etc. If you are experiencing this problem, you may be able to fix it by enabling IPv6 on your host (so that the IPv6 queries work), disabling IPv6 *completely* on your host (so that no AAAA records are returned), or by using another Whois client. The RIPE Whois client will work in this case, and is available from our FTP site: ftp://ftp.ripe.net/tools/ripe-whois-latest.tar.gz -- Shane Kerr RIPE NCC

3 2

RE: [ipv6-wg@ripe.net] IPV6 Whois
by matthew.ford＠bt.com 23 Jan '03

23 Jan '03

I'm getting Type 1 (Unreachable) Code 1 (Administratively Prohibited) messages back from 2001:7f8:1::a500:3333:1 - luckily the client falls back to IPv4 and that works just fine ;-) Mat. > -----Original Message----- > From: Pim van Pelt [mailto:pim@ipng.nl] > Sent: 23 January 2003 14:17 > To: ripe-dbm(a)ripe.net > Cc: db-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: [ipv6-wg(a)ripe.net] IPV6 Whois > > > | We are happy to announce the availability of RIPE Whois > servers on IPv6 > | network. It is now possible to query whois.ripe.net and > test-whois.ripe.net > | from an IPv6 host, using an IPv6 enabled whois client. If > your system doesn't > | already have one, you can find the latest RIPE Whois client at: > Hi Can, > > I cannot reach the server from AS12859, nor from AS8954. > > --- whois.ripe.net ping6 statistics --- > 2 packets transmitted, 0 packets received, 100% packet loss > > A traceroute from me (2001:7b8:3:17:202:b3ff:fe10:d926) to you gives: > 1 dapje-gw.ipv6.network.bit.nl 0.383 ms 0.286 ms 0.269 ms > 2 jun1.telecity.ipv6.network.bit.nl 1.537 ms 1.552 ms 1.505 ms > 3 nikipv6.ripe.net 3.378 ms 3.035 ms 3.111 ms > 4 nikipv6.ripe.net 4.432 ms !P 3.248 ms !P 3.288 ms !P > > And telnetting to port 43 of whois.ripe.net does not do much: > $ telnet 2001:610:240:0:193::135 whois > Trying 2001:610:240:0:193::135... > ^C > > Please advise. > -- > ---------- - - - - -+- - - - - ---------- > Pim van Pelt Email: pim(a)ipng.nl > http://www.ipng.nl/ IPv6 Deployment > ----------------------------------------------- > >

1 0

RRCC scripts beta release
by DB-News 23 Jan '03

23 Jan '03

[apologies for duplicate messages] Dear Colleagues, We are happy to announce the beta release of RRCC scripts. Routing Registry Consistency Check, or RRCC project had already its web interface, where you can check the accuracy of your data in the RIPE Routing Registry and Whois Database. Per-maintainer reports are also available as in an e-mail interface. For more information, please visit http://www.ripe.net/rrcc/ . Now you can build you own RRCC database yourself, using RRCC scripts, which you can find at ftp://ftp.ripe.net/ripe/dbase/software/RRCC-0.2.tar.gz Using these scripts, you can check the consistency of other routing registries as well. Please contact rrcc(a)ripe.net for any comments. Best regards, Engin Gunduz RIPE NCC Database Group

1 0

draft agenda (v1), for DB-WG meeting, RIPE 44, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 22 Jan '03

22 Jan '03

Dear WG list members, dear "Meeting Role" @ the NCC, dear WG-Chairs! Attached please find the 1st, very preliminary, draft: Proposed Agenda for the DB-WG Meeting at RIPE 44 in Amsterdam, NL. For the moment this is pretty much "work in progress", but something has to be printed on paper. I'll add the usual "syntactic sugar" later... As usual, if you have any comments, corrections or additions please get back to me directly. Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting 1. Draft A. Administrative stuff (WW, chair) 10 min B. Action Items 15 min C. DB update (RIPE NCC, Shane K.) 20 min D ERX (Status report and future plans) (RIPE NCC) 15 min E. Organisation object proposal (RIPE NCC, Shane K.) 10 min F. status: SUB-ALLOCATED PA (Space.Net, Gert D.) 10(?) min G. reclaim: - Attribut (Space.Net, Gert D.) 10(?) min H. allowing "generated" attributes in updates (WW et.al.) 10 min I. Key Certificates to person: role: ? 10 min Y. Input from other WGs . Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 22-JAN-2003 09:53:47 UTC _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Only one thing in life is certain: init is Process #1"

2 1

Re: contacts
by leo vegoda 20 Jan '03

20 Jan '03

Dear Mouse, You are correct in stating that the RIPE NCC does not manage the contact information stored in the RIPE Database. Contact information is currently published in "person:" or "role:" objects managed by database users. The RIPE NCC and other database users reference contact information from various objects describing networks. The current design allows the people publishing the contact data to update it independently from the people publishing the network objects that reference it. It should also be noted that the "e-mail" attribute is optional for the "person:" object in the current database specification. The RIPE NCC takes direction from consensus reached within the RIPE community. If you would like to bring about a change then please bring a proposal to the mailing list of the appropriate working group. Information about RIPE working groups may be found at: <http://www.ripe.net/ripe/wg/index.html> It may also be possible to raise a proposal during a working group session at RIPE 44 next week. RIPE 44 meeting details are available from our web site at: <http://www.ripe.net/ripe/meetings/current/ripe-44/> Kind regards, -- leo vegoda RIPE NCC Registration Services

2 1

Contacts
by der Mouse 18 Jan '03

18 Jan '03

I'm not sure this is the right place for this, but if not, perhaps someone can point me at the right place. I previously raised the issue with ncc(a)ripe.net and the person dealing with it there pointed me here, among other places. When dealing with net-abuse, I have occasion to look up addresses in RIPE's database, to contact people responsible for the relevant netblock. Mostly this is unremarkable, but sometimes the contact address bounces. In this case, I normally write to the contact for the next larger containing netblock, but when that's the RIPE, that doesn't work (the contact address for RIPE's netblocks is one which doesn't accept mail from the world at large - or at least is documented as such; I don't recall trying it recently). So I was reporting such broken contact addresses to ncc@. But the person there (signing with the name Yvette Vermeer) tells me that ncc@ is not the correct place to send them. She (I assume "Yvette" is "she") referred me to two lists, of which this is one. Presumably _somewhere_ at RIPE there is _someone_ to whom such things should be addressed; like any assigning authority, RIPE has responsibility concomitant with its authority, in particular to make sure its assignees behave themselves - such as by maintaining correct contact info. But it seems to be difficult to find whom to report such outdated contacts to. I've been lurking here for a little while, and this doesn't look like the right place to send such notifications; this appears to be more operational than policy. But perhaps I'm wrong, or perhaps someone here can tell me where I *should* send such notifications; I'm going to exhaust all the leads I can find at RIPE before going upstairs about this. I don't like to kick it even far up as RIPE (I wouldn't except that the invalid contact addresses in question are direct RIPE assignees) and I really don't want to have to go even further. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse(a)rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

1 0

Ref: Agenda points for the db-wg session (call for...)
by Wilfried Woeber, UniVie/ACOnet 17 Jan '03

17 Jan '03

Dear DB-WG! The RIPE NCC has already submitted items for the Jan 2003 DB-WG meeting's draft agenda. If anyone wants to propose issues/topics/items to be included, please sumbit them _asap_. I'll review the list of open actions and the minutes to complement the set of items from my end during the weekend. Regards, Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0