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 <[email protected]> wrote: > Hi Ronald, > > > On 20 Jul 2021, at 21:03, Ronald F. Guilmette via db-wg <[email protected]> > wrote: > > > > According to information given to me by Edward Shryane < > [email protected]>, > > 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 > > > > >
