Route objects for space administered by other RIRs
Can anyone please explain to me, preferably using small words that I can understand, why route objects such as the following still exist in the data base at the present time? route: 62.61.192.0/18 descr: SRR origin: AS49902 mnt-by: CEGETEL_LA_REUNION created: 2014-09-30T15:01:51Z last-modified: 2018-09-04T18:00:38Z source: RIPE-NONAUTH (Please note that the whole of 62.61.192.0/18 currently appears to be under the administration of AFRINIC.) I understand that pre-existing route objects within the RIPE data base that relate to IP space which is under the administration of other (non-RIPE) RIRs was set to "RIPE-NONAUTH" awhile back, which is certainly a Good Thing, but I wonder if there is a date certain by which even these route objects will be sunsetted and removed from the RIPE db. Regards, rfg
Hi Ronald, less than a week ago, on this same list there was the conclusion that these route objects would be removed. real-soon-now, is my understanding. That should resolve *this* issue. But I think the holders could then create a similar route object in AfriNIC... Another thing that confuses me: [I see the inetnum object in AfriNIC, but:] $ whois -h whois.iana.org 62.61.192.0 says one should look at RIPE whois for the whole /8 and $ whois -h whois.ripe.net 62.61.192.0 says "nothing here - look at IANA" shouldn't IANA point to AfriNIC?? Regards, Frank On 12/05/2021 03:06, Ronald F. Guilmette via db-wg wrote:
Can anyone please explain to me, preferably using small words that I can understand, why route objects such as the following still exist in the data base at the present time?
route: 62.61.192.0/18 descr: SRR origin: AS49902 mnt-by: CEGETEL_LA_REUNION created: 2014-09-30T15:01:51Z last-modified: 2018-09-04T18:00:38Z source: RIPE-NONAUTH
(Please note that the whole of 62.61.192.0/18 currently appears to be under the administration of AFRINIC.)
I understand that pre-existing route objects within the RIPE data base that relate to IP space which is under the administration of other (non-RIPE) RIRs was set to "RIPE-NONAUTH" awhile back, which is certainly a Good Thing, but I wonder if there is a date certain by which even these route objects will be sunsetted and removed from the RIPE db.
Regards, rfg
Hello Frank, Ronald, The RIPE-NONAUTH database contains all out of region route(6) objects (referencing prefixes not allocated to RIPE). This database was created by NWI-5: https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005245.html The proposed cleanup is to only remove route(6) objects from RIPE-NONAUTH which are not registered in *any* region: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html The cleanup will not delete the 62.61.192.0/18AS49902 route, as the prefix is registered to AFRINIC. Regards Ed Shryane RIPE NCC
On 12 May 2021, at 06:17, Frank Habicht via db-wg <db-wg@ripe.net> wrote:
Hi Ronald,
less than a week ago, on this same list there was the conclusion that these route objects would be removed. real-soon-now, is my understanding.
That should resolve *this* issue. But I think the holders could then create a similar route object in AfriNIC...
The proposed cleanup is to only remove route(6) objects from RIPE-NONAUTH which are not registered in *any* region: too bad, because I have a use case where I have a couple of route objects in RIPE-NOAUTH but they are maintained by an old peering partner which seems to have no wish to help me remove those objects which are legit AFRINIC route objects. thus although I want to clean them, I can't.
regards Erik On Wed, 12 May 2021 at 10:35, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Hello Frank, Ronald,
The RIPE-NONAUTH database contains all out of region route(6) objects (referencing prefixes not allocated to RIPE).
This database was created by NWI-5: https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005245.html
The proposed cleanup is to only remove route(6) objects from RIPE-NONAUTH which are not registered in *any* region: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
The cleanup will not delete the 62.61.192.0/18AS49902 route, as the prefix is registered to AFRINIC.
Regards Ed Shryane RIPE NCC
On 12 May 2021, at 06:17, Frank Habicht via db-wg <db-wg@ripe.net> wrote:
Hi Ronald,
less than a week ago, on this same list there was the conclusion that these route objects would be removed. real-soon-now, is my understanding.
That should resolve *this* issue. But I think the holders could then create a similar route object in AfriNIC...
Hi Erik,
On 12 May 2021, at 09:27, Erik Linder <erik.linder@gmail.com> wrote:
The proposed cleanup is to only remove route(6) objects from RIPE-NONAUTH which are not registered in *any* region: too bad, because I have a use case where I have a couple of route objects in RIPE-NOAUTH but they are maintained by an old peering partner which seems to have no wish to help me remove those objects which are legit AFRINIC route objects. thus although I want to clean them, I can't.
regards Erik
There is a RIPE policy to cleanup conflicting route(6) objects in the NONAUTH database: https://www.ripe.net/publications/docs/ripe-731 If you can create a ROA for the Afrinic prefix, a cleanup job will delete any conflicting route(6) for you. Regards Ed
is there a need for the ROA object to be identical in length to the route object? take 41.213.128.0/21 is a RIPE-NOAUTH route object and there is a valid ROA from AFRINIC for 41.213.128.0/17 max length 24 regards erik On Wed, 12 May 2021 at 11:46, Edward Shryane <eshryane@ripe.net> wrote:
Hi Erik,
On 12 May 2021, at 09:27, Erik Linder <erik.linder@gmail.com> wrote:
The proposed cleanup is to only remove route(6) objects from RIPE-NONAUTH which are not registered in *any* region: too bad, because I have a use case where I have a couple of route objects in RIPE-NOAUTH but they are maintained by an old peering partner which seems to have no wish to help me remove those objects which are legit AFRINIC route objects. thus although I want to clean them, I can't.
regards Erik
There is a RIPE policy to cleanup conflicting route(6) objects in the NONAUTH database: https://www.ripe.net/publications/docs/ripe-731
If you can create a ROA for the Afrinic prefix, a cleanup job will delete any conflicting route(6) for you.
Regards Ed
Hi Erik,
On 12 May 2021, at 10:00, Erik Linder <erik.linder@gmail.com> wrote:
is there a need for the ROA object to be identical in length to the route object?
take 41.213.128.0/21 is a RIPE-NOAUTH route object and there is a valid ROA from AFRINIC for 41.213.128.0/17 max length 24
regards erik
The cleanup job follows RFC6811 to match a route prefix: o Matched: A Route Prefix is said to be Matched by a VRP when the Route Prefix is Covered by that VRP, the Route prefix length is less than or equal to the VRP maximum length, and the Route Origin ASN is equal to the VRP ASN. In your example, the ROA should match the route object. I will check whether there is a conflict between the ROA and the route object. Regards Ed
Dear Erik, On Wed, May 12, 2021 at 12:00:52PM +0400, Erik Linder via db-wg wrote:
is there a need for the ROA object to be identical in length to the route object?
take 41.213.128.0/21 is a RIPE-NOAUTH route object and there is a valid ROA from AFRINIC for 41.213.128.0/17 max length 24
Following the RFC 6811 procedure, the RIPE-NONAUTH route object is 'valid' from a RPKI ROA perspective. 1) 41.213.128.0/17 covers 41.213.128.0/21 2) the /21 prefix length is between /17 and maxlength /24 3) the origin AS in the ROA is equal to the origin AS in the RIPE-NONAUTH object A current overview of related objects is available here: https://irrexplorer.dashcare.nl/prefix/41.213.128.0/21 I recommend reaching out to RIPE NCC directly and request them to remove the objects manually: https://www.ripe.net/contact-form "RIPE database" -> "contact form" Kind regards, Job
On 12/05/2021 09:35, Edward Shryane wrote:
The proposed cleanup is to only remove route(6) objects from RIPE-NONAUTH which are not registered in *any* region: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
The cleanup will not delete the 62.61.192.0/18AS49902 route, as the prefix is registered to AFRINIC.
I see that now. my bad. Frank
In message <77E5D90B-6733-4CF8-8E15-3D984E4FBFFE@ripe.net>, Edward Shryane <eshryane@ripe.net> wrote:
The RIPE-NONAUTH database contains all out of region route(6) objects (referencing prefixes not allocated to RIPE).
This database was created by NWI-5: https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005245.html
The proposed cleanup is to only remove route(6) objects from RIPE-NONAUTH which are not registered in *any* region: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
The cleanup will not delete the 62.61.192.0/18AS49902 route, as the prefix is registered to AFRINIC.
Thank you for the clear answer. It is difficult me to tell, based only upon looking at the current relevant AFRINIC allocation WHOIS records, when, exactly, the 62.61.192.0/18 was transferred from RIPE to AFRINIC, so let's just set that point aside for a moment. I'd like to ask a more general question anyway, which is just this: When the authority for some IP number resource is transferred from, say, RIPE, to some other RIR, is there any good reason why any associated route objects should not likewise travel to the new RIR along with the IP block allocation itself? And if there is no such good reason, then could we please have a rule that says that a transfer of an IP address block out of the RIPE region will be followed also by a deletion, in short order, from the RIPE data base of any directly relevant route object(s)? More broadly, it is parhaps a result of my overly-fastidious nature, but I personally would be in favor of simply deleting all of the remaining RIPE-NONAUTH route objects from the RIPE data base. Is there any clear need for any of these? If the relevant IP blocks have been entirely deallocated, then maintaining the route objects would seem to be a Bad Idea on the face of it. On the other hand, if a given IP block has been transferred to some other region, why doesn't it not make perfect sense for any relevant route objects to also and likewise be created in the WHOIS data bases of those other regions? It seems that we are now in the era of RPKI and that everyone is being generally encouraged to take routing security rather more seriously these days, which is a profoundly Good Thing. Yet it appears that when it comes to these RIPE-NONAUTH route records, RIPE is still, in effect catering not just to the last generation of route registration protocols, but also and even to the generation before that. At what point in time does will all of this stuff be seen to be what it is, i.e. antiquated and counterproductive? Regards, rfg P.S. In response to Frank Habicht's question about the IANA WHOIS referral server, let me just say that due to the work I have done to try to build a single tool capable of getting the correct WHOIS record for any arbitrary IP address from whichever RIR it needs to come from. I can say definitively and without hesitation that if one were to try to rely exclusively on whois.iana.org for proper referrals then one would actually get the Wrong Answer (i.e. one would get pointed to the Wrong RIR) a really substantial percentage of the time. I have asked IANA to "fix this" and they have responded clearly that they have absolutely no intention of doing so. Thus, for my own tool, I have been forced to resort to building my own quite lengthy table of exceptions so that my tool will just ignore what whois.iana.org says in all of the numerous cases where I have learned that what it says is just plain wrong.
Hi Ronald Interesting that you have tried to build a tool to get the correct whois data on a resource from any RIR. The RIPE Database already does this for you. The RIPE NCC mirrors all the other RIR resource databases and some independent IRR databases in a Global Resource Service (GRS) If you include the flag '--resource' in your query to the RIPE Database you will get a response from all sources. whois -r --resource 62.61.192.0/18 inetnum: 62.61.192.0 - 62.61.255.255 netname: SRR-DYN-DSL descr: Societe Reunionnaise du Radiotelephone country: RE org: ORG-SRdR1-AFRINIC admin-c: DUMY-RIPE tech-c: DUMY-RIPE status: ALLOCATED PA notify: ***@gaoland.net notify: ***@srr.fr notify: ***@sfr.com notify: ***@neufcegetel.fr notify: ***@srr.fr mnt-by: AFRINIC-HM-MNT mnt-lower: SRR-mnt source: AFRINIC-GRS remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the AFRINIC Database at: remarks: * http://www.afrinic.net/ remarks: **************************** as well as the two different ROUTE objects from RIPE and RADB Databases. As for when this resource was transferred, IANA shows that 62/8 was allocated to the RIPE NCC. According to the RIPE NCC web page listing all 'valid' transfers, there have not been any transfers from RIPE to AFRINIC. https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran... (Maybe I am missing something...) cheers denis co-chair DB-WG On Wed, 12 May 2021 at 21:59, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
In message <77E5D90B-6733-4CF8-8E15-3D984E4FBFFE@ripe.net>, Edward Shryane <eshryane@ripe.net> wrote:
The RIPE-NONAUTH database contains all out of region route(6) objects (referencing prefixes not allocated to RIPE).
This database was created by NWI-5: https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005245.html
The proposed cleanup is to only remove route(6) objects from RIPE-NONAUTH which are not registered in *any* region: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
The cleanup will not delete the 62.61.192.0/18AS49902 route, as the prefix is registered to AFRINIC.
Thank you for the clear answer.
It is difficult me to tell, based only upon looking at the current relevant AFRINIC allocation WHOIS records, when, exactly, the 62.61.192.0/18 was transferred from RIPE to AFRINIC, so let's just set that point aside for a moment.
I'd like to ask a more general question anyway, which is just this: When the authority for some IP number resource is transferred from, say, RIPE, to some other RIR, is there any good reason why any associated route objects should not likewise travel to the new RIR along with the IP block allocation itself? And if there is no such good reason, then could we please have a rule that says that a transfer of an IP address block out of the RIPE region will be followed also by a deletion, in short order, from the RIPE data base of any directly relevant route object(s)?
More broadly, it is parhaps a result of my overly-fastidious nature, but I personally would be in favor of simply deleting all of the remaining RIPE-NONAUTH route objects from the RIPE data base. Is there any clear need for any of these? If the relevant IP blocks have been entirely deallocated, then maintaining the route objects would seem to be a Bad Idea on the face of it. On the other hand, if a given IP block has been transferred to some other region, why doesn't it not make perfect sense for any relevant route objects to also and likewise be created in the WHOIS data bases of those other regions?
It seems that we are now in the era of RPKI and that everyone is being generally encouraged to take routing security rather more seriously these days, which is a profoundly Good Thing. Yet it appears that when it comes to these RIPE-NONAUTH route records, RIPE is still, in effect catering not just to the last generation of route registration protocols, but also and even to the generation before that. At what point in time does will all of this stuff be seen to be what it is, i.e. antiquated and counterproductive?
Regards, rfg
P.S. In response to Frank Habicht's question about the IANA WHOIS referral server, let me just say that due to the work I have done to try to build a single tool capable of getting the correct WHOIS record for any arbitrary IP address from whichever RIR it needs to come from. I can say definitively and without hesitation that if one were to try to rely exclusively on whois.iana.org for proper referrals then one would actually get the Wrong Answer (i.e. one would get pointed to the Wrong RIR) a really substantial percentage of the time.
I have asked IANA to "fix this" and they have responded clearly that they have absolutely no intention of doing so. Thus, for my own tool, I have been forced to resort to building my own quite lengthy table of exceptions so that my tool will just ignore what whois.iana.org says in all of the numerous cases where I have learned that what it says is just plain wrong.
In message <CAKvLzuFZzCrr-jdU_WJOQ69jcWnnt1o0-gmBwy2i4pKtv4UypQ@mail.gmail.com> denis walker <ripedenis@gmail.com> wrote:
Interesting that you have tried to build a tool to get the correct whois data on a resource from any RIR. The RIPE Database already does this for you. The RIPE NCC mirrors all the other RIR resource databases and some independent IRR databases in a Global Resource Service (GRS) If you include the flag '--resource' in your query to the RIPE Database you will get a response from all sources. ... (Maybe I am missing something...)
I prefer to get the data from the horse's mouth. There are a number of complex technical reasons for this, at least some of which having to do with (a) simulating the effect of the -L option for those RIRs that do not really support it (i.e. ARIN & LACNIC) and also (b) dealing with the problems caused by per-RIR unique rate limits, once again, in particular, relative to ARIN & LACNIC[1]. Regards, rfg ======== [1] Trying doing more that a handful of WHOIS queries against the LACNIC WHOIS data base if you want to see a glaringly ridiculous rate limit. Or try asking the ARIN WHOIS server for all of the records it has that relate to IP allocations assigned to, e.g. OHV. And good luck with that.
Hi, On 13/05/2021 03:19, denis walker via db-wg wrote:
As for when this resource was transferred, IANA shows that 62/8 was allocated to the RIPE NCC. According to the RIPE NCC web page listing all 'valid' transfers, there have not been any transfers from RIPE to AFRINIC.
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran...
Well, RIPE whois also says there was an INETNUM once .... [ was it really deleted only 12 minutes *before* it was created? ;-) ] $ whois -h whois.ripe.net -- --list-versions 62.61.192.0/18 [Querying whois.ripe.net] [whois.ripe.net] % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Version history for INETNUM object "62.61.192.0 - 62.61.255.255" % You can use "--show-version rev#" to get an exact version of the object. % This object was deleted on 2019-01-07 11:38 rev# Date Op. 1 2019-01-07 11:50 ADD/UPD % This query was served by the RIPE Database Query Service version 1.100 (HEREFORD) still strange .... Frank
Hi Frank,
On 13 May 2021, at 07:45, Frank Habicht via db-wg <db-wg@ripe.net> wrote:
Hi,
On 13/05/2021 03:19, denis walker via db-wg wrote:
As for when this resource was transferred, IANA shows that 62/8 was allocated to the RIPE NCC. According to the RIPE NCC web page listing all 'valid' transfers, there have not been any transfers from RIPE to AFRINIC.
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran...
Well, RIPE whois also says there was an INETNUM once .... [ was it really deleted only 12 minutes *before* it was created? ;-) ]
The RIPE database contains placeholder objects for out-of-region space, and these placeholders were re-created from a common template in January 2019. The prefix 62.61.192.0 - 62.61.255.255 was transferred from the RIPE database to AFRINIC in 2005 when the AFRINIC region was created. Regards Ed Shryane RIPE NCC
Hi Ronald,
On 12 May 2021, at 21:59, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
... I'd like to ask a more general question anyway, which is just this: When the authority for some IP number resource is transferred from, say, RIPE, to some other RIR, is there any good reason why any associated route objects should not likewise travel to the new RIR along with the IP block allocation itself?
During an inter-RIR transfer in the RIPE region, any associated routes are updated according to the user's wishes, in coordination with the RIPE NCC, to minimise any potential for disrupting networks.
And if there is no such good reason, then could we please have a rule that says that a transfer of an IP address block out of the RIPE region will be followed also by a deletion, in short order, from the RIPE data base of any directly relevant route object(s)?
Deleting the route objects are done manually, we are investigating how to automate this (or at least email reminders so they are not left behind). In April I found 2 routes in the RIPE database with an out-of-region prefix, and 33 routes in the RIPE-NONAUTH database with an in-region prefix. These were left over from Inter-RIR transfers since 2018. I notified the maintainers and moved the routes to the correct database.
More broadly, it is parhaps a result of my overly-fastidious nature, but I personally would be in favor of simply deleting all of the remaining RIPE-NONAUTH route objects from the RIPE data base.
The NONAUTH routes date back to the time when the RIPE database served as a global IRR, and at the time it was decided to move them to a separate database rather than delete them altogether and risk disruption for users that depend on them. There is some more detail in the impact analysis for the original change: https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implem... <https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation> And extensive discussion in the DB-WG archives from 2017 - 2018: https://www.ripe.net/ripe/mail/archives/db-wg/ <https://www.ripe.net/ripe/mail/archives/db-wg/>
... It seems that we are now in the era of RPKI and that everyone is being generally encouraged to take routing security rather more seriously these days, which is a profoundly Good Thing. Yet it appears that when it comes to these RIPE-NONAUTH route records, RIPE is still, in effect catering not just to the last generation of route registration protocols, but also and even to the generation before that. At what point in time does will all of this stuff be seen to be what it is, i.e. antiquated and counterproductive?
The intent of the 2018-06 policy proposal (now RIPE-731) was to clean up route(6) objects in RIPE-NONAUTH where they conflict with an RPKI ROA: https://www.ripe.net/participate/policies/proposals/2018-06 <https://www.ripe.net/participate/policies/proposals/2018-06> Regards Ed Shryane RIPE NCC
participants (6)
-
denis walker -
Edward Shryane -
Erik Linder -
Frank Habicht -
Job Snijders -
Ronald F. Guilmette