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@ripe.net>, from May 14th till October 15th to <auto-181@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@ripe.net> robot after 23 April. Updates requiring PGP auth should be sent directly to <auto-rpsl@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
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@ripe.net>, from May 14th till October 15th to <auto-181@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@ripe.net> robot after 23 April. Updates requiring PGP auth should be sent directly to <auto-rpsl@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
Dear Colleagues, On 19-Mar-2001 Andrei Robachevsky wrote:
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.
* Means that, all non RIPE IP/ASN space is available on 23 of April as default or should we send an request if needed ? * Should we still use the human mail interface for "aut-num" and "mntner" creations on 23 of April ? * Can we assume that the database on 23 of April is the same like the current RPSL mirror ? many thanks Frank -- Frank Bohnsack email fb@de.uu.net UUNET, A Worldcom Company phone +49 (0)231 972-1495 EMEA Access & Backbone Networks fax +49 (0)231 972-1188 Team Dortmund web www.de.uu.net
Dear Colleagues, [Apologies for duplicate messages] Please let me answer some of your questions. Frank Bohnsack asked:
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.
* Means that, all non RIPE IP/ASN space is available on 23 of April as default or should we send an request if needed ?
Non RIPE IP space will be protected by the encompassing inetnum object. There is no need to create a corresponding inetnum object in case of "foreign" route creation. In case 1.3 people will be able to create a corresponding aut-num object themselves.
* Should we still use the human mail interface for "aut-num" and "mntner" creations on 23 of April ?
Yes. Except for aut-num creations in non RIP ASN space (case 1.3), when the request should be sent to <auto-dbm@ripe.net> or <auto-rpsl@ripe.net>.
* Can we assume that the database on 23 of April is the same like the current RPSL mirror ?
RPSL mirror is being kept in sync with the production RIPE Database. That means the contents of the both databases is the same. This will slightly change at the beginning of April when we plan to begin final pre production phase. Several objects (like as-block, encompassing inetnum) will be added to RPSL database. In a few days we are going to present a detailed migration plan, and your comments are highly appreciated. Ernesto Baschny asked:
PGP authorization scheme will not work with <auto-dbm@ripe.net> robot after 23 April. Updates requiring PGP auth should be sent directly to <auto-rpsl@ripe.net>.
Does that refer only to route/inetnum objects, or to all (also person-objects)? If so, can person-objects already be created using the adress auto-rpsl@ripe.net the same way we used the auto-dbm@ripe.net (with PGP)?
This restriction applies to all updates/objects sent in RIPE-181 format to <auto-dbm@ripe.net>. So if you are using PGP authorization, starting from 23 of April you should send your updates to <auto-rpsl@ripe.net> in RPSL format. To avoid confusion <auto-rpsl@ripe.net> will not be valid until April 23. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC
participants (3)
-
Andrei Robachevsky -
andrei＠ripe.net
-
Frank Bohnsack