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:
But the route prefix falls between 2 RIR assignments
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
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
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
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