Hi Christian, On 2002-11-05 11:46:35 +0100, Christian Rasmussen wrote:
Hi Engin,
Yes, I understand that the "old ISP" can authorize the new ISP by adding the maintainer of the new ISP as a MNT-ROUTES in the route object. But this actually means that if the current should ISP refuse for some reason to either delete the route object or add another ISP as MNT-ROUTES then the end user doesn't have too many options!... The idea of PI blocks should be that they are independent of the provider which doesn't exactly seem to be the case here.
Unfortunately the RFC does not distinguish between PI and PA space for route object creations. My personal opinion is that the owner of the IP space (thus the owner of the inetnum object) must have absolute control over it, including route objects in it. So even in the existence of other encompassing route objects, inetnum object must be taken into account. However this is not the RFC specifies. On the other hand, RFCs are not set into stone, and they can be changed (or rather, obsoleted by newer RFCs). Other than that, there might be another solution: the "reclaim" attribute. From the RFC2725, section 9.5: -------------------------------------- 9.5 reclaim and no-reclaim attributes A reclaim attribute is needed in as-block, inetnum and route objects. The reclaim attribute allows a control to be retained over more specific AS, IP address or route space by allowing modify and delete privileges regardless of the mnt-by in the object itself. The reclaim attribute provides the means to enforce address lending. It allows cleanup in cases where entities cease to exist or as a last presort means to correct errors such as parties locking themselves out of access to their own objects. To specify all more specific objects the reclaim attribute value should be "ALL". To allow finer control a set of prefixes can be specified. [...] -------------------------------------- This attribute and functionality is not implemented in RIPE RR, as it is listed as "non-core" functionality in the RFC. I think, even if it was considered for 'address lending' cases, it might be useful for the case you mention. Regards, Engin Gunduz RIPE NCC Database Group
In situations where modifying/adding route objects are relevant it means that a customer is changing/getting another provider, in such situations its not always in the "old ISP"'s interest to speed up the process.
I understand that the current implementation follows the relevant RFC, but maybe this should be reviewed.
Med venlig hilsen/Best regards
Christian Rasmussen Hosting manager, jay.net a/s
Frederiksgade 7, 2., 1265 København K., Denmark
Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301
Produkter / Products: http://hosting.jay.net
-----Original Message----- From: db-wg-admin@ripe.net [mailto:db-wg-admin@ripe.net]On Behalf Of Engin Gunduz Sent: 5. november 2002 11:06 To: Christian Rasmussen Cc: Harald.Singer@tesion.de; Ripe db-wg Subject: Re: [db-wg] RE: Hierarchical authorisation failed, request forwarded to maintainer ???
Hi Christian,
Hi Harald,
I have recently had the same problem, just with a PA block. I solved it by asking my customer to have Ripe insert our maintainer as MNT-ROUTES, then our customer asked their current ISP to delete their route object, hereafter I could create our route object.
It would have been preferable if we could have added our route object, then after we had verified everything was working then we could have
On 2002-11-05 10:49:59 +0100, Christian Rasmussen wrote: the route
object for the previous ISP deleted. I have a ticket at Ripe asking how to solve this problem, but maybe someone on the list has a suggestion?
The solution could be to ask the previous ISP to modify the "old" route object to add a mnt-routes attribute that lists your mntner name. This will allow you to create exact match and less specific route objects.
Looking at:
http://www.ripe.net/ripencc/faq/database/route-creation-checks.html
it seems that the reason for the "Hierarchical authorisation
failed" is that
when a route object exists and a second is beeing created, the first one has to authorize the second.. Im not sure I understand the reason for this...?
This is what the RFC that RIPE Routing Registry implements says. It's RFC2725, Routing Policy System Security (ftp://ftp.ripe.net/rfc/rfc2725.txt).
Best regards,
Engin Gunduz RIPE NCC Database Group
I think it would make sense if it was only the enduser of a PA/PI block who could authorize the creation of route objects by adding MNT-ROUTES for each upstream provider.
Med venlig hilsen/Best regards
Christian Rasmussen Hosting manager, jay.net a/s
Frederiksgade 7, 2., 1265 København K., Denmark
Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301
Produkter / Products: http://hosting.jay.net
-----Original Message----- From: db-wg-admin@ripe.net [mailto:db-wg-admin@ripe.net]On Behalf Of Harald.Singer@tesion.de Sent: 4. november 2002 17:59 To: db-wg@ripe.net Subject: Hierarchical authorisation failed, request forwarded to maintainer ???
Hello,
i have the problem to create a route-object for a customer of me. The customer will transfer his PI-Network (192.109.176.0/24, I´m CNSPLUS-MNT) from another ISP into my AS. And of course a mnt-routes:CNSPLUS-MNT exists. I need to create the new route-object, but i get the error: "Hierarchical authorisation failed, request forwarded to maintainer." I think I should be able to create such an object without assistance from another ISP.
- As the ISP and I are using Crypt-PW I don´t want to send a mail with my password to this ISP (like the proposal from Daniel in this WG).
- Some time ago i was able to create such objects without any assistance, what was the reason to change this behaviour?
- The discussion some weeks ago doesn´t have any hints for a solution, or i missed it.
- Do you have any proposal to create the object?
Regards
Harald
-- Harald Singer Telefon: +49 (0)711/2021-847 tesion )) Telekommunikation Telefax: +49 (0)711/2021-93-847 Systemingenieur / CCIE #7326 Mobil: +49 (0)178/2021-847 Kriegsbergstrasse 11 Mail: harald.singer@tesion.de D-70174 Stuttgart Web: http://www.tesion.de