In message <[email protected]>, Edward Shryane <[email protected]> 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.
