In message <CAKw1M3PPUM4qdwCOLgiY=gkuintknm4s5umrozrphzoc3_q...@mail.gmail.com>, =?UTF-8?Q?Cynthia_Revstr=C3=B6m?= <[email protected]> wrote:
>Are there any route objects that would be impacted by this change outside >of 192.88.99.0/24? Just 192.31.196.0/24, I think, based on my results so far. >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. I agree. This is -not- actually an issue at the moment... except for the very unusual cases of 192.88.99.0/24 and 192.31.196.0/24... but I suspect that everyone would agree that *if* there existed a route object in the data bases for, say, 127.0.0.0/8, most people would probably like to see that go away. So the default should be that any routes that exist to IANA-reserved IP blocks should get cleaned up along with the rest. >P.S. Ronald, you probably want to at least exclude this from your script >"192.31.196.0/24 112 2018-09-04". :) Yes, well, I did just notice that additional oddity yesterday, and I'm frankly a bit concerned about how this one will be handled. I mean I've skimmed the relevant RFCs (RFC 7534, RFC 7535) and it is quite clearly a Good Thing that someone is sinking this inappropriate and pointless DNS traffic, but as far as having a route object for this in the RIPE NONAUTH data base? Well, I'm not so sure about that. What happens when the RIPE NONAUTH data base goes away entirely one day? Will this whole "AS112 Project" start to malfunction horribly? All things considered, I think it would be best if some helpful RIR effectively "claimed" the 192.31.196.0/24 block, started putting the block into that RIR's daily stats file, and if the route object pertaining to it were moved to a stable and permament home in that RIR's AUTH data base. Until these steps or some other appropriate solution is implemented I think it will be best if my scripts keep on reporting this one as an open issue. Regards, rfg
