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