Hi Ronald,
On 10 Jun 2021, at 23:57, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
It appears that, by and large, the route objects currently present within the ripe-nonauth.db.gz file refer either to bogons (which I've already provided a list of) or else they refer to out-of-region IP address blocks.
The latter group seems at least explainable. The former group I am hoping will disappear from the data base soon.
Correct, the route objects with an unregistered prefix will be cleaned up soon.
Checking now however I find there are a very small number of anomalous route objects within the latest edition of the ripe-nonauth.db.gz file, i.e. ones that refer to in-region IP blocks:
In April I found 33 route objects in NONAUTH with a completely in-region range. I notified the maintainers and moved those routes to the RIPE database. The 4 cases you found are not completely in the RIPE region, so it's not clear if they should remain in NONAUTH or be (re)moved. None of the ranges appear to have been split by an inter-RIR transfer: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran... <https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/inter-rir/inter-rir-ipv4-transfer-statistics> But the route prefix falls between 2 RIR assignments
192.124.252.0/22
This prefix is referenced from 1 NONAUTH route 192.124.252.0/22AS680 The prefix is split between RIPE and ARIN: ripencc|DE|ipv4|192.124.252.0|256|19920812|assigned|472b74a8-9fd5-4837-9024-f7574bdd7f7c ripencc|DE|ipv4|192.124.253.0|256|19931019|assigned|e68966fe-33c9-47f0-ad13-e83ca182b8bf ripencc|DE|ipv4|192.124.254.0|256|19840101|assigned|e4626976-484a-4850-897d-d7be3e709511 arin||ipv4|192.124.255.0|256||reserved| I see 3 routes in the RIPE database: 192.124.252.0/24AS3320 192.124.253.0/24AS680 192.124.254.0/24AS680
192.70.0.0/17
This prefix is referenced from 1 NONAUTH route: 192.70.0.0/17AS2200 The prefix is mostly assigned to the RIPE region, except for a /24: ripencc|FR|ipv4|192.70.0.0|23552|19930901|assigned|4c5e10ae-266a-4127-84ac-04b780309b1d ripencc|FR|ipv4|192.70.92.0|1280|20050411|assigned|b8f87e41-6e2a-427f-af98-60c978d51985 ripencc|FR|ipv4|192.70.97.0|4352|19930901|assigned|3e011729-91a0-412e-8947-1ac32eef22e2 192.70.113.0 - 192.70.113.255 not in *any* delegated stats file? ripencc|FR|ipv4|192.70.114.0|256|19900315|assigned|3e219d39-a2e5-476b-bf9b-835f172f89ae ripencc|FR|ipv4|192.70.115.0|256|19900315|assigned|4d073146-29da-45c5-a74c-e90c3963405f ripencc|FR|ipv4|192.70.116.0|256|19900315|assigned|ef2d7312-e300-4850-83d0-e99faa095c12 ripencc|FR|ipv4|192.70.117.0|256|19930520|assigned|a4b599d8-871f-4f0a-b5c3-5b5d96a614e4
192.76.32.0/21
This prefix is referenced from 1 NONAUTH route: 192.76.32.0/21AS786 The prefix is split between RIPE and ARIN: ripencc|GB|ipv4|192.76.24.0|3072|19900815|assigned|1ae99a59-4b02-4c77-8ce0-e7e359a12842 arin|US|ipv4|192.76.36.0|1024|19900828|allocated|eaf44477133ed73a4fc62658b886953b
192.108.160.0/20
This prefix is referenced from 1 NONAUTH route: 192.108.160.0/20AS2607 The prefix is split between RIPE and ARIN: ripencc|SK|ipv4|192.108.134.0|10496|19910724|assigned|755273b5-19e0-4fae-95c4-0e804f714dea arin|US|ipv4|192.108.175.0|256|19910724|assigned|c096bf755fee3dfb7b9046461595ebd0
I'm not sure how these should be made to go away, but I wish they would. They offend my personal sense of fastidiousness, and I don't like unexplainable mysteries.
I suggest that the RIPE NCC emails the maintainer(s) of these objects, and ask them to update the routes so they align to the assigned regions. They are not using unregistered space, and are not eligible to be cleaned up. Regards Ed Shryane RIPE NCC
Note that the RIPE-NONAUTH route object 192.76.32.0/21 appears to have some counterpart route objects for sub-blocks of that /21 and these sub-blocks route objects are *not* marked as RIPE-NONAUTH, suggesting that there is no compelling reason for the 192.76.32.0/21 route object to be marked as RIPE-NONAUTH.
The same sort of syndrome appears to apply also in the case of the 192.124.252.0/22 RIPE-NONAUTH route object, i.e. in this case also there appear to be valid non-RIPE-NONAUTH route objects in the data base for sub-blocks of 192.124.252.0/22, which begs the question: Why is the 192.124.252.0/22 markes as RIPE-NONAUTH?
Regards, rfg