[db-wg] RIPE-NONAUTH route object anomalies

Hi Ronald,

> On 10 Jun 2021, at 23:57, Ronald F. Guilmette via db-wg <db-wg at 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/transfer-statistics/inter-rir/inter-rir-ipv4-transfer-statistics <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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20210611/490cc1b3/attachment.html>