[db-wg] Bogon cleanup -- Current anomalies

In message <6C1149E8-E751-4863-BDCF-82C5D9D1CE5F at ripe.net>, 
Edward Shryane <eshryane at ripe.net> wrote:

>I will check why the routes you listed were not scheduled for deletion.

Thank you Edward.  I suppose that it may be the case that some of route
objects may relate to recent allocations (and thus I might have gotten
it wrong in those instances) but the last-modified dates on most of
the route objects I just posted seem to suggest otherwise, i.e. most
have been in existance for quite some time now.

>> and a great many of them refer
>> either to the 192.88.99.0/24 IPv4 block, which is apparently reserved
>> by RFC 3068, or to some IPv6 block which is *not* clearly related to
>> RFC 3068.  I am frankly not sure what to make of any of these, but I
>> do suspect that they are all invalid, because no RIR has assigned any
>> of the relevant IP space to any resource member.
>
>According to the implementation plan:
>https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
>
>if these ranges are not marked as "available" or "reserved" in an RIR's
>delegated stats, then it will be skipped, and I didn't find
>192.88.99.0/24 in any RIR's delegated stats.

The additional information that Job Snijders posted about these oddities
is both helpful and enlightening, but still leaves the question of the
status of such route objects a bit ambiguous, I think.

I personally have no preference or opinion whatsoever as regards to
whether these specific route objects should go or stay.  I'll be
happy to defer to wiser heads than mine on this point.  All I will
say is that until such time as some RIR lays claim to 192.88.99.0/24
via its daily stats file, the relevant route objects will continue
to show up in my automated analysis results.

>(To Ronald and the list) Should we add other sources of bogon prefixes
>(e.g. RFC 3068) to the implementation?

I would tenatively say "yes" but if others think there is some value in
preserving these route objects, then I can quite easily hack my analysis
scripts to ignore these ones, specifically, in future.  (Or alternatively,
some helpful RIR could step up and "claim" the block in its daily stats
file, which would also cause the relevant routes to disappear from my
bogon analysis results.)


Regards,
rfg


P.S.  The way I wrote my anaylsis scripts, *all* route objects within the
RIPE AUTH or NONAUTH data bases that refer to IPv4 and/or IPv6 addresses
that are not claimed by any RIR in their daily stats file will pop out
at the end of the analysis as "bogon routes".

I mention this only because Edward talked about "other sources of bogon
prefixes".  Believe me, if there were any route objects in the RIPE AUTH
or NONAUTH data bases that refered to, say, any part of 127.0.0.0/8 or
10.0.0.0/8 or any other RFC-reserved IP block, then I would have reported
those here already.

So it's really just this RFC 3068 stuff that is at issue.  No other RFC-
reserved ranges seem to associated with RIPE bogon route objects.