Hello, 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. 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. I found the above prefixes listed at iana.org: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia... https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-specia... 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. Please Comment, -- +358 44 9756548 / http://www.trex.fi/ Aleksi Suhonen / TREX Regional Exchanges Oy You say "potato", I say "closest-exit."