- db-wg - mailman.ripe.net

RIPE Database Software Version 3.0.
by DB-News 05 Apr '01

05 Apr '01

Dear Colleagues, [Apologies for multiple messages]. The RIPE NCC is pleased to announce the release of Version 3.0 of the RIPE Database software. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). You can download this release by anonymous ftp from the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0.tar.gz We remind you that you can also test the functionality of this release of the new RIPE Whois server in 2 ways: - by querying the host rpsl.ripe.net at port 43; you will find there a Near-Real-Time Mirror of the RIPE Database; this mirror is in RPSL format; - by using the RIP Test Database; you can send test updates to this database at the address <auto-rip(a)ripe.net>, and you can query this database at reimp.ripe.net port 4343. We would be very pleased if you could test this release in both ways, and send us your comments. Comments and bug reports may be sent to the <db-beta(a)ripe.net> mailing list. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your message. This is a moderated mailing list so some delays in subscription are possible. Version 3 of the RIPE Database software will be deployed on the RIPE Whois server on 23 April 2001. Please see http://www.ripe.net/rpsl/ for more information on how this will affect you. There is a mailing list to discuss the migration to the new service, <reimp-mig-tf(a)ripe.net>. To subscribe, send a message to <majordomo(a)ripe.net> with the line: subscribe reimp-mig-tf in the body of your message. As for the db-beta mailing list, this is a moderated mailing list so some delays and so some delays in subscription are possible. If you have any other questions or comments, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee ______________ RIPE NCC

1 0

RE: Another issue related to the migration
by Lu, Ping 03 Apr '01

03 Apr '01

Andrei, The existing ripe2rpsl tool will automatically translate "AS-" to "ASN-" for the aut-num object and I think "ASN-" is more meaningful than "AS_". Best Regards. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Andrei Robachevsky [mailto:andrei@ripe.net] > Sent: Thursday, March 29, 2001 11:10 AM > To: db-wg(a)ripe.net; routing-wg(a)ripe.net; Migration TF; lir-wg(a)ripe.net > Subject: Another issue related to the migration > > > Dear Colleagues, > > [Apologies for duplicate messages] > > One issue related to RIPE-181 to RPSL migration escaped our > attention and has > not been discussed. It is related to reserved prefixes that > cannot appear in > object names according to RPSL specification (RFC2622) which says: > > "Names starting with certain prefixes are reserved for > certain object types. > Names starting with "as-" are reserved for as set names. > Names starting with > "rs-" are reserved for route set names. Names starting with > "rtrs-" are > reserved for router set names. Names starting with "fltr-" > are reserved for > filter set names. Names starting with "prng-" are reserved > for peering set > names." > > Unfortunately "as-name:" attribute is an object name in RPSL > and we have 133 > aut-num objects with as-name starting with reserved 'AS-' prefix. > > Our suggestion how to deal with these objects is: > > 1. Send a message to the maintainers of these objects asking > them to change the > name to avoid conflict with RPSL specification. > 2. Give two-week notice period after which ripe-dbm will > convert non compliant > as-names using the following mapping: AS-ASNAME -> AS_ASNAME. > > This is more a "cosmetic" change as as-name is not even a > lookup key in the RIPE > Database. > > Your comments and suggestions are appreciated. > > Best regards, > > > Andrei Robachevsky > DB Group Manager > RIPE NCC >

2 1

Re: Plan of the migration to the new RIPE Database
by Andrei Robachevsky 02 Apr '01

02 Apr '01

Hi Rob, Rob Evans wrote: > > Hi Andrei, > > > Please find below a list of milestones related to the migration to the new > > version of the RIPE Database. > > Silly question; are the times UTC or CET? Sorry about this, all times are CEST (Central European Summer Time, UTC+2). > > Thanks, > Rob Regards, Andrei

1 0

Plan of the migration to the new RIPE Database
by Andrei Robachevsky 02 Apr '01

02 Apr '01

Dear Colleagues, [apologies for duplicate messages] Please find below a list of milestones related to the migration to the new version of the RIPE Database. Your comments and suggestions are welcome. Should you have any further question regarding the migration, please don't hesitate to contact me. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC ------------------------------------------------------------------ Date Actions ------------------------------------------------------------------ 4.04 Final release of the v3.0 DB software 12.04 Advised mirror's switchover to rpsl.ripe.net. - Reminder is sent to NRTM clients on 9.04 - Starting from this date NRTM clients that mirror the RIPE Database are advised to use the new server at rpsl.ripe.net, port 4444 for mirroring. 17-18.04 Migration of the TEST database to v3.0 (RPSL) - TEST Database becomes a RPSL database. Updates are accepted in RPSL format at <test-dbm(a)ripe.net>. - No RIPE-181 TEST database exists anymore. - Estimated downtime 6 hours. 22.04-23.04 Migration of the RIPE Database to v3.0 (RPSL) - New server becomes the official RIPE Database server at 00:00 23.04. - Updates received after 16:00, 22.04 are queued until the new server becomes operational. After that they are automatically converted to RPSL and processed by the new server. New syntax and authorization rules apply. - Downtime in queries will be deliberately introduced to mark the migration. Whois server downtime is planned from 18:00, 22.04 till 00:00 23.04. During this time a message explaining the migration process will be sent as a whois query reply. 23.04, 00:00 New server becomes the official RIPE Database server - Short (1-2 min) downtime is possible during final tests. 23.04, 02:00 New server starts processing updates - Two mail robots are available: <auto-dbm(a)ripe.net> - updates in RIPE-181 format (restrictions apply) <auto-rpsl(a)ripe.net> - updates in RPSL format (recommended).

1 0

RIPE Database Software V3.0 compliance test.
by DB-News 30 Mar '01

30 Mar '01

Dear Colleagues, If you have software that works with RIPE Database Software, then you should make sure that it works with Version 3.0, which will be put into production next month. Compliance tests are available at: http://www.ripe.net/ripencc/pub-services/db/rpsl/usercl.html More information about Version 3.0 of the RIPE Database Software and how it will affect you is available at: http://www.ripe.net/rpsl/ If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee -------------- Database Group RIPE NCC

1 0

RE: Another issue related to the migration
by Hallgren, Michael 29 Mar '01

29 Mar '01

Hi, > > > Dear Colleagues, [...] > > Our suggestion how to deal with these objects is: > > 1. Send a message to the maintainers of these objects asking > them to change the > name to avoid conflict with RPSL specification. > 2. Give two-week notice period after which ripe-dbm will > convert non compliant > as-names using the following mapping: AS-ASNAME -> AS_ASNAME. > > This is more a "cosmetic" change as as-name is not even a > lookup key in the RIPE > Database. Yes. Agree. Been hinting customers to trash/modify such names prior to migration date - not knowing whether or not such conflict would be treated auto-magically... Regards Michael > > Your comments and suggestions are appreciated. > > Best regards, > > > Andrei Robachevsky > DB Group Manager > RIPE NCC > -- Michael Hallgren, Eng., Teleglobe, MH2198-RIPE

1 0

Another issue related to the migration
by Andrei Robachevsky 29 Mar '01

29 Mar '01

Dear Colleagues, [Apologies for duplicate messages] One issue related to RIPE-181 to RPSL migration escaped our attention and has not been discussed. It is related to reserved prefixes that cannot appear in object names according to RPSL specification (RFC2622) which says: "Names starting with certain prefixes are reserved for certain object types. Names starting with "as-" are reserved for as set names. Names starting with "rs-" are reserved for route set names. Names starting with "rtrs-" are reserved for router set names. Names starting with "fltr-" are reserved for filter set names. Names starting with "prng-" are reserved for peering set names." Unfortunately "as-name:" attribute is an object name in RPSL and we have 133 aut-num objects with as-name starting with reserved 'AS-' prefix. Our suggestion how to deal with these objects is: 1. Send a message to the maintainers of these objects asking them to change the name to avoid conflict with RPSL specification. 2. Give two-week notice period after which ripe-dbm will convert non compliant as-names using the following mapping: AS-ASNAME -> AS_ASNAME. This is more a "cosmetic" change as as-name is not even a lookup key in the RIPE Database. Your comments and suggestions are appreciated. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

RE: Summary of the Migration issues
by Lu, Ping 21 Mar '01

21 Mar '01

Some questions followed. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu(a)cw.net [snip] > ---------------------------------------- > 1. Route object creation (RFC2725 implications) > > In order to create route object in the RIPE DB, one needs to have > corresponding objects (inetnum or less specific route, and > aut-num) and > pass proper authorization from these objects. > > The problem occurs when someone needs to register route > object which has > either prefix, or origin, or the both from non RIPE IP/ASN space. > > Proposed solution: > 1.1 An as-block object(s) encompassing the non RIPE ASN space will be > created with "mnt-lower:" protected by mntner with NONE auth. > > 1.2 An encompassing inetnum object with "mnt-routes:" protected by > mntner with NONE auth will be created. This will eliminate need for > corresponding inetnum creation and will reduce amount of redundant > information. > > 1.3 In case origin of a route object being created is from non RIPE > space, users will need to create corresponding aut-num object in the > RIPE DB. > Does 1.3 means RIPE is going accept non-RIPE aut-num(AN) object thus a mntner(MT) object to protect that AN thus some person(PN) objects associated with that MT ? And is RIPE going to allow the NONE auth specified in 1.1 and 1.2 to be changed to a real MT once the rightful holder created them ? > > 2. Updates in RIPE-181 format > How about the ftp mirror ? Will RIPE-181 format text files still be available to download after April 23, 2001 or just the RPSL format text files ? [big cut for the rest]

2 1

Summary of the Migration issues
by Andrei Robachevsky 20 Mar '01

20 Mar '01

Dear Colleagues, Please let me summarize the migration issues that have been discussed already and highlight some issues that require more attention. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC ---------------------------------------- 1. Route object creation (RFC2725 implications) In order to create route object in the RIPE DB, one needs to have corresponding objects (inetnum or less specific route, and aut-num) and pass proper authorization from these objects. The problem occurs when someone needs to register route object which has either prefix, or origin, or the both from non RIPE IP/ASN space. Proposed solution: 1.1 An as-block object(s) encompassing the non RIPE ASN space will be created with "mnt-lower:" protected by mntner with NONE auth. 1.2 An encompassing inetnum object with "mnt-routes:" protected by mntner with NONE auth will be created. This will eliminate need for corresponding inetnum creation and will reduce amount of redundant information. 1.3 In case origin of a route object being created is from non RIPE space, users will need to create corresponding aut-num object in the RIPE DB. 2. Updates in RIPE-181 format Migration plan allows users to send updates in RIPE-181 format for some time (until May 14th to <auto-dbm(a)ripe.net>, from May 14th till October 15th to <auto-181(a)ripe.net>) after the migration. In such case objects are automatically converted to RPSL. However the switchover to the new version of the RIPE Database occurs on 23 of April, and since then the following constraints will apply: 2.1 PGP authentication PGP authorization scheme will not work with <auto-dbm(a)ripe.net> robot after 23 April. Updates requiring PGP auth should be sent directly to <auto-rpsl(a)ripe.net>. The problem occurs because after ripe181->RPSL transformation it is impossible to verify signature. For this reason, some updates requiring PGP auth may be rejected during migration. It advisable not to send such updates from 22 April, 9a.m. till 23 April 9a.m. 2.2 New syntax rules When processing an object after ripe181->RPSL conversion new v3.0 syntax rules apply. The results of this will be: - empty attributes (i.e. having no value) are not allowed; - some attributes that were optional before are now mandatory; Also some undocumented behaviour of the v2.x Database will not be supported, namely: - attribute aliases (please see list of aliases attached) are not allowed; - inetnum object cannot be specified in prefix notation. 2.3 New authorization rules New authorization rules defined by RFC2725 apply to creation of aut-num and route objects. See 1. 3. Objects with names containing reserved RPSL prefixes They will be renamed on 2 of April. All references will be updated accordingly. Currently there are 6 of them in the RIPE Database. mntner: AS-5532MNTB mntner: AS-NETLINK-MNT mntner: AS-THENET-MNT mntner: AS-NEW1-MNT mntner: RS-MNT mntner: AS-MNT 4. Broken PGP certificates. They will be deleted on 2 of April. ---------------------- v2.x attribute aliases (not supported in v3.0!): Alias Attrbute change -> changed email -> e-mail fax -> fax-no remark -> remarks deleted -> delete asname -> as-name rev-svr -> rev-srv network -> inetnum netnum -> inetnum

3 3

RFC2725
by Holger Muenx 15 Mar '01

15 Mar '01

Guten Tag, I hope this is the correct forum - if not please direct me to a more appropriate one. After following the discussion for a while I am still unsure about the exact consequences of the activation of RFC2725 on 23-Apr-2001. I will try to summarize my understanding: Please check this and correct me where necessary. You will find a list of open questions at the bottom of this mail. As Frank Bohnsack wrote in http://www.ripe.net/ripe/mail-archives/db-wg/current/msg00090.html AS numbers are allocated to regional registries as shown in http://www.isi.edu/in-notes/iana/assignments/as-numbers and the IPv4 address space allocated to various registries as shown in http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space RFC2725 states in section 9.9 that during addition of an inetnum the most specific matching inetnum is being searched to find the required authentication. During addition of a route the aut-num of the originating AS and either a most specific matching inetnum or a most specific matching route is being searched to find the required authentication. This leaves UUNET in a curious situation. For example, UUNET uses AS 702 which is in the range 1 - 1876 allocated by the ARIN and the inetnum 193.96.0.0/13 which is in 193.0.0.0/8 allocated by the RIPE. With RFC2725 in place UUNET would have its aut-num record in a different registry than its inetnum, rendering it impossible to add routes for the 193.0.0.0/8. There are probably more complications caused by moving data from one registry to another. For example, some people will continue to expect information at the original registry because they did not prepare for RFC2725, breaking mechanisms such as automatic prefix filter creation. Andrei Robachevsky presented two suggestions in http://www.ripe.net/ripe/mail-archives/db-wg/current/msg00095.html Suggestion 1 means that RIPE will implement changes so that RFC2725 will be in effect for AS numbers and IP address space allocated by RIPE only. No checks according to RFC2725 will be done for all other AS numbers and IP address space. Suggestion 2 means that there will be encompassing inetnum objects which contain the address ranges assigned to other registries than RIPE. These objects will have a maintainer with NONE authentication so that everybody can add routes within these inetnum which refer to their own aut-num records. No decision has been made on whether one of the suggestion and, if so, which of them will be implemented. So far my understanding. Please review - if it is completely wrong I hope that I at least amused you. ;-) Thank you for your help! Holger Münx EMEA Access & Backbone Networks UUNET Deutschland GmbH Tel. +49 231 972 0 Sebrathweg 20 Fax. +49 231 972 1111 44149 Dortmund, Germany Holger.Muenx(a)de.uu.net http://www.de.uu.net/

1 0