On Fri, Jan 31, 2020 at 09:04:58AM +0200, Aleksi Suhonen via db-wg wrote: > On 06/01/2020 16:26, Edward Shryane via db-wg wrote: > > The RIPE NCC Database team have now implemented the 2018-06 proposal > > (now ripe-731), "RIPE NCC IRR Database Non-Authoritative Route > > Object Clean-up". > > While I think this is a very commendable effort, I'm worried about > resources that have been assigned directly by IANA through IETF > action. They aren't covered by any RIR db and cannot be signed by > RPKI.
If they can not be signed by RPKI, these objects will not be impacted by clean up effort described in RIPE-731. So, I'd posit there is no reason to worry. > I'm primarily worried about the anycast addresses that we (AS29432) > announce: AS112 prefixes, 6to4 prefixes and Teredo prefixes. We're > already having trouble getting those into automatic filters, and I'm > worried that some day the route(6) objects might disappear completely. There is no proposal for further deletion as far as I know. Should at some point the Internet numbers community figure out a way how to do RPKI for such prefixes, again we wouldn't need to worry since the RPKI ROA registrations will act as a superior successor to the IRR registrations (and they wouldn't be in conflict). > I found the above prefixes listed at iana.org: > https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml > https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml > > I strongly suspect that there may also be a few root or TLD name > server prefixes that fall into this category, even tho they aren't > listed in the above links. > > As far as I've understood, IANA is not going to operate a RIR db or > start maintaining their own RPKI signer. So we have to find some other > solution. Ultimately this may need to be solved by an RFC, but I > thought I'd start here by soliciting some ideas and opinions on what > the correct approach should be. Until a problem has been defined, and a solution specified, I'm happy to accomodate this type of special registration in the NTTCOM database. Kind regards, Job
