Hi,

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

With regards to that specific prefix I feel like that should absolutely be added given that it was also deprecated and terminated in the IANA registry in 2015.

With regards to other bogons, I feel like at least for the prefixes that are listed as not globally reachable in the "IPv4 Special-Purpose Address Registry"[1].

I have not evaluated this in great detail though and this is just my initial thoughts.

Are there any route objects that would be impacted by this change outside of 192.88.99.0/24?

If the answer is no, then I would suggest that all non-globally reachable prefixes listed in the special-purpose registry be added to the bogon cleanup.

P.S. Ronald, you probably want to at least exclude this from your script "192.31.196.0/24 112 2018-09-04". :)

[1]: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

-Cynthia

On Tue, Jul 20, 2021 at 10:12 PM Edward Shryane via db-wg <db-wg@ripe.net> wrote:

Hi Ronald,

> On 20 Jul 2021, at 21:03, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
>
> According to information given to me by Edward Shryane <eshryane@ripe.net>,
> the cleanup of bogon route objects which made reference to bogon IP
> address space should have been completed the night before last.
>

To be clear (apologies it was not), the outstanding route objects were deleted *last* night, not the night before last.

The cleanup job ran first on the morning of 30th June, the maintainers were emailed a week later on 6th July, and the route(6) objects were deleted two weeks after that (last night).

In summary, the job deleted 863 route(6) objects in RIPE-NONAUTH, except for 7 which were excluded.

We received two tickets from maintainers, asking to exclude those 7 route(6) objects from the cleanup, and we are currently in discussion with them.

The latest split files in https://ftp.ripe.net/ripe/dbase/split/ were generated this morning around 05:50 UTC so do not contain the deleted route(6) objects.

> My latest analysis suggests that a few such route objects escaped the
> net and are still present within the NONAUTH data base. These route
> objects are summarized below. I'd appreciate it if others would take a
> look at these and tell me if they think that these route objects should
> or should not be present within the data base.
>

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

> Note that both batches of bogon routes given below are really rather
> curious due to the fact that nearly all of the routes have the exact
> same last-modified date (2018-09-04)

I think this is because the NWI-5 implementation that created the RIPE-NONAUTH database for out-of-region route, route6 and aut-num objects was run on September 4th, 2018, and many of those objects have not been modified since then.

> 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.

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

Regards
Ed Shryane
RIPE NCC