- db-wg - mailman.ripe.net

AW: [db-wg] Adding route objects
by Ihler, Hermann 06 Apr '06

06 Apr '06

Hi Winfried, if OLD-ISP updates his objects as follows it also will work: route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT mnt-routes: NEW-ISP-MNT source: RIPE # Filtere In this case there is no need for OLD-ISP to insert mnt-by, mnt-routes is sufficient. We often create objects like this. best regards Hermann Ihler _________________________________________ Deutsche Telekom T-Com Headquarters Network Information Center Ammerlaender Heerstrasse 138 DE 26129 Oldenburg +49 441 234 - 4582 (phone) +49 441 234 - 4589 (fax) E-Mail: Hermann.ihler(a)t-com.net -----Ursprüngliche Nachricht----- Von: Winfried Haug [mailto:wh@germany.com] Gesendet: Mittwoch, 5. April 2006 07:40 An: db-wg(a)ripe.net Betreff: [db-wg] Adding route objects Hello, we would like to ask the db-wg working group to change the behavior of adding route objects to the ripe database. I had a discussion with someone from ripe during the routing registry course and he told me that ripe could change the way how route objects can be created but this must be decided by the db-wg. We need route-objects for proper routing via bgp4. As customers may change their upstream they need for a certain amount of time more than one route object. The creating of this new route object failes if the old isp does not respond. Let me give you the following example: inetnum: 192.168.230.0 - 192.168.231.255 netname: DUMMY-NET descr: Customer GmbH country: DE org: ORG-AAAAA-RIPE admin-c: AA1 tech-c: AA1 status: ASSIGNED PI mnt-by: RIPE-NCC-HM-PI-MNT mnt-by: CUSTOMER-MNT mnt-by: NEW-ISP-MNT mnt-lower: RIPE-NCC-HM-PI-MNT mnt-routes: OLD-ISP1-MNT mnt-routes: OLD-ISP2-MNT mnt-routes: NEW-ISP-MNT mnt-domains: OLD-ISP1-MNT mnt-domains: OLD-ISP2-MNT mnt-domains: NEW-ISP-MNT source: RIPE # Filtered route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT source: RIPE # Filtered we want now add this object parallel to the existing one: route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS5678 mnt-by: NEW-ISP-MNT source: RIPE # Filtered but fail because: not authenticated by: OLD-ISP1-MNT Thus if OLD-ISP doesnt want for whatever reason help the customer it seems to be that he can block new route objects. This is stupid and can as i know only solved with the help of ripe ncc. It seems to work only if the old isp changed his route object: route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT source: RIPE # Filtered to route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT mnt-by: NEW-ISP-MNT source: RIPE # Filtered I think the owner of the network (inetnum object) should be able to create route objects for his IPs. This would solve the problem. Currently he cant do this because the AS does not have his Maintainer i doubt large ISPs want even for a short period customer maintainer in their AS. To avoid abuse, the db should prevent to alter or create route-objects if there is no maintainer in the inetnum object. If the db will accept new route objects created by those who are maintainer in the inetnum object, the customer can do this without help of the old isp or ripe ncc. Could we have some input and comments from the working group ? Winfried Haug --- Headlight Housing Factory | Rechenzentrum: Azenbergstrasse 35 | Neue Bruecke 8 D-70174 Stuttgart | D-70173 Stuttgart Fon: +49 711 2840 0 | e-mail: wh(a)headlight.de Fax: +49 711 2840 999 | http://www.headlight.de

7 6

Adding route objects
by Winfried Haug 06 Apr '06

06 Apr '06

Hello, we would like to ask the db-wg working group to change the behavior of adding route objects to the ripe database. I had a discussion with someone from ripe during the routing registry course and he told me that ripe could change the way how route objects can be created but this must be decided by the db-wg. We need route-objects for proper routing via bgp4. As customers may change their upstream they need for a certain amount of time more than one route object. The creating of this new route object failes if the old isp does not respond. Let me give you the following example: inetnum: 192.168.230.0 - 192.168.231.255 netname: DUMMY-NET descr: Customer GmbH country: DE org: ORG-AAAAA-RIPE admin-c: AA1 tech-c: AA1 status: ASSIGNED PI mnt-by: RIPE-NCC-HM-PI-MNT mnt-by: CUSTOMER-MNT mnt-by: NEW-ISP-MNT mnt-lower: RIPE-NCC-HM-PI-MNT mnt-routes: OLD-ISP1-MNT mnt-routes: OLD-ISP2-MNT mnt-routes: NEW-ISP-MNT mnt-domains: OLD-ISP1-MNT mnt-domains: OLD-ISP2-MNT mnt-domains: NEW-ISP-MNT source: RIPE # Filtered route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT source: RIPE # Filtered we want now add this object parallel to the existing one: route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS5678 mnt-by: NEW-ISP-MNT source: RIPE # Filtered but fail because: not authenticated by: OLD-ISP1-MNT Thus if OLD-ISP doesnt want for whatever reason help the customer it seems to be that he can block new route objects. This is stupid and can as i know only solved with the help of ripe ncc. It seems to work only if the old isp changed his route object: route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT source: RIPE # Filtered to route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT mnt-by: NEW-ISP-MNT source: RIPE # Filtered I think the owner of the network (inetnum object) should be able to create route objects for his IPs. This would solve the problem. Currently he cant do this because the AS does not have his Maintainer i doubt large ISPs want even for a short period customer maintainer in their AS. To avoid abuse, the db should prevent to alter or create route-objects if there is no maintainer in the inetnum object. If the db will accept new route objects created by those who are maintainer in the inetnum object, the customer can do this without help of the old isp or ripe ncc. Could we have some input and comments from the working group ? Winfried Haug --- Headlight Housing Factory | Rechenzentrum: Azenbergstrasse 35 | Neue Bruecke 8 D-70174 Stuttgart | D-70173 Stuttgart Fon: +49 711 2840 0 | e-mail: wh(a)headlight.de Fax: +49 711 2840 999 | http://www.headlight.de

8 12

AW: [db-wg] Adding route objects
by Ihler, Hermann 31 Mar '06

31 Mar '06

Hi, > But that's winfried's point: the old ISP need to actively enable > creation of the new route object. Yes, you are right, if you have authenticated against the maintainer of the inetnum (mnt-by/mnt-routes) and against the maintainer of the new AS, you should be allowed to create the new route object. But you also have to delete the obsolete old object. And if > The old AS might be bankcrupt, not cooperative, or whatever... you can't, you have to contact RIPE NCC. There is a procedure at RIPE: Ask your customer to send a FAX using the company letterhead paper and signed by one of the responsible contacts of the IP range. The FAX should include the explanation and requesting to remove the route object from the RIPE Database. Submit this FAX to +31 20 535 4341. Ask the customer to include the Ticket Number (if existing) in the FAX. RIPE NCC will remove it then. best regards Hermann Ihler _________________________________________ Deutsche Telekom T-Com Headquarters Network Information Center Ammerlaender Heerstrasse 138 DE 26129 Oldenburg +49 441 234 - 4582 (phone) +49 441 234 - 4589 (fax) E-Mail: Hermann.ihler(a)t-com.net

1 0

Re
by S A 31 Mar '06

31 Mar '06

confirm 352302 --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low rates.

1 0

Re
by S A 31 Mar '06

31 Mar '06

confirm 352302 --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.

1 0

WG action 48.6
by md＠Linux.IT 31 Mar '06

31 Mar '06

http://www.ripe.de/ripe/wg/db/minutes/ripe-51.html says: 48.6 RIPE NCC To change DB behaviour to return IRT object [Misunderstanding of requirement, superceded by AP51.8, complete] Can somebody explain this? I tought that everybody agreed that it would be a good idea to always return IRT records for inetnum/inetnum queries, but this is still not happening. I could not find action 51.8 in the draft minutes of the AP WG. -- ciao, Marco

2 1

Call for agenda items, DB-WG Meeting during RIPE52, Istabul
by Wilfried Woeber, UniVie/ACOnet 30 Mar '06

30 Mar '06

Dear DB-WG folks, the RIPE NCC has asked us to submit the draft agendas for the WGs by mid April. Thus, please submit (to the WG list or to me personally) your item requests or suggest topics for discussion to be included in the draft agenda. The DataBase-WG meeting is scheduled for Friday morning, April 28. The overall RIPE meeting outline is available at http://www.ripe.net/ripe/meetings/ripe-52/meeting-plan.html The list of plenary presentations scheduled is available at http://www.ripe.net/ripe/meetings/ripe-52/presentations/ See you in Istanbul, Wilfried.

1 0

Re: [db-wg] Since when does one need 3 nameservers for inverse?
by Ulrich Schmid 28 Mar '06

28 Mar '06

on 8.2.2006 11:10 Uhr Brett Carr wrote: >> -----Original Message----- >> From: db-wg-admin(a)ripe.net On Behalf Of Hank Nussbacher >> Sent: Wednesday, February 08, 2006 10:19 AM >> Cc: rdns-project(a)ripe.net >> Subject: [db-wg] Since when does one need 3 nameservers for inverse? >> >> In the "Reverse Delegation How To": >> http://www.ripe.net/rs/reverse/reverse_howto.html >> it states: >> >> "NS Servers >> Ensure you have at least two nameservers that are >> authoritative for the zone. The resolvable names of these NS >> servers should be in the NS resource records of the zone. The >> nameservers should be on different subnets." >> >> Yet when I submit a request I get: >> ***RDNS: (related to set) ERROR (20 points): At least 3 nameservers >> are required for each properly delegated zone. >> We found only >> 2 in your submission. >> >> In addition the reverse delegation checker at: >> http://www.ripe.net/cgi-bin/delcheck/delcheck2.cgi >> doesn't flag only 2 nameservers as an error. >> >> What gives? >> > > Indeed you are right, something doesn't look quite right here. Thanks for > flagging it I'll take a look. > > Brett > Any news about this item? Changes to the domain objects are still rejected by the delegation checker due to the (wrong) requirement of 3 nameservers and this prevents us to perform simple updates (e.g. contact address changes). Regards Ulrich Schmid

2 1

Re: WHOIS changes
by Hank Hampel 08 Mar '06

08 Mar '06

Hi Marie-Luise, On 4-Mär-2006 Dr. Marie-Luise Hansen wrote: > But how and where do I change the settings? This depends on what whois client you use. If you use the commandline whois client from RIPE you can just use the new flags on the commandline. If you use an other client it may not be able to "understand" the new flags so maybe you should switch to the RIPE client or use the web interface at: http://www.ripe.net/fcgi-bin/whois?form_type=simple&full_query_string=&sear… (this should be one line) Best regards, Hank

4 3

Since when does one need 3 nameservers for inverse?
by Hank Nussbacher 08 Feb '06

08 Feb '06

In the "Reverse Delegation How To": http://www.ripe.net/rs/reverse/reverse_howto.html it states: "NS Servers Ensure you have at least two nameservers that are authoritative for the zone. The resolvable names of these NS servers should be in the NS resource records of the zone. The nameservers should be on different subnets." Yet when I submit a request I get: ***RDNS: (related to set) ERROR (20 points): At least 3 nameservers are required for each properly delegated zone. We found only 2 in your submission. In addition the reverse delegation checker at: http://www.ripe.net/cgi-bin/delcheck/delcheck2.cgi doesn't flag only 2 nameservers as an error. What gives? -Hank

2 1