Problem Statement for Additional RIPE-NONAUTH Cleanups
Dear colleagues, Following the discussion on cleaning up the RIPE-NONAUTH database last year: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/SFN4AKUI2G3XCZB... and also following the discussion at the DB-WG session at the RIPE 91 and RIPE 92 meetings, here is a problem statement to reduce the size of the RIPE-NONAUTH database. Introduction ------------ The objects in the RIPE-NONAUTH database are not authoritative, and were created anonymously with a well-known password as out-of-region data in the RIPE IRR database. We don’t know who created this data or whether it is still valid. There are very few (< 100) updates per year, which suggests the data is not being maintained. The RIPE-NONAUTH database now contains about 44,526 objects (about the same since RIPE 92). The existing cleanup jobs and maintainers are not deleting much data. I propose to implement additional cleanups to further reduce the size of the NONAUTH database. Scope ----- I propose to implement two additional cleanups of objects in the RIPE-NONAUTH database, as previously discussed. (1) Delete NONAUTH objects with a matching VALID ROA. This will affect approximately 16,497 objects. (2) Delete NONAUTH objects with a matching object in another RIR database. This will affect approximately 27,449 objects. The implementation should initially reduce the size of the NONAUTH database by about 60%, and will continue to reduce over time. Out of Scope ------------ * I do not propose to delete the NONAUTH database completely, only to implement these additional cleanups. * RIPE-NONAUTH database objects will continue to be returned in queries. * Any objects created under IANA or ICANN action will be excluded. See https://mailman.ripe.net/archives/list/db-wg@ripe.net/message/D7242C4PRTXOPF... * Mirroring the NONAUTH database using NRTM will still be supported. Conclusion ---------- I’d like to propose creating a new Numbered Work Item for this problem statement. If the WG agrees with the problem statement, I will follow up with a more detailed Solution Definition, including: * Defining how to match candidate objects in the RIPE-NONAUTH database * Notifying maintainer(s) of affected objects in advance * Allowing maintainer(s) to opt-out (so their object is not deleted) * Documenting the cleanups on the website Regards Ed Shryane RIPE NCC
Edward Shryane wrote on 09/10/2026 15:56:
If the WG agrees with the problem statement, I will follow up with a more detailed Solution Definition, including: * Defining how to match candidate objects in the RIPE-NONAUTH database * Notifying maintainer(s) of affected objects in advance * Allowing maintainer(s) to opt-out (so their object is not deleted) * Documenting the cleanups on the website
this seems like a reasonable way of draining obsolete nonauth objects. Thumbs up from here at least. Nick
Hi, On Fri, Oct 09, 2026 at 03:56:52PM +0100, Edward Shryane wrote:
(1) Delete NONAUTH objects with a matching VALID ROA. This will affect approximately 16,497 objects. (2) Delete NONAUTH objects with a matching object in another RIR database. This will affect approximately 27,449 objects.
Sounds good. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet GmbH Geschäftsführer: Sebastian v. Bomhard, Joseph-Dollinger-Bogen 14 Maja von Bomhard D-80807 München HRB: 317057 (AG München) Tel.: (089) 32356-0 USt-IdNr.: DE813185279
Ed, Thank you for writing this up. I support the problem statement and a numbered work item for it. Both cleanups remove objects that have a better copy elsewhere, so what disappears is a duplicate, not information. Additionally, the database stops carrying data that nobody has maintained since it was created with the shared password. All the best, K. Kaveh
On Mon, Oct 12, 2026 at 04:34:50PM +0100, Kaveh Ranjbar via db-wg wrote:
Both cleanups remove objects that have a better copy elsewhere, so what disappears is a duplicate, not information. Additionally, the database stops carrying data that nobody has maintained since it was created with the shared password.
Kaveh summarizes it nicely. I support deleting the following classes of objects: * NONAUTH objects with a matching VALID ROA. * NONAUTH objects with a matching object in another RIR database. But just to be sure - can 'valid ROA' be defined as valid ROAs subordinate to the following RPKI Trust Anchors? afrinic.tal (key identifier EB680F38F5D6C71BB4B106B8BD06585012DA31B6) apnic.tal (key identifier 0B9CCA90DD0D7A8A37666B19217FE0D84037B7A2) arin.tal (key identifier 13D4F24F9A9FCD98DB36F930631808C88F3974BC) lacnic.tal (key identifier FC8A9CB3ED184E17D30EEA1E0FA7615CE4B1AF47) ripe.tal (key identifier E8552B1FD6D1A4F7E404C6D8E5680D1EBC163FC3) I believe the RIPE-NONAUTH cleanup should not use the dangerous 'AS0' TALs that APNIC & LACNIC maintain alongside their normal 'production' RPKI. Kind regards, Job ps. For a detailed write-up on why AS0 TALs are bad for business please see https://mailman.ripe.net/archives/list/routing-wg@ripe.net/message/3MPEL5Q4I...
Hi, On Wed, Oct 14, 2026 at 11:57:17AM +0000, Job Snijders via db-wg wrote:
* NONAUTH objects with a matching VALID ROA. [..] I believe the RIPE-NONAUTH cleanup should not use the dangerous 'AS0' TALs that APNIC & LACNIC maintain alongside their normal 'production' RPKI.
RIPE-NONAUTH has no single object with "origin: AS0". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet GmbH Geschäftsführer: Sebastian v. Bomhard, Joseph-Dollinger-Bogen 14 Maja von Bomhard D-80807 München HRB: 317057 (AG München) Tel.: (089) 32356-0 USt-IdNr.: DE813185279
On Wed, Oct 14, 2026 at 06:57:03PM +0200, Gert Doering wrote:
On Wed, Oct 14, 2026 at 11:57:17AM +0000, Job Snijders via db-wg wrote:
* NONAUTH objects with a matching VALID ROA. [..] I believe the RIPE-NONAUTH cleanup should not use the dangerous 'AS0' TALs that APNIC & LACNIC maintain alongside their normal 'production' RPKI.
RIPE-NONAUTH has no single object with "origin: AS0".
Yes, but my comment about the presence of AS0 ROAs under these non-standards TALs. I posit that the cleanup should happen based on the 'normal' Trust Anchors, not the 'special' ones. Kind regards, Job
Hi, On Wed, Oct 14, 2026 at 05:17:33PM +0000, Job Snijders wrote:
On Wed, Oct 14, 2026 at 06:57:03PM +0200, Gert Doering wrote:
On Wed, Oct 14, 2026 at 11:57:17AM +0000, Job Snijders via db-wg wrote:
* NONAUTH objects with a matching VALID ROA. [..] I believe the RIPE-NONAUTH cleanup should not use the dangerous 'AS0' TALs that APNIC & LACNIC maintain alongside their normal 'production' RPKI.
RIPE-NONAUTH has no single object with "origin: AS0".
Yes, but my comment about the presence of AS0 ROAs under these non-standards TALs.
I posit that the cleanup should happen based on the 'normal' Trust Anchors, not the 'special' ones.
"NONAUTH objects with matching valid ROA" would imply "origin: AS0" to be relevant for the "special TAL for AS0 ROAs" question, no? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet GmbH Geschäftsführer: Sebastian v. Bomhard, Joseph-Dollinger-Bogen 14 Maja von Bomhard D-80807 München HRB: 317057 (AG München) Tel.: (089) 32356-0 USt-IdNr.: DE813185279
On Wed, Oct 14, 2026 at 09:40:56PM +0200, Gert Doering wrote:
On Wed, Oct 14, 2026 at 05:17:33PM +0000, Job Snijders wrote:
On Wed, Oct 14, 2026 at 06:57:03PM +0200, Gert Doering wrote:
On Wed, Oct 14, 2026 at 11:57:17AM +0000, Job Snijders via db-wg wrote:
* NONAUTH objects with a matching VALID ROA. [..] I believe the RIPE-NONAUTH cleanup should not use the dangerous 'AS0' TALs that APNIC & LACNIC maintain alongside their normal 'production' RPKI.
RIPE-NONAUTH has no single object with "origin: AS0".
Yes, but my comment about the presence of AS0 ROAs under these non-standards TALs.
I posit that the cleanup should happen based on the 'normal' Trust Anchors, not the 'special' ones.
"NONAUTH objects with matching valid ROA" would imply "origin: AS0" to be relevant for the "special TAL for AS0 ROAs" question, no?
Ah, right, thanks. Good point :-) Kind regards, Job
Sorry for my confusion yesterday, wires got crossed (I was thinking in terms of RFC 6811 matching / containment checking). This is the portion from my earlier message that's relevant: On Wed, Oct 14, 2026 at 11:57:17AM +0000, Job Snijders wrote:
I support deleting the following classes of objects:
* NONAUTH objects with a matching VALID ROA. * NONAUTH objects with a matching object in another RIR database.
Kind regards, Job
Hi Everyone, I believe everybody has had the time to express their opinion on this. So, just in time for the DB-WG session at RIPE-93, I'd like to declare this NWI-22. :D As always, I'd like to thank everybody for taking the time to contributing. Kind regards, David On behalf of the DB-WG Co-Chairs. On 10/15/26 9:38 AM, Job Snijders via db-wg wrote:
Sorry for my confusion yesterday, wires got crossed (I was thinking in terms of RFC 6811 matching / containment checking).
This is the portion from my earlier message that's relevant:
On Wed, Oct 14, 2026 at 11:57:17AM +0000, Job Snijders wrote:
I support deleting the following classes of objects:
* NONAUTH objects with a matching VALID ROA. * NONAUTH objects with a matching object in another RIR database. Kind regards,
Job ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Hi Ed, I am aligned with Kavel as well and I totally support this proposal. The methodology described is a good way to move forward with this task. Kind Regards Stavros P.S: Ideally, we should get rid completely of RIPE-NONAUTH just like ARIN did with its own, right? From: Kaveh Ranjbar via db-wg <db-wg@ripe.net> Date: Monday, 12 October 2026 at 17:35 To: db-wg@ripe.net <db-wg@ripe.net> Subject: [db-wg] Re: Problem Statement for Additional RIPE-NONAUTH Cleanups Ed, Thank you for writing this up. I support the problem statement and a numbered work item for it. Both cleanups remove objects that have a better copy elsewhere, so what disappears is a duplicate, not information. Additionally, the database stops carrying data that nobody has maintained since it was created with the shared password. All the best, K. Kaveh ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
participants (7)
-
David Tatlisu -
Edward Shryane -
Gert Doering -
Job Snijders -
Kaveh Ranjbar -
Nick Hilliard -
Stavros Konstantaras